Detection Maturity Level Model

The Detection Maturity Level (DML) model is a capability maturity model for referencing one's maturity in detecting cyberattacks. It's designed for organizations who perform intel-driven detection and response and who put an emphasis on having a mature detection program. Two of the key principles driving the establishment of this model are:

  1. The maturity of an organization is not measured by its ability to merely obtain relevant intelligence, but rather it's capacity to apply that intelligence effectively to detection and response functions.
  2. Without detection, one has no opportunity to respond.

Pasted image 20230214194512.png

DML-8 Goals

Goals are nearly impossible to detect (directly) but they're almost always the toughest question C-level leaders ask about post-breach. "Who was it and why?" These kinds of questions can never truthfully be answered unless you're operating at Detection Maturity Level 8 against your adversary and can prove reliably that you know what their goals are.

DML-7 Strategy

If the adversary's high level goal is to "replicate Acme Company's Super Awesome Product Foo in 2 years or less" their strategies might include:

  1. Implant physical persons into the companies that produce this technology, in positions with physical access to the information necessary to fulfil this goal.
  2. Compromise these organizations via cyber attack, and exfiltrate data from the systems containing the information necessary to fulfil this goal.

For less targeted attacks, the strategy may be completely different, with shorter durations or different objectives.

DML-6 Tactics

To successfully operate at DML-6, one must be able to reliably detect a tactic being employed regardless of the Technique or Procedure used by the adversary, the Tools they chose to use, or the Artefacts and Atomic Indicators left behind as a result of employing the tactic.

DML-5 Techniques

From a maturity perspective, being able to detect an adversary's techniques is superior to being able to detect their procedures. The primary difference being techniques are specific to an individual. So when respecting this distinction, the ability to detect a specific actor operating within your environment by technique exclusively is an advantage.

Note

It should be noted that although it is tougher to detect the specific techniques employed by an adversary, when it comes to detection the broader approach of detecting and covering full tactics provides more value.

DML-4 Procedures

In its most simple form, detecting a procedure is as simple as detecting a sequence of two or more of the individual steps employed by the actor.  The goal here is to isolate activities that the adversary appears to perform methodically during an incident.

An example of this would be an adversary systemically connecting to the victim's systems one by one performing directory listings, and dumping those results to a file that is later extracted and exfiltrated.

DML-3 Tools

Being able to detect at DML-3 means you can reliably detect the adversary's tools, regardless of minor functionality changes to the tool, or the Artefacts or Atomic Indicators it may leave behind. Detecting tools falls into two main areas:

  1. Detecting the transfer and presence of the tool.

    This includes being able to observe the tool being transferred over the network, being able to locate it sitting at rest on a file system, or being able to identify it loaded in memory.

  2. Detecting the tool by functionality.

    For example, let's take a given webshell that has 25 functions. If we want to claim DML-3 level detection for this webshell we have to exercise each of those 25 functions and understand what each of them do. We then aim to build detections for as many of those 25 functions across those data domains as we possibly can, reliably, balancing false positives and other constraints. The reason behind this is simple, we want to be able to detect this version of the tool and as many future variants of the tool as we can by the function that it performs.

DML-2 Host & Network Artefacts

DML-2 is where most organizations spend too much of their resources; attempting to collect what they call "threat intelligence" in the form of Host & Network Artefacts.  The reality is, these are merely just indicators that are observed either during or after the attack. They're like symptoms of the flu, but not the flu itself.

Host & Network Artefacts are still important, but they should be thought of as the individual building blocks that support our work at the higher levels.

DML-1 Atomic IOCs

These are the atomic particles that make up Host & Network artifacts.  If you're detecting at Detection Maturity Level 1, it means you are probably taking "feeds of intel" from various sharing organizations and vendors in the form of lists, like domains and IP addresses, and feeding them into your detection technologies.

There are a few, and I mean a very precious few, circumstances where this makes sense and can be done reliably.  These are edge cases where specific atomic indicators have a high enough "shelf life" where it makes sense to go ahead and create detection capabilities from them.  Examples of this include unique strings found inside a binary, or perhaps an adversary is foolish enough to sit on the same recon, delivery, C2, or exfiltration infrastructure allowing you to detect reliably on their domain names or IP addresses.

DML-0 None or Unknown

For organizations who either don't operate at DML-1 or higher, or they don't even know where they operate on this scale.[1]


Relevant Note(s): Detection Engineering Tactics, Techniques & Procedures


  1. http://ryanstillions.blogspot.com/2014/04/the-dml-model_21.html ↩︎