Your Database Was Breached: Now What?

With high-profile breaches such as the ones suffered by RSA, Comodo, and Epsilon cluttering the newswires these days, even the most secure enterprises are given pause to think that they could be at more of a risk of a database breach exposure than they initially thought. And, yet, according to post-data breach response consultants, the majority of organizations today simply do not make plans for how they'd handle a big database exposure if they were struck.

That has to change, says Tom Quilty, CEO of BD Consulting, a data breach response firm. "People used to laugh at me when I said this, but it is not a matter of if, but when, a data breach will affect your organization," he says.

Quilty and Rick Kam, president and founder of post-breach response consultancy ID Experts, offer some step-by-step instructions on handling the situation when your security just doesn't catch the threat.

Develop A Plan
If it seems like most organizations are scurrying around like chickens with their heads cut off following a typical breach, then it probably is because they really don't have a clue what comes next. Most organizations suffer decision paralysis and extreme discomfort at having to work outside their comfort zones following a breach -- both common symptoms of failure to plan for the situation.

"If you have a plan, you'll be ahead of most organizations," says Kam, who in eight years has worked with 400 organizations, none of which had a post-breach plan in place. "They've had backup recovery plans, they've had business continuity plans, they even had plans if there was a fire. But because [a post-breach is] not required necessarily, it's one of the things they don't think about."

Part of the plan should include guidelines for how investigations will be carried out, who will work on an incident-handling team, how responsibilities will be divided within that team, who will head up the team, and when, how, and by whom notification will be made.

While there are some rudimentary database breach incident plans out there, Quilty says organizations would be best served by a plan that is tailored specifically to the organization's risk appetite, business needs, and customer make-up.

"I'm not a fan of cookie-cutter plans," he says. "But any plan is better than no plan at all."

Know Where Critical Data Resides
Many organizations face the monumental task of figuring out what exactly has been breached because they have not prepared with effective discovery practices in advance. In short, they just don't know where their critical information resides. It is common for organizations to lose track of databases containing the information, not to mention unstructured data scattered across the network and partner databases.

"If you know where the critical information is, it is easier to protect," BD Consulting's Quilty says.

This can be very difficult when databases are shared with partners. Some organizations have poor records of what went out the door, so when a partner is breached they are unable to notify customers of the impact. Take the Epsilon breach, for instance, for which the post-breach response from its business customers has been inconsistent.

"What's interesting to me is who I didn't get a notification from," says Quilty.

Organizations should not only be prepared to know where the data is, but also how it's being accessed. That means ensuring that logging is turned on where appropriate and the chain of custody for that data is airtight.

"Pertaining to databases and [other] logs, make sure you have consistent records," Kam says. "That's helpful in the investigation, and if you have any holes you create this massive unknown that just blows your investigation out of the water."

Triage, Then Gather Forensics Information
Quilty says that when a breach is first discovered, the very first step is triage. "I say, stop the bleeding first," he says. "If it's still going on, pull the plug, then come back to investigate."

If it is possible to pull attacked systems offline for forensics, do so. But if it is a critical database that has to stay live, then start with snapshots.

"You do the best you can; you want to do some sort of a live forensics where you can take a snapshot, and whoever takes it needs to say, 'I did this, this is something I do under my normal course of business,' or some verbiage that shows they did it in a legal manner for evidence," he says.

He says the snapshot should be copied, with one copy available for further investigation and the other set aside unmolested for evidence if a case goes to trial.

Next: Time for a team Quickly Convene An Incident Response Team
After the very immediate step of capturing evidence of a breach, it's time to get the incident response team together -- and fast.

"One of the first things that's most important is to bring together the incident response team quickly," ID Experts' Kam says. "Getting the team together helps deploy a coherent investigation, and they should be able to specifically come up with options for the executive team to make decisions quickly. Decisioning paralysis is one of your worst enemies because everyone is second-guessing each other, no one wants to put their name on the letter, and all sorts of crazy things happen."

Some common stakeholders include IT folks who can offer more investigation into technical evidence, crisis communication experts within PR, an outsourced firm that was picked ahead of time during the planning stage, the legal department, and executives from the corner office.

Don't Rush To Notification
While the first inclination of organizations is to notify customers as quickly as possible that something could put their identities at risk, Kam warns organizations not to rush to notification before getting enough information together from investigations. He cites Ponemon Research, which shows organizations that rush to notify tend to spend more on their breaches as a result.

"Organizations that rush spend more time and energy and money trying to deal with problems," he says. "What we recommend is doing a very thoughtful and thorough investigation to understand what happened, who's affected, and whether or not there are data elements that would create higher risk."

Consider the recent Comodo breach. Not more than a week after the certificate authority rushed to warn of problems, it had to revise the announcement to inform customers that the extent of damage was much worse. This type of "oops, it was way worse than we thought" announcement happens all of the time and could potentially be avoided with more thorough investigations.

Weigh Customer Perception With Liability Concerns Carefully
RSA is currently being hammered by customers and partners for its tightlipped status about what exactly was exposed in its SecurID breach, and many more organizations face a big challenge on how much to actually disclose during notification above and beyond the information laid out by disclosure laws.

"The more transparent the organization can be, even if they don't know a lot yet, the better off they'll be," Kam says. "Perception is a real challenge in these situations."

Quilty explains that there is a balancing act with legal departments, but businesses must consider customer goodwill and brand value when they're fessing up to a database exposure. "If you ask the lawyers for a statement, they want to tell you not to say a word, but that's the legal side," he explains. "From a company side and a reputation side, you have to explain it to customers."

Notify In Plain English And According To Risk
Similarly, organizations need to consider having the lawyers only advise and approve notification letters rather than write them, Kam says.

"Many letters you'll see are written by people who don't write for human beings -- by that I mean attorneys. They're trying to protect their position if these letters ever surface again," he says. "Our suggestion is that it's written in plain language so that the individuals receiving it understand what the risks are."

He believes that the easier it is to understand a notification letter, the lower the costs. There will be fewer calls from customers to handle and also a smaller likelihood of lawsuits if customers feel the company is being straight with them.

Don't Turtle Following Notification
The tendency of many organizations is to think of that breach notification letter as a grenade. They lob it over the wall into the public domain and then hunker down in the weeks ensuing with a lot of 'no comments' to customers and the media. Kam says that organizations can't do it that way.

"Treat this as a crisis communications event," he says, recommending that organizations bring in outside crisis communicators with experience in events such as these.

While RSA has received flack for failure to provide full transparency, Kam says its willingness to hold conference calls with customers and partners following the breach announcement could act as a good example for other businesses in a breach situation.

"It's a lot harder to put the grenade back in the box once it has gone off," he warns.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.