Without being a pessimist, as I am at my core an optimist, it is not a matter of if you will be breached, but when. It is a reality that vendors face when they are deploying the latest security tool you have bought, and it is reality when they are providing POV (proof of value) of their tool as it sits in your environment for a month.
How your team and organisation choose to respond to these incidents is the difference between being on the front page of the newspaper and potentially facing millions in fines from the Australian privacy officer, and sending an email to your customer base letting them know there’s been an incident and as a precaution, their password has been reset. In this post, I’ll give you a primer on the role of incident response in cybersecurity, focusing on the key steps involved and the importance of preparation. (step 1 of the NIST Incident Response Lifecycle, and NIST Computer Incident Handling Guide (SP 800-61)
What is Incident Response?
Incident response refers to the systematic approach taken by an organisation to address and manage the aftermath of a security breach or cyberattack. The goal is to handle the situation in a way that limits damage and reduces recovery time and costs. Incident response involves a series of well-defined steps, often guided by frameworks like the NIST Incident Response Lifecycle (I’ll shorten this to NIRL to make it brief throughout this blog). While using the Incident Response lifecycle is a good start, it is still generic and does not address the unique ways your organisation operates. A hand-in-glove approach here would work by using the NIRL plus a bespoke Incident Response playbook. The playbook caters to the ways you respond to an incident, with somewhat high level details. One of the key components here is the call-tree. If you’re not used to responding to incidents there may not be an established flow of who to talk to and when an incident occurs.
Having everyone who would be affected during an incident read through and then participate in a briefing on how incidents will be run is one of the best forms of preparation (apart from having a forensic lab setup and appropriate logging in place of course) you can do.
The NIST Incident Response Lifecycle
The NIST Incident Response Lifecycle consists of four main phases:
Preparation: Developing and implementing an incident response plan, training staff, and ensuring the necessary tools and resources are available.
Detection and Analysis: Identifying and analysing potential security incidents to determine their scope and impact.
Containment, Eradication, and Recovery: Containing the incident to prevent further damage, eradicating the root cause, and recovering affected systems.
Post-Incident Activity: Reviewing the incident and the response to improve future incident handling processes.The Importance of Preparation
As I talk about in in the TLP podcast (https://www.buzzsprout.com/2361455/15085312-episode-2-nist-sp-800-61-computer-security-incident-handling-guide-preparation.mp3?download=true), preparation is the cornerstone of effective incident response. Having a well-thought-out incident response plan and trained personnel can significantly reduce the impact of a cyber incident. This involves regular training, testing, and updating of the incident response plan to ensure it remains effective.
Detection and Analysis: The Frontline of Defense
Detecting and analysing potential security incidents quickly gives you the upper hand to limit the impact and duration of a cyber incident. This involves using various tools and techniques to monitor networks, systems, and applications for signs of malicious activity. For example, Security Information and Event Management (SIEM) systems can aggregate and analyze log data from multiple sources to identify suspicious patterns.
Containment, Eradication, and Recovery
Once an incident is detected, the incident response team or your pre-defined IT staff drop what they’re doing as BAU and focus on containing the threat to limit impact and if you’re early enough in detecting the incident, preventing the attacker from achieving their goal (action on objectives). This might involve isolating or containing affected systems, blocking malicious IP addresses, deleting the phishing email from staff mailboxes, and in the case of ransomware, just shutting everything off immediately. After containment, the next step is eradicating the root cause of the incident, such as sweeping the entire environment for IOC’s, removing malware, patching vulnerabilities and following the list of recommendations identified as part of the incident debrief and lessons learned.. Finally, the recovery phase involves restoring systems and data to normal operations, ensuring that all traces of the incident have been removed.
Learning from Incidents: The Post-Incident Review
After an incident has been resolved, it’s essential to conduct a thorough review to identify what went well and what could be improved. This post-incident review helps organizations refine their incident response plans and better prepare for future incidents. It’s also an opportunity to update training and procedures based on lessons learned.
I’ve recorded a 4 part series specifically on NIST Computer Incident Handling which covers these steps in a lot more detail. Listen on Spotify: https://open.spotify.com/show/4E7GQAtCVMbTvqhwLFM68L?si=cf3aa036dbab45a8. Episodes 2-5 have everything you need to get started.