Actionable information to deal with computer security Incidents. Repeatable and effective steps. Steps that are unanimous among security practitioners.
It’s a good way to describe the SANS methodology for incident handling, compelled by Stephen Northcutt and others. With its origins on the Computer Incident Response Guidebook (pub. #: 5239-19) from US Navy Staff Office back in 1996. It is a 6 steps methodology. It will help you quickly and efficiently recover from a security incident.
The purpose of these 6 steps is to respond systematically to incidents. It includes the ability to minimize loss or theft of information or disruption of services when an incident occurs.
Types of incidents might include malicious code attacks, denial of service, espionage, sabotage, hoaxes, unauthorized access, insider threats, policy violations and many others.The six steps are preparation, identifications, containment, eradication, recovery and lessons learned.
A very similar process has also been brought to life by NIST on the Computer Security Incident Handling Guide (pub. #: 800-61) published in 2004. This special publication is very consistent with SANS methodology. In fact it is also a 6 step methodology with the difference that step two is named detection instead of identification.
Below a short and high level introduction of the 6 Computer Security Incident Handling steps:
Preparation : It’s at this stage that you develop the formal incident response capability. It’s at this stage where you create an incident response process defining the organizational structure with roles and responsibilities. It’s on this stage that you create your procedures with detailed guidance in order to respond to an incident. Its where you select the right people with the appropriate skill set. Its where you define the criteria do declare an incident. Its where you define the right tools to handle an incident. It’s where you define what you are going to report. To whom are you going to communicate.
This step is crucial to ensure response actions are known and coordinated. Good preparations will help you limits the potential damage by ensuring quick and effective response actions.
Identification: This is the step where you determine if an incident has occurred. Based on events observation, indicators, you look for deviations from normal operations. You look for malicious acts or attempts to do harm. The security mechanism in place will help you doing the identification. Your incident handler team will use their experience to look at the signs and indicators. The observation could occur at network level, host level or system level. It’s where you leverage the alerts and logs from your routers, firewalls, IDS, SIEM, AV gateways, operating system, network flows, etc. After identifying an incident you need to assess the impact. Notify the appropriate individuals or external parties. If there are reasons to believe that you will engage law enforcement it’s where you ensure chain of custody. It’s also at this stage that you define next steps such as containment.
Containment: The third stage of responding to incidents. It consists of limiting the damage. Stop the bleeding. Stop the attacker. It’s where you make decision on which strategy you will use to contain the incident bases on your processes and procedures. It’s where you engage the business owners and decide to shut down the system or disconnect the network or continue operations and monitor the activity. All depends on the scope, magnitude and impact of the incident.
Eradication: After successfully contained the incident. The next step entails removing the cause of the incident. In the case of a virus incident it may simply require removing the virus. On other complex incident cases you might need to identify and mitigate exploited vulnerabilities. It’s on this step that you should determine how it was initially executed and apply the necessary measures to ensure don’t happen again.
Recovery: It means back in production. Eventually, restoring a backup or re-image a system. It’s where you return to normal operational status. After successfully restoration is important to monitor it for a certain time period. Why? Because you want to potentially identify signs that evaded detection.
Lessons Learned: Follow up activity is crucial. It’s where you can reflect and document what happen. Where you can learn what failed and what worked. It’s where you identify improvements for your incident handling processes and procedures. It’s where you write your final report.
References and further reading:
Computer Incident Response Guidebook (pub. #: 5239-19), 1996, US Navy Staff Office
Computer Security Incident Handling Guide (pub. #: 800-61), 2004, US NIST
Incident Handling Step by Step ver. 2.2, 2001, SANS Institute
RFC 2350: Expectations for Computer Incident Response, 1998, IETF
Handbook for Computer Security Incident Response Teams (CSIRTs), 2003, CERT / Carnegie Mellon Software Engineering Institute
Essential Incident Response Activities during the First 24 Hours, 2006, Gartner, Inc.
Good Practice Guide for Incident Management,2o1o, ENISA
Count Upon Security 