You don’t need cyber threat intelligence. Buy this instead

Last week I saw another hot take on Twitter. This Twitter influencer asserted that for most organizations, Cyber Threat Intelligence (CTI) is a waste of money and they would be better off spending that money elsewhere. In this blog post, I will dig into this argument, including what proper use of Cyber Threat Intelligence looks like.

A disclaimer or two

It’s easy to conclude that cyber threat intelligence is a waste of money. While I see organizations use it all the time, I rarely see them using it productively.

First, the argument isn’t that Cyber Threat Intelligence is always a waste of money. The assertion was that most organizations are not making use of it. And if they aren’t using it, they would be better off spending that money on something they will receive value from.

Second, it’s no great secret, at least to my regular readers, that in my day job I work for Tenable, a security vendor. Some conditions I’ll discuss here assume use of their products. If you use someone else’s products, you will need to determine their suitability for it. I know of at least one use case I will describe that is not possible in competing products. And let’s get a third disclaimer out of the way while we are at it. This blog post was not reviewed, endorsed, sanctioned by, or approved by Tenable. Opinions I express here are my own and neither my current nor any former employers are likely to agree with all of it.

What is Cyber Threat Intelligence?

At one of my old workplaces, we had specialists who used CTI to become storytellers of old. Their scary campfire stories made the daily grind more interesting, but never resulted in action to fix things.

Cyber Threat Intelligence is data about threats to cyber security. It can take any number of forms, ranging from data feeds to daily analysis that gets e-mailed to you.

My first exposure to it was in 2013. I was working for a Fortune 20 megacorporation, and they had a subscription to some analysis that showed up in our inbox every morning. As I recall, we had mixed opinions about it.

We had people on the team who were very good at reading the analysis and using it to paint doom and gloom scenarios that got them a lot of attention. They attracted big audiences as they told their stories, but they weren’t very effective at driving people to action. They may have had the opposite effect.

The reason I say that was because the system administrators didn’t know if something went wrong and they needed to roll back a change, would the security team have their back, or would they tell a story in front of all of their vice presidents about cyber Doomsday and how there was no turning back. The impression they had was the latter. It was only after I assured them that availability is also a tenet of security and that if a system was rendered unavailable, of course we would let them fix it, that they started fixing the issues that we found.

A more useful form of CTI

A more useful delivery format is data feeds. These feeds are just data about security threats. It will likely include file hashes from malware used in known recent cyber attacks, and will probably also include data about CVEs. CVEs are the bread and butter of the world I live in, common vulnerabilities in common software.

The key to using these data feeds is automation. They are really designed for computers to read and act on rather than humans. One possible application for these would be to have a SOAR platform launch an investigation of a system by grabbing the list of the day’s file hashes and initiating a Tenable scan with plugin 65548 for those file hashes on a system that starts throwing alerts.

This scan can go on in the background while incident responders look for other indicators of compromise.

Another potential use case would be loading the data into Splunk so that a threat hunter could correlate that data against known events gathered from systems in the field.

Why isn’t everyone doing this?

In my experience, I rarely saw anyone implement either of these two things. They’d get wrapped up in some of the details and end up never taking any action because they couldn’t agree 100%. Or maybe they simply weren’t collecting enough data to allow the automations to work. Collecting data is expensive, and you have to make some hard decisions about what you collect and what you don’t collect.

I won’t tapdance around this. If you can’t find the money to collect the event log entries about what processes are being launched on your servers and workstations, you’re not in a good position to extract value from CTI either. At least not in the incident response side of things.

Using CTI in vulnerability management

Manage Engine Patch Manager integrated with Tenable.io
When you prioritize by VPR score (second column from the right) in Manage Engine to decide what vulnerabilities to patch, you’re using Cyber Threat Intelligence.

But if all of that sounds bad, wait until I tell you about CTI in vulnerability management. There has been a cottage industry for more than a decade now of companies that will slurp up all of your vulnerability data, make it searchable, and inject correlated threat intelligence. With this threat intelligence correlated with your existing vulnerability data, you can prioritize what to remediate by the probability of exploitation rather than by CVSS scores, which tend to overstate risk.

At various points in my career, I supported to such products. And let me tell you, getting buy-in on this type of prioritization was difficult. Keeping buy-in after 6 or 12 months was even more difficult. Companies inevitably get a few quick wins. But inevitably, their top-10 list would get clogged with vulnerabilities that didn’t have clear and easy-to-figure-out fixes. They’d stop fixing those, fall back on fixing random stuff, see their scores stagnate, and give up. The inevitable conclusion was that CTI doesn’t work.

The thing is, you don’t need separate CTI and you don’t need a separate and very expensive data aggregator to apply CTI to vulnerability management. Simply use the Tenable’s VPR score, which incorporates CTI into its calculation, and fix the highest VPRs first. Link your vulnerability scanner to a current-century patch deployment system like BigFix or ManageEngine (not WSUS, and not SCCM) to make it easy to figure out how to deploy the best update for your given priority criteria, and then you can use CTI very successfully.

And you don’t need a separate CTI feed either. Spend the money you’re spending on CTI on BigFix or Manage Engine insteaed.

Using CTI successfully: In conclusion

Notice a theme here? To really make CTI work, you need automation.

You will also find that when you fix your vulnerabilities, that’s a preventative control. That gets your incident response team out of having to react to as many things. These two purchases don’t get you any street cred at your local security meetups, but they solve real problems.

My unpopular hot take: The best way to make use of CTI in incident response is to use it in vulnerability management.

Yeah, if I keep talking like that, I’ll never be a Twitter influencer. That’s for sure.

If you found this post informative or helpful, please share it!