I see folks ask a lot about adding fields not originally in a notable to the notable in incident review in SplunkES. The initial idea people have is that if they make an adaptive response action that it magically go get more data and have it show up for that notable event. The seed of the idea is there, but it does not work on its own.
Let’s go backwards through this.
Follow the ES Docs on adding a field to display in incident review IF it is in the notable and has a value. https://docs.splunk.com/Documentation/ES/latest/Admin/CustomizeIR
That means normally the field has to be present already in the notable to be displayed . Bear with me. This is the first step and we can actually make fields show up that are NOT already in the notable event. Let’s say we added the field support_ticket to Incident Review Settings.
Next a magic trick that has nothing to do with adaptive responses. You CAN make new fields not in the notable show up if you have them added above AND you use a lookup. This is what most folks do not know.
Prior to ES 4.6 there was a macro that drives the content display for Incident Review called “Incident Review – Main”. This became a search with v4.6.
<<IMAGE NOT ARCHIVED>>
The default search looks like:
$time_filter$ index="notable" $source_filter$ | eval `get_event_id_meval`,rule_id=event_id | search $event_id_filter$ | fields - host_* | tags outputfield=tag | `mvappend_field(tag,orig_tag)` | dedup rule_id | `notable_xref_lookup` | `get_correlations` | search $security_domain_filter$ | `get_current_status` | search $status_filter$ | `get_owner` | search $owner_filter$ | `get_urgency` | search $urgency_filter$ | typer | tags outputfield=tag | `mvappend_field(tag,orig_tag)` | search $tag_filter$ | `suppression_extract` | search NOT suppression=* | `risk_correlation` | sort 0 -_time
We can cleanly insert our own lookup by making a macro for it and shimming it into the Incident Review – Main search. Just make sure your lookup, macro permissions are set right and everyone in ES can read it.
Presume we have a lookup that somehow has event_id to support_ticket mapped. Since we have event_id for a notable event the lookup can return the field support_ticket.``
We define a macro for the lookup command: get_support_ticket
lookup ticketTable event_id OUTPUTNEW support_ticket
We shim that macro into the Incident Review – Main search:
Note I put it after the suppression filter.
$time_filter$ index="notable" $source_filter$ | eval `get_event_id_meval`,rule_id=event_id | search $event_id_filter$ | fields - host_* | tags outputfield=tag | `mvappend_field(tag,orig_tag)` | dedup rule_id | `notable_xref_lookup` | `get_correlations` | search $security_domain_filter$ | `get_current_status` | search $status_filter$ | `get_owner` | search $owner_filter$ | `get_urgency` | search $urgency_filter$ | typer | tags outputfield=tag | `mvappend_field(tag,orig_tag)` | search $tag_filter$ | `suppression_extract` | search NOT suppression=* | `get_support_ticket` | `risk_correlation` | sort 0 -_time
Now magically if a notable’s event_id value is added to the lookup, next time someone views that notable in Incident Review they will see the new field support_ticket. If you are clever you can add a workflow action on the support_ticket field to open that ticket via URL in the ticketing system.
The above is helpful already. Think of having a lookup of your cloud account IDs for AWS, Azure etc with all sorts of contact and context. Have that field cloud_account_id show in your notables and the above auto lookup can make more context show for your SOC team.
Now you can go further by writing a custom alert action using Splunk Add-On builder setup with Adaptive Response support. The code can get data from an external system based on data in the notable event. You could then index that returned data and have a search run across that to maintain a lookup table using outputlookup. Alternatively, you can update KVStore based lookups directly via the Splunk API. If you are willing to dig into the code you can see something similar with my TA-SyncKVStore app modular alert for Splunk.
Combining all that would let an adaptive response fetch data, store it in Splunk and have it display automatically on existing Notable Events within Incident Review.
Good Luck!