High Assurance by Architectural Constraint
Sovereign Fortress is our architecture and engineering concept for security systems whose authority, communication and configuration are explicitly constrained. The formal architecture name is Sovereign Fortress High Assurance Security Enforcement Platform.
Its shared foundation combines SELinux Type Enforcement, Linux namespaces and restricted Linux capabilities with explicit trust boundaries and verification. Each component has a defined responsibility and only the access required to perform it. These principles guide how our security products and services are structured and operated.
The first application is our High Assurance Web Application and API Protection (WAAP) project. It adds application inspection, behavioural signals and risk evaluation for web and API protection. Future Sovereign Fortress products and services can apply the same architectural foundation with protection mechanisms suited to their own purpose.
Sovereign Fortress / Architecture principles
Boundaries define the architecture
Reviewed configuration establishes the runtime policy. Security observations inform bounded decision-making; enforcement applies authorised decisions. Operational evidence supports independent review.
Approved configuration establishes runtime policy and permitted communication.
↓ Validated configuration
Runtime authority boundaries
Bounded inputs with defined provenance and lifetime.
↓ Security information
Explicit authority, defined policy and failure handling.
↓ Authorised decision
Constrained permissions and restricted communication.
SELinux Type Enforcement · Linux namespaces · restricted Linux capabilities
↓ Operational evidence
Tests, events and policy review establish deployment properties.
SELinux as an architectural foundation
Sovereign Fortress is built on the SELinux MLS policy. The security platform’s runtime processes operate in confined SELinux domains, with no unconfined runtime processes.
Policy defines which resources a service may access and which operations it may perform. A gateway, a risk service and an event collector have different responsibilities; their permissions should reflect those differences. Ordinary file ownership and application permissions remain part of the access checks, while SELinux supplies the mandatory policy boundary.
This makes confinement concrete: which configuration may a process read, where may it write, and which other services may it interact with? The effective domains, resource labels and policy rules provide the basis for review and tests of both permitted and prohibited access.
Our SELinux overview explains the security models behind these controls and links to the SELinux Project’s documentation.
For public authorities and other organisations with demanding security requirements, the value lies in those enforceable boundaries and the evidence supporting them. Policy review, controlled administration and repeatable validation connect the architecture to the deployed system.
Linux namespaces and capabilities
Linux namespaces separate selected views of kernel resources, including network environments and mounted filesystems. Their configuration determines which resources services share and which remain separate. Communication across those boundaries is governed by network and access policy.
Linux capabilities divide privileged operations into individually controlled permissions. Sovereign Fortress limits the capabilities available to each service to its operational requirements, reducing the privileged operations a compromised process could perform.
Together, these mechanisms constrain different parts of a service’s authority: namespaces separate resource views, capabilities limit privileged operations, and SELinux Type Enforcement controls access between labelled processes and resources. The effective boundary comes from their combined configuration. The Linux manual pages describe namespaces and capabilities in more detail.
Runtime network separation
Network reachability is part of a component’s authority. Sovereign Fortress treats separation between security runtime networking and host networking as an explicit architectural boundary. Traffic-processing services should have only the network access required for their responsibilities, with permitted communication paths defined and reviewed.
Our High Assurance WAAP applies this principle through a dedicated network namespace shared by its runtime services and separated from the host’s network stack. macvlan interfaces provide connections to the required networks, while Virtual Routing and Forwarding (VRF) separates routing domains. Explicit communication rules constrain access to application backends and operational services, including connections made by components that share the runtime network environment.
This network boundary complements SELinux confinement and restricted capabilities. Together, they limit the resources, privileged operations and network destinations available to a compromised component. The Firewall overview describes how the principle is applied to the protection platform.
Explicit trust boundaries
A security component needs a defined responsibility and a bounded set of permissions. Application traffic, policy administration and event handling do not all need the same access. Separating these responsibilities helps make the consequences of a failure or compromise easier to examine.
SELinux and Mandatory Access Control support service confinement within this foundation. Network segmentation and restricted communication paths provide complementary boundaries. These mechanisms need to be designed together and validated in the deployed configuration.
Controlled decisions and enforcement
The architecture distinguishes security signals from decisions and enforcement. An observation may inform a decision, but it should not acquire unrestricted authority over traffic or configuration.
For enforcement-critical paths, the design objective is explicit failure behaviour: loss of a required decision or control should not silently open an unintended path. The exact behaviour belongs in the deployment’s policy and tests.
Local control and reproducible changes
Local control means maintaining authority over policy, configuration and the handling of security information. Dependencies and external intelligence should have a documented role and a bounded influence.
Versioned configuration, reproducible generation and validation make proposed changes reviewable before they reach the runtime. Operational feedback then helps compare the intended configuration with observed behaviour.
Assurance through evidence
High assurance is an engineering objective that needs evidence. Useful evidence includes policy reviews, configuration validation, tests of permitted and denied paths, security events and documented failure handling.
An architecture describes the intended boundaries. Implementation and testing establish which properties a particular deployment achieves. Keeping those two views connected is a central part of the work.
Security engineering references
NSA’s Embracing a Zero Trust Security Model is a useful reference for least privilege, explicit verification and risk-aware access decisions. These principles help frame the questions we ask about service access, trust boundaries and operational evidence.
NSA’s Raise the Bar strategy addresses cross-domain solutions: controlled information exchange between security domains. It provides context for high-assurance architecture discussions. A WAF architecture is not, by itself, evidence of conformance to cross-domain requirements or NSA approval. Any specific conformance claim would require an applicable requirements baseline and supporting verification.
The first application: High Assurance WAAP
The Sovereign Fortress High Assurance WAAP applies these principles to web application and API protection. It combines application traffic controls with attention to the security and operability of the gateway itself.
We develop Sovereign Fortress through architecture work, implementation and validation. Specific deployment properties are established through configuration and verification. For a discussion of your application and infrastructure requirements, contact SELinuxComputing.