Awareness is growing that organizations of all sizes lack cybersecurity incident response preparedness. Companies regardless of size are not exempt from cybersecurity threats. Being prepared with an established plan of action to immediately execute following a security incident is crucial to limit incident costs and damages to the organization’s technical infrastructure, operations, and reputation.
“The majority of companies — 77% of respondents — don’t have a cybersecurity incident response plan applied across the enterprise,” according to a 2019 study conducted by the Ponemon Institute.
According to this study one of the primary reasons for this is the well-documented security skills shortage. It is particularly severe in incident response because it is a newer discipline for many companies. Survey respondents said they lack the headcount to create, maintain and test their incident response plans. Only 30% of respondents reported staffing for security is sufficient to achieve a high level of cyber resilience.
INCIDENT RESPONSE (IR) FRAMEWORK VS PLAYBOOK
An incident response framework provides a structure to support incident response operations. A framework typically provides guidance on what needs to be done, but not on how it is done. A framework is flexible enough to allow elements to be added or removed as necessary to satisfy a particular organization’s needs.
An incident response plan has a goal delivering effective incident response through a detailed set of steps. An incident response plan details the processes needed to deal with cybersecurity incidents, calls out the resources required, and outlines the communication and escalation paths required for plan operation.
Together the framework suggests logical elements that should be included in a plan. A plan includes those elements as well as elements of mission, services, people, process, technology and facilities. With this in mind, it helps to understand two (2) industry incident response frameworks to determine the best approach for your organization.
The NIST Incident Response Framework
The National Institute of Standards and Technology (NIST) is responsible for developing information security standards and guidelines, including minimum standards for federal information systems. The NIST “Computer Security Incident Handling Guide” includes an incident response framework in the form of an incident response lifecycle.
The four stages of the NIST incident response lifecycle are preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Here’s a look at each one in some detail.
Phase 1: Preparation. The quality of incident response largely depends on incident response preparation. In this preparation phase of the lifecycle, all the components needed to respond effectively to a computer security incident are identified, created or acquired.
Phase 2: Detection and Analysis. While the capability to detect incidents is set up as part of the preparation phase, incident detection starts the incident response process. Incidents cannot be responded to until detection occurs.
Phase 3: Containment, Eradication and Recovery. Containment follows the detection and validation of a security incident. The goals of containment are simple – stop the problem from getting worse (i.e., limit the damage); and regain control of systems and network.
Phase 4: Post-incident activity. Post-incident activity centers on lessons learned to accomplish two things: Improve the incident response capability and prevent the incident from recurring.
The ISO Incident Response Framework
The International Organization for Standardization (ISO) is an independent non-governmental international standards organization. The ISO standard details how individuals should “detect, report and assess information security incidents; respond to information security incidents … report information security vulnerabilities … learn from information security incidents and vulnerabilities, institute preventive controls, and make improvements to the overall approach to information security incident management.”
ISO/IEC 27035-1:2016 outlines the principles underlying information security incident management, which is structured into five (5) parts:
PART 1. Planning and Preparation.
- Establish an information security incident management policy.
- Create an incident response team.
PART 2. Detection and Reporting.
- Set up the processes, procedures and technology required to detect and report the incident.
PART 3. Assessment and Decision.
- Set up processes and procedures.
- Establish incident descriptions and criteria.
PART 4. Response to Incidents.
- Establish controls to prevent, respond and recover from incidents.
PART 5. Lessons Learned.
- Learn from security incidents and improve overall computer security incident management.
NIST and ISO 27035-1 are similar in approach to each other. However, there is an important and subtle difference. The NIST “Computer Security Incident Handling Guide” focuses on incident handling which deals with the prevention, detection and responding to incidents. ISO 27035-1 focuses on incident management, which is integrated broadly into other business management and risk reduction functions outside of the incident response organization.
So which framework should you choose? Should you choose one framework in its entirety or should you choose part of one and combine it with parts of another framework in a kind of incident response a la carte? When considering whether to adopt a framework as is or build your own, these are some things to think about:
- Are your business operations business within the US borders or global?
- Are you publicly traded or privately held?
- What are the requirements of your regulatory and compliance landscape? Are you highly regulated?
- Do you have obligations under the Federal Information Systems Management Act (FISMA)?
- What are your contractual obligations with your business and trading partners?
There are certainly more questions to be assessed. Consider an appropriate framework that provides structure to guide the incident response plan. Building the incident response plan on the framework, not the framework itself, enables your organization to create the resilience needed to support your business.