The Cynet 360 platform is the world’s fastest IR tool and includes automated attack detection and remediationLearn More
An incident response process enables teams to effectively detect, prevent, and mitigate cyber security events. Typically, an incident response process workflow cycles through a number of phases. Each team can create a different incident response cycle, but many use the six phases outlined by SANS—preparation, identification, eradication, recovery, and lessons learned.
This article explains how to use the six SANS phases to build a successful incident response process, including pro tips for a successful implementation.
In this article, you will learn:
The incident response process is a set of steps performed by incident response teams to prevent, detect, and mitigate security incidents. It is a cyclical process that is improved with each cycle by feedback and a review of any actions taken. Depending on the specific process you’re using there may be a differing number of steps but all processes manage the same tasks and responsibilities.
There are two main guidelines that organizations tend to follow when developing their incident response process—NIST and SANS. NIST incident response guidelines were developed by the National Institute of Standards and Technology, an agency operated by the US Department of Commerce. These guidelines outline four phases, considering the steps taken to contain, eradicate, and recover from an incident inseparable.
SANS is an independent security training company. Their guidelines outline six phases that are covered below.
The six phases of the SANS guidelines are preparation, identification, containment, eradication, recovery, and lessons learned. During the incident response cycle, teams flow through these steps in order, but may return to previous phases as needed.
If this is your first preparation phase, you need to start with creating your team. This team is responsible for assessing current systems, policies, and security measures. These assessments include creating an inventory of your assets, performing a risk assessment, and prioritizing possible incidents or responses. At the completion of this phase you should have:
Once all of your various policies and procedures are in place you need to train your team and any support employees. This typically includes running through created procedures in incident drills. Drills ensure that procedures work as planned and no information is missing. It may also include developing skills found to be missing or lacking during the assessment steps.
During the identification phase, you monitor your systems, investigate events, and work to determine if an incident has occurred. This requires continuous visibility of your systems as a whole and the ability to detect when system events deviate from normal patterns.
When a suspicious event occurs, teams are responsible for investigating that event to determine the cause and whether it represents a threat. If it does, you then need to identify:
Any time an event is investigated during this phase, you need to begin documenting your actions taken and what is discovered. This documentation enables you to track what steps have been taken and is used later in the review process. Clear, complete documentation is also necessary if you want to take legal action against attackers.
In the containment phase, you are working to isolate the incident and prevent further damage. This typically takes the form of first short and then long term containment. Short term containment generally involves isolating any affected assets or network components. For example, taking a server offline or sandboxing files.
Long term containment serves as a temporary fix while clean versions of assets are prepared for recovery. For example, recreating passwords for affected users or blocking IP addresses used in the attack.
During the eradication phase, you are working to remove any tooling or changes that may have been used in the incident. For example disabling and eliminating malware or disabling ports that were opened.
This phase also involves strengthening any clean copies of your assets that you plan to use in recovery to replace affected components. For example, applying patches or replacing security measures like authentication with more appropriate ones. If you are not fully replacing assets, then you need to apply these fixes to your existing components.
Before moving on to the next phase, it is critical that you verify that all threats have been effectively removed. If any trace of an attack remains in your system, replacing or repairing your assets just creates a clean slate for attackers to start again.
In the recovery phase, you bring your production systems fully back online. This requires making important decisions as to which versions of a system you should recover to if you have not or cannot create updated versions of assets. It also involves thoroughly testing your restored system to ensure that vulnerabilities have been eliminated and that the system is functioning as expected.
6. Lessons learned
This is one of the most important phases and should be performed no more than two weeks after an incident has been resolved. During this phase your team reviews the how incident response went from start to finish. This includes identifying things that went smoothly and providing recommendations for how to improve processes that could have gone better.
If any documentation needs to be completed, now is the time to do it. Additionally, teams should take the time to more fully investigate any evidence collected to draw additional insight from it if possible. This insight can then be applied to improving preventative measures or detection processes in future cycles.
When following your incident response process, three components should be present throughout. These components ensure that your team can work effectively and can help ensure that responses are quick and successful.
Visibility is key throughout the response process. To achieve and maintain it you need to centralize your monitoring and logging as much as possible. This means choosing solutions that can integrate a wide variety of data sources smoothly. It may also mean creating custom integrations to ensure that all tools can forward alerts, logs, and analyses effectively.
As much as possible you should try to automate your incident response workflow. Automation can significantly speed response time and helps ensure that responses are standardized. This eliminates the chance that mistakes are made or incident response steps are skipped due to oversight or responder stress. Generally, this is accomplished through the use of runbooks, scripted processes that a responder or tool can initiate as needed.
Collaboration and information-sharing
To effectively respond to incidents your team needs to collaborate and communicate. During response processes, you have many team members working on a wide variety of tasks. Many of these tasks rely on the information and efforts of others.
If you do not have coordination between team members you cannot know which tasks have already been completed or which to do next. In contrast, having clear communication channels ensures that all members understand what is happening throughout the response process, what the results of others’ efforts are, and what still needs to happen.
In Cynet, we implement a holistic and proactive incident response process. We provide high-end incident response automation and expert-lead incident response services.
Our platform, Cynet360, offers incident response automation capabilities that support the entire incident response cycle. Our incident response team, CyOps, is on call 24/7/365, helping enterprises of all sizes to get access to enterprises-scale incident response services.
Here’s what you can expect from the CyOps incident response team:
Learn how the Cynet Autonomous Breach Protection platform and the CyOps 24/7 incident response team can help you.