Welcome to the Acumen Security Blog

Happy New Year!

Another year gone by, and what a year it was on so many fronts! This was the year that challenged us to scale effectively and am heartened to see how the team responded. We went from a handful of customers in 2015 to a full book in 2016. Scaling to a greater customer diversity while maintaining or exceeding level of service is always tough, but Team Acumen was up to the challenge. This was evidenced by the all round positive feedback we have received from our customers and quantified by the high marks received in the FIPS survey. Along the way we had some key team additions as well as diversification into other services such as support for FedRAMP audits.

April 2017 Acumen will be three years old and I guess that is when we stop being a startup? If 2016 was exciting, 2017 is going to be down right amazing. Few items already lined up are move to a new larger office space, revamping our website, a project management and customer interaction portal, validating the next version of openSSL and lot more! What will remain unchanged will be our ethos to keep simplifying certification and driving value for the investment our customers make in certifying their products.

Happy New Year! Welcome 2017!

New Guidance from the CMVP on Operational Environment (OE) requirements

Here at Acumen we want to keep our clients plugged-in as product certification requirements change or evolve. From time to time FIPS 140-2 testing labs receive updates or new guidance from the Cryptographic Module Validation Program (CMVP). The following guidance was sent from CMVP last week pertaining to the level of detail required for cryptographic module operational environments for CAVP algorithm validation certificates and FIPS 140-2 module validation certificates (under the CMVP). The CMVP emphasized that the information in the OE field must be accurate and adhere to CAVP FAQ GEN.12. Specifically:

1. The information listed in the OE field is a valid operating system (or operating system family) and/or processor (or processor family). Note: There have been cases where the information supplied for the OE was a platform and not a valid operating system and/or processor. Simply listing the platform is not allowed for CAVS validations.

2. The information listed in this field is the operating system (or operating system family) and/or processor (or processor family) on which the CAVP algorithm validation testing was performed and on which the response results were produced.

GEN.12 in the CAVP FAQ (http://csrc.nist.gov/groups/STM/cavp/documents/CAVPFAQ.pdf) defines Operating System Family and Process Family as follows:

“For Software implementations, the following information must be listed:

1. Processor – This field shall identify the vendor and processor family. Examples that satisfy the requirement for the processor field are Intel Core i5, ARM 7, and AMD Opteron.

No further specificity is required unless the vendor or the lab knows that the software implementation executes differently on different processors within the same family. In this case, the listing must be more specific. AES.2 describes such a case. A vendor may also choose to be more specific than
required, e.g., in order to gain a marketing benefit.

2. Operating system – This field shall identify the vendor and operating system family, or major version number where more appropriate. Examples that
satisfy the requirement for the OS field are Microsoft Windows Vista, Apple Mac OS X, Red Hat Enterprise Linux 5, and Wind River VxWorks 6.
No further specificity is required unless the vendor or lab knows that the software implementation executes differently on different OSes within the
same OS family or major version number. In this case, the listing must be more specific. A vendor may also choose to be more specific than required if
so desired. Any virtual machine (VM) used during testing shall be listed in the OS field of the Operating Environment (OE). If the VM was running between the software implementation and the OS, as in the case of a Java VM, it should be listed along with the OS using the same vendor and family/version number requirements. See GEN.17 for the case of a VM running underneath the target OS.

From a CAVP algorithm validation perspective, the OE field can either list the actual operating system and/or processor or it can list the operating system family and/or processor family, or some combination thereof.

On a FIPS 140-2 validation certificate (under the CMVP), the OE must consist of the actual operating system and platform (with processor if applicable).

– If the CAVP validation lists the actual OEs operating system and/or processor, then the CMVP OEs operating system must match and/or processor must match.

– If the CAVP validation lists an operating system family, then the actual operating system listed on theFIPS 140-2 certificate must be a member of the operating system family. Likewise, if the CAVP validation lists a processor family, then the processor of the actual platform listed on the FIPS 140-2 certificate must be a member of that processor family. The OE components in both the CAVP validation and the CMVP certificate must be in sync.

If the CAVP algorithm validation indicates an OE consisting of a processor family and/or an operating system family and the CMVP module validation indicates a processor and/or an operating system that is a member of the corresponding families, the lab must provide an explanation/rationale of how the CMVP OE satisfies CAVP FAQ GEN.10 and GEN.12, and CMVP IG 1.4. (For example, the CAVP validation might list Intel Xeon and then the CMVP test report might list Intel Xeon E5-4603 v2 and Intel Xeon E7-8893 v4. The lab would provide an explanation/rationale to address the difference.)

FIPS 140-2 IG G.13 (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf) states the following:

the specific operational environment(s) or configuration(s) that was employed during testing by the CST laboratory shall be specified for all module types. (e.g. software, firmware, hardware and hybrid). This shall match the information in the test report in AS.01.08. The operational environment includes both the operating system(s) and the tested platform(s).

Therefore, if the tested platform itself may be procured with different processors, the processor on which the module was tested shall be listed on the CMVP certificate, security policy and test report.

Even with this recent clarification we understand if you might still have questions or concerns on how this applies to you. Please dont hesitate to contact us if we can be of assistance – we would be happy to walk through these requirements in the context of your cryptographic module or products.