In some ways, incident response is both anticlimactic and depressing! After all, you have spent endless hours getting to this point, only to turn around and develop a plan for when all you’ve done proves inadequate to the task. You’ve built a defensive perimeter around your castle, but you still need to make a plan for what happens when the enemy crosses the alligator moat anyway. What a joy!
In the 2015 movie The Martian, the main character teaches a group of aspiring astronauts. He tells them:
“At some point, everything’s gonna go south on you… Everything’s going to go south and you’re going to say, “This is it. This is how I end.” Now you can either accept that, or you can get to work. That’s all it is. You just begin. You do the math. You solve one problem…and you solve the next one…and then the next! And if you solve enough problems, you get to come home!?
Honestly, if there is a better description about what an incident response plan looks like, I have not found it!
Incident Response Planning: Not Just a Good Idea—It’s the Law!
You may have heard of FISMA. It stands for Federal Information Security Management Act. It was signed into law in 2002, and it essentially requires all federal agencies to develop an incident-response plan.
I know what you’re thinking—“But my company is private, so why should I care about federal regulations?” The reason is similar legislation requiring your firm to do the same is already here. For example, New York State passed 23 NYCRR 500, a regulation requiring most financial and insurance firms to retain a chief information security officer (CISO), have a robust cybersecurity program, perform risk assessments and testing, roll out two-factor authentication, and report incidents within the first 72 hours. And, of course, develop an incident-response plan.
Today, having an incident-response plan is either mandated by regulators or most certainly expected by your vendors and clients. If you don’t have one, you will either lose business or fail to gain business.
Consider seatbelts. Once considered optional, the current policy on seatbelts is “Click it or ticket.” Having an incident response plan is like a seatbelt for your business. It may not prevent an attack (that’s what all the other stuff is for), but if one happens anyway, it will help limit the damage and recover the business.
Another reason why regulators are getting increasingly intrusive by requiring incident response plans is that insurance companies and governments are not prepared to shoulder the hits from an attack alone. The cost of a breach is going up by the day, and with privacy regulations being what they are, you should expect these costs to continue to rise for the foreseeable future. In some cases, this cost has been terminal to the business.
The good news is that there are plenty of resources to help you develop an incident response plan. The bad news is that developing an incident response plan can be fairly complicated.
In a sense, it’s similar to building a hospital. The basics are obvious: You know it must have an emergency room, diagnostic facilities, intensive care units, operating rooms, patient rooms, offices, and so forth. But that’s just the beginning! You also need to know the community that this hospital will be serving. Is it a metro area? Is it a small town? A group of isolated villages? Is the hospital in the tropics? The Arctic? And more questions follow: Who’s funding it? The community? A wealthy donor? Is this a private company or government-owned? What kind of specialties will it have?
You get the idea. Your preexisting knowledge of minimum essential services plus demographics, geography, and budget will go a long way in deciding size and scope. For example, maybe your hospital can handle most everyday types of medical care, but when it comes to transplants, you’ll need to refer the patient to a more specialized facility.
The same is true with your incident-response plan. Your firm’s size, location, and budget will determine how sophisticated the plan will be. A small company may have an incident response plan that calls for identifying an incident and immediately calling in outside expertise. A larger firm may have multiple incident response specialists in-house. As you can guess, the most critical step in developing your incident response plan is going into it prepared to answer these questions, with the privacy impact questions at the top of the list! What happens when the PII you so carefully guard are exposed? How do you recover? What is the liability?
The answer to all these questions will guide your incident-response plan. Some of the answers will come from your asset discovery-in-depth exercise and the resulting spreadsheets. Other answers will come from your risk register that ingests information from your cybersecurity and privacy programs. The rest of the answers will come from your board of directors (or equivalent corporate authority); they are the governance body that is most informed about risk, and they alone can set the risk appetite and tolerance.
Incident-Response Plan Phases
Back in 2012, the National Institute of Standards and Technology (NIST) in Gaithersburg, Maryland, was hard at work releasing “NIST Special Publication 800-61 Revision 2: Computer Security Incident Handling Guide.” You have to hand it to them; their titles are killers! But that’s nothing compared to what’s inside.
Currently, NIST 800-61r2, as it’s known, is required reading for anyone in the cybersecurity field. It is a beautiful piece of work, and if you plan to get hands-on with incident management, you need to get to know it. You should also get cozy with other reports with captivating titles such as “ISO/IEC 27035-2 Information Technology—Security Techniques—Information Security Incident Management—Part 2: Guidelines to plan and prepare for incident response.” (No, I am not kidding. That’s the title. Fantastic work, too.)
And while you’re at it, you should also consult ENISA’s “Actionable Information for Security Incident Response” and “Strategies for Incident Response and Cyber Crisis Cooperation,” as well as their “NCSS Good Practice Guide—Designing and Implementing National Cyber Security Strategies.”
What do you need to understand from all this? What are the essential elements of an incident response plan that you need to own in order to complete your own privacy-centric cybersecurity program?
The first critical thing to understand is that incident response is a program in and of itself. As such, it has its own distinct phases, and much like the overall cybersecurity program, it, too, is a living program. It’s not one and done–it should be continuously managed.
What are the phases? Have you heard of Elisabeth Kübler-Ross’s five stages of grief: denial, anger, bargaining, depression, and acceptance? Many people go through them during an incident: “No! This can’t be happening to us!” followed by choice expletives, then by the desire to pay to make this go away, quickly replaced by depression about having to face the music, and finally acceptance of the fact that you, like millions of others, have fallen victim to a cybercrime.
Thankfully, the core phases of incident-response planning are less gloomy. They are: preparing for incidents, identifying the occurrence of an incident, containing the incident, treating the incident (e.g., killing the virus, disabling access, etc.), recovering from the incident, and post-incident review, aka the “lessons learned” phase. That last one is key and should never be omitted.
To properly prepare for an incident you need to have four things in place:
- an active privacy program;
- an active cybersecurity program;
- a business-continuity plan; and
- a disaster-recovery plan.
The first two are rather obvious: you can’t develop a privacy-centric cybersecurity incident response plan unless you have both active privacy and cybersecurity programs going.
The business-continuity (BC) plan is the document that the business has prepared to ensure continuity of operations and value delivery in case of disruption. A business disruption could involve a natural disaster such as a hurricane, an earthquake, or a disease outbreak such as the most recent COVID-19 pandemic. Or it could be a man-made disaster such as a terrorist attack or a cyberattack. It could even involve a simple human failure, like if Julie from Accounting gets food poisoning from the cafeteria’s tacos, and she’s the only one who can get people paid!
The BC plan has all sorts of useful information that feeds into the incident response plan. For example, it has a defined business-continuity organizational structure, policies, and workflows, as well as information about who can trigger the BC plan and how that occurs, detailed contact information, including emergency contact numbers, client and vendor information, relocation strategies, recovery procedures, and the like. The benefit of the BC is that if and when it is invoked, different parts of the business execute different workflows designed to protect people, communicate effectively with all affected, and initiate as rapid a business recovery as possible.
The disaster-recovery plan (DR) is technology-centric. Its focus is in recovering the technology infrastructure of the company. This is where you will find all our favorite acronyms and their values per system: recovery time objectives (RTO), recovery point objectives (RPO), and the maximum tolerable downtime (MTD). All directly influence the incident response plan.
Consider, for example, if your MTD is zero. Who has such zero tolerance for downtime? Trading systems. Banking systems. Air-traffic control systems. Utility systems. (And, for some of us, Uncle Bob’s Bagel and Pastrami Paradise.) How do their incident response plans address this requirement, keeping in mind that a cyberattack on a trading system may well have serious regulatory implications, which means preserving evidence, forensics, and so forth? You would need to plan for a zero MTD and remain compliant with regulations, which means you can’t just kill the intruder, reboot the system, and be back in business. As a matter of fact, shutting down an infected system would wipe its volatile memory, destroying any forensic data that may be there.
Do you see now why planning ahead is so important? You need to take this a step at a time. Also, it is in the DR plan that you will find the pertinent privacy metrics that apply to your information technology ecosystem. The reason for that is straightforward: The technology ecosystem is the one that both hosts, processes, and shares PII internally and externally. Therefore, its DR plan addresses the recovery steps necessary for all digital PII.
Now that you understand the basics, in “Creating Your Incident Response Plan,” I’ll walk you through some of the key decisions you’ll need to make as you go forward.
0 Comments