09:00 AM
Connect Directly

5 Big Incident Response Mistakes

Failing to have a formal incident response plan is just one of the mistakes organizations make.

Organizations that suffer major security incidents can end up spending tens and even hundreds of millions of dollars in remediation costs, fines, damages, and other expenses. Many suffer considerable brand damage as well.

While the initial breach itself tends to draw the most attention, how an organization responds to the incident shapes the eventual scope and damage of the attack. This is where being prepared for a breach can help, according to security analysts. Organizations with a formal incident response plan and process in place generally are better able to contain resulting costs and damage.

A Ponemon report last year showed that companies worldwide that had an incident response team spent about $12.60 less per record on average on response and mitigation costs compared to those that did not have one.

Not having a formal plan and being unprepared are just two of the mistakes that organizations make. Here are some of the others:

1. Responding before understanding the full scope of the breach.

Modern attacks are not quite as noisy and random in nature as attacks of the past. They are a lot more targeted, stealthy, and persistent. Companies sometimes may be more deeply compromised than an initial analysis might suggest, says Wade Woolwine, director of global services at Rapid7.

“Victims often think that once they’ve found a backdoor, they’ve identified all ingress methods used by the attackers,” he says. The reality in many cases is that organizations fail to effectively investigate endpoints and other systems to derive reliable indicators of compromise and to use those IOCs to properly scope the incident across the enterprise, Woolwine says.

Not properly understanding scope is a huge problem, Ben Johnson, chief security strategist at Bit9+carbon Black, says. “An organization may have found patient 0, or maybe it has actually found patient 20,” Johnson says. “If it’s patient 20, there will be a lot machines to clean up. Understanding how big or small an incident is will be critical to proper response and recovery. “

2. Not communicating effectively.

The manner in which an organization communicates breach details to stakeholders is vital. Disclosing too many details without proper vetting is almost as bad as releasing nothing at all especially in incidents involving loss of personal data. Organizations need to have a formal post-breach communication plan beforehand, and not scramble to figure what to say publicly in the middle of a breach situation.

“Putting out a claim that only X number of records were accessed or saying that everything has been cleaned up when, in reality, you don’t know the full scope of the impact, or the incident is still being eradicated,” is inadvisable, Johnson says. “It is a dangerous path to navigate and puts a bigger target on the company’s back. “

If the information released turns out to be incomplete or incorrect, it also suggests a sloppy investigation, or that your organization does not have a proper handle on the situation.

3. Not getting legal involved early.

Data breaches can have legal consequences. Many organizations that have suffered data breaches in recent times have been hit with big lawsuits from victims claiming a lack of due diligence in protecting their data, loss of privacy, financial losses, and other issues. So it’s vital to get your legal team involved, or to get legal help, as soon as possible once you’ve discovered a breach.

“Legal does not often move at the speed of security and definitely not at the speed of attackers,” concedes Johnson.

But that’s no reason for not getting them involved quickly anyway, he says. “Legal should be responsible for coordinating with outside parties to avoid information leakage or disclosure to other parties."

Disclose information only under legal advice, and only when there are enough relevant facts around what happened, how, and whom it affected, he says.

4. Tipping your hand.

Playing “whack-a-mole” with an attacker is the best way to drive them deeper into your network, says Woolwine. When investigating a data breach, it is vital not to tip your hand to the attacker.

A knee-jerk reaction to an attack in many cases, for instance, is to immediately shut down affected systems. “For an attacker, this is an immediate indication that they’ve been made,” Woolwine says. “[This] usually results in the attacker establishing other methods of ingress and disappearing off the victim’s detection radar,” entirely, he says.

It’s only when you have fully scoped the breach and have a clear idea of the ingress points, the nature of the intrusion, attack tools, and tactics, that you should start shutting it down.

5. Using an improperly staffed response team.

Not all breaches are the same. A denial of service attack, for instance, is very different from a malware infection. A network intrusion by an external threat actor is different from one carried out by a trusted insider with privileged access to enterprise systems and data. So it is important to assemble the right team and have the right skills and resources in place when initiating an incident response.

Using the wrong people to investigate the breach is a mistake that organizations can often make, Woolwine says.

“Identifying the right technical expertise to investigate the breach is critical,” he says. Having inexperienced IT specialists who dabble in incident investigation or selecting a third party without the credentials to respond to an enterprise breach, can have major consequences, he says.

In addition to the right technical staff, an IR team should ideally also include representatives from legal, communications, HR, and other enterprise functions.

Ultimately though, the key to mounting a good response is planning and preparation, Woolwine says.

“Making sure that you have the technology, processes, and expertise at the ready to help your organization deal with the breach will help streamline the various breach response processes,” he says. It should “remove some of the firefighting stigma associated with responding to breaches.”

Interop 2016 Las VegasFind out more about attacks and breaches at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Register today and receive an early bird discount of $200.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
2/19/2016 | 4:27:08 AM
2016 should be the year of Incident Response
During last months, I have read a lot of articles about Incident Response and it seems it would be the buzz word during this year.

For sure, these 5 tips are a great start point to advance from a protect and detection view to the protect/detection/response view. FMPOV, this is the only way to fight properly against cyberattacks.
User Rank: Apprentice
2/14/2016 | 9:12:34 AM
Great tips
Great tips to reduce the possibility of an inneficient incident response plan.


I just want to add that have a good response protocol against incidents, categorizing and identyfing possible response process by information assets is very effective.




Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.