Standard Fields

Panther's log analysis applies normalization fields to all log records

Panther's log analysis applies normalization fields (IPs, domains, etc) to all log records. These fields provide standard names for attributes across all data sources enabling fast and easy data correlation.

For example, each data source has a time that an event occurred, but each data source will likely not name the attribute the same, nor is it guaranteed that the associated time has a timezone consistent with other data sources.

The Panther p_event_time attribute is mapped to each data source's corresponding event time and normalized to UTC. This means while querying multiple data sources, you can join and order by p_event_time, despite the disparate schemas of each data source.

All appended standard fields begin with p_.

Required Fields

The fields below are appended to all log records:

Field name	Type	Description
p_log_type	string	The type of log.
p_row_id	string	Unique id (UUID) for the row.
p_event_time	timestamp	The associated event time for the log type is copied here and normalized to UTC. Format: YYYY-MM-DD HH:MM:SS.fff
p_parse_time	timestamp	The current time when the event was parsed, normalized to UTC. Format: YYYY-MM-DD HH:MM:SS.fff
p_schema_version	integer	The version of the schema used for this row.
p_source_id	string	The Panther generated internal id for the source integration.
p_source_label	string	The user supplied label for the source integration (may change if edited).
p_source_file	object	Available for S3 sources only, this field contains metadata of the file that this event originated from, including the bucket name and object key.

If an event does not have a timestamp, then p_event_time will be set to p_parse_time, which is the time the event was parsed.

The p_source_id and p_source_label fields indicate where the data originated. For example, you might have multiple CloudTrail sources registered with Panther, each with a unique name (e.g., "Dev Accounts", "Production Accounts", "HR Accounts", etc.). These fields allow you to separate data based on the source, which is beneficial when configuring detections in Panther.

In addition, the fields below are appended to log records of all tables in the panther_rule_matches database:

Field name in panther_rule_matches	Type	Description
p_alert_id	string	Id of alert related to row.
p_alert_creation_time	timestamp	Time of alert creation related to row.
p_alert_context	object	A JSON object returned from the rule's alert_context() function.
p_alert_severity	string	The severity level of the rule at the time of the alert. This could be different from the default severity as it can be dynamically set.
p_alert_update_time	timestamp	Time of last alert update related to row.
p_rule_id	string	The id of the rule that generated the alert.
p_rule_error	string	The error message if there was an error running the rule.
p_rule_reports	map[string]array[string]	List of user defined rule reporting tags related to row.
p_rule_severity	string	The default severity of the rule.
p_rule_tags	array[string]	List of user defined rule tags related to row.

Indicator Fields

A common security question is, “Was some indicator ever observed in any of our logs?” Panther's Search tool enables you to find the answer by searching across data from all of your various log sources.

As log events are ingested, the indicators field in their corresponding schema identifies which fields should have their values extracted into p_any_ fields, which are appended to and stored with the event. The table below shows which p_any_ field(s) data is extracted into, by indicator. All p_any_ fields are lists.

When constructing a custom schema, you can use the values in the Indicator Name column in the table below in your schema's indicators field. Each of the rows (except for hostname, net_addr, and url) corresponds to a "Panther Fields" option in Search.

Note that field name/value pairs outside of the fields in the table below can be searched with Search's key/value filter expression functionality—though because those fields have not been mapped to corresponding ones (with different syntax) in different log sources, only matches from log sources containing the exact field name searched will be returned.

In order for a field to be designated as an indicator in a schema, it must be type string.

Indicator Name	Extracted into fields	Description
actor_id	p_any_actor_ids	Append value to p_any_actor_ids.
aws_account_id	p_any_aws_account_ids	If the value is a valid AWS account id, append to p_any_aws_account_ids.
aws_arn	p_any_aws_arns, p_any_aws_instance_ids, p_any_aws_account_ids, p_any_emails	If value is a valid AWS ARN then append to p_any_aws_arns. If the ARN contains an AWS account id, extract and append to p_any_aws_account_ids. If the ARN contains an EC2 instance id, extract and append to p_any_aws_instance_ids. If the ARN references an AWS STS Assume Role and contains and email address, then extract email address into p_any_emails.
aws_instance_id	p_any_aws_instance_ids	If the value is a valid AWS instance id then append to p_any_aws_instance_ids.
aws_tag	p_any_aws_tags	Append value into p_any_aws_tags.
cve	p_any_cves	Extract any values matching the regex ^[Cc][Vv][Ee]-\d{4}-\d+$ and append to p_any_cves
domain	p_any_domain_names	Append value to p_any_domain_names.
email	p_any_emails	If value is a valid email address then append value into p_any_emails. The portion of the value that precedes @ will also be populated in p_any_usernames
hostname	p_any_domain_names, p_any_ip_addresses	Append value to p_any_domain_names. If value is a valid ipv4 or ipv6 address then append to p_any_ip_addresses.
ip	p_any_ip_addresses	If value is a valid ipv4 or ipv6 address then append to p_any_ip_addresses.
mac	p_any_mac_addresses	If a value is a valid IEEE 802 MAC-48, EUI-48, EUI-64, or a 20-octet IP over InfiniBand link-layer address then append to p_any_mac_addresses.
md5	p_any_md5_hashes	If the value is a valid md5 then append value into p_any_md5_hashes.
mitre_attack_technique	p_any_mitre_attack_techniques	Extract any values matching the regex \b[Tt]\d{4}(?:\.\d{3})?\b and append to p_any_mitre_attack_techniques. For example, if the field value is "Technique: T1234", p_any_mitre_attack_techniques would have a value of ["T1234"]
net_addr	p_any_domain_names, p_any_ip_addresses	Extracts from values of the form <host>:<port> and appends host portion to p_any_domain_names. If host portion is a valid ipv4 or ipv6 address, then append to p_any_ip_addresses.
serial_number	p_any_serial_numbers	Append value to p_any_serial_numbers. This feature is in closed beta starting with Panther version 1.69. To share any bug reports or feature requests, please contact your Panther support team.
sha1	p_any_sha1_hashes	If the value is a valid sha1 then append to p_any_sha1_hashes.
sha256	p_any_sha256_hashes	If the value is a valid sha256 then append to p_any_sha256_hashes.
trace_id	p_any_trace_ids	Append value to p_any_trace_ids. Tag fields such as session ids and document ids that are used to associated elements with other logs in order to trace the full activity of a sequence of related events.
url	p_any_domain_names, p_any_ip_addresses	Parse url, extract the host portion after "http://" or "https://". Append host portion to p_any_domain_names. If host portion is a valid ipv4 or ipv6 address then append to p_any_ip_addresses.
username	p_any_usernames	Append value into p_any_usernames. This field is also populated with values marked with the email indicator. The portion of the email value that precedes @ will be appended to this field.

Enrichment Fields

The Panther rules engine will take the looked-up matches from Lookup Tables and append that data to the event using the key p_enrichment in the following JSON structure:

{ 
    'p_enrichment': {
        <name of lookup table>: { 
            <key in log that matched>: <matching row looked up>,
            ...
	    <key in log that matched>: <matching row looked up>,
        }    
    }
} 

Enrichment Field Name	Type	Description of Enrichment Field
p_enrichment	object	Dictionary of lookup results where matching rows were found.
p_match	string	p_match is injected into the data of each matching row within p_enrichment. Its value is the value that matched in the event.

The "all_logs" view

Panther manages a view over all data sources with standard fields.

This allows you to answer questions such as, "Was there any activity from some-bad-ip, and if so, where?"

The query below will show how many records, by log type, are associated with the IP address 95.123.145.92:

SELECT
 p_log_type, count(1) AS row_count
FROM panther_views.public.all_logs
WHERE p_occurs_between('2020-1-30', '2020-1-31')
     AND array_contains('95.123.145.92'::variant, p_any_ip_addresses)
GROUP BY p_log_type

From these results, you can pivot to the specific logs where activity is indicated.

Standard Fields in detections

The Panther standard fields can be used in detections.

For example, the Python rule below triggers when any GuardDuty alert is on a resource tagged as Critical:

def rule(event):
    if 'p_any_aws_tags' in event:
        for tag in event['p_any_aws_tags']:
            if 'critical' in tag:
                return True
    return False