Meet Federal Requirements for Government and High-Assurance Work

If you're selling to government agencies or handling sensitive federal information, FIPS 140-3 isn't optional—it's a mandatory requirement. DISA STIG requirements are equally non-negotiable for defense and government contractors. Cryptographic algorithms must be approved through official validation processes. This learning path teaches you how to navigate federal compliance: what regulations apply to your specific organization, how to implement FIPS-compliant cryptography correctly, achieve DISA STIG compliance across your container infrastructure, and generate the audit evidence that government customers require before awarding contracts. By the end of this path, you'll know how to bid on federal contracts and maintain compliance through ongoing security audits.

Duration: 4-6 weeks (20-30 hours) Skill Level: Intermediate to Advanced Prerequisites: Container security fundamentals, Kubernetes knowledge

graph TB    Requirement["Federal<br/>Requirement"]    Requirement --> FIPS["FIPS 140-3<br/>Cryptographic<br/>Compliance"]    Requirement --> STIG["DISA STIG<br/>Security<br/>Controls"]    Requirement --> NIST["NIST 800-190<br/>Container<br/>Guidance"]    FIPS --> Build["Build<br/>FIPS-compliant<br/>containers"]    STIG --> Harden["Harden<br/>Per STIG<br/>requirements"]    NIST --> Implement["Implement<br/>Best practices"]    Build --> Audit["Audit &<br/>Verify"]    Harden --> Audit    Implement --> Audit    Audit --> Evidence["Generate<br/>Compliance<br/>Evidence"]    style Evidence fill:#c8e6c9

Learning Outcomes

After completing this path, you will understand FIPS 140-3 requirements and how to implement FIPS-compliant cryptographic practices within your container infrastructure. You'll achieve DISA STIG compliance across your containerized deployments by understanding control requirements and mapping them to implementation. You'll meet federal SBOM and provenance requirements established through Executive Order 14028. You'll implement NIST 800-190 container security guidance as the authoritative federal standard for secure container practices. You'll establish federal compliance monitoring through automated verification and real-time policy enforcement. You'll learn to generate compliance audit reports that demonstrate adherence to government frameworks. Finally, you'll understand how to maintain compliance over time through continuous monitoring and scheduled re-assessments.

Module 1: Federal Compliance Landscape (Week 1)

Concepts

Federal regulations form the foundation of compliance requirements. Executive Order 14028 establishes the cybersecurity mandate requiring federal agencies to implement specific security controls. OMB Circular A-130 dictates cryptographic requirements for all information systems handling federal data. The Federal Information Security Management Act (FISMA) requires federal agencies to classify information and apply appropriate security controls. Federal procurement regulations establish that vendors must meet baseline security requirements to bid on government contracts.

Standards and frameworks provide the implementation guidance. FIPS (Federal Information Processing Standards) define specific cryptographic and security requirements. The NIST Cybersecurity Framework provides a structured approach to managing cybersecurity risk. DISA STIGs (Security Technical Implementation Guides) provide detailed implementation guidance specific to technologies like Docker and Kubernetes. CIS Benchmarks have achieved government adoption and are referenced in many federal contracts.

Compliance requirements are multifaceted. SBOM mandates for federal software mean every piece of software delivered to government must include a detailed component inventory. Provenance requirements demand cryptographic proof of how and where software was built. Cryptographic algorithm approval is non-negotiable—only algorithms approved by CMVP (Cryptographic Module Validation Program) can be used. Audit and logging requirements dictate that all security-relevant events must be recorded and retained for specified periods.

Hands-On Labs

The first assessment lab determines which regulations apply to your specific organization through a structured set of questions. Does your organization handle federal data? If yes, FISMA compliance is mandatory. Do you sell software to the government? If yes, FIPS-140 is likely required. Are you a defense contractor? If yes, DISA STIG becomes a strict requirement. Do you store healthcare, financial, or other sensitive data? If yes, additional regulations beyond those already identified also apply. This assessment exercise results in a compliance requirements matrix that becomes the foundation for all subsequent work in this learning path.

The second lab focuses on understanding FISMA requirements through the lens of container security. FISMA requires federal agencies to classify all information into categories (Public, Sensitive, Confidential). These classifications then map to specific security controls that must be applied. FISMA requires that audit logs capture all authentication events, all data access, and system modifications. Logs must be protected from tampering through cryptographic means or physical isolation. FISMA mandates that only government-approved cryptographic algorithms and validated cryptographic modules are used. All security measures must be documented in formal security plans that are reviewed annually.

Module 2: FIPS 140-3 Cryptographic Requirements (Weeks 1-2)

Concepts

FIPS 140-3 is the current standard (released 2019) establishing cryptographic requirements that supersede the previous FIPS 140-2 standard. The CMVP (Cryptographic Module Validation Program) is the government process that validates cryptographic modules against FIPS 140-3 requirements before they can be used in federal systems. Only algorithms that have passed CMVP validation and are listed on the approved cryptographic algorithms list can be used in FIPS-compliant implementations.

Approved cryptographic practices are well-defined. For encryption, AES (Advanced Encryption Standard) in 128, 192, or 256-bit variants is the approved symmetric encryption algorithm. For hashing, SHA-256, SHA-384, and SHA-512 are all approved. MD5 and SHA-1 are explicitly forbidden. For key exchange, ECDH and Diffie-Hellman with 2048+ bit keys are approved. For digital signatures, RSA with SHA-256/384/512 and ECDSA with SHA-256/384/512 are both approved. DSA signatures are not approved.

Implementation requires using FIPS-validated modules, configuring systems to operate in FIPS mode, and performing verification and testing to confirm compliance.

Hands-On Labs

The first lab creates a comprehensive audit of approved versus non-approved cryptographic algorithms used in your codebase. Python codebases are scanned for md5, sha1, DES, and RC4 usage. Node.js applications are scanned for deprecated algorithms. Java projects are checked for non-approved cipher suites. The results are documented with specific file locations, line numbers, and recommended replacements. For example, if md5 is found in an authentication function, the lab documents that hashlib.sha256() is the correct replacement.

The second lab enables FIPS mode on the systems where containers will run. On RHEL/CentOS systems, the fips-mode-setup command enables FIPS mode at the kernel level. OpenSSL version output will show "FIPS" if the configuration succeeded. The openssl engine -t command verifies that the FIPS engine is available. For container deployments, FIPS base images from Red Hat or other vendors provide pre-configured FIPS-capable environments.

The third lab verifies CMVP validation for cryptographic modules in use. The CMVP module list maintained by NIST is searched for modules relevant to your deployment. For OpenSSL, we verify the specific version certificate number (e.g., OpenSSL 3.0.1 has certificate #4282). For Java Cryptographic Extensions, we record the certificate number and validation date. This documentation becomes evidence for auditors.

Module 3: DISA STIG Compliance for Containers (Weeks 2-3)

Concepts

DISA STIG (Security Technical Implementation Guide) is the DoD standard for hardening specific technologies. The container-specific STIG defines approximately 200+ controls covering authentication, encryption, audit logging, and vulnerability management. STIG requirements are mandatory for any contractor working with DoD information.

STIG controls address multiple domains. Access control requirements mandate that containers enforce authentication and that access to container settings is restricted. Encryption requirements mandate data encryption both in transit and at rest. Audit and logging requirements mandate that all access events are logged. Vulnerability management requirements mandate regular scanning and patching.

Compliance mapping translates STIG requirements into concrete container configurations. STIG requirements about authentication map to specific CIS Docker Benchmark controls. STIG encryption requirements map to TLS configuration and signed image requirements. Logging requirements map to Docker logging drivers and centralized log aggregation.

Hands-On Labs

The first lab creates a detailed mapping document comparing DISA STIG requirements to CIS Docker Benchmark controls. For each STIG requirement about authentication, the lab documents the corresponding CIS control and how to implement it. The mapping shows that "containers must enforce authentication" is satisfied by "set default user to non-root" through the USER Dockerfile instruction. "Access to container settings restricted" maps to "do not run privileged containers" implemented through --privileged flag omission.

The second lab involves deploying Kubernetes resources that meet DoD STIG requirements. The deployment manifests include specific security contexts, resource limits, service account configurations, and network policies. A complete example shows how to structure a pod that will pass STIG compliance checks, including non-root users, read-only filesystems, dropped capabilities, and resource limits.

The third lab runs automated STIG compliance checks using OpenSCAP. The oscap container image scan command evaluates container images against DISA STIG profiles. The results are generated in an HTML report format suitable for submission to government auditors. Non-compliant findings are documented with specific remediation steps.

Module 4: NIST 800-190 Container Security (Weeks 3-4)

Concepts

NIST 800-190 is the definitive federal guidance for securing containerized applications. The document defines four domains: image assurance and security (scanning, signing, provenance), deployment security (access control, network isolation, secrets management), security monitoring and enforcement (runtime detection, policy enforcement, audit logging), and compliance and supply chain (SBOMs, provenance, license compliance).

Each domain maps to specific control implementations. Image assurance requires vulnerability scanning, signature verification, and SBOM generation. Deployment security requires non-root users, read-only filesystems, network policies, and secrets encryption. Security monitoring requires audit logging, runtime detection, and policy enforcement. Compliance requires SBOMs, SLSA provenance, and license inventories.

Hands-On Labs

The first lab maps NIST 800-190 controls to CleanStart features. For each control, the lab documents which CleanStart capability addresses it and how to verify compliance.

The second lab creates a complete NIST 800-190 compliance checklist for a containerized application. The checklist verifies that all four domains are addressed: image assurance (signing, scanning, SBOM), deployment security (non-root, read-only, network policies), monitoring (audit, runtime detection), and compliance (SBOM, provenance).

The third lab prepares for government audits by collecting evidence of compliance. This includes screenshots of policy enforcement, audit logs showing monitoring, test reports showing scanning results, and attestations proving image signing and verification.

Module 5: Compliance Monitoring and Auditing (Weeks 4-5)

Concepts

Compliance doesn't end at implementation—it must be continuously verified. Continuous monitoring detects policy violations, drift, and emerging risks. Audit trails document all compliance decisions and their justifications. Automated reporting generates evidence for government auditors. Scheduled reassessment confirms continued compliance.

Hands-On Labs

The first lab sets up continuous compliance monitoring using policy enforcement and runtime detection. Policy violations trigger alerts. Compliance reports are automatically generated on schedules.

The second lab creates compliance audit reports suitable for government review. The reports document control implementation, evidence of compliance, and remediation of any violations.

The third lab establishes scheduled compliance reassessment (quarterly) to confirm continued adherence to federal standards.

Module 6: Building for Federal Contracts (Week 5-6)

Concepts

Federal procurements require specific contractual language, compliance documentation, and ongoing compliance commitment. Bids on federal contracts must demonstrate compliance with applicable standards. Service Level Agreements must include compliance maintenance requirements.

Hands-On Labs

The first lab creates compliance documentation suitable for federal contracting. This includes compliance matrices, control implementations, monitoring procedures, and remediation processes.

The second lab prepares for government security assessments by organizing evidence of compliance in formats government auditors expect.

Final Project: Federal Compliance Infrastructure

Design and implement a complete container infrastructure that meets federal compliance requirements. The infrastructure should include FIPS 140-3 cryptographic modules, DISA STIG-compliant container configurations, NIST 800-190 security controls, continuous compliance monitoring, and automated compliance reporting.

Your project documentation should explain how each federal requirement is addressed and include evidence suitable for government auditor review.

What to Read Next

FIPS 140-3 Overview. DISA Container Security Technical Implementation Guide. NIST 800-190: Application Container Security. Executive Order 14028 on Cybersecurity.