How to Use Threat Intelligence with Your SIEM?

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