An incident response plan ensures that in the event of a security breach, the right personnel and procedures are in place to effectively deal with a threat. Having an incident response plan in place ensures that a structured investigation can take place to provide a targeted response to contain and remediate the threat.
It’s Friday afternoon and after a steady week working for your company’s IT helpdesk your thoughts are on that cold bottle of wine you have chilling in the fridge, the perfect accompaniment to a quiet night in watching Netflix. The thought is interrupted as your desk phone rings, probably another employee requesting a password reset.
Get the Free Pentesting Active
Directory Environments e-book
However, the panic in the caller’s voice quickly becomes evident, they can’t open any of their files and are asking if you know what a bitcoin payment is? Probably not a big deal, malware on a single laptop is not the end of the world. However, you turn around to the sight of multiple phones ringing around the office, the situation now seems a little more serious than a single laptop infected with malware. To make matters worse a colleague leans over to tell you a server containing customer data has also been infected with ransomware.
This scenario has played out many times around the world, how effectively you respond to this situation depends on the answer to one question, “Do you have an incident response plan?”
Why You Need an Incident Response Plan
It is crucial a business has an incident response plan so that under the pressure of an incident the correct decisions can be made to bring the situation back under control. A cybersecurity incident can be a very daunting situation, if the response is not conducted in an orchestrated manner then the potential outcome could result in severe damage to a brand’s reputation.
To effectively deal with a cybersecurity incident, your company will need a team that specializes in incident response. Some organizations call this team the Computer Security Incident Response Team (CSIRT) – there are other permutations of that acronym out there like Security Incident Response Team (SIRT) or Computer Incident Response Team (CIRT). The mission of this team is the same no matter what you call it – to enact the company’s established incident response plan when the bat-signal goes up.
If you work in data security, you deal with security incidents on a day-to-day basis. Occasionally, a minor security issue turns out to be a real live panic situation. When the bat-signal does light up will everyone know what to do? Will every CSIRT member know their role and responsibilities and follow the approved plan?
When the stakes get high and the pressure intensifies, the CSIRT will perform as they have practiced. If there is no plan in place, there is no guarantee they will be able to properly respond to a cybersecurity incident.
However, simply having an IR plan is not enough: the CSIRT team must have the skills and experience to deal with a potentially high-stress situation like this. Digital Forensics experts, Malware Analysts, Incident Managers, and SOC Analysts will all be heavily involved and will be the boots on the ground dealing with the situation This will involve making key decisions, conducting an in-depth investigation, providing feedback to key stakeholders, and ultimately giving assurances to senior management that the situation is under control.
On top of all that, there is often a time crunch. Data breach notification laws are becoming more common: the GDPR, for instance, requires that companies report data security incidents within 72 hours of discovery.
My experience of working on cybersecurity incidents has shown me the value of having an incident response plan. I have been called out in the early hours of the morning to an incident to find that a cybersecurity breach has occurred, the CEO is looking to the CSIRT for answers and guidance on how disaster can be averted. The incident response plan means the right people, with the right skill sets and experience will be on that call, they each know what is expected of them and what procedures need to be followed to successfully contain and remediate the threat. Having that structure in place has always proved invaluable.
Considerations for Incident Response Planning
The incident response plan will be made up of key criteria that can be developed as a company’s security posture matures. There are several considerations to be made when building an incident response plan.
Backing from senior management is paramount. Building an incident response plan should not be a box-ticking exercise. If not backed by senior management then it will be at risk of becoming filed away until needed. Senior leadership should be outlining what is required from a process and people point of view and ensuring that any required support is provided.
Define the key stakeholders. Contact details for key individuals and teams inside and outside of business working hours need to be documented.
Communicate clearly. Ownership of sending out communications, assigning tasks, and appropriate actions should be established. Also, consider who needs to be included in any incident comms and how much detail is required depending on the audience. Tasks assigned to security teams need to be precise and technical whereas updates to the board will need to be clear and free of any technical jargon.
Define what constitutes an incident. Specify which events can be dealt with as business as usual or when it is all hands-on deck and an incident call needs to be stood up.
- KEY TIP: A triage matrix will provide an understanding of the severity of an incident so that it can be prioritized quickly and correctly.
Plans and procedures are important. However, it is the CSIRT who will be executing the incident response plan and performing the incident recovery. The right people and skill sets need to be in place for the IRP to be successfully executed.
The CSIRT will be made up of various teams and each role is key to turning an incident from a potential disaster into a success story. The CSIRT is a mix of experienced, technical, and non-technical personnel who work together to understand the scope of the incident, how it can be mitigated, and ultimately remediated. The right people need to be hired and put in place.
Automation is also key to incident response planning, understanding what security tools are in place along with their capability and coverage means a certain level of automation will be possible. Finely tuned security controls ensure that your first line of defense, the Security Operations Center (SOC), is responding to alerts that are meaningful and legitimate. Having reliable and finely tuned alerts means that some areas of the incident response process can be initiated automatically and that it may be possible for the initial triage and gathering of evidence for an incident to be automatically generated. If your automation is generating a large number of false positives, not only will this cause fatigue in a key area of your IRP but you are also more likely to miss a key alert if it is lost amongst the noise of false positives.
Alongside an incident response plan, a company must also consider having a disaster recovery plan in place. While an IRP is designed to remediate the threat of an incident, a DRP is designed to restore the functionality of a business and bring it back online following a major natural or human-induced disaster. If the business cannot function, then the DRP will outline the steps required to bring the company back online.
A company may also need to consider if they are impacted by the Payment Card Industry Data Security Standard (PCI DSS). This is applicable if a business processes, stores or transmits records of customer credit card details.
Who is Responsible Within an Incident Response Plan
The CSIRT is made up of specialized teams who each have an important role to play when dealing with an incident.
The Security Operations Centers (SOC) are the first line of defense. They are the soldiers on the ground who operate 24 hours a day, 7 days a week. It is their role to triage every security alert, gather the evidence, and determine the appropriate action. Working in shifts, the SOC Analysts must have a broad understanding of cyber security threats, they will have access to various security platforms and tools such as the SIEM (Security Incident Event Manager) and EDR (Endpoint Detection & Response) solutions. These tools can generate a wide range of alerts that can vary from DDoS attacks to malicious commands being run on a device, the SOC analysts need to be able to understand and interpret this data. If an incident is deemed high priority or falls outside of the SOC’s skill set then their escalation point is the Incident Management team.
The role of an Incident Manager was described to me by a colleague as “The Art of Herding Cats.” It is their job to put their arms around an incident, pull the key stakeholders together and drive the discussion to determine the best plan of action. The Incident Management team are the Generals, they are provided with evidence, advice, and opinions and set the pace of an incident. They identify what tasks need to be completed, who needs to complete them, and when they should be completed by. Any incident calls and communications that need to be scheduled are completed by Incident Management.
The CIRT team is the Special Ops soldiers, they are only involved in high profile and high priority incidents and when they are not involved in incidents they are refining and developing their skills. Whereas the SOC analysts will have a broad skill set, the CIRT team will be made up of individuals with specialized skills and interests such as malware analysts and digital forensics experts. This team provides expert technical advice and analysis and is assigned tasks by Incident Management which cannot be conducted by the SOC.
The Threat Intelligence team are the scouts who assess and understand the cyber threat landscape. If the incident relates to a compromised server containing sensitive data, then they will be scouring the dark web looking for evidence of the data being up for sale. If the incident relates to a malware infection, the intel team will conduct OSINT (Opensource Intelligence) research on the malware family and advise on the likelihood of this being a targeted attack against your organization.
6 Steps to Create an Incident Response Plan
SANS published their Incident Handler’s Handbook a few years ago, and it remains the standard for IR plans. It’s a 6-step framework that you can use to build your specific company plan around.
1. Preparation
Preparation for any potential security incident is key to a successful response. I highly recommend developing some playbooks that provide guidance to the SOC when triaging an incident, these will give clear instructions on how to prioritize an incident and when they should be escalated. These should be high level and focused on specific areas such as DDoS, Malware, Insider Threat, Unauthorized access, and Phishing. The playbooks and procedures should be tested on the people and teams who will be using them. Tabletop exercises are an excellent way to solidify the knowledge and see if any improvements can be made.
2. Identification
You can only successfully remove a security threat once you know the size and scope of an incident. Begin with ‘patient zero’, the initial compromised device. The goal is to understand the root cause of the compromise, however do not just focus on the one device, could the threat have spread and moved laterally?
True identification of an incident comes from gathering useful indicators of compromise (IOC’s). Rather than just rebuild the original infected device, look to identify any unique IOC’s that can be used to search across your estate for further evidence of compromise. If the incident relates to a malware infection then ask the following questions, what network connections does the malware generate? Does the malware connect to any domains? What files are created on disk? What running processes are created? Are there any unique registry keys that have been created? This data can then be used to search for further evidence of compromise and identify any other infected machines in your estate.
3. Containment
Once the scope of an incident has been successfully identified the containment process can then begin. This is where the compromised devices within the estate are isolated from the rest of the network to stop the spread of an attack.
Short term containment may be used to isolate a device which is being targeted by attack traffic. Long-term containment may be necessary when a deep-dive analysis is required which can be time-consuming. This may involve taking an image of the device and conducting hard disk forensics. This may generate further IOC’s and the identification phase may need to be revisited.
4. Eradication
Once the incident is successfully contained then the eradication of the threat can begin. This will vary depending on what caused a device to be compromised. Patching devices, disarming malware, disabling compromised accounts are all examples of what may be required in the eradication phase of an incident.
5. Recovery
The goal of the recovery phase of an incident is to restore normal service to the business. If clean backups are available, then these can be used to restore service. Alternatively, any compromised device will need rebuilding to ensure a clean recovery. Additional monitoring of affected devices may need to be implemented.
6. Lessons Learned
Once the threat has been fully remediated the next step will involve answering the question ‘how do we stop this from happening again?’. A meeting known as a Post Incident Review (PIR) should take place and involve representatives from all teams involved in the incident. This is the platform to discuss what went well during the incident and what can be improved. This is where the incident response plan is refined based on the outcome of the PIR, and procedures and playbooks are amended to reflect any agreed changes.
Incident Response Plan Best Practices
Create Playbooks. Creating playbooks will guide the SOC on how to triage various incidents and gather the relevant evidence. Focus on the main attack scenarios that companies face – Malware, DDoS, Unauthorized Access, Phishing, and Insider Threat. These documents should outline what triggers an escalation to the Incident Management team and advise on what evidence needs to be gathered. Keep them high level, they shouldn’t be too granular so that they become too complex.
Perform cyber threat exercises. Prepare for the real thing by wargaming some attack scenarios, this can even be as simple as arranging some tabletop exercises. Creating some attack scenarios that can be talked through by the relevant teams is a great way to test any playbooks that have been put in place, this will also help identify any gaps in an incident response plan and should be reviewed at least once a year.
Start threat hunting. Waiting for an alert to fire on a shiny new platform is one thing, proactively looking for suspicious activity is where incident response teams begin to mature. Not only is a potential compromise likely to be found earlier but the individuals who are performing these ad hoc investigations are developing their investigative mindset. These skills and this type of mindset is exactly what is required during the identification phase of an incident, querying network traffic, looking at uncommonly used ports and unusual processes to understand the size of an incident. If the SOC has a strong understanding of what ‘normal’ looks like it becomes a lot easier to spot malicious activity.
Incident Response Plan Templates
Creating an incident plan can seem quite daunting. However, using a template will provide structure and direction on how to develop a successful incident response plan.
NCSC Planning guide – The NCSC (National Cyber Security Centre) is a British government organization that provides cyber security support to critical UK organizations. As a major authority on cyber security, their recommendations will prove invaluable when planning an incident response plan.
Sysnet’s Incident Response Template – Outlines how to recognize a security incident, roles and responsibilities of key stakeholders, incident response plan steps, and what needs to be considered for various incident types.
Incidentresponse.com has provided several playbook templates that cover scenarios such as malware, phishing, unauthorized access, and are all mapped to the NIST incident response framework. These will be separate standalone documents but should be referenced in the incident response plan.
To help understand when an incident response plan would be used Varonis’s incident response webinar showcases a live attack simulation. During this simulation, our security analysts give a brief tour of Varonis for Office 365, execute the attack from intrusion to privilege escalation to exfiltration, then show you how to use DatAlert to detect and respond.
What to do After a Cyber Incident?
The dust settles, the bad guys are defeated, and the CSIRT team followed the IR plan to the letter. What next? Take stock and resupply for the next encounter.
Tighten up the IR plan or look to improve the monitoring that is already in place, are there any additional logs that were not available during an incident and need enabling? Is there a gap in skills within the security team? Does the company’s patching policy need reviewing? Constantly reviewing and refining the incident process ensures that not only will any response to an incident be improved but the attack surface is also being reduced. If additional controls and improvements are being made to a company’s security posture then this will ultimately result in fewer security incidents.
This article should arm you with the knowledge and resources to successfully develop and deploy an incident response plan. To ensure your data is protected, start a trial of the Varonis Data Security Platform to add best-in-class behavioral analysis of all your critical data stores and infrastructure.
Incident Response Plan FAQ
A quick look at the answers to common questions people have about incident response plans.
Q: What is an incident response?
A: Incident response refers to the actions taken in the event of a security breach.
Q: What is an incident response plan?
A: An incident response plan defines the procedures and personnel needed in place to effectively deal with a security breach.
Q: What are the six steps of incident response in order?
A: The six steps of incident response are:
- Prepare
- Identify
- Contain
- Eradicate
- Recover
- Learn
