Custom Properties, Extracted Properties, and Parsing
Parsing questions test whether you can pull a field out of a raw event and make it searchable.
Core rules
- A Custom Event Property is defined in Admin > Custom Event Properties using a regex over a field or the payload; an Extracted Property is defined in the DSM Editor or Log Source Extension and uses a capture group.
- Processing order matters: the DSM parses first, then custom/extracted properties run against the parsed or raw data.
- Use explicit capture groups and anchor patterns; test with a real sample in DSM Editor.
- Declare the correct type (IP, port, numeric, string) so searches and rules behave correctly.
- Properties become available to rules, searches, reports, and offense naming.
Worked example
A log contains user=bob and the regex user=(\S+) with capture group 1 yields bob. If the property is empty, first confirm Store Event Payload is enabled, then test the exact payload in DSM Editor. A common cause is applying the property to the wrong log source type, so the DSM never runs it.
Traps
- Using a greedy pattern that captures trailing text.
- Selecting the wrong capture group.
- Assuming properties are retroactive; old events are not re-parsed.
- Case sensitivity or whitespace differences in the sample.
- Editing a DSM globally when a Log Source Extension would be safer.