Trigger Silences

A silence suppresses a particular notification without changing the trigger that produced it. You reach for one when a legitimate thing in your environment keeps matching intelligence written about somebody else's use of the same thing, the match is correct, and you do not want to hear about it again. Silences are narrow on purpose, they are reversible, and they never remove data: the match still exists, still shows in the product, and still turns up in a search. Only the notification stops.

This page is mostly about scope, because scope is the whole risk. An over-broad silence does not feel like a mistake when you set it. It feels like relief. You find out it was a mistake months later, when the alert that would have told you something was wrong is the one you turned off, and nothing in the interface reminds you that you did.

Which control should I use?

Four different tools get confused for each other. Pick by what is actually generating the noise.

Never unsubscribe from a report to quiet one indicator. You lose coverage of every other indicator in it, including the ones the campaign has not published yet, and reports keep matching forward as well as backward.

How do I silence one indicator in one report?

This is the self-service control, and it is the one to reach for first.

1. Open the report from the Threat Reports page and go to its IOCs tab.
2. Find the indicator that is generating the noise. Select several if several are.
3. Right-click and choose Silence hash, Silence hostname, or Silence IP.
4. Write the comment. The dialog asks you to explain why the indicator is being silenced, and this is the field that makes the decision reviewable rather than mysterious.
5. Check the environment named at the bottom of the dialog. It defaults to your default writable environment and you can change it there.
6. Select Save.

The scope is one indicator, in one report, in one environment. That is the feature working as designed, not a limitation to route around. The same indicator in a different report keeps matching, every other indicator in this report keeps matching, and your other environments are untouched.

Unsilence from the same right-click menu reverses it.

Stairwell also silences some indicators centrally, when its research team establishes that an indicator matches widely deployed legitimate software. That is why a report can show fewer matches than its indicator list would suggest, and it is applied for everyone rather than per customer.

Why does the same noise keep arriving after I silence it?

Because the same underlying fact reaches you under different match types depending on which side moved, and a silence scoped to one type does not cover the others.

Say a report indicator links to your remote monitoring agent. If a copy of that agent is already on a machine when the indicator lands, you get a threat report match. If a machine you enroll next week also runs that agent, the indicator was already known by the time the file arrived, so what you get is an object sighting, carrying the same report in its payload but labeled differently. Same noise, same cause, different label, decided purely by ordering.

The practical consequence: a silence written against report matches and rule matches alone will keep letting the object-sighting version through, and it will look as though the silence did nothing. This is the most common reason a silence appears not to work, and it is the first thing to mention when you ask for one.

How do I silence a file by name or path?

That control has no customer-facing UI. It is applied by Stairwell support, so email [email protected] with the file's hash, a couple of the notifications it produced, and the application it belongs to.

Ask for the narrow version. Broad is always available and it is always the wrong trade.

Here is the behavior, so you can describe what you want and check afterwards that you got it:

• It is scoped to one environment. Your other environments are unaffected.
• It matches on the file's name, its path, or both. When both are given, both have to match.
• Every place the file has been seen must match. If your agent lives at the managed vendor path on 340 machines and a copy also sits in a temp directory on one, the silence does not fire and you still get the notification. That is deliberately conservative, and it is the property that makes this control safe: a copy of your remote access tool somewhere it does not belong is not the deployment you approved, and it should still wake somebody.
• It can be narrowed further to specific match types, to named reports, to a pattern over report names, or to a pattern over YARA rule names, so a single noisy rule can be silenced while every other rule keeps alerting.
• It takes effect within a couple of minutes, not instantly.
• It is recorded and reversible. Each silence carries who asked for it, when, and why, and it can be disabled without being deleted, which is what you want when you are testing whether it was the right call.

Two requests worth making explicitly, both of which cost nothing at the time and save an investigation later. Ask for the file name and path to be anchored to the exact name and the exact directory, rather than left loose enough to match a substring: a loose pattern written for index.node will also match myindex_node-bak.txt. And ask for the reasoning to be recorded in the silence itself, naming the application, the team that owns it, and the date.

How do opinions interact with silences?

An opinion of Trusted or Benign on a file stops the trigger notifications that file was generating, and the scope of that is broader than one environment.

Precisely: for a trigger owned by your organization, a safe opinion on that file in any environment your organization can read is enough to suppress the notification. It is not limited to the environment the file was seen in, and it is not limited to the environment where you set the opinion. If your organization reads several environments and somebody marks a file Benign in one of them, triggers your organization owns stop notifying about that file everywhere.

That is usually what people want and occasionally a surprise, so it is worth knowing before you use an opinion as a noise control. A service provider reading many customer environments should be especially deliberate here.

Setting an opinion also does two other things worth weighing: Trusted and Benign make the verdict your readers see safe, and they take the file out of threat report match counts while leaving it visible in the results list. See Setting Opinions for the full set of values.

What does a silence not do?

Worth stating, because a silence whose edges you cannot describe is a silence you should not have set.

• It does not delete anything. The match, the sightings, the rule hit, and the report link all remain, in the object panel and in search.
• It does not stop matching. Everything Stairwell knew about the file it still knows, and a colleague looking at that file sees the same evidence you would have.
• It does not change a verdict. Only an opinion does that.
• It does not cover a new build. A new version of the same application is a different file with a different hash, so it will notify. That is correct: a version you did not deploy is worth a minute of somebody's attention.
• It does not cover the file somewhere else. A file-property silence stops applying the moment the file turns up outside the name or path it was scoped to.
• It is not visible in the notification stream. Nothing arrives saying "one notification was suppressed", which is precisely why the comment and the periodic review below matter.

How do I keep a silence from hiding a real detection?

Five habits. The first one is the one that actually goes wrong.

1. Never silence a whole match type to fix one file. A silence that suppresses every rule match, or every report match, in an environment will hide something within the year. If one application is generating the volume, adjudicate the application.
2. Prefer the opinion when the question is about the file. Trusted, Benign, and Grayware are per-file judgments with an author and a comment. Reach for a silence when one indicator or one rule is matching many legitimate files, rather than when one file is matching many indicators.
3. Remember that the noise and the detection share machinery. The reason your admin tool matched is that intrusions use your admin tool. Silence the mechanism and you have not removed noise, you have removed the detection.
4. Write down why. In six months the value of the record is entirely in the reasoning, and the reasoning is the part nobody can reconstruct.
5. Re-read your silences on a schedule. Applications get retired, vendors get breached, and a silence written for a tool you no longer run is pure risk with no remaining benefit. Ask support for the current list for your environments when you review, and have them disable the ones that no longer earn their place.

What should I read next?

• The Alert Is a Legitimate IT Tool, the playbook that ends in this decision, worked end to end on a real case.
• Setting Opinions, for the control to reach for when the answer is about the file.
• Triggers, for what each match type means and why the labels move.