Data Models
Data Models provide a way to configure a set of unified fields across all log types
Last updated
Data Models provide a way to configure a set of unified fields across all log types
Last updated
Data Models provide a way to configure a set of unified fields across all log types.
Suppose you want to check for a particular source ip address in all events that log network traffic. These LogTypes might not only span different categories (DNS, Zeek, Apache, etc.), but also different vendors. Without a common logging standard, each of these LogTypes may represent the source ip by a different name, such as ipAddress
, srcIP
, or ipaddr
. The more LogTypes you want to monitor, the more complex and cumbersome this simple check becomes:
If instead we define a Data Model for each of these LogTypes, we can translate the unified data model field name to the LogType field name and our logic simplifies to:
Data Models for detections are different from the Panther Unified Data Model fields (also known as Core Fields). To learn more, see Core Fields vs. Data Models in Python detections.
By default, Panther comes with built-in data models for several log types, such as AWS.S3ServerAccess
, AWS.VPCFlow
, and Okta.SystemLog
. All currently supported data models can be found here.
New Data Models are added in the Panther Console or via the Panther Analysis Tool. Each log type can only have one enabled data model specified. If you want to change or update an existing data model, disable
the existing one, and create a new, enabled one.
To create a new Data Model in the Panther Console:
Log in to your Panther Console and navigate to Build > Data Models.
.
In the upper right corner, click Create New.
Fill in the fields under Settings and Data Model Mappings.
In the upper right corner, click Save.
You can now access this Data Model in your rule logic with the event.udm()
method.
Use your Data Model in a rule via any of the following methods:
Add the LogType under the Rule specification LogType
field
Add the LogType to all the Rule's Test
cases, in the p_log_type
field
Leverage the event.udm()
method in the Rule's python logic:
See examples of Data Models in Panther's Github repository.
Rules can be updated to use unified data model field names by leveraging the event.udm()
method. For example:
Update the rule specification to include the pertinent LogTypes:
Panther provides a built-in method on the event object called event.udm_path
. It returns the original path that was used for the Data Model.
Using event.udm_path('destination_ip')
will return 'dstAddr'
, since this is the path defined in the Data Model for that log type.
The following example uses event.udm_path
:
This test case was used:
The test case returns an alert that includes Alert Context with the datakey
and datavalue
:
A complete list of DataModel specification fields:
Field Name
Required
Description
Expected Value
AnalysisType
Yes
Indicates whether this specification is defining a rule, policy, data model, or global
datamodel
DataModelID
Yes
The unique identifier of the data model
String
DisplayName
No
What name to display in the UI and alerts. The DataModelID
will be displayed if this field is not set.
String
Enabled
Yes
Whether this data model is enabled
Boolean
FileName
No
The path (with file extension) to the python DataModel body
String
LogTypes
Yes
What log type this policy will apply to
Singleton List of strings
Note: Although LogTypes
accepts a list of strings, you can only specify 1 log type per Data Model.
Mappings
Yes
Mapping from source field name or method to unified data model field name
List of Maps
Mappings translate LogType fields to unified data model fields. Each mapping entry must define a unified data model field name (Name
) and either a Path (Path
) or a method (Method
). The Path
can be a simple field name or a JSON Path. The method must be implemented in the file listed in the data model specification Filename
field.
For more information about jsonpath-ng, see pypi.org's documentation here.
The initial set of supported unified data model fields are described below.
Unified Data Model Field Name
Description
actor_user
ID or username of the user whose action triggered the event.
assigned_admin_role
Admin role ID or name assigned to a user in the event.
destination_ip
Destination IP for the traffic
destination_port
Destination port for the traffic
event_type
Custom description for the type of event. Out of the box support for event types can be found in the global, panther_event_type_helpers.py
.
http_status
Numeric http status code for the traffic
source_ip
Source IP for the traffic
source_port
Source port for the traffic
user_agent
User agent associated with the client in the event.
user
ID or username of the user that was acted upon to trigger the event.