This post provides an approach for designing your incident response capability. Use this as your starting point for developing and maturing your incident response capability.

Understand your incident response phases. The six proposed phases are:

1. Phase 1: Planning
2. Phase 2: Detection
3. Phase 3: Containment
4. Phase 4: Eradication
5. Phase 5: Recovery
6. Phase 6: After Action Review

For more about incident response preparedness read the National Institute of Standards Guide SP 800-61 Rev 2 published in August 2012.

The Workshop

Our recommended approach is to conduct a workshop to review each of the six phases. Let’s examine each phase in greater depth and highlight the items that you need to address in your own incident response planning.

1. Planning

Time spent on planning reduces risk and increases the effectiveness of your approach and work efforts. Do not under resource the planning phase! Preparing for incidents is the foundation for protecting your business and data. If you are in Aerospace and Defense, Construction, or other industry preparation will improve your incident response performance by lowering expended resources, improving activity effectiveness and coordination, and the quality of the work during times of crisis. This phase includes:

Policy Development – Your policy is your documented statement of you high-level objectives and requirements for how you will address any possible incidents. Your policy should define the purpose of having an incident response capability, explain event types and escalation classes, and define key activities and roles in responding to incidents.

Plan – Your plan is your detailed step by step handbook on how the incident response process works. The plan will detail how you will work in any given incident type and the escalation procedures you will apply. 

Team Formation – Selecting the right team and roles in advance can be the difference between muddling through the process or doing it effectively. As a minimum include the following:

Legal Counsel - used for incident response overall coordination. Crucial to protect privilege of the investigation and work products. All work should be coordinated with Legal Counsel.

Incident Response Manager – A person coordinating the technical effort

Security Analysts – Your security technical team to investigate the incident (internal and external)

In addition to your core team, you will have interaction with Management and Leadership (for resources and funding), Human Resources (if employees are involved), Strategic Communications (Public Relations), Internal Corporate Legal Counsel.

Activity and Work Flow – Defining activities, workflows, and assigning responsibility are crucial to developing, testing, and using your incident response capability. A visual, a graphic depiction of the workflow will show all of your response steps and how you will work through them. From the trigger (cause of the incident) through resolution, and ultimately closure.

Training and Testing – Train your staff and incident response teams regarding their roles and responsibilities in the event of data breach. Test your different incident response event types in advance through table top testing.

Sample questions to ask:

• Have your policies and plans been developed and approved by management?
• Have workflows been included in the planning documentation?
• Do you have an Incident team established and has the team been trained and participated in testing the plans?
• Has the incident response policy been communicated to staff and subcontractors?

2. Detection

Security Incidents come in all shapes and sizes. Being able to detect them and have an approach for dealing with them requires people and technology working side by side to determine if you have been breached. 

Speed is of essence, and incident response expectations have moved from fairly laissez-faire questions such as do you have an incident response capability, to do you have a documented capability, to can you respond in 30 days, to can you respond in 72 hours, to can you respond in 24 hours, 8 hours, or less.  That requires you having the capability to detect that something occurred, be made aware of it, and have the ability to take action in that time period. Leverage your understanding of your business by having up to date architecture, threat models, so that you can draw upon these resources.

Oh, have times changed.

Sample questions to ask:

• Did an event take place? What was it?
• Who discovered it?
• What was discovered?
• Where was it discovered?
• When did the event take place?
• Why did it take place?
• How is the business impacted?
• How pervasive is the breach/compromise?

3. Containment

We often run into cases where the information around an incident no longer exists as the organization moved quickly to delete it. However, containment is both a strategy and process step to limit the impact of an incident but also preserve enough information to prevent it from occurring again.

Different incidents will have different containment strategies. For example, if there is a breach on an endpoint you will disconnect the device and examine it offline. You can then examine what the issue is (i.e. like a ransomware attack) using forensic software. Then you can wipe and re-image the device.

However, there are attacks that may cause greater harm when a device (such as a host) is disconnected from a network. Those incidents need to be dealt with a different way.

What is critical is to consider the types of threats and containment options you have. It could also be based on where the attack takes place and what data it is putting at risk (short term and long term).

Sample questions to ask:

• What is the type of breach you have?
• What has been done (i.e. did some person or system take action that you need to know/understand)?
• What needs to be done to contain the breach now and moving forward in the longer term?
• Can you operate the business while you are mitigating the breach? Are disaster recovery/backup procedures in place?
• Can you safely separate the breached environment, contain it?
• What environment will you have to set up the containment environment?

4. Eradication

After putting a containment strategy in place, you will take steps to fully investigate and eliminate the cause of the data breach. You will collect information and conduct root cause analysis.

You will make decisions on what are sufficient steps or technical measures you will take to eliminate the causes of the attack. You are striving to eliminate it completely or to an acceptable level.

Sample questions to ask:

• How will you eradicate the vulnerability you are facing?
• What system changes (hardening, patching, other configuration activities) will need to be implemented?
• Are user accounts affected?
• What vulnerability scans/tools will use to validate the eradication process?
• Will you implement changes at once, will you have work around in the short term, will you require significant investment to implement new solutions?
• Will you need to wipe and re-image systems?

5. Recovery

Recovery is the process of restoring you affected systems back to “normal” operating status. The process starts when the eradication step is complete. You should take your time to do this right. The old adage, go slow to go fast, is the basic principle here. This requires prioritizing recovery activities and not trying to do too much at once and not meeting your recovery objectives.

Sample questions to ask:

• Have systems been patched and hardened (to a standard)?
• Can the system be restored from a trusted back-up?
• How will you know that systems are clean and fully operational?
• Have the systems been tested, has data been validated, and when can systems be returned to production?
• How long will you continue to monitor the systems for abnormal behaviors? 
• What abnormalities will you look for?

Do you have the right tools or procedures to make sure a similar attack will not take place? (Example Tools: Security Incident & Event Management (SIEM), end point protection, behavioral threat analytics, file integrity monitoring, security configuration monitoring, next generation data intrusion detection/protection, privileged access management)

6. After Action Review

Once the incident response team has completed the investigation, hold an after-action review with all the team members. The purpose of the review is to discuss what you have learned from investigating the data breach. We call this a “Hot Wash”.  

The hot wash will review the entire event and response from beginning to end. Examine what worked well and where the team and process ran into challenges. Document everything

All team members should be part of this hot wash. Each will bring a unique perspective. It is critical to take the individual perspectives and integrate them through discussion to reach a common understanding of what you learned from the investigation. Document everything and use this information for improving the next iteration of your Incident Response Plan.

Sample questions to ask:

• What changes need to be made to the security?
• What changes need to be made to the incident response process?
• How should employees be trained differently?
• What weakness did the breach exploit?
• Do you have an actionable plan to prevent this type of breach event from happening again?

After the Workshop

Begin documentation as you prepare and conduct the workshop. Following the workshop continue the documentation process. All of your documentation efforts form your inputs to the Planning and Preparation phase. 

The six-step process gets codified through an incident response policy and managed through an incident response plan. Be sure that you have both. 

In addition, you need to be sure you can follow your process. You do this by testing. Test the policy and the plan by conducting drills. They will not replace a real incident, but they will greatly improve your preparation.

Keep preparing. Keep testing. Keep learning. Keep improving.