Writing Custom Parsing Rules in McAfee ESM
Writing Custom Parsing Rules in McAfee ESM
Writing Custom Parsing Rules in McAfee ESM
2 Prerequisites
The following will be required, or useful, in creating custom parsing rules:
A sample of the log to parse.
Account privileges to add data sources. In some cases, administrator privileges, such as
the ability to define custom types may also be needed.
Vendor documentation can be helpful to determine the meaning of each field in the
logs desired to be parsed.
A working knowledge of PCRE (Perl Compatible Regular Expressions).
2. The Add Data Source window will open, set the Data Source Vendor as Generic and the
Data Source Model as Advanced Syslog Parser. Give the new data source a name, add
the proper IP address, and ensure that the Support Generic Syslogs field is left as Do
nothing.
3. Select OK, and then apply the new data source settings by confirming in the next
window. This will create a new data source with an empty rule policy.
2. The Policy Editor window should appear. In the menu on the left, expand Receiver by
selecting the + symbol, and select Advanced Syslog Parser. Initially this list will be
blank while looking at the policy for the new data source.
Name Assign a name, making it as descriptive and unique as possible. This is the
event message that will show in the ESM views when the rule matches a log, unless the
message is mapped directly from the log text within the rule.
Tags Assign tags to the rule. It is best practice to assign one or more tags to which this
rule belongs. This helps in finding and grouping sets of rules created for a given device
or application within the policy editor. Any tags added to a rule, will cause ESM to
automatically include the rule in any policy that has enabled the given tagged rule set.
Default Normalized ID The normalization or category is a key step as many views,
correlation rules, and reports use this field as a filter. It is very important to select the
most relevant value in the taxonomy for the parsing rule in order to get the greatest
value from within the McAfee ESM.
Default Severity If the log message does not contain a value for the severity, then the
event will be assigned the value that is set here (the default is 25, with a scale of 1-100,
1 being the lowest and 100 being the highest).
Rule Assignment Type Rules can be grouped together; this pull-down menu provides
a list of supported products to group the parsing rules by, separating the events from
other data sources. This allows the event to be reported for a specific product.
Description Give the new rule a clear human-readable description. It should be a clear
and complete description of the rule with complementary information to what was
given in the rules name.
Process Name This is an optional filter that acts similar to the content string, but only
applies to the process name found within the SYSLOG header. Due to various syslog
header formats used, and no guarantee that a syslog header will be present in the log, it
is recommended to use content strings instead of the process name match.
Content String If a fixed string is always going to be found in the log then add it as a
content string. The content string(s) of an ASP rule should uniquely identify each log if
possible. Content strings are very important as they will not only make matches more
accurate, but will speed up the execution of the rules in the running policy. It is highly
recommended to have one or more content strings per ASP rule. This is a pre-filter for
optimization only logs that match the given content strings will be considered for
matching and parsing by the regular expressions. The log must contain all given content
strings, otherwise the logs will not be parsed using the regular expressions.
Regular Expression The first regular expression determines if the ASP rule will match
the log. Any additional expressions will be used to capture values from the log that may
or may not be found in all logs.
Named Captures Named captures can be used in regular expressions to more easily
identify capture groups. The label used for the named capture can consist of alpha-
numeric and underscore characters but cannot begin with a number or include a space.
The regular expression syntax for a named capture is: (?P<NAME>regular expression
capture). Here is an example of a named capture where hostname is the name
assigned to the capture group: Host\x3d(?P<hostname>\S+). When using named
captures the policy editor will display the capture name instead of the capture number,
in the right-hand side of the Parsing tab as shown below.
The information contained in this document is confidential and proprietary.
Please do not redistribute without permission.
In the image below, the named capture group full_name has a value of Sam Johnson.
This named capture is being used as the Target Key for the first_name and last_name
targeted regular expressions. The regular expression for first_name and last_name will
be evaluated against the value of the full_name named capture. The result shows the
key of first_name:1 with a value of Sam and last_name:1 with a value of Johnson.
This specific example could be done within a single regular expression, and is a
simplified example to illustrate the purpose of the Target Key field used with regular
expressions. In general, it is recommended to run as few regular expressions as
possible, but that may vary with specific use cases.
Only use regular expressions for parsing purposes Checking this box will remove the
requirement for the first regular expression to match the log. The parser will rely upon
the Content String for matching purposes, and will only use regular expressions to
parse data when it finds a matching pattern.
Case Insensitive If the log may contain either upper or lower case letters in some
fields, it may be simpler to write the expression in the same case and then use this
option. This enables the case insensitivity option for all regular expressions defined in
the parsing rule.
Trigger when data doesnt match This option will make the rule trigger when the
regular expression does not match the log.
a. The Edit Regular Expression window will appear. Add the expression and
select OK.
8. With the expression added, the parsed values should be highlighted in blue, with the
Group and Value shown to the right. Verify that each value is parsed out correctly and
that all of the log line samples match. Make sure to know the meaning (from the vendor
device documentation or own knowledge) of all the fields within the logs and capture
the values that are useful.
The information contained in this document is confidential and proprietary.
Please do not redistribute without permission.
11. Drag and drop the Values from the right hand side to the Expression column next to
the Field on the left.
a. For more complicated log file formats, multiple regular expressions may be
used to capture the same data. In such cases, a field such as First Time might
come from one of several potential several expressions. McAfee ESM allows the
ability to specify the regular expression values in order of preference, so that if
one does not match, it will use the second, or third, or so on. An example of this
is shown below:
12. If the field is not displayed that is needed, click + above the Sample Value column, to
display all custom type fields.
13. The Custom Types window will now be displayed. Select the desired field and then
select OK.
b. Enter a custom time format. As the values are entered, a small window will
appear to assist in creating the custom time. The values can either be typed or
selected from the given list.
c. Select the fields that this custom format will apply to. It is best practice to apply
it to both First Time and Last Time.
d. Select OK to save.
17. To add an Action Map, find an applicable Action Value by scrolling through the list and
then click inside the Action Key column. Enter the value that will be parsed from the
device logs. If this value is parsed and assigned to Action, then it will map to the
assigned Action Value.
18. To add a Severity Mapping, select the + symbol in the upper-right of the Severity
Mapping section.
b. Within the Severity Mapping field, enter the value that will be parsed from the
device logs. If this value is parsed and assigned to Severity, then it will map to
the assigned Severity Value.
c. Move the sliding scale to the desired Severity Value.
d. Select OK to save.
19. Below the Severity Mapping section, the option to add a default severity will be given.
This is generally a good option to set in order to insure that all logs receive a severity
value. Depending on the device, the default severity should be different. To add the
default severity, place a check next to Use the following severity for the default if one
is not specified, and then enter a default value.
20. With the previous steps complete, the new ASP rule should be finished. Select Finish,
located in the bottom-right hand corner to finish and save.
2. With the new rule set as enabled, click on the Rollout icon displayed in the upper-right
hand corner of the Policy Editor window.
3. If the rule didnt already save previously, it will prompt to save. Select Yes to save.
4. Once saved, the Rollout window will appear and will display a list of devices to roll
policy out to. Ensure that the applicable data source is set to Roll this policy out now.
and select OK to do so.
1. Select the Custom Types option from the menu on the left.
Note: Select the Edit option to edit a user defined pre-existing custom type if
needed.
3. The Add Custom Type window will appear. Setup the new custom type as desired and
select OK.
3. The Data Source Properties window will appear, select the Upload button.
4. Navigate to the log sample file and select it to upload. Select the Upload button and
then a confirmation window will be displayed showing the file was successfully
uploaded. Select Close to close out the window.
6. The Get Events and Flows window will appear. Select Events and then click the Start
button to collect the events.
7. Once the events are collected, find the events in the dashboard and verify the newly
created ASP rule is parsing as expected. If any adjustments need to be made, make the
changes and then send the sample logs through again to verify that the rule is parsing
as expected.
The table below shows an example of how to use the content field to uniquely identify a log
sample.
Syslog Sample Content Fields