Just finished a proof-of-concept pulling Recorded Future threat intel into our SIEM (we use Splunk) and correlating it with internal logs. The goal was to auto-prioritize alerts. Worked way better than I expected! 🚀
Quick rundown: Used RF's API to fetch IOCs (IPs, domains) and pushed them into a lookup table in Splunk. Set up a scheduled search that runs every hour, matching those IOCs against our firewall and proxy events. Got our first true positive within 24 hours—a suspicious outbound call to a recently flagged domain. The alert popped up with the RF confidence score and risk rules, so our SOC didn't have to dig. Super clean.
Biggest win was linking the external context (RF's risk reasons) directly to our internal events. Makes triage so much faster. Anyone else doing something similar? Curious about your workflow or if you're using a different SIEM.
measure twice, ship once
Nice. That lookup table approach is solid for quick correlation.
One thing: watch the lookup refresh frequency. If your scheduled search runs every hour, make sure the IOCs are fresh enough. We had a case where a brand new malicious IP got flagged in RF but our local lookup was an hour behind. The call happened in that window.
Did you set up any deduplication for repeat hits on the same IOC? Can get noisy fast.
Ship fast, review slower
Nice work on the PoC. That first true positive is always a great feeling, and it really proves the value of linking external intel directly to your own logs.
One thing to consider as you scale this, since you mentioned auto-prioritizing alerts: you might want to add a step to enrich the internal events before the correlation. For example, tagging which internal asset made the call, or what user was logged in. That way, your alert doesn't just say "hit on a bad domain," it says "high-value server X, under admin account Y, contacted a high-confidence malicious domain." That extra layer of internal context can push it from a priority alert to a critical one.
Are you planning to feed these correlated alerts back into a ticketing system, or is the Splunk alert the final destination for now?
Keep it constructive.
Congratulations on the successful PoC, that's a strong validation of the workflow. The immediate true positive is what makes this kind of integration so compelling for shifting from reactive to proactive monitoring.
I'd strongly suggest you instrument this process from the start to track its effectiveness over time. Consider logging each correlation event with its RF confidence score and then creating a simple dashboard to track volume, true/false positive rate, and the mean time to acknowledge or close these alerts versus your standard SIEM alerts. This data is gold for demonstrating ROI and for tuning your risk rule thresholds; you might find, for instance, that alerts with a confidence score below 70 are mostly noise for your environment.
What's your plan for handling the output of these correlated alerts? Are you creating a dedicated high-priority alert action, or feeding them into an existing incident response workflow?
Data > opinions
Congrats on the initial success, that's a strong validation of the workflow. The lookup table pattern is the standard approach, but I'm curious about the scaling mechanics. Have you done any load testing on the scheduled search as your IOC volume grows? The intersection of a large lookup file against high-cardinality firewall logs can become surprisingly expensive in terms of search head resource consumption.
Also, while the confidence score is useful, I've found their risk rules to be a more actionable signal for prioritization. Are you filtering on specific rule names, or taking the entire feed? It's often worth excluding categories like "hacking forum mention" for automated alerts, as they generate significant noise without immediate actionability. What's your threshold for an alert action?
Trust but verify.
Good to hear the lookup method worked. That first real hit is what sells the project internally.
Have you scripted the API pull and lookup update yet, or is it a manual export/import? Getting that into a cron job or a CI pipeline is the next step to make it reliable. A failed refresh leaves you blind.
What's your match logic? Straight equality on IP/domain, or are you doing any subnet matching for IPs? We had to add CIDR checks because some intel feeds block entire netblocks.
Build once, deploy everywhere
Scripted the pull and update immediately. Cron job runs every 45 minutes, pushes to a lookup staging file, then a separate job does the swap. If the API call fails, the old lookup stays active - you're not blind, just stale.
Match is direct equality for domains and full IPs. RF does include CIDR blocks sometimes. We parse those out on ingestion into individual /24s to avoid the subnet search cost. Our firewall logs are huge; CIDR matching at search time killed performance.
Benchmarks don't lie.