Incidents can have a huge impact on an organization in terms of cost, productivity and reputation. Being prepared to detect and quickly respond to incidents will help to prevent the attacker from inflicting further damage, so reducing the financial and operational impact. Handling the incident effectively while in the media spotlight will help to reduce the impact on your reputation.

1 in 10 organizations don’t have an incident management plan. If you’re one of these organizations, then you should address this immediately.

Incidents often occur at inopportune moments and most people’s decision making is compromised in times of crisis. For these reasons, everyone must have a clear understanding of their role and the organizational response in advance, especially Board members who would likely be representing the organization in the media.

The Board also needs to be explicit about who it is willing to devolve authority to (especially outside core working hours), and exactly what that authority covers. For example, does that cover calling in a contracted incident response company, or taking down a public facing website? The Board also needs to be explicit about when it wants to be informed of an incident, both in terms of at what stage of the incident, and in terms of what significance of incident they need to know about.

The best way to test these processes and thresholds (and to get a good understanding of the Board’s role) is through exercising the incident management plan. If you would be involved during a real incident, then you should be involved in an exercise. Doing this in conjunction with operational staff can also help to highlight issues around authority for critical decisions. Even if you do not have a direct role in responding to an incident, running an exercise can be a good way to understand the realities of how an incident would impact on your organization.

Post-incident analysis provides insight that can help you reduce the likelihood of incidents occurring in the future and reduce their potential impact. Crucially in order to get this insight you need to be able to be honest and objective about what has happened. This can only happen in a no blame culture, such as you would use when investigating health and safety incidents. Critically for the Board, new regulation, such as GDPR, is clear that responsibility for incidents or data breaches sits with the organization and not an individual. Therefore the Board is ultimately responsible for any cyber security incident as the governing body. Apportioning blame to a specific individual within the organization will be treated as poor cyber security practice.

One of the most common things overlooked is being able to identify what constitutes an incident. There’s two aspects to this:

1. Working out how you would spot an event in the first place.

2. Working out at what point an event (something happening on your networks or systems) becomes an incident.

HOW WOULD YOU SPOT AN EVENT?

Depending on their motives, an attacker is unlikely to tell you when they have successfully compromised your organization, so you need your own methods to identify an intruder or an attack. This normally takes the form of monitoring. Monitoring refers to observing data or logs collected from your networks or systems to identify patterns or anomalies that could indicate malicious activity. Even if you don’t have monitoring to identify the incident, it is still useful to collect system or network logs (especially those relevant to your critical assets) so that you can retrospectively review them once you know an incident has occurred.

WHEN DOES AN EVENT BECOME AN INCIDENT?

This is often not a clear cut decision. You can try and gather as much information as possible to inform your assessment of an ‘event’, but you probably won’t have a complete picture of what has happened. Beginning an incident response might have implications for cost, reputation and productivity, so you will want to consider who has the authority to make this decision, and what the thresholds are for an incident in advance.

WHAT IS A CYBER SECURITY INCIDENT?

A breach of the security rules for a system or service - most commonly:

• attempts to gain unauthorized access to a system and/or to data

• unauthorized use of systems for the processing or storing of data

• changes to a systems firmware, software or hardware without the system owner’s consent

• malicious disruption and/or denial of service

All the information you have previously gathered on what’s important to protect, the threat and your technical estate will provide critical insight in two key areas:

• It will give you insight into the impact of incident. If the attacker has accessed a particular user device, what could they access? Could they access those things you care about the most?

• It will help you determine your operational response. If the attacker is on a specific network can you isolate that network? If you can, what would the impact be on your organization?

Put measures in place to help reduce the harm that an attacker could do. This could be:

• introducing measures that restrict their movement once they are inside your network

• preemptively reducing the impact of attacks (for example, backing up your data will help to reduce the impact of a ransomware incident)

As with any other defensive measures, these should be focused on protecting what is most important to you.

Cyber Incident Response is a complex subject as no two incidents are ever the same. However, as with all business continuity planning, you can develop a plan that will outline the key elements of your response. Your plan should not only cover the technical elements, but also:

• the people and process elements such as media, customer and stakeholder handling

• reporting to regulators

• dealing with legal actions

For more common incidents (such as password compromise) it may be helpful to develop a specific ‘playbook’ setting out your organization’s response.

Rehearsing your response to different scenarios is key to ensuring your plans are effective and remain current. There are various exercising packages you can use. This will be a critical part of the role for any staff involved directly in incident management, but every Board member also needs to understand their specific area of responsibility during an incident.

An often overlooked aspect of incident management is the post-incident review. An incident can provide valuable insight into your cyber readiness, including:

1. The threat your organization faces.

• Who carried out the attack and was it targeted?

• Did they go about it in the way you expected?

• Did they go after the things you expected?

2. The effectiveness of your defensive measures.

• What did your defenses protect against?

• What didn’t they?

• Could they be improved?

3. The effectiveness of your incident response measures.

• What would you have done differently?

• Did your response help to reduce the impact of the incident?

• Did it make some aspects worse?

Your plan should also consider how you mitigate the impact on any partners or customer organizations if you were compromised. When do you inform them? What mechanisms are in place to limit the damage it could do to them? You should also consider what you would do in the event that a supplier is compromised; you may not have control over how they deal with the incident. What would you be able to do independently to reduce the impact on your organization? The best way to mitigate this risk is to have a collaborative approach to your security with your partners and suppliers.

The following questions can be used to generate productive discussions with your technical team. The aim is to identify what constitutes ‘good’ cyber security in terms of responding to cyber incidents.

The organizations best equipped to respond to incidents treat them as a matter of when they occur, not if.

A basic plan should include:

• Identifying the key contacts* (incident response team or provider, senior management, legal, PR, and HR contacts, insurance providers).

• Clear escalation routes (for example to senior management) and defined processes for critical decisions.

• Clear allocation of responsibility (specifically whether this is for normal working hours or 24/7).

• Basic flowchart or process for full incident lifecycle .

• At least one conference number which is available for urgent incident calls.

• Guidance on regulatory requirements such as when incidents need to be reported and when to engage legal support.

• Contingency measures for critical functions

This might include:

• Incident response providers

• Your Partnered Cyber Incident Response Team

• Intelligence sharing groups, for details of other companies experiencing the same incident.

It’s important to learn lessons from incidents as well as from ‘near-misses’. These will give you valuable insight into the threat you’re facing, the effectiveness of your defense, and potential issues with your policies or culture. A good organization will use this insight to respond better to future incidents, and not seek to apportion blame. The Board may decide it doesn’t need to know the details of every incident, just the most significant lessons learned from the incidents experienced.

This incorporates two aspects; what are the triggers that can tell us an incident has happened, and how do we then share that information within the organization?

When considering what might trigger an incident, you need to consider:

• What monitoring is in place around critical assets (like personal data) that would have an impact if compromised, lost or changed?

• Who examines the logs and are they sufficiently trained to identify anomalous activity?

• What reporting mechanisms are there in place for staff to report any suspicious activity?

• Are the thresholds for alerts set to the right level - are they low enough to give suitable warning of potential incidents and high enough that the team dealing with them are not overloaded with irrelevant information?

When considering how an incident will be shared internally, consider:

• What constitutes an incident?

• Who has the authority to make that decision?

• Who needs to know the details of the incident?

• Has the Board explicitly conveyed the threshold for when it wants to be informed of an incident?

This will depend on your organizational structure. It might sit with the one member of the Board, or one of the executives, or it might be divided out into different roles. Ideally you should:

• Specify exactly who is able to take decisions on which aspects.

• Have backup plans in place if those decision makers are unable to fulfilll that duty (for example, out of hours).

• Test this decision making process, with a focus on potential areas of overlapping responsibility.

Consider:

• Do I have the understanding required to make decisions potentially out of hours, and under time pressures?

• Do I need training to support my specific role in an incident, such as understanding relevant regulation, or dealing with the media?