Incident Response

Roles and Responsibility: For example, who can lead the incident response team? Who can procure goods and services? Who will liaise with HR when there’s an insider threat or an internal breach of policy? Who has the expertise to explain how laws, regulations and contractual agreements are affected? Again, who has the skill and diplomacy to communicate across the organisation and to external entities in a manner that will not adversely affect the reputation or operational efficiency of the organisation?

You don't need someone in the organisation to fill all these roles - you can just as easily hire out specialists, for example. However, knowing in advance, who can solve which problems is extremely useful.

SECTION 2: RESPONSE AND DECLARATION

Criteria to Classify The Incident: It is so much easier to say, 'we've seen some account misuse', or 'we're experiencing a distributed denial of service attack' and for everyone to understand what this means and what they should be doing about it.

Criteria To Rate The Incident: Your CSIRP needs to clearly state how the gravity of the incident will be measured in order to elicit the appropriate response across the organisation. For example, you might use something like this:

Declaration Procedure: Based on your initial assessment of the incident, you must then explain, how an emergency will be declared and communicated to the appropriate teams. Additionally, you want to be able to say what you are expecting to happen next and which strategies should be implemented.

Contact Details: Get all your critical contacts and jot them down here. You need, full name, job role and 2 phone numbers as a minimum. This is not just a list of the organisation's employees either. It might include your suppliers, solicitors, police cyber response teams, utilities, or PR specialist. Many organisations also develop a cascade tree to facilitate quicker communication across the enterprise.

Facilities & Technology: Your plan should designate a 'war room'. This is a preassigned location containing everything the team will need to handle the incident - from stationary, to USB thumb drives that can capture forensically sound images. A war room usually includes a redundant line of communication (in case yours are compromised) and a separate internet connection too. It is probably the most effective way of gathering key personnel, to facilitate quicker decisions whilst ensuring unity of effort.

Related Documentation: Think of all the documents you may want at your finger tips and state their location (bearing in mind that your IT might be down). Strategic Team Leaders will need a business impact assessment, a continuity and disaster recovery plan, as well as organisation charts. Technical teams will want network architecture diagrams, asset lists, change management documentation, network baselines to detect anomalous activity and 'incident playbooks'. Your Comms will have draft communication material with content placeholders; internal memos or Q&A documents to address questions from customers, investors and the media.

Deviations: For example, when dealing with an insider threat, the handling and reporting procedures may differ slightly. There may also be restrictions on the amount of detail captured within a tracking system, depending upon the data exposed. Document these exceptions here.

SECTION 3: INVESTIGATION, CONTAINMENT AND MITIGATION

Intelligence Recording: Your CSIRP should spell out how information about the incident will be recorded. This will be the who, what, when, where, how and why. Some organisations will use formal methods to document this - such as the 'Diamond Model' which we have an article on here. Others, will just generate a series of templates with instructions on who should receive a copy and what distribution methods should be used. Be mindful, that this is sensitive information and consider that usual channels of dissemination could be compromised. Some organisations will even invest in software to track investigations; store artefacts, accept tickets and facilitate information sharing. RTIR, FIR and TheHive are excellent open source tools.

Whatever option you go with, never underestimate the value of documenting events and actions. You may need this for legal purposes, post mortem analysis - or just to organise your thought processes and plan the next logical steps to take.

Evidence Collection: Your CSIRP will spell out your requirements for evidence collection. This may be especially important; in the event of a data breach, when dealing with insurance companies or root cause analysis. Be mindful that some evidence perishes quickly (the order of volatility) and must be captured and preserved in a forensically sound manner to have any credibility in a court of law. It is also worth stressing, that this is high value data so you will need to explain how it will be secured and shared.

Containment & Mitigation: Some organisations take this opportunity to outline initial containment strategies for a variety of different incidents. For example, if there is some form of email infection, then you might decide to take the mail server offline. Again, if a rogue account is discovered, it might be disabled. Mitigation strategies are also defined by some organisations. This may include removing a virus, revoking certificates, or firing up a backup server.

The Play Book: This will outline multiple incidents and the workflows necessary to resolve them. A playbook can be developed through table top exercising. In other words, key personnel sit around a table and discuss different types of incidents and what actions should be taken. The more scenarios that can be thought of, the better.

For each type of incident, a good play book might spell out : tell tale symptoms; containment, mitigation, eradication and recovery strategies - often broken down into step-by- step checklists. Trust me, every checklist is worth its weight in gold when an organisation is in trouble.

It is tempting to leave the development of this playbook and the table top exercising to IT teams, however, that would be a huge mistake. For example:

Only members of the senior leadership teams (SLT) have a line of escalation and a platform to update and communicate to senior board members.
Only SLT can determine how much money and time can be invested into fixing a problem
Only SLT can determine the level of acceptable risk to mission critical goals and - for example - determine whether a system can be shut down
Again, only public relations can craft consumer-facing materials to protect the reputation of the organisation.
Only public relations can identify the best notification and crisis management tactics for each type of scenario.

And, finally, only legal can determine whether the organisation should notify affected individuals, regulatory bodies and other relevant third parties. They will also be able to advise on what evidence must be kept to demonstrate due care and diligence.

SECTION 4: RECOVERY AND NOTIFICATION

Business Continuity: The CSIRP will emphasise the importance of the Business Continuity Plan (BCP) at this point. Remember, the BCP describes how the different departments will keep the show on the road despite the loss of services or facilities (see here for more).

Recovery: As before, our Incident Playbook will outline the strategies and workflows to enable the recovery of services as dictated by their criticality (yet another reason for SLT involvement). Recovery usually involves system hardening, such as the removal of redundant services, default accounts or installing patches. Recovery can also include the deployment of additional security controls (such as two factor authentication, firewalls or intrusion detection systems etc.) and the installation of a clean backup.

Certification: Getting your IT systems up and running is all well and good, but you need some level of assurance that they are no longer prone to attack. Use this space to outline how your response teams will test, validate, and certify systems. It is quite tempting to skip this part of your plan, but rolling back prematurely can often precipitate a second disaster. Finally, you should also state how the incident will be officially declared over. This is known as your recovery declaration.

SECTION 5: POST INCIDENT REPORT

This section of the plan will probably include a template to help document the entire incident from start to finish. Typical sections include:
- Incident Identification Information.
  - Date & time of discovery and notification
  - Incident duration
  - Author and contact details
- Executive Summary
  - A high-level overview of events, decisions taken, implications and consequences for the organisation
- Incident Root Cause.
  - illustrates the who, what, when, where, why and impact
- Incident Timeline
  - Of events, including key discoveries and communications
- Recovery Actions
  - Summary of the actions taken to contain, mitigate, remediate and recover
- Evidence Relied Upon
  - Sources of information used to draw conclusions & opinions e.g. depositions, transcripts, digital evidence.
- Acquisitions Made
  - Processes used to acquire admissible evidence - such as tools, techniques and validation procedures so another examiner is able to confirm or dispute the findings.
- Evaluation
  - Covers lessons learned from the incident

Report Distribution: Not everyone will need to see the report in full. The Board of Directors, for example, will only want an executive summary as will 3rd party partners. You can use this space, therefore, to identify different audiences and their information requirements.

After Action and Post Mortem: following an incident, you must draw together key players to evaluate any processes followed and tools used. What went well, what might have gone better? This is your blueprint for dealing with future incidents and is probably one of the most important steps to take and document.

FINAL THOUGHTS

Your CSIRP is not something that should be carefully placed in a glass cabinet with instructions to 'break glass in case of an emergency'. It needs to be embedded into the workforce so that everyone understands their role and responsibilities as well as how they can support the efforts of the incident response team.

In particular, the playbook is essential to recovery. As such, it must be the product of careful consideration by multiple team players. Table top exercising, detailing different types of threats are critical. To read more about how to organise such sessions, check out our exercising resource here.

No matter how robust we think our security posture is, it will never be perfect. At some point, a threat will come along and exploit one of our weaknesses, causing complete pandemonium. Since incidents can and will happen, it's important to be prepared. To paraphrase Benjamin Franklin, 'by failing to prepare, you are preparing to fail'.

BEFORE WE BEGIN

You have to know your reason raison d'être or - quite literally - your reason for being. What does your organisation do that is critical to its survival? Is it all about supplying goods or services or is it about the safety and wellbeing of your employees? Once you understand your 'mission critical functions' (MCF), you can start to get to grips with what IT systems and what data enables you to implement them. At this point, you can:

Quantify how bad the incident is, based on its impact to MCF and the likelihood of the event occurring.
Develop plans beforehand to keep these functions going without IT (aka Business Continuity Planning).
Develop plans to recover critical systems as quickly as possible when they do go down (aka Disaster Recovery Planning).

To learn more about this, see our article on Business Continuity here.

STAGE ONE:

Ok, so first the bad news - you need to write a 'Cyber Security Incident Response Plan' (CSIRP).

The good news is, that once it's written, you've won half the battle right there.

A Cyber Security Incident Response Plan will include:

SECTION 1: INTRODUCTION, OVERVIEW AND THE TEAM

Plan Objectives: For example, 'this document will help the organisation identify; analyse, contain, eradicate and recover from security incidents. As such, it will define who will do what, when and how, so that the operational, financial, and reputational impact of a security related issue is mitigated and manageable'.

Plan Ownership: For example, the plan should identify an appropriate person within the organisation who will make sure that its provisions are communicated, understood and enforceable. This person usually has the support of the Senior Leadership Team and the Board of Directors.

Scope Of The Plan: The plan should identify which information systems, institutional data and networks should fall under its remit. This normally includes any person, device or partner system that accesses your data.

Definitions: What - exactly - is an 'incident' and how is it different to a 'security event' or a 'data breach'? What is a 'threat actor' or a 'vulnerability'? What do we mean by 'personally identifiable information' (PII), DDoS, Ransomware or a 'Whaling Attack'? If terms are defined carefully, everyone sings from the same hymn sheet and effective dialogue can take place.