Incident Response Plan

Think of this as a fire drill

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.

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.

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.

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 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.

Join the CSO newsletter!

Error: Please check your email address.

Tags cybersecuritydirectors for CSO AustraliaShellshocksocService Level Agreements (SLAs)Doris Daycyber attackdisclosureSystem RestorationManaged Security Services Provider (MSSP)Enex TestLabHitchcock movieemailsvpnHeartbleedSecurity operations centre (SOC)CSO Australia

More about AISAAkamai TechnologiesCSOEnex TestLabISACA

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Dr Claudia Johnson

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts