PyPanther Detections Style Guide

PyPanther Detections are in closed beta starting with Panther version 1.108. Please share any bug reports and feature requests with your Panther support team.

Repository structure recommendations

Get up and running quickly by cloning the pypanther-starter-kit repository.

In your code repository where your PyPanther Detections are stored, it's recommended to:

  • Maintain a top-level module, content, in which all of your custom Python code is stored (except for the main.py file).

Within this folder, it's recommended to:

  • Store custom rule definitions in a rules directory.

  • Store logic that makes overrides on Panther-managed rules in an overrides directory.

  • Store custom helpers in a helpers directory.

# Recommended repository structure
.
├── README.md
├── content
│   ├── __init__.py
│   ├── helpers
│   │   ├── __init__.py
│   │   ├── cloud.py
│   │   └── custom_log_types.py
│   ├── overrides
│   │   ├── __init__.py
│   │   ├── aws_cloudtrail.py└
│   │   └── aws_guardduty.py
│   ├── rules
│      ├── __init__.py
│      ├── my_custom_rule.py
│      └── my_inherited_rule.py
   └── schemas
       └── schema1.yml
└── main.py

main.py content recommendations

It's recommended for your main.py file to:

  • Import Panther-managed rules (which you do or don't want to make overrides on) using get_panther_rules

    • If you defined apply_overrides functions, call pypanther's apply_overrides() to apply all of your changes. Learn more in Call apply_overrides(), below.

  • Import custom rules using get_rules

Call apply_overrides()

The pypanther apply_overrides() convenience function lets you, in main.py, efficiently apply all detection overrides made in a separate file or folder.

apply_overrides() takes an imported package (folder) or module (file) name and an optional list of rules, and runs all functions named apply_overrides() from that package or module against the list of rules. (This is similar to how get_rules() works.) It's recommended to name this package or module overrides.

Each folder containing rules imported with apply_overrides() must contain an __init__.py file.

In the following example, the apply_overrides() functions in general.py and aws_cloudtrail.py are applied when apply_overrides(overrides, all_rules) is called in main.py:

Best practices for PyPanther Detection writing

Use filters instead of overriding rule()

If you would like to alter the logic of a Panther-managed PyPanther Detection, it's recommended to use include/exclude filters instead of overriding the rule's rule() function. Filters are designed for this purpose—to be applied on top of existing rule logic. They are executed against each incoming event before the rule() logic, in order to determine if the rule should indeed process the event.

If you are significantly altering the rule logic, you might also consider writing a custom rule instead.

Use upgrade() or downgrade() in severity()

While each PyPanther rule must define a default_severity, it can also define a severity() function, whose value overrides default_severity to set the severity level of resulting alerts.

Within severity(), it's common practice to dynamically set the severity based on an event field value. One way to do this is to add some condition, which, if satisfied, returns a hard-coded Severity value. In the example below, if the actor associated to the event has an admin role, Severity.MEDIUM is returned, regardless of the value of self.default_severity:

Note that you can reference the default_severity value with self.default_severity.

In the example above, if MyRule's default_severity was ever changed from Severity.LOW to, say, Severity.MEDIUM, you would also need to remember to update the Severity.MEDIUM in severity() (presumably to Severity.HIGH), to preserve the escalation.

Using upgrade() instead of hard-coding a Severity

Instead of setting the return value of severity() as a hard-coded Severity value (as is shown in the example above), it's recommended to call the Severity class's upgrade() and downgrade() functions on self.default_severity.

In this model, if your detection's default_severity value ever changes, you won't also need to make changes in the severity() function. In the example below, default_severity has been changed to Severity.MEDIUM, and the return value within the condition automatically adjusts to returning Severity.HIGH because it uses upgrade():

There may be rare instances when using a static value within severity() is preferable—for example, you may always want to return Severity.INFO when an event originates in a dev account, even if the default_severity later changes. This might look like:

Optionally use explicit typing

The pypanther base Rule class is typed, so when you create a custom detection (i.e., inherit from Rule), explicit typing is optional. Still, if you prefer to use explicit types, you can do so.

Example of a custom rule with explicit typing

Last updated

Was this helpful?