Incident Response Planning
Some time in the past, it seems that my work has shifted mostly from doing (what I consider) actual work to talking and writing about actual work.
Although I spend much of my time writing or reviewing documents and sitting in meetings, every now and then a call comes in that usually starts with something along the lines of "Something interesting happened and I think you may be interested in it". That phrase will send me right over to my incident response documentation toolkit and I start taking notes. Being responsible for incident response management gives me that one escape that everyone should have.
Most incidents can be dealt with as a matter of routine and can typically be addressed by help desk and system administrators. Such calls usually result in a quick resolution and happy customers. In my role (CISO-like) I care mostly about proper execution of previously defined security procedures and about getting some good reporting out of this process. That reporting will then be used to drive process improvements.
Not all calls can be resolved by relying on procedures that are documented in detail. Sometimes you can tell that it will be a good one, just based on the caller ID of the person who reports the event to you. Other times, you'll know in the first minute of the conversation that something interesting is going on. In those cases, having a documented incident response plan will be invaluable.
Your incident response plan may not give very detailed instructions for such odd cases, and that is fine. In such cases, your plans should give you the guidance to determine what to do and know that your actions have been previously discussed with key executives and that they have their support.
If your computer security incident response team (CSIRT) is activated, you want to things right the first time. For incident types where it is impossible, impractical or just too expensive to developed detailed incident response procedures, I have found it very useful to document some incident types, such as "Unauthorized information disclosure", and provide a basic strategy, roles and responsibilities, and reporting forms for these incidents. Rather than focusing on the cause of the incident, my planning revolves around the outcome. This approach is sometimes referred to as an all-hazards approach. An analogy is that in your response planning, you don't really care what started the fire, but you do care about how to fight it.
Incidents like this are meant to be addressed by the CSIRT and for a successful tactical and operational execution they rely heavily on the expertise and training of the incident handlers. I typically use the following boiler template when developing general response templates for CSIRT incidents:
1. One or two pages on general response strategy, including explicit assignment of some basic responsibilities. For example, one of the first steps in the identification and notification phase will be "CISO will send heads-up notice to CIO after initial report has been received".
2. A master checklist containing one or two pages of actionable items that cover the entire response process. Action items can be: a) Determine law-enformcement involvement. b) Assess and document scope of breach. c) Close case. Checklist must have enough space to check off the items, add comments, and record dates/times. Completed checklists will be used as input to writing up the post-incident report.
3. Some basic reporting forms. I tend to conclude my identification phase with a written report that outlines initial findings in a convenient one-page format that I can use to update key stakeholders. The initial incident report will be used as input to writing up the post-incident report.
4. Timeline forms that can capture date/time and actors of all actions that take place affecting the response. All actors are required to maintain their own timeline forms and they are also used as inputs for the post-incident report.
Approaching an incident response in this way, where a basic strategy is known ahead of time and "maintaining excellent notes" is embedded in the response is a key for successful reporting and process improvements.
Although I spend much of my time writing or reviewing documents and sitting in meetings, every now and then a call comes in that usually starts with something along the lines of "Something interesting happened and I think you may be interested in it". That phrase will send me right over to my incident response documentation toolkit and I start taking notes. Being responsible for incident response management gives me that one escape that everyone should have.
Most incidents can be dealt with as a matter of routine and can typically be addressed by help desk and system administrators. Such calls usually result in a quick resolution and happy customers. In my role (CISO-like) I care mostly about proper execution of previously defined security procedures and about getting some good reporting out of this process. That reporting will then be used to drive process improvements.
Not all calls can be resolved by relying on procedures that are documented in detail. Sometimes you can tell that it will be a good one, just based on the caller ID of the person who reports the event to you. Other times, you'll know in the first minute of the conversation that something interesting is going on. In those cases, having a documented incident response plan will be invaluable.
Your incident response plan may not give very detailed instructions for such odd cases, and that is fine. In such cases, your plans should give you the guidance to determine what to do and know that your actions have been previously discussed with key executives and that they have their support.
If your computer security incident response team (CSIRT) is activated, you want to things right the first time. For incident types where it is impossible, impractical or just too expensive to developed detailed incident response procedures, I have found it very useful to document some incident types, such as "Unauthorized information disclosure", and provide a basic strategy, roles and responsibilities, and reporting forms for these incidents. Rather than focusing on the cause of the incident, my planning revolves around the outcome. This approach is sometimes referred to as an all-hazards approach. An analogy is that in your response planning, you don't really care what started the fire, but you do care about how to fight it.
Incidents like this are meant to be addressed by the CSIRT and for a successful tactical and operational execution they rely heavily on the expertise and training of the incident handlers. I typically use the following boiler template when developing general response templates for CSIRT incidents:
1. One or two pages on general response strategy, including explicit assignment of some basic responsibilities. For example, one of the first steps in the identification and notification phase will be "CISO will send heads-up notice to CIO after initial report has been received".
2. A master checklist containing one or two pages of actionable items that cover the entire response process. Action items can be: a) Determine law-enformcement involvement. b) Assess and document scope of breach. c) Close case. Checklist must have enough space to check off the items, add comments, and record dates/times. Completed checklists will be used as input to writing up the post-incident report.
3. Some basic reporting forms. I tend to conclude my identification phase with a written report that outlines initial findings in a convenient one-page format that I can use to update key stakeholders. The initial incident report will be used as input to writing up the post-incident report.
4. Timeline forms that can capture date/time and actors of all actions that take place affecting the response. All actors are required to maintain their own timeline forms and they are also used as inputs for the post-incident report.
Approaching an incident response in this way, where a basic strategy is known ahead of time and "maintaining excellent notes" is embedded in the response is a key for successful reporting and process improvements.