DISA Security Requirements Guides. Technology-Specific Controls Forged from 800-53.

Security Requirements Guides (SRGs) are published by the Defense Information Systems Agency (DISA) to define security requirements for broad technology categories used across the Department of Defense. Where NIST 800-53 provides a comprehensive catalog of security and privacy controls applicable to all federal information systems, SRGs narrow that catalog to a specific technology domain and add implementation detail relevant to that domain. The General Purpose Operating System SRG, for example, takes NIST 800-53 controls related to access control, audit, configuration management, and system integrity and specifies how those controls must manifest in an operating system context. The Application Security SRG does the same for application-layer concerns: input validation, session management, error handling, cryptographic implementation. Each SRG is structured as a set of requirements identified by SRG-prefixed identifiers (SRG-OS, SRG-APP, SRG-NET, SRG-WS, SRG-DB, SRG-CTR), each traceable to one or more NIST 800-53 controls. SRGs are authoritative. They carry the weight of DoD policy and form the basis for all product-specific Security Technical Implementation Guides.

The SRG hierarchy establishes a clear separation between technology categories and specific products. An SRG applies to a category: all general-purpose operating systems, all web servers, all databases. A STIG applies to a specific product within that category: RHEL 9, Apache HTTP Server, PostgreSQL 15. The SRG defines WHAT must be secured. The STIG defines HOW a specific product achieves that requirement. This two-tier architecture means organizations can assess their security posture at the technology-category level (using SRGs) before drilling into product-specific implementation details (using STIGs). When a new product enters the environment, the SRG requirements already apply. The STIG provides the product-specific verification procedures. Organizations that understand their SRG posture understand their security obligations at the architectural level, independent of which specific products they deploy. This architectural perspective is valuable during technology selection, migration planning, and authorization boundary definition.

Redoubt Forge supports six major SRGs as overlays on NIST 800-53. The General Purpose OS SRG covers operating system security requirements for authentication, access control, auditing, and configuration management. The Application Security SRG addresses application-layer controls including input validation, session management, error handling, and cryptographic implementation. The Network Device SRG specifies requirements for routers, switches, firewalls, and other network infrastructure components across management, control, and data planes. The Web Server SRG covers HTTP security, TLS configuration, content restrictions, and web-specific access controls. The Database SRG defines requirements for data access control, encryption at rest and in transit, audit logging, and backup and recovery procedures. The Container Platform SRG addresses container image security, orchestration platform hardening, runtime isolation, and image provenance verification. Each SRG is loaded as an overlay that extends your base 800-53 assessment with technology-specific requirements relevant to the components in your authorization boundary.

SRGs operate as overlays on the NIST 800-53 control catalog, following the overlay composition model defined in NIST SP 800-53B. An overlay performs three types of operations on a base framework. ADD operations introduce new requirements that do not exist in the base catalog. The GP OS SRG adds operating-system-specific requirements for kernel hardening, file system permissions, and boot integrity that have no direct equivalent in 800-53's technology-neutral language. MODIFY operations refine existing controls with technology-specific implementation detail. Where 800-53 control AC-2 requires account management, the Database SRG modifies that control to specify database-level account management requirements: schema-level privileges, role separation between application accounts and administrative accounts, and audit of privilege escalation within the database engine. PARAMETER operations set specific values for control parameters that the base framework leaves to organizational definition. Where 800-53 says "organization-defined frequency" for access reviews, the Network Device SRG may specify quarterly review of administrative access to network infrastructure.

The overlay composition engine in Rampart stacks multiple SRGs onto a single base 800-53 assessment. An environment running a web application on Linux with a PostgreSQL database behind a network firewall activates four SRGs simultaneously: GP OS, Application Security, Web Server, and Database. Each overlay applies its ADD, MODIFY, and PARAMETER operations to the base framework. The composition engine resolves conflicts through a deterministic precedence model. When two overlays modify the same 800-53 control with different parameters, the more restrictive parameter takes precedence. When two overlays add requirements that address the same security function, both requirements apply unless one explicitly supersedes the other. The precedence chain is transparent and auditable: every requirement in the composed view traces back to its source overlay, the specific operation that introduced it, and the base 800-53 control it modifies or extends. Organizations can inspect the composition at any level of detail, from the unified requirement list to the individual overlay operations that produced it.

No engine changes are required to activate SRG overlays. Rampart's overlay composition is a core capability that applies uniformly to all overlay types: DISA SRGs, CIS Benchmarks, privacy overlays, and organization-defined overlays at the Enterprise tier. Activating the GP OS SRG overlay adds its requirements to your assessment. Deactivating it removes them. The composition recalculates automatically. This means organizations can model different overlay combinations to understand their impact before committing. An organization preparing for a DoD authorization can activate all applicable SRGs and see the full requirement set before beginning assessment. An organization migrating from one technology stack to another can compare the SRG requirements for each stack side by side: deactivate the Database SRG, activate the Container Platform SRG, and observe how the composed requirement set changes. Artificer recommends which SRGs to activate based on the technology inventory that Sentinel has discovered in your connected infrastructure. If Sentinel finds Linux hosts, Artificer suggests the GP OS SRG. If it finds web server processes, Artificer suggests the Web Server SRG. The recommendation is informed by what is actually running, not what was documented months ago.

The General Purpose Operating System SRG defines security requirements for any operating system that provides general computing services: Linux distributions, Windows variants, and Unix-based systems deployed across the authorization boundary. The GP OS SRG is the most broadly applicable of the six guides because nearly every system in an environment runs an operating system. Its requirements address the foundational security functions that every OS must provide: user authentication and credential management, discretionary and mandatory access control enforcement, audit event generation and log protection, configuration baseline establishment and drift prevention, and cryptographic module integration for data protection. The SRG organizes these requirements into categories that map to NIST 800-53 control families. SRG-OS-000004 maps to AC-2, requiring the operating system to provide automated mechanisms for account management. SRG-OS-000021 maps to AC-7, requiring the OS to enforce a limit on consecutive invalid logon attempts. Each requirement carries a severity category (CAT I, CAT II, CAT III) indicating its security significance and the urgency of remediation when unmet.

Key control areas within the GP OS SRG span every layer of operating system security. Authentication controls require multifactor authentication for privileged access, password complexity enforcement, credential storage protection using approved cryptographic hashing algorithms, and session locking after periods of inactivity. Access control requirements mandate role-based privilege assignment, least-privilege enforcement for user and service accounts, file system permission management that prevents unauthorized access to system files and audit data, and separation between administrative and operational functions. Audit requirements specify which events the OS must log (authentication attempts, privilege escalation, file access to sensitive directories, configuration changes, account modifications), how those logs must be protected from tampering, and where they must be transmitted for centralized collection. Configuration management requirements establish that the OS must operate from a defined baseline, that deviations from that baseline must be detectable, and that unauthorized modifications to system files trigger alerts. These requirements are concrete and verifiable. They specify observable behaviors, not aspirational goals.

Vanguard scans operating systems against GP OS SRG requirements using STIG-derived check procedures adapted to the SRG's technology-category level. Vanguard executes automated checks for password policy configuration, audit rule presence, file permission correctness, service configuration state, cryptographic module status, and kernel parameter settings. Each scan result maps to a specific SRG requirement identifier, which traces to the underlying 800-53 control. Scan results flow into Rampart, where they serve as evidence for the composed assessment. A Vanguard finding that the password minimum length is set to 8 characters when the SRG requires 15 maps to SRG-OS-000078, which traces to IA-5(1), which satisfies a portion of the GP OS overlay on your base 800-53 assessment. Sentinel monitors OS configurations continuously between Vanguard scans. When a configuration drifts from the assessed baseline, Sentinel detects the change and triggers re-evaluation of affected SRG requirements. The result is continuous GP OS compliance assessment, not periodic snapshot collection that decays between scan cycles.

The Application Security SRG addresses security requirements at the application layer, above the operating system and below the user interface. Applications process, store, and transmit data in ways that operating system controls cannot fully govern. An OS can enforce file permissions, but it cannot validate that an application properly sanitizes user input before constructing a database query. An OS can enforce process isolation, but it cannot ensure that an application manages session tokens securely or handles authentication failures without leaking information to an attacker. The Application Security SRG fills this gap by defining requirements that applications must satisfy independent of the underlying operating system or infrastructure. These requirements apply to custom-developed applications, commercial off-the-shelf software deployed within the authorization boundary, and internally developed tools and utilities that handle controlled or sensitive data. The SRG uses SRG-APP prefixed identifiers, each traceable to NIST 800-53 controls, and each carrying a severity category that reflects the security impact of non-compliance.

Key control areas within the Application Security SRG cover the attack surface that application code exposes. Input validation requirements mandate that applications validate all input received from external sources before processing, reject input that does not conform to expected formats, and protect against injection attacks (SQL injection, command injection, cross-site scripting, XML external entity processing). Session management requirements specify that applications must generate session identifiers using cryptographically secure random number generators, invalidate sessions after defined inactivity periods, prevent session fixation attacks, and transmit session tokens only over encrypted channels. Error handling requirements mandate that applications must not expose internal implementation details (stack traces, database schemas, internal IP addresses) in error responses visible to users or external systems. Cryptographic requirements specify that applications must use FIPS-validated cryptographic modules for all encryption, hashing, and digital signature operations, must not implement custom cryptographic algorithms, and must manage cryptographic keys according to NIST 800-57 guidelines. These are not suggestions. They are verifiable requirements with defined check procedures.

Vanguard maps its SAST, DAST, and SCA scan results directly to Application Security SRG requirements. A SAST finding that identifies an SQL injection vulnerability in application source code maps to SRG-APP-000251, which traces to SI-10 (Information Input Validation) in NIST 800-53. A DAST finding that reveals session tokens transmitted over unencrypted HTTP maps to SRG-APP-000014, which traces to SC-8 (Transmission Confidentiality and Integrity). Vanguard's dependency analysis identifies third-party libraries with known vulnerabilities, mapping each to SRG-APP-000454 (SI-2, Flaw Remediation) with specific CVE references and remediation guidance. These scan-to-SRG mappings are not approximate alignments. They are deterministic relationships maintained in Rampart's control mapping engine. When Vanguard scans produce new findings, affected SRG requirements are re-evaluated automatically. When developers remediate a vulnerability and Vanguard's next scan confirms the fix, the corresponding SRG requirement score improves without manual intervention. The feedback loop between development activity and compliance posture is continuous and automated.

The Network Device SRG defines security requirements for routers, switches, firewalls, load balancers, and other network infrastructure components that route, filter, and inspect traffic within and across authorization boundaries. Network devices occupy a privileged position in any security architecture. They control which traffic flows between network segments, enforce boundary protections between trust zones, and provide the transport layer that every other system depends on. A compromised network device can bypass every application-layer and operating-system-layer control in the environment by redirecting, intercepting, or modifying traffic at the network level. The Network Device SRG recognizes this privileged position by imposing requirements across all three operational planes of a network device. The management plane handles administrative access: how operators authenticate to the device, what protocols they use, and how configuration changes are authorized and logged. The control plane handles routing and switching decisions: protocol authentication, route filtering, and protection against routing table manipulation. The data plane handles traffic forwarding: access control lists, inspection policies, and traffic filtering rules.

Key requirements within the Network Device SRG address the most consequential security functions that network infrastructure provides. Management plane requirements mandate encrypted administrative access (SSH, HTTPS; no Telnet, no HTTP), multifactor authentication for privileged access, role-based administrative access that separates read-only monitoring from configuration change authority, and comprehensive logging of all administrative actions with tamper-evident log transmission to centralized collection infrastructure. Control plane requirements specify that routing protocols must use cryptographic authentication to prevent route injection attacks, that the device must limit the rate and source of control plane traffic to prevent denial-of-service conditions, and that routing table changes must be logged and auditable. Data plane requirements mandate deny-by-default access control policies, traffic inspection capabilities at authorization boundary crossing points, protection against IP spoofing and other traffic manipulation techniques, and enforcement of network segmentation between trust zones. Each requirement maps to specific NIST 800-53 controls: management plane requirements primarily map to AC (Access Control) and AU (Audit) families, control plane requirements to SC (System and Communications Protection), and data plane requirements to SC and AC jointly.

Sentinel monitors network device configurations continuously by ingesting configuration state from connected infrastructure. When a firewall rule changes, Sentinel evaluates whether the change affects any Network Device SRG requirement. An access control list modification that opens a new port on a boundary device maps to SRG-NET-000019 (SC-7, Boundary Protection) and triggers re-evaluation. An administrative access policy change that enables an insecure management protocol maps to SRG-NET-000062 (AC-17, Remote Access) and generates a drift alert. Sentinel collects the configuration evidence that demonstrates compliance: current access control lists, active routing protocol authentication settings, management access configurations, and logging pipeline status. This evidence flows into Rampart where it supports the Network Device SRG overlay requirements in the composed assessment view. Garrison displays the complete network device inventory, providing visibility into which devices are connected, monitored, and assessed against SRG requirements. Organizations can identify network infrastructure gaps where devices exist in the environment but lack monitoring coverage or SRG assessment.

The Web Server SRG addresses security requirements specific to HTTP server infrastructure. Web servers are externally facing by design, which makes their security requirements particularly consequential. The SRG mandates TLS configuration requirements including minimum protocol versions, approved cipher suites, and certificate validation procedures. It requires content restriction controls that prevent directory listing, limit exposed HTTP methods to those required by the application, and enforce content security policies that mitigate cross-site scripting and content injection attacks. Access control requirements specify that web server administrative interfaces must be separate from application-serving interfaces, that administrative access must use encrypted channels with multifactor authentication, and that the web server must not run with elevated operating system privileges. Logging requirements mandate that the web server record all access attempts, authentication events, and error conditions with sufficient detail to reconstruct the sequence of events during incident investigation. Each requirement maps to 800-53 controls: TLS requirements to SC-8 and SC-13, access control to AC-3 and AC-6, logging to AU-3 and AU-12.

The Database SRG defines security requirements for database management systems that store, process, and retrieve structured data. Databases are high-value targets because they concentrate sensitive information in a single, queryable location. The SRG requires granular access control at the schema, table, and column level, enforcing least-privilege principles that limit each database account to the minimum permissions required for its function. Encryption requirements mandate data-at-rest protection using FIPS-validated cryptographic modules, data-in-transit protection for all client-to-server and server-to-server database communications, and transparent data encryption for sensitive columns or tablespaces. Audit logging requirements specify that the database must record all authentication attempts, privilege escalation events, data definition language operations (CREATE, ALTER, DROP), and access to tables containing sensitive data. Backup and recovery requirements mandate that database backups are encrypted, stored in a location separate from the primary database, tested on a defined schedule to verify recoverability, and retained according to the organization's data retention policy. Each requirement traces to 800-53 controls in the AC, SC, AU, and CP (Contingency Planning) families.

The Container Platform SRG addresses the security requirements unique to containerized environments: container runtimes, orchestration platforms, image registries, and the lifecycle management of container workloads. Image security requirements mandate that container images are built from approved base images, scanned for vulnerabilities before deployment, signed with cryptographic signatures that verify provenance, and stored in registries with access controls that prevent unauthorized image publication. Orchestration requirements specify that the container platform must enforce namespace isolation between workloads, restrict container capabilities to the minimum required set, prevent privileged container execution unless explicitly authorized, and enforce network policies that control inter-container communication. Runtime protection requirements mandate that containers must not mount sensitive host file systems, must run with read-only root file systems where possible, and must be monitored for anomalous process execution that could indicate compromise. Vanguard scans each technology category with specialized check procedures: web server configuration analysis for the Web Server SRG, database security assessment for the Database SRG, and container image scanning with orchestration configuration review for the Container Platform SRG. Results map directly to SRG requirement identifiers and flow into Rampart for composed assessment scoring.

Evidence collection against SRG requirements spans the full technology stack covered by each SRG's scope. For each SRG requirement, the evidence sources that demonstrate compliance must be identified: configuration parameters from operating systems, access control lists from network devices, TLS settings from web servers, privilege assignments from databases, and orchestration policies from container platforms. Evidence collection is not a periodic activity scheduled around assessment deadlines. It is a continuous process that must produce a persistent stream of configuration snapshots, compliance check results, and drift detection events. Each evidence artifact requires full provenance metadata: the source system that produced it, the timestamp of collection, the collection method, and a SHA-256 integrity hash that proves the artifact has not been modified after collection. Evidence is classified by type (automated configuration check, scan result, log extract, policy document) and freshness (how recently it was collected relative to the current assessment period). A thorough SRG evidence program covers both automated configuration checks and manual attestation requirements across every technology domain in the authorization boundary.

Many SRG requirements demand active testing rather than passive configuration observation, and this creates challenges for evidence programs. Application Security SRG requirements need source code analysis (SAST) to identify input validation failures, insecure cryptographic implementations, and session management weaknesses. Web Server SRG requirements need dynamic testing (DAST) to verify TLS configuration, HTTP security headers, and content restriction enforcement from an external perspective. Container Platform SRG requirements need image scanning to validate image provenance, vulnerability status, and base image compliance. Each of these scan types produces findings that must map to specific SRG requirement identifiers with pass/fail status, finding detail, and remediation guidance. Organizations that rely on generic vulnerability scanners find that results do not align to SRG requirement identifiers, creating a manual mapping burden that introduces errors and delays. Evidence from active scanning must carry the same provenance chain as passively collected evidence: source identification, timestamps, integrity hashes, and direct SRG requirement linkage. Without this alignment, evidence packages contain findings that assessors cannot trace to the specific SRG requirements they are supposed to satisfy.

The combination of Sentinel's continuous monitoring and Vanguard's active scanning produces a comprehensive evidence set for each SRG overlay. Sentinel catches configuration drift between Vanguard scan cycles. Vanguard tests active security behaviors that Sentinel cannot observe through configuration monitoring alone. Together, they ensure that evidence remains current across the full scope of SRG requirements. Rampart aggregates evidence from both sources, mapping each artifact to the SRG requirement it supports and scoring the requirement based on defense effectiveness, evidence coverage, and evidence freshness. When evidence for a requirement expires (the most recent artifact exceeds the configured freshness threshold), Rampart flags the requirement for re-collection. Sentinel re-collects from continuous sources automatically. Vanguard rescans on its configured schedule or on demand. Evidence that requires human action (policy document reviews, manual verification of physical controls, management authorization renewals) triggers notifications through the escalation chain. The result is an evidence posture that stays current without requiring periodic manual collection campaigns that consume engineering time and produce artifacts that begin decaying immediately after collection.

Every SRG requirement traces back to a specific NIST 800-53 control through a published, deterministic mapping maintained by DISA. This traceability is not approximate alignment or thematic similarity. It is a structural derivation: each SRG requirement exists because a specific 800-53 control requires technology-specific implementation guidance for the SRG's domain. SRG-OS-000004 (the operating system must provide automated mechanisms for supporting account management functions) derives from AC-2 (Account Management). SRG-APP-000251 (the application must validate all input) derives from SI-10 (Information Input Validation). SRG-NET-000019 (the network device must enforce approved authorizations for controlling the flow of information) derives from SC-7 (Boundary Protection). SRG-DB-000004 (the database must enforce approved authorizations for logical access to information and system resources) derives from AC-3 (Access Enforcement). These mappings are bidirectional: from SRG requirement to 800-53 control, and from 800-53 control to all SRG requirements that implement it. An organization working through SRG requirements is simultaneously advancing its base 800-53 assessment.

Cross-walk examples illustrate how SRG work compounds across the base framework. Consider NIST 800-53 control AC-2 (Account Management). The GP OS SRG implements AC-2 through SRG-OS-000004 (automated account management), SRG-OS-000118 (disable accounts after defined inactivity), and SRG-OS-000123 (automatically remove temporary accounts after expiration). The Database SRG implements AC-2 through SRG-DB-000004 (database account management) and SRG-DB-000005 (enforce database account review). The Application Security SRG implements AC-2 through SRG-APP-000025 (application account management automation). When an organization satisfies all three SRGs' AC-2-related requirements, the base 800-53 AC-2 control has deep, technology-specific evidence across operating systems, databases, and applications. The assessor reviewing AC-2 does not see a single narrative claiming "we manage accounts." They see verified evidence of account management enforcement at every technology layer within the authorization boundary. This depth of evidence transforms control satisfaction from a binary claim into a demonstrable, multi-layered defense.

Rampart maintains the cross-walk engine that resolves these SRG-to-800-53 relationships in both directions. When you view your base NIST 800-53 assessment, each control displays which SRG requirements contribute to its satisfaction and what evidence supports each. When you view an SRG overlay assessment, each requirement displays the base 800-53 control it derives from and the current satisfaction status of that control across all active overlays. This bidirectional visibility means work is never duplicated and gaps are never hidden. Satisfying a GP OS SRG requirement for audit logging simultaneously advances the AU-12 control in your base 800-53 assessment, which advances your FedRAMP posture if FedRAMP is active, which advances your CMMC posture if CMMC is active. The derivation chain compounds through every framework that traces back to NIST 800-53. Artificer identifies which SRG requirements deliver the greatest cross-framework impact: requirements that, when satisfied, advance the most controls across the most active frameworks. This prioritization ensures that remediation effort produces maximum posture improvement across the organization's entire compliance portfolio, not just the SRG overlay currently under review.