Threat Detection and Response (TDR) is a methodology that enables security operators to detect attacks and neutralize them before they cause disruption or become a breach.

In this first of a series of articles on the topic, we’ll be taking a step-by-step look at what TDR is all about, from the key components and investigative process, to why it matters. Subsequent articles will go through components in more detail.

Getting started with TDR

Why do we need it?

It is increasingly difficult for cybersecurity teams to identify, investigate and act on cyber threats across operating environments and to do so effectively and efficiently.

As the threat landscape has evolved, adversaries have become stealthier, implementing advanced evasion techniques to avoid detection by security technologies. They are also making widespread use of native operating system tools, or open source or freeware attack tools, which enable them to undertake their malicious activity without alerting the cybersecurity team.

Such attacks are often directed by human operators, able to test and try different options and move quickly in unexpected directions if they encounter an obstacle.

Threat hunters and analysts uncover these hidden adversaries by looking for suspicious events, anomalies and patterns in everyday activity and investigating them to see if they are malicious.

Their human insight is complemented by automated security intelligence technologies including AI-guided detection. Together, they form a strong line of defense in a layered next-generation security system.

Threat hunters and analysts don’t stop at finding the threat, they work with colleagues to mitigate and neutralize it. This is TDR.

The TDR framework

Cybersecurity borrows heavily from military concepts and TDR is no exception. For instance, the Sophos investigative framework for threat hunting and response is based on the military concept known as the OODA loop: Observe, Orient, Decide, Act.

This framework enables threat hunters and analysts to work in a consistent, structured way and ensure nothing is overlooked.

• Observe: what do you see in the data?
• Orient: what is the context, the behavior, how does it map against known attack tactics, techniques, and procedures (TTPs)?
• Decide: is it malicious, suspicious, or benign?
• Act: mitigate, neutralize, and re-enter the loop

In applying the framework stages, threat hunters and analysts build up a picture of what is happening inside the environment, determining whether it is malicious, and what action needs to be taken.

The five core components of TDR

There are five key components of TDR that underpin the various stages of the framework. Let’s consider each of them more closely.

1. Prevention

The first, and most important thing to do is to strengthen your defenses to prevent attackers from being able to penetrate your network.

Effective prevention involves knowing where your critical data and compute resources (the infrastructure that provides processing capabilities) live on the network and ensuring they are protected with competent security technologies that offer an array of protection options.

It is vital that you configure the technology properly; regularly and promptly apply updates; and tightly manage access controls, as all this will significantly limit the attack surface.

Having robust prevention technologies in place also reduces the number of security alerts that are generated on a daily or even hourly basis.

With fewer alerts to wade through, the security team is better able to spot and focus on the signals that matter.

2. Collection of security events, alerts and detections

Data is the fuel that powers threat hunting and analysis: without the right type, volume, and quality of signals it is incredibly difficult for security operations teams to accurately identify potential indicators of attack.

Yet data absent context complicates the analyst’s conviction decision. Without meaningful metadata associated to the signal, the analyst will have a harder time determining if the signals are malicious or benign.

The most common methods for collecting and reviewing security data are as follows:

EVENT-CENTRIC

The classic example of an event-centric approach is security incident and event management (SIEM).

SIEMs ingest and aggregate data points, such as log files, from different sources across the network. It is up to the SIEM operators to understand the context, determine what to filter, what to create correlation logic around and attempt to minimize and manually curate the data so they don’t overwhelm the investigation team, while balancing the miss-rate (also known as ‘false negatives’, where an actual threat is not detected as such).

THREAT-CENTRIC

In this model, signals are prioritized and used to programmatically create cases that are reviewed by analysts. In addition, threat hunts are performed based on intelligence trends and an attack hypothesis (see component (4), Investigation, below).

Signals need to be prioritized based on how actionable or useful they are for investigations and should indicate adversarial tactics, techniques and procedures (see component (4)).

Signals that more commonly result in the identification of adversarial activity should take priority over those that do not.

To set the criteria by which signals are deemed worthy of investigation, different algorithms or machine learning models can be applied that look at things such as behavior, raw data, attack vector, attack method and so on.

HYBRID

This is a combination of both event-centric and threat-centric methods. It relies on speed to detect, investigate and respond to data from both sources, and to supplement threat-centric detections and any resultant cases with correlated data from other event and telemetry sources. This approach is used most effectively by mature security teams.

THE ADVANTAGES OF EXTERNAL SUPPORT AS PART OF A HYBRID MODEL

Engaging an experienced external security team to help with data collection and detection frees up internal teams to be more strategic in their activity.

For instance, more time could be spent on enhancing prevention or reducing attack surfaces; or focusing on important business processes, applications, or assets, where the data and associated detections need to be customized and targeted.

External teams can also offer a wider perspective gained from defending a range of customers. They will have more experience with emerging threats and handling incidents that involve active adversaries.

Internal teams will know their environments better, but their “battlefield” experience will be less.

The important thing to remember is that the alerts themselves are not the endgame.

Often, you don’t initially know whether a signal is malicious or benign, and if it is malicious, where it fits in an attack sequence.

Are you seeing an alert at the beginning or in the middle of an attack? Did something happen prior to this event, or will something happen afterwards? You need to understand the context before deciding what course of action to take, if any.

3. Prioritization of the signals that matter

Threat detection is a critical component of security operations, but it is only the first of a multi-step, human-led process that includes validation, investigation (threat hunting) and threat response (neutralization).

It is important to remove friction between each of these activities. SIEMs and other log-based approaches typically lack the context needed to make well-informed decisions about where to focus attention, resulting in reduced time efficiency or even missed critical events.

To avoid being overwhelmed by data and failing to spot the items that warrant closer investigation, you need to be able to pinpoint the alerts that matter.

This is harder than it looks. The more you can improve signal-to-noise ratios by using a combination of context that only event producers can provide, together with automated and artificial intelligence, the better. Even with automation, it is not a simple process.

For instance, you need to be careful not to over-filter the data. In one case seen by our TDR team, a monthly log of two billion events revealed just three security incidents after all the filters had been applied.

4. Investigation

Once you have isolated the key signals, it is time to add insight, and to measure what you have discovered against industry frameworks and models to build towards a confidence threshold in the conviction of malicious or benign behavior.

These include the MITRE ATT&CK framework, a globally accessible knowledge base of known adversary tactics, techniques and procedures (TTPs), or Lockheed Martin’s Cyber Kill Chain model, which identifies the key steps adversaries attempt in order to achieve their objective.

This is the time to consider things such as:

• Where you’re detecting the signal
• Is this what you expected to see?
• Are there repeated patterns in the signals that look unusual?
• Is data moving in a typical direction or to a known/common device?
• And more…

The aim is to understand not just whether the signal is indicative of an actual attack, but where in the attack sequence it falls. You want to block the attack as early in the threat chain as possible.

The outcome of the investigation will hopefully enable you to decide: (1) if the signal is a known or potential attack indicator, and (2) what the unfolding attack process is likely to be.

This provides you with a hypothesis for proactive threat hunting across the network: you can test ideas and assumptions and anticipate what might happen next, making it easier to find and block the threat at any stage of the attack.

5. Action

This is a big one. Once you’ve determined that you are dealing with a threat, you need to do two things – and they are equally important.

The first is to mitigate the immediate issue, while the second is to remember that you are probably only addressing a symptom of the attack, and still need to hunt down and neutralize the root cause. The first must be done without impairing your ability to do the second.

Sometimes it will be enough to quarantine a machine or to disconnect it from the network, while at other times the security team will need to go deep into a network to extract the tendrils of an attacker.

For instance, just because you’ve successfully blocked and removed malware from your system and stopped seeing the alert that put you onto it, this doesn’t mean the attacker has been eliminated from your environment.

Professional threat hunters who see thousands of attacks know when and where to look deeper. They look for what else attackers are doing, have done, or might be planning to do in the network – and neutralize that too.