LogoLogo
Knowledge BaseCommunityRelease NotesRequest Demo
  • Overview
  • Quick Start
    • Onboarding Guide
  • Data Sources & Transports
    • Supported Logs
      • 1Password Logs
      • Apache Logs
      • AppOmni Logs
      • Asana Logs
      • Atlassian Logs
      • Auditd Logs
      • Auth0 Logs
      • AWS Logs
        • AWS ALB
        • AWS Aurora
        • AWS CloudFront
        • AWS CloudTrail
        • AWS CloudWatch
        • AWS Config
        • AWS EKS
        • AWS GuardDuty
        • AWS Security Hub
        • Amazon Security Lake
        • AWS S3
        • AWS Transit Gateway
        • AWS VPC
        • AWS WAF
      • Azure Monitor Logs
      • Bitwarden Logs
      • Box Logs
      • Carbon Black Logs
      • Cisco Umbrella Logs
      • Cloudflare Logs
      • CrowdStrike Logs
        • CrowdStrike Falcon Data Replicator
        • CrowdStrike Event Streams
      • Docker Logs
      • Dropbox Logs
      • Duo Security Logs
      • Envoy Logs
      • Fastly Logs
      • Fluentd Logs
      • GCP Logs
      • GitHub Logs
      • GitLab Logs
      • Google Workspace Logs
      • Heroku Logs
      • Jamf Pro Logs
      • Juniper Logs
      • Lacework Logs
        • Lacework Alert Channel Webhook
        • Lacework Export
      • Material Security Logs
      • Microsoft 365 Logs
      • Microsoft Entra ID Audit Logs
      • Microsoft Graph Logs
      • MongoDB Atlas Logs
      • Netskope Logs
      • Nginx Logs
      • Notion Logs
      • Okta Logs
      • OneLogin Logs
      • Orca Security Logs (Beta)
      • Osquery Logs
      • OSSEC Logs
      • Proofpoint Logs
      • Push Security Logs
      • Rapid7 Logs
      • Salesforce Logs
      • SentinelOne Logs
      • Slack Logs
      • Snowflake Audit Logs (Beta)
      • Snyk Logs
      • Sophos Logs
      • Sublime Security Logs
      • Suricata Logs
      • Sysdig Logs
      • Syslog Logs
      • Tailscale Logs
      • Teleport Logs
      • Tenable Vulnerability Management Logs
      • Thinkst Canary Logs
      • Tines Logs
      • Tracebit Logs
      • Windows Event Logs
      • Wiz Logs
      • Zeek Logs
      • Zendesk Logs
      • Zoom Logs
      • Zscaler Logs
        • Zscaler ZIA
        • Zscaler ZPA
    • Custom Logs
      • Log Schema Reference
      • Transformations
      • Script Log Parser (Beta)
      • Fastmatch Log Parser
      • Regex Log Parser
      • CSV Log Parser
    • Data Transports
      • HTTP Source
      • AWS Sources
        • S3 Source
        • CloudWatch Logs Source
        • SQS Source
          • SNS Source
        • EventBridge
      • Google Cloud Sources
        • Cloud Storage (GCS) Source
        • Pub/Sub Source
      • Azure Blob Storage Source
    • Monitoring Log Sources
    • Ingestion Filters
      • Raw Event Filters
      • Normalized Event Filters (Beta)
    • Data Pipeline Tools
      • Chronosphere Onboarding Guide
      • Cribl Onboarding Guide
      • Fluent Bit Onboarding Guide
        • Fluent Bit Configuration Examples
      • Fluentd Onboarding Guide
        • General log forwarding via Fluentd
        • MacOS System Logs to S3 via Fluentd
        • Syslog to S3 via Fluentd
        • Windows Event Logs to S3 via Fluentd (Legacy)
        • GCP Audit to S3 via Fluentd
      • Observo Onboarding Guide
      • Tarsal Onboarding Guide
    • Tech Partner Log Source Integrations
  • Detections
    • Using Panther-managed Detections
      • Detection Packs
    • Rules and Scheduled Rules
      • Writing Python Detections
        • Python Rule Caching
        • Data Models
        • Global Helper Functions
      • Modifying Detections with Inline Filters (Beta)
      • Derived Detections (Beta)
        • Using Derived Detections to Avoid Merge Conflicts
      • Using the Simple Detection Builder
      • Writing Simple Detections
        • Simple Detection Match Expression Reference
        • Simple Detection Error Codes
    • Correlation Rules (Beta)
      • Correlation Rule Reference
    • PyPanther Detections (Beta)
      • Creating PyPanther Detections
      • Registering, Testing, and Uploading PyPanther Detections
      • Managing PyPanther Detections in the Panther Console
      • PyPanther Detections Style Guide
      • pypanther Library Reference
      • Using the pypanther Command Line Tool
    • Signals
    • Policies
    • Testing
      • Data Replay (Beta)
    • Framework Mapping and MITRE ATT&CK® Matrix
  • Cloud Security Scanning
    • Cloud Resource Attributes
      • AWS
        • ACM Certificate
        • CloudFormation Stack
        • CloudWatch Log Group
        • CloudTrail
        • CloudTrail Meta
        • Config Recorder
        • Config Recorder Meta
        • DynamoDB Table
        • EC2 AMI
        • EC2 Instance
        • EC2 Network ACL
        • EC2 SecurityGroup
        • EC2 Volume
        • EC2 VPC
        • ECS Cluster
        • EKS Cluster
        • ELBV2 Application Load Balancer
        • GuardDuty Detector
        • GuardDuty Detector Meta
        • IAM Group
        • IAM Policy
        • IAM Role
        • IAM Root User
        • IAM User
        • KMS Key
        • Lambda Function
        • Password Policy
        • RDS Instance
        • Redshift Cluster
        • Route 53 Domains
        • Route 53 Hosted Zone
        • S3 Bucket
        • WAF Web ACL
  • Alerts & Destinations
    • Alert Destinations
      • Amazon SNS Destination
      • Amazon SQS Destination
      • Asana Destination
      • Blink Ops Destination
      • Custom Webhook Destination
      • Discord Destination
      • GitHub Destination
      • Google Pub/Sub Destination (Beta)
      • Incident.io Destination
      • Jira Cloud Destination
      • Jira Data Center Destination (Beta)
      • Microsoft Teams Destination
      • Mindflow Destination
      • OpsGenie Destination
      • PagerDuty Destination
      • Rapid7 Destination
      • ServiceNow Destination (Custom Webhook)
      • Slack Bot Destination
      • Slack Destination (Webhook)
      • Splunk Destination (Beta)
      • Tines Destination
      • Torq Destination
    • Assigning and Managing Alerts
      • Managing Alerts in Slack
    • Alert Runbooks
      • Panther-managed Policies Runbooks
        • AWS CloudTrail Is Enabled In All Regions
        • AWS CloudTrail Sending To CloudWatch Logs
        • AWS KMS CMK Key Rotation Is Enabled
        • AWS Application Load Balancer Has Web ACL
        • AWS Access Keys Are Used Every 90 Days
        • AWS Access Keys are Rotated Every 90 Days
        • AWS ACM Certificate Is Not Expired
        • AWS Access Keys not Created During Account Creation
        • AWS CloudTrail Has Log Validation Enabled
        • AWS CloudTrail S3 Bucket Has Access Logging Enabled
        • AWS CloudTrail Logs S3 Bucket Not Publicly Accessible
        • AWS Config Is Enabled for Global Resources
        • AWS DynamoDB Table Has Autoscaling Targets Configured
        • AWS DynamoDB Table Has Autoscaling Enabled
        • AWS DynamoDB Table Has Encryption Enabled
        • AWS EC2 AMI Launched on Approved Host
        • AWS EC2 AMI Launched on Approved Instance Type
        • AWS EC2 AMI Launched With Approved Tenancy
        • AWS EC2 Instance Has Detailed Monitoring Enabled
        • AWS EC2 Instance Is EBS Optimized
        • AWS EC2 Instance Running on Approved AMI
        • AWS EC2 Instance Running on Approved Instance Type
        • AWS EC2 Instance Running in Approved VPC
        • AWS EC2 Instance Running On Approved Host
        • AWS EC2 Instance Running With Approved Tenancy
        • AWS EC2 Instance Volumes Are Encrypted
        • AWS EC2 Volume Is Encrypted
        • AWS GuardDuty is Logging to a Master Account
        • AWS GuardDuty Is Enabled
        • AWS IAM Group Has Users
        • AWS IAM Policy Blocklist Is Respected
        • AWS IAM Policy Does Not Grant Full Administrative Privileges
        • AWS IAM Policy Is Not Assigned Directly To User
        • AWS IAM Policy Role Mapping Is Respected
        • AWS IAM User Has MFA Enabled
        • AWS IAM Password Used Every 90 Days
        • AWS Password Policy Enforces Complexity Guidelines
        • AWS Password Policy Enforces Password Age Limit Of 90 Days Or Less
        • AWS Password Policy Prevents Password Reuse
        • AWS RDS Instance Is Not Publicly Accessible
        • AWS RDS Instance Snapshots Are Not Publicly Accessible
        • AWS RDS Instance Has Storage Encrypted
        • AWS RDS Instance Has Backups Enabled
        • AWS RDS Instance Has High Availability Configured
        • AWS Redshift Cluster Allows Version Upgrades
        • AWS Redshift Cluster Has Encryption Enabled
        • AWS Redshift Cluster Has Logging Enabled
        • AWS Redshift Cluster Has Correct Preferred Maintenance Window
        • AWS Redshift Cluster Has Sufficient Snapshot Retention Period
        • AWS Resource Has Minimum Number of Tags
        • AWS Resource Has Required Tags
        • AWS Root Account Has MFA Enabled
        • AWS Root Account Does Not Have Access Keys
        • AWS S3 Bucket Name Has No Periods
        • AWS S3 Bucket Not Publicly Readable
        • AWS S3 Bucket Not Publicly Writeable
        • AWS S3 Bucket Policy Does Not Use Allow With Not Principal
        • AWS S3 Bucket Policy Enforces Secure Access
        • AWS S3 Bucket Policy Restricts Allowed Actions
        • AWS S3 Bucket Policy Restricts Principal
        • AWS S3 Bucket Has Versioning Enabled
        • AWS S3 Bucket Has Encryption Enabled
        • AWS S3 Bucket Lifecycle Configuration Expires Data
        • AWS S3 Bucket Has Logging Enabled
        • AWS S3 Bucket Has MFA Delete Enabled
        • AWS S3 Bucket Has Public Access Block Enabled
        • AWS Security Group Restricts Ingress On Administrative Ports
        • AWS VPC Default Security Group Restricts All Traffic
        • AWS VPC Flow Logging Enabled
        • AWS WAF Has Correct Rule Ordering
        • AWS CloudTrail Logs Encrypted Using KMS CMK
      • Panther-managed Rules Runbooks
        • AWS CloudTrail Modified
        • AWS Config Service Modified
        • AWS Console Login Failed
        • AWS Console Login Without MFA
        • AWS EC2 Gateway Modified
        • AWS EC2 Network ACL Modified
        • AWS EC2 Route Table Modified
        • AWS EC2 SecurityGroup Modified
        • AWS EC2 VPC Modified
        • AWS IAM Policy Modified
        • AWS KMS CMK Loss
        • AWS Root Activity
        • AWS S3 Bucket Policy Modified
        • AWS Unauthorized API Call
    • Tech Partner Alert Destination Integrations
  • Investigations & Search
    • Search
      • Search Filter Operators
    • Data Explorer
      • Data Explorer SQL Search Examples
        • CloudTrail logs queries
        • GitHub Audit logs queries
        • GuardDuty logs queries
        • Nginx and ALB Access logs queries
        • Okta logs queries
        • S3 Access logs queries
        • VPC logs queries
    • Visualization and Dashboards
      • Custom Dashboards (Beta)
      • Panther-Managed Dashboards
    • Standard Fields
    • Saved and Scheduled Searches
      • Templated Searches
        • Behavioral Analytics and Anomaly Detection Template Macros (Beta)
      • Scheduled Search Examples
    • Search History
    • Data Lakes
      • Snowflake
        • Snowflake Configuration for Optimal Search Performance
      • Athena
  • PantherFlow (Beta)
    • PantherFlow Quick Reference
    • PantherFlow Statements
    • PantherFlow Operators
      • Datatable Operator
      • Extend Operator
      • Join Operator
      • Limit Operator
      • Project Operator
      • Range Operator
      • Sort Operator
      • Search Operator
      • Summarize Operator
      • Union Operator
      • Visualize Operator
      • Where Operator
    • PantherFlow Data Types
    • PantherFlow Expressions
    • PantherFlow Functions
      • Aggregation Functions
      • Date/time Functions
      • String Functions
      • Array Functions
      • Math Functions
      • Control Flow Functions
      • Regular Expression Functions
      • Snowflake Functions
      • Data Type Functions
      • Other Functions
    • PantherFlow Example Queries
      • PantherFlow Examples: Threat Hunting Scenarios
      • PantherFlow Examples: SOC Operations
      • PantherFlow Examples: Panther Audit Logs
  • Enrichment
    • Custom Lookup Tables
      • Creating a GreyNoise Lookup Table
      • Lookup Table Examples
        • Using Lookup Tables: 1Password UUIDs
      • Lookup Table Specification Reference
    • Identity Provider Profiles
      • Okta Profiles
      • Google Workspace Profiles
    • Anomali ThreatStream
    • IPinfo
    • Tor Exit Nodes
    • TrailDiscover (Beta)
  • Panther AI (Beta)
  • System Configuration
    • Role-Based Access Control
    • Identity & Access Integrations
      • Azure Active Directory SSO
      • Duo SSO
      • G Suite SSO
      • Okta SSO
        • Okta SCIM
      • OneLogin SSO
      • Generic SSO
    • Panther Audit Logs
      • Querying and Writing Detections for Panther Audit Logs
      • Panther Audit Log Actions
    • Notifications and Errors (Beta)
      • System Errors
    • Panther Deployment Types
      • SaaS
      • Cloud Connected
        • Configuring Snowflake for Cloud Connected
        • Configuring AWS for Cloud Connected
        • Pre-Deployment Tools
      • Legacy Configurations
        • Snowflake Connected (Legacy)
        • Customer-configured Snowflake Integration (Legacy)
        • Self-Hosted Deployments (Legacy)
          • Runtime Environment
  • Panther Developer Workflows
    • Panther Developer Workflows Overview
    • Using panther-analysis
      • Public Fork
      • Private Clone
      • Panther Analysis Tool
        • Install, Configure, and Authenticate with the Panther Analysis Tool
        • Panther Analysis Tool Commands
        • Managing Lookup Tables and Enrichment Providers with the Panther Analysis Tool
      • CI/CD for Panther Content
        • Deployment Workflows Using Panther Analysis Tool
          • Managing Panther Content via CircleCI
          • Managing Panther Content via GitHub Actions
        • Migrating to a CI/CD Workflow
    • Panther API
      • REST API (Beta)
        • Alerts
        • Alert Comments
        • API Tokens
        • Data Models
        • Globals
        • Log Sources
        • Queries
        • Roles
        • Rules
        • Scheduled Rules
        • Simple Rules
        • Policies
        • Users
      • GraphQL API
        • Alerts & Errors
        • Cloud Account Management
        • Data Lake Queries
        • Log Source Management
        • Metrics
        • Schemas
        • Token Rotation
        • User & Role Management
      • API Playground
    • Terraform
      • Managing AWS S3 Log Sources with Terraform
      • Managing HTTP Log Sources with Terraform
    • pantherlog Tool
    • Converting Sigma Rules
  • Resources
    • Help
      • Operations
      • Security and Privacy
        • Security Without AWS External ID
      • Glossary
      • Legal
    • Panther System Architecture
Powered by GitBook
On this page
  • Overview
  • Rules vs. scheduled rules
  • Using Python vs. Simple Detections YAML
  • How rules and scheduled rules work
  • Title of associated alerts
  • Deduplication of alerts
  • How to write rules and scheduled rules
  • How to write rules
  • How to write scheduled rules
  • Rule errors and scheduled rule errors
  • Rule examples
  • Auth0 multi-factor authentication policy disabled
  • Detect and alert when an admin panel is accessed on a web server
  • Reference
  • Alert severity

Was this helpful?

  1. Detections

Rules and Scheduled Rules

Rules and scheduled rules detect suspicious activity in logs, then generate alerts

PreviousDetection PacksNextWriting Python Detections

Last updated 2 months ago

Was this helpful?

Overview

Rules and scheduled rules are segments of logic through which log data is run to detect suspicious activity and generate signals (and optionally alerts). Rules analyze real-time events, while scheduled rules analyze events queried from your data lake. These detection types differ from policies, which apply to cloud resource configurations.

Rules can be created in the Console using the Simple Detection builder or by writing Python; in the CLI workflow, rules can be written as Simple Detections (in YAML) or in Python. Scheduled rules can be written in Python (in the Console or CLI workflow).

Rules can use inheritance, which allows you to created one or more Derived Detections from a single Base Detection.

If you'd like to create rules or scheduled rules for actions that aren't worthy—at least on their own—of generating an alert, you can (only generating signals). You may then want to include those rules in a correlation rule.

Panther provides a number of Panther-managed rules and scheduled rules in Python, which are already written and continuously updated. Rules can use derivation, which allows you to create one or more Derived Detections from a single Base Detection. You can also convert Sigma rules into Panther rules.

Common examples of rules include analyzing logs for:

  • Authentication from unknown or unexpected locations

  • Sensitive API calls, such as administrative changes to SaaS services

  • Network traffic access to sensitive data sources, such as databases or virtual machines

  • New, suspicious entries added into a system's scheduled tasks, like cron

  • Alerts generated from NIDS, HIDS, or other security systems

Rules vs. scheduled rules

Both rules and scheduled rules define logic through which log events are run—but rules analyze real-time events, while scheduled rules analyze events queried from your data lake.

  • Rules

    • Rules are the default mechanism of analyzing data sent to Panther. Rules work by accepting a defined set of log types such as one or more of the Supported Logs sources, or your own custom data. Rules have the benefit of low-latency detection and alerting.

    • Use cases: High-signal logs that do not require joins with other data.

    • Rules may also be known as streaming rules, real-time rules, and low-latency rules.

  • Scheduled rules

    • Scheduled rules work by accepting individual rows output from an associated Scheduled Search.

    • Use cases: Searching windows of time further in the past, running statistical analysis over data, or joining separate data streams.

Using Python vs. Simple Detections YAML

If you are writing rules locally, in the CLI workflow, you can create them as Python or Simple Detections. (Scheduled rules can only be written in Python.) There are advantages to both methods of rule creation, outlined below.

  • Write rules in Python when:

  • Write rules as Simple Detections when:

    • You'd like to promote collaboration between team members with differing levels of technical skill. When Simple Detections written in the CLI workflow are uploaded to Panther, they're represented in the Console in the Simple Detection builder. You can then edit (or create new) detections in the Console using the Simple Detection builder.

For examples of the same detection logic written in both Python and YAML, see Rule examples, below.

How rules and scheduled rules work

Rules and scheduled rules each analyze one event at a time. They use event thresholds and de-duplication to create event grouping within windows of time.

At a minimum, each rule and scheduled rule must define rule logic. For Python detections, this means they each must contain a rule() function; for Simple Detections written in the CLI workflow, each must contain a Detection key with at least one match expression.

Rules cannot run longer than 15 seconds. If this happens, a rule error is generated and processing is terminated. (This constraint does not apply to scheduled rules.)

Title of associated alerts

When a detection has alerting enabled, the title of a resulting alert is determined by that detection's configuration. When a separate deduplication string is not explicitly set, the alert title is also used to deduplicate alerts.

How the alert title is set

The order of precedence for setting the alert title is as follows:

Alert title precedence in Python:

  1. If title() is not defined, the value of the detection's display name is used. This is defined:

    • In the Console: in the Name field

    • In the CLI workflow: in the DisplayName field in the YAML file

  2. If there is no display name defined, the detection's ID is used. This is defined:

    • In the Console: in the ID field

    • In the CLI workflow: in theRuleID or PolicyID field in the YAML file

Alert title precedence in Simple Detections YAML:

  1. The dynamic alert title is used. This is defined:

    • In the Console: in the Optional Fields > Default title is > Change to field

  2. If a dynamic alert title is not defined, the value of the detection's display name is used. This is defined:

    • In the Console: in the Name field

    • In the developer workflow: in the DisplayName field

  3. If there is no display name defined, the detection's ID is used. This is defined:

    • In the Console: in the ID field

    • In the developer workflow: in theRuleID or PolicyID field

Deduplication of alerts

Events triggering the same detection within its deduplication period that also share a deduplication string will be grouped together in a single alert.

Each rule and scheduled rule has a default event threshold of 1 and deduplication period of 1h. This means all events returning True from the rule function (with the same deduplication string) will be grouped into a single alert within the hour after first being generated.

A rule or scheduled rule with an event threshold of 5 and deduplication period of 15m would not trigger an alert until five or more events (with the same deduplication string) passed into the rule function returned True within a 15-minute time period.

Deduplication period

The detection editor in the Panther Console supports a maximum deduplication period of 24 hours. If you upload your detections via the bulk uploader or the Panther Analysis Tool (PAT), there is no limit on the value of DedupPeriodMinutes.

The deduplication period is not affected by changing the status of an alert. This means, for example, events will continue to be grouped into the same alert for the length of the deduplication period even if an alert's status is changed to Resolved.

How the deduplication string is set

The order of precedence for setting the deduplication string is as follows:

Deduplication string precedence in Python:

  1. Ifdedup() is not defined, the alert title is used. The alert title is defined by the order of precedence defined here.

Deduplication string precedence in Simple Detections YAML:

  1. If GroupBy is not present, the alert title is used. The alert title is defined by the order of precedence defined here.

Which method you use to set the deduplication string depends on how granularly you want to group alerts:

  • If you only want alerts generated by a certain detection to be grouped separately from alerts from other detections, using the detection's display name (given that the display name is unique) or ID as the deduplication string will suffice.

How to write rules and scheduled rules

You can write rules in the Panther Console (using the Simple Detection builder or Python) or locally (in Simple Detections YAML or Python); scheduled rules can be written in Python (in the Panther Console or locally).

Before you start writing a new rule, check to see if there's an existing Panther-managed rule that meets your needs. If you (or Panther) has already created a rule similar to the one you want to build, consider creating a Derived Detection.

Writing detections locally means creating Python and/or YAML files that define a Panther detection on your own machine. After writing detections locally, you upload the files to your Panther instance, typically via PAT.

Note: Anything printed to stdout or stderr by your Python code will end up in CloudWatch. For SaaS/CPaaS customers, Panther engineers can see these CloudWatch logs during routine application monitoring.

How to write rules

These instructions outline how to set up real-time rules. To configure a scheduled rule, see How to write scheduled rules.

Follow the below instructions to learn how to write rules:

How to write scheduled rules

If the Scheduled Search returns multiple rows, each row is processed by the rule logic as a separate event. The number of alerts triggered depends on the deduplication settings you've configured on the scheduled rule.

We recommend doing as much data processing as is possible in SQL (i.e., in the Scheduled Search) in order to take advantage of database optimizations and improve rule performance.

Follow the below instructions to learn how to write scheduled rules:

Rule errors and scheduled rule errors

Rule errors and scheduled rule errors are types of detection errors generated when:

  • A detection's code raises an exception.

  • Python processing of a rule or Scheduled Rule runs longer than 15 seconds.

In the event of a Scheduled Search timeout, a System Error is generated.

Rule examples

See templates for rules and scheduled rules in the panther-analysis GitHub repository.

For in-depth information on how to write detections, see Writing Python Detections and Writing Simple Detections.

Auth0 multi-factor authentication policy disabled

See how one detection is represented in both Python and as a Simple Detection:

Auth0 multi-factor authentication policy disabled detection in Python

View this detection in full in the panther-analysis repository in GitHub.

from global_filter_auth0 import filter_include_event
from panther_auth0_helpers import auth0_alert_context, is_auth0_config_event
from panther_base_helpers import deep_get


def rule(event):
    if not filter_include_event(event):
        return False
    data_description = deep_get(event, "data", "description", default="<NO_DATA_DESCRIPTION_FOUND>")
    request_path = deep_get(
        event, "data", "details", "request", "path", default="<NO_REQUEST_PATH_FOUND>"
    )
    request_body = deep_get(event, "data", "details", "request", "body", default=[-1])
    return all(
        [
            data_description == "Set the Multi-factor Authentication policies",
            request_path == "/api/v2/guardian/policies",
            request_body == [],
            is_auth0_config_event(event),
        ]
    )

Auth0 multi-factor authentication policy disabled detection in Simple Detection YAML

Detection:
  - DeepKey:
      - data
      - description
    Condition: Equals
    Value: Set the Multi-factor Authentication policies
  - DeepKey:
      - data
      - details
      - request
      - path
    Condition: Equals
    Value: /api/v2/guardian/policies
  - DeepKey:
      - data
      - details
      - request
      - body
    Condition: IsNullOrEmpty
  - DeepKey:
      - data
      - details
      - request
      - channel
    Condition: Equals
    Value: 'https://manage.auth0.com/'

Detect and alert when an admin panel is accessed on a web server

As an example, let's write a rule to send an alert when an admin panel is accessed on a web server.

Take the following NGINX log:

{
  "httpReferer": "https://domain1.com/?p=1",
  "httpUserAgent": "Chrome/80.0.3987.132 Safari/537.36",
  "remoteAddr": "180.76.15.143",
  "request": "GET /admin-panel/ HTTP/1.1",
  "status": 200,
  "time": "2019-02-06 00:00:38 +0000 UTC"
}

We want to create a detection that:

  • Looks for 200 (OK) web requests to any URL containing "admin-panel"

  • Generates an an alert title that says there has been successful admin panel logins from a specific IP address

  • Deduplicates events based on IP address

def rule(event):
  return event.get('status') == 200 and 'admin-panel' in event.get('request')

    
def title(event):
  return f"Successful admin panel login detected from {event.get('remoteAddr')}"


def dedup(event):
  return event.get('remoteAddr')
Detection:
  - KeyPath: status
    Condition: Equals
    Value: 200
  - KeyPath: request
    Condition: Contains
    Value: 'admin-panel'

AlertTitle: "Successful admin panel login detected from {remoteAddr}"

GroupBy:
  - KeyPath: remoteAddr

Then, the following would occur:

  1. An alert would be generated and sent to the set of associated destinations, which by default are based on the rule severity.

  2. The alert's title would say, "Successful admin panel login detected from 180.76.15.143".

  3. Similar events with the same deduplication string of 180.76.15.143 would be appended to the same alert.

    • A unique alert will be generated for each unique deduplication string, which in this case, is the IP of the requestor.

  4. The recipient of the alert could then log into Panther to view all alert metadata and a summary of the events, as well as execute searches across all events to perform additional analysis.

Reference

Alert severity

We recommend following these guidelines to define alert severity levels:

Severity

Exploitability

Description

Examples

Info

None

No risk, simply informational

Gaining operational awareness.

Low

Difficult

Little to no risk if exploited

Non-sensitive information leaking such as system time and OS versions.

Medium

Difficult

Moderate risk if exploited

Expired credentials, missing protection against accidental data loss, encryption settings, best practice settings for audit tools.

High

Moderate

Very damaging if exploited

Large gaps in visibility, directly vulnerable infrastructure, misconfigurations directly related to data exposure.

Critical

Easy

Causes extreme damage if exploited

Public data/systems available, leaked access keys.

The complexity of the logic is very high, or the detection requires any of the features currently listed as .

Python rules can also define , and Simple Detections can use . Both can use Inline Filters, which run before detection logic.

Matches on rules and scheduled rules generate signals. When rules and scheduled rules have alerting enabled, rule matches are generated, which can create alerts, according to event threshold and deduplication configurations. .

The output of the dynamic function is used.

In the developer workflow: in the field

If your deduplication threshold is greater than one (meaning multiple events must match before an alert is generated), the first matching event will be used as the event parameter to and .

The output of the dynamic function is used.

The value of the key is used.

If you want alerts generated by a certain detection to be grouped separately not only from alerts generated by other detections, but also from alerts triggered by the same detection where one or more event fields have different values, you can use or (for Python and Simple Detections, respectively) to dynamically set the alert title and therefore, the deduplication string.

If you want to group alerts generated by a certain detection distinctly from alerts generated by the same detection where one or more event field values differ and you want to group the alerts based on one or more event fields that weren't used in title() or AlertTitle (or if you didn't set title() or AlertTitle at all), you can use or (for Python and Simple Detections, respectively) to set the deduplication string.

Scheduled rules are associated with one or more Scheduled Searches. If you have not yet created a scheduled search, follow the instructions first, then return to these instructions to create the scheduled rule.

If no alert destination is configured to receive rule errors (or scheduled rule errors), the alert for a rule error (or scheduled rule error) will be routed to the same destination as the one that would be used for that rule or scheduled rule's alert. See for more information.

Learn more about the difference between signals, rule matches, and alerts here
How to create a Saved and Scheduled Search
title()
dedup()
In Python (in either the Console, or the CLI workflow)
In Python (in either the Console, or the CLI workflow)
Routing order precedence on Alert Destinations
dynamic alert functions
alert functions in Python detections
title()
dedup()
configure them to not generate alerts
In the Simple Detection builder in the Console
limitations of Simple Detections YAML
dynamic alert keys
AlertTitle
alert keys in Simple Detections
GroupBy
AlertTitle
GroupBy
As a Simple Detection in the CLI workflow