10 Essential Elements For Your Incident-Response Plan
The middle of a DDoS attack or ransomware infection is hardly the time to start talking about divisions of labor, or who should do what when.
February 2, 2017
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt21d5947721a2f829/64f0d9218e08dfc90f942522/01-incident.response.jpg?width=700&auto=webp&quality=80&disable=upscale)
Failing to plan, as we know from Zen masters and MBA lecturers, is planning for failure. So when things go off the tracks with networks, servers, or your data, you need to have a plan, even if it's super-basic or seems gratuitous. Some back-of-the-envelope notes won't do the trick, nor will trying to recall hazy remnants of conversation from that night you and a coworker discussed incident response over a couple beers.
The middle of a DDoS attack or ransomware infection is not the time to be talking about divisions of labor or who should do what, crisis communications experts remind us, and they're right. Have an incident response plan, even if you don't follow it to the letter, or are forced to improvise more pieces of it than you'd like. You can minimize the improvisation and come out the other side in better shape if your incident response plan incorporates many of these steps. You can also recover more quickly and get on with the business of serving customers and making money.
The scope and scale of an incident aren't always immediately evident; it can take 24 hours or more to determine exactly what happened, depending on the impact and type and type of incident. So company management will have to work closely with the legal department or retained counsel to determine if the incident constitutes a regulatory issue, and whether the company is obliged to report it.
Making clear determinations about legal exposure was a lot easier 25 years ago, before a raft of corporate compliance laws were passed at county, state, federal and international levels. Additionally, financial services and healthcare companies operate under additional compliance constraints in which these determinations aren't always obvious. But getting all the information the legal teams needs should be a top priority in any incident-response plan.
Of course you want to find out what exactly happened, what's been exposed (or held for ransom, or shut down), and just how egregious the exposure is. And every good investigator knows you don't let the trail get cold, so IT forensics specialists stress the importance of gathering information on critical assets within the 24 hours of the incident.
"Companies don't always understand what their critical assets are, and that those assets can change over time," vArmour's Weatherford says. "Going back and doing that kind of forensics analysis sometimes takes time."
Let's say your forensics team comes back to say that the intruder is still active in your servers or databases. What does the chief executive do then?
Mark Weatherford of vArmour calls this the "CEO gut check." Decision-makers can either throw the bad guys out, or let them remain while investigators figure out how deeply the intruders have penetrated and how bad the problem really is.
"If you pull up the drawbridge, you've no idea what they've infected. If you monitor it for a week, two weeks, or a month, you can see what's been exposed and compromised," Weatherford says. "But it's hard to let somebody wander around your house and pretend they're not there."
And those in the "C" suite need to check their gut and see how much risk they can temporarily endure in the name of understanding more about the nature of the incident -- and the perpetrators.
Purists will quibble that incident-response planning can easily tip over in to business continuity, the skillset that ensures the business can still operate after some sort of incident, natural or man-made.
But in the event of a major technical incident, it's fair to ask as part of incident response what the plans are for staying in business when the impact of the incident is far-reaching. Incident-response plans should specify alternate resources where the organization can shift its operations, whether it's another data center, ISP or cloud provider, according to vArmour's Weatherford. The more attention paid to contingencies, the faster everyone can rebound from an incident.
Purists will quibble that incident-response planning can easily tip over in to business continuity, the skillset that ensures the business can still operate after some sort of incident, natural or man-made.
But in the event of a major technical incident, it's fair to ask as part of incident response what the plans are for staying in business when the impact of the incident is far-reaching. Incident-response plans should specify alternate resources where the organization can shift its operations, whether it's another data center, ISP or cloud provider, according to vArmour's Weatherford. The more attention paid to contingencies, the faster everyone can rebound from an incident.
Failing to plan, as we know from Zen masters and MBA lecturers, is planning for failure. So when things go off the tracks with networks, servers, or your data, you need to have a plan, even if it's super-basic or seems gratuitous. Some back-of-the-envelope notes won't do the trick, nor will trying to recall hazy remnants of conversation from that night you and a coworker discussed incident response over a couple beers.
The middle of a DDoS attack or ransomware infection is not the time to be talking about divisions of labor or who should do what, crisis communications experts remind us, and they're right. Have an incident response plan, even if you don't follow it to the letter, or are forced to improvise more pieces of it than you'd like. You can minimize the improvisation and come out the other side in better shape if your incident response plan incorporates many of these steps. You can also recover more quickly and get on with the business of serving customers and making money.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024