Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Examples of Parsing Issues

When you create a log source extension, you might encounter some parsing issues. Use these XML examples to resolving specific parsing issues.

Converting a Protocol

The following example shows a typical protocol conversion that searches for TCP, UDP, ICMP, or GRE anywhere in the payload. The search pattern is surrounded by any word boundary, for example, tab, space, end of line. Also, the character case is ignored:

Making a Single Substitution

The following example shows a substitution that parses the source IP address, and then overrides the result and sets the IP address to 192.0.2.1, ignoring the IP address in the payload.

This example assumes that the source IP address matches something similar to SrcAddress=203.0.113.1 followed by a comma:

Generating a Colon-separated MAC Address

JSA detects MAC addresses in a colon-separated form. Because all devices might not use this form, the following example shows how to correct that situation:

In the preceding example, SourceMAC=12-34-1a-2b-3c-4d is converted to a MAC address of 12:34:1a:2b:3c:4d.

If the dashes are removed from the pattern, the pattern converts a MAC address and has no separators. If spaces are inserted, the pattern converts a space-separated MAC address.

Combining IP Address and Port

Typically an IP address and port are combined into one field, which is separated by a colon.

The following example uses multiple capture groups with one pattern:

Modifying an Event Category

A device event category can be hardcoded, or the severity can be adjusted.

The following example adjusts the severity for a single event type:

<event-match-single event-name="TheEvent" device-event-category="Actual Category" severity="6" send-identity="UseDSMResults" />

Suppressing Identity Change Events

A DSM might unnecessarily send identity change events.

The following examples show how to suppress identity change events from being sent from a single event type and a group of events.

Formatting Event Dates and Time Stamps

A log source extension can detect several different date and time stamp formats on events.

Because device manufacturers do not conform to a standard date and time stamp format, the ext-data optional parameter is included in the log source extension to allow the DeviceTime to be reformatted. The following example shows how an event can be reformatted to correct the date and time stamp formatting:

Multiple Log Formats in a Single Log Source

Occasionally, multiple log formats are included in a single log source.

For example, there are 2 log formats: one for firewall events, and one for authentication events. You must write multiple patterns for parsing the events. You can specify the order to be parsed. Typically, the more frequent events are parsed first, followed by the less frequent events. You can have as many patterns as required to parse all of the events. The order variable determines what order the patterns are matched in.

The following example shows multiple formats for the following fields EventName and UserName

Separate patterns are written to parse each unique log type. Both of the patterns are referenced when you assign the value to the normalized fields.

Parsing a CSV Log Format

A CSV-formatted log file can use a single parser that has multiple capture groups. It is not always necessary to create multiple Pattern IDs when you parse this log type.

The following log sample is used:

  1. Create a parser that matches all relevant values by using the previous patterns.

  2. Place the capture groups around each value:

  3. Map the field that each capture group is mapped to, incrementing the value as you move.

  4. Include the values in the log source extension by mapping the capture group to the relevant event.

    The following code shows a partial example of mapping the capture group to the relevant event.

  5. Upload the log source extension.

  6. Map the events.