A major goal of HSPD-12 was to have an interoperable credential across logical and physical contexts for employees and contractors. The goal remains elusive. The GSA’s approved product list was developed to help meet this goal. Some changes need to take place to better achieve this.
The approved product list consists of products and systems. In both cases the list tests items against test scripts. The testing program does not test products with one another or in real world configurations. There are also no tests against a matrix of devices for interoperability. As the list expands and data models evolve it will be increasingly difficult to achieve interoperability among products and systems based on the current testing performed.
In the case of the approved product list authentication systems test there are items bolted on to make up for deficiencies in the typical items found in an access control system. If you look at the list you will see that no typical access controller–door controller or domain controller–is on the Approved Products List. Making testing configurations map to system configurations would help achieve interoperability goals.
A representative infrastructure for testing does not exist–it is also limited in agencies but that is a different matter. As an example there is a Central Certificate Validator (CCV), yet for authentication system testing applicants do not use the validator.
Instead each item under test must provide its own online certificate status protocol responder. The GSA’s approved product list should make a representative development environment available and that same environment should be used for testing.
The 33 categories need to be revisited. The test categories and items, in some cases, do not represent components in a physical access control system. The first generation approved product list products that have come to market are not based on the enterprise architecture requirements but rather are based on the test item product and system categories. Product categories that are more aligned with solution components and tests that more align with best practices in product assurance and interoperability would make the list better.
This is the third review over more than three-years of the FIPS 201 Government Services Administration Approved Products List also known as the FIPS 201 Evaluation Program for Products & Services. The approved product list process was started eight-years ago because of HSPD-12.
Directly related to that process and since IDmachines’ last review, FIPS 201-2 Draft Personal Identity Verification (PIV) was issued in March 2011 and the comment period closed. Changes in a number of areas are expected (see blog on NIST top 10). Also the Federal Identity Credentialing and Access Management (FICAM) 2.0 was issued in December 2011.
Indirectly the National Strategy for Trusted Identities in Cyberspace was issued in April 2011. Products and systems on the approved product list are directly and indirectly impacted by significant other Federal cybersecurity and information security initiatives and publications, many of which have come to pass recently.
There are 606 products from 111 companies listed in 27 of 33 categories on the approved product list. Little changed from 2011 when there were also six categories without products.
The first product has been listed in the Biometric Authentication System category. The Certificate Validator and Server-based Certificate Validation Protocol (SCVP) client categories have been modified to have listing categories of with or without authentication. There is only one supplier in five categories.
- One-third of categories have zero to one supplier
- Nearly half (48.4%) have two or fewer suppliers
- more than a third are in the transparent reader category
- About 70% are in the top five categories (69.47%)
- More than 85% (86.3%) are in the top 10
The following table shows the counts of products and companies in the categories over time.
The approved product list–and general Federal certification and accreditation–is problematic. FIPS 201 is one part of a regime that solution providers must comply with and can include, as examples Federal Information Security Management Act (FISMA), DIACAP/DIARMF (FIPS 199, Controls, SP 800-37, 53A, 137) FIPS 140 Crytpographic Modules, Common Criteria, Transportation Worker Identification Credential. These are all moving and multiple requirements for certification and accreditation.
Security and information technology product and system providers in the Federal enterprise have a lot to bear to get into the market. These requirements do not play nicely with rapidly developing technology. Patches and version upgrades could require new certifications. All of which might be acceptable if you get to a federated and interoperable network from the requirements, otherwise it’s a sink hole.
For the APL to matter it needs to provide the Federal enterprise customers and suppliers a list of items they can buy or build to construct identity application systems and the supporting infrastructure. The system components should be interoperable and the APL should provide an ability to test this.
The test infrastructure and requirements should be public facing, documented, freely available and when possible open source. Ideally there would be more of an option for self compliance. It would reduce the number and frequency of interactions with national validation laboratory accreditation program organizations.
In effect the APL should provide a development environment for testing FICAM applications and infrastructure. If you think you have something that plays, plug it in and see what happens.
Evolving in this way provides more value to end users and industry. End users can leverage the competition among multiple suppliers and move to a common set of procurement requirements, consolidate training and maintenance.
Manufacturers can develop systems and test them in the course of manufacturing in a way that would meet the test laboratory and certification requirements. But companies could also test by leveraging the product assurance performance before making products generally available. These changes would better address the goals of HSPD-12, reduce costs and timelines and improve productivity, privacy and security.
The original D’Agostino post can be found here.