TL;DR Detection-as-code increases the efficiency, effectiveness, and collaboration of security teams. Use Python to create detections and manage them using the command line interface; or use a selection of non-code tools to create and manage detections with Panther, and still benefit from detection-as-code.
Soon you’ll learn that creating a code-based detection is remarkably straightforward. You’ll understand how to manage coded detections using the command line interface (CLI) and version control, both of which are hallmarks of detection-as-code.
But this blog also explains how teams with diverse skill sets can benefit from detection-as-code without knowing how to code or use the CLI. This enables cross-functional teams—developers, security practitioners, leadership, and operations—to have the tools to collaborate on detections and develop more effective security coverage.
Let’s start with the basics.
Detection-as-code is the practice of creating detection rules using programming languages, such as Python, and managing them through version control systems like GitHub. This approach aligns with other ‘as-code’ methodologies—such as infrastructure-as-code—which aim to make processes consistent, scalable, portable, and auditable. In the field of information security, DaC extends these advantages by injecting flexibility and customizability into Security Information and Event Management (SIEM), effectively addressing the common challenges faced by practitioners: ease of use, accuracy, and comprehensive coverage.
Here are the key benefits of detection-as-code:
In Panther, a code-based detection is created using two files: a Python file (rule.py) that contains the detection logic and a YAML file (rule.yml) that contains the metadata for the detection. Here’s an example of the basic rule structure from the Panther docs:
These two files make up a single detection rule:
Now let’s get into the syntax.
To create a detection rule in Python, you’ll incorporate these basic elements:
You have many options for information to include in the YAML metadata file, however you must include six pieces of required information (as shown in the previous image), listed in any order:
Convention is for the name of the Python detection logic and the YAML metadata files to match.
Now that you’re familiar with the basics, let’s look at a more complex example, one of the 500+ out-of-the-box detections that Panther offers.
Here’s the Python detection logic:
This Python rule detects an access error for an AWS S3 bucket. Notice the new elements in comparison to the basic rule structure:
This is just one example of how Python enables you to customize detection logic: you can develop your own libraries of helper functions, or make use of many Panther-provided tools; you can use Python variables to represent any changing data that needs to plug into the detection logic; you can leverage Python’s flexibility to structure your logic to be both effective and expressive; or you can add dynamic information to your alerts.
Next, let’s take a look at the corresponding metadata file written with YAML:
The YAML metadata file for an AWS S3 access error defines how the detection rule is identified and managed. Crucially, this file determines when an alert should be triggered, and what information should go in it.
In addition to the six required key-value pairs, there are ten optional fields. For brevity, let’s review just a few of these fields and how they impact workflows. You can read about the others in the Panther rule specification reference.
These optional fields work to reduce alert noise and increase your efficiency by structuring all the relevant information so that you can understand, correlate, and prioritize alerts and eliminate threats.
Let’s step back now and take a look at the big-picture process of creating and managing code-based detections using the CLI. The very first step in this process is signing up for Panther and onboarding all of your log sources. From there, here’s how you would manage code-based detections:
SIEM solutions are increasingly offering detection-as-code to access the advantages of scalable, flexible, and customizable threat detection. But not all solutions use Python, or other widely known programming languages. To understand this, let’s compare Panther with Splunk.
Splunk detections use Search Processing Language (SPL), their proprietary search language that is based on the Unix pipeline and Structured Query Language (SQL). With SPL, practitioners can query their security data lake and create code-based threat detection rules. Consider this SPL detection for access to AWS S3 from a new IP address:
Similar to Panther, a YAML metadata file describes this detection. Departing from Panther, SPL is the search logic that processes the log data to detect threats. While evaluating whether Python or SPL is harder to understand at face value is entirely subjective, there are some core drawbacks to using a proprietary language:
Panther offers more ways to create detections, enabling security teams to reap the benefits of detection-as-code without needing every team member to have programming experience.
Practitioners can create, test, and deploy detections without code in the Panther Console using the Simple Detections builder. The Simple Detections builder provides a series of forms that allows practitioners to target log data and specific conditions that indicate a threat is present. Under the hood, these forms generate a YAML-based detection, which means Simple Detections retain the benefits of detections-as-code: expressiveness, testability, CI/CD integration, and reusability.
A markup language, YAML is known as a human-readable description language that structures data. A YAML detection looks like the YAML metadata file that you saw earlier in this blog, but it contains a few additional fields that describe detection logic, which forgoes the need for Python detection logic. YAML detections can be created in the Panther Console or in the CLI.
Panther offers 500+ out-of-the-box detections for security teams to get value from their SIEM on day one. Panther manages the core logic and periodically releases updates. Practitioners can use these detections as is, or customize them in the Panther Console or using the CLI workflow.
Panther covers other use cases and ways to customize for detections. So far you’ve learned about analysis rules that detect threats in real-time. Panther also offers:
Get started with Panther’s detection-as-code by requesting a demo.
Or, take a closer look at how Panther does detection-as-code: