FIPS again, and FedRAMP

[Duane_Toler]

I've searched SK and the community and seen lots of bits on FIPS support for the gateways.  Looks like the available information is a bit thin on details, even in the admin guides I pulled.  I saw some URLs for the NIST reference sites and I see R81.20 has FIPS 140-2 certification.  However, the list also specifies a specific appliance model.   Does this mean that hardware platform (9300 in this case) is the only appliance certified for FIPS?

https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4264

https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/modules-in...

Can someone make an SK article to cover all this in one place? That'd be fantastic!  Similarly, can this include FedRAMP support, too?  I see the R82.20 EA release notes mention FedRAMP; is that the only version?

Thanks!

[Chris_Atkinson]

@Malcolm_Levy recently posted about FIPS 140-3

https://community.checkpoint.com/t5/Firewall-and-Security-Management/FIPS-140-3/td-p/279085 

[Malcolm_Levy]

I updated the referenced post.

We are listed under the Modules In Process for 140-3 and we tested on all current modules Smart-1, Quantum GWs, MHO. The list is given under the separate Entropy certification certificate E309

[Duane_Toler]

Thanks! I saw that post as well.  Does this mean that ONLY those appliance hardware models qualify? Or is the specified software version enough, regardless of the underlying hardware (or VM/cloud) platform?

[Malcolm_Levy]

In 140-2 a vendor affirmation was allowed under Implementation Guidance G.5. In our case our appliances are GPC. Implementation Guidance for FIPS 140-2

FIPS 140-3 Management Manual similarly says the following that allows a vendor affirmation to porting to another appliance: FIPS-140-3-CMVP Management Manual.pdf

7.9.1 Vendor 2554
1. A vendor may perform post-validation recompilations of a software, firmware, or hybrid 2555
module and affirm the modules continued validation compliance. By adding vendor support 2556
of non-tested configurations to the validated module security policy, the vendor bears all 2557
responsibility. These non-tested configurations versions may be considered by the user at 2558
their risk, provided the following is maintained: 2559
a) Software modules do not require any source code modifications (e.g., changes, additions, 2560
or deletions of code) to be recompiled and ported to another OE and must: 2561
i) For Level 1 OE, a software cryptographic module can be considered compliant with 2562
the FIPS 140-3 validation when operating on any general-purpose platform/processor 2563
that supports the specified operating system as listed on the validation entry or 2564
another compatible4 operating system, or 2565
ii) For Level 2 OE, a software cryptographic module can be considered compliant with 2566
the FIPS 140-3 validation when operating on any general-purpose platform/processor 2567
that supports the same level 2 operational environment settings specified on the 2568
validation entry. 2569
b) Firmware modules do not require any source code modifications (e.g., changes, additions, 2570
or deletions of code) to be recompiled, and its identified unchanged tested operating 2571
system (i.e., same version or revision number) may be ported together from one platform 2572
to another platform while maintaining the module’s validation. 2573
Level 2 and above Firmware modules cannot be ported and maintain their validation, 2574
since Physical Security must be retested.

AI Overview

Section 7.9 of the FIPS Cryptographic Module Validation Program (CMVP) Management Manual covers Vendor or User Affirmation of Modules. This section details the conditions under which a vendor or system user can formally affirm that a validated software or firmware cryptographic module will operate correctly and maintain compliance when ported or used in an operational environment (OE) similar to, but not explicitly tested during, the original lab validation. [1, 2]

[Duane_Toler]

Nice! Thanks for the updates!  I also noticed your name was attached to the NIST document section, too. 🙂 

[Malcolm_Levy]

For possible future reference, this is NIST advice for usage of modules with updates when a CVE is remediated.

Note the strong recommendation to apply patches before the update is certified. 

https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow

Cryptographic Module Validation Program CMV

FIPS Validation and Updates, Patches, and CVEs

We often get the question whether patching/updating a FIPS validation module (particularly when there is a significant security-related reason such as addressing a CVE) will invalidate that module’s FIPS status. The original version would maintain its validation but the new version that includes the patch/update would not be validated. Changing the code of the module results in that portion being untested and the CMVP is only able to make validation assurances for the tested configuration. As noted in our guidance: 

The tested/validated module version, operational environment upon which it was tested, and the originating vendor are stated on the validation certificate. The certificate serves as the benchmark for the module-compliant configuration. (FIPS 140-2 IG G.5, FIPS 140-3 Management Manual 7.9)

However, we strongly recommend patching to safeguard the security of systems and data, noting that organizations must use their own Vulnerability, Patch and Risk Management programs, policies and procedures to make those decisions within the context of their organization. Simply, this is not a decision the CMVP has either the information necessary or the authority to make.

To reestablish those assurances as quickly as possible and minimize the risk, we also strongly recommend that vendors quickly have a CMVP certified lab test and submit an update for their module that reflects the patching/updating. The CMVP has an expedited processes in place to handle these updates when they are in response to a published CVE or a security relevant maintenance/bug fix (see FIPS 140-2 IG G.8 Scenario 3A, and FIPS 140-3 Management Manual 7.1.11 CVE).

To summarize, the CMVP would agree that quickly addressing a known risk and then following up with an expedited validation of the updated module is generally the best and recommended way to minimize the overall security risk for government agencies.

[Malcolm_Levy]

> Thanks! I saw that post as well.  Does this mean that ONLY those appliance hardware models qualify? Or is the specified software version enough, regardless of the underlying hardware (or VM/cloud) platform?

I answered regarding other appliances in the earlier post for vendor affirmation. 

Regarding the software version:

The FIPS 140-3 certification relates to the OS defined as Gaia R82.10 or Gaia R82.20 (both have the same kernel).

The FIPS Security Policy shows the cryptographic boundary. For 140-3 this is defined in this table. 

Package/File Names	Software/ Firmware Version	Non-Security Relevant Distinguishing Features	Integrity Test Implemented
fips.so	arm-v1.0.0	Fips Provider for ARM appliances, 64-bit variant	HMAC SHA256
libjitterentropy.so	arm-v1.0.0	Entropy Source for ARM appliances, 64-bit variant	HMAC SHA256
fips.so	arm-32bit-v1.0.0	Fips Provider for ARM appliances, 32-bit variant	HMAC SHA256
libjitterentropy.so	arm-32bit-v1.0.0	Entropy Source for ARM appliances, 32-bit variant	HMAC SHA256
fips.so	x86-v1.0.0	Fips Provider for X86 appliances, 64-bit variant	HMAC SHA256
libjitterentropy.so	x86-v1.0.0	Entropy Source for X86 appliances, 64-bit variant	HMAC SHA256
fips.so	x86-32bit-v1.0.0	Fips Provider for X86 appliances, 32-bit variant	HMAC SHA256
libjitterentropy.so	x86-32bit-v1.0.0	Entropy Source for X86 appliances, 32-bit variant	HMAC SHA256