The GSA FIPS 201 Approved Products List (APL) III (Aye, Aye, Aye)

A major goal of Homeland Security Presidential Direction (HSPD) 12 was to have an interoperable credential across logical and physical contexts for employees and contractors.  The goal remains elusive.  The APL was developed to help meet this goal.  Some changes need to take place to better achieve this. 

The APL consists of products and systems.  In both cases the APL tests items against a test script(s).  The testing program does not test product items with each other or in real world configurations. There is no test against a matrix of devices for interoperability.  As the list expands and data models evolve it will be increasingly difficult to achieve interoperability based on the current testing done.

In the case of the APL authentication systems test you find items that are 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 CCV.  Instead each item under test must provide their own on line certificate status protocol responder.  The APL should make a representative development environment generally available and for the same environment to be used for test.

The 33 categories need to be revisited.  The test categories (items) in some cases do not represent components in a physical access control system.  The first generation APL 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 aligned with best practices in product assurance and interoperability would make the APL better.

This is the third review over 3+ years (see blog) of the Federal Information Processing Standard 201 (FIPS 201) Government Services Administration (GSA) Approved Products List (APL) also known as the FIPS 201 Evaluation Program for Products & Services.  The APL process was started 8 years ago by HSPD 12.  Directly related to that process and since IDmachines’ last review FIPS 201-2 Draft Personal Identity Verification (PIV) was issued 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 (NSTIC) was issued in April 2011.  Products and systems on the APL are directly and indirectly impacted by significant other Federal cybersecurity and information security initiatives and publications (see below), many of which have come to pass recently.

 

Card Reader – Biometric Authencation

Card Reader - Biometric Authentication

Card Reader - CHUID Authentication Reader (Contact)

Card Reader - CHUID Authentication Reader (Contactless)

Certificate Validator (without authentication)

PIV Card Delivery

There are six hundred and six products from 111 companies listed in 27 of 33 categories.    In the first table the categories have no products.  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 5 categories.

• 1/3^rd  of categories have 0 or 1 supplier
• Nearly ½ (48.4%) have 2 or less suppliers
• Over 1/3^rd are in the transparent reader category
• About 70% are in the top 5 categories (69.47%)
• Over 85% (86.3%) are in the top 10

The following table shows the counts of products and companies in the categories over time.

 

The APL (and generally 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, TWIC (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 effect 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, be freely available and when possible as 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 also be something they would do anyway by mimicking/leveraging the product assurance they perform in making products generally available.  These changes would better address the goals of HSPD-12, reduce costs and timelines and improve productivity, privacy and security.