Many security teams, especially those in larger enterprises are adopting “Detection-as-Code” to automate their Detection Engineering workflows. Detection-as-Code is a set of principles that use code and automation to implement and manage threat detection capabilities in an agile Continuous Detection/Continuous Response model. Managing detection rules “as code” offers benefits such as enhanced collaboration around changes to detection rules and robust change management and auditing practices.
Google Security Operations (SecOps) provides security teams with the flexibility of managing their detection rules within the user interface (UI) and as code via its API. In this two-part blog series, I’ll share my knowledge gained from building Detection-as-Code pipelines at multiple companies and demonstrate how organizations can get started with deploying and managing their detection rules as code with Google SecOps. I’ll also highlight some useful features of the UI along the way such as managing previous versions of a rule.
I'm going to use our Content Manager tool for this implementation, which can be customized to meet your needs. The readme file contains instructions for configuring and using the code.
Example Detection-as-Code Workflow
The image below shows an example Detection Engineering workflow that a team can use for managing their detection rules as code in a software development platform like GitHub or GitLab. In this example implementation, there are jobs configured in a CI/CD pipeline to handle the testing and deployment for rule changes.
Some larger enterprises that are subject to strict auditing may even disable access to edit detection rules in the UI of their SIEM and ensure that all rule modifications go through a review & approval process before they’re deployed. We won’t be disabling access to edit rules in Google SecOps’ UI for this project however, as it has some powerful features that are easy to use.
What are the Benefits of Detection-as-Code?
Let’s review why some security teams choose to manage their detection rules as code and the benefits of doing so before diving into the specifics of managing rules in Google SecOps via the UI and API.
Collaboration Around Changes
When changes are made to a rule by an individual in the UI of a security tool, the context and reason for the changes is sometimes lost and mistakes can happen that lead to false negatives. In a typical Detection-as-Code workflow, a Detection Engineer will create a pull request in GitHub/GitLab that contains their proposed changes. Example changes include creating new rules or updating existing ones.
After the engineer submits their pull request for review, it’s easy for team members to discuss and collaborate around the proposed changes before they’re approved and deployed to production. A group of practitioners with unique insights working together will result in more accurate and effective threat detection rules.
Detection-as-Code also makes it easier to share detections with other people in the cybersecurity community leading to a stronger defense against attacks. For example, we have a collection of YARA-L detection rules that you can load into Google SecOps and customize to fit your organization’s environment. As a reminder, these rules aren’t considered production ready for every environment. Google SecOps provides a test rule capability that should be used when validating and tuning rules. You can read more about that in our community rules blog post.
Automation
CI/CD tools are used to ensure a continuous and iterative process to build, test, and deploy changes to the security team’s detections while minimizing bugs and the risk of introducing false positives/negatives. For mature teams, new detection capabilities can be rolled out quickly and efficiently using automated workflows.
Change Management
Security teams who store their detection rules in a platform such as GitHub or GitLab can configure certain settings to have more control over how rules are modified. For instance, any changes to rules can be prevented unless a set of tests complete successfully and peer review & approval is obtained. The history and context around changes is preserved for future reference and any audits that the organization must comply with.
Agility
With a DAC CI/CD pipeline, security teams can respond to emerging threats quickly by creating or modifying detection rules and having them tested and deployed with zero (or minimal) manual effort required.
Managing Detection Rules via Google SecOps' API
In this example project, I’m going to store my detection rules in a GitHub project and configure GitHub Actions workflows to manage the testing and deployment of rule changes via Google SecOps’ API. My example GitHub Actions workflow configuration files can be found on GitHub.
As per the Google SecOps API documentation, there are various methods that can be used to manage rules. For example, the rules.create method is used to create a new rule and rules.patch can be used to create a new version for an existing rule.
Content Manager can be customized to meet your requirements and comes with a simple CLI that can do the following:
- Pull the latest version of all rules from Google SecOps and write them to local files.
- Update remote rules in Google SecOps based on local rule files and a rule config file.
- Verify that a rule is a valid YARA-L rule without creating it or evaluating it over log data.
- Manage other content in Google SecOps such as data tables, reference lists, and rule exclusions.
python -m content_manager rules --help
03-Jun-25 07:42:13 MDT | INFO | <module> | Content Manager started
Usage: python -m content_manager rules :OPTIONS] COMMAND tARGS]...
Manage rules.
Options:
--help Show this message and exit.
Commands:
get Retrieve the latest version of all rules from Google SecOps and
update local files
test Test a rule in Google SecOps without persisting results.
update Update rules in Google SecOps based on local rule files and
config.
verify Verify a single rule file is a valid YARA-L rule.
verify-all Verify all local rules are valid YARA-L rules.
Please note, a prerequisite for managing rules (and other features in Google SecOps) via the API is to link your customer-supplied Google Cloud project to your Google SecOps instance. Please reference the onboarding or migrating a Google SecOps instance documentation for guidance and reach out to support if you require any additional assistance.
Syncing Rules Between Google SecOps and GitHub
In order to keep my GitHub repo updated with the rules that are currently in Google SecOps, I’ve configured a GitHub Actions workflow (Pull Latest Content) to run on a schedule. The job pulls the latest version of all rules from Google SecOps and commits any changes to the main branch of the project.
If you’re implementing this in a production environment, protect the main branch of your project to prevent anyone making rule changes without first creating a pull request and going through your team’s review and approval process.
The images below show what it looks like when the GitHub Actions workflow runs. This workflow makes use of Content Manager's "rules get" command and has some additional steps in it to commit changes to the repo.
In the output from the workflow below, we can see that the retrieved collection of rules are written to files in the rules folder in the format rule_name.yaral. The configuration and metadata for the rules is stored in a file named rule_config.yaml.
After the latest rules are pulled from Google SecOps, the workflow commits any changes to the rules or rule config file to the main branch of the GitHub repo.
The images below show an example commit that was made from the GitHub Actions workflow. The changes in this commit show that someone created three new rules in Google SecOps. We can also see that an entry has been created for each rule in the rule_config.yaml file.
You can configure this workflow to run on a schedule to keep your version control system up to date with the latest version of rules that are in Google SecOps. Alternatively, you can run this workflow once, on-demand to commit your detection content to your GitHub repo and going forward, manage your rules in Google SecOps via your CI/CD pipeline. That is what we are going to do in part two of this mini series.
Wrap Up
That’s it for part one of this blog series. In this post, we covered the following:
- The principles and benefits of managing detection rules as code as well as an example detection engineering workflow used by security teams.
- How to configure GitHub Actions workflows to pull existing detection rules via Google SecOps' API and commit them to a GitHub repo.
As a reminder, our Content Manager tool can be found in the chronicle/detection-rules repo on GitHub.
Thanks for reading. In part two, I’ll demonstrate how to create and modify detection rules via Google SecOps' API and a CI/CD pipeline. I’ll also explain the importance of testing as it relates to detection engineering.
Additional Reading
Check out the following resources if you’re interested in learning more about Detection Engineering and Detection-as-Code.
- Can We Have “Detection as Code”? — Anton Chuvakin
- Detection-as-code: Why it works and where to start — Kyle Bailey
- From soup to nuts: Building a Detection-as-Code pipeline — David French
- Automating Detection-as-Code — John Tuckner
- Detection as Code: Detection Development Using CI/CD — Patrick Bareiß, Jose Hernandez
- Practical Threat Detection Engineering — Megan Roddie, Jason Deyalsingh, Gary J. Katz
- Detection Engineering Weekly — Zack Allen