We've been running the Recorded Future Splunk Technical Add-on (v2.0.1) for a few months now, and I've hit a consistent snag that's driving my security paranoia nuts. The TA seems to only be pulling a subset of our alert types, specifically the "Critical" and "High" severity alerts from a couple of categories, but it's completely missing others we've configured in Recorded Future, like certain "Medium" risk alerts from the Vulnerability Management module.
This creates a dangerous blind spot in our SIEM. If the pipeline isn't ingesting everything we've paid for, we might as well be hardcoding a false sense of security.
Our `recordedfuture.conf` looks correct at a glance—we're using the default alert index and have the modular inputs configured. The sourcetype is `recordedfuture:alerts`. The TA logs into Splunk's internal logs don't show errors, just successful fetches with seemingly low record counts. I suspect the issue might be in how the API query is being constructed by the TA, or perhaps a filter we've overlooked.
Here's a sanitized snippet of our setup in `inputs.conf`:
```
[recordedfuture://alerts]
api_token =
alert_status = no-action
risk_lower_bound = 25
pull_related_entities = 0
index = rf_alerts
disabled = 0
```
Has anyone else experienced this selective pulling behavior? I'm particularly interested in whether the `risk_lower_bound` parameter is interacting with Recorded Future's internal alert scoring in a way the documentation doesn't fully explain. Or, is there a known limitation on certain alert modules? I'm about to start writing a custom script to pull via the API directly and compare, but I'd rather not maintain another secret-handling pipeline if the TA can be fixed.
Encrypt all the things.
Ah, that's a classic gotcha with those modular inputs. Your snippet cuts off, but I'd bet the config has `pull_related_entities = false`. That's usually fine, but sometimes the API logic for certain alert categories, especially from modules like Vulnerability Management, ties the alert metadata to the related entity object. If that's not pulled, the alert might not meet the implicit filter the TA applies.
Check the full API call the TA makes. You can often see it in the `splunkd.log`. Look for the URL parameters. The `risk_lower_bound` you've set might be interacting with the module-specific risk scores in a way you don't expect. Recorded Future sometimes uses different scoring scales per module.
Also, verify your `alert_types` parameter isn't defined, which would default to only a subset. You might need to explicitly list them, or use `alert_types = *` to grab everything configured in your Recorded Future instance. That medium risk VM alert could be categorized under a different type string than the TA's default set is looking for.
Encrypt all the things.
Check your default risk rule mapping in the Recorded Future UI. Their API often uses a different numeric scale than the UI labels you see. A "Medium" in Vulnerability Management could be scored below your `risk_lower_bound = 25` threshold.
Also, successful fetches with low counts are a red flag. The TA is getting *something*, which means the API isn't erroring - it's filtering. Vendor documentation on filter logic is usually vague. You need to see the raw API response to confirm what's being sent.
Hey, great catch on the logs showing successful fetches but low counts - that's the key clue. It's not failing, it's filtering.
You've probably got a mismatch between the UI's "Medium" label and the actual numeric risk score the API uses for that module. The TA's `risk_lower_bound = 25` might be just above the Vulnerability Management's score for those alerts. I'd run a quick API test directly to check the actual JSON. Use the same parameters from your `splunkd.log` curl, but maybe lower the risk bound to 1 or remove it temporarily to see what *really* comes back.
Also, double-check that your `alert_types` isn't implicitly defined elsewhere. Sometimes a default stanza in `default/recordedfuture.conf` inside the app itself sets a limited list. If it's not specified in your local `inputs.conf`, the TA might be using that restrictive default. 😅
Clean code, happy life