What Makes a WAF High Assurance?
A high-assurance WAF needs explicit security requirements, bounded authority and evidence that its configured behaviour holds during both normal operation and failure.
A policy service becomes unavailable while a web application is receiving requests. What should the gateway do next? The answer depends on the route’s requirements, the authority of any cached decision and the failure behaviour that has actually been implemented.
This small scenario captures a large part of high-assurance engineering. A system needs clearly stated security properties and reasons to trust that those properties hold in its intended environment. The reasoning must extend to failures, changes and the platform’s own privileges.
Begin with a claim that can be examined
“Protect this application” is a useful business objective but an incomplete verification target. More specific claims can be investigated: an unauthenticated request must not reach a protected route; a required challenge must not be reusable; the request-processing service must not be able to modify its enforcement policy.
Each claim needs a scope. Identify the application routes, relevant traffic formats, software/configuration versions and operational assumptions. A successful test of an ordinary HTTP request says little about inspection of every message in a long-lived protocol connection. A claim about one deployment should remain attached to that deployment’s evidence.
This discipline gives reviewers something concrete to challenge. They can ask which component enforces the property, which assumptions it depends on and what would constitute a failed test.
Make authority visible
A WAF platform combines several responsibilities: application inspection, external or local security observations, risk evaluation, traffic enforcement and configuration management. They need different permissions.
An intelligence input may report a reputation signal. A decision service may evaluate authorised inputs under a selected policy. A gateway may apply the resulting action. A configuration process may introduce a reviewed change. Describing those roles makes it possible to ask whether any component has acquired more authority than its job requires.
The boundary matters particularly when a component is compromised. A useful review asks whether a signal producer could write authoritative state, whether a gateway could rewrite its own policy, and whether an event-processing service could reach management interfaces. These are questions about permitted actions and communication, not just component placement on a diagram.
Define failure behaviour per dependency
Different dependencies deserve different treatment. Loss of an advisory reputation feed may permit a documented degraded mode. Loss of an enforcement-critical authorisation decision may require denying the affected operation. A cached result is only useful while its scope, provenance and lifetime remain acceptable.
The term fail closed should therefore be accompanied by a concrete description: which operation is denied, under which failure, at which enforcement point? Include startup, stale state, partial recovery and reconnection. A design that denies during an outage but briefly bypasses the check after restart has a different property from the one usually intended.
The test plan should exercise those transitions. An error code to the client is useful evidence, but the backend observation also matters when the requirement concerns preventing delivery to the application.
Control changes as part of the security boundary
Security properties can change when a route, policy, image or dependency changes. A reviewable workflow connects the proposed change with the generated runtime configuration and the capabilities of the selected software.
Versioned inputs, compilation and validation help make that connection explicit. They can catch unsupported settings and inconsistent intent before deployment. They still need a controlled path to the runtime and a way to establish which version is actually active.
A rollback also needs a security interpretation. Restoring an old configuration may restore availability while reintroducing an earlier policy defect. Define which known-good state is acceptable and what evidence must accompany its restoration.
Build assurance from several kinds of evidence
Architecture review, policy review, deterministic tests, exploratory security testing and operational observations answer different questions. Their combination is stronger when each result states what was examined and what remains outside its scope.
A concise assurance record can link:
- A security requirement and its operational assumptions.
- The component and policy responsible for enforcement.
- A review of that component’s authority and reachable resources.
- Positive, negative and failure-transition tests.
- The versioned configuration and observations produced by those tests.
Independent assessment can challenge assumptions that an internal test suite shares with the implementation. Its value depends on the assessment’s actual scope and method. Neither a collection of passing tests nor an architectural description alone establishes universal protection.
Sovereign Fortress as the organising approach
We use Sovereign Fortress to organise this work around explicit trust boundaries, controlled authority and reviewable evidence. Its first application is SELinux Firewall, our High Assurance Web Application and API Protection (WAAP) engineering project.
Its runtime confinement combines SELinux Type Enforcement, Linux namespaces and restricted Linux capabilities. SELinux controls access to labelled resources, namespaces separate selected resource views, and capability restrictions limit privileged operations. Review and testing need to establish how these controls work together in the deployed system. Protecting the WAF Itself examines those boundaries in more detail.
The central question is practical: can we explain the intended restriction, identify the mechanism that enforces it and produce evidence for the relevant version and deployment? That question guides both implementation choices and the work needed before making a specific assurance claim.
References
- NIST SP 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems, a broader systems-security engineering reference.
- Sovereign Fortress architecture concept.