Make the SOC more efficient with the help of an orchestrator

With any cyber threat, a rapid response is essential. The use of an orchestrator at the SOC, based on the automation possibilities offered, makes it easier to monitor alerts and take quicker decisions when facing a cyber risk.

Increasing the security of IT systems, a Security Operations Centre (SOC) continuously analyses the activity at an IT environment’s core. It is used for the real-time detection and handling of anomalies, and generation of alerts. Such a solution gives users greater peace of mind, as someone is permanently watching over the organisation’s digital assets and security.

Improve the management of each alert

Managing each alert means carrying out investigations to be able to classify them.

An alert does not necessarily mean a threat, and does not systematically require intervention at a system level.

When an anomaly is spotted, SOC teams are tasked with gathering as much information as possible to determine whether the company has fallen victim to an attack and is exposed to any leak or loss of data, or whether the alert is a false positive. In the latter case, the alert will be placed on file.

This information must be taken from intelligence threat databases (e.g. data on a public IP address, file hash, etc.) or directly from logs (to check what action has been taken before or after the alert).

Speed up the threat response time

The checks to be made after an alert, which require a lot of human resources, may take time. Operators often have to perform them manually. When a risk is presented, the ability to react quickly is crucial.

To shorten the response time, it’s worth using an orchestrator.

This is an application used to automate the searches and some of the tasks performed manually by operators after an alert. An orchestrator enhances alerts by automatically retrieving the information so that it can then be reported in an e-mail, Teams notification or any other means of communication, to make it directly available to the person responsible for classifying the danger.

This saves precious time and prevents any decision that might have disrupted the organisation’s operations, such as blocking a user’s machine or terminal due to a potential threat that ultimately proves to be a false positive.

Facilitate the classification of each alert

A playbook is a series of actions performed in a specific order, and which may be shown in a decision tree.

With the help of these playbooks, certain tasks can be automated directly through the orchestrator, such as searching for information in a given situation or for other operations, collating data or classing an alert as a false positive where appropriate. The level of automation can be very high.

By interfacing the orchestrator with ticketing applications, it is possible to automate the creation of tickets and assign this, along with all the necessary information, directly to the team best able to handle the alert. The engineer can then close the ticket much more quickly if it proves to be a false positive on the basis of the available data sent, or otherwise take the measures required.

If the factors leading to classification as a false positive are known, they can be entered in the orchestrator so that it can close the ticket automatically whenever it detects them.

The tasks delegated to the orchestrator – a real help to SOC operators – will gradually be increased in response to the scenarios encountered wherever automation may be appropriate. This allows for ongoing improvement of the service by freeing up time, enabling staff working on redundant tasks to switch to more specific tasks, such as threat hunting or technology watch.

Automate decision-making to contain the threat

Following an automatic data analysis, the orchestrator can also take action to block a user or machine, or any other part of the system environment if the procedure so requires, in order to prevent any contamination of systems.

However, raising automation to this level requires a full understanding of the components of the analysis, being sure that the automatic block is a response to actual threats.

A block caused by the orchestrator misclassifying the alert could disrupt production across the organisation.

…or support the decision-making

To avoid this kind of inconvenience, a semi-automatic block may be considered. In this scenario, the orchestrator collects the information and sends it to the person authorised to make a decision, by e-mail for example. In this e-mail, the recipient is asked whether or not to trigger the block just by clicking on ok. Once the decision is confirmed, the orchestrator begins the process to contain the threat.