DOCSEARCHbyAlgolia
Submit Docs

Automata Secure Documentation

website·Indexed 30 days ago

https://docs.automatasecure.com

Documentation and whitepapers for the Automata FIPS (AFIPS) Model, providing a layered framework to plan, implement, and assess FIPS 140 validated cryptography. Covers FIPS 140-3 validation requirements, the transition from FIPS 140-2, and detailed objectives for cryptographic policy, key storage, and data protection in transit and at rest.

Tokens
8.2K
Snippets
3
Records
57
Agent score
50%

What's inside Automata Secure

  1. Overview of the Automata FIPS (AFIPS) Model

    The Automata FIPS (AFIPS) Model is a conceptual framework that maps Federal Information Processing Standards (FIPS) 140 validated cryptography to real-world systems. It provides a repeatable structure for architects and practitioners to align modern delivery practices with FIPS 140 requirements, focusing on how cryptography is selected, enforced, and evidenced across the stack.

  2. Overview of the Automata FIPS (AFIPS) Layers

    The AFIPS Model organizes cryptographic responsibilities into eight distinct layers (L0-L7). This layering ensures that approved cryptographic operations are centralized in validated providers while other layers handle policy, orchestration, and management.
    AFIPS LayerLayer NamePurposeFIPS Focus
    7Key and Trust ManagementKey lifecycle, trust anchors, attestation, certificatesApproved key establishment/wrapping, separation of duties
    6Network and API SecurityTLS, mTLS, IPsec, SSH, API gatewaysEnforce approved cipher suites and certificate validation
    5Data Protection ServicesEncryption at rest, tokenization, hashing, anonymizationEnvelope encryption using approved algorithms with L7 keys
    4Applications and MiddlewareBusiness logic, frameworks, service meshes, brokersUse system or bundled validated providers; avoid non-approved modes
    3Execution EnvironmentContainers, VMs, serverless runtimesRuntimes resolve to validated providers and inherit OS FIPS policy
    2Validated Crypto ProvidersSoftware or hardware modules implementing algorithmsOnly CMVP validated modules in approved mode are selected at load time
    1Platform OS and PolicyOperating system and baseline crypto policyOS configured for FIPS mode; system APIs use validated modules
    0Hardware Crypto BoundaryPhysical roots (HSMs, TPMs, true RNGs)Device is validated; tamper resistance and self-tests operate inside boundary

  3. Overview of AutomataSECURE platform capabilities

    AutomataSECURE is a platform designed to unify vulnerabilities and simplify compliance for security engineers, compliance teams, and system owners. Key capabilities include:

    • Automated POA&M updates that map vulnerabilities to plan entries.
    • Continuous compliance monitoring with status tracking.
    • A unified view of assets, findings, and control evidence.
    • Security architecture tailored for federal needs, featuring validated cryptography and strict access controls.

  4. Understand the relationship between FIPS 140-3 modules, primitives, and algorithms

    FIPS compliance involves three distinct but related concepts: the Cryptographic Module Validation Program (CMVP), which validates the overall cryptographic module (FIPS 140-3), and the Cryptographic Algorithm Validation Program (CAVP), which validates the specific cryptographic algorithms and primitives used within those modules. Common examples of validated algorithms include AES, RSA, and SHA-256.

  5. Establish platform-wide cryptographic policy for AFIPS Layer 1

    The objective of AFIPS Layer 1 is to establish a platform-wide cryptographic policy that constrains algorithms and determines which modules are available to applications and runtimes. This involves enabling FIPS mode, restricting algorithms to approved sets, ensuring system libraries select validated modules, and configuring kernel/user space consumers (TLS, IPsec, SSH) to enforce this policy.

  6. Understand FIPS-validated cryptography requirements for federal compliance

    For U.S. federal agencies and cloud service providers, using strong cryptographic algorithms (like AES or SHA-256) is insufficient on its own. To protect sensitive data, encryption must be performed by cryptographic modules that have been formally tested and validated under NIST's Cryptographic Module Validation Program (CMVP). Non-validated cryptography is often treated as providing 'no protection' in federal audits.

  7. Understand FIPS-Validated Cryptography requirements

    FIPS-validated cryptography requires that cryptographic operations be performed by a module (software, hardware, or firmware) that has undergone independent lab testing and government validation via the CMVP.

    Crucially, simply using FIPS-approved algorithms (e.g., AES, RSA, SHA) is not sufficient for validation. The specific implementation of those algorithms must be validated. A module is only considered FIPS-validated if it:

    1. Appears on the NIST validated modules list.
    2. Is operated in an 'Approved Mode' as defined by its Security Policy.

    Terms like 'FIPS-compliant' or 'FIPS-capable' do not guarantee that a module has received a CMVP certificate and therefore do not satisfy federal requirements (such as FedRAMP).

  8. Implement data protection using AFIPS Layer 5 (L5) standards

    AFIPS Layer 5 (L5) is responsible for protecting data at rest and in use. It provides encryption, decryption, and integrity services for data stores and filesystems, as well as tokenization, hashing, and anonymization. L5 must integrate with Layer 7 (L7) for key generation, rotation, and access control.

  9. Use the Cryptographic Module Security Policy for FIPS compliance

    The Security Policy is the authoritative document for a FIPS-validated module. It defines the module boundary, roles, services, and self-tests. To ensure a system is FIPS-validated, developers must use the Security Policy to:

    1. Configure the module to run in 'FIPS-approved mode' (e.g., calling a specific initialization function like FIPS_mode() in OpenSSL or loading a FIPS provider).
    2. Identify which cryptographic algorithms are 'FIPS-approved' (e.g., SHA-256, AES, RSA) and which are 'non-approved' (e.g., MD5).
    3. Verify if any non-approved algorithms are permitted under specific circumstances (e.g., SHA-1 may be allowed for hashing but not for digital signatures).
    4. Map the module to its specific certificate number and version.

  10. Compliance frameworks supported by AutomataSECURE

    The platform and its guidance align with several widely adopted standards and assessment regimes. Note that framework coverage depends on deployment choices and authorizing official (AO) requirements.

    Supported frameworks include:

    • FedRAMP: LI‑SaaS, Moderate, High
    • DoD Cloud Computing SRG: IL4, IL5, IL6
    • StateRAMP and GovRAMP
    • FISMA and NIST RMF
    • NIST SP 800‑53
    • NIST SP 800‑171 and 800‑172
    • CMMC

  11. Implement AFIPS Layer 7 Key and Trust Lifecycle Management

    AFIPS Layer 7 governs the lifecycle for keys and trust, encompassing generation, rotation, distribution, attestation, archival, and destruction. To implement this layer, ensure the following requirements are met:

    Core Responsibilities:

    • Manage root and intermediate CAs and trust stores.
    • Generate keys inside validated boundaries and approved modes.
    • Provide attestation signals regarding platform and module state to relying systems.

    Implementation Guidance:

    • Hardware Generation: Generate keys in hardware when required. Use approved key establishment methods for distribution or wrapping.
    • Separation of Duties: Separate operator and auditor roles. Enforce approvals for sensitive operations.
    • Provenance: Record provenance for keys and certificates and export signals to security monitoring.

    Common Components to Use:

    • Key management services (KMS) and HSM-backed CAs.
    • Certificate lifecycle management and automated issuance tools.
    • Attestation frameworks and policy engines.

  12. Distinguish between CAVP and CMVP validation

    NIST uses two distinct programs to validate cryptography. CAVP validation is a prerequisite for CMVP validation.

    CAVP (Cryptographic Algorithm Validation Program):

    • Focus: Validates the correctness of specific cryptographic algorithm implementations.
    • Scope: Individual algorithms, modes, and key sizes.
    • Outcome: Algorithm certificates.
    • Limitation: Does not evaluate module design, key management, entropy, or physical controls.

    CMVP (Cryptographic Module Validation Program):

    • Focus: Validates the entire cryptographic module (the 'container' of the algorithms).
    • Scope: The complete module, including its design, operational environment, and security policy.
    • Outcome: Module certificates and a published Security Policy.
    • Verification: The definitive reference for auditors to confirm a product's FIPS validation status.