Skip to content

ADR 0032 — DLP egress monitor + behavioural anomaly detector

  • Status: Accepted (formalized 2026-05-12 with v3.7.0 — Wave 13 + Wave 14 shipping)
  • Date: 2026-05-11 (locked), 2026-05-12 (formalized)
  • Deciders: TLSStress.Art project
  • Targets: v3.7.0 (5 DLP baseline rules + 4 anomaly detectors)
  • Patent claim family: claim #23 — bench-internal DLP-then-anomaly chain as ZTP-prem camadas 11 + 12
  • Umbrella ADR: 0026

Context

The first ten ZTP-prem camadas address who can read the keys, who can run code, and what we record about it. They do not address two residual insider attack patterns:

  1. Slow exfiltration through legitimate-looking egress — the operator's bench has limited, allowlisted egress (CLONER tracked-fetch, release-feed pull, telemetry push). An insider can weaponise any one of these by tunnelling lab traffic summaries or customer URL lists out as part of an otherwise normal request.

  2. Behavioural drift — the insider produces a rate of denials, break-glass invocations, Tier B pod admissions, or off-hours activity that's individually-allowable but collectively suspicious. The sealed audit log (ADR 0029) records it, but no one reads 1M JSONL lines a day.

Both gaps need bench-internal mitigation, because once data leaves the bench through an allowlisted channel, it's gone.

Decision

Ship two layered detectors as Tier A modules:

DLP egress monitor (camada 11)

A tracked-fetch wrapper sits between every bench module that issues outbound HTTP and the actual fetch/http.Client. It:

  • Records request URL + size + content-type + timestamp into the sealed audit log
  • Pre-screens the request body against 5 baseline rules for v3.7.0:
  • PEM-format certificate/key material (catches -----BEGIN)
  • K8s ServiceAccount tokens (catches JWT prefix + audience)
  • Persona webserver TLS material (catches the project's CA cert subject DN)
  • Sealed audit hash-chain fragments (catches the JSONL signature pattern)
  • Cloud HSM ISK fingerprints (catches the Patent #18 envelope identifiers)

A rule hit is not a block — the request still goes through, because v3.7.0 prioritises observability over policing. The hit is recorded into the sealed audit log + raised in the dashboard's DLP card. Mode-flip to "block on hit" is planned for v6.0+ once false-positive baselines are established.

Source: dashboard/src/lib/ztp-prem/dlp/.

Behavioural anomaly detector (camada 12)

A rule-based detector reads the sealed audit log + admission audit + DLP events and runs 4 detectors for v3.7.0:

  1. Denial-flood — admission-webhook denial rate >N/min for

    M minutes (sustained pressure)

  2. Break-glass-burst — break-glass label usage rate >threshold (incident-response abuse)
  3. Tier-B-ratio-spike — Tier B Pod admission ratio per namespace deviating from the rolling baseline
  4. Off-hours-activity — admission/DLP/licence-check events outside the customer's operator-defined business hours

Each detector emits a named event into the sealed audit log itself (closing the loop: detection is auditable). Detectors are not ML models — they're rule-based, explainable, customer- auditable Tier A. ML upgrades are future work and explicitly out of scope here.

Source: dashboard/src/lib/ztp-prem/anomaly/.

Consequences

Pros - Closes the two residual insider patterns with bench-internal detection — no cloud round-trip required, works air-gapped - DLP baselines are pre-seeded with project-specific patterns (HSM fingerprints, sealed-chain fragments) — false-positive rate is acceptable on day one - Anomaly detectors are rule-based and explainable, so customer compliance audits can certify them without an ML risk review - Both detectors are Tier A — customers can fork and extend the rule set

Cons - DLP is observe-only in v3.7.0 (records, doesn't block) — explicit trade-off for false-positive baselining - Rule-based anomaly detection misses creative novel patterns (intentional — ML upgrade is deferred) - DLP cost: every outbound fetch grows by the pre-screen latency (microseconds, but amortisable)

Reversibility: high. Both modules ship as drop-in wrappers that can be disabled by feature flag. We retain the option to move DLP to block-mode in v6.0+ without breaking the v3.7.0 contract.

Last verified against shipping code: v3.7.0 (2026-05-12).