Consumption of Shared Security Data

The theme of "your detection is my prevention", whispered among The Enlightened Few of security data sharing, works as a good motivator for both sharing and consuming the shared security information (in this post, BTW, ‘data’ and ‘information’ are used interchangeably). Even if "your detection is my FASTER detection" is what happens in your environment, the value of consuming the data shared by those who already cracked the nut is fairly obvious.

So, how do organizations consume the security data received from others? Apart from blocking (such as dropping IP blacklists in as ACLs and praying that you don’t hit the maximum limit on the device) and searching (such as looking back for an artifact or an activity to check whether it was seen on your network), there are plenty of other uses.

But first, it should be clear that the usage depends on the broad type of data – "bad" IP lists are used in a very different manner compared to, say, threat actor identities and techniques, tactics, and procedures (TTPs). Here in this post, we will primarily focus on the technical data as it is easier to consume, in general.  Examples include IP addresses, domains, email addresses, URLs, SSL certificates, file characteristics, etc. Further, types of technical shared data  (is this a host artifact or a network one? is this a threat indicator or a new detection technique?) also affect where and how it will be used. Finally,  reliability of shared data  (is this “safe to block on the perimeter” or “only for investigations / intelligence gathering”?).

So far in our research, we have observed the following usage of shared technical data:

• Blocking via ACL on routers, firewalls, etc
• Loading into a SIEM – for monitoring, correlation and investigations, “right-click context” and historical searches (a major common use)
• NIPS or SWG proxy watch lists and/or block lists
• Custom NIDS signatures with URLs, file names, etc
• Host scans via endpoint agents (such as for file sizes, names, hashes)
• Custom AV signatures.

These uses of shared data help organizations achieve “noise reduction” (by blocking the stuff that can be safely blocked) and/or dramatically speed up detection of malicious activities in their environments (BTW, here is an example client software that converts data shared via CIF into device rules). It goes without saying that shared technical indicators or other data cannot replace your own "hunting"/exploration activities. If you have something of value to them, there is always a chance that your organization will get hit by something unique.  Even in this case, however, shared non-technical intel will help you optimize your own data exploration activities when nobody will spoon-feed you a file hash to look for…

Finally, a bit of free advice: don’t load a million IP list into a router ACL 🙂

Related posts:

• On Trust in Security Data Sharing
• On Security Data Sharing Research
• On Security Data Sharing
• Our Log Standards Paper Publishes (mentions select data sharing standards such as STIX)
• More on DoS and Shared Security.