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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...