FIPS 140 Archives | SafeLogic

All posts in FIPS 140

30 Nov 2017

Last Call for NIST 800-171

Classified data has always been treated with significant security precautions. Restricted access, Suite A encryption (yes, even the cryptographic algorithms themselves are classified), and a slew of other protections. Federal agencies are accustomed to safeguards on unclassified data as well, relying heavily on FIPS 140-2 validated encryption (which deploys Suite B algorithms, available to the public).
NIST 800-171

The establishment of NIST SP 800-171, first by executive order back in 2010, responded to the concept that this level of data protection should be expanded to include nonfederal systems, by nonfederal organizations, as long as it pertains to government business. This is Controlled Unclassified Information (CUI), and it applies to virtually all information that relates to, is the property of, or will become the property of U.S. federal. It was described to me as anything that relates to government but cannot be found on a public .gov domain. That struck me as a very logical way to determine what has been pre-approved as readily available public info. Be careful though. That would classify proposals and contracts under NIST 800-171, which puts the onus on every government contractor, from the huge conglomerates building warships right on down to the sole proprietor trying to win a bid to set mousetraps in a federal courthouse as a subcontractor. It’s got broad reach and big teeth, and the requirements are not to be taken lightly.

It’s also approaching very quickly. Yes, it was first on the radar in 2010, but December 31, 2017 will not just ring in the New Year. It is also the deadline for compliance with NIST 800-171. If you’re still scrambling for clarity, you should gather yourself, take a deep breath, and begin preparing your POA&M (Plan of Action and Milestones) instead. You have run out of time to effectively complete the compliance documentation process before the end of the calendar year, but writing the POA&M is achievable, with the execution of the plan viable for Q1 2018.

Why would I recommend pulling the plug on a final Hail Mary effort in the last month of the year? Well, other than the obvious toll it would take on your holiday plans, NIST 800-171 identifies 14 different families of security requirements. This is no walk in the park. Encryption is specified in four of those families: (1) Access Control, (5) Identification and Authentication, (8) Media Protection, and (13) System and Communications Protection. The final mention of cryptography in these 14 families is extremely blunt, in fact, about the level of encryption that is required.

3.13.11 – Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.

So everywhere in the previous mentions of cryptography is expected to be FIPS 140-2 validated. Not compliant, but actually validated and posted to NIST’s CMVP website. SafeLogic’s RapidCert process should carry some strong weight in your POA&M if you do indeed go that way. It would demonstrate a focus on timeline as well as meeting the strict benchmark head-on.

NIST 800-171 relies, as most of NIST’s newer special publications do, upon the security framework dictated by SP 800-53, which spells out more specifically the baseline measures that are expected of affected entities. Everybody loves a good mapping table, so here are the cryptographic-relevant entries for 800-171, as mapped to 800-53:

 

800-171

3.1.13 Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.

 

800-53

AC-17(2) Remote Access Protection of Confidentiality / Integrity Using Encryption

 

3.1.17 Protect wireless access using authentication and encryption. AC-18(1) Wireless Access Authentication and Encryption
 

3.1.19 Encrypt CUI on mobile devices.

 

AC-19(5) Access Control for Mobile Devices Full Device / Container Based Encryption

 

3.8.6 Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.

 

MP-5(4) Media Transport Cryptographic Protection

 

3.13.8 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. SC-8 Transmission Confidentiality and Integrity

 

SC-8(1) Transmission Confidentiality and Integrity Cryptographic or Alternate Physical Protection

 

3.13.10 Establish and manage cryptographic keys for cryptography employed in the information system. SC-12 Cryptographic Key Establishment and Management

 

3.13.11 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. SC-13 Cryptographic Protection

Even with a strong POA&M, time will be of the essence in 2018. FIPS 140-2 validation is a major effort if handled in-house, so consider offloading it to SafeLogic. We will complete the validation with zero man-hours required from your team and we will accelerate the timeline, guaranteeing completion during that vital first quarter of 2018. Let’s get that RapidCert started!

NIST 800-171

29 Aug 2017

Introducing CryptoComply for Libgcrypt

The last entry to our SafeLogic blog announced CryptoComply for NSS. A little more than a week later and that is already old news.

I have the honor of sharing two items:
First, SafeLogic scored a Gold medal win at the Golden Bridge Awards. Awesome job, team!
And second, the FIPS 140-2 validation is complete for CryptoComply for Libgcrypt and RapidCert is available immediately!

As Ray said last week, we have been hard at work expanding our product line to provide more compatibility options for our customers, based on the most common architectures that we encounter. Please check out the new product page and don’t hesitate to reach out if you have questions. We’ll be ready when you are.

 

CryptoComply for Libgcrypt blog footer

21 Aug 2017

Introducing CryptoComply for NSS

Last week, if you regularly read NIST’s list of Validated FIPS 140-2 Cryptographic Modules, you would have noticed a new addition. (If you don’t regularly read the list, I highly recommend it as a panacea for insomnia, but that’s a different story.)

I’m proud to announce that SafeLogic has completed the validation process for our CryptoComply for NSS module, the latest addition to our stable of encryption engines and now eligible for RapidCert.

This is a valuable piece to the puzzle as the SafeLogic team pursues universal compatibility options for our customers’ needs, and there is much more to come. Stay tuned as we unveil more cryptographic modules as they become available for licensing and RapidCert. If you have specific questions or requests, please contact us!

CryptoComply for NSS blog footer

18 Jul 2017

HBO’s Silicon Valley Foreshadows Possible Federal Storyline

Originally posted in its entirety at CIOstory.com.

HBO Silicon ValleyRecently, HBO’s hit series Silicon Valley made reference to the once-esoteric FIPS 140-2 validation process for encryption. In the show, the massive Hooli juggernaut is pulling out all the stops to stake claim to market share and elbow out Pied Piper, the brainchild of protagonist Richard Hendricks. Amidst the inside jokes from the Bay Area and the Easter eggs for techies and entrepreneurs, Silicon Valley does a fantastic job illustrating the dynamics between incumbent vendors and disruptive startups in real life. While it is certainly fictionalized (although who doesn’t recognize an Erlich Bachman in their life), HBO’s portrayal of the stark contrast in resources is on point. Pied Piper is a skeleton crew, while Hooli has budget and personnel to spare. So in that context, what is FIPS 140-2 and why did HBO feature it in their script?

Keep reading at CIOstory.com!

BlogFooterWalt3

13 Jul 2017

A Golden Age in Federal Technology Procurement

Originally posted in its entirety at AFCEA’s Signal Magazine.

orange-capitolThe National Institute of Standards and Technology’s (NIST) benchmark for encryption modules has seen recent innovation, opening the playing field for competition.

For years, NIST’s Federal Information Processing Standards (FIPS) 140-2 validation list read like a Who’s Who of Fortune 100 technology vendors. Only those products that leverage cryptographic modules shown on the list were eligible for federal agency deployment. Until recent changes, only the deepest pockets could absorb the costs of development, testing and expensive consultants to facilitate introducing solutions into the federal marketplace.

Soft costs for FIPS 140-2 validation efforts added up as well, with significant hours required from engineering teams. The result? A huge barrier to entry, effectively blocking any technology company outside of the elite (or rich) from participating in the lucrative federal cybersecurity market. It built a phenomenal feedback loop for those big enough to enjoy it. It was fantastic for the vendors on the inside, but terrible for agencies severely limited in their available options for deployment.

Keep reading at AFCEA’s Signal Magazine!

BlogFooterRay3

15 Jun 2017

Compliance – It’s Not a Dirty Word

Originally posted in its entirety at CIOstory.com.

From a pessimist’s point of view (or someone that has had their arm twisted to meet a standard), compliance is a necessary evil, an act of submission, kneeling to an arbitrary requirement that has no benefit to the actual product. Overtaxed engineering resources were pushed to their limit to build this solution to meet customer specifications, and then they were asked to meet another list of needs just to get a checkmark. Ridiculous, right? The number of features shared by those two sets of requirements might feel like it is non-existent. The Venn diagram would look like a pair of binoculars – completely separate circles.

How could there be any other perspective? It would be like being an apologist for the Black Plague, or being a fan of Jar-Jar Binks. Indefensible positions! Well, bear with me and read on.

Keep reading at CIOstory.com!

BlogFooterWalt3

23 Mar 2017

FedRAMP Kicks It Up a Notch

FedRAMPHave you been following the evolution of the FedRAMP program lately? They are proving to be as nimble as any other group in federal, and even better – they are putting an emphasis on transparency. Check out their blog Focus on FedRAMP for example. After we gave kudos to the CMVP for their recent renewed efforts, it wouldn’t feel right to forget the folks at FedRAMP.

Last month, FedRAMP rolled out an update to their 3PAO Requirements. 3PAOs, Third Party Assessment Organizations, play a huge role in the process, just like the testing labs certified by NVLAP, the National Voluntary Laboratory Accreditation Program, do for FIPS 140-2. For each certification procedure to move smoothly, the 3PAOs and FIPS labs must meet an ongoing standard of excellence. In this case, FedRAMP worked with A2LA, the American Association for Laboratory Accreditation, and determined that they “need to strengthen the 3PAO accreditation requirements to provide for greater 3PAO oversight to ensure that a FedRAMP Accredited 3PAO provides the highest quality, most technically accurate assessments for the Cloud Service Providers (CSPs) who participate in the FedRAMP Program.”

FedRAMP-RAR-768x806An even bigger step forward was taken when FedRAMP unveiled the FedRAMP Readiness Assessment Report (RAR) Template as part of their FedRAMP Accelerated Process initiative in the summer of 2016. Their primary goal was to give Cloud Service Providers a pre-audit tool to self-assess and prepare themselves for scrutiny. But even more importantly in my opinion, the RAR was created as a living document, intended to be updated as needed to shed light on areas that need further interpretation. (Pro tip – make sure that you download the latest version of the RAR when you are prepping and doing due diligence. 3PAOs must use the most current RAR template that is available on the FedRAMP website at the time of submission.) This has been a huge help for CSPs hoping to secure FedRAMP approval. We have had more than a few frantic phone calls from CSPs that were suddenly faced with a mandate for FIPS 140-2 validation and they didn’t have a strategy. This should assist folks plan ahead and develop a more comprehensive plan in advance.

Despite our efforts to raise awareness about the requirement for FIPS 140 in FedRAMP over the last few years, it had still been a subject of debate. So it’s great that FedRAMP has finally made it more explicit in the RAR. For example, Section 4. Capability Readiness, subsection 4.1 Federal Mandates, bluntly asks “Are FIPS 140-2 Validated or National Security Agency (NSA)-Approved cryptographic modules consistently used where cryptography is required?” This should be no surprise, of course. A federal program requiring the crypto to be federally approved. That makes more sense than many bureaucratic requirements, doesn’t it? More below about the NSA caveat.

Further, check out subsection 4.2.1. Approved Cryptographic Modules [SC-13]:

The 3PAO must ensure FIPS 140-2 Validated or NSA-Approved algorithms are used for all encryption modules. FIPS 140-2 Compliant is not sufficient. The 3PAO may add rows to the table if appropriate, but must not remove the original rows. The 3PAO must identify all non-compliant cryptographic modules in use.

Table 4-2. Cryptographic Modules

  Cryptographic Module Type FIPS 140-2 Validated? NSA Approved? Describe Any Alternative Implementation
(if applicable)
Describe Missing Elements or N/A Justification
Yes No Yes No    
1 Data at Rest [SC-28]
2 Transmission [SC-8 (1), SC-12, SC-12(2, 3) ]
3 Remote Access [AC-17 (2)]
4 Authentication [IA-5 (1), IA-7]
5 Digital Signatures/Hash [CM-5 (3)]

As you can see from the Cryptographic Module planning matrix above in Table 4.2, FedRAMP is taking extra care to highlight the need for a FIPS validated module. They clearly had more than a handful of conversations with CSPs trying to argue for the use of a selection of algorithms from the CAVP list as ‘good enough’ and wanted to nip that in the bud. In fact, those were their bolded terms, not mine! The distinction is very important and the clarification was clearly needed.

I almost forgot. Circling back for those of you eyeballing the ‘NSA Approved’ verbiage as a potential loophole to bypass FIPS 140, I have just two words: Good. Luck.

That ubiquitous AES-256 implementation that you’re hoping will satisfy this requirement, because, after all, it is an included component for NSA Suite B… yes, well, it’s also included in FIPS 140-2 and therefore governed by CMVP/CAVP. So if there’s no CAVP certificate, and it’s not implemented as part of a CMVP validated FIPS 140-2 cryptographic module… well, let’s just say that you already missed St. Patrick’s Day and you’re going to need a whole truckload of four-leaf clovers for that to pass muster.

FedRAMP is taking great steps to take the mystery out of the process, and one of those major clarifications is the explicit reliance on the CMVP and FIPS 140-2 validation. If you’re reading this blog, you probably already know it, but nobody handles FIPS 140-2 requirements as quickly, easily, or effectively as SafeLogic. For more information, please explore our products and services at your leisure. They are designed to work in tandem and remove the hassle for your team. As always, contact us with any questions.

 

BlogFooterWalt3

7 Mar 2017

The CMVP Historical Validation List Is Here with a Vengeance

SunsetEditor’s note: This post was updated on March 14, 2017 to reflect a distinction that came to light in dialogue with CMVP – validations moved to the Historical List have not been revoked outright. The validation still exists, but are not for Federal Agencies to include in a new procurement. Agencies are recommended to conduct a risk determination on whether to continue using existing deployments that include modules on the Historical List.

Over a year ago, our blog featured posts about the RNG issue that was leading to certain FIPS 140-2 validations moving to the Historical List and the 5 year sunset policy that CMVP was adopting. [Geez, was that really more than a year ago? Crazy.]

Now the hammer has dropped, and the industry is seeing modules routinely relegated to the Historical List each month. The sunset policy created a waterfall in January 2017, and as of today, there are 1,914 modules on the Historical List, representing approximately 2/3rds of the total validations completed in the history of the CMVP.

Let me repeat that for emphasis. 1,914 modules.
Approximately 2/3rds of all modules ever validated by NIST to meet the FIPS 140 standard are no longer on the active validation list.

This includes some modules that were updated in 2016, and a few were even just revised in 2017! Many of these are hardware, so they are often more static and harder to update, but certainly not all. Check out the entire Historical Validation List for yourself. It’s a veritable “Who’s Who” of once-proudly validated companies. Big names, hot startups, none are immune. Between the sunset timeline and the active removal of modules that are no longer compliant, the herd has been severely thinned.

The takeaway? Maintaining FIPS 140 validation is really hard! It’s not “just one big push” to get on the list anymore. It requires constant vigilance to stay on top of the updates and to keep up with NIST’s reinvigorated policies. A more active CMVP can seem like a pain in the ass at first glance, but it is ultimately better for the industry. Nobody (except for lazy vendors) benefited from old, insecure, ‘grandfathered’ modules remaining on the active validation list. A stringent, active CMVP has embraced their role as a clearing house and it increases the value of the modules that do satisfy current standards. And I think they’re doing a great job.

This underscores the strategic significance of relying upon SafeLogic to complete and maintain FIPS 140-2 validation. As I tell folks every day, this is our focus. Our business is based upon the proper production of FIPS-compliant modules and their subsequent validation. Our customers reap the benefits of our work, and we succeed by scaling it, replicating our effort and leveraging our niche expertise for each client. CryptoComply is smooth and RapidCert accelerates the initial validation, but our customers have really appreciated the value of offloaded maintenance for the certificate. We talk a lot about the time, money, and effort with the traditional process, and the savings realized when using SafeLogic are growing. The delta is getting wider.

I scratch my head when a product manager boasts that they plan to roll their own crypto and get it validated. There are no bonus points for suffering in-house or for reinventing the wheel. When you hire consultants to complete a validation, you’re paying a premium for a single push, when the maintenance really is a constant effort. Consider those costs in time, money, and effort to complete your initial validation – and then add a multiplier for every revalidation you anticipate. It will be at minimum a quinquennial (every five years) project, and that’s if you’re lucky enough to avoid any other pitfall. The math doesn’t lie – the traditional path to FIPS 140-2 validation has become cost prohibitive. And if you’re pursuing Level 2 or Level 3, you still need a solid crypto module at the heart of the product. Using CryptoComply ensures that component meets the necessary requirements, again saving time, money, and effort.

CryptoComply is proven, again and again, to continually meet standards and retain its validated status with NIST. This is one of those situations where you don’t need to be creative. Choose SafeLogic, let us take care of the crypto, and you can get back to doing what you do best.

Written by Ray Potter

22 Dec 2016

FIPS Module 3.0 for OpenSSL 1.1 Update

(L to R) Tony Busciglio (Acumen), Ashit Vora (Acumen), Mark Minnoch (SafeLogic), Steve Marquess (OpenSSL) Not pictured: Ryan Thomas (Acumen)

(L to R) Tony Busciglio (Acumen), Ashit Vora (Acumen), Mark Minnoch (SafeLogic), Steve Marquess (OpenSSL) Not pictured: Ryan Thomas (Acumen)

In December, Acumen Security hosted our kick-off meeting for the FIPS Module 3.0 validation effort. I was SafeLogic’s delegate, Steve Marquess represented OpenSSL, and Ashit Vora, Tony Busciglio, and Ryan Thomas attended for Acumen. With the expected adoption of TLS 1.3 and upcoming algorithm transition deadlines (outlined in NIST SP 800-131A), the OpenSSL-SafeLogic-Acumen Security partnership strives to deliver a FIPS module that works with OpenSSL 1.1 during the 2017 calendar year.

For this project to be successful, we will need additional Project Sponsors. Technology vendors that plan to deliver products using OpenSSL 1.1 in the future should consider sponsorship to support the effort. Financial contributions from Project Sponsors will help fund the engineers developing the code (OpenSSL) and the FIPS Laboratory (Acumen Security) for their validation testing services.

Here is the tentative schedule for the FIPS Module 3.0:

January 2017: Receive initial contributions from Project Sponsors
February 2017: Technical parameters locked in for development
March 2017: OpenSSL team begins development to meet FIPS requirements
May 2017: Development checkpoint
July 2017: SafeLogic reviews FIPS Module, finalizes FIPS 140-2 documentation
August 2017: Acumen submits FIPS 140-2 report to CMVP
October 2017: CMVP provides report comments to Acumen (2 month queue time expected)
November 2017: CMVP issues FIPS 140-2 certificate for FIPS Module 3.0 (for OpenSSL 1.1)

Important Notes:

1. Additional Project Sponsors are needed to make their initial contributions in January to begin the process on time.
2. All development and testing work is scheduled based upon sponsorship contributions being delivered as planned. Additional sponsors will mitigate risk of delays.
3. FIPS Module 3.0 Technical Objectives and Sponsorship information are available here: https://wiki.openssl.org/index.php/FIPS_module_3.0
4. Early releases of the FIPS code will be available from Github for public review and testing.
5. For a quick history of how the OpenSSL/SafeLogic/Acumen team came together, please see our July announcement.

How Can My Company Become a Sponsor?

Thank you for your interest! We welcome additional sponsors to support this crucial development for the community. Please contact me directly to discuss and stay tuned for additional updates here at the SafeLogic blog.

13 Dec 2016

RapidCert for CryptoComply | Java 3.0 Is Available!

CryptoComply | Java 3.0 is here!You may have noticed – SafeLogic has a new FIPS 140-2 certificate posted by NIST. Published on December 8th, it’s our CryptoComply | Java module, version 3.0! Fully compatible with Bouncy Castle’s recent FIPS API revisions and with a nice helping of SafeLogic’s secret sauce (yes, it’s orange), customers with Java deployments now have a natural upgrade path available with CryptoComply | Java 3.0.

Technical improvements over CryptoComply | Java 2.2 include a variety of bugfixes, a significant simplification of deployment, a single JAR that includes both approved FIPS mode and non-approved mode, and the promise of greater forward compatibility. Many of you are already aware of the technical benefits of Bouncy Castle’s latest release, and now SafeLogic’s CryptoComply offering includes RapidCert, which delivers your own FIPS certificate quickly. With a validation in your name and support from our technical staff, CryptoComply is a clear upgrade. See our Top 10 Reasons to Choose SafeLogic Over Open Source Encryption for more!

RapidCert is available NOW for CryptoComply | Java 3.0
License the software today and have a certificate in your name in 8 weeks.
It really is that easy.

Contact us immediately for a quote.

 

BlogFooterWalt3