As an IT security professional, you work hard to prevent cyberattacks. You patch your systems regularly, update antivirus libraries, run user trainings, and lock down user access to sensitive systems and data. You’re the poster child for solid cyberhygiene.
Despite all the money you spend, the tools you buy, and the effort you put in to prevent compromise, you will still be attacked. And even the best laid defenses can be bypassed.
When a cybersecurity incident does happen (and it will), you need a comprehensive incident response process to align your team and set them up for success. Building an incident response plan beforehand helps ensure your team will be prepared to efficiently investigate and handle cybersecurity incidents as they arise. Here are the top seven steps to keep in mind as you build your incident response process to help ensure your team can react quickly to contain the incident while minimizing business disruptions.
Step One: Define the Plan
Your organization needs incident response guidelines to help ensure everybody involved in responding to a security incident knows what they need to do during an emergency. It’s somewhat like that short briefing video airlines show when you get on plane. You’ve probably been on a plane hundreds of times before, yet they play that video every time. Why? In an emergency, it’s too easy to make a mistake and cause a bigger problem. Having a clearly defined incident response plan and process helps minimize issues and helps you recover quicker.
A good cyberincident response plan includes several key elements:
- Team members and roles—Every good incident response plan clearly defines established roles such as “incident commander” and “incident communications” who will get called in when needed. There are other team members who will be involved to work the incident, liaise with other parts of the business, or potentially communicate with customers. Specific roles relevant to your audience and the team members required to fill these roles should be defined upfront and given the authority to investigate, respond, and communicate as needed.
- Risk and severity criteria—Not all incidents are equal. Some cybersecurity incidents may be considered minor, while others may be catastrophic, like breach of valuable customer data. It’s important to establish clear guidelines and prioritization criteria to help you quickly and easily triage an incident to determine the level of response needed. Don’t be fancy. Use simple, well-defined criteria that can be evaluated with minimal effort when an incident arises.
- Communication—When an incident occurs, it’s important to communicate the existence of the issue quickly to those involved in incident investigation and response. It’s equally important to control communication while the team works on the incident so that information about the incident doesn’t leak before it is contained or fully understood. Establish a clear communication protocol for use during a cyberincident, then ensure the team follows it. Teams can easily forget incident response protocols in the heat of the moment—so document ahead of time and strictly enforce the process.
- Documentation—Every incident response plan should be clearly and fully documented to ensure everybody involved understands the process, team roles, how to respond, and how to communicate status of the incident both internally and externally. Review the incident response plan regularly and adjust as needed to account for changes in the business.
- Continuous Introspection—Each security incident will be different, and the team won’t know what they’re dealing with until they’re in the middle of it. The incident should be carefully managed and documented, and the process followed. After the incident is over, the team should conduct a post-mortem (though I prefer the word “retrospective,” as it’s less “death-like”) and learn from the experience. Determine what went well, what didn’t, and how the process can be improved, so you can improve the response for the next incident.
Make sure everyone understands what defines a security incident as well as the types of incidents your team must respond to immediately and which can wait. Part of this involves defining your highest risk data, user accounts, and assets. This allows you to set up additional preemptive safeguards and lets your team better understand the severity of the issue.
Finally, define what systems need to be online for business continuity. Your goal should be to minimize business disruption during a security incident.
Step Two: Assess the Situation and Triage
When an attack occurs, your team should try to quickly discover what happened and triage issues appropriately. This is only a first pass. They should look for the symptoms of the attack—were there multiple failed login attempts, or did a file attempt to edit registries?
Next, the team should ascertain what was targeted. For example, did the attackers target one machine? The full network? Were they after specific types of data? Was a database with critical customer data compromised? Was the data exfiltrated?
The goal here is to understand how widespread the issue is and to give the team enough context to decide how to react.
Step Three: Quarantine
Once the team assesses the situation—and knows which systems have been affected—unplug! Have them quarantine affected systems or user accounts to help ensure the issue doesn’t keep spreading. If possible, keep as many business-critical systems operational as you can.
Step Four: In-Depth Analysis
Once you’ve quarantined the affected areas, the incident response team can start to dig deeper into the issue. Some questions that could help here include:
- Where did the attack originate? Was this an insider attack or were outsiders to blame?
- Were any user accounts or passwords compromised?
- Was regulated data affected in any way?
- What else can you tell from the logs? A strong SIEM solution is essential for helping the team deal with log data.
Once your team knows more, they can start recommending steps for fixing the issue. It’s crucial that any information from this step gets documented. You may need to provide an audit trail after the fact, particularly under regulations like the
General Data Protection Regulation (GDPR).
Step Five: Remediate
Next, have your team fix the issue based on what they learned during in-depth analysis. The cyberincident remediation may require you to reset user account privileges, restore a computer that was affected by malware, ransomware, or some other malicious code, or it may require you to apply a good old-fashioned patch to a system to prevent further compromise. Regardless of the fix, make sure every step gets documented. Showing due diligence will be important for
security auditing purposes—and frankly, it’s just good practice.
Before you move on, make sure to verify that the issue has been removed. Don’t rush to bring everything back online—you don’t want to re-infect any systems or leave a foothold for attackers.
Step Six: Restore
Once you get the all-clear, start restoring systems. This step is pretty self-explanatory. However, don’t neglect to double check that all systems run properly and are secure. Patch them. Lock down permissions so only users that need to access the systems can. Monitor for continued threats that look and behave similarly to what you just encountered. It’s important here to be careful and thorough. The last thing you want is to leave your organization open to another attack.
Once everything’s good to go, communicate out to the wider organization that everything’s fixed.
Step Seven: Review
As mentioned above, every good incident response plan is a continuously evolving process. After major cybersecurity incidents, you’ll want to review not only what happened, but how your team responded. Avoid calling this a post-mortem—you don’t want anyone getting defensive. It’s a retrospective. You want to learn what went well and what didn’t. How did the team respond? This isn’t intended to place blame, but rather to improve so the team executes better over time. Keep the discussion friendly and open. Review what happened and what actions your team took, then try to discover what could be improved next time. Any process or policy improvements should come out of this meeting. And as always, document!
Final Thoughts
Security isn’t all about preventive measures. Mistakes happen and attacks do land. Having a strong incident response process helps your team deal with threats as they arise—and do so with minimal pain to the business.
