Attacks/Breaches
9/26/2013
05:34 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Establishing The New Normal After A Breach

Breach response shouldn't just be about notifications and system clean-up -- organizations can use their mistakes as learning aids to change processes and policies for lasting security success

As embarrassing and costly as a big data breach may be for an organization, many security professionals will tell you such an incident can be good news in the long run for a business' risk posture. Sometimes even after numerous warnings from security and risk advisers, the only way for senior managers to sit up and pay attention to a set of risks is to have an incident from that risk detailed blow by blow in the business press.

"Once an organization has gone through all that pain, they're forever changed," says Lucas Zaichkowsky, an enterprise defense architect at AccessData. "Your whole outlook changes."

For all of the problems that breaches bring, they also present a learning opportunity and potential for developing better processes that improve the day-to-day effectiveness of IT security. But that growth can occur only if organizations spend the time to thorough analyze the event to find the fundamental risk factors that contributed to a compromise.

"If you haven't taken the time to figure out what's wrong in your program or your technology, then it's pretty natural that it's going to happen again," says Vinnie Liu, managing partner for security consulting firm Bishop Fox.

[Are you getting the most out of security analytics? See Connecting The Dots With Quality Analytics Data.]

Unfortunately, some organizations today tend to engage in a type of whack-a-mole brand of incident response, responding to breaches and malware outbreaks only by cleaning up systems affected by the incidents but never delving into root causes, says James Phillippe, leader of threat and vulnerability services for the U.S. at Ernst & Young. Meanwhile, he says, "the root cause -- weak network controls, poor user education, weak policies, or perhaps improper architecture configurations -- will persist."

On the other end of the spectrum, many organizations recognize that they can't simply clean up systems after a breach and carry on as before. But because they react quickly without analyzing why things went wrong, they end up wasting a lot of money. And then they still end up breached again.

"I think a lot of recidivism stems from the knee-jerk reactions," Liu says. "You see something wrong, you buy a bunch of tools, you drop them in place, and you think you're safe."

This is why leveraging a breach for more executive buy-in, budget, and meaningful change requires you to use that event "in a balanced manner, not in a panic attack," says Robert Stroud, international vice president of ISACA.

Once a thorough post-mortem is done, he recommends either using an existing risk model or developing a new one and running the operational and financial impacts of the breach outcome through that model to understand how that changes risk calculations. From there, an organization can more clearly understand if it needs to only change a few controls, or if it needs to make a major overhaul in security processes.

"More often than not, we see organizations go, 'Hey, we've got to do something about that, let's just do it,' and they start executing immediately," Stroud says. "Organizations will go without any assessment, and spend significant money on potential vulnerability without any understanding of the business impact or risk exposure, potentially costing their business significant money. It might be more money than the risk itself."

As the experts have explained, establishing the new normal following a breach is going to take post-mortem analysis, and it's also going to require changing risk models. But, more significantly, it is going to involve sustained investment. The cost of upping the security game is easy to overlook amid all of the more picayune line-items of breach response, but process improvement should be part of the overall response budget once a breach has come to light.

"People talk about overlooking the cost of credit monitoring, reporting, fees, and things like that," Liu says. "But from what we've seen, I think some of the biggest investments that have to be made over the long term following a breach is for changing process."

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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
WKash
50%
50%
WKash,
User Rank: Apprentice
9/27/2013 | 9:52:28 PM
re: Establishing The New Normal After A Breach
User diversity and growth in network activity including
cloud services are among reasons it's getting harder to guard against
insider data breaches. That and some other factors, including advances in malware that make it easier for outsiders to work from the inside are among the reasons many IT pros say its getting harder than before to detect/prevent insider threats. We report more on that at: http://www.informationweek.com...
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0103
Published: 2014-07-29
WebAccess in Zarafa before 7.1.10 and WebApp before 1.6 stores credentials in cleartext, which allows local Apache users to obtain sensitive information by reading the PHP session files.

CVE-2014-0475
Published: 2014-07-29
Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC_*, (2) LANG, or other locale environment variable.

CVE-2014-2226
Published: 2014-07-29
Ubiquiti UniFi Controller before 3.2.1 logs the administrative password hash in syslog messages, which allows man-in-the-middle attackers to obtains sensitive information via unspecified vectors.

CVE-2014-3541
Published: 2014-07-29
The Repositories component in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to conduct PHP object injection attacks and execute arbitrary code via serialized data associated with an add-on.

CVE-2014-3542
Published: 2014-07-29
mod/lti/service.php in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to read arbitrary files via an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) is...

Best of the Web
Dark Reading Radio