Why Safely Automating Means Selectively Automating In Security Operations

Back to all articles

Selectively Automating In Security Operations

The most dangerous aspect of automating security operations and incident response processes and tasks is automating the containment of a threat. It is here where the greatest potential detrimental impact on operational integrity can occur, but there are a lot of actions and tasks involved in effective incident response that can be safely automated. Primarily focused on four core task categories, in this blog post we will discuss these core areas in more detail, outlining what can more easily be automated and what may require a little more care and thought in the process.

Continuous Data Collection

Ingesting, normalizing, parsing and correlating incoming security data from disparate security technologies and sources is something that can be safely and trivially automated. Security Information Event Management (SIEM) tools are the most commonly utilized technology to do this, but its focus is primarily on correlating log and event sources. Security Orchestration, Automation and Response (SOAR) solutions, like IncMan SOAR from DFLabs, provides a broader focus in terms of third party security data sources that can be ingested, and also provides granular and customizable playbooks and runbooks that can execute additional and specific data collection actions based on conditional workflows and triggers.

Continuous data collections means that security operations centers (SOCs) and/or computer security incident response teams (CSIRTs) can be proactively alerted of suspicious and malicious activity and events that occur in the environment that they are monitoring, and makes additional data required for incident qualification, analysis and investigation immediately available.

Automatically fusing incident data with external threat intelligence, or enriching it with additional context, such as related observables or indicators of compromise is also generally safe. There is one possible caveat to this though that applies to sensitive environments or organizations with critical security requirements. Sending out requests for related threat intelligence or submitting malware hashes to an external third party provider, can enable that party to infer that the submitting organization has been impacted by a specific threat or threat actor.

Automating threat intelligence fusion and context enrichments can overall be a great time saver, reducing the time and effort required to qualify and verify an incident, assess the impact and shorten the subsequent time from discovery to containment.

Triage and Notification

Triaging incidents to ensure that they are assigned to the correct security analyst or incident responder can also be safely automated, as can notifying relevant stakeholders such as HR, legal or executive management or related IT operations teams. Similarly, opening tickets or cases in IT Helpdesk and Service Management systems reduces the amount of menial work that the SOC or CSIRT must conduct. This essentially speeds up incident resolution and also ensures that a closed-loop incident response process is followed.

Forensic Evidence Gathering

Gathering and fetching related forensic evidence such as process lists, application inventories configuration settings, activity logs and disk images can also be safely automated, providing these do not lock out active users, shut down running processes or initiate system shutdowns or reboots.

Forensic evidence gathering must be conducted in a manner that does not tamper with or destroy relevant evidence, and must collect and store that evidence in a way that ensures that it is compliant with legal and regulatory mandates. Automation, if carried out correctly, can aid to assure this as well.

Automating Containment

The greatest risk and danger in automating incident response is when applying it to containment and remediation of threats, and so poses the greatest challenge. When considering automating the containment of a specific threat, three questions are relevant and should be asked.

  • How reliable is the detection and identification?
  • What is the potential detrimental impact if the automation goes wrong?
  • What is the potential risk if this is not contained?

Let’s now briefly look at these one by one.

How reliable is the detection and identification?

The degree of confidence in the detection and identification of a specific threat or attack is a major factor in deciding whether to automate containment. This has been the historical inhibitor for enabling full blocking and containment, for example when deploying an intrusion prevention system (IPS). Generally there are two types of approach to this.

The first approach considers how reliable it is in general to detect a specific attack. Some types of malware or exploitation can be easily identified. This is the case for example when a malware file hash has been confirmed via multiple queries, for example via a local AV solution and an external service.

The second approach is based on an analysis, which is essentially a consolidated score that factors in multiple related indicators of compromise (IoCs), exploited attack vectors and other observables to derive a weighting or certainty which will be used to determine whether containment will be automated or not. Once a highly certain threshold is exceeded, containment can be automated. Behavioural analysis and related machine learning capabilities are frequently used for this, although simpler methods such as correlation can also be used, providing sufficient IoCs have been evaluated.

What is the potential detrimental impact if the automation goes wrong?

Whether the curse is worse than the disease must be carefully considered when deciding what to automate. Erroneously automating threat containment on critical infrastructure or in operationally critical environments, or when related to priority customer or mission critical processes can detrimentally impact operational integrity and in a worst-case scenario could cause the loss of revenue.

Trading platforms, internet retail portals and medical or energy infrastructure are good examples where automated response is best avoided unless done very selectively or with caution. One thing to consider though is that the same reasons why we are hesitant to automate, because they are critical and sensitive, also means that incident response in these cases must often be executed more rapidly to contain threats to avoid the same potentially negative impacts that hap hazardous automation may cause.

What is the potential risk if this is not contained?

This question needs to consider the potential impact and associated risk of not automating the containment. Many types of incidents do not require an immediate response. For example, detecting a port scan against an external asset does not necessarily pose an immediate danger, it just indicates that a malicious actor or automated tool is probing your infrastructure. Malicious activity in a test environment, providing that it is not used for research and development, will represent a lower risk than if the same activity is detected in a mission critical environment.

On the opposite end of the spectrum, if activity is detected in a critical or sensitive environment or targeting privileged users, or an attack in the latter phases of the cyber kill chain are discovered, automating the containment response may be highly desirable or even necessary to prevent the loss of a sensitive IP or a detrimental impact on operational integrity. Generally, the further along the kill chain an attack has progressed, the quicker the response must be, and the higher the need for automated containment.

The Safest Way to Automate Containment

One of the safest ways to approach and implement the automated containment of threats is to work with White and Black lists. These are used to identify threats and identify incident types, environments and infrastructure where automation is acceptable and desirable, or where it is absolutely not safe and permitted.

These lists will be adapted and amended as confidence in detection and automation increases and improves, and as the threat landscape, regulatory drivers and organizational priorities and objectives evolve.

For cases where the potential risk is high if the threat is not contained, however the detection and identification confidence is low and/or the detrimental impact if the automation goes wrong is high, semi-automated containment actions may be a better alternative than fully manual actions. Semi-automated actions (referred to as User Choice Decisions within DFLabs’ IncMan SOAR solution) pause the automated workflow, allow analysts to review the previously gathered intelligence, and make a human decision regarding the next appropriate course of action.

In contrast to a completely manual decision, a semi-automated decision contains two or more predefined paths for the analyst to choose from as appropriate, and allows the automated workflow to continue after the decision is made. In the case of containment actions, a semi-automated decision may be used to allow an analyst to view previously gathered intelligence on the source and destination of malicious network traffic. The analyst can then manually determine if blocking the external host or internal asset is necessary and most appropriate course of action to take.

Get Started with a One-to-One Personalized Demo

Dramatically reduce the mean time to detection, response and remediation of all potential security incidents, ensuring no alert goes untouched.

See IncMan SOAR in Action.

Request a demo