Is Your Incident Response Process Robust and Up to Date?
Hackers and service outages are at the forefront of business leaders’ minds—and for a good reason: they’re increasingly common. Stay ahead of bad actors by creating your own incident response procedures.
Take a minute to think about your daily routine at work. What tools and processes do you interact with regularly? In the digital age, virtually everyone relies on internet-connected devices like smartphones, personal computers, and even cars. These machines deliver unprecedented flexibility, knowledge, and processing power to complete tasks that were unthinkable or impossible mere decades ago.
Electronics are so widespread that they’re simply quotidian. Imagine joining a company that still insists on sending business records by mail. Your first question would be: “Why isn’t this digitalized?”
But when we solve one problem, another will likely take its place. The cyber-revolution has bestowed vast opportunities for businesses, but it has done the same for criminals.
Memorial Health System in Ohio has embraced the digital revolution in all aspects of its business: Everything from advanced medical imaging machines like MRIs to the cafeteria cash registers is internet-connected. That allows them to serve their community more efficiently, but it also opens their system to potential penetration by malicious actors.
When Memorial became the target of a ransomware hack, they sprang into action. Quarantining infected servers, temporarily transitioning to paper records, and using alternative ways to communicate with their partners allowed them to maintain business continuity while simultaneously eradicating the harmful code. They knew what they needed to do well before the cyberattack occurred.
The way in which Memorial responded to the hack—known as their incident response process—was critical to getting back on their feet quickly. Want your organization to be as resilient as Memorial Health? Then you need to design your own cybersecurity incident response process.
Download Our IT & Cybersecurity Communication Templates
What Is the Incident Response Process?
When an organization is compromised by a cyberattack, the procedures they activate are known as the “incident response process.” There are five phases of incident response:
- Cyber threat assessment
- Detection
- Investigation
- Alleviation
- Preparing and improving
Broadly speaking, an incident response plan empowers an organization to recognize and prioritize the threats they are likely to face. Planning an effective response mitigates the cyber threat itself and minimizes damage to the business overall.
Each of the five phases incorporates a variety of actions and depends on diverse stakeholders. You’ll collect all the steps of this process in a “computer security incident handling guide.” Think of this as your playbook.
The Computer Security Incident Response Team (CSIRT)
Yes, the IT and information security teams will always be primary stakeholders when you initiate an incident response process, but they’re not the only ones who touch sensitive digital systems. In order to connect all personnel who play a role in organizational cybersecurity, your HR leaders will be tasked with spreading the word of an active incident, and representatives from your operations team will help ensure business continuity. The physical location where the CSIRT often operates is known as the security operations center (SOC).
The composition of your IR team will vary depending on how your company is organized and the type of digital systems you rely on.
The Phases of an Incident Response Plan
1. Cyber risk assessment
Before you charge onto the digital battlefield, you need to do some reconnaissance on your potential enemies first. A cyber threat assessment is a process by which your organization determines what digital risks are most likely to occur and the severity of the damage they would cause. These can and should cover all areas of the business, from digital access control systems to your firewall to remote-working tools and beyond.
While this risk assessment is considered part of the incident response plan, according to some, it is not part of the incident response process, which starts only when a real threat is detected. However, you can’t have an incident response process without a threat assessment, so we like to think of them as part of the same project.
Once you and your team are confident in your list, it’s helpful to plot these threats on a threat matrix—a visual representation of the likelihood and severity of each—leaving you with an easy-to-read table that can help with prioritization of your incident response plans.
2. Threat detection and investigation
Here’s when the incident response steps begin in earnest. Now that you know what kind of threat vectors and vulnerabilities to look out for, you should also know what specific events will clue you in to the fact that you are currently under attack. Think of these as the trigger mechanisms for your various plans.
These triggers should be specific to individual root causes. After all, you aren’t going to respond in the same way to every type of incident, which means that you’ll need similarly unique ways to kick off your plans. For example, if an unauthorized user from another continent logs into a sensitive database, the trigger should alert an on-shift IT manager to investigate and block further access. Try to account for false positives—maybe an employee is innocently trying to log in while abroad—but always prioritize system safety.
In another case, say your email system experiences an outage stemming from non-malicious causes. In that case, you don’t need to worry about bad actors, but you do have to keep business going without a critical system in play. This trigger might also alert an on-shift IT manager but will kick off an entirely different response focused on standing up an alternative communication plan.
An equally important part of this step is determining how this incident occurred. Was it an error on the part of your third-party software provider? Was it a successful password phishing attempt against one of your employees? Noting the specific causes of the incident will not only help your incident response team fix the problem quickly but will also help you improve for next time when you’re ready to reflect on the incident.
You might also need to alert law enforcement or the proper authorities of a security incident if it puts other entities “downstream” of your company at risk, especially if you’re a government contractor. The DOJ has even announced that it will sue federal contractors that hide these incidents.
3. Eradication/alleviation
Now, it’s time to roll up your sleeves and remedy the issue. Your incident response team’s first priority is to contain the threat or security breach and prevent any further damage. In the case of a data breach like ransomware or malware, quarantining infected devices by disconnecting them from your internal network can arrest the spread of the bug while the team works to eradicate it.
At this point, your incident response plan intersects with your business continuity plan. As your team works to regain control of the situation, you should deploy backup solutions so critical work can continue despite the disruption. Mitigation methods include secondary computer systems, paper records, and restoring offsite backups of currently affected systems.
Once the original issue has been effectively quarantined, restored, or circumvented, it’s time to restore normal operations. Be sure to monitor all digital operations once they resume to confirm that all problems have been fixed.
4. Protecting against future incidents
The dust has settled, work is back to normal, and the incident response team returns from cyberspace triumphant. But there are still post-incident activities to complete. Gather your incident response team, as well as cross-departmental functions that were affected by the incident, to create an after-action report. This report is a detailed retrospective that explains how the incident occurred, what was done to counteract it, and the outcome of those response efforts.
The part of this that will materially improve your plans is where you reflect on what went well, what could have been done better, and what unforeseen circumstances impacted the incident response. You might find certain metrics, such as total downtime, helpful in gauging the efficacy of your response. Then you can look back on your documented incident response plans and adjust them to account for these revelations, strengthening them over their lifecycle.
Resources and Tools
Here are some of our favorite resources from trusted professionals to help your organization boost its incident response capabilities.
- AlertMedia’s IT & Cybersecurity Communication Templates
- AlertMedia’s After-Action Report Template
- National Institute of Standards and Technology’s (NIST) Incident Handling Guide
- SANS Incident Management 101
Responding in Advance
Cyber incidents are chaotic and confusing, meaning they’re the worst environment in which to make a plan. The entire purpose of an effective incident response plan is to do that work before a security event occurs. By discovering which incident response processes work for you, you’ll be in a better position to react quickly and avoid the impacts of a negative incident.
