In part 1 of this 2-part piece I introduced and defined some of the terms relating to identity assurance. In this last piece I intend to illustrate identity assurance's intersection with real-life through some examples.

Identity Assurance in the Enterprise?

Some interesting considerations come to mind when thinking of identity assurance within an Enterprise Identity and Access Management (IAM) context. I will illustrate with two scenarios:

  1. In the US, organizations need to follow the Employment Eligibility Verification or "I-9 Form" process for their employees. This is a minimum baseline, which meets AL4 (assurance level 4) requirements from an identity proofing standpoint. In some cases, many organizations, obligated by regulation in a specific industry or by the responsibility level the individual is assuming, perform background checks and other due diligence steps to help them increase the confidence in the individual's qualification for the job. Evidently, they are not driven by an identity assurance need but by other needs (e.g. AML - US Patriot Act compliance requirement in banking). This need results in a high-quality identity verification process for employees, which once entered into an HR system can be leveraged for other identity lifecycle and identity-enabled processes.

    But the same cannot be said about other types of employees such as contractors within the same organization. In many cases, these identities are managed by groups outside of HR, and are not obligated to follow as strict a process to register.

    In most cases, employees and contractors end up with an entry in the organization's Active Directory, from which they get assigned a username and password - an AL2 authentication method. As is often the case, these AD credentials are used to control access to a large number of systems and applications, ranging from a low to high level of sensitivity. In other cases, users (employees or contractors) are issued VPN access, with a 2-factor authentication credential - soft or hard tokens,  all the same either AL3 or AL4 authentication methods. This is so the user can access systems remotely in a secure fashion, since internal system's sensitivity level is deemed to increase when accessed remotely. But, in all such  cases, the organization is not effectively increasing the identity assurance of contractors. Even with strong authentication credentials, the risk level has not effectively gone down.

  2. An example introduced in my blog post of January 25, 2010, a client has a request/approval process in place to manage the issuance of access cards (in this case, with no picture ID) to various facilities and sites. When an employee first comes onboard, their identity is vetted against information in HR in order to be issued an access card. The request must be approved by two management levels. Now, since the process often takes a few days to complete, some managers tend to hold on to the access card from a departed employee, literally keeping them in a drawer. When a new employee comes onboard, the manager recycles the access card and, by doing so, increases the employee's productivity by providing her with an access card without any delays, but all access activity and access authorization is based on the departed employee's information. The organization is now incurring significant costs to ensure that access to its facility is tightly managed, but the process for ensuring that a departed employee event triggers the deactivation of the access card is not well enforced.

    So in the end, this imbalance in identity assurance costs the organization money and does not really mitigate the risk it was intended to.

I hope I have convinced you that you are making identity assurance tradeoffs in your internal environment today. As you internalize identity assurance as a tenet  in your IAM program, remind yourselves of the importance of data classification and application sensitivity ranking, so you can tie identity assurance more effectively.

identity assuranceAdvice: Do not make identity assurance a burden or yet another heavy set of requirements to deal with in your already complex IAM initiative, instead, think about it as a compass, or a tool that can help you make decisions around complexity, cost and risk. The point here is to ensure that your effort and investment is balanced in light of your requirements. Otherwise, you may be wasting precious dollars. Ask yourself: am I spending too much in authentication technology and too little in the process of ensuring I know who the person is? Is it the reverse? When you deploy single sign-on (SSO) solutions for your applications, what AL can you reliably say you are conveying or providing to them? Should they all have SSO?

Another Everyday Life Example

My friend Tom Smedinghoff recently informed me of this case: The Prudential Insurance Company of America, v. Dukoff et al (December 18, 2009), which was of particular significance for me in the context of identity assurance. It deals with authentication requirements for an electronic signature in an online insurance application. 

Basically, Prudential wanted to deny coverage under a group life insurance policy, and was trying to use allegedly false statements that appeared in the electronically signed online application as the basis for doing so.  The insured argued that the online application did not contain a valid electronic signature under the NY Electronic Signatures and Records Act, so, therefore, the allegedly false statements in the online application could not be used to deny coverage (since NY law prohibits insurance companies from using a statement made by an insured for purposes of contesting the validity of the insurance "unless it is in a written instrument signed by him").

 In this case the insurance application was submitted through a standard Internet click-through process that is normally considered a valid signature.  Yet the court focused on an opinion of the Office of General Counsel for the State of New York Insurance Department, which stated as follows:

Generally speaking, a checked box on an electronic form on the Internet constitutes a valid electronic signature in New York if the "electronic ... symbol or process [is] attached to or logically associated with [the] electronic record and executed or adopted by a person with the intent to sign the record,". . . provided that the insurer, agent or broker using such technology to transact business is capable of verifying that the person providing the electronic signature is actually the party to be charged. Without such verification measure in place, the Department would not consider a checked box to be a valid signature

 Relying on this opinion, the court held that in order for an insurer to use statements made in an online application to support its fraud lawsuit against a claimant, the company must have had sufficient authentication processes in place to make the signer reasonably identifiable.  While the court agreed that the signature itself did not need to identify the person signing, it held that "Prudential may use statements made in the insurance application to challenge the insurance contract's validity only if Prudential could reasonably identify the person who made them."  In other words, the court required that Prudential adequately authenticate the identity of the signer of the application.

 This real life example shows that:

    • Identity assurance is truly an everyday issue with real life consequences
    • Identity assurance is more than just authentication
    • Even a simple checkbox on a web page has a direct tie to identity assurance

I am interested in your thoughts about these issues, and how your views of identity assurance affect your IAM initiatives. I am particularly interested in other real life examples.

Strategic Planning for IAM Success

Frank Villavicencio

Frank Villavicencio