Threat Intelligence in SIEM: Are you getting your money’s worth?

Some Threat Intelligence solutions are free, but they require a substantial investment of time, energy, and research. Some cost money (and some are more expensive than others), but none of them are complete upon installation, and you usually get what you pay for. So is it worth the expense?

Before I begin, let me preface my long-winded speech by jumping right to the punchline, and then I’ll fill in the details afterwards a la Quentin Tarantino: I ABSOLUTELY advocate for the devoted, mature use of a threat intelligence feed in every SIEM, but you have to think of this resource as an antibiotic: you may see improvement almost immediately when you start taking an antibiotic, but as I’m sure your doctor will tell you, it isn’t enough to take them only until the symptoms stop. You need to keep taking them until you finish the prescription, or you risk the symptoms coming back stronger, and worse, potentially resistant to that antibiotic! (It’s not a perfect metaphor, but don’t give up on me just yet.)


The number one problem with threat intelligence feeds within a SIEM environment (in my traveled, though admittedly personal and unverified opinion) is an insufficient investment by companies into the necessary time to develop and mature their use cases around that data. As any provider of such a solution will tell you, context immediately makes even your existing monitoring capabilities more meaningful, and that may be true, but the flip-side is that SOCs often assume at the start that nearly everything that triggers on threat intelligence-based monitoring is actionable, and that rarely the case.
Often a SOC/security team is handed, or delivers for themselves, a threat intelligence feed to close a generally perceived gap; a few use cases are thrown together or imported directly from a vendor’s stock content pack and then turned over to analysts to make sense of the noise. If someone is really ambitious, they might even apply it somehow to existing alerting to indicate whether a host in question is on a “bad guy” list.

The analysts or their management initially embrace these new alerts with enthusiasm, but after several false positives and a number of hours spent putting out non-existent fires they feel as though they are drinking from a fire hose. (Forgive the over-used phrase.) Rather than find a way to reduce the flow to drink safely from that hose, they turn off the fire hose completely (or walk away from it while it spews wastefully into the street) and move on in search an easier drink.

Man I use an excessive number of metaphors. It’s like that time I… wait, sorry.

Back on topic.

Anyway, if you really want to get your money’s worth, this is point at which you must stand out from the rest. Make your case and convince your senior management to give you some “special time” with your threat intel feed to put together a real arsenal of unique perspectives.

  • Ensure that all of the “Top N” alerts from a *uniqueness* perspective are being investigated. A hundred connections from one host to a single malicious IP may be a false positive, but one host connecting to a hundred distinct malicious IPs is probably not.   (Alright, well in the very beginning it could be… think of me the first time you discover a security tool running on a Windows server with NetBIOS enabled and tries to contact every bad IP it can’t resolve. But once you tune that out the previous statement should hold true.)
  • Tune, tune, tune… spend long enough looking through the events that cause each of the stock rules to fire to determine what events you have that are causing misfires. For instance, if events from a given feed are parsed incorrectly and the source and destination addresses are reversed, you’ll get some funky results.
  • Prioritize existing rules when the offender also matches on a threat intel list. A rule that already fires might mean something bad, sure. But if it fires AND the offender is on a watch list, that’s probably worse.
  • Monitor the threat intelligence feed itself! What good are rules around lists of bad actors, bad URLs, etc. if you don’t notice when the feed quits working and the data gets stale? In fact, stale data doesn’t just impede detection, it increases the risk of false positives.
  • Make time for whiteboarding! Go through dry erase markers like it’s going out of style–or chalk for you purists out there–in whiteboarding sessions with the most creative security minds at your disposal. Block out your calendars for a while, load up on coffee, and don’t leave the conference room until you’ve written out every possible way of correlating with threat intel data in your current feeds that you can think of.
    • Cross correlate between different intel lists. A system which triggers one rule is less scary than a system that triggers two or more.
    • Stack the data with existing feeds. While for some companies your valid activity can come from anywhere, for many companies a successful web logon event from a suspected malicious host could mean credentials have been compromised. Or better yet, what if that same bad IP that’s successfully logging in from the outside was previously seen as the destination in traffic from an INSIDE host? Host beacons out to a bad IP, then bad IP comes back in through the front door?
    • Look at known activities from different angles. Sure you’re reacting when you find out that traffic to a malicious site was successful, but what if your proxy is denying traffic to the same malicious URL a hundred times a day because an 0-day bot is beaconing?
    • Take a paranoid look at what presumed legitimate activity. One IP successfully logging in to your popular website as 5 unique user IDs over a period of time could be some corporation’s proxy, but if that IP is on a watch list, you may have a list of leaked credentials out there somewhere.
  • Use your network security model data! (You have that, right?) This is probably the most underrated approach at SIEM correlation.
    • Maybe you have use cases that you can’t generally apply to all users, but I bet you could use them for production servers!
    • Maybe there are more moderate indicators that you can’t investigate for every system, but you could find the time just to monitor Internet-facing systems!
    • You may not have time to look at every single alert for an end-user navigating to a malicious URL, but servers should never be hitting them.
    • Depending on the maturity of your network security model, you might have systems categorized by OS, running services and known open ports, known vulnerabilities (from vulnerability scanning feeds), and business unit. Dig deep into the data you have available for another whiteboarding session, and come back often!
  • Protip: many companies freak out at the idea of spending more capital funds but don’t mind shelling out some operating dollars for a measurable security benefit, especially if it helps them save in operating costs in the years to come. (Differences and Similarities of Capital and Operational Budgeting) Now that you’ve already got a threat intelligence feed in the doors, you might be surprised at how willing your boss (or your grandboss) is to pay for professional services to come in and work some magic in your SIEM around this data, because they don’t have to depreciate that cost over the next few years like the would the purchase of an additional security tool.

And finally, the piece so few companies ever get around to doing but EVERYONE should: make it part of your standard process for NEW monitoring requests. For any new business unit that comes along with their logs, consider having them walk you through some of the features of their sites/systems, and ask them whether it would be scary if it were performed by an IP on a watch list full of known malicious hosts, or if the referring URL were on a list of malicious URLs, or if a file that gets uploaded matches against a scary hash value. If someone comes to you with use cases already in mind, tell them about all the threat intelligence lists you have available to you, and then ask whether they think applying them in any way to their system would be actionable.


This isn’t a requirement, but this is my favorite bit. That threat intelligence data is only available because folks out there SHARED, right? So spend some time sharing ideas and IOCs. Share them at conferences, share them at regional user group meetings, share them with your trusted circles, share them on LinkedIn… share them with me. 🙂

Chad wearing "I Heart OpenSSL" t-shirt


–chad (deathbywedgie)



I’m a workaholic on vacation, an extrovert who’s cooped himself up in the house too long, a geek with ADD and OCD, and I realized too late that I consumed too much caffeine yesterday. So, still wired and in the mood to write, I started a comment on a LinkedIn thread.

That comment turned into a dissertation, too long to be meaningful, so I started a new thread. That thread turned too long, and LinkedIn’s formatting abilities are annoying and weak, so it became an article, but I had nowhere to post it. That led to starting a security blog, which I may or may not keep up with, but here it is.

I’ll try my hand at this for a while and see if I’m able to keep it going. I’ve created a basic About page, picked a basic theme for the blog, and uploaded a photo… that’s about it. But at least one post will follow shortly.

That Annoying "First" Guy