Detection as Code: How To Embed Threat Detection into Code

Like many concepts at the intersection of software engineering and cybersecurity, threat detection has emerged as a recent candidate to adopt the ‘as-code’ discipline to detection. This is driven by two key factors:

• The growing need for organizations to streamline the threat detection process — especially as your infrastructure and tooling portfolio grows exponentially. 
• The increasingly convoluted dependencies and software-oriented infrastructure instances are, at best, difficult to manage.

Detection as Code is a new paradigm that brings a structured, systematic and flexible methodology for threat detection inspired by the as-code best practice of software engineering, commonly adopted in DevOps and Agile software development frameworks. 

But it is more than just translating bulky threat detection tools into programmable commands — let’s take a look in this article. 

What is “Detection as Code”? 

Detection as Code looks to communicate at the machine level, and it presents a systematic and flexible way to do so. It is treated as a code-script. That means it can incorporate: 

• QA best-practices for source and version controls
• Peer reviews
• Monitoring and alerting for changes

Perhaps most importantly, detection as code enables you to adopt rapid changes based on real-time performance indicators.

Similar to the DevOps implementation of QA and Infrastructure Operations best practices — including CI/CD, continuous testing and Infrastructure as Code (IaC) — Detection as Code (DaC) can also be characterized by several flavors. In fact, every organization can have their own preferences for deploying a DaC mechanism. 

Components & characteristics for DaC systems

So where do you start? Let’s review the key characteristics that serve as a foundation for modern Detection as Code systems:

Machine-readable definitions

The rules that govern threat detection should be represented in a systematic format that is well understood by automation systems at the machine level. The syntax and structure should allow users to write holistic rule definitions, which cover all aspects of the threat detection policies. 

With this approach, DaC can be used as part of an existing codebase that communicates well with all third-party tools and services.

(Are you a Splunk user? Get free Splunk Enterprise Security content updates, including 1,300+ Splunk-build detections and nearly 200 analytics stories.)

Versioning

Keep track of rule versions and reverse changes to previous operational states when a code change uses outdated or misconfigured policies. Versioning also allows users to make these changes frequently, document and review them systematically. Versioning is also important to track how alerts respond to specific rule definitions, as well as gaining more context into the rules and policies that are attributed to the alerts.

QA

The log-data deluge can trigger an endless number of alerts and false-positives — which can hide impactful alerts and false negatives. This requires any Detection as Code implementation to undergo thorough QA testing. For extensive rules definitions, you should:

• Focus on QA for internal and external dependencies.
• Eliminate blind spots as your network scales.

(Uncover & eliminate blind spots with end-to-end observability.)

Shift-left detection

In order to improve the capacity for proactive threat detection, integrate DaC early during your software development cycle (SDLC): this is known as shifting security to the left (earlier) in the lifecycle. It’s also called shift-left for short. 

Create a CI/CD pipeline that allows you to eliminate threat detection silos: the security policy enforcement should act uniformly and consistently across all network zones and functions. Automate these pipelines and ensure the workflows adopt the collaborative development and testing best practices from your DevOps framework.

Modularity

Your detection code should be reusable, modular and easy for cross-functional teams to work together toward creating a holistic detection as code repository. 

These modules can be developed and tested separately by multiple teams to evaluate performance against business metrics, and a version control system integrates the DaC implementation to the most acceptable and effective version.

Embedded DaC into code

Any standard machine-readable format for DaC can be adopted — the specifications should align with open standards as well as the specifications of your existing third-party solutions. This allows Devs, QA and security teams to work collectively toward embedding threat detection capabilities into the codebase. The practice may involve:

• Additional logging and monitoring protocols, where necessary security logs are captured at the time of feature execution or the application layer. 
• Security instrumentation schemes to collect data on the nature of requests at the Network layer level.

(Understand the network layer, application layer, and the other 5 layers in the OSI networking model.)

Metrics

Detection as Code allows users to track a variety of metrics that help improve detection performance and security posture. The common metrics include:

• Detection coverage
• False positive/negative rates
• MTTR/MTTD 
• The effectiveness of detection with specific rules, signatures and definitions

Test driven development

DaC can further capture insights into the strategy of threat actors and evaluate how existing metrics perform against a variety of risk levels. 

The Test-Driven Development (TDD) strategy allows security personnel to understand the end-to-end cyber-attack lifecycle, evaluating how their threat detection mechanism reacts at different stages of the attack and make improvements necessary to discover the attack at earlier stages of this lifecycle.

Can everything be code?

Following the paradigm of Infrastructure as code, the emerging discipline of Detection of Code appears to be an evolution to express and implement Everything as Code. When all artifacts of a system – such as threat detection policies and functions – are treated as artifacts, it becomes easier to code the programmable mechanism (threat detection, for instance) as highly scalable, systematic and agile.