Detection Packs
Packs are used to logically group detections as well as enable detection updates via the Panther UI. Panther-provided packs are defined in this open source repository: panther-labs/panther-analysis.
A single pack can group any number of detections, queries, global helpers, and data models. For example, one of the provided Detections Packs, Panther Universal Detections, groups all the rules that rely on data models and all of their dependencies.
Updates to detections in these packs are tracked automatically by the Panther backend. When a new update for a detection pack is available in the panther-analysis repository, the Packs page in your Panther Console under Analysis > Packs will display an Update available flag next to the relevant items.
Detections that are part of an enabled detection pack will be labeled as MANAGED, and detections that are not part of a detection pack will be labeled as UNMANAGED.
Note: The process is not recommended if you are using a Git-Based workflow and uploading detections with Panther Analysis Tool. Doing so may result in unexpected behavior.

Panther Built-In Detection Packs

Panther provides several Detection Packs by default. There are packs that group all of the Panther-provided detections related to a particular log source, as well as Detection Packs that are grouped on a particular focus (e.g., generic rules that leverage unified data models or a core set of detections for AWS.) Some popular examples include:
Display Name
Description
Universal Detections
This pack groups the standard rules that leverage unified data models
Panther Core AWS Pack
Group of the most critical and high value detections pertinent to the AWS environment
Panther Okta Pack
Group of all Panther created detections for Okta

Viewing Detection Packs

You can view a list of Panther-provided detection packs in your Panther Console under Analysis > Packs.
List Packs
Click on a Pack to view its details, including a description, the enabled status, the currently enabled version, and which detections are in the pack.
Pack Details

Enable and Disable Detection Pack

Packs can be disabled or enabled in your Panther Console. If you enable a pack, all the detections in the pack will be enabled. If you would like to disable a single or multiple detections within it, you can do this on a one-by-one basis without having to disable the entire pack. When you update a pack that has disabled detections, the detections will be updated but they will stay disabled.
To enable or disable a Pack:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs.
  3. 3.
    Toggle the Enabled slider on or off.
Enable Pack From List
The Enabled slider also appears on Pack detail pages:
Enable Pack From Details

Update or Rollback Detection Pack

New updates to detection packs are periodically released to the panther-analysis repository. These updates are automatically detected by Panther, and the pack overview page will show an Update Available flag next to relevant packs.
To update pack detections:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs.
  3. 3.
    Select the version in the "Version" dropdown menu then click Update Pack.
Update Pack
To revert to a previous Pack version:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs.
  3. 3.
    Select the version in the "Version" dropdown menu then click Revert Pack.
Revert Pack

Managing Detections with Packs

Editing Managed Detections

After a pack has been enabled, there are a subset of fields that you can manually edit in the Panther Console:
  • Enabled / Disabled
  • Severity
  • Events Threshold
  • Deduplication Period
  • Destination Override
Any changes you make to these fields in the Panther Console will be preserved when the pack is updated or reverted to a previous version. All other fields will be greyed out in the UI, and the "Functions and Tests" editor will be read-only.
Note: For enabled Packs, the above fields can only be edited manually in the Panther Console. Editing these fields in the Detection .yml files will not override these values.
You can make changes to the editable fields in the Panther Console:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs.
  3. 3.
    Click on the Pack that contains the detection you want to edit, then click on the detection.
  4. 4.
    In the page that opens, click Edit Rule in the upper right side.
    • You will be presented with all the fields that you can edit.
  5. 5.
    Click Update to save your changes.

Cloning and editing a managed detection

If a rule or policy included in a Detection Pack does not fit your needs, you can clone it and then customize the cloned copy of the Detection Pack:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs.
  3. 3.
    Click on the Pack that contains the detection you want to edit, then click on the detection.
  4. 4.
    In the page that opens, click Clone & edit in the upper right:
    • You will be redirected to the standard rule creation interface where you can make changes to the new copy of the rule.
  5. 5.
    Click Update in the upper right.
Note that the display name of a cloned Detection will have _COPY appended to it.
Also note that cloning and editing a rule does not disable it. If you wish to have your customized copy of the Detection replace the Panther managed rule, make sure to go back and disable it.
The Cloned rule will not be managed by Panther or receive automatic updates when the original version of the Pack is updated. The original version that is still contained within the Pack will continue to receive updates as normal, whether it is enabled or disabled.

Pack Sources

Pack Sources provide a way to configure custom Github sources for Detection Packs. Once a Pack Source is configured, Panther will check the source repository for new tagged releases every 24 hours. In order for Panther to find your custom Pack(s) from your Pack Source, you must:
  • Ensure that your release is finalized, and not in a draft state
  • Ensure that your release is named according to SemVer format, and the tag of the release must be the same as the name of the release
  • Ensure that the artifact of the release is named panther-analysis-all.zip (and a corresponding panther-analysis-all.sig if you are signing your release)
  • Ensure that your panther-analysis-all.zip contains at least one Pack Manifest file (see section on Pack Manifests below)
You can use the panther_analysis_tool (PAT) to generate the required release assets, as well as publish a draft release (see Creating a Github Release - Panther Analysis Tool for additional details.) You can manage custom packs using the same functionality as Panther-provided packs.
Pack source fields are described in the following table.
Field Name
Required
Description
Expected Value
Owner
Yes
The owner/organization of the target repository
String
Repository
Yes
The name of the repository
String
kmsKey
No
The ARN for a sign/verify kms key to validate release signatures
String
AccessToken
No
Personal Access Token used to access a private repository
String

Pack Manifests

Packs are defined by creating Pack Manifest yaml files, which contain metadata about your Pack (such as its name, description, and the detections/files that are included in your Pack).
Your panther-analysis-all.zip release artifact can contain many different Pack Manifests along with other files from your repository such as detections, global helpers, data models, etc. If you add your GitHub repository as a Pack Source in the Panther Console, then each of these Pack Manifest files will show up as a Pack in the Panther Console that can be separately enabled/disabled.
The following table is a reference of the different keys that are valid in your Pack Manifest. You can find additional examples of the Pack Manifests that Panther uses in our Panther-provided Packs on Github.
Field Name
Required
Description
Expected Value
AnalysisType
true
Indicates the analysis type this file is
pack
PackID
true
The unique ID of this pack
String
Description
false
Extra information about this Pack that will be displayed in the Panther Console
String
PackDefinition
true
A mapping with a single field called IDs which is a list of strings. Each string in the IDs list should be a unique ID of a file that is included in this Pack
{ IDs: [string] }
DisplayName
true
The user-friendly title that will be displayed for this Pack in the Panther Console
String

Accessing Private Repositories

In order for Panther to have access to poll a private repository, you must configure the Pack Source with a personal access token. See the Github documentation for further details on creating a token.
A personal access token will grant access to all the repositories where the account owner has access. We recommend creating a "machine user" that you can add as an outside collaborator to the repository containing the detection packs. This way, the access token can be scoped for a particular use and repository.

Release Signatures

The Panther-provided packs are signed using an asymmetric AWS KMS key. Prior to importing any detections from the Panther pack source, it will validate the signature using the release asset panther-analysis.sig. This ensures that any detections being imported have not been tampered or modified. If you would like to use similar functionality, create a sign/verify KMS key and modify the policy to allow Panther to run kms:Verify using that key.
In this example entry to add to the key policy, the account ID should be replaced with the account ID where Panther is running:
1
{
2
"Sid": "Enable KMS Verify",
3
"Effect": "Allow",
4
"Principal": {
5
"AWS": "arn:aws:iam::{accountid}:root"
6
},
7
"Action": "kms:Verify",
8
"Resource": "*"
9
}
Copied!

Managing Pack Sources

To Add a pack source:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs, then click the Detection Pack Sources tab.
  3. 3.
    Click Create New in the upper right.
    • Enter the field names for each input field.
  4. 4.
    Click Save.
To modify the kmsKey or AccessToken fields for a pack source:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs, then click the Detection Pack Sources tab.
  3. 3.
    Click ... next to a Pack Source then click Edit. Click on a Pack Source.
    • Edit the fields on this page.
  4. 4.
    Click Save.
To Delete a pack source:
  1. 1.
    Log in to your Panther Console.
  2. 2.
    Navigate to Analysis > Packs, then click the Detection Pack Sources tab.
  3. 3.
    Click ... next to a Pack Source then click Delete.
Deleting a Pack Source will delete the packs originating from it, along with all of the detections in it.

Creating a Github Release - Panther Analysis Tool

The panther_analysis_tool can streamline the process of creating an appropriate Github release, with or without an associated signature file.
To generate the release assets, use the release command.
1
% panther_analysis_tool release --help
2
usage: panther_analysis_tool release [-h] [--aws-profile AWS_PROFILE]
3
[--filter KEY=VALUE [KEY=VALUE ...]]
4
[--kms-key KMS_KEY]
5
[--minimum-tests MINIMUM_TESTS]
6
[--out OUT] [--path PATH] [--skip-tests]
7
8
optional arguments:
9
-h, --help show this help message and exit
10
--aws-profile AWS_PROFILE
11
The AWS profile to use when updating the AWS Panther
12
deployment.
13
--filter KEY=VALUE [KEY=VALUE ...]
14
--kms-key KMS_KEY The key id to use to sign the release asset.
15
--minimum-tests MINIMUM_TESTS
16
The minimum number of tests in order for a detection
17
to be considered passing. If a number greater than 1
18
is specified, at least one True and one False test is
19
required.
20
--out OUT The path to store output files.
21
--path PATH The relative path to Panther policies and rules.
22
--skip-tests
Copied!
To automatically create a draft release in your Github repository, first set the GITHUB_TOKEN environment variable to a personal access token with appropriate permissions to access the target repository. Then, use the publish command.
Note: Using the panther_analysis_tool publish command creates a draft release. Before Panther is able to pull in this release artifact, you must go to your Github repository and manually finalize the draft into a release.
1
% panther_analysis_tool publish --help
2
usage: panther_analysis_tool publish [-h] [--body BODY]
3
[--github-branch GITHUB_BRANCH]
4
[--github-owner GITHUB_OWNER]
5
[--github-repository GITHUB_REPOSITORY]
6
--github-tag GITHUB_TAG
7
[--aws-profile AWS_PROFILE]
8
[--filter KEY=VALUE [KEY=VALUE ...]]
9
[--kms-key KMS_KEY]
10
[--minimum-tests MINIMUM_TESTS]
11
[--out OUT] [--skip-tests]
12
13
optional arguments:
14
-h, --help show this help message and exit
15
--body BODY The text body for the release
16
--github-branch GITHUB_BRANCH
17
The branch to base the release on
18
--github-owner GITHUB_OWNER
19
The github owner of the repsitory
20
--github-repository GITHUB_REPOSITORY
21
The github repsitory name
22
--github-tag GITHUB_TAG
23
The tag name for this release
24
--aws-profile AWS_PROFILE
25
The AWS profile to use when updating the AWS Panther
26
deployment.
27
--filter KEY=VALUE [KEY=VALUE ...]
28
--kms-key KMS_KEY The key id to use to sign the release asset.
29
--minimum-tests MINIMUM_TESTS
30
The minimum number of tests in order for a detection
31
to be considered passing. If a number greater than 1
32
is specified, at least one True and one False test is
33
required.
34
--out OUT The path to store output files.
35
--skip-tests
Copied!
The kms-key argument is an optional argument that you can use to generate a signature file. If you want to use this argument, be sure to run panther_analysis_tool using the appropriate aws credentials to call kms:Sign on the specified key.