WAF v1 compliance definition-of-done (PCI 6.4.2: audit logging, redaction, rule-change trail, health signal, monitor mode, starter pack) #518

Context

Security/compliance review of the WAF proposal (Aron, 2026-07-02; design doc: Confluence SD "Harper WAF — Design Proposal"; component PR: #517). Verdict: the enforcement engineering is strong, but a WAF that regulated customers can buy has three legs — enforce, prove, operate — and v1 currently only stands up the first. PCI DSS 4.0 Req 6.4.2 (mandatory since 2025-03) requires the automated solution to be actively running, generating audit logs, and configured to block or alert for immediate investigation — that makes several "productize-later" items part of what "WAF" means, not polish.

v1 definition-of-done (moved up from "productize")

• Blocked/logged-request audit logging ships with the component: structured records (timestamp, source IP, rule id, action, request summary) durable enough for assessment evidence, with a path to alerting. Without this a customer cannot pass a PCI assessment using our WAF.
• Log content redaction policy before any logging ships: WAF logs capture paths, query strings, and headers → tokens, PII, potentially PANs. PCI forbids logging PAN; GDPR expects minimization. Define masking rules now — retrofitting redaction into a shipped log format is miserable.
• Rule-change audit trail: who changed which rule, when, before/after values (SOC 2 change management; PCI Req 10). Cheap while rule management is four registered operations. Investigate first: Harper table-level audit on system.hdb_waf_rules may provide most of this natively (read_audit_log records operations with originating user) — if so this is enablement + documentation, not new machinery.
• Enforcement health signal: "actively running" is literal requirement language. Fail-open on subscription/compile failure is the chosen default — it must be documented, ideally configurable, and observable (a health/status surface proving the WAF is enforcing, e.g. rules loaded + last-recompile timestamp + subscription liveness).
• Global monitor mode (detection-only): per-rule log action gets most of the way; name it as an explicit mode — every customer expects a tuning period, every QSA asks.
• Default starter rule pack: an empty rule table "detects and prevents" nothing (6.4.2). Ship OWASP-Top-10-injection-floor coverage on path/query. Note this also pressures the requestBody phase priority — most real injection arrives in POST bodies, and the label "WAF" carries assessor expectations; be careful with the word in customer-facing material until coverage matches.

Open-question resolutions (from the same review)

• Block responses: per-rule blockStatus + fixed minimal body for v1; no custom bodies (info-leak / template-injection surface for zero compliance benefit).
• Log rules alongside a block: log them — enforcement can short-circuit, telemetry must not (being fixed in WAF component: rule-table-driven request filtering with live updates, reserved v1 schema, shadow/monitor mode, and activation gating #517 directly).
• Non-SU denial as 400 op-not-found: acceptable, no core change.
• Rate limiting: documented per-worker approximation is fine.

Plan-for-later (decisions now must not preclude)

• RBAC below super_user for rule management (separation of duties; today one compromised super_user on any node controls traffic fleet-wide via replication). Don't freeze the rule schema/authz in a way that blocks it.
• Compliance reporting: rule-set export, config attestation, blocked-traffic summaries (customers must show auditors the control exists and operates; Studio UI is planned, reporting isn't).

Symphony-side counterparts: HarperFast/symphony#11 (hot-swappable protection config — also a prerequisite for the WAF→Symphony blocklist feed), #12 (JA4), #13 (deployment security docs).

Filed by KrAIs (Claude) on Kris's behalf, digesting Aron's review.

🤖 Generated with Claude Code