SIEM and Threat Intelligence (TI) feeds are a marriage made in heaven! Indeed, every SIEM user should send technical TI feeds into their SIEM tool. We touched on that subject several times, but in this post will look at in in depth. Well, in as much depth as possible to still make my future paper on the topic a useful read :–)
First, why are we doing this:
- Faster detection – alerting on TI matches (IPs, URLs, domains, hashes, etc) is easier than writing good correlation rules
- Better context – alert triage and incident investigation becomes easier and information is available faster
- Threat tracking and awareness – combining local monitoring observations, external TI and [for those who are ready!] internal TI in one place.
What log data do we need?
- Most common log data to match to TI feeds: firewalls logs (outbound connection records … my fave logs nowadays!), web proxy logs
- Also used: netflow, router logs or anything else that shows connectivity
- NIDS/NIPS (and NBA, if you are into that sort of thing) data (TI matching here helps triage, not detection)
- ETDR tools can usually match to TI data without using a SIEM, but local endpoint execution data collected in one place marries well to TI feeds.
Where would TI data comes from (also look for other TI sources):
- SIEM vendor: some of the SIEM vendors are dedicating significant resources to the production of their own threat intelligence and/or TI feed aggregation, enrichment and cleaning
- Community, free TI feeds: CIF format comes really handy here, but CSV can be imported just as well (some lists and information on how to compare them)
- Commercial packaged feeds from the TI aggregator (it may even have pre-formatted rules ready for your SIEM!)
- Commercial TI providers of original threat intelligence.
Obviously, using your SIEM vendor TI feeds is the easiest (and may in fact be as easy as clicking one button to turn it on!), but even other sources are not that hard to integrate with most decent SIEM tools.
Now, let’s review all the usage of TI data inside a SIEM:
- Detect owned boxes, bots, etc that call home when on your network (including boxes pre-owned when not on your network) and, in general, detect malware that talks back to its mothership
- Validate correlation rules and improve baselining alerts by upping the priority of rules that also point at TI-reported “bad” sources
- Qualify entities related to an incident based on collected TI data (what’s the history of this IP?)
- Historical matching of past, historical log data to current TI data (key cool thing to do! resource intensive!)
- Review past TI history as key context for reviewed events, alerts, incidents, etc (have we seen anything related to this IP in the past TI feeds?)
- Review threat histories and TI data in one place; make use of SIEM reports and trending to analyze the repository of historical TI data (create poor man’s TI management platform)
- Enable [if you feel adventurous] automatic action due to better context available from high-quality TI feeds
- Run TI effectiveness reports in a SIEM (how much TI leads to useful alerts and incidents?)
- Validate web server logs source IP to profile visitors and reduce service to those appearing on bad lists (uncommon)
- Other use of TI feeds in alerts, reports and searches and as context for other monitoring tasks
So, if you are deploying a SIEM, make sure that you start using threat intelligence in the early phases of your project!
Posts related to this research project:
- On Internally-sourced Threat Intelligence
- Delving into Threat Actor Profiles
- On Threat Intelligence Sources
- How to Make Better Threat Intelligence Out of Threat Intelligence Data?
- On Threat Intelligence Use Cases
- On Broad Types of Threat Intelligence
- Threat Intelligence is NOT Signatures!
- The Conundrum of Two Intelligences!
- On Comparing Threat Intelligence Feeds
- Consumption of Shared Security Data
- From IPs to TTPs
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
Once again a thoughtful writing. I know we implemented TI from one SIEM Vendor, however it didn’t exactly work out the way it was originally designed to as it provide us a much higher level of FP than we originally thought it would. Also at times the licensing fee is not what a client wants to pay. They feel with the cost of the product and support it should be provided free of charge…..
Glenn, thanks for the comment. Indeed, FPs are common if you send TI data that is meant for investigative context straight into alerting (ie. “an IP with some suspicious history” vs “known bad – spreads malware now”)
Also, my telepathic abilities are weak today, but I suspect that vendor’s name starts from “S.” 🙂 They charged for TI feeds and [sadly] recommended raw intel to be flowing into rule engine with alerts set to on … FAIL!
Anton, as usual, extremely good comments and words of wisdom