Part of the RST intelligence layer
RST Noise Control
Trusted subtraction — the known-good verdict that decides whether anything downstream should act on an indicator at all, across IPs, domains, URLs, and hashes.
The question asked before enforcement, across every indicator type — not just IPs.
Allowlists, resolved DNS from multiple regions, and NSRL cleaned of red-team tooling.
Trusted subtraction — what NOT to act on.
Key Benefits
Large number of rulesets to detect “known good”.
Real-time response via a unified API. Flexible pricing policy with low entry.
Heuristic algorithms based on data from sandboxes and honeypots.
182
Rule Sets
12GB+
individual exceptions covered
API
Can be integrated with various SIEM, SOAR, and TIP
MS Updates, CDP, CDN, Public DNS, etc
Well-known IPs, Domains, URLs, and hashes
Key Usage
RST Noise Control can be integrated with various SIEM, SOAR, and TIP solutions. In SIEM and SOAR it can be used to stop alerting on indicators that were mistakenly added as an IoC for detection or prevention by one of the security vendors. In TIP a bulk API can be utilised to check indicators right after those are collected from various TI sources to ensure you are not improting noisy ones.
Decreased false positives in real-time detection
Alleviating the SOC system's workload by filtering out irrelevant data and false indicators from connected feeds
Enhanced efficiency, saving analysts valuable time when managing incidents
RST Noise Control
{
"value": "1.1.1.1",
"type": "ip",
"benign": "true",
"reason": "Well-known Public DNS Server"
}
The question nobody else asks
Scanner-noise tools cover IPs at the perimeter. Noise Control asks a broader question across every indicator type: should anything downstream act on this at all? Known-good detection for software, files, IPs, domains, URLs and hashes — live benign intelligence, not a static allow-list. The industry built an economy around known-bad; this is the trusted known-good layer. See how we score →
Inside the known-good
Known-good is harder to build than known-bad
A malicious indicator only has to be observed once to be worth publishing. A benign one has to be proven — from more than one vantage point, against software we have actually profiled, and re-proven every time the estate behind it changes. That work is the product.
Resolved from the whole world, not one data centre
We take the domains that genuinely carry traffic — Tranco and Cisco Umbrella rankings, per-country Cloudflare DNS top lists, public NTP pools — and resolve them continuously from nodes in different regions, keeping every answer as a real observed mapping.
Why it mattersAnycast and CDN estates hand back different addresses in Frankfurt than in Singapore. Resolve from one place and you allowlist one slice of a provider while quietly mislabelling the rest.
Software profiled, not assumed
We stand up clean golden images of the operating systems our clients actually run and hash every binary they ship, then combine that with NIST NSRL releases, generic Windows executables and analyst submissions. A few of the images currently profiled:
Windows Server 2025Ubuntu Server 26.04 LTSRHEL 10Amazon Linux 2023NSRL 2024.03 → 2026.x& more, plus manual submissions
Allowlists that retire, not accumulate
Around 76 dedicated fetchers refresh cloud, CDN, scanner, search-engine and bot ranges on a schedule — AWS, Azure, Akamai, Cloudflare, Shodan, Censys, Googlebot, OpenAI and the rest — each mapped to its own ruleset with its own verdict.
Why it mattersRanges get returned and reissued. An allowlist that only ever grows will keep vouching for infrastructure its original owner gave up years ago, so superseded entries are dropped rather than kept.
NSRL cannot be used raw. NIST's reference set is the standard known-good hash corpus — and it also catalogues Kali Linux, Mimikatz and a long shelf of offensive-security tooling. Load it unfiltered into a noise filter and you have just told your SOC that Mimikatz is benign. We strip dual-use and red-team software out of every release before a single hash becomes a benign verdict.