Incident response roles, resources, and problem statements
One can notice that efficient incident response is a role-based process. A role is a virtual entity that has defined power, responsibilities, and capabilities. One professional can take on multiple roles or several professionals can take one role for scaling purposes and to achieve robustness, redundancy, and quality assurance. Moreover, they can be delegated to a third-party vendor with a skilled Digital Forensics and Incident Response (DFIR) team.
There are some best practices for how a role model should look, and we will define the most important technical roles in the next section. Management role setup is a topic worth discussing in another book as it varies based on the business size and operations.
The main coordinator role during the incident response process is called the incident manager. Usually, it is a Chief Information Security Officer (CISO), or the Chief Technology Officer (CTO) or Chief Information Officer (CIO) if the cybersecurity division hasn’t been formed yet. In general, the incident manager gathers findings from the incident response team and plans and approves incident analysis and remediation actions with the board, management, and key stakeholders using preserved communication channels.
There are many real-life examples when, after 48 hours of sleepless work during incident response, the incident manager is knocked out for 12 hours. Usually, these situations happen because of a lack of resources. People need to have some rest after dealing with lots of stress. Incident response is never a controlled and well-planned activity; there is always a high probability of unforeseen situations. Consider this during the planning, making sure at least some part of your team is resting and will be ready to provide support on the next duty shifts. At this point, we are ready to raise a question: what is the best recipe to create a silver bullet that will solve all problems with one shot?
The best way is to use a combination of an incident handling framework, the current cyber threat landscape, an understanding of the targeted attack’s lifecycle, and the existing resources to fight against cybercrime. The most widespread framework is provided by National Institute of Standards and Technology (NIST), introduced in the special publication 800-61 Computer Security Incident Handling Guide. It introduces the four major phases of the incident response life cycle:
- Preparation
- Detection and analysis
- Containment, eradication, and recovery
- Post-incident activity
Another popular framework was introduced by SANS, called PICERL (https://www.giac.org/paper/gcih/1902/incident-handling-process-small-medium-businesses/111641). It breaks down the incident response process into six phases: preparation, identification, containment, eradication, recovery, and lessons learned.
Organizations may develop their own frameworks using their unique expertise. We will explain some of them in this chapter. The goal of the author is not to confuse, but to encourage you to be open-minded and able to choose the most appropriate framework based on your organization’s specific needs.
We will deep dive into this model throughout this chapter by advising the most efficient techniques that can be implemented by organizations to enhance their preparedness, resilience, and incident response capabilities.
