A Quick Guide to Getting a Product onto the GSA FIPS 201 Approved Products List

by Steve Weingart

Going through the evaluation process and getting your product onto the GSA Approved Products List (APL) can be a trial, but if you follow these steps, it just might be a lot easier:

1. Visit the GSA FIPS 201 website (fips201ep.cio.gov) and obtain a login (under ‘2’ on the left side). Then go to the right side of the page and click on the Supplier’s Handbook, which will tell you about the process and rules.  
2. Under Approval Procedures (AP), a bit lower on the right, figure out which category or categories are applicable for your product, and then download the Approval Procedure package(s) for your product(s).
3. In the AP, section 3.1, table 1 lists all of the requirements.  There are four (4) kinds:
   a.    Vendor Documentation Review (VDR) - is performed by the lab on the vendor’s product documentation.
   b.    Vendor Test Data Report (VDTR) - shows the results of the tests that must be performed by the vendor or a consultant; the lab is not allowed to perform these tests, and the results are detailed in the VDTR and reviewed by the lab.
   c.    Lab Test Data Report (LTDR) - shows the results of the tests that the lab performs. These tests are defined in a separate document called the Test Procedure. The Test Procedures, for categories that have them are in the Test Procedure section of the website, on the right under the APs.  The lab produces the LTDR, if one is required, and it is submitted to the GSA along with the final report.
   d.    Certification (C) - to fulfill these requirements, you must get some other certification outside of the GSA program.  The typical requirements are FIPS 140-2 for cryptography, MINEX for fingerprint template matching or FIPS 201 NPIVP by NIST for PIV cards or Middleware.  Some of these certifications can take quite a long time to obtain (up to a year, or more),  so you should get these started, if you need any of them, before you start the GSA PIV evaluation process.
4. Now that you know the requirements, you can get any needed certifications and make any needed design updates. It is time to pick your lab, get training for your staff and a gap analysis for your product, if needed.
5. Once you begin the testing process with the lab, you will fill out the web application form for your product on the GSA website and assign the case to your lab.  At this time, you will send your VTDR with any supporting evidence, product documentation and the three other required forms from the AP package to the lab. Those three forms are a spreadsheet showing where to look in each of your documents for the evidence for each requirement and two affidavits; one attesting to the truth of your company statements and the other one having to do with Federal Acquisition Regulations.
6. One really important note: By the time you complete the submission, you will have had to enter the product name, the version numbers for the software, firmware and hardware and the company name and address about 6 times, so make sure that each entry is EXACTLY the same as all others. They must match, including case, punctuation and spaces, etc.
7. Once the data and docs are available to the lab, the lab testing and review of documentation and the VTDR begins.  If any nonconformities are found, they can be corrected and the test process iterated, until the product passes all tests and the docs meet all requirements.
8. Once the product meets all of the requirements and the reports are complete, the lab submits the package to the GSA for approval.

The Top 3 Mistakes When Starting a FIPS 140-2 Project

by Steve Weingart

1. Starting without the standard in mind
Probably the biggest problem causing issue in a FIPS 140-2 validation project is when the developer decides to ‘back into’ the standard after the fact. Trying to validate a product that was developed without being mapped to the standard is more difficult at the very least and has a potential for failure at the worst.

FIPS 140-2 has many specific system requirements including: self-test on start-up, where the integrity of the module has to be verified and all cryptographic functions have to be run against known answer tests to ensure correct operation. The entire lifecycle of the cryptographic keys has to be managed, from how they are created; to how they are used, transported, stored and ultimately how they are destroyed (or zeroized in FIPS 140-2 parlance). How random numbers for key creation are generated, how user authentication is performed and which cryptographic algorithms are used (and in what context), are also functions that have to be performed in a compliant manner.

When the developer comes to a validation test lab with a cryptographic module that is missing required components, or has implemented them in a non-compliant way, it always makes the validation process more difficult, more time consuming and ultimately more expensive for the developer.

The best time to start with the standard is when the design and architecture are first beginning. Reading the standard for the general overview, then really getting into the details of the Derived Test Requirements and Implementation Guidance documents (all available at the NIST Cryptographic Module Validation Program website) will get you started down the best path to a successfully validated FIPS 140-2 cryptographic module.

2. Being unaware of your responsibilities
As in #1 above, many customers come to test labs not knowing anything about their part in the validation process. Validation is a team effort. The developer must supply the lab with all of the required documents and artifacts for testing, but that is really only the beginning. It is the open support and cooperation - both ways - that allows the project to go smoothly and quickly. The relationship between the lab and the customer should not be adversarial. We are all on the same side. The goal is to get your product validated, but the lab has to meet that goal by assisting and guiding you in meeting every requirement. It is not the lab that issues the Certificate of Validation; it is issued by the CMVP (Cryptographic Module Validation Program) at NIST in the U.S., and the CSEC (Computer Security Establishment Canada) in Canada. Both of those agencies review the final test report and then usually ask the lab for clarification on several points, sometimes sending us back for some additional evidence, before issuing the certificate. So it is you and the lab working together to present your case to the program, and we really have to be a team.

The best way to set up for this teamwork is to choose your lab early in the development process. That way the lab can start to review your architecture and design early on, hopefully saving you from going down any non-compliant paths. The lab can also provide training on the FIPS 140-2 standard and its requirements, as well as perform a readiness assessment to go over your design in detail, before the formal validation process begins.  Going down this path is probably the best way to make sure your validation experience is a good one.

3. Expecting a “rubber stamp”
After seeing the first two pitfalls above, this one may seem redundant, but unfortunately it’s not. Many folks never get it that receiving a Certificate of Validation for your product is not just a matter of paying some money, tossing some documentation over the fence and waiting for the Certificate to arrive. The FIPS 140-2 process entails documentation review, code review, testing of your product both in its normal state, as well as in induced error states and more testing to see if your security protection mechanisms work as claimed. This work is performed by highly trained engineers and each of these tests and reviews must be formally documented. The final report often runs 50+ pages and is what NIST and CSEC review. It is a serious process and it is backed up by months of serious work for each validation. As a customer, you definitely get a lot of work for your time and money.

I hope this gives a bit of insight into the FIPS 140-2 validation process and helps to prepare you and your product for an easier and successful path to a Certificate of Validation.