News Database Security
Your Database Was Breached: Now What?
Don't rush to notification before getting enough information from your investigation, and when you do go public, be as open as possible
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.
More Security Insights
- Accelerating Economic Growth and Vitality through Smarter Public Safety Management
- Digital Transformation: Creating new business models where digital meets physical
- Get Actionable Insight with Security Intelligence for Mainframe Environments
- Technical Debt: Asset or Liability
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