At some point, the chances are growing that your business will have to deal with a cyber security incident.

But when you are under pressure and your team is stressed, people make mistakes.

Crisis patterns over the past decade have changed dramatically. 10 years ago elements such as civil war and oil prices were the top global risks to take into account. Now we see water crisis and extreme weather events taking control of keeping us up at night.

Delaying too long in making critical response decisions may exacerbate the impact of the incident but, conversely, making knee-jerk decisions can cause further damage to the business or hinder a complete response.

There are many ways you may suspect that a security incident has happened, from detecting unusual activity through proactive monitoring of critical systems or during audits, to outside notification from law enforcement and compromised data located in the wild.

However, indicators such as unusual CPU (central processing unit) and network usage on a server may have multiple potential causes, many of which are not information security incidents. So it is vital to investigate further before jumping to conclusions.

Do you have any corroborating evidence? For example, if the IDS (intrusion detection system) detects a brute force attack against the website, do web logs support this having occurred? Or, if a user reports a suspected phishing attack, has this email been received by other users and did the user click on links or open documents?

You also need to think about answering questions about the nature of the incident. Is it a generic malware infection, or an active system hack? Is there an intentional denial of service (DoS) attack in progress and is this an incidence of deliberate insider action?

Once you have confirmed an incident has occurred, you need to take time out from initial response activities to prioritise your actions and decide, definitively, what the business objectives are for the response operation. Incident triage generally consists of classifying the incident in terms of impact and urgency and how it should be handled. The incident response team can then use the impact, urgency and priority evaluation to define the objectives for the incident response operation and assign actions or further investigation, as required.

Impact classifications defined by the National Cyber Security Centre’s (NCSC) GovCertUK and adopted by Crest, the body that represents the technical security industry, may provide a useful point of reference for initial classification based on the perceived or established impact.

Many minor types of incident can be capably handled by internal IT support and security. All events should be reported back to the information security team who will track occurrences of similar events. This will improve understanding of the IT security challenges and may raise awareness of new attacks.

It is not necessary to report on incidents with little or no impact or those affecting only a few users, such as isolated spam or antivirus alerts, minor computer hardware failure and loss of network connectivity to a peripheral device, such as a printer.

The urgency of an incident should also be assessed along with the impact. Some incidents are unlikely to worsen over time, such as the discovery of a historical compromise by a former employee. But in other cases, such as a ransomware outbreak, it may be absolutely critical to respond rapidly to isolate the infection.

Mobilising full emergency incident response capabilities may not be applicable or appropriate in every situation. You need to understand as much about what you are dealing with as you can. For example, who is the attacker? How was the attack introduced? When did the attack occur? What data or systems have been compromised? Is the attack ongoing? Why were we the target of the attack?

The goal of triage is to understand the methodology and the extent of the attack as fully as possible, in the shortest possible time.

Information about the incident, the impact, urgency and business impact analysis for the affected data or systems will guide the incident response operation. If possible, the business priorities should be pre-determined and documented in incident response plans.

Objectives for the incident response team could include:

Resumption of service as quickly as possible, where the affected system is critical in terms of availability for the business.
Rapid ring-fencing and protection of confidential information, where the affected system or network is critical in terms of confidentiality for the business.
Integrity checking of the affected systems, where integrity of data is critical for the business.
Preservation of evidential integrity, where criminal activity is suspected and prosecution is likely to be an outcome of the incident, or where culpability must be established definitively.
Identification of the origin of the threat and gathering intelligence about the activities being conducted during the incident.

For organisations with known advanced threat actors, continued covert observation of an attacker to determine their goals and modus operandi may be an objective of the incident response operation for intelligence-gathering purposes, even if the urgency for containment is high. Experienced internal or external incident handlers should be used to inform these decisions.

Once the priority of the incident and the objectives of the response have been defined, it is time to act and allocate activities to the incident response teams.

So if you want to save yourself stress, money and a damaged reputation from a cyber incident please ring us now on 01242 521967 or email assist@cyber139.com or complete the form on our contact page NOW