Derek Banks //
John’s hating on threat intelligence feeds post got me thinking. As a former blue team member that is now solidly purple team, I do not hate threat intelligence (sorry, John). But, I am not going to disagree with John’s take (and not just because he signs my paychecks), because he’s right.
Paying for a feed of blacklisted IP addresses and domain names and ingesting that firehose of data into a security device to detect or prevent it, and slapping a threat intelligence label on it, is not all that effective. Purchasing the latest super-appliance that promises to stop all advanced attacks before the attacker even thinks about it while drinking his morning coffee is not going to actually going to stop a determined attacker.
If this is your organization’s idea of what threat intelligence is and how to use it, then you’re doing it wrong. What you are going to accomplish in that model is either sending out tons of meaningless alerts to information security staff with no context of why something may be bad, or, even worse, blocking access to something for your users when somehow Google.com made it into the threat intelligence feed that you have no control over what goes in it (of course that would never happen, right!?)
So, then who is threat intelligence good for? For, organizations that already have effective and tested controls in place for basic security issues (such as patching and vulnerability management), and are ready to start actively hunting for attackers in their network. If your organization has effectively addressed the CIS Critical Controls, then you may be tall enough for the threat intelligence ride.
So what exactly is threat intelligence? Vendor XYZ told me that their super-appliance stops all advanced attacks thirty minutes before they even happen using threat intelligence! As with many things in the computing world, terms to describe technology end up becoming buzzwords used by vendors to sell more products – this definitely seems to be the case with threat intelligence.
To me there are two categories. The first is Atomic Indicators of Compromise (IOCs). These are things that cannot be broken down further into additional data such as IP addresses, domain names, and file hashes. These are typically what you see in a threat intelligence feed.
Atomic indicators are then used to help describe the next category – Tools, Techniques, and Procedures (TTPs). This describes the tools an attacker uses, the techniques they employ with those tools, and the procedures they follow to reach a specific goal. This is generally not what you find in a threat intelligence feed.
For example: “When this attacker sent an email from the server at this IP address, the malicious attachment with this file hash created a command and control channel to the server at this IP address. Then the attacker downloaded and used this Remote Access Tool and moved laterally in the internal network over SMB and gathered this type of sensitive data from these systems and used this compression method to package up the data and exfiltrate it to this other IP address.”
Wait, this sounds difficult to figure out, how can an appliance do that?! It is. Very difficult. An appliance or feed cannot do that kind of analysis, people do that analysis. Attackers can change atomic indicators relatively easily. When they do, the feed does not help detect that attacker any longer until an actual person somewhere does some analysis and adds new data back in.
Effective use of threat intelligence takes a dedicated team of security analysts that have as their only job to detect and respond to potential attackers in your network. It cannot be done by purchasing an appliance or feed of indicators, given to the one security guy who already is not paying attention to the 3,000-a-day alerts from the un-tuned IDS, because he is trying to figure out why a patch broke 12 workstations in the HR department.
So now we have a team of people and want to get started with effectively using threat intelligence, where do we begin? To get started, seek out and become involved with security analyst communities that analyze and share information specific to your industry. These groups do exist, and data that you get from the analysts that contribute to the intelligence will have more context than a feed from a vendor serving every industry.
Also, generate your own threat intelligence. When someone in the C-suite reports an email as suspicious and it turns out that the attachment is a weaponized document, take the time to do some analysis and gain some indicators of your own. Afterall, the indicators from that one phishing attempt have a much better chance of being someone actually attacking your organization rather than any of the indicators in a feed from a vendor.
Now that you are getting some context to why a particular atomic indicator is bad for your organization, what do you do with it? I would suggest looking through your log files to see if any has ever been seen before in your network. Next, put into the appropriate detection device to let you know if you see it in the future, but do so with the realization that the atomic indicator has a relatively short lifespan.
If it is data that you discovered from your own analysis, contribute it back to the information sharing community that you are now a part of. Provide the atomic indicators in as much detail as you can on the TTPs the attackers used. Just one atomic indicator of recent and specific attacker activity could help prevent an incident, but TTPs are harder for an attacker to change and will be valid longer than atomic indicators alone.
This kind of analysis feedback model with information sharing groups is a much more effective way of actually using threat intelligence to discover attackers in your network and to help others do the same.