When the Splunk App for Enterprise Security correlation rules are triggered by the raw event stream, they create notable events. Notable events are hashed for data protection, see "Configure data protection" in the Installation and Configuration Manual for more information. Notable events, event IDs, and rule IDs can also be used for identification purposes.
Notable events are generated by correlation searches from the raw events in Splunk. As a correlation search recognizes a notable pattern from these raw events, it will create a new notable event in the notable event index. The notable event is hashed at this time and cannot be further changed. Modifying the attributes of a correlation search will not affect notable events that have already been generated and stored.
Event ID management
The event_id field identifies the original event that triggered a rule to alert. All events (whether notable or raw) can have an event_id associated with them. For notable events that fire on single original events, the event_id of the original event is represented in the notable event as "orig_event_id".
This field can be used to associate the original event to the event in the notable index. The event_id field will not be included for correlation searches that look at an aggregate set of events, such as a brute force rule that triggers when a certain number or pattern of log in failures occur.
The rule_id field uniquely identifies all notable events. It is populated by the get_rule_id macro. This macro will populate rule_id with event_id if it exists. However, event_id is not always included and thus you should always use the rule_id field to identify a notable event.
|Purpose:||Unique identifier for all events (notable or otherwise). Will also become "rule_id" if rule_id doesn't exist.||Match a notable event to a particular original event||Uniquely identify a notable event|
|Included when:||When `get_event_id` macro is used to generate it.||When a notable event is associated with a single original event||For all correlation searches|
Managing notable event history
Notable events are associated with users, statuses, and comments. Changing the name of a status will cause the display of previously generated notable events to use the new status name. The stored notable event is associated with a status ID, which is separate from the status name. Changes to the status name flow throughout the user interface without affecting hashed notable events.
Working with notable events from search
Notable events cannot be reviewed from the search tool, but they can be searched for auditing and awareness. To search the existing notable events, use the macro:
The following fields are returned:
|_time||local time when the notable event occurred|
|host||the ES search head that recorded the notable event|
|sourcetype||the notable event sourcetype (always stash)|
|source||the correlation search that generated the notable event|
|src_user||the user that created the correlation search, if applicable|
|dest||the affected destination system, if applicable|
|tag::action||the recorded action, if applicable (same as action)|
|tag::app||the affected app, if applicable|
|tag::eventtype||the type of event, if applicable|
|src||the affected source system, if applicable|
|TaskCategory||the task category, if applicable|
|vendor||the affected vendor, if applicable|
|product||the affected product, if applicable|
|dest_is_expected||a flag indicating if the system is supposed to report to Splunk regularly|
|action||the recorded action, if applicable (same as tag::action)|
|_raw||the raw detail of the notable event|
These fields can be used in the Splunk search pipeline to evaluate and report on generated notable events.
You can also use the
`incident_review` macro to see incident review events. Note that this is not the same thing as listing notable events, the output will not include notable events that have not yet been reviewed:
The returned listing shows any incident review activity. Notable events that have not been reviewed will not be shown in this output.
The following fields are returned:
|_time||local time of the incident review event|
|comment||the reviewer's comment on the notable event at the time of the incident review event|
|owner||the assigned owner of the notable event at the time of the incident review event. This is the account name, to convert to a full name use the `notable_owners` macro.|
|reviewer||the user who performed the incident review event|
|rule_id||the unique event identifier|
|rule_name||the correlation search that generated the notable event|
|status||the numeric status code of the notable event at the time of the incident review event|
|status_default||true/false, whether the notable event is in its default status at the time of the incident review event|
|status_description||the long form description of the notable event status at the time of the incident review event|
|status_end||true/false, whether the notable event is in an end status at the time of the incident review event|
|status_group||Open, New, or Closed|
|status_label||the short form description of the notable event status at the time of the incident review event|
|time||GMT time of the incident review event|
|urgency||the urgency of the notable event at the time of the incident review event|
These fields can be used in the Splunk search pipeline to evaluate and report on notable event incident review activity.
This documentation applies to the following versions of Splunk® Enterprise Security: 3.0, 3.0.1