Managing False Positives and Alert Fatigue
Opinions, tags, and intake filters do different jobs. Choosing the wrong one either fails to reduce noise or creates a permanent blind spot.
Findings arrive continuously as files are collected and analyzed, so an environment accumulates alerts on objects somebody already reviewed. Without a way to record those decisions, analysts re-triage the same files repeatedly, and the queue teaches them to skim.
Three tools address this, and they are not interchangeable. The whole of this page is choosing correctly between them.
| Tool | What it does | Reach for it when |
|---|---|---|
| Opinion | Applies your team's verdict to a file | You have made a decision about a specific file |
| Tag | Attaches a label without changing any verdict | You want to track or categorize, not adjudicate |
| Intake filter | Stops matching files being collected at all | You want to stop seeing a class of file entirely |
The ordering principle: prefer the tool that removes the least information. An opinion keeps the file and records a judgment. A tag keeps everything and adds a note. An intake filter throws the file away before Stairwell ever sees it, and no rule written afterwards can reach what was never collected.
Opinions, for a file you have judged
When Stairwell flags something your team has reviewed and cleared, an internal tool, a known library, a sanctioned application, set a Trusted opinion.
That marks it as reviewed, keeps it out of unreviewed triage queues, and creates an auditable record of who decided and when. It applies inside your environment only.
- Open the object.
- Find the Opinion field in the metadata panel.
- Select Trusted, or the appropriate value.
Opinions are per file, meaning per hash. An internal tool that ships weekly produces a new object every release, each needing its own review. That is the limitation that sends people to intake filters, and it is worth being deliberate about rather than reflexive.
Tags, for tracking rather than judging
A tag is a label with no verdict attached. Conventions that earn their place:
| Tag | Meaning |
|---|---|
reviewed | An analyst has looked at it |
benign-confirmed | Confirmed safe, no action needed |
vendor-approved | Known vendor software, cleared by security |
remediated | Threat identified and addressed |
pending-review | Queued, not yet examined |
false-positive | Rule matched, not a threat in this context |
Tags are searchable, so they double as a work queue.
Remediation tracking is the case worth knowing about. Stairwell has no native "remediated" state, so a tag is the recommended way to record that a threat has been cleaned up. A Malicious opinion plus a remediated tag gives the full history: detected, judged, resolved.
Intake filters, and the blind spot they create
An intake filter stops the forwarder uploading files matching your criteria. Filtered files generate no sightings and never appear in search.
Reasonable uses: very high-volume known-good files present on every asset, internal tools updated so often that per-hash opinions cannot keep up, and file classes your organization has decided not to monitor.
A filter is a permanent blind spot, and this is the one irreversible choice on the page. A file that was never collected has no verdict, no variants, and will never match a YARA rule written later, including a rule written next year about a threat nobody has heard of yet.
So filter on a hash rather than a path or a name pattern wherever you can. A path filter suppresses whatever is at that path, and a directory an attacker can predict is a directory an attacker can use. A hash filter suppresses exactly one file and nothing that merely resembles it.
Which one do I want?
| Situation | Do this |
|---|---|
| Reviewed a specific file, it is benign | Trusted opinion, optionally a reviewed tag |
| Handled a real threat and cleaned it up | Malicious opinion, then a remediated tag |
| Same known-good internal tool on every asset | Trusted opinion on the current version. Consider a filter only if it updates faster than you can review |
| A YARA rule is firing on a file you know is safe here | Tighten the rule, or set Trusted on that file. Do not filter at intake |
| Want to stop collecting a class of file entirely | Intake filter, hash-based where possible |
That fourth row is the one people get wrong under pressure. A rule matching your own software is a rule that wants tightening, and suppressing its input hides every future match including the ones that matter. See YARA Rule Best Practices and, for the full worked case, The Alert Is a Legitimate IT Tool.
What should I read next?
- Setting Opinions, for recording a judgment.
- Trigger Silences, for quieting notifications without changing what matched.
- The Alert Is a Legitimate IT Tool, the playbook version of this decision.
Updated 19 days ago