Using Derived Detections to Avoid Merge Conflicts
A workflow that could produce merge conflicts is reimagined using detection derivation
Last updated
Was this helpful?
A workflow that could produce merge conflicts is reimagined using detection derivation
Last updated
Was this helpful?
One of the most compelling reasons to use , if you are a team managing your Panther detection content using , is that you can use and customize detections not solely managed and updated by your own team while still avoiding the challenge of merge conflicts, which can arise when the same detections are updated by an external team.
This scenario can present itself when you use the detections produced and distributed by Panther's Threat Research team via the , known as . Merge conflicts can arise when you attempt to maintain a fork of panther-analysis in which you've customized Panther-managed detections, but also want to keep up to date with content changes from Panther by syncing your fork with the upstream repository.
In this case, derivation is useful, as it allows you to customize Panther-managed detections by editing a file completely separate from the ones Panther modifies—meaning you can later receive content updates from Panther without generating merge conflicts.
In the scenario below, a user is attempting to modify a Panther-managed detection. See how the update is made without, then with, detection derivation.
Let’s say you'd like to use the AWS.Console.LoginWithoutMFA Panther-managed detection (see the and ), but you also want to make the following modifications to it:
You do not want to alert if the account being logged into is a dev account
Correspondingly, you want to change the tests to reflect this logic
You want the severity to be Low if the account being logged into is an internal, non-dev account, and High otherwise
You want to change the runbook
Without using derivation, you would make the following changes in the CLI workflow:
Modify the aws_console_login_without_mfa.py file in the following ways:
Alter the rule() function to include something similar to the following logic:
Modify the aws_console_login_without_mfa.yml file in the following ways:
Replace the Tests section with a new series of tests, including one for a log that contains a dev account ID, and one for a log that does not
Update the value of Runbook to your custom runbook link
After making these changes, the rule is customized to your organization's needs. However, from this point forward, if Panther makes any changes to either file, you will likely encounter merge conflicts when pulling down updates.
See how to use derivation to avoid merge conflicts while making all of the same customizations, below.
In the derivation workflow, begin by creating a Derived Detection that inherits all aspects of the Base Detection by default:
Then start adding overrides, starting with Runbook:
Finally, add a set of your own Tests that allows you to test the detection and filter you added. Below is the complete Derived Detection after adding all of the aforementioned overrides:
Now that you've added all of your overrides to your Derived Detection, you can upload it to Panther and use it just like you would any detection.
Whenever Panther updates the Base Detection—i.e. Panther modifies either of the aws_console_login_without_mfa.py or aws_console_login_without_mfa.yml files—you will inherit the changes without needing to manually update your Derived Detection (given that these changes were not to fields you added overrides for in your Derived Detection). Most importantly, you will not encounter merge conflicts.
Add a function similar to the following:
Add to indicate the rule should not run if the AWS account being logged into is a dev account:
Add to adjust the severity if the account is a staging account: