So within the Enterprise Security App, there is the built-in threat activity dashboard. One of panels shows your sourcetype(firewall) and all the hits the events off that source type match up with a threat activity. What is not showing here is if the event that matched was blocked or allowed. From the query that was being run, I was able to figure out that it was using the Threat Intelligence data model. Within the firewall source type I have, there is a field called status that has passthrough or accept. When doing a search on
index=threat_activity, there is no option here for the status field. I went into the data model of Threat_ Intelligence and searched for the action field using add attribute and saw some fields from my firewall sourcetype, but not status. I added status manually and waited for a refresh and still did not see it coming up.
How can I properly edit this data model to include the specific field action so that I can then edit the query in the threat activity dashboard to filter out blocked events from allowed events?
We are still waiting for an acceptable solution here. Messing with the data models in ES can be tricky...
I had a quick look and the data model Threat Activity is based on the index:
You also mention threat_intelligence in your original post, are you working on the threat acitivty or threat intelligence ?
FInally, something inside ES is populating the threatactivity index, so unless you also update that to populate the data for status into the threatactivity index, the data model will not be updated...
I haven't found how that works...
Actually this already is happening. If you look at the search "Threat - Source And Destination Matches - Threat Gen" this search is matching threat IPs to traffic on your network and is a building block for the datamodel and creates the sourcetype "stash." The search is only looking at "allowed" traffic.
Further the scheduled search is:
| `src_dest_tstats("allowed")` | `truncate_domain_dedup(src)` | `truncate_domain_dedup(dest)` | `threatintel_multilookup(src)` | `threatintel_multilookup(dest)` | search threat_collection_key=* | fields - count | `zipexpand_threat_matches` | fields sourcetype,src,dest,threat*,weight
One option is you could change the "allowed" to blocked. What this would result in is identifying potential high risk endpoints, that while blocked from communicating at this time might be a future indicator or source of compromise.