I can call this standard as «CISO Time!» As far as computer security incidents are corncerned enough companies act in a reactive way. We have an incident, let's do something to reduce damage. Sometimes they thought how to patch vulnerabilities, which leads to some kind of remediation. And then wait for another incident.
Also there is another way to deal with incidents — proactive way. In this standard you can find some useful steps how to implement incident response activities in company's every day life. Almost all recommendations are obvious, but they are placed together. If you are going to write incident response plan, you can follow instructions in this standard and you'll get sufficient plan.
Standard consists of 3 parts. First part is devoted to organizing a Computer Incident Response (CIR) Capability. In this chapter you can find useful information about policy and plan elements, also with obvious advantages of developing CIR plan. Some pages describe how to effectively communicate within organization and what departments should participate in incident response activities.
Second chapter was about how to handle an Incident. This activity consists of 4 steps: Preparation → Detection and Analysis → Containment, Eradiction, Recovery → Post-Incident Activity.
As far as preparation step is is concerned I can't but mention 3 main activities:
- get all necessary contacts from people with whom you are going to work while CIR;
- all incident analysis hardware and software should be up to date and easy to use;
- incident analysis resources are also important, because using them you have all information about infrastructure in one place.
Detection and analysis is one of the most important part of the plan. First of all, you should determine attack vectors, indicators and profile activity in your infrastructure. When you understand normal behaviour and create correlation and log retention policies you will be able to prioritize incidents. It is better to make such decision with colleagues and top-manager, such as CISO. Generally, you can try to divide incidents by functional or informational impact and recoverability, but every company can find their own criteria about how to prioritize incidents.
Containment and eradication also as a recovery can be much different because of your organization internal policies. Containment depends on many factors as impact on SLA, potential damage and so on. Eradiction should be carefully done, because of possible information lost. Effectiveness on this step is fully depends on how good detection analysis was performed. Almost all recovery procedures are held by IT staff. It is their part.
Post-Incident Activities include lesson learned meetings after incident. On this meetings your CIR team should update CIR policies and procedures, create chronology and monetary estimate of the amount of damage. Based on this lessons you can justify fundings, help your IA department to find incident trends and systemic security weaknesses. Also measures of success can be renewed. It is always important to understand when incident is localized and eliminated.
In this chapter you can find CIR handling checklist. It is very brief, but also helpful to start from. The last part is devoted to coordination and information sharing. It is also a good start to from your list whom to call and what to say. Special attention in this standard is paid to granular information sharing because of business impact. It is better to speak with law and PR departments before presenting information to some unauthorized people.
In conclusion, I would like to say that this standard is not a full guide about CIR. It is only a brief review. Almost every topic should be expanded with different technical and administrative measures. But if you don't know where to start or even you know — it is a good review to check your key positions. Great job, NIST!