Writing Simple Detections

Construct Simple Detections in the CLI workflow


Simple Detections can be created in the CLI workflow in YAML, in addition to being created in the Simple Detection Builder in the Console.

Simple Detections created in the CLI workflow, then uploaded to Panther, can be viewed and edited in the Simple Detection builder in the Console. This may be valuable if members of your team have varying levels of experience with YAML.

Simple detections can be used in detection derivation.

If you aren't sure whether to write detections locally as Simple Detections (in YAML) or Python detections, see the Using Python vs. Simple Detections YAML section.

If your team uses the CLI workflow to manage detection content, the changes made to detections using the Simple Detection builder in the Console will be overwritten on next upload (except for Inline Filters created in the Console, which will be preserved).

If you create or edit detections using the Simple Detection builder in the Console, copy the resulting YAML representation and include it in your local detections files, in order to prevent the changes from being overwritten on next upload.

Limitations of Simple Detections YAML

  • Scheduled rules and policies cannot be created as Simple Detections.

    • Only rules can be created in YAML.

  • Panther-managed Simple Detections are not yet available.

  • Many helper functions available in Python, including those for specific log sources, are not represented in YAML.

  • It is not possible to make external API calls in Simple Detections, including to fetch values from your Dynamo KV store to use caching.

How to create a Simple Detection (rule) in YAML

Creating a Simple Detection rule in the CLI workflow

If you're writing Simple Detections locally (instead of in the Simple Detection Builder in the Console), we recommend managing your local detection files in a version control system like GitHub or GitLab.

Folder setup

If you group your rules into folders, each folder name must contain rules in order for them to be found during upload (using either PAT or the bulk uploader in the Console).

We recommend grouping rules into folders based on log/resource type, e.g., suricata_rules or aws_s3_policies.

File setup

Each rule and scheduled rule consists of:

  • A YAML specification file (a file with a .yml extension) containing the detection logic, as well as metadata attributes of the detection.

    • This file has similar syntax to the Python YAML files, with some additional keys.

Simple Detection rules contain lists of boolean logic called match expressions that detect suspicious behaviors. Returning a value of True indicates suspicious activity, which triggers an alert.

Learn more about Simple Detection YAML syntax, and see a complete list of required and optional YAML fields below.

  • Create a YAML file (e.g. my_new_rule.yml) using the template below (including a top-level Detection key):

    AnalysisType: rule
    DedupPeriodMinutes: 60 # 1 hour
    DisplayName: Example Rule to Check the Format of the Spec
    Enabled: true
    RuleID: Type.Behavior.MoreContext
    Severity: High
      - LogType.GoesHere
      ReportName (like CIS, MITRE ATT&CK):
        - The specific report section relevant to this rule
      - Tags
      - Go
      - Here
    Description: >
      This rule exists to validate the CLI workflows of the Panther CLI
    Runbook: >
      First, find out who wrote this the spec format, then notify them with feedback.
    Reference: https://www.a-clickable-link-to-more-info.com
      - KeyPath: hostName
        Condition: Contains
        Value: prod

After this rule is uploaded to Panther, it will be viewable in the Console in the Simple Detection builder.

Simple Detection YAML syntax

Each custom Simple Detection can be composed of:

  • Detection key

  • Filter key

  • Metadata keys

  • Alert keys (dynamic)

  • Alert keys (static)


Learn more about each of these keys, including which are required and optional, in the Simple Detection rule specification reference below.


Within the Detection key, include one or more match expressions.


Learn more about using InlineFilters in Simple Detections on Modifying Detections with Inline Filters.

Dynamic alert keys in Simple Detections

Alert fields are fields in a Simple Detection definition that are applicable to the alerts generated by that detection.

Alert fields can be static or dynamic. With static alert fields, you provide a set value in the detection definition, which does not change based on the incoming event. Dynamic alert fields, however, can use information in the event to determine the value.

If you are using alert deduplication, the first event to match the detection is used by these alert keys.


Use DynamicSeverities to dynamically set the severity of an alert generated by a match on this detection. This field is dynamic because you can use values from the event to determine the severity.

When DynamicSeverities is present, its value overrides the value of the Severity key. Severity is still required, and its value will be the fallback value if there are no matches on any of the match expressions contained within DynamicSeverities.

Within the DynamicSeverities key, include one or more ChangeTo keys, each with a corresponding Conditions key. The value of ChangeTo should be one of the alert severities. The ChangeTo blocks are evaluated in order, from top to bottom, and evaluation stops once a match has been found.

Within Conditions, include one or more match expressions. The Conditions list has the following limitations:


  - ChangeTo: CRITICAL
      - Key: status
        Condition: Equals
        Value: severe
  - ChangeTo: MEDIUM
      - KeyPath: user.name
        Condition: StartsWith
        Value: admin_
      - DeepKey:
          - user
          - roles
        Condition: Contains
        Value: wheel


Use AlertTitle to dynamically set the title of an alert generated by a match on this detection. This field is dynamic because you can use values from the event in the title.

The value of AlertTitle should be a string. You can reference event values by using curly braces. Inside the curly braces, use JSON path syntax.


AlertTitle: "User {actor.username} impersonated {target.username} at {time}"


AlertContext lets you identify event data to pass onto generated alerts, formatted as a dictionary.

Within AlertContext, include one or more KeyName and KeyValue pairs. KeyName takes a string of your choice, which will become the key in the alert context dictionary. Within KeyValue, use a key specifier to indicate an event key—its value will be the value in the alert context dictionary.


  - KeyName: ip
      Key: sourceIP
  - KeyName: user
        - user
        - username
  - KeyName: resource
      KeyPath: resource.arns


GroupBy sets the deduplication string for your detection. Learn more about deduplication, including the order of precedence for how the deduplication string is set, on Rules and Scheduled Rules.

Within the GroupBy key, include a list of one or more event keys defined with key specifiers.


  - Key: sourceIP
  - KeyPath: user.name
  - KeyPath: resource.arn

The values of the keys provided under GroupBy are joined with a colon to form the deduplication string. The outputted deduplication string for the above example would be:

<value of sourceIP>:<value of user.name>:<value of resource.arn>

Simple Detection rule specification reference

The table below contains all available YAML keys for Simple Detections. Required fields are in bold.

If you are writing a Python rule, instead see the Python rule specification reference.

Field Name


Expected Value


Indicates whether this analysis is a rule, scheduled_rule, policy, or global



Whether this rule is enabled



The unique identifier of the rule



The list of logs to apply this rule to

List of strings


Which severity an associated alert should have

One of the following strings: Info, Low, Medium, High, or Critical This field is overwritten by DynamicSeverities, but is required even if DynamicSeverities is defined


The list of match expressions to apply to the event data

Alternate severities based on custom sets of conditions

List of dynamic severity configurations, consisting of ChangeTo and Conditions fields. ChangeTo is a Severity value and Conditions is a list of match expressions.


A brief description of the rule


Set of event values that will be used to deduplicate alerts by

List of event keys


The time period (in minutes) during which similar events of an alert will be grouped together

15,30,60,180 (3 hours),720 (12 hours), or 1440 (24 hours)


A user-friendly name to show in the Panther Console and alerts. The RuleID will be displayed if this field is not set.



Static destination overrides. These will be used to determine how alerts from this rule are routed, taking priority over default routing based on severity.

List of strings


The reason this rule exists, often a link to documentation



A mapping of framework or report names to values this rule covers for that framework

Map of strings to list of strings


The actions to be carried out if this rule returns an alert, often a link to documentation



A list of fields that alerts should summarize.

List of strings


How many events need to trigger this rule before an alert will be sent.



Tags used to categorize this rule

List of strings


Unit tests for this rule

List of maps


The list of filters in the form of match expressions to filter in data

List of match expressions (limited to filter-compatible versions)

An alternate DisplayName that can use event values to create a dynamic title for alerts


Event values to add to the Event under custom keys to create a dynamic alert context

List of key name and key value pairs

Last updated