The U.S. Homeland Security Presidential Directive 12 (HSPD-12) and the Federal Identity Processing Standard 201 (FIPS 201) help ease the pain of enterprise identity device deployments.
Smart cards and smart card-based devices are rapidly becoming the secure device of choice for storing digital identities. The combination of security and portability allows them to carry credentials that can be used to easily validate a person’s identity.
When an individual uses a digital credential held on a smart card-based device to authenticate to something, the level of trust required is dependent upon the risks associated with the damage caused by fraudulent use. As the risk levels rise, the reliance you place in the validation of the identity increases.
With smart, secure device-based identities, this means you have to not only trust that the device itself is secure, but that the device has been issued to a person in a secure manner. (There is no value in an individual carrying a device proving they are J Smith if they are not actually J Smith!)
By Ian Lowe
ENTERPRISE IDENTITY DEPLOYMENTS
Smart device-based identity programs within the corporate enterprise have had mixed results. Success has come slowly due to a number of factors including:
Complexity and Lack of Interoperability -- When deploying smart cards in the enterprise there are numerous infrastructure and technology elements that need to work together, including authoritative user data stores (directories, HR systems, etc.), Public Key Infrastructure (PKI), authentication and Single Sign-On systems, physical access control systems, biometrics, etc. These technologies often exist as discrete silos and often do not naturally interoperate.
Lack of Policy and Process -- In many organizations there are no standard policies for issuing identity devices to users. Without reliable processes there is a tangible risk that an identity device will be issued incorrectly, or worse, fraudulently to a user. Establishing reliable processes is complex and requires experience and expertise.
When combined, the above factors ultimately lead to the return on investment promised by an identity system not being realized.
A DRIVER FOR IDENTITY DEVICE DEPLOYMENT
In 2004 the U.S. President Bush issued Homeland Security Presidential Directive 12 (HSPD-12). HSPD-12 established a standard for the identification of all Federal Government employees and contractors. HSPD-12 requires the use of a common identification credential called a Personal Identity Verification (PIV) smart card for both logical and physical access.
HSPD-12 led to the creation of the Federal Identity Processing Standard 201 (FIPS 201), which set out the two key aspects of deploying a secure identity card:
-
The technical specifications of the cards, their content and the interoperability of key systems and technologies
-
The business processes necessary to ensure a consistent level of assurance between issuing and relying authorities
HSPD-12 has been an accelerator for the adoption of smart card-based identities within US Federal Government and is now providing a further catalyst for the adoption of smart cards within corporate enterprise and other non-US government environments.
|
.jpg)
|
|
Figure 1. Device and identity management system (Source: Intercede) |
DEFINING INTEROPERABILITY
HSPD-12 and FIPS 201 are paving the way towards a future where identity technologies and IT systems and infrastructure work together in harmony. Any technology vendor wishing to provide identity solutions to the U.S. Federal government must put their products and solutions through a rigorous testing and approval process. Once the products have been approved and certified interoperable (based on published standards) they are listed on the Approved Products List (APL) (see http://fips201ep.cio.gov/apl.php).
At the center of any identity deployment is an identity management and card/credential issuance system.
The identity management and card/credential issuance system is the central piece that unites all the necessary identity technologies and systems together to create digital identities, its key role is to bind people with devices and credentials -- creating identities. This process is secured from both a technology and process perspective allowing digital credentials issued by the system to be trusted.
SECURE POLICY AND PROCESSES
FIPS 201 provides a clear and secure set of roles and processes for the enrollment, issuance and management of people, devices and credentials.
The roles:
Applicant -- An applicant is the person who requires a PIV card (e.g., an employee of a federal agency). They must first contact their designated PIV sponsor so that they can initiate the application process. An applicant must ensure that they have accurate personal information including: (name, date of birth, contact details) and their employment status within the U.S. Government Department (agency/ department, status, role, etc.)
Sponsor -- The sponsor is responsible for creating the initial requests for PIV credentials for those individuals under their authority. The sponsor determines whether or not an individual is entitled to apply for a PIV card. A sponsor is typically someone who knows the individual, e.g., their line manager.
Registrar -- The registrar is responsible for verifying the identity of the applicant and the authenticity of their application documents and once he/she is satisfied that the documents are in order he/she will make the request for the PIV card to be issued to an applicant. The registrar will also capture biometric data from the applicant, including capturing fingerprints and a photo.
Signatory -- The signatory is responsible for approving PIV card requests that have been processed by a registrar. Depending on the policies adopted by an agency, this tertiary approval process may or may not be necessary depending on the card types.
Issuer -- The card issuer has the task of actually producing the PIV card and delivering it to the applicant within a face-to-face collection process. This involves electronically personalizing the card (e.g., fingerprints and certificates) and printing the card surface.
CORPORATE APPLICATION
Applicant => Employee/Cardholder -- Is the person who requires an identity device.
Sponsor => Human Resources/ System -- Typically the U.S. Human Resources Department is responsible for the mechanics of hiring an individual and in the FIPS 201 process would make the initial requests for identity devices to be issued to employees. In corporate environments this process is likely to be automated by utilizing information already in an HR system or directory.
Registrar => Human Resources/ Person -- During the induction of a new employee, personal data is likely to be gathered (e.g., fingerprint or photo). This function could be carried out by HR department personnel and is likely to be incorporated into the standard employee enrollment procedure.
Signatory => Authorizer/ Witness (Optional) -- The Authorizer/ Witness is an optional role and is responsible for approving, for a second time, card requests that have been processed by a registrar. In a corporate environment if this stage is required it is likely to be the applicant’s Line Manager or the Line Manager’s Manager who authorizes the card issuance.
Card Issuer -- The card issuer has the task of actually producing the identity device and delivering it to the applicant within a chosen collection or delivery process. Dependent upon the issuance model, this could be face to face, issued centrally in batches or via self-service collection.
The scope of these roles is summarized in the above diagram that represents the HSPD-12 secure PIV request, issuance and management workflow.
A BENCHMARK
FIPS 201 is helping to ease the pain of device-based identity deployment by providing a standard for interoperability and a clearly defined secure process for issuing identity devices to end-users. Organizations adopting the interoperability standards and, issuance and management process defined in FIPS 201 can be certain that an identity device has been issued to their employees with a high level of trust and integrity. Organizations that adopt a FIPS 201 like model can have confidence that:
-
The device itself is a secure platform.
-
The applicant’s identity has been validated before the device is issued.
-
The device has been issued in a secure fashion by trusted employees.
-
The device and identity management system has been validated and is interoperable.
The U.S. initiative has defined a benchmark. This benchmark can be easily adopted by any organization looking to deploy device-based identities. Not all of the policies, processes and controls defined in FIPS 201 will be appropriate for your organization, but many will. HSPD-12 and FIPS 201 have provided a model that can be quickly adopted and easily adapted to meet an organization’s needs without having to reinvent the wheel or start from a blank sheet of paper. HSPD-12 is removing the barriers to identity device deployment and at the same time is raising the level of trust and reducing the cost associated with deploying identities.
Ian Lowe is Marketing Manager of Intercede (www.intercede.com).
For more information, please send your e-mails to swm@infothe.com.
ⓒ2007 www.SecurityWorldMag.com. All rights reserved.
|
