About Detection Engineering
In recent months I’ve noticed several attempts to define the term detection engineering and thought I should share my thoughts on this topic in a short blog post.
This blog post tries to cover all possible purposes of detection engineering to develop a broad definition of the term, excluding only a few borderline areas.
The Scope of Detection Engineering
The term detection engineering is usually immediately associated with security monitoring. Security monitoring is often defined as the collection and analysis of events. These events describe the activity of programs and users.
However, detection engineering is by no means limited to the detection of events (activity). It also includes detecting conditions (states), often used in digital forensics or incident response.
- Activity: adding the guest account to the local admin group
- State: the guest account is a member of the local admin group
I’ve also identified three different categories of detection targets.
- Threats or possible threats
e.g., malware, hack tools, attacker activity, backdoors, etc. - Anomalies, deviations from the usual
e.g., user activity at unusual hours, uncommon traffic patterns, extraordinary file locations - Items of special interest
e.g., name of a suspect, contents of stolen data, policy violations, breaches of the law
Areas of Detection Engineering
In the past, detection engineering has been only an incidental activity carried out by threat researchers, malware analysts, security monitoring analysts, incident response consultants, or digital forensic analysts.
As mentioned before, the most prominent association is with security monitoring.
- Detection engineering in security monitoring
e.g., application of IOCs on log data; transforming information about threats into SIEM queries, Sigma rules, - Detection engineering in incident response
e.g., enriching IOCs and creating YARA rules to detect the adversary’s toolset in disk images or target systems (see my blog post for details) - Detection engineering in malware analysis
e.g., extracting IOCs and creating a YARA rule as part of a malware analysis report - Detection engineering in threat intelligence
e.g., the creation of YARA rules to track an actor’s toolset/phishing documents in online platforms like Virustotal - Detection engineering in digital forensics
e.g., creation of YARA rules to detect specific case-related keywords (name of the victim, content of exfiltrated data); creation of a list with case-related keywords
The following graphic shows the role of detection engineering in relation to other roles within the detection and response ecosystem.
Definition
In my previous blog post about detection engineering in digital forensics for incident response, the definition I provided focused only on the first of the three targets (threats or possible threats).
Detection engineering transforms information about threats into detections.
A broader definition that focuses on the activity and encompasses all possible targets would be:
Detection engineering transforms an idea of how to detect a specific condition or activity into a concrete description of how to detect it.
This detection logic can be a pattern, a rule, a program code, or a textual description. The result of detection engineering can be a textual description written to be interpreted by a human or a machine-readable description of the detection logic. (better: machine-actionable)
Open Questions
Is it the detection engineer’s job to ensure the correct data collection?
Tim Brown asked if the work of a detection engineer also includes:
- Data generation (e.g., audit policies, scripts that evaluate states)
- Data collection (e.g., log forwarding, data conversion)
- The selection of appropriate mechanisms to apply the detection logic to the telemetry (e.g., select/build an engine that applies detection rules)
I tend not to include this kind of task in the definition of detection engineering. A detection engineer can undoubtedly provide information on the data required to carry out his work, yes, but is that specific task detection engineering? I’d say “no”. A detection engineer may have to do or help with these tasks, but that doesn’t mean they can be called detection engineering.
Frequently Asked Questions
What about results that are not machine-readable?
Sometimes people argue that the result of detection engineering must not be in a machine-readable or machine-actionable form. They say it cannot be a textual description of what a human analyst must do to detect a specific activity or condition.
The term engineering is defined as:
Engineering is the study of using scientific principles to design and build machines, structures, and other things, including bridges, roads, vehicles, and buildings.
So it is specific about the activity but not about the outcome.
From my point of view, this still can be considered detection engineering because the common understanding of the term engineering doesn’t include any specifications about the results of the engineering work.
What about Machine Learning?
I’m unsure if I’d like to include models created by machine learning algorithms in this definition because the algorithm would be the detection engineer.
I guess the question is very similar to “is a machine that was trained to paint pictures based on keywords an artist?”. If the answer to that question is “yes,” then the creation of machine learning models can also be seen as detection engineering and the machine as a detection engineer.
In this case the the learned models would also be a result of detection engineering.
Can the creation of a simple query be considered detection engineering?
Yes. Why not? It’s basic but fits the description as long as it is saved to be reused or shared. Detection engineering doesn’t mean that the work or the outcome has to be complex or sophisticated. Some detection engineers write dozens of simple detection queries daily; others work days to create a complex rule. It makes no difference. Simple art is still art.
How does closing detection gaps fit in?
It depends on the gaps and the way they’re closed.
E.g., if your detection engineers try to figure out ways to detect LSASS process dumping attacks because you currently have no coverage for this technique, they could do the following:
- Detect the usage of well-known process dumpers (based on file names, imphash, hashes)
- Detect a suspicious access request to the lsass.exe process based, e.g. on the access flags or the source image that requested the access
- Detect access from a process that never has accessed lsass.exe before or not with the same access flags
In case 1. they would create a detection for a “threat”, and in case 2. they would create a detection for a “possible threat”, and in case 3. they’d create a detection for an “anomaly”.
Conclusion
The definition of detection engineering is still debated and should be considered work-in-progress. The blog post aimed to provide a broad perspective and serve as a starting point for future discussions.
I’ll likely update this blog post frequently whenever someone adds new aspects to the discussion or highlights flaws in my reasoning.
