A starting point for enterprise identity device deployments

By Ian Lowe, Intercede

Smart cards and smart card-based devices are rapidly becoming the secure device of choice for a persons identity. The combination of security and portability allows them to carry credentials (such as; photographs, PKI certificates and biometrics) 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 validate their identity or authenticate to something, the level of trust required is dependent upon the risks associated with the damage caused by fraudulent use. As the risks rise, the reliance you place in the validation of the identity increases.

This means you have to not only trust that the device and the technology itself is secure, but that the device has been issued to a person in a secure and trusted manner.

Enterprise identity deployments = mixed success

Smart device-based identity programs within the corporate enterprise have had mixed results. Success has come slowly due to a number of factors including:

(i) 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), card management systems (CMS), provisioning systems, public key infrastructure (PKI), authentication and Single Sign-On (SSO) systems, physical access control systems (PACS), biometrics etc. These technologies often exist as discrete silos and often do not naturally interoperate.

(ii) 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. However, FIPS 201 is helping to remove some of these barriers by providing a standard for interoperability and clearly defined policy and secure process for issuing identity devices to a population of users.

HSPD 12/FIPS 201 driving identity device deployment

In 2004 President Bush issued Homeland Security Presidential Directive 12 (HSPD-12 establishing a standard for the identification of all U.S. 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:

(i) the technical specifications of the cards, their content and the interoperability of key systems and technologies

(ii) 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 U.S. Federal Government and is now providing a further catalyst for the adoption of smart cards within corporate enterprise and other non-U.S. government environments.

FIPS 201 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/identity credential management system, such as Intercede’s MyID.

The card identity credential management system is the central piece that unites all the necessary identity technologies and systems together to create digital identities. The main role of the identity credential management system is to bind people with devices and credentials – creating identities. This process must be secured from both a technology and process standpoint in order for the digital credentials issued by the system to be trusted.

FIPS 201 – Secure policy and process for identity device deployment

FIPS 201 provides a clear and secure set of roles and processes for the enrolment, 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 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.

FIPS 201 can easily map across to the corporate enterprise Applicant => Employee/Cardholder Is the person who requires an identity device.

Sponsor => Human Resources Typically the 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 => Authoriser/Witness (Optional) The Authoriser/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.

FIPS 201 helping ease the pain of enterprise identity device deployments

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 employee’s with a high level of trust and integrity. Organizations that adopt a FIPS 201 like model can have confidence that:

• The device and technologies used are tested and secure.
• The applicant’s identity has been verified and validated.
• The identity device has been issued in a secure fashion by trusted employees.
• The device and identity credential management system has been validated and is interoperable.

HSPD 12 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 scratch. HSPD-12 is removing the barriers to identity device deployment by providing a readily available ‘shopping list’ of interoperable technologies and a clearly defined set of secure process for issuing and managing identities. Combined these factors ultimately pave the way for successful identity deployments by reducing both the complexity and the overall cost of deploying identities.

---

About the author:

Ian Lowe, Intercede Ian.lowe@intercede.com http://www.intercede.com