Whitelisting

This guide explains how to use the graph whitelist feature from the analyst dashboard. Audience: SOC analysts, threat hunters, anyone triaging Logster inferences.

What is whitelisting?

Logster's inference engine flags suspicious activity as attack by analyzing a graph of processes, files, and network events from each short time window. Sometimes that graph captures activity that looks suspicious to the detection model but you, the analyst, know is benign — a scheduled backup script, an admin lab command, a known auditing tool.

Whitelisting lets you tell the engine: "this exact pattern is fine — don't flag it again." From the moment you save a whitelist entry, any future window whose graph contains the same pattern will have those nodes removed before the detection model scores it. The detection model never sees the whitelisted activity, so it can't flag it.

The whitelist is per-tenant: entries you save for tenant-A won't affect inferences for tenant-B.

When (not) to whitelist

✅ Good candidates: - Recurring admin activity that you've confirmed is benign (scheduled backups, monitoring scripts, telemetry agents). - Lab / test activity from your own machines that triggers the detection model. - Known-noisy patterns from third-party software (e.g. installer helpers, update services).

❌ Don't whitelist: - Anything you haven't fully investigated. A whitelist is trust, not suppression. - A pattern just because it's getting flagged a lot — first confirm it's truly benign on every endpoint where it appears. - Anything that's only benign on one specific endpoint. Whitelists apply across all endpoints in the tenant. - A graph containing both benign and malicious activity. Only whitelist the part you trust. Use subgraph scope (see below).

How to whitelist from the dashboard

Step 1 — open the inference's graph

On the dashboard inference list, click the Graph button on any row to open the Graph Modal. You'll see the full window graph as nodes (processes, files, network) and edges (spawn / file write / network connection).

Step 2 — choose what to whitelist

The whitelist panel is on the right side of the graph modal. You have two scope options:

Whole graph (default — no node selected). Every connected component in this window's graph becomes a whitelist entry.
Subgraph (click a node first). Only the connected component containing the node you clicked is whitelisted. The selected component is highlighted in the graph.

Recommendation: prefer subgraph scope. Click the specific node that's at the heart of the activity you want to whitelist (for example, the parent powershell of a benign script chain). The connected component will be selected and highlighted.

Step 3 — choose shape or strict mode

The mode controls how forgiving the matching is on future runs.

Mode	What it matches	When to use
Shape	Topology + node category (e.g. "any shell spawning any system-utility"). Renamed binaries within the same category still match.	When you want to whitelist a class of activity. Broader; risk of accidentally matching something hostile.
Strict	Shape plus exact command lines, file paths, domains. Only the exact action you approved is matched.	When you want to whitelist a specific action. Safer; you may need separate entries for variations.

Shape mode — worked examples

Whitelisted:  powershell → mshta → dns(google.com)
Future run:   powershell → mshta → dns(github.com)   ← still matches

The dns category is the same, the topology is the same — shape matches.

Whitelisted:  cmd → whoami + hostname
Future run:   cmd → quser + hostname

whoami.exe and quser.exe are both SYS_UTIL, so the renamed binary matches under shape.

Strict mode — worked examples

Whitelisted:  mshta vbscript:Close(Execute("...whoami & hostname"...))
Future run:   mshta vbscript:Close(Execute("...whoami & hostname"...))   ← matches (PIDs/GUIDs masked)

Whitelisted:  cmd /c whoami & hostname
Future run:   cmd /c quser & hostname            ← does NOT match — different cmdline

When shape can be too broad

Be careful with 2-node shape patterns where both nodes are the same category. For example, process|SHELL → process|SHELL (any powershell spawning any powershell) is a very common Windows pattern and a whitelist for it can silence many other shell chains too. If you find your shape whitelist is matching too often, switch to strict — or pick a 3-node pattern so the additional node narrows the match.

Step 4 — add a reason and save

Add a short, descriptive reason — your future self and your team will need to know why this entry exists. Examples:

"Nightly backup job — confirmed benign across all DC endpoints"
"Iranian-APT-LoLBin lab test — internal red-team work"

Click Add subgraph/graph to whitelist. The entry is stored immediately. The inference engine reloads its whitelist set every 60 seconds, so allow up to one minute before re-running activity to confirm the whitelist is active.

Step 5 — verify

Re-run the activity (or wait for it to recur). When the next window contains that pattern, the inference will show:

A whitelist badge on the inference row
whitelist_applied: true in the inference detail
whitelist_matched_ids listing your entry's ID
prediction: benign (because the matched subgraph was stripped before the detection model scored)

Managing existing entries

Inside the whitelist panel, switch to the Manage tab to see all entries:

Action	Effect
Disable (toggle the green pill to gray)	Entry remains saved but the engine stops applying it. Reversible.
Enable (toggle gray → green)	Re-activates a disabled entry.
Delete (× button)	Permanently removes the entry. No undo.

Disabled entries don't take effect immediately — the engine will pick up the change on its next 60-second refresh. Same for re-enabling.

Common gotchas

"I whitelisted it but the next inference still flagged it"

Most common causes: 1. Engine refresh delay — entries take up to 60 seconds to be loaded. 2. You whitelisted the wrong subgraph. Many inferences contain multiple disconnected subgraphs in one window. If you clicked somewhere unrelated, you may have whitelisted only the background noise. Re-open the graph and confirm by reading the saved entry's pattern under Manage. 3. The pattern shape differs slightly from last time. Different parent process, different command line, missing child events — any of these changes the graph. If you used strict mode and the command line is even slightly different, it won't match. If you used shape mode but a key node has shifted category (e.g. a binary fell out of the "SHELL" category), it also won't match. 4. The Sysmon agent didn't capture the child events. If short-lived children (like whoami.exe, hostname.exe) didn't make it into the window, the pattern is incomplete and won't match. Check that Sysmon's ProcessCreate rules don't exclude the binaries you care about.

"Whitelisting accidentally silenced something I cared about"

Disable the offending entry from the Manage tab. The engine will stop applying it within 60 seconds. Then create a narrower entry — either switch to strict mode or pick a smaller, more specific subgraph.

"How retroactive is whitelisting?"

Not at all. Whitelists only affect inferences that run after the entry exists. Already-stored inference verdicts are frozen.

Quick reference

I want to…	Do this
Silence a specific recurring chain	Strict mode, subgraph scope.
Silence a family of similar chains	Shape mode, subgraph scope, but spot-check that it doesn't engulf attack chains.
Whitelist an entire window	"Whole graph" scope. Rare — usually too broad.
Temporarily silence something	Disable instead of delete.
Confirm what an entry actually covers	Open Manage, read the entry's pattern, count nodes/edges and process categories.
Stop a whitelist applying to other endpoints	Whitelists are tenant-scoped only; if you need per-endpoint scope, talk to engineering.

FAQ

Does the detection model still see the whole graph? No — the engine removes the matched subgraph nodes before the detection model runs. It only sees what's left.

Does whitelisting affect the persisted graph in the dashboard? No. The full graph (including the whitelisted nodes) is still persisted so you can review the original. The whitelist_* fields on the inference document tell you what was excluded from scoring.

What happens if the entire graph matches a whitelist? The inference is recorded as prediction: benign with attack_prob: 0. It is not skipped — you'll still see it in the dashboard, just with a whitelist badge.

Can I see which whitelist matched a given inference? Yes. Each inference's detail view lists whitelist_matched_ids — those are the entries that fired on that window.

How many entries can I have? There's no hard limit. The engine loads all enabled entries (up to 10,000) on each refresh. Match latency grows roughly linearly with the count, so once you have hundreds of entries consider periodic audits to consolidate or delete unused ones.

What if my analyst whitelisted something I disagree with? Disable or delete it from the Manage tab. The entry's created_by field records who saved it.