As security moves to the cloud, manual threat detection processes are unable to keep pace. This article will discuss how detection engineering can advance security operations just as DevOps improved the app development world. We’ll explore detection-as-code (DaC) and innumerate several compelling benefits of this trending approach to threat detection.
What is detection-as-code?
Detection-as-code is a systematic, flexible, and comprehensive approach to threat detection powered by software; the same way infrastructure as code (IaC) and configuration-as-code are about machine-readable definition files and descriptive models for composing infrastructure at scale.
It is a structured approach to analyzing security log data used to identify attacker behaviors. Using software engineering best practices to write expressive detections and automate responses, security teams can build scalable processes to identify sophisticated threats across rapidly expanding environments.
Done right, detection engineering — the set of practices and systems to deliver modern and effective threat detection — can advance security operations just as DevOps improved the app development world.
Similar to a change CI/CD workflow, a detection engineering workflow might include the following steps:
Observe a suspicious or malicious behavior
Model it in code
Write various test cases
Commit to version control
Deploy to staging, then production
Tune and update
You can see that the detection engineering CI/CD workflow is not so much about treating detections as code but about improving detection engineering to be an authentic engineering practice; one that is built on modern software development principles.
The concept of detection-as-code grew out of security’s need for automated, systematic, repeatable, predictable, and shareable approaches. It is essential because threat detection was not previously fully developed as a systematic discipline with effective automation and predictably good results.
Threat detection programs that are precisely adjusted for particular environments and systems have the most potent effect. By using detections as well-written code that can be tested, checked into source control, and code-reviewed by peers, security teams can produce higher-quality alerts that reduce burnout and quickly flag questionable activity.
What are the benefits of detection-as-code?
The benefits of detection-as-code include the ability to:
Build custom, flexible detections using a programming language
Adopt a Test-Driven Development (TDD) approach
Incorporate with version control systems
Writing detections in a universally recognized, flexible, and expressive language like Python offers several advantages. Instead of using domain-specific languages with too many limitations, you can write more custom and complex detections to fit the precise needs of your enterprise. These language rules are also often more readable and easy to understand. This characteristic can be crucial as complexity increases.
An additional benefit of using expressive language is the ability to use a rich set of built-in or third-party libraries developed or familiar by security practitioners for communicating with APIs, which improves the effectiveness of the detection.
Quality assurance for detection code can illuminate detection blind spots, test for false positives, and promote detection efficacy. A TDD approach enables security teams to anticipate an attacker’s approach, document what they learn, and create a library of insights into the attacker’s strategy.
Over and above code correctness, a TDD approach improves the quality of detection code and enables more modular, extensible, and flexible detections. Engineers can easily modify their code without fear of breaking alerts or weakening security.
When writing or modifying detections, version control allows practitioners to revert to previous states swiftly. It also confirms that security teams are using the most updated detection. Additionally, version control can provide needed meaning for specific detections that trigger an alert or help identify changes in detections.
Over time, detections must change as new or additional data enters the system. Change control is an essential process to help teams adjust detections as needed. An effective change control process will also ensure that all changes are documented and reviewed.
Security teams that have been waiting to shift security left will benefit from a CI/CD pipeline. Starting security operations earlier in the delivery process helps to achieve these two goals:
Eliminate silos between teams that work together on a shared platform and code-review each other’s work.
Provide automated testing and delivery systems for your security detections. Security teams remain agile by focusing on building precision detections.
Finally, DaC promotes code reusability across broad sets of detections. As security detection engineers write detections over time, they start to identify patterns as they emerge. Engineers can reuse existing code to meet similar needs across different detections without starting completely over.
Reusability is an essential part of detection engineering that allows teams to share functions across different detections or change and adjust detections for particular use-cases.
Every environment is different, and as a result, requires a different set of techniques for detections. Detection engineers need to create custom-tailored rules to adequately test, version, and programmatically manage version control. The flexibility and robust nature of an expressive programming language enables security teams to detect either advanced or straightforward behaviors in addition to context fetching, enriching, and telling the whole story of what happened.
DaC enables engineers to write flexible detections and provides the ability to create detections specific to the organization. Practitioners can structure and normalize logs into a strict schema for SQL queries and perform power investigations against large volumes of security data.
Detection-as-code (DaC) can now take its rightful place alongside Infrastructure-as-code (IaC) in the emerging idea of Everything-as-code (EaC), where across each layer of the stack, everything is expressed with code.