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
- 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.
Read Complimentary Relevant Research
Five Golden Rules for Creating Effective Security Policy
Policy writing is a risk communication exercise that is frequently performed by people who lack the skills needed to create good security...
View Relevant Webinars
Office 365 and Google Apps for Work: Security Comparison
Google Apps for Work is increasingly a viable option for many businesses as a replacement for Microsoft Office. As CISOs consider their...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.