To fight this growing threat on equal terms, incident response teams – Security Operations Centres (SOCs) and Computer Security Incident Response Team (CSIRTs) – can benefit from a wide range of automated security tools. A type of solutions gradually gaining more attention are Security Orchestration, Automation and Response (SOAR) platforms. These tools combine together incident response, orchestration and automation, and threat intelligence platform management capabilities.

Notwithstanding the ultimate benefits, introducing any automated tool in existing incident response processes is no easy task. It presents new challenges to the teams, especially to define what tasks and decisions should be automated and which require human expertise instead.

This article aims to present an overview of SOAR platforms and provide best practices and recommendations on how to address some challenges faced by incident response teams as they approach SOAR solutions. First, it breaks down the potential uses of SOAR platforms in support of all incident response phases. Then, it dives deeper into some of the considerations and decisions that teams have to make, offering concrete recommendations as well. Last, it briefly looks into the of role of humans as opposed to AI-enhanced platforms.

Supporting the incident response process

Bringing together all security tools, a SOAR platform can work as the conductor of the security ecosystem in an organisation, streamlining the incident response process. It can indeed support and facilitate all key phases of the incident response, including triage and prequalification, investigation and analysis, and last response and remediation.

Figure 1 – High level SOAR integration model

During the triage and prequalification phase, a SOAR platform can collect alerts coming from specialized incident detection tools, like Security Information and Event Management (SIEM) tools. While this is a consolidated activity run by well-established tools, two major issues remain, concerning false positives detection and threat prioritisation based on contextual information.

This is where SOAR platforms can be helpful, by automatically enriching incidents, filtering out false positives and then highlighting critical security incidents. On one hand, relevant Indicators of Compromise (IoCs) can be automatically from reputable sources, such as cyber threat intelligence (CTI) providers offering highly tailored data from recent breaches occurred to similar organisations. On the other hand, internal knowledge can be ingested as well, drawing from predefined assets classification or machine-readable business impact analysis (BIA) results. This enables analysts to save time and directly tackle critical incidents, having all the information needed to focus on incident response.

In the incident investigation and qualification phase, a CSIRT can benefit from SOAR support by automating basic use cases management. While the first phase concerned more automated actions triggered from systems alerts, for instance CTI enrichment based on SIEM alerts, in the investigation phase the value added of a SOAR platform consists mostly of supporting the team’s analysis. For example, when a phishing email is reported, the SOAR platform can facilitate the collection of information needed to perform the investigation and qualification of the incident, thus making it more efficient. However, the expert’s assessment can hardly be automated for more complex tasks, like thorough analysis and qualification of complex incidents.

The response and remediation phase remains the most complicated to automate, due to both the nature of the actions required and the risk of negatively impacting the business if a remediation is executed poorly. Automating a response action must allow to capitalise on the efficiency gains, while keeping into consideration the cost-benefits assessment. 

SOAR platforms therefore can significantly facilitate the work of cybersecurity analysts, who do not have to process every incident, from tool to tool, manually, at each step of the incident response process, but can rather rely on automated tasks involving several security tools working together. After seeing different possible applications, the following question concerns how to choose what to automate.

Deciding when to automate based on the low-regret impact principle

For each IR task, there exist three different approaches for SOAR platforms:

• Full automation,
• Semi automation,
• No automation.

In full automation cases, multiple steps are pre-defined and automated in sequence, based on pre-set triggers or manual activation. Simple use cases, like the previously mentioned phishing emails, can build on full automation and provide substantial benefits to minimise time-consuming and repetitive tasks.

In semi automation cases, some steps – e.g., initial analysis, evidence collection, or information enrichment – are automated to enable the analyst to choose the best course of action. This might indeed be the most common usage of SOAR platform at the moment.

Last, some situations just do not allow for automation and will continue to require and be performed by human operators.

As IR teams explore the functionalities and potential of SOAR platforms, it is common to wonder how to choose what use cases can and should be automated. Besides a feasibility assessment, a fundamental driver to adopt is the low-regret impact principle. Considering that security is always a supporting function of business objectives, a careful risk-analysis is needed when there is the risk to affect business units or services. A benefit-versus-regret assessment leads organisations to change their perspective on the problem by making them choose when certain actions can be automated instead of whether they can be automated.

To provide a more sophisticated and realistic picture, two observations are in order. First, this choice is usually non-binary (e.g., high-regret vs. low-regret), since there should be growing levels of risks and reasonable confidence, based on an organisation’s risk appetite. Regret is better quantified on a scale. Second, such cost-benefit analysis is necessarily contextual, meaning that it has to take into account the situational conditions in which it is taken. During an ongoing crisis, automated actions might become more or less appealing, given the evolving risk calculation.

In concrete, actions with very little chance to disrupt business operations are to be considered low-regret actions, allowing for greater automation. Actions with the potential to cause widespread or impactful disruptions when carried out incorrectly can be assessed as medium-regret actions, requiring human confirmation to complete the workflow. Finally, actions that would disrupt business activities in an unacceptable way (e.g., disruption of highly-critical assets) are seen as high-regret actions, discouraging automation. Nevertheless, in particular circumstances, such scale can be revised and adapted.

Adopting a progressive approach

Once the basic concepts about SOAR solutions are defined, IR teams face another major challenge related to change management. Switching from manual playbooks to automated workflows entails a burdensome process that require careful prioritisation. An increasing degree of automation can be reached through a gradual and progressive approach.

Simple tasks that are time-consuming and present a low-regret risk can be automated first, reducing the low added-value workload of IR analysts and increasing their efficiency. This can be set up quickly, given the technical feasibility of such actions (e.g., existing API). In addition, standardising tasks can accelerate further automation stages by making them reusable in different playbooks or branches. Indeed, it is better to start automating easy playbooks’ branches, like clearing-out false positive, before extending the automation to the whole playbook where all possibilities of an alert have to be considered.

AI supporting humans’ activities

Some SOAR solutions rely on and benefit from Artificial Intelligence (AI), whereby a machine learning (ML) model can be trained on specific data fed to it. For example, a dataset of phishing emails classified according to different values (e.g., legitimate, malicious, spam) can train the ML model.

AI-enhanced SOAR solutions can help to quickly resolve simple incidents or easily identify automatable actions, yet the human reasoning will better contextualise choices based on business and operational considerations. Ultimately, no automated solution can work without the intervention and supervision of analysts yet. Instead, AI is mostly meant to perform a specialized single task efficiently by processing large amounts of data. This highly improves the team’s efficiency, working alongside humans, rather than replacing them.

Conclusion

All considered, SOAR platforms are powerful tools. While they can support IR teams throughout all stages of their everyday work, including information collection, analysis and active response, it should be emphasised that SOARs are not magic tools capable of solving all issues and problems teams face today. On the contrary, purchases not followed by well-defined implementation projects will likely result in ineffective outcomes and low returns on investments. On the technical side, SOARs cannot perform tasks that backend systems do not allow; on the organisational side, they will always rely on well-established, standardised, and tested processes and procedures. As organisations evaluate their adoption and consequently navigate the steps to integrate them and capitalise on their potential, driving principles like low-regret impact and a progressive approach determine the ultimate result and benefits teams are aiming to gain.

Thanks to Fabien Leclerc for the research and writing support

Cet article Improving Incident Response through Automation: An overview of SOAR platforms est apparu en premier sur RiskInsight.

Improving knowledge of threats and attackers

Cyber-threat intelligence (CTI) platforms

Cyber-Threat Intelligence (CTI or Threat Intel) is a discipline that brings together the collection, consolidation, and exploitation of all information on cyber-threats. “Know your enemy” says Sun Tzu in the Art of War. Although this quote refers to “physical” wars, the principle remains true, and is probably even more true when it comes to “cyber” battles.

Today, a large number of security approaches rely on knowledge of attacks: the signature-based approach of antivirus and IDS solutions, targeted detection scenarios, etc. Even though this trend is reversing (in particular with the detection of anomalies) the vast majority of security products still rely—and will continue to rely—on the principles of Threat Intelligence.

With companies’ needs becoming more specific, and attackers ever more specialized, Threat Intel solutions are becoming increasingly popular, with services being offered directly to companies. In addition to commercial offerings, more and more exchange platforms and partnerships are enabling direct collaboration with other companies (in the same sector or geographical area, etc.).

Threat Intel offers a range of services. On the one hand, ‘strategic’ Threat Intel helps an SOC better understand the context and specific threats to the company. To do this, the risks from various ecosystems are studied: geographical, political, ideological, sectoral, etc. This information enables security teams to better understand the threats they face and guides their decisions to define “long-term” strategy (solutions to be deployed, etc.).

On the other hand, ‘tactical’ Threat Intel provides more precise information on attackers’ methods, allowing the SOC to facilitate detection and tailor existing measures: new threat scenarios to monitor, ports to block, etc.

In addition to these approaches, ‘technical’ Threat Intel contributes greatly to the analysis of security events by providing, on request (from SOAR in particular—see below), elements that enable the veracity of an alert to be judged: an IP belonging to a botnet, a file hash corresponding to a known virus, etc.

Threat Intelligence approaches are therefore among an SOC’s most versatile tools, enabling it to make the most of existing devices, by remaining up to date and prioritizing the threats to be detected, as well as identifying future tools and measures to be deployed.

Examples of Threat Intelligence publishers:

The standardization and automation of the response process

Security Orchestration, Automation and Response

Security Orchestration, Automation and Response (SOAR) is derived from the combination of three SOC tools: Security Incident Response Platforms (SIRPs—more details here), Security Orchestration Automation (SOA— orchestration and automation solutions) and some of the functionality of Threat Intelligence platforms. In summary, these are platforms that provide help and automate responses to security incidents. The solutions are similar to traditional ticketing tools (ITSMs) but include functionalities specific to cybersecurity issues. SOARs offer three main capabilities, each linked to one of the three types of tools from which they are derived.

First, like SIRPs, they allow the definition of response processes that are tailored to each security event. These are based on pre-defined playbooks provided by the publisher, published by the community using the solution, or created manually to better tailor things to the needs of the business. In particular, this task requires response teams to establish a clearly defined process that encourages them to ask themselves the right questions when they create response procedures, as well as to capitalize on and retain the knowledge gained.

The benefits of a SOAR, however, come more from the automation of the various stages that follow detection. During the analysis phase, the tool will automatically enrich knowledge about a security event by retrieving contextual information about the IS (identity in the AD, criticality of a resource, etc.), and querying external Threat Intelligence services (via APIs) or those that are offered as part of the solution. In addition to automating the enrichment and analysis steps, SOARs also facilitate the work of analysts:  the investigation of terminals, the interrogation of VirusTotal etc. in one click—when their involvement is required.

But automation doesn’t stop there! Although controversial, the automation of the response (via the connection to security equipment, a legacy of SOA) can represent an important gain for security teams: the blocking of a URL, the generation of the signature of a file and its propagation to antivirus tools, the blacklisting of an IP, etc.

The goal of SOARs is clear: to make it easier for the teams in charge of analysis and response, by helping them to define processes and automate tasks to the greatest extent possible. Although SOARs are very adaptable and can therefore help in response to any type of attack, they really shine when it comes to automating the treatment of common attacks (such as ransomware, phishing, etc.), which are very repetitive and tie up the resources of response teams.

Once these tasks have been automated, the security teams responsible for responding can focus on more complex alerts, where their knowledge adds real value.

Provided they are prepared to put in the initial effort (the formalization of processes, etc.), the likely reactivity and load gains are significant. SOARs will change the way SOC teams work, especially with respect to top-level analysts. Even though these solutions are still rarely deployed in France, they are set to become an essential tool for SOCs in the coming years.

Examples of SOAR publishers:

Even though tools are only part of equipping an SOC, each of these solutions has distinct advantages that can help detection teams keep up to date in terms of the evolution of ISs and threats.

All the tools are promising, and some are coming to maturity. However, it’s important to keep in mind that current toolkits already raise a raft of alerts, which presents a challenge when it comes to processing. It’s therefore advisable to complete the deployment and automation of what exists (using SOARs, for example), before turning toward new solutions.

And, as for any innovative product, a cool head is needed: the deployment of a new solution must be the result of well-defined needs.

Cet article SOAR, UEBA, CASB, EDR and others: which tools do you need for you SOC? (3/3) est apparu en premier sur RiskInsight.