Banner Image

Understanding FIPS 140-2 Crypto Requirements for Meeting FedRAMP and CMMC Compliance Standards

Federal Information Processing Standard (FIPS) FIPS 140-2 validated encryption is a prerequisite for FedRAMP and CMMC compliance and is governed by the FIPS 140-2 Publication, a U.S. government computer security standard used to approve cryptographic module. This publication provides a standard that is used by Federal organizations when these organizations specify that cryptographic-based security systems are to be used to provide adequate security and protection in its information system for sensitive or valuable data. FIPS 140-2 establishes the Cryptographic Module Validation Program (CMVP) as a joint effort by NIST and the Communications Security Establishment (CSE) for the Government of Canada. Modules validated as conforming to FIPS 140-2 are accepted by the Federal Agencies of both, the U.S. and Canada for the protection of sensitive information.

FedRAMP and CMMC Guidance on FIPS 140-2 Crypto Requirements

The FIPS 140-2 standard specifies the security requirements that will be satisfied by a cryptographic module. The standard provides four increasing qualitative levels of security intended to cover a wide range of potential applications and environments. A particular level requires that the previous levels also be met, but not every product must reach FIPS Level 4. For example, Level 1 provides the most basic security with practically no physical requirements, such as a personal computer encryption board, which is a validated Security 1 cryptographic module. In order for a PC to be Security Level 2 validated, it would need to comply with all the standards outlined in Level 1, and additionally meet role-based authentication requirements to account for tamper-evidence required in FIPS Level 2. Certain levels are only appropriate for certain products or solutions.

As mentioned in the guideline for using crypto standards by NIST, cryptography is a branch of mathematics that is based on the transformation of data and can be used to provide several security services such as:

  • Confidentiality: A confidentiality service can be provided by a cryptographic process called encryption
  • Data integrity authentication (also known as integrity verification): It is a service used to determine that the data has not been altered in an unauthorized manner since its creation
  • Identity authentication: It is used to provide assurance of the identity of an entity interacting with a system
  • Source authentication: It is used to provide assurance of the source of information to a receiving entity

Why is Encryption Necessary?

The increasing move towards zero-trust architectures and emphasis on securing data both internal to the environment and external facing is driving intense scrutiny of encryption compliance. For example, storage devices such as attached volumes and persistent storage services, data being exchanged between two end-points as well as archival backups etc. are great scenarios that must support encryption using FIPS 140-2 validated modules. When unprotected data leaves the owner’s control and is compromised, it has a huge impact on the company revenue, market share, and customer confidence. Additionally, there might be penalties relating to violation of data privacy regulations. In order to avoid such problems, in the U.S., the FedRAMP requires all commercial cloud service providers to use FIPS 140-2 Level 2 ValidatedTM products to secure data designated as Sensitive but Unclassified within computer and telecommunications systems (including voice systems).

What Should be Encrypted- Data at Rest: Data at rest is data stored on a hard drive. It is relatively secure in this state with protection from conventional perimeter-based defenses such as firewalls and anti-virus programs.  However, these barriers are not impenetrable. Organizations need additional layers of defense to protect sensitive data in an event the network is compromised. Encrypting hard drives is one of the best ways to ensure the security of data at rest. Here are some examples of what should be encrypted:

Transmitted Information SC-8(1)(2)(3)

  • Information System Backup (CP- 9)
    •   EBS/RDS/AMI snapshots
    •    S3 Buckets
  • Information at Rest – Data Partitions/Storage “Devices”  SC-28(1)
    •     EBS volumes
    •     S3 Buckets
    •     Log files

Cryptographic Key Establishment & Management SC-12(2)(3)

  •        Hardware Encryption Modules

Cryptographic Module Authentication (IA-7)

  •       Cryptographic module within the information system must implement authentication mechanisms (i.e., role-based or identity-based) to control access to the cryptographic module

What Should be Encrypted- Data in Transit: Data in transit is most vulnerable and to be able to secure information in this state requires specialized capabilities. For example, when you send an email, it is critical that your attachments and messages remain secure. The best way to ensure this is through an encryption platform that integrates with your existing systems and workflows. The most commonly used method for encrypting data in transit is through the use of Transport Layer Security (TLS). TLS is a cryptographic protocol designed to provide secure communication across a computer network. The latest version of TLS is 1.2 and should ideally be used for ensuring compliance with FIPS 140-2 requirements.

Transmitted Information SC-8(1)

  • When traversing the authorization boundary
    • Remote Access (VPN)
    • From client to Application
  • Within the authorization boundary
    • Web application to database

What Should be Encrypted- Operating Systems: To comply with FIPS 140-2, your system must be configured to run in a FIPS-approved mode of operation, which involves ensuring that a cryptographic module uses only FIPS-approved algorithms. Enabling FIPS 140-2 on the operating systems forces the OS to only use FIPS-validated encryption schemes and enforces OS applications/services and communications to do so as well.

About Us

Are you looking to sell cloud solutions to US Federal clients? Schedule a free consultation with our experienced FedRAMP, FISMA, and CMMC compliance experts. Our stackArmor ThreatAlert®- ATO on AWS solution, helps customers avoid costly FedRAMP compliance mistakes in the area of FIPS 199 categorization, FIPS 140-2 compliance, MFA requirements, and boundary definition amongst others. Our end to end solution accelerates compliance by delivering a FedRAMP/NIST compliant security system with over 17 security requirements delivered ‘’in-boundary’’ reducing risk and complexity. We are able to reduce the time and cost of a FedRAMP, FISMA, or DFARS Authorization by 40% through automation, standardization, and pre-filled documentation. Have questions? Click here to contact us and we’d be happy to assist.

Contact Us Please write to us at solutions at stackarmor dot com