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
Oldest First  |  Newest First  |  Threaded View
Commentary
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
Edge-DRsplash-10-edge-articles
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-31811
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-31812
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-32552
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.
CVE-2021-32553
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-17 package apport hooks, it could expose private data to other local users.
CVE-2021-32554
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the xorg package apport hooks, it could expose private data to other local users.