“Here is a ‘bad’ IP – let’s ACL the sucker!” thinking is many people’s first experience with technical shared security data. However, as I pointed out in my previous blog post, “Consumption of Shared Security Data”, it is definitely not the only way – and often not the most useful way – of consuming shared technical information (“bad” IPs are also not the only type of such information). Threat indicators (network and host), NIDS/NIPS rules, queries/patterns and other information received from whatever external entity have plenty of uses for detecting, mitigating and investigating incidents. Even simply collecting such external data for future reference during the upcoming investigations (such as “where was this IP seen before?”) often comes handy when you need additional historical context.
However, all the above discussion applies to TECHNICAL information. By ‘technical’ here I mean the types of data consumed, not produced, by the information systems (“boxes”) as opposed to meat and blood humans (excluding cyborgs and androids, presumably ).
The technical indicators that are the easiest to share and consume. Their usefulness is also the most short-lived! URLs that drop binaries may live for hours. Binaries may be used once. Exfiltration upload sites (the “holy grail” of technical indicators, according to some) may survive until the attackers moves the data off your site.
As I was writing this blog post, a blog post from Mandiant came up with the line I really wanted to write myself (and now I can just quote them): “When we talk about threat intelligence, the conversation sometimes gravitates toward signatures or tactical [that I called “technical” – A.C.] indicators that allow security teams to detect more evil: IP addresses, domain names, MD5 hashes, etc. However, real security intelligence does much more than this. It allows us to draw conclusions based on observed data and judge the likelihood of future actions.”
Non-technical data/information/intelligence may include things like actor profiles, TTPs, etc. For example:
- bruting passwords before trying to use exploits
- targeting the information about energetic materials
- often exfiltrating to IPs in “Country X”
- making a particular typo in phishing emails
- communicating with other actors, known to be from “Group Y”
However, these non-technical indicators are not consumed by computers. They are consumed by your threat intelligence team. What? You don’t have such a team? Well, do you have at least “an intelligence dude”? Well… the shared non-technical intelligence has to be used by somebody, and if that somebody does not exist, then you cannot make use of it.
At this point, it should be clear that the real “intelligence-based security” is most definitely not for everybody. I’d be more harsh and say it like this: if you are asking a question “am I ready?”, you probably are not – please patch your Windows boxes at least monthly first
- Consumption of Shared Security Data
- 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.