Incident Response Plan

Do you take a fatalistic approach to cyber attack?  ‘Whatever will be, will be’ is an attitude in life (and movies) that is well suited to events that evoke a spontaneous response—like who will you marry?  These are the questions posed in Doris Day’s song from the Hitchcock movie ‘The Man Who Knew Too Much’.  They’re not appropriate for incidents which inspire fear, which Doris learns when her son is kidnapped.

A fatalistic approach is very definitely not the right one to adopt towards a cybersecurity event.  You should make something out of your fear, not only in terms of prevention, but in terms of preparing for ‘what if?’.

First, take a closer look at your business and consider what you are most afraid of (in terms of an exploit).  Be honest with yourself.  Is it going offline simply because of lost revenues, or is it defacement of your site which could ruin your organisation?  What if your entire data centre went offline, including email and VPN?  Consider which scenarios could have the most impact.  Why—because you can plan for them.  Conquer your fear.

The rest is straightforward, albeit hard work.

Detecting an attack or event
When critical attack types are identified, your next step is to make sure a clear process is defined for detecting such an event. This may be, for example, outsourced to a Managed Security Services Provider (MSSP). A good MSSP will be able to guide you through the remaining steps. If all security is done internally via your own Security Operations Centre (SOC), the rest of these steps apply.

Non-conform methods of detection should be included as well, for example (worst case) reading about the event in the press, or simply manual intervention.

Consider detecting the severity of a situation. This may feed into potential responses depending on how serious the incident is perceived.

Evidence
Make sure logs and other evidence are meticulously maintained in case there is a follow up investigation seeking the cause—potentially criminal.

The Who, What, and Where
This is the meat of any Incident Response Plan.  Once a security event has been detected, it must be clear who is to contact who, via which method.  Which actions need to be taken in which order, and by whom?  If email is non-functional, do we have a telephone number to use?  What if the relevant party has left the organisation?   Taking all this into account will ease the fear and help drive a rational reaction.

The Devil is in the Details
Service Level Agreements (SLAs) are a must-have.  Make sure you get SLAs for your Incident Response Plan.  What good is it if your MSSP detects an incident but needs 24 hours to respond?  Do not rely entirely on an automated system (such as Security Incident and Event Management (SIEM)) for zero-day vulnerabilities which are becoming more prevalent (think Heartbleed and Shellshock). A well-trained  SOC is necessary.  Any well positioned MSSP will have a SOC in addition to a SIEM. 

Ask details about the procedures and people working there.  Are they accustomed to reacting to unknown attacks?  What do they have in place to support them? What about the people and processes in your organisation?  Is it clear who is responsible for a potentially necessary personal communication with your MSSP?

Diagnostics and Mitigation
Mitigating an ongoing attack  is much more likely to be successful if the diagnosis of the exploit is accurate.  Here the MSSP or your internal SOC are critical. 

Once the mitigation strategy is decided upon between the SOC and the business, there must be a feedback loop to determine whether the mitigation is taking hold.  This must be done early and at regular intervals.  Also, the possibility that an attacker changes his attack vector during mitigation must also be taken into account.

Resolution
It must be agreed which circumstances conclude resolution of the event.  This should be part of the plan.  Once resolution is agreed upon between MSSP or internal SOC and business, documentation of the attack, its cause and its mitigation is crucial to ensure the next attack of this kind is mitigated earlier or even prevented altogether.

System Restoration
There must be a backup version of the system and relevant data to fall back to. This may be done in parallel with mitigation or resolution. A complete back up plan is necessary, including the requirement of maximum allowable restoration time.

Ongoing Improvement
There are key features to avoid approaching events with ‘que sera sera’ as your attitude:

1. Practice.  Think of this as a fire drill. If no one knows what is to be done if, even the best conceived plan will not succeed.
2. Review the plan at regular intervals.  Are email addresses and telephone numbers up to date?  Has the company’s data centre been moved or is there a new one?  Be sure to include some kind of change management procedures.  If major changes are required due to a new organisation or infrastructure, a clearly documented change process is necessary. 
3. Document and preach.  Make sure all of the details of the above (your ‘Security Incident Response Plan’) are documented and that all relevant staff have access.  Conduct regular interviews or checks to make sure staff know the document and have an understanding of its contents.
4. Review each major incident afterwards.  Detailed information like root cause, delayed response, unclear sets of responsibilities must be identified, and remedial actions should included in an updated version of the Incident Response Plan.
5. Any internal, MSSP or SOC needs a reliable ticketing system.  Assuming that users follow process by lodging a ticket as the first step, this will provide valuable data to track diagnosis and mitigation effectiveness, and can be leveraged to force improvement measures.

Disclosure: 
It may be necessary to disclose a breach publicly, depending on the details.  If the incident is already in the press, a reaction is necessary.  Who will contact the press?  Who decides which details are to be disclosed?   If there is a vendor involved, then the vendor must also be notified. See http://www.cso.com.au/blog/cso-bloggers/2013/02/15/what-responsible-disclosure/. Maybe the breach only needs to be disclosed internally. If so which stakeholders must be informed? In which order?  Mistakes made around disclosure, both internal and external, may have far worse consequences than the incident itself. 

Still afraid?  You shouldn’t be. You have a plan.

Claudia Johnson is a Senior Solutions Engineer at Akamai Technologies. Claudia is an active member of AISA, ISACA and holds a CISSP. 

This article is brought to you by Enex TestLab, content directors for CSO Australia.