If you’ve ever been around security operations, you can probably relate to at least one of these:
These are just a few challenges teams experience when managing threat detection content. Detection-as-Code principles are the long-needed missing link that enables security practitioners to apply 50+ years of learnings from software engineering to the discipline of building and maintaining threat detection.
Detection-as-Code is the application of software engineering best practices to detection engineering. By adopting this new paradigm, teams can build scalable, repeatable processes for writing, maintaining, testing, and deploying detection content.
Threat detection is not a new concept. Detection and response teams have been around for decades though the term detection engineer is relatively new. Pre-2018, most organizations called the same position a “SOC use case analyst.” The scale at which detection and response teams must operate has changed. Teams face more data, more diverse technologies, and more advanced and tailored threats than ever, which drives the need for environment-specific, custom threat detection logic.
Anything that helps your organization detect threats can be considered detection content. We can categorize detection content into three major buckets: custom logic, vendor-defined logic, and end-users.
For the remainder of this article, we will focus on custom logic.
As a security practitioner, what would you do if you found out your org’s SREs were deploying the latest production code base by hand? That sounds crazy, right? Think about how you’ve deployed detection logic in the past, though. I would be willing to bet nearly everyone reading this has had to copy and paste logic into a SIEM or, at a minimum, made a change to production detection logic directly in your SIEM.
Over time these manual processes lead to inconsistent results. Many things can go wrong in this scenario because a human is too directly involved. These manual mechanisms for managing detection logic increases mistake leading to more false positives and fewer true positives.
The good news is that the industry is starting to recognize these problems, and vendors are providing native solutions to fix them.
Detection-as-code is a framework composed of five domains applied to detection engineering that help address the problems we have covered up to this point.
From the beginning, Panther was architected around detection-as-code principles. Because of this design, Panther natively provides workflows and tools that enable teams to easily integrate external systems like version control and CI/CD pipelines into their detection engineering processes. In addition, Panther uses Python to define detection logic and bundles pre-defined test cases with each detection use case in our public GitHub repo.
At a high-level the detection-as-code workflow in Panther looks like this:
Let’s walk through what it would look like to make a small change to an existing detection in Panther while following detection-as-code principles. The detection below will alert if the user deletes an S3 bucket:
from panther import aws_cloudtrail_success
from panther_base_helpers import deep_get
def rule(event):
# Capture DeleteBucket, DeleteBucketPolicy, DeleteBucketWebsite
return event.get("eventName").startswith("DeleteBucket") and aws_cloudtrail_success(event)Code language: Python (python)In this example, let us say we know the operations team will delete specific buckets. To prevent those actions from generating unnecessary alerts, we need to add an allowlist.
from panther import aws_cloudtrail_success
from panther_base_helpers import deep_get, pattern_match_list
ALLOWED_BUCKETS = [
"TEMP-*",
]
def rule(event):
# Capture DeleteBucket, DeleteBucketPolicy, DeleteBucketWebsite
if event.get("eventName").startswith("DeleteBucket") and aws_cloudtrail_success(event):
# Don't alert on buckets that we know will be deleted
if pattern_match_list(deep_get(event, "requestParameters", "bucketName"), ALLOWED_BUCKETS):
return False
# alert on all other buckets
return True
return FalseCode language: Python (python)A few notes:
Once the detection engineer has completed their change locally, they start by submitting a pull request to their Panther detection repo. Opening a pull request notifies team members that a review is needed, and the diff view in version control enables the reviewing engineer to identify the changes.
Tests and linting run automatically in CI validate that all detection logic is functional, which gives the engineers the confidence their changes won’t break production logic.
Finally, upon merging the pull request, the detection logic is automatically uploaded to Panther. A Panther maintained open-source tool called Panther Analysis Tool (PAT) enables CI/CD workflows. This command-line-based tool allows security practitioners to quickly leverage their organization’s existing CI/CD infrastructure for testing and linting their detection logic.
By following detection-as-code principles, security practitioners can make the lifecycle of detection content more consistent. Learn how, one of Panther’s customers, Cedar scaled their security program with detection-as-code.
Panther is a modern SIEM platform that solves the challenges of security operations at scale. Panther can analyze log data from hundreds of systems, including AWS, GCP, O365, G Suite, Crowdstrike, OSquery, and more. Check out a list of all our supported integrations. Request a personalized demo to get started. If you are interested in learning more about detection-as-code, ask us about a workshop in your area.
