A framework of frameworks#
Fig. 2 UDEF#
This represents the entire, cumulative framework and consists of several sub-frameworks and intermediate steps, and it describes the overall end-to-end detection engineering process. While intended to be comprehensive, it is possible that certain components may feel left out, especially dependent on your interpretation; however, this represents the most prominent steps in the most common processes.
Data and Posture Baseline Lifecycle (DPBL)#
This stage is all about establishing as much understanding about the normal or starting state of the environment — like its data and defensive posture — as well as the baseline for industry threat coverage. It is just as important to establish repeatable procedures for accomplishing these tasks, including safely storing and retrieving the data and findings.
An additional supplemental step to help bolster the data and understanding includes hunting for outliers and unknown threats. This also allows for taking a less biased or influenced approach by focusing on generic threats or outliers (malicious and benign). It is a way to control tendencies to over focus on assumptions.
Research and Capability Development Scoping (RCDS)#
A significant amount of time spent on planning tends to be around scoping to specific outcomes, such as addressing emerging threats, satisfying product gaps, or enabling new product features. Additionally, because security features are often layered across disparate technologies such as endpoints, cloud workloads, an ecosystem of integrations, and ultimately any datasource logged to a SIEM, scope has the potential to essentially be unbounded.
The RCDS breaks down the factors that should be considered into six categories. These categories have the flexibility and resiliency to be applicable to just about any organization, operation, or threat landscape.The goal of using this is to determine the most appropriate scoping of efforts and focus, while predicting the best value outcomes for these decisions.
Detection Capability Development Lifecycle (DCDL)#
This should feel similar to the traditional Software Development Lifecycles (SDLC) or other Rule Development Lifecycles
(RDL), because it is deliberately intended to and where it originally evolved from. The DCDL initially started out as a
Rule Development Lifecycle, but evolved for multiple reasons. First off, RDL’s seem overused and under-representative of
what the focus of the lifecycle actually represents. This lifecycle is meant to be applied beyond typical rules or
detections. “Capabilities” is a much more accurate term to represent some of the targeted outcomes, which include:
Detection logic (actual or pseudocode)
Detection rules
Prevention rules
Signatures (YARA, atomic indicators, etc.)
Tools to detect or simulate
TTP’s for hunting, triaging, or incident response
Research and reports
Other capabilities
A significant amount of time is often spent within this lifecycle, which is even more reason to focus on it as a standalone framework within UDEF, allowing it to be fine tuned to the specific application and interpretation of it. It is especially relevant to any teams developing and maintaining large sets of security artifacts.
Threat Research Lifecycle (TRL)#
The primary benefit of formalizing the research process is intended to provide value beyond just conducting the best possible research, but is aimed at truly operationalizing it as a process, while standardizing sharing and preservation.
The role of threat research can vary significantly across detection engineering, with some focusing purely on third or first party research, or possibly outsourcing it completely. Regardless, whether the research occurs within the formal bounds of defined detection engineering teams or not, the same principles apply. Additionally, research plays a very important role in successful detection engineering.
TRL, which is technically a sub-component of the DCDL, focuses on the pragmatic and natural flow across the research process, with explicit steps broken down to emphasize opportunities for improvement and advancement.
Detection Engineering as Code (DEaC)#
This is the gold standard for fully adopting a systematic approach to operationalizing detection engineering. This becomes more achievable with greater maturity and standardization across all of the other steps. Eventually, everything will be built on a foundation of automation, optimizing all processes along the way.