Threat intelligence has traditionally been a buy-or-build proposition. You subscribe to commercial feeds, scrape abuse lists, or operate your own honeypots. Each approach has limits: commercial feeds lag behind emerging attacks, scraped lists lack context, and honeypots require dedicated infrastructure.
Federated threat intelligence offers a third model — collective defense without collective data exposure. Participating organizations share attack observations anonymously, enriching each other's detection without revealing customer data, raw IPs, or identifiable device fingerprints.
LRDefender's federated threat service implements this model for device fingerprinting customers. This post explains the architecture, privacy guarantees, and engineering trade-offs behind the system.
The problem federated intel solves
Consider a bot farm attacking e-commerce checkouts. The farm rotates through hundreds of residential proxies and real browser profiles. No single merchant sees enough traffic to confidently block the devices. But across fifty merchants in the LR Defender network, the same hardware hashes appear hundreds of times — each tenant independently confirming the threat.
Without federation, each merchant fights the same bot farm in isolation. With federation, the first few reports anonymize and aggregate into a shared signal that protects the entire network within minutes.
Architecture overview
The federated threat service maintains three in-memory stores:
1. Global device blocklist — anonymized hardware hashes with report counts, contributing tenant counts, threat types, and maximum severity. 2. IP reputation index — hashed IP addresses with aggregated report counts and reputation scores. 3. Bot signature registry — hashed automation framework signatures with cross-tenant sighting counts.
All three stores operate as singleton in-memory maps with TTL-based cleanup (default 90 days), capacity enforcement (100,000 entries per store), and hourly garbage collection.
Anonymization: what enters the network
Every identifier is hashed before storage or transmission:
anonymized_id = SHA-256("federated:" + raw_value)This applies to device hashes, IP addresses, bot signatures, and tenant IDs. The network never stores raw values. A tenant contributing a threat report sends the original device hash to the API, which hashes it before inserting into the federated store. Other tenants querying the same device hash receive risk scores and report counts — never the source tenant's identity or the original hash from another contributor.
This is not differential privacy in the formal sense (no calibrated noise injection), but it achieves the practical goal: no tenant can reverse another tenant's identifiers or customer data from federated signals.
Reporting pipeline
Threat reports enter the federated pool through two paths:
1. Automatic reporting — when a fingerprint session's suspect score exceeds 70, the API asynchronously reports the anonymized device hash, client IP, threat type, and severity to the federated service. 2. Manual reporting — future tenant API endpoints for explicit threat contribution (planned).
Each report is validated: - Severity must be a finite number between 0 and 10. - Rate limiting enforces a maximum of 60 reports per tenant per minute. - Duplicate reports from the same tenant increment counters without creating new entries.
Consumption: checking federated signals
On every fingerprint ingest, the API checks the incoming device hash and client IP against federated stores:
- Device check — returns
known,blocked,riskScore,reportCount, andtenantReports(anonymized count of contributing tenants). - IP check — returns reputation tier (
clean,moderate,suspicious,malicious) and numeric score. - Bot signature check — returns sighting count and cross-tenant confirmation status.
Results surface in smartSignals.federatedThreat and smartSignals.federatedIpReputation on the fingerprint response payload.
Consensus-based blocking
A device is marked blocked only when both conditions are met:
- Report count ≥ 3 (configurable via
minReportsToBlock) - Contributing tenant count ≥ 2
This consensus requirement prevents a single compromised or overly aggressive tenant from polluting the global blocklist. An attacker would need to compromise multiple independent tenants to inject false blocks — dramatically raising the attack cost.
Risk scores scale with both report volume and tenant diversity:
riskScore = min(1, (reportCount / 10) × (tenantCount / 3))Opt-in and tenant control
Federation is designed as an opt-in capability. Tenants enable contribution and consumption through settings (the dashboard federated intel page shows network signals and statistics). Tenants that do not opt in receive no federated enrichment and contribute no reports.
Rate limiting and capacity enforcement protect the network from abuse: - 60 reports per tenant per minute prevents flooding. - 100,000 entry cap per store with LRU-style eviction of oldest entries. - 90-day TTL ensures stale threats decay automatically.
What federated intel is not
Clarity about limitations is important:
- Not a replacement for LR Shield — VPN, proxy, and TOR detection remain separate network intelligence services.
- Not real-time global threat feeds — the in-memory store reflects LR Defender tenant observations, not commercial IOC feeds.
- Not formally differentially private — SHA-256 anonymization prevents identifier recovery but does not add statistical noise to aggregate counts.
- Not persistent across API restarts — the current implementation is in-memory; production hardening with Redis backing is on the roadmap.
Lessons for builders
If you are designing a federated threat system, the LRDefender implementation reinforces several principles:
1. Hash before store — never persist raw identifiers in a shared pool. 2. Require consensus — single-tenant reports are intelligence; multi-tenant reports are action. 3. Rate limit aggressively — federation amplifies abuse if contributors are not bounded. 4. Decay stale data — threat relevance has a half-life; TTL enforcement prevents permanent false positives. 5. Make participation opt-in — trust is earned, not assumed.
Federated threat intelligence turns isolated device fingerprinting deployments into a collective defense network — without asking tenants to share customer data. That is the model LR Intel is built on.