The Policy Builder allows administrators who are not familiar with Regex to create custom policies for log source types that Axon does not support out of the box. The administrator uses a raw log message from an unidentified log to create a new log source type and build a processing policy for that log source type. This processing policy should include identification rules that recognize when incoming log messages match the specified log source type. It should also include normalization rules that determine how the log message data is parsed and mapped to the Axon Data Schema fields.
Policy Builder Workspace
Sample Log Message
On the left side of the Policy Builder workspace, the Sample Log Message panel displays the raw log message you are using to create your policy. You can edit the sample log message in real time. You can also completely replace your sample log message with another raw log message.
Axon recognizes the sample log message format and separates the log data into structured field/value pairs in Message Interpreter panel. The Message Interpreter panel appears in the middle of the Policy Builder workspace. This where you select fields from the log message and apply the rules used to build your processing policy. The first line in the Message Interpreter indicates the overall message format Axon used to parse the sample log message into field/value pairs. The Message Interpreter also recognizes child relationships and arrays within the raw log message and organizes the data accordingly. Axon typically parses the sample log message into one of the following overall message formats:
- CEF (Common Events Format)
- DSV (Delimited Separated Value)
- Key Value (KV)
The Message Interpreter also allows you to apply additional text processors to individual data elements within the overall message format. For more information on text processors, see Text Processors.
Identification, Normalization, and Common Event Rules
The right side of the Policy Builder workspace displays the details on your identification, normalization, and common event rules as you create them from the Message Interpreter. The top panel contains three tabs with a list of identification rules, a list of the normalization rules, and a list of common event rules. These lists update in real time as you create your rules. The bottom panel shows a preview of how your identification, normalization, and common event policies will be applied when you publish the message processing policy.
The identification policy determines which log source type a raw log message matches to ensure the log data is parsed and mapped correctly to the Axon Data Schema fields. You build your identification policy by creating identification rules from the Message Interpreter. Each identification rule you create appears in the Identification Rules tab in the top panel. The Policy Results Preview panel also displays a Match/No Match indicator. This indicator tells you if the values in the sample log message match the values in your identification rules.
The Match/No Match indicator becomes more useful as your identification rules get more complicated.
The normalization policy determines how to process the log message and map the log data to the Axon Data Schema fields. Normalization rules specify how a field in the raw log message is extracted and mapped to a field within the Axon Data Schema. Each normalization rule you create appears in the Normalization Rules tab in the top panel. As you create your normalization rules, the Policy Results Preview panel displays the Internal Database Field you have chosen next to the value you extracted from the sample log message.
Common Event Policy
A common event policy allows you to select from a host of pre-configured rules that cover a wide variety of log messages out of the box. These common events are designed to be easy to grasp, allowing for quick understanding of the meaning of a log message without any special knowledge. Common event rules can belong to a number of categories, including Authentication, Policy Management, and Threat Detection. Once a general common event has been assigned to a policy, additional rules can be created to determine conditional assignments if certain prerequisites are met.