[P0] Put proven WAF/IDS engines in the enforcement path and publish detection-quality evidence

[seonghobae]

Production blocker

Wardnet explicitly describes itself as a gateway/SOC control-plane baseline rather than a complete WAF or IDS. Coraza audit and Suricata EVE HTTP ingest can translate external evidence, but production protection requires a continuously operated, versioned, fail-safe enforcement path backed by proven engines—not only hand-written indicator scoring or manually posted audit documents.

Audited protected base: b53dc7a1b8904a16752abbdc04429df893a4e32e.

Required product architecture

HTTP WAF

1. Integrate Coraza with a pinned, reviewed OWASP Core Rule Set in the live HTTP transaction path, either in-process or through a narrowly specified sidecar/adapter contract.
2. Cover request headers/body, response headers/body where enabled, method/path/query normalization, decompression and transfer framing, body-size/time limits, multipart handling, protocol errors, and streaming behavior.
3. Preserve route-scoped monitor/block operation, but define deterministic precedence between Wardnet policy, CRS anomaly scores, explicit exclusions, emergency overrides, and upstream responses.
4. Version rules, exclusions, thresholds, and policy bundles; support dry-run simulation, staged rollout, rollback, expiration, approval, and immutable audit evidence.
5. Never silently continue with an unknown/failed ruleset. Define fail-closed or explicitly degraded behavior per traffic class.

Network IDS

1. Operate a supported Suricata EVE tail/shipper or equivalent durable ingest path rather than requiring ad hoc HTTP posts.
2. Authenticate the producer, bind events to sensor identity/config/version, preserve sequence/time/provenance, and deduplicate replayed events.
3. Correlate network alerts to gateway requests, tenant, route, policy version, and external-effect decisions without fabricating certainty when identifiers are absent.
4. Define sensor outage, backlog, late event, clock skew, malformed event, and version compatibility behavior through the durable outbox/worker model in [P0] Add a transactional outbox and idempotent leased workers for external effects #81.

AI SOC boundary

• AI may summarize, cluster, prioritize, and recommend.
• It must not replace CRS/Suricata authority, invent unsupported indicators, or activate enforcement without the human approval contract in [P1] Integrate Keyverse identity, tenant authorization, consent, and human approval evidence #82.
• Every recommendation must cite the source events/rules, model/provider/version, prompt/policy version, confidence/calibration evidence, and approval outcome.

Detection-quality evidence

Create a reproducible evaluation harness with versioned benign and malicious corpora plus production-safe replay fixtures.

Report at minimum:

• true-positive rate/recall, false-positive rate, precision, and miss categories by attack family and route class;
• latency/throughput/resource impact at representative body sizes and concurrency;
• robustness to encoding, canonicalization, request smuggling/framing differences, multipart, compressed payloads, and fragmented evidence;
• rule/exclusion regression deltas between releases;
• calibration and abstention/error rates for AI triage separately from deterministic engine detection;
• exact dataset/license/provenance and confidence intervals where sampling is used.

Do not publish a single aggregate accuracy number that hides attack families, route classes, or severe false positives.

RED → GREEN verification

• RED: prove attacks can reach the current mock/indicator baseline without authoritative CRS/Suricata enforcement.
• GREEN: run hermetic end-to-end attacks through the real server and engine adapter, not only parser unit tests.
• Include OWASP-style injection/traversal/protocol cases, benign business payloads, known false-positive patterns, corrupted/missing rulesets, sensor outage/backlog, duplicate/late EVE, and rollback.
• Connect issue 서버를 켜고 Strix가 포트를 향해 각종 공격을 할 때 감지해내야 함 (CI) #11's Strix lane to the exact candidate deployment and publish attack/decision evidence.
• Add fuzz/property tests at every untrusted parser boundary and maintain 100% production statement/branch coverage for Wardnet-owned code.

Acceptance criteria

• Production traffic is evaluated by a proven WAF engine with pinned rules and auditable policy composition.
• Live IDS evidence is authenticated, durable, deduplicated, and correlated.
• Engine/ruleset failure has documented and tested traffic-class behavior.
• Rule changes are simulated, approved, staged, reversible, and attributable.
• Detection and false-positive evidence meets declared release thresholds by attack/route class.
• AI SOC remains advisory until a human-approved action is committed.

Dependencies and related work

• 서버를 켜고 Strix가 포트를 향해 각종 공격을 할 때 감지해내야 함 (CI) #11: active attack CI acceptance.
• AI SOC: quarantine-sandbox malware analysis for attachment/link lures (validated by a real incident) #38: quarantined malware-analysis expansion; not required to pretend the WAF/IDS path is complete.
• [P0] Add a transactional outbox and idempotent leased workers for external effects #81: durable event/worker execution.
• [P1] Integrate Keyverse identity, tenant authorization, consent, and human approval evidence #82: human approval and identity.
• [P1] Add bounded distributed admission control, trusted client attribution, and overload behavior #83: overload protection during attacks.
• [P1] Build an immutable signed release, promotion, and rollback pipeline #84: immutable engine/ruleset packaging and promotion.

References

• OWASP Foundation. (2025). OWASP Core Rule Set documentation. https://coreruleset.org/docs/
• Coraza. (n.d.). Coraza Web Application Firewall. https://coraza.io/docs/
• Open Information Security Foundation. (2026). Suricata user guide. https://docs.suricata.io/
• OWASP Foundation. (2025). OWASP Application Security Verification Standard 5.0.0. https://owasp.org/www-project-application-security-verification-standard/
• National Institute of Standards and Technology. (2022). Secure Software Development Framework (SSDF) version 1.1 (NIST SP 800-218). https://doi.org/10.6028/NIST.SP.800-218