Detection as Code
A guide for detection engineers to establish their workflows & methodologies
The threat landscape is constantly evolving at a pace that challenges detection engineers to keep up and develop robust detection rules. Threat actors don’t stay stable and are developing their techniques and tooling regularly. This situation creates the need for detection engineers to approach the development of detection rules in a similar manner and to establish processes and procedures that will enable the quick development and maintenance of rules with high fidelity.
Detection Engineering is a new domain in terms of security. Since it involves the development of code to identify cyber security threats, software development approaches could be adopted to resolve various challenges. Detection as Code has some key benefits such as:
Centralization of Detection Rules
Easier to Read and Maintain Code
Approval Process
Version Control
Easy to Share & Collaborate
The diagram below visualizes what Detection as Code is and the stages involved:
Typically, the detection engineer should receive a notification about a new threat directly or via another team such as Purple Team or Threat Intelligence. The detection engineer should write the detection rule based on the information shared and push the code into a repository that contains all the detection rules. The new detection rule is then pushed to the SIEM or EDR via the utilization of an orchestration technology. The following diagram displays some of the associated technologies and tools which could be used in the workflow.
CI/CD Workflow
At a very high level the continuous integration and code development (CI/CD) in detection engineering consists of six different stages. Initially, the detection engineer uploads the detection code to the repository (Commit). The detection rule is then converted from the generic schema to the specific language used by the organization. Some SIEM’s require the custom detection rule to be packaged into a specific extension (i.e. Splunk → .spl). Upon successful deployment to the non-prod SIEM a notification is triggered to the relevant teams. Detection rules must be validated manually and automated (if possible) to provide confidence about the efficiency and identify any gaps which the rule doesn’t cover. Once the detection is validated it is pushed for deployment in the production version of the SIEM.
Commit Detection
The lack of standardization is a common problem in detection engineering. Even though some SIEMs are more popular in the market compared to others still detection engineers they have to face challenges such as differentiation in syntax across different SIEMs and changes in defensive technologies. Detection engineers must determine the schema language they will use to build new detections. Sigma provides a universal method to write detections, code is easily read and maintained and it is product agnostic. Leveraging a code repository for commit detections enables multiple detection engineers to work on the same code without affecting the work of the other, allow tracking code changes (what was modified, by whom and when) and version of code.
Convert & Package Detection
Using a common schema to write detections like YAML enables detection engineers to convert them into SIEM format. The danger of writing detection rules directly in the format of the SIEM (Splunk, Elastic etc.) is that in an event where the organization decides to switch products developed detection rules will be invalid and the custom rule set will need to be rewritten from scratch. More specifically, utilization of SIGMA which rules are following a YAML extension can converted to a Splunk query like the query displayed below:
source="WinEventLog:*" AND index="wineventlog" AND EventCode=4688 AND (New_Process_Name="*\\reg.exe" OR New_Process_Name="*\\regedit.exe" OR New_Process_Name="*\\regedit32.exe") AND (Process_Command_Line="*WDigest*" OR Process_Command_Line="*password*" OR Process_Command_Line="*sam*" OR Process_Command_Line="*UseLogoCredential*" OR Process_Command_Line="*SecurityProviders*" OR Process_Command_Line="*CurrentControlSet*")The above query could be packaged into the format which Splunk uses .spl for execution at regular time periods.
Validate Detection
A detection lab environment that mimics production is ideal for validating detection mechanisms. Detection engineers are required to have full control over the systems during the validation stage to monitor the attack flow and re-adjust the detection rule if necessary. In the initial phase, detection engineers can independently validate a detection. However, according to Detection Rules Development Framework utilization of the Red Team (internal or external) can bring an independent eye toward the validation process and minimize any detection rule gaps. In the validation phase, it's crucial to determine whether any executions could prevent the alert from being triggered (evasion) and to document these instances. The following diagram visualizes the detection rule validation flow:
Deployment
Once the rule has been validated it should be deployed in the SIEM. Some SIEMs necessitate that detection be formatted in a particular way (i.e. .spl for Splunk), forked from a Git repository and via REST API if it is cloud-based. Packaging a detection consists of multiple configuration files which are uploaded directly into SIEM. Similarly, detection rules can retrieved and pushed directly from a Git repository or from a specific API if cloud micro-services are used as part of the CI/CD pipeline.