Hand-written security rules go stale the moment a deployment changes. We report early lessons from building a security baseline that learns itself — and the poisoning traps we are designing against.
Rules rot quietly
Every manually authored security baseline carries an expiry date that nobody writes down. The rule was correct for the workload it was written against; six months later the deployment has scaled, traffic has changed shape, and the rule is either silent (because it matches nothing) or screaming (because it matches everything).
The obvious fix is to learn the baseline from observed behaviour. The obvious fix is also dangerous: a system that learns what normal looks like will cheerfully absorb an attacker's behaviour as normal too.
Frequency is not normality
The single most valuable idea from our first round of experiments is to separate behaviour that is frequent from behaviour that is normative. Frequent-but-unhealthy states — a leaking process, a degraded replica — look statistically identical to healthy ones. A baseline that treats frequency as validity will defend a system on its way to failure quite confidently.
Our approach is to maintain two models: a descriptive model of what happens, and a normative model of what should happen, constrained by invariants the operators can express cheaply (what may talk to what, what should never restart). Deviations from the normative model are trusted more than surprises in the descriptive one.
What comes next
The open question is poisoning resistance: can a baseline evolve continuously while staying provably resistant to an adversary who is inside the feedback loop? We are publishing our staged pre-attack dataset and the evaluation harness so the comparison can be reproduced. The problem statement on the board lists the exact metrics we care about.