LIMIT
or GROUP BY
clause.p_any_ip_addresses
is used. Panther extracts a number of common indicator fields over all data sources into standard fields (see Panther Fields).p_any_aws_instance_ids
to easily search over all CloudTrail events for any related activity.p_any_aws_arns
can be used to quickly and easily find all CloudTrail activity related to an ARN of interest (perhaps an ARN of role known to be compromised).p_any_aws_account_ids
(perhaps the account is compromised, where the concern is lateral movement).sourceIPAddress
from within this IP space. You keep a table of these IP blocks in the datalake. NOTE: this example uses a simple equality join operation and assumes that the table of IP blocks are all /32 addresses. In a realistic implementation the IP block table would have CIDR blocks and the check would be to find those not inside the CIDR blocks. This is left as an exercise for the reader.LIMIT
clause or use GROUP BY
aggregations that return limited number of rows (less than a few thousand maximum).sourceIPAddress
dedupe which will only create 1 alert per 30 minutes.aid
. The CMDB has a mapping of aid
to reference data. For this example we will assume it has the attributes employee_name
, employee_group
and last_seen
. The employee related attributes help identify who currently uses the endpoint and the last_seen
is a timestamp we assume is updated by a backend process that tracks network activity (e.g, VPN access, DHCP leases, Authentication, liveliness detections, etc).endpoints
using the employee info for easy vetting. As with all Panther rules, you have the flexibility to customize destinations of alert. For example, if the employee_group
is C-Suite
then perhaps that generates a page to the oncall, while the default alerts simply go to a work queue for vetting the next day.client
information that might indicate stolen credentials. NOTE: the Okta data is very rich in context, this is just one simple example of how to make use of this data.actor
, for up to 30 days in the past:resource_history
table to compute activity statistics that may be of interest to operations as well a security.resource_history
table has detail down to the specific resource, so there are variations of the above query that can be more detailed if desired.snowflake.account_usage
audit database (this may need to be done by the snowflake admins).