We gave our two cents on how everyone in the company should be involved in creating a cybersecurity culture at the workplace. But what happens when a cyber incident occurs and needs a specialised strategy by a qualified cybersecurity team? Does incident management stop at detection?

TechTarget defines incident management as an area of IT service management where the IT team returns service to normal as quickly as possible after a disruption, aiming to create as little negative impact on the business as possible. However, as much as we hope employees are human firewalls and own their role as part of the whole, slip-ups may happen.

Suppose you are a managed security service provider or MSSP with a single service level agreement or SLA line item for incident detection. In that case, you might say incident management stops at detection. However, the journey for the entity is far from over. Incident detection, or the ability to understand the most negligible differences and notify these as soon as possible or otherwise known as incident detection, is only the first out of many steps. While your internal cybersecurity team or MSSP may be tasked with incident detection, the other stages are equally as crucial in reducing the scale of the impact. 

The above step is one in the incident management process. Ransomware and other malware attacks in the IT and OT space have a silver lining: entities are now taking cyber security seriously. It’s a subject for a different blog, as many organisations still opt out of cyber security without realising the mistake until it’s too late. As we know, no one person or entity is off limits. 

Incident management can take many forms but will take on the following stages for cybersecurity-related incidents:

1. Detection
2. Containment
3. Eradication
4. Recovery
5. Lessons learned

Ahead of all these stages is the preparation stage. This stage is arguably the most crucial as it sets the scene, governs the process, and establishes the team and authority.  

The effectiveness of the planning stage will result in some key metrics; 

1. How fast the team and the business can execute the incident.
2. The management process.
3. Positioning the people when an incident occurs.
4. Technology and tools available (incident management resources) to address security incidents and reduce business impact to the best of their capabilities. 

In the opening paragraph, I noted that the MSSP or the incident detection resource would potentially be off the hook. However, these resources will be there until the end to support the incident response team or IRT in traversing the mountain ahead.

The IRT would have resources such as cyber security information officers, analysts, etc., with clearly defined roles and responsibilities they will need to execute during the journey. Cyber security responsibilities are not the only resources required. As this will be a unique journey for the business in question, usually essential functions will also be well represented in the team. The IRT must have a playbook to work with, including detailed procedures to address and handle incidents in line with the risk appetite and tolerance of the business. It’s unique to each company and will mature over time as the team grows. 

The playbook should include scenarios that will apply to the business and not ones that will carry no relevance. The range should be extensive and cater to a variety of likely situations or outliers with huge impacts. 

As with all plans, annual tests come highly recommended with lessons learned from previous incidents, test runs, and updates. It will ensure that the last context is provided to avoid making the same mistakes or errors. In addition, the test will help the team identify gaps early on so that they are addressed and the team is ready should an actual incident occur. 

Resource skills and certifications should be maintained and updated from time to time. They should always be in line with the needs and systems of the business. For example, an error in collecting an essential piece of necessary evidence due to an incorrect procedure could mean that the attacker gets away with the incident. The journey should be well documented, systematic and structured, with a critical experienced team leader. 

These examples can help with context and information for individuals not part of the IRT. 

For example, some of the key things to remember during an incident are to:

1. Collect volatile data critical to the journey.
2. Using identified indicators of compromise or IOCs, use available intelligence sources to support the journey.
3. Safeguard essential elements/components of the journey.
4. Collect applicable logs such as events, audits, networks, etc. 

In the event of an incident, it is recommended not to:

1. Panic. Remain calm and follow the plan or training to plot the journey based on the scenario. 
2. Shut down any systems as volatile data in place (information loaded into temporary memory such as RAM) may be lost if power is removed. 
3. Overcommunicate. Restrict communication to address the incident at hand. We would not recommend unnecessary contact in such incidents; they may delay the process or expose additional risk to the entity. 
4. Act in isolation. Always follow procedure and or training, especially as an end user. There are no heroes here, and incidents are always best addressed as a team, not as individuals. 

It covers the basics and hopefully will provide you with some information you did not know.

If you want to get started on your incident management plan as a company, get in touch with us here for a free consultation!