Let's start by understanding what an incident response plan actually is?
An incident response plan is a set of instructions designed to help IT staff identify, respond to, and recover from a security incident. The IR plan refers to the scope of measures to be taken during an incident, not to the details of the incident itself. Furthermore, the IR plan for an incident is the instruction that the response team follows when an event occurs.
So what is the purpose of an IR Plan?
The purpose of an IR plan is to protect sensitive data from a security breach, just as contingency plans are used to ensure the continuity of business processes and services during a malfunction.
Some businesses have a dedicated incident response team, while others have employees on standby who form an ad-hoc incident response unit when the need arises. Other businesses outsource incident response to security vendors—for example, SentinelOne and Comodo Security provide a managed incident response service as an additional service that will definitely give you peace of mind.
A successful incident response plan aims to identify attacks and deal with them as effectively and as early as possible. The objective of an incident response plan is to bring the following to a minimum:
- The number of systems and users affected by a breach
- The dwell time of attackers in the corporate network
- The damage inflicted to the organization
- The time required to restore normal operations
- The cost of mitigation and clean-up efforts
- Liability and damage caused to third parties such as customers
Incident Response Plan Frameworks
There are two primary frameworks you can use to plan and execute an incident response process, created by NIST, a US government standards body, and SANS, a non-profit security research organization. They are summarized below:
The Incident Response Process: NIST vs. SANS
When creating your incident response plan, it is useful to follow existing incident response frameworks from leading research institutions. There are two commonly used frameworks:
NIST Incident Response Framework – the National Institute of Standards and Technology is an agency operated by the USA Department of Commerce that provides standards and recommendations for multiple industries. NIST provides a four-step incident response process that emphasizes that incident response should be cyclical, with continuous learning and improvement to enhance defences over time.
SANS Incident Response Framework – SANS is the world’s largest provider of security training and certification and operates an early warning system for global cyber threats. SANS released an incident response handbook, which provides a structured six-step process for incident response, from preparation before an incident to lessons learned from an incident.
Lets breakdown the frameworks to give brief insights into each aspect:
NIST Incident Response Steps:
1. Preparation
Compile a list of IT assets, identifying critical assets, set up monitoring, define types of security events, and create incident response steps for each type.
2. Detection and Analysis
Collect data from IT systems, security tools, and external sources, identify precursors (signs of impending incidents) and indicators (signs of an actual attack), and analyze them to identify incidents.
3. Containment, Eradication, and Recovery
The containment strategy depends on the level of damage, the need for continuous access to affected systems, and the time needed to implement a solution.
After the incident is contained, remove all threat elements from the environment, restore systems and recover normal operations, while ensuring the same assets are not attacked again.
4. Post-Incident Activity
Learn from previous incidents to improve the incident response process. Use your findings to adjust incident response policies, plans, and procedures, and feed the preparation stage for future incidents.
SANS Incident Response Steps:
1. Preparation
Create a security policy, perform a risk assessment, identify sensitive assets, and build the incident response team.
2. Identification
Monitor IT systems, detect anomalies, identify actual security incidents and investigate them to establish type and severity.
3. Containment
Perform short-term containment to prevent the threat from spreading, then perform long-term containment, including temporary fixes and rebuilding clean systems.
4. Eradication
Clean malware, identify the root cause of the attack and take action to prevent similar attacks in the future.
5. Recovery
Bring production systems back online, taking measures to prevent additional attacks. Test, verify and monitor systems as they recover.
6. Lessons learned
No later than two weeks from the end of the incident, perform a retrospective, prepare complete documentation, evaluate containment efforts and see if anything in the process should be improved.
Best Practices for Building an Incident Response Plan
Create a simple, well-defined process
An incident response plan, even if it is very well thought out, must be simple and crystal clear to be effective. Keep details, procedures and explanations to a minimum, to ensure that staff can very easily follow the plan in the urgency and confusion of a real security incident.
Create a communication strategy
Clarify who needs to be informed of a security breach, which communication channels should be used and what level of detail should be provided. There should be clear guidelines on how to inform operations, senior management, affected parties inside and outside the organization, law enforcement, and the press. This is a commonly overlooked part of the incident response process.
Use an incident response plan template
Don’t reinvent the wheel. Always start your incident response plan from a template created by others in the industry, and adapt it to your specific needs. For example, you can start from this template provided by TechTarget which includes incident scope, planning scenarios, logical sequence of events for incident response, team roles, notification and escalation procedures.
Put your incident response plan to the test
Conduct realistic drills and exercises to see how the incident response plan is carried out in practice, and be ready to adapt the plan according to lessons learned. Test your tools to ensure they are able to detect an attack as early as possible in the kill chain and ensure the team can identify a threat and contain it before sensitive data leaves your network.
Use a centralized approach
Organizations should not be logging into multiple tools and correlating information between them during the urgency of an attack. Processes and tooling should support a centralized incident response process where an analyst can view all the information about an incident in one place.
Put incident response technology in place
Incident response tools\technology provides you with the means to eradicate discovered malicious presence and activity from your environment as well as optimize response workflows by automating repetitive tasks. They can:
Provide a complete picture of an attack operation, correlating data from endpoints, user behaviour and network communications
Enable remote manual response by security analysts, such as blocking users, killing processes, restarting hosts, deleting files or changing passwords.
Enable automated response, for example, automated quarantine of an endpoint when malware is discovered, or automatically stopping a malicious process that encrypts or deletes large numbers of files.
At Effectualness we are resellers of cyber solutions and do not directly provide incident response services your IT staff can receive product training on the products you acquire from us or alternatively you can add on managed detection and response services that is available from SentinelOne and Comodo respectively.