Anomaly Detection

Anomaly Detection

--models adds anomaly detectors to prohori detect, incidents and triage (v0.2.0). They look for a source address that behaves unlike the others in the same log. The full page, with every table, is docs/ANOMALY.md.

prohori detect access.log --models
prohori incidents app.jsonl --models
prohori triage auth.log --models -o triage/

How it works

1. Events are grouped by source IP into five-minute windows.
2. Each window gets thirteen behaviour features: sign-in attempts and failures, accounts and paths touched, the share of 4xx responses, path entropy, user-agent diversity, new clients, night activity and the event rate.
3. Each detector compares the windows of the log with each other:
   • a robust z-score (base install), flagging a window with z of at least 12;
   • an Isolation Forest (ml extra), flagging an anomaly score of at least 0.8.
4. Flagged windows become low alerts with detector_kind: model, explained with feature names and numbers only, and join the incidents. Such incidents say that unusual is not proof of an attack.

Nothing is trained in advance and no model file is loaded. A log needs at least 20 windows.

How well it works

On the simulator's held-out attacks (cut-offs were chosen on the default variants first):

Detector	Attacks caught	False alerts a run	Caught only by it
Detection rules	36/40	6.47	-
Robust z-score	15/40	0.0	0
Isolation Forest	17/40	0.35	0

The detectors catch loud attacks (brute force, scanning, injection) with almost no false alerts, but nothing the rules miss: slow or spread-out attacks look ordinary in a five-minute window from one address. Their false alerts come from addresses several accounts share, such as a NAT. Use them as a quiet second signal next to the rules.