Policies
Scan and evaluate cloud infrastructure configurations
Last updated
Was this helpful?
Scan and evaluate cloud infrastructure configurations
Last updated
Was this helpful?
Policies are used to identify misconfigured cloud infrastructure and generate alerts for your team. Panther provides a number of already written and continuously updated .
Policies may be written as ; they cannot be written as .
Before you start writing a new policy, remember to check to see if there's an existing that meets your needs.
The policy body must:
Be valid Python3.
Define a policy()
function that accepts one resource
argument.
Each policy takes a resource
input of a given resource type from the page.
Return a bool
from the policy function.
The Python body should name the argument to the policy()
function resource
and also may do the following:
Import standard Python3 libraries
Import from the user defined aws_globals
module
Import from the Panther defined panther
module
Define additional helper functions as needed
Define variables and classes outside the scope of the rule function
In the left-hand navigation bar of your Panther Console, click Build > Detections.
In the upper-right corner, click Create New.
At the top of the page, choose Policy as the detection type.
In the Basic Info section, provide values for the following fields:
Name: Enter a descriptive name for the policy.
ID (optional): Click the pen icon and enter a unique ID for your policy.
In the upper-right corner, click Continue.
On the next page, configure your policy:
In the upper-right corner, the Enabled toggle will be set to ON
by default. If you'd like to disable the policy, flip the toggle to OFF
.
In the For the Following Resource Types section:
Resource Types: Select one or more resource types this policy should apply to. Leave empty to apply to all resources.
In the Detect section:
In the Policy Function text editor, write a Python policy
function to define your detection.
In the Set Alert Fields section:
In the Optional Fields section, optionally provide values for the following fields:
Description: Enter additional context about the policy.
Runbook: Enter the procedures and operations relating to this policy.
Reference: Enter an external link to more information relating to this rule.
Ignore Patterns: Enter patterns to ignore.
Custom Tags: Enter custom tags to help you understand the rule at a glance (e.g., HIPAA
.)
In the Framework Mapping section:
Click Add New to enter a report.
Provide values for the following fields:
Report Key: Enter a key relevant to your report.
Report Values: Enter values for that report.
In the Test section:
In the upper-right corner, click Save.
Manually building test cases can be prone to human error. We suggest one of the following methods:
Option 1: In the Panther Console, navigate to Investigate > Cloud Resources. Apply a filter of the resource type you intend to emulate in your test. Select a resource in your environment, and on the Attributes
card you can copy the full JSON representation of that resource by selecting copy button next to the word root
.
Option 1 is best when it is practical, as this can provide real test data for your policies. Additionally, it is often the case that you are writing/modifying a policy specifically because of an offending resource in your account. Using that exact resource's JSON representation as your test case can guarantee that similar resources will be caught by your policy in the future.
Debugging exceptions can be difficult, as you do not have direct access to the Python environment running the policies.
Running this test case either locally or in the Panther Console should provide more context for the issue, and allow you to modify the policy to debug the exception without having to run the policy against all resources in your environment.
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.
In the example below, the policy checks if an S3 bucket allows public read access:
This example policy alerts when the password policy does not enforce a maximum password age:
In the policy()
body, returning a value of True
indicates the resource is compliant and no alert should be sent. Returning a value of False
indicates the resource is non-compliant.
Using the schemas in provides details on all available fields in resources. Top level keys are always present, although they may contain NoneType
values.
The order of precedence for setting the alert title for policies is the same as it is for Rules and Scheduled Rules—see the section.
You can write and deploy policies in the Panther Console or you can write them locally and upload them to Panther using the CLI workflow:
For detection templates and examples, see the
Severity: Select a for the alerts triggered by this detection.
To see examples of runbooks for built-in rules, see .
Destination Overrides: Choose destinations to receive alerts for this detection, regardless of severity. Note that destinations can also be set dynamically, in the rule function. See to learn more about routing precedence.
In the Unit Test section, click Add New to for the policy you defined in the previous step.
It's best practice to create a fork of Panther's , but you can also create your own repo from scratch.
We recommend grouping policies into folders based on log/resource type, e.g., suricata_rules
or aws_s3_policies
. You can use the open source repo as a reference.
See the full for a complete list of required and optional fields.
Option 2: Open the Panther , and navigate to the section for the resource you are trying to emulate. Copy the provided example resource. Paste this in to the resource editor if you're working in the web UI, or into the Resource
field if you are working locally. Now you can manually modify the fields relevant to your policy and the specific test case you are trying to emulate.
When you see a policy that is showing the state Error
on a given resource, that means that the policy threw an exception. The best method for troubleshooting these errors is to use option 1 in the section above and create a test case from the resource causing the exception.
The policy is based on an resource:
See the full .