From 3b811822daa8c2cbffe53313d0100ade2a748969 Mon Sep 17 00:00:00 2001 From: stacknil Date: Sat, 20 Jun 2026 12:59:15 +0800 Subject: [PATCH] docs(rules): add false-positive taxonomy --- docs/case-study-linux-auth-bruteforce.md | 2 +- docs/rule-catalog.md | 46 ++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 1 deletion(-) diff --git a/docs/case-study-linux-auth-bruteforce.md b/docs/case-study-linux-auth-bruteforce.md index 40bc510..e53e24d 100644 --- a/docs/case-study-linux-auth-bruteforce.md +++ b/docs/case-study-linux-auth-bruteforce.md @@ -119,7 +119,7 @@ These warnings are useful because they prevent silent overconfidence. A reviewer ## False-positive boundary -The findings should be read as triage statements: +The findings should be read as triage statements and checked against the rule-by-rule taxonomy in [`rule-catalog.md`](./rule-catalog.md): - `203.0.113.10` is a documentation-range placeholder; in a real case, the same pattern could be an external scanner, shared gateway, internal test, or replayed lab traffic. - Username spread supports a probing interpretation, but intent is not observable from these lines alone. diff --git a/docs/rule-catalog.md b/docs/rule-catalog.md index 49303e2..de8dd30 100644 --- a/docs/rule-catalog.md +++ b/docs/rule-catalog.md @@ -39,6 +39,19 @@ JSON findings include both the finding conclusion and the rule context used to r For `multi_user_probing`, `observed_count` is the distinct username count, while `event_count` remains the number of attempt-evidence events in the selected window. +## False-Positive Taxonomy + +The taxonomy names benign or ambiguous explanations a reviewer should consider before interpreting a finding. It is not an allow-list, suppression policy, or automatic disposition. + +Each rule uses the same review buckets: + +- NAT +- internal scanner +- lab replay +- shared bastion +- scheduled admin task +- malformed log replay + ## Brute Force ### Rule name @@ -85,6 +98,17 @@ This rule identifies concentrated failed SSH authentication evidence from one so The finding is a triage signal. It is not a compromise verdict, attribution claim, or recommendation to block an address. +### False-positive taxonomy + +| Bucket | Review interpretation | +| --- | --- | +| NAT | Multiple legitimate clients behind one egress address can collapse into one `source_ip`. | +| internal scanner | Authorized credential auditing or exposure scanning can intentionally generate repeated failures. | +| lab replay | Sanitized sample data, training fixtures, or repeated demos can preserve concentrated failure patterns. | +| shared bastion | A managed jump host or administrative relay can make many failed attempts appear to come from one source. | +| scheduled admin task | A recurring job with stale credentials can fail repeatedly inside the rule window. | +| malformed log replay | Duplicated or replayed log material can inflate apparent volume; unsupported malformed lines remain warnings and are not counted. | + ### Why unsupported evidence is not counted Unsupported lines are parser warnings, not `AuthSignal` records. They may appear in `top_unknown_patterns`, but they do not carry the `counts_as_terminal_auth_failure` flag required by this rule. @@ -142,6 +166,17 @@ This rule identifies username spread from one source IP. Username spread can be The rule does not infer intent. It only states that one source IP produced attempt evidence against multiple usernames inside the configured window. +### False-positive taxonomy + +| Bucket | Review interpretation | +| --- | --- | +| NAT | Different users behind one egress address can look like one source probing multiple accounts. | +| internal scanner | Authorized username-enumeration tests or account-audit tooling can touch many usernames by design. | +| lab replay | Replayed lab logs can preserve synthetic username spread without representing live probing. | +| shared bastion | Shared administrative entry points can produce attempts for several accounts from one source IP. | +| scheduled admin task | Account validation, migration, or monitoring jobs can try multiple service or user accounts in one window. | +| malformed log replay | Replayed or partially malformed evidence can duplicate username variety; unsupported records remain parser warnings and do not add usernames. | + ### Why unsupported evidence is not counted Unsupported records do not provide normalized usernames, source IPs, or attempt-evidence flags. Counting them would turn parser uncertainty into detector confidence. @@ -194,6 +229,17 @@ This rule identifies concentrated sudo command activity by one user. It does not The finding is strongest when reviewed with session context, change windows, host ownership, and the command text preserved in the report. +### False-positive taxonomy + +| Bucket | Review interpretation | +| --- | --- | +| NAT | Usually not a primary explanation because this rule groups by `username`, but it may matter when reviewed alongside source-IP findings. | +| internal scanner | Endpoint assessment, compliance checks, or privileged inventory tooling can run several sudo commands quickly. | +| lab replay | Demo or training logs can replay a compact privileged-command sequence. | +| shared bastion | Shared administrative accounts or jump-host workflows can concentrate privileged commands under one username. | +| scheduled admin task | Maintenance windows, package updates, service repair, or scripted operations can produce bursty sudo activity. | +| malformed log replay | Duplicated sudo lines or replayed command logs can inflate the command count; unsupported malformed sudo-like lines stay out of rule input. | + ### Why unsupported evidence is not counted Unsupported sudo-like lines are parser warnings, not sudo burst signals. They do not carry `counts_as_sudo_burst_evidence`.