Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

11/3/2014
11:45 AM
Phil Smith
Phil Smith
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Preparing For A Data Breach: Think ‘Stop, Drop & Roll’

Breaches are going to happen, which is why we need to treat incident response readiness like fire drills, practicing time and time again until the response is practically instinctive.

When there’s a fire, most of us know what to do. We have practiced for decades -- at school, home, and work -- because if we immediately know how to respond, we can significantly minimize the damage.

What about a data breach? How should businesses respond? From what we have seen, after conducting hundreds of post breach forensic investigations every year, many businesses do not know how to respond, leaving ample time for an attacker to move throughout their infrastructure stealing data.

Preparing for a data breach is three-fold -- pre-planning, responding, and testing. If an incident response readiness program is not up-to-date and not tested, the response will be unorganized and lead to mistakes delay, and further exposure. Executives and lawyers will be scrambling for answers and unintentionally divert IT and other resources from responding to the actual incident.

For example, during one of our investigations, the business’s IT team assumed all of its security technologies were reporting into a central logging server so if a breach occurred, the team would be able to analyze the activity leading up to the breach. However, when we arrived, we noticed the central logging server was not connected and therefore we did not have activity logs for critical servers. The flaw left us, and more importantly the victim, with many unanswered questions about the intrusion including when they were breached, how they were breached, and what data was exfiltrated. The business was perplexed as to whether it had statutory disclosure obligations. Testing the IR program would have detected such a problem.

In many of our investigations, we encounter businesses that struggle to answer our basic questions such as who has access to systems that have been breached or systems that contain information necessary for our investigation. We often see unorganized contact lists with out-of-date information which severely impacts a post-breach investigation. Panic begins to set in when a business cannot figure out who is the appropriate IT resource for a particular system or they are unable to contact that person due to vacations or weekend issues. The executives begin to lose confidence in both the staff and the response.

Businesses must implement an IR readiness program that includes identifying where their business’s valuable data lives, who has access to it, which controls are in place to protect it as well as step-by-step details of how to respond to an incident and make sure the plan is practiced on a regular basis. We are not trying to trivialize the level of effort to maintain and exercise an IR program but the ROI for such an effort is a significant reduction of damage from a breach and the ability to recover more quickly. According to the 2014 Trustwave Global Security Report, the median number of days it took organizations that self-detected a breach to contain the breach was one day, whereas it took organizations 14 days to contain the breach when it was detected by a third party.

All of these elements play a critical role in an effective incident response and if businesses practice the plan on a regular basis, when they are breached, their response will be effective. For example, if the business that had misconfigured the central logging server had tested its readiness plan, it would have discovered the issue before a critical incident. When there is a breach, if the in-house team knows who to call, what unusual activity had taken place, where their most sensitive data is stored, who can access it, how they should respond (which includes notifying customers, getting their legal and human resources teams involved, and collecting information for investigators), and how they can stop the attack from escalating any further, they can minimize the damage and get back to business-as-usual more quickly.

It’s no longer a surprise. Breaches are going to happen, which is why we need to treat incident response readiness plans as business as usual just like fire drills -- practicing time and time again until the response is practically instinctive.

Phil J. Smith is Senior Vice President of Security Solutions at Trustwave. He has more than 14 years of federal criminal investigative and prosecutorial experience, having served as both a Special Agent with the US Secret Service and as a Senior Trial Attorney with the US ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
I 'Hacked' My Accounts Using My Mobile Number: Here's What I Learned
Nicole Sette, Director in the Cyber Risk practice of Kroll, a division of Duff & Phelps,  11/19/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industry’s conventional wisdom. Here’s a look at what they’re thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-2079
PUBLISHED: 2019-11-22
A cross-site request forgery (CSRF) vulnerability in the Activity module 6.x-1.x for Drupal.
CVE-2019-11325
PUBLISHED: 2019-11-21
An issue was discovered in Symfony before 4.2.12 and 4.3.x before 4.3.8. The VarExport component incorrectly escapes strings, allowing some specially crafted ones to escalate to execution of arbitrary PHP code. This is related to symfony/var-exporter.
CVE-2019-18887
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. The UriSigner was subject to timing attacks. This is related to symfony/http-kernel.
CVE-2019-18888
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. If an application passes unvalidated user input as the file for which MIME type validation should occur, then arbitrary arguments are passed to the underlying file command. T...
CVE-2019-18889
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. Serializing certain cache adapter interfaces could result in remote code injection. This is related to symfony/cache.