Whitelisting of alerts

[dobin]

Motivation

A large chunk of SOC work is to whitelist false-positives. This can be done on different layers, e.g. at the SOAR, or SIEM - but often we want to silence alert generation on the endpoint. Either for performance reasons, bandwith (e.g. laptops connected via GSM), or to save money by ingesting less stuff into Splunk.

Feature

An ability to whitelist alerts.

• It should be easy to add, list, and delete whitelist entries.
• They should persist over Fibratus software updates.
• They should be independant from the detection rules itself.

And also:

• Whitelist should be easy to generate (e.g. for a SOC T1 Analyst)
• Idea: Given a plaintext alert, a way or tool to convert it into a whitelist entry, without the need to write like a plaintext rule

Proposal

Something like a Whitelist/ directory, where each file in it can contain one or more whitelist entries, filtering alerts on all available properties.

A bad example with edge.yaml with some invented yaml:

whitelist_edge_fp01: 
  - alert_is: "Suspicious object symbolic link creation"
  - Cmdline_is: "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
  - Kparams_contains: "\Sessions\1\AppContainerNamedObjects"

For the alert:

 source=action/alert.go:37
time=2026-01-23T15:26:26+01:00 level=info msg=sending alert: [Suspicious object symbolic link creation]. Text: Suspicious object symbolic link \Sessions\1\AppContainerNamedObjects\S-1-15-2-3251537155-1984446955-2931258699-841473695-1938553385-924012159-129201922 � created by process C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
 Event(s): 
		Seq: 71545003
		Pid: 1132
		Tid: 4060
		Type: CreateSymbolicLinkObject
		CPU: 0
		Name: CreateSymbolicLinkObject
		Category: object
		Description: Creates the symbolic link within the object manager directory
		Host: DESKTOP-C0HF6MF
		Timestamp: 2026-01-23 15:26:27.1999612 +0100 CET
		Kparams: desired_access➜ READ_CONTROL|SYNCHRONIZE, source➜ Session, status➜ Success, target➜ \Sessions\1\AppContainerNamedObjects\S-1-15-2-3251537155-1984446955-2931258699-841473695-1938553385-924012159-129201922 �
...

[rabbitstack]

In Fibratus, exceptions are an integral part of the rule. They evolve alongside the detection rule, and whenever a change happens, the version control system reflects that. Additionally, the rule version is incremented to record the changeset. Having a separate set of configuration files for whitelisting the rule would defeat the previous principles. Needless to say, the code complexity would increase to support this new feature.

As of now, I'm leaning toward keeping the exceptions close to the rule. In the future, we can consider altering this workflow, for example, once Fibratus is a full-fledged security platform and has the rule exception editor.

[dobin]

Understandable. But just my two cents:

If the architecture does not support this, it should be changed asap (and not later).

Exception management, independent of detection rules, is a basic requirement of not only business, but also normal users.

Its good to update the detection rule with common exceptions, so all users profit from it (so 1000 customers dont have to whitelist Edge after Fibratus installation). But making it hard, or impossible, to integrate an EDR in heterogenous environments makes it completely unsuitable for productions use.

Detection rules should detect. Having to fiddle with detection rules on every false positive is a disaster waiting to happen. Users may have dozens of machines, companies hundreds or multiple thousands - with even more different software. Having to update exceptions daily, or even hourly. Especially during onboarding. Mixing exceptions with rules also weaken its security, as you'll need to be aggressively whitelist stuff of the lowest denominator of your customer base. It will also be a breach of regulatory compliance (especially for banking). And imagine patching Microsoft Defender detection rules instead of clicking "Add exception".

I recommend to dogfood Fibratus (deploy it on a fleet of your own machines), and see how it goes.

[rabbitstack]

I can't agree more. There's also another side of the dice. Exceptions, if not tuned well, can make rules weak and introduce opportunities for evasion. Obviously, we could limit exclusions to just file/process paths (basically what Microsoft Defender does).

Nevertheless, for regular users, that might be sufficient. We're definitely considering implementing this feature, but as mentioned previously, it would fall under the umbrella of the Fibratus Security platform. For example, we already have a working PoC, where Fibratus connects to a remote service and pulls rule definitions rather than loading them from the file system. This is the first step towards truly distributed/scalable rule management capabilities.

We hear you, and promise, sooner or later, we'll incorporate rule exclusions ; ). At the moment, there is always a bigger fish to fry.