What is Detection Engineering as Code?

Fig. 45 Detection Engineering as Code Composition

A significant benefit of formalizing operations around processes and a framework is that it becomes much more compatible and easier to automate recurring tasks and workflows. This is exactly what is meant by Detection Engineering as Code being foundational to automating everything, as maturation improves. DEaC is meant to encompass all considerations for automation integration, however, the two specifically called out are DaC and operationalizing telemetry. These two do not cover all automation use cases within DEaC, but account for the primary use cases.

Fig. 46 Relationship between maturity and DEaC adoptability

This chapter will dive deep into the detections-as-code paradigm, but we will first briefly explore what DEaC is and what it means at a high level.

Automation doesn’t necessarily need to mean standalone code for every unique process, but rather, it should take advantage of the representative technology stack and architecture. For instance, your SIEM platform may allow storing queries and running them as scheduled jobs (not rules), which can be leveraged to perform continuous mini snapshots of the environment to keep refreshed baselines.

You may also have some sort of Security Orchestration Automation and Response (SOAR) platform, which will take several layers of abstracted definition files across many languages.

Telemetry observations and feedback also have a lot of room for automotive integration. There is a lot of redundancy across these processes, such as exporting, creating a case, adding context, labeling, and assigning, to name a few. Automating out that workflow makes the consumption and processing of raw telemetry significantly more efficient. This will be the focus of chapter 8, where operationalizing telemetry to make data driven decisions will be explored.