Create a Cyber Incident Plan from scratch

You have been told you need to create a cyber incident response plan and I don’t know where to start.

Many companies do not currently have a cyber incident response plan (link to survey), so it is likely that there are quite a few out there that are trying to get to grips with writing their first one.

This can seem a little scary at first but rest assured that the best people to write the plan are the people who know the company best. How it works, the culture, senior management visibility and involvement. These are all things a consultant will ask of you, so that they can then charge you to write them down (Yes, I do consult).

What you do need from someone who knows how to write incident plans, is a structure to work to, and some logical reasoning on what things tend to work, and what things don’t. In this post, I’m going to try to explain what makes a good plan, how do you create it, and then how do you make sure it is fit for purpose by testing it.

Controlled Document

The Cyber Incident Plan will be important through its lifetime. Make sure it is a controlled document. ISO27001 uses the term “controlled document“ to mean documents that are fundamental to the control of your Information Security Management System (ISMS). What this means is you should ensure it is in a template that allows the recording of change. It should have a version control section and It should say when it should be reviewed. It should link with your security policies.

Your Security Policy should say that you should have a Cyber Incident Plan, and the Cyber Incident Plan should link back to say that this document covers the requirement defined in the security policy. In this way, you create a set of security policy documents that clearly align and link up, showing a logical and consistent approach to managing security controls.

Client Friendly

Consider if this document is for release to clients, or if you wish to create a redacted or summary version for external consumption. A lot of organisations will be asking their third parties to prove that they know what they are doing with regard to security. This used to be as simple as asking whether a third party had a security policy. The simple answer “Yes” used to be sufficient. Not anymore. We are in a situation where organisations will request lots of evidence of security behaviours and controls, and it is likely that the security questionnaire you will get from your client will say something like “Do you have a current Cyber Incident Plan? Please provide a copy for review.”

You don’t want to release something that has confidential or private information in it. For example, if you have embedded the call tree for the incident team and escalation contacts in the main body of the document, then that cannot be released.

The structure of your document is important. All confidential and private information should be confined to appendices, so that you can choose which bits you want to release, and which bits stay within the company. In this way, you can provide the document to a client, minus the confidential/private appendices and you will get no pushback.

Document Structure

Structure is very important. As above, make sure you consider the confidentiality and privacy aspects of the data in the document, and split it up accordingly. It is a good time to re-enforce the purpose of the incident plan. A Cyber Incident Plan is a guide to the incident team to ensure that all of the different incident areas are covered off correctly. It covers the instigation of the incident team, how the meetings will be conducted, how the Incident Team will communicate (mode and frequency), roles and responsibilities and escalation triggers. You can think of it as the core activities that would be associated with ALL Cyber Incidents. No scenarios. The scenarios are in the Incident Playbook. The Incident Plan needs to function like a checklist. Have we done all the things required at this stage, before we move on to the next stage?

Incident Plan Invocation

How is the Incident Plan invoked?

You need to clearly set out how an event can trigger an Incident Response. There may be many different ways you could be notified of a cyber incident. Here are a few:

• User raises event through IT helpdesk (this could be malware as an example)
• IT Operations raise an IT ticket due to server running slowly
• A third party notifies the company.

This one is really important as you need to ensure that anyone who does not know your company, can raise and incident and talk to the right people rather than being passed around black holes by the company switchboard. If the third party already has a relationship with your company, they invariably will reach out to someone they know in the company, like a relationship manager. That contact has to result in the correct event being recorded and an evaluation of whether an incident response is required.

Is the Event big enough to invoke the Cyber Incident Plan?

The first key piece of logical assessment is, “Does this event require us to invoke the Cyber Incident Plan or can we just cover it off in Operations (BAU)?”.

This is actually harder than it sounds. Sometimes metrics get in the way of making sensible decisions, which is why the logic needs to be clearly laid down in the plan and agreed before any incidents arise. If achieving your personal end of year bonus depends on you having fewer that 2 Cyber Incidents per year, then every time a decision like this has to be made, the decision will be skewed to minimise the number of events that are being recorded as incidents.

The logic in the plan should have clear triggers and thresholds that when reached will trigger the invocation of the Cyber Incident Plan.

Try to keep this simple and objective.

Take for example a potential trigger such as:

“Is there media interest in this event? Has it already been reported publicly or is it highly likely to be reported publicly?”

The first part of this trigger is clear. It’s a simple yes or no. The second part of this trigger is subjective. It has the words “highly likely” in it, which can lead to some disagreement on whether the trigger point has been reached.

The more you stick to clear trigger points, the easier it will be for everyone.

Invoking your Cyber Incident Plan, having your first incident response meeting and then agreeing to stand everyone down, is a good result. It is far better than the reverse, which would be to bury it in an IT Helpdesk ticket and hope nobody notices.

Make sure everyone is involved from the start

Make sure all the right people are involved at the beginning and allow people to drop away when it is clear that their area of expertise is not required. A lot of companies try to minimise the upfront impact of getting senior decision makers involved at the start, preferring to see if they can fix it without bothering the seniors. This is the wrong approach.

All the right people need to be there at the start, so they can make the decision on whether they are needed or not. The instigation of the Cyber Incident Plan should reflect this, with the first meeting being the key one where all the roles decide if this is likely to need them, whether they can delegate, what the required constitution of the Incident team will be going forward for this incident, etc.

Record everything

The Cyber Incident Plan needs to dictate what gets recorded and why. It is highly recommended that legal council are involved from the start. A Cyber Incident requires legal support to ensure you are not breaking any laws or contracts when you make a decision. Without legal council in the Incident Team, you are likely to make a mistake that could be very serious. The side effect of having legal advice in the Incident Response Meetings, is that your incident minutes and records will be subject to legal privilege, IF (and only if) legal advice is being provided to the Incident Team on how to respond. If legal sit there in the meeting and don’t say anything relevant, then those minutes are still subject to legal discovery if it all goes pear-shaped. Clearly mark your minutes and action logs accordingly.

Communications during an Incident

The communications plan is a key part of incident plan. Legal discovery is something you have to pay close attention to, as allowing everyone to communicate without due restraint will result in a lot of emails, SMS’s, IM messages being open to legal discovery should another party decide to take legal action against you.

You need to be crystal clear on which decisions you take will require legal council support and review and which ones do not. This needs to be clearly laid out in the Incident Plan and legal council need to review this to make sure it is correct.

Step 1: Contain the Incident

The first priority for the incident team is to understand and contain the incident. Assuming no-one is in physical harm, the containment of the incident is the key.

The Incident Plan should guide the Incident Team in how to contain the incident, and the playbook should have a further level of detail, specific to the type of scenario that is relevant for this type of Incident.

The reason to emphasis this point is that it is very easy to start chasing multiple threads without focus. There are very defined stages that we are trying to step through and complete.

I need to make a distinction between Containment and Neutralisation, as most other resources on the Internet do not make this distinction.

Let’s use an analogy:

Event notification:  Loud scream from bedroom. Parent goes upstairs to conduct preliminary investigation.  Event identified as wasp in bedroom.

We have a containment strategy in the wasp invasion playbook. It’s called a glass jar and a piece of paper. Parent applies containment strategy.

This event is neutralised when the wasp is released external of the building.

We can then identify the likely cause of ingress as the open bedroom window, which we may consider closing to prevent re-occurrence, even though it is hot, and we want some air circulation.

In this analogy, the event is not getting worse once the wasp is contained in the glass jar. However, the event is not neutralised until the wasp is outside of the house again.

Step 2: Neutralise the Incident

We have stopped the cyber-incident getting bigger, we now want to stop any residual bad stuff. This part is very specific to the type of cyber incident you are dealing with, and relies on a cyber incident playbook to describe the actions required in different scenarios. A lot of this part is technical and requires the IT team or a group of specialist external resources to do their thing.

Step 3: Identify/Investigate

You are now at the point where you can take your first deep breath for a while, take a short step backwards and evaluate where you are and what needs to be done next. Before you start the clean-up operation, you need to try to preserve as much useful data as possible so that any investigation into the incident has as much information available to it as possible to be a success.

This means preserving logs. This means consolidating log events and looking for the needle in a haystack type clues to find out who did this, what did they take, are there other suspicious things still happening on the network? Your incident plan will describe how this is to be done with the systems you have available to you, and what assistance you will need from specialists in this field.

Step 4: Remediate

The war is over. But you have casualties. You need to provide first aid, assess them and get them the long-term treatment they need. The remediation step is about that first aid and assessment of what needs to happen in order to get back to BAU. It is an intermediary step where you are functional again but not necessarily fully functional.

Step 5: Recovery

This part overlaps with the business continuity plan when the Cyber Incident is significant in scale. Recovery of systems, networks, any dual running that may have been compromised, etc.

The Incident Team should not be stood down until it is clear who is delivering the recovery process. Regardless, there will be a handover to the recovery team before the incident team is stood down.

Just because the Incident Team are no longer meeting, does not mean that all of the actions are closed. The is a significant lessons learnt activity that needs to take place in order to handle the incident better in the future, and to update and of the plans/scenarios/playbooks as a result of new knowledge.