Alright, I've been wrestling with this for a few months now and I think I've finally got a system that works for our team. The volume of brand impersonation alerts we get from Recorded Future is no joke, and the false positives were killing our efficiency.
My main issue was that a lot of alerts were triggered by:
* Legitimate third-party vendors mentioning our brand in their marketing (think "Works with [OurBrand]").
* Internal security researchers or bug bounty write-ups that get indexed.
* News articles about us (surprisingly common).
Here's what I ended up doing to filter the noise:
**1. The Initial Triage Query**
I set up a scheduled query in Snowflake (could be BigQuery, etc.) that pulls in the raw alert data from RF's API feed. The first filter is a simple exclusion list of domains we *know* are okay.
```sql
-- Example of a simple daily filter view
CREATE OR REPLACE VIEW analyst_false_positive_filter AS
SELECT
alert_id,
domain,
alert_reason,
confidence_score
FROM recorded_future.raw_alerts
WHERE
-- Exclude our known partners
domain NOT IN ('trusted-partner.com', 'legit-security-news.org')
-- Filter out low-confidence alerts for initial review
AND confidence_score >= 65
-- Keyword exclusions in the alert reason
AND LOWER(alert_reason) NOT LIKE '%bug bounty%'
AND LOWER(alert_reason) NOT LIKE '%press release%';
```
**2. Building a Feedback Loop into the Dashboard**
I built a Tableau dashboard from that filtered view. The key addition? A simple action button (simulated with parameters) that lets analysts mark an alert as "Reviewed - FP" directly. That action writes back to a small logging table. Over time, we use that log to:
* Automatically add new domains to the SQL exclusion list.
* Adjust the confidence score threshold.
* Spot patterns in `alert_reason` text to add new keyword filters.
**3. The Human Process**
We still have a human check the filtered list daily, but it's down to ~10 items from 100+. The rules evolve weekly based on that feedback log.
I'm curious—has anyone else tackled this? I'm wondering if there's a better way to integrate the feedback loop, maybe using a dbt model to dynamically update the exclusion list, or if RF's API has improved methods for feeding back into their alert scoring.
What's your workflow look like?
--diver
Data is the new oil - but it's usually crude.
I'm a security platform lead at a fintech processing around $12B annually; we've been in production with Recorded Future's brand intelligence module for about 18 months, managing alerts for four major sub-brands across a hybrid AWS/GCP stack. I run the filtered alert stream into a dedicated Slack channel and a Jira Service Desk queue for our fraud ops team.
Core comparison for a false-positive mitigation layer on top of Recorded Future:
1. **Custom rule tuning scope**: RF's native dashboard allows for domain and keyword exclusions, but it's a global setting. The main limitation is you can't create complex logic (e.g., `domain=news-site.com AND alert_type=typosquat AND confidence<85`). For anything beyond simple blocklists, you must export the data. This pushes the engineering effort to your team.
2. **Alert volume and data processing cost**: At our scale (~3k raw alerts/day), the Snowflake processing costs from a scheduled query are negligible, about $12-18/month. The real cost is the initial setup time (2-3 engineering days for pipeline + views) and the ongoing maintenance of exclusion lists, which requires a dedicated resource for 2-3 hours weekly to review new patterns.
3. **Integration and workflow effort**: The simplest integration is RF's built-in ticketing connectors (ServiceNow, Jira). It's a one-click setup but applies the same blunt filters to all tickets. Building a custom filter via their API feed, like you've done, takes more effort but allows for dynamic scoring. The main breakage point is when RF changes an API field format, which has happened once, requiring about half a day to fix our ingestion job.
4. **Operational effectiveness gap**: Even with a good filter, you'll miss novel attack vectors if you're too aggressive. Our filter catches about 70% of clear false positives, but we still require a human analyst to review the remaining 30% (roughly 900 alerts/day). The system clearly wins on eliminating the obvious noise, but it does not eliminate the need for a tier-1 analyst; it just makes their queue actionable.
Given your described issue with vendors and news articles, I'd recommend sticking with and expanding your custom filtering approach. It's the most adaptable. To make a cleaner recommendation, tell us the size of your analyst team reviewing these alerts and whether you have any regulatory requirements to archive or audit all raw alerts, even false ones.
infrastructure is code