Incident management – so much more than managing incidents
Incident management is mentioned extensively in Cyber Security certifications and (should you wish to go for it) ISO 27001. Though this doesn’t meant you should only prepare for an incident if you are going for a certification. Incident Management can be so much more than just managing incidents – it can be used to help you understand how well your controls are working and can also help you buy precious time in the event of something as bad as a ransomware attack.
Incidents have a lifecycle
In IT things have lifecycles, documents, developments and also incidents. A lifecycle is a stage an incident is at – allowing you to follow a particular set of stages to manage it. These stages fall into 4 phases:
| Phase | Title / Description |
| Phase 1 | Preparation. This is about preparing for the incident. Having the resources in place, making sure that the people involved in the incident are trained. This is also about trying to make sure that the incidents dont happen in the first place. NIST uses ‘Identify and Protect‘ at this stage. |
| Phase 2 | Detection and Analysis. Detecting an incident could be a number of sources – perhaps from a phone call saying ‘Ive just had a weird email off you’ or your SOC team contacting you to say that their displays are lighting up around a particular device.
When detecting an incident – you see what’s happening and also what severity you think the incident is. At this point, you need to take a moment to get things right. Too soon, and you have a ‘Cry Wolf’ scenario and too late, and you have lost precious time. NIST uses ‘Detect’ at this stage Sometimes, it is easier to declare an incident with a high priority though let people know if may get to be higher priority as facts are established. |
| Phase 3 | Contain, Eradicate and Recovery. Depending on the type of incident, you need to contain it (for instance with malware – ensure that the spread is contained, with a data exfiltration – ensure that no more data can be egressed etc). This part is making sure that the stable door is shut whilst the horse is still in there.
Eradicate is finding the initial source of the compromise and making sure that all traces are removed. We used to call this ‘patient zero’. How or where did the attack start and try to develop a chronology of events. Recovery. This is all about getting back to a Business as Usual state. It is imperative that at each stage we document what happened. By documenting this, it helps when it comes to the post event activity. It also helps if law enforcement or cyber security teams need to carry out investigations. This falls into the NIST ‘Respond’ and ‘Recover’ state |
| Phase 4 | Post Event Activity. Post event activity is where we close the loop. What caused the incident to occur, why did it happen, was one of our controls breached, did it not work or was it not there. How can we be sure that this one wont come back – can we put things in place ?
This stage is all about reducing the chances of that incident re-occuring or one similar taking place. This also falls under the ‘Recover‘ state. |
First steps – Preparation
Let’s start with some definition. Firstly what are we defining an incident as ?
The National Cyber Security Centre (NCSC) defines a cyber incident as a
breach of a system’s security policy in order to affect its integrity or availability and/or the unauthorised access, or attempted access, to a system or systems; in line with the Computer Misuse Act (1990).
That’s fine, though there is another definition that I would prefer to use, it’s from the National Institute of Standards and Technology (NIST):
An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
So, this means we don’t need to have a breach. It means that we would also report on the times ‘we were lucky’. This also means we encourage users to report near misses so we have a fuller understanding of what is going on and controls which may need to be strengthened.
So how do we go about preparing our Security Incident Management Process?
Preparation
We start with the preparation. For Security Incident Management, I would suggest having:
- An agreed definition of what a security incident is. We all want to agree on what an incident consists of before it occurs. Are the board members happy with what we are defining as an incident ?
- A security incident management policy – outlining intent and signed by management. This may just be contained in the Information Security Policy. Here we can include our agreed definition of an incident.
- A security incident management guide, detailing the types of Security Incident you respond to, how you would know that an incident has occurred (this may be technical indicators of compromise – or trends / items reported in through the helpdesk). You also need to agree on the levels of priority that should be assigned to them, as they occur. An example could be:
| Priority Level | Description |
| Severity 1 | A critical incident that has the ability to have high impact on the business. Here it is down to the organisation to determine what consists of high impact. Perhaps use past experience or look at how an incident could impact revenue, reputation or brand. |
| Sev. 2 | This may have medium to high impact. It could have a negative impact on the reputation of the business |
| Sev. 3 | This may be low to medium impact. Some customers may see the services you offer in a negative light – though any reputational damage could be short lived. |
| Sev. 4 | This could be a near miss reported into the security desk. |
The above is subjective and time should be taken to work out what applies to your particular scenario.
- A security incident response plan – detailing how security incidents will be responded to.
- A security incident playbook – telling you what a security incident is and how each member of staff can respond to it.
- A security incident log – a mechanism for recording security incidents
Anything else?
There might also be other documents that either need to be created or reviewed whilst we are developing this. For instance:
- A critical incident management plan. Imagine that your technology was done. Do you have Authenticator codes somewhere so you could access a server. Are there any access control rules that may need to be changed in short order. Do you have agreement with your service provider how this could be performed.
- A communications plan. Do you have a list of people who you and your peers will be in touch with, and a mechanism for the technical folk to work on the incident, whilst there is a conduit between technical and management (sometimes technical people spend more time updating more than one person, whilst loosing time trying to fix things)
- A list of stakeholders with contact numbers. Perhaps the ability to create a bridge conference facility.
- A grab bag – holding an upto date list of all these numbers – perhaps even in hard copy and a working mobile phone – just in case you need to evacuate the building (for an environmental incident).
- A pizza or fast food menu of a local takeout for when the night is ruined.
These are going to be discussed in more detail over the coming weeks. We are busy creating some fun scenario planning games around Incident Management – so please. Check back.
Incident Management and cybe essentials
In2secure are a Certified Body for Cyber Essentials, the UK government scheme that covers all the fundamentals of cyber security. We’ve completed the assessment ourselves and help other businesses who want to get certified in Cyber Essentials.