The Model(s) of D.E.A.T.H & Thrunt

There Can Only (Not) Be One

We often talk about thrunting (threat hunting) & DEATH (Detection Engineering and Threat Hunting) in different perspectives, but these are also applicable to the organization of the teams. As much as we would like a universal structure and order to Thrunt and DEATH teams, not every organization will standardize or subscribe to one model for an entire umbrella of business reasons. What should be illustrated here are the variety of models that are available to you in terms of thrunting and DEATH. We will outline each and provide a succinct example, but not include pros/cons.

I’ve had experience in each of the three constructs, and there is a good chance in your thrunting career you would experience one or more of these models.

Model 1: Universal Analyst (Unithrunt Model)

The Universal Analyst, or as I like to call it Unithrunt, is a model where Security Operations Center (SOC) analysts conduct alert review as well as hunt activities. Because these skill sets are complementary in nature, experience benefits are accrued for each of them. This model is standard amongst the following types of organizations:

• Smaller organizations

• Orgs with a higher baseline skill level

• Orgs with strong detection and signature development capabilities

The challenge with the Unithrunt model is that while you empower the lone analyst to learn a plethora of knowledge, the other responsibilities and job duties may take away from optimal threat hunting time and contribute to accelerated burnout. There are only so many thrunt and DEATH activities a universal analyst can accomplish. From my experience, a third of the time should be dedicated to the following categories:

• Threat research

• Learn new skills (can be offensive or defensive in nature)

• DEATH

Model 2: Organizational Model - Hunt Team Thrunt

The second model is one we see often in organizations- a dedicated thrunt or DEATH team (if the organization is mature enough to accommodate a detection capability). This team exclusively exists to hunt (and build detections, if mature enough). The team can be small (which is relative, depending on organizational size) and comprised of highly experienced analysts (Tier 3s and 4s). This model is common amongst:

• Large organizations

• Government and defense

• Department of Defense Cyber Protection Teams

One of my best hunters who was misaligned in a role had this to say when the Threat Intelligence team had the Threat Hunt team reporting to them:

“Threat hunting is proactively looking for evidence of a compromise within your environment where detections may not exist. This is both a counterpart and extension of detection response and is a critical part of a successful security operations program. You need people to respond to alerts and people looking for existence of a compromise where alerts may not have coverage.

Threat Intelligence is the gathering of intelligence from external sources and working with the appropriate parties to warn them and mitigate against threats as well as brief the relevant parties with information they need to make decisions.

Threat hunting can utilize threat intelligence, however they are separate processes with separate functions and the combining of the two under one or the other indicates a foundational misunderstanding of the roles and responsibilities of each of the teams.”

The danger of misaligning Thrunt teams is reducing efficiency, creating potential siloes and diluted priorities. Detection Engineering should be blended with this as it is the other side of thrunt. When you separate both from one another, if not done correctly, it creates a major inefficiency within the organization. Some organizations have a dedicated detection engineering team, but this team would be a partner team with the thrunt team reporting to the same leadership chain. In that vein, the teams can work independently and in synchronization as well.

Model 3: Organizational Model - Expedition (The Thrunt/DEATHfari)

Source: HuntOps

The last of the models to discuss is the Expedition-based hunting or DEATHFARI. In this model, core security operations analysts are periodically pulled away from alert review to form small, task-oriented hunting groups. For this model to succeed, a requirement is to have a clear plan of what you want to hunt for on a given mission. On the detection engineering side, it would be the same with the exception of it being what detection you want to create and what does the end state look like. Model 3 is common among:

• Well organized large security teams

• Organizations with no formal security team

The challenge often faced with this model is the interruptions. Interrupting thrunting or DEATH often creates disconnects in analysis as well as anomaly flow awareness. General research shows that the worst time to interrupt anyone is when they have the highest memory load. These disconnects hamper learning, pivots, reporting and other critical inflection points during thrunting and detection developments. A good rule of thumb is to plan to hunt in 2-3 hour intervals for optimal analysis with ample time to take a break, recharge then return to the dataset at hand.

This is by no means an exhaustive list and there may be additional models of thrunting that have evolved since my time in the trenches. There is no one optimal model since the needs of the business you would be working for will vary. It comes down to executive perception, budget, resource allocation, and how much value (past, present, and future) the team(s) would bring to the organization. It is important to remember, as a generalization, you will have to consistently demonstrate the value of thrunting or DEATH to leadership; it is a continuous process.

Long live the thrunters and D.E.A.T.H. dealers