Federal Identity

Achieve compliance without a rip-and-replace investment

• By David Adams
• Oct 01, 2011

When the Homeland Security Presidential Directive-12 (HSPD-12) was enacted in August 2004, government agencies embarked on the challenging task of complying with an evolving set of standards designed to ensure that all federal employees and contractors have secure and reliable forms of identification.

Agencies were given more specific deadline information in February 2011. The Department of Homeland Security and the Office of Management and Budget issued a memorandum stating that, beginning in the government’s fiscal 2012—that is, Oct. 1, 2011—all existing physical and logical access control systems must be upgraded to implement Personal Identification Verification (PIV) credentials before federal agencies can use development and technology refresh funds to complete other activities. These access control systems must use smart card and biometric technology and support identification credentials in compliance with National Institute of Standards and Technology (NIST) guidelines, which are embodied in Federal Information Processing Standards Publication 201 (FIPS-201).

Complying with these guidelines has generally been a costly and complex process that has required agencies to gather, organize and deploy a variety of technologies. Agencies have also frequently needed to hire experts and third-party suppliers to assist with their upgrades and to establish a migration path from existing credentials. Too often, agencies have been required to completely replace their physical access control head-end servers, panels and door control hardware. With proper planning and a modular, turnkey approach, however, FIPS-201 compliance can be accomplished at a significantly lower cost while preserving investments in the existing access control infrastructure.

Compliance Requirements and Deadlines

HSPD-12 is intended to enhance security, increase government efficiency, reduce identity fraud and protect personal privacy. It requires agencies to follow specific technical standards and business processes for the issuing and routine use of secure and reliable forms of identification in compliance with FIPS-201.

The FIPS-201 document, titled “Personal Identity Verification (PIV) of Federal Employees and Contractors,” defines the multi-factor authentication, digital signature and encryption capabilities required for standardized PIV smart card credentials. Federal employees and contractors must use these cards to gain access to all government facilities and disaster response sites. FIPS- 201 compliance is expected to create a standardized infrastructure of interoperable access control products across a wide range of facilities belonging to disparate agencies and partners. This will lead to reduced overall costs while improving the government’s ability to leverage its buying power. All new systems under development will need to support PIV credentials and physical building access modifications according to NIST guidelines.

One of the most important documents issued by the government is SP800- 116, which introduces the concept of controlled, limited and exclusion areas, to which agencies must tailor risk-based PIV authentication mechanisms. The document also proposes a PIV Implementation Maturity Model (PIMM) to measure the progress of facility and agency implementations. Finally, it recommends to federal agencies an overall strategy for the implementation of PIV authentication mechanisms within a facility’s physical access control system (PACS).

Compliance Best Practices

Using fully interoperable, simple-to-deploy and cost-effective products and technologies that have been tested and validated as part of a complete, turnkey solution is the best way to streamline FIPS- 201 compliance. The most successful upgrade programs also provide agencies with a single point of deployment responsibility, and they ensure that compliance is achieved quickly, effectively and with all necessary audit support, on an incremental, pay-as-you-go basis, so agencies can retain much of their existing infrastructure. Compliance programs should:

• Enable the authentication of credentials across the full range of assurance levels;
• Deliver compliance without requiring a wholesale rip-andreplacement of existing equipment;
• Offer the option of implementing a converged physical and logical security solution as envisioned by HSPD-12;
• Provide a single solution for both FIPS-201 and SP 800-116 compliance; and
• Meet all security, compliance and ROI objectives by enabling the full range of PIV, PIV-I and CAC card access.

Achieving these objectives requires a modular approach using a new generation of more flexible and secure reader platforms combined with modular compliance hardware.

Leveraging Reader Advances for FIPS-201 Compliance

The latest reader technology reduces the complexity of the compliance process significantly by employing better-protected architectures that significantly enhance access-control security and deployment flexibility. These reader platforms employ EAL5+ secure element hardware that ensures tamper-proof protection of keys and cryptographic operations. They also use the industry-standard open supervised device protocol (OSDP) communications standard to establish a seamless and secure, bidirectional link between the reader and today’s easy-to-deploy FIPS-201 compliance hardware modules.

Next-generation reader technology also enhances security by using a new, portable credential methodology on a standardsbased, technology-independent and flexible identity data structure. This data structure uses a device-independent data object that HID Global calls a secure identity object, which can exist on any number of identity devices. These data objects work with companion SIO interpreters on the reader side that, together, behave as traditional cards and readers do while using a significantly more secure, flexible and extensible data structure.

Device-independent data objects offer three key benefits for FIPS-201-compliant solutions and other access control system implementations. First, because they’re portable, these data objects can reside on traditional contactless credentials and many different mobile device formats, ensuring interoperability and easy migration.

Second, their device independence enhances trusted security by enabling them to act as a data wrapper to provide additional key diversification, authentication and encryption while guarding against security penetration.

Third, because they use open standards, these deviceindependent identity objects improve flexibility and can grow in security capabilities while traditional architectures remain stuck in a fixed definition. Each of these benefits is critically important for next-generation, secure identity portability and for enhanced protection in a FIPS-201-compliant environment.

Implementing a Modular Compliance Upgrade

With a modular upgrade, the only hardware that needs to be added is new readers, compliance hardware modules and a compliance manager. Installed between the readers and the existing PACS panel, the compliance hardware modules are used to validate FIPS-201 cards, extract the badge ID and pass it along to the PACS panel for an access decision. The compliance manager provides centralized control of assurance level settings and distribution of validation data. The most recent offerings add a new service application programming interface (API) that integrates PACS enrollment capability directly into the validation service.

Today’s modular compliance systems perform all of the steps required for PIV authentication. At the time of enrollment, the trusted card issuers—also known as the trust anchors—are set in the system. The status of enrolled PIV cards is checked on a periodic basis to prohibit access by revoked cards. This is done by retrieving the card revocation status from the issuing certificate authority (OCSP/ CRL/MiniCRL) and the TWIC Hotlist. When a PIV, PIV-I, CAC or TWIC card with the appropriate assurance level is presented to a corresponding reader, the compliance hardware module validates the card according to the assurance level setting, extracts the badge ID from data on the card, and then passes the badge ID to the PACS panel for an access decision and logging.

The compliance hardware module also validates PIV cards from visitors by using the Server-based Certificate Validation Protocol (SCVP) to implement the path discovery process and establish a chain of trust through the federal bridge. This enables interoperability across government agencies and with non-government members of the federal bridge.

For invalid cards, the compliance hardware module is configurable to send a preset badge ID to the PACS panel and/or close an output relay. In case of communication interruption, the compliance hardware module maintains an updated validation data cache—such as issuer trust status and revocation status—so it can function offline, while strong authentication continues at the door.

Additionally, cardholder data can be captured automatically the first time a card is presented for validation to any reader connected to a compliance hardware module. The data also can then be stored and distributed to all other compliance hardware modules by a compliance management station. This feature delivers several benefits. It allows traditional cardholder enrollment using existing PACS enrollment functionality. It also allows integration with an identity management system or card management system.

Finally, it enables the use of third-party enrollment packages. Federal agencies face challenges in upgrading their PACS infrastructure to meet the latest government mandates. Until now, the compliance process has required multiple vendors, and agencies have often had to replace their entire systems. A new, modular hardware approach makes it significantly easier and less costly for agencies to respond to regulatory changes, while giving them the flexibility to modify security levels in selected areas, as required, and take advantage of ongoing advances in access control technology.

This article originally appeared in the October 2011 issue of Security Today.