Overriding and Extending Global Parsers

custom parsers integrations

Overview ⫘

XDR offers customers the ability to both extend and override global parsers.

Create a New Parsers to Extend or Override a Global Parser

What is a Global Parser? ⫘

The term global parser refers to a parser that is built into the XDR platform. Global parsers are available to all XDR customers and cannot be modified.

Use Cases ⫘

Overriding an Existing Global Parser ⫘

This allows you to override an existing global parser in rare cases where the global parser behavior does not provide expected results for your data. If selected, you will be required to add !PARENT=<name> in your parser script, where <name> is the name of the global parent parser. The Name of the override global parser must be the same as the name of the Global Parser Name. The !PARENT= statement works in conjunction with the Set Global Parent in Parser Script setting, which is enabled automatically when Override Global Parser is enabled.

Example ⫘

Your data's timestamp is not provided in UTC, but the global parser expects UTC time, so you plan to alter the eventTimeUsec$ calculation to add/remove microseconds for your timezone offset so that your timestamps are properly converted to UTC. In this example, a custom parser is created to override a global parser that expects the log message timestamp to be in UTC.

1. Create the new parser with the Override Global Parser setting enabled.

Create Override Parser

2. Set the !PARENT= value, calculate the timestamp (epoch time) based on UTC time zone offset, then normalize the calculated timestamp.

Override a Global Parser

3. Select Run Test and verify:

• That the Extractor path is correct. The Extractor path reflects the route a log message takes through the XDR parsers.
• That the timestamp has been converted as expected.

Verify the Extractor Path and the Normalized Value are Correct

Extending an Existing Global Parser ⫘

This allows you to create extensions (child parsers) for new/unsupported event types of global parent parsers (e.g., an uncommon Windows Event ID sent by Snare), which are not available in the parent parser drop-down. If selected, you will be required to add !PARENT=<name> in your parser script, where <name> is the name of the global parent parser for your new custom child parser. The !PARENT= statement works in conjunction with the Set Global Parent in Parser Script setting.

Example ⫘

In this example, a custom parser is created as the child of a global parser to normalize an event type not normalized by XDR.

1. Create the new parser with the Set Global Parent in Parser Script setting enabled.

Create Parser to Extend a Global Parser

2. Set the !PARENT= value and normalize the desired fields.

Set Global Parent

3. Select Run Test and verify:

• That the Extractor path is correct. The Extractor path reflects the route a log message takes through the XDR parsers.
• That the desired fields are normalized as expected.

Verify the Extractor Path and the Normalized Value are Correct