Raw Threat Intel Docs in Enterprise Security 3.3

For those that would like to visibly see a raw version of STIX/OpenIOC docs being consumed by the Threat Intel Framework in Enterprise Security 3.3, I thought I’d post a bit of an unofficial work around that could potentially be used to do this. It occurred to me that if a user wanted Splunk to index the raw STIX/OpenIOC documents, all they would need to do is have Splunk monitor the Threat Intelligence Manager directory that Enterprise Security is using to consume the OpenIOC/STIX documents. As an example, I will show how this can be done using the “da_ess_threat_default” entry, which is the Threat Intelligence Manager for the STIX documents that Enterprise Security 3.3 ships with out of the box.


Note that by default, none of these entries have the sinkhole parameter set to true. If this parameter is set to true, then ES will delete the intel documents immediately after the intel is extracted from them. This may inhibit what we’re trying to do here so it’s important to ensure that the sinkhole parameter is set to false on the Threat Intelligence Manager directory that you will be indexing the intel documents from.

Moving forward, to monitor the STIX/OpenIOC files that get dropped into the Threat Intelligence Manager directory, we’ll add the following entry to inputs.conf .

disabled = false
sourcetype = raw_intel_docs

Note the sourcetype used in the inputs.conf entry.

By default, Splunk will break the documents at certain points when ingesting them, resulting in a single document being divided into a number of different Splunk events without a simple means of reconstructing them. To prevent Splunk from doing this we’ll add the following props.conf entry, using our defined sourcetype, which will tell Splunk to place the entire document into a single event. Thus giving us one event for every document contained in our Threat Intelligence Manager directory.

MAX_EVENTS = 200000
CHECK_METHOD = modtime

Note that the stanza for our props.conf entry matches the sourcetype of our inputs.conf entry.

This alone will enable users to ingest STIX/OpenIOC documents in Splunk, allowing the entire raw document to be searchable. Now, to further tie it into Enterprise Security, I also created some workflow actions for the Incident Review dashboard that allow users to go straight from the “Threat Activity Detected” notable event to the raw STIX/OpenIOC document in splunk search, or directly to the Threat Artifacts dashboard showing all the intel Enterprise Security was able to extract from that document.

# This workflow action is to go from Incident Review, directly to the indexed RAW STIX/OpenIOC document
display_location = field_menu
fields = threat_source_path
label = View RAW Document
type = link
link.uri = /app/$@namespace$/search?q=source%20%3D%20%22$@field_value$%22

# This workflow action is to go from Incident Review directly to the Threat Artifacts dashboard.
display_location = field_menu
fields = threat_source_path
label = View Related Threat Artifacts
type = link
link.uri = /app/$@namespace$/threat_artifacts?form.threat_source_path=$@field_value$

These workflow actions will work off the “Threat Source Path” field under the “Threat Activity Detected” notable event:



View RAW Document



View Related Threat Artifacts:



One last note: All of the conf entries used in the example were added to their respective conf files under the $SPLUNK_HOME/etc/apps/DA-ESS-ThreatIntelligence/local/ directory.