A Rapid and Robust Incident Response Plan is Vital 

A lot of things can go wrong when you respond to a cyber incident, so it is vital that you have a plan of action in order to mitigate and deal with any damage. As Tim Stiller outlines in his online webinar, How Robust (and Rapid) is Your Incident Response Plan (available to view here) incident response can be a challenge, but to be successful teams need to take an organized and coordinated approach with 6 core steps.

The specific elements of an incident response plan will differ depending on the company and the incident, but all plans must be built on the foundation that your response teams can develop the muscle memory to deal with a threat, no matter its size and scope, in an efficient and timely manner, ensuring that dwell time is kept to a minimum and proactiveness is encouraged.

RECOMMENDED: Threat Intel Tools Take Enterprises Away From ‘Reactive’ Posture

During the investigation response phase, your company doesn’t have the time to formulate a plan – your teams should already know who to engage, what technology to use and what steps to take. Without having a playbook or plan in place, your investigation response procedures will fall short and you will miss critical pieces of data that will help you prepare for the next attack.

Shutterstock

Here is a rundown of the core pillars of an incident response plan:

Preparation

The first step is preparation and this stage is centered on people, process and technology – and knowing what you have in place already, including contacts lists for internal and external stakeholders.

You should have a list that accounts for systems, software and processes involved in the following key areas of preparation:

Endpoint – This can include any antivirus or HIPS systems you have in place and generally any software solutions.

Network – Network preparation includes email security and perimeter documentation.

Log management – In addition to log retention, this area also pertains to log review and how this interacts with your alerts platform to enable an investigation.

Policy – The policy area includes data collection and preservation.

The core takeaway from the preparation stage is to document what you have in order to become familiar with your capabilities and the value of each individual component.

Not only is this a core element of incident response, but it will also give you’re the opportunity to improve processes over time if they’re not working, and it will give you more data adequately map maturity, identify gaps and pain points.

Incident response teams must develop the muscle memory to deal with a threat, no matter its size and scope

In addition, it is imperative to define what the critical business assets are in order to discern a better grasp on the estimated impact of a breach. For example, if you have helpdesk you need to have its uses defined in a holistic document that details the sum of each part of an incident response.

SEE ALSO: Cryptocurrency ‘Fueling’ Ransomware Incidents

Last of all; find a framework that fits your organization. It is essential that your incident response teams are not surprised by the situation no matter how severe. A response team cannot correctly mitigate an incident without predetermined guidelines that are relatively bespoke to your company to ensure your breach readiness is as good as it can possibly be.

Identification

The next step is identification. When an incident does occur, you need to find out everything you can about it to ensure the appropriate measures are taken. First and foremost, your incident response plan should clearly distinguish between a security event and a security incident.

This will help to make a good case to leadership, for example, if an attack occurs at night and out of office hours. Understanding the incident and the priority – the difference between the amounts of affected computers and what systems are compromised, will be pivotal for presenting a case to leadership.

RELATED: Know Your Systems: Cyber Security Tips For Board-Level Execs

Security event - Any observable occurrence in a system or network. For example, users connecting to a remote file share or receiving spam email.

Security incident - Violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. For example, Web shell identified on a public facing server.

With good identification processes in place, you should have an easier time trying to answer the following questions:

• What is the scope of the incident?
• How was it discovered?
• What areas have been impacted?
• Does it affect operations?
• Why did the incident occur?

Containment

The next step is containment which should be enacted as soon as the scale of the breach is determined. At this stage, the most important course of action is to stop the breach in its tracks, ensuring that it doesn’t spread and further damage other areas of your business. The containment process is a short-term solution.

Short-term – The key goal is to limit the scope of the incident and reduce damage. From an endpoint perspective, this will mean isolation. From a network perspective, some steps you can take include blocking domains and IP addresses, VM snapshots and leveraging forensic VLAN.

Eradication

Now we move on to the mid and long-term solution. The goal at this stage is to remove all the identified remnants of the incident. This will entail removing malicious code and irresponsible personnel. In conjunction, a full forensic analysis should be completed with logs kept throughout the process.

Long term - Long term solutions include account deletion, malware removal, reimaging systems, disabling unused services, ensuring systems are patched and updated, and the initial restoring systems to know good baselines.

Recovery

The recovery process isn’t just about restoring and bringing your systems online, it’s about ensuring that breaches are patched. At this point, it is imperative to ensure that all company policies and procedures are effectively being implemented.  

SEE ALSO: Incident Response Plans Heighten All Facets Of Cyber Defense

As a result of the correct implementation of the strategy, you increase the chance the threat has been completely eradicated and isn’t lingering in your network. Think proactive cyber defense procedures. 

The recovery process can include:

• Deploying IOCs from the incident and reviewing alerts.
• Tracking blocked IP’s and domains to ensure that the blocks are effective.
• Pushing out updated DAT files to AV engines.

Lessons learned

Now, your company should take everything it learned from the experience and update your incidence response processes. The core elements are understanding gaps, trends and prioritizing long and short terms plans. Incident response teams often skip this step as the heavy lifting has already been done, but by skipping this step you only set yourself up to make the same mistakes during the next cyber attack.

The after-action stage should give you enough data to determine if you need the following:

• Tool optimization, including automation.
• Gaining more visibility.
• Identifying tasks which can be optimized through automation.
• Threat intelligence extraction.
• Fixing or abandoning broken and outdated processes.

[inlinead-1]

What does your playbook look like?

Ideally, your incident response playbook should have 5-10 scenarios that impact your organization and can be used by the teams affected by an incident response. Some common playbook scenarios include defense procedures for phishing, malware infection, privilege escalation, lateral movement and data theft.

Shutterstock

As part of designing your playbook, you should determine team roles and responsibilities, and a mapped guideline of your incident response lifecycle.  Every team member should have a clear understanding of what steps are taken during each phase of the investigation, with regards to tracking and tasking.

Your incident response playbook should have 5-10 scenarios that are likely to impact your organization

During the investigation response, it is also critical that your teams know how to build status reports and incident updates – ensuring that your customers receive the most pertinent information and not the same multi-page report over and over again.

RELATED: Go Phish Yourself: Non-Profit Tests Employees, Improves Security

The same goes for escalations across your organization. Ask yourself if internal teams are involving members higher up the chain at the right time. Last of all, the extent of third party involvement should be well defined. The key here is to review their capabilities. 

Testing your playbook

A playbook that hasn’t been tested is not a worthwhile playbook.

Live simulation and observation are critical for identifying gaps and ensuring the plan is functional. It is also the only way to engage the team with the plan so they can be prepared to deal with a live cyber attack. You can also incorporate non-incident response into the test, as they may have key roles to play that they’re not aware of.  Again, frequent testing to ensure the plan is up to date and becomes muscle memory is pivotal.

Testing Methods

Discussion – Discussion with various involved teams.

Tabletop – This entails step by step instructions with examples and tends to involve stakeholders around a table running through a security event scenario.

Live simulation – This is the most effective way of pressure testing a plan. A live simulation is similar to the tabletop method, but with it focuses on the use of security tools to give your team the ability to simulate attacks and run your playbooks. A live observation test to ensure the plan is functional and that every team understands their role.

Want More? Check out this report
 Beyond The Firewall: Breaking Down Layered Security