Blog

IAM Assets Often Overlooked in the Enterprise

Share

 

After reading very interesting posts by Earl Perkins at Gartner, an article from Deloitte on financial institutions making Identity and Access Management (IAM) their #1 priority, and my friend Nishant Kaushik's recent series on Federated Provisioning and the Cloud, which is brilliant and thought provoking (nicely done Nishant); I felt compelled to chime in.

Having drunk the identity assurance cool-aid for way too long, I can't help but think about IAM in terms of risk and assurance levels, the yin-yang balance sort-of-speak. So, before thinking about automating and deploying technology, I wonder what kind of risk is being mitigated and what kind of investment is warranted to provide the right level of assurance. In reaching equilibrium, one will inevitably follow the path of maximum value at the lowest cost possible.

So, with that thought in mind, I have been considering "lazy" assets that often exist in the Enterprise. They have significant potential in helping organizations derive higher levels of assurance, without significantly increasing cost, and can also add greater value to IAM initiatives.

Notwithstanding the great thoughts of Earl and Nishant, here are three examples of such assets, and my attempt to illustrate their use in real life.

User Activity Logs

I referred to this in prior blogs dealing with the topic of identity activity monitoring. The point here is to think about how one could utilize information collected from system or application logs, particularly if they contain traces of identity that can be used to link activity to a human being.

With the maturity and pervasiveness that SIEM technologies have nowadays in the Enterprise, deriving value from correlating and reporting on data (whether near real-time or historically) is relatively simple and inexpensive. This information can prove crucial in increasing visibility into day-to-day risks such as insider threads, segregation of duty violations, detecting terminated accounts activity, and other undesirable scenarios that would normally go under the radar of traditional IAM infrastructures.

We see this as a clear trend that is here to stay. More and more customers in different industry verticals (from energy to financial services) are gravitating toward identity activity monitoring as an important part of their IAM initiative. And based on our insight, the benefits make for a great business case.

Employee Identity Proofing (ala US Form I-9)

I touched on this point within the context of a two-part blog posting regarding identity assurance in everyday life. In the US, the Employment Eligibility Verification Form I-9, constitutes a great identity proofing mechanism, yielding (for the most part) an Assurance Level 4 (AL4) compliant verified identity in accordance to the Kantara Initiative Identity Assurance Framework (as well as NIST SP 800-63).

I realize that this statement is a controversial one since many would argue that the form I-9 verification process is inconsistently followed and audited. This inconsistency was a precursor to the work being led by NASPO, specifically by Graham Whitehead. However, many organizations enrich their employment verification process with "know-your-employee" checks that help them meet high-risk mitigation and compliance requirements. This is particularly true in regulated industries such as financial services, healthcare, pharmaceutical, and aerospace and defense. Hence, I argue that this high-quality identity proofing constitutes a valuable asset to the organization.

For instance, this proofed identity could be leveraged in some instances to issue AL4 credentials. Examples include credentials issued within federations such as CertiPath in the aerospace and defense industry, SAFE-BioPharma in the bio-pharmaceutical industry, or by other credential issuing authorities cross-certified with the Federal Public Key Infrastructure (FPKI) Policy Authority.

There are multiple benefits that an organization can derive from using these credentials, whether within its firewall or outside it. For example, in the biopharmaceutical industry, paperless R&D is achievable by leveraging legally accepted digital signatures that comply with the SAFE-BioPharma standard. These signatures are accepted by the FDA for eSubmissions, by the US Patent Office, and within the EU as legally accepted in conformance with the Electronic Signature Directive (1999/93/EC). Therefore, significant value can be derived from the use of these credentials, which can be issued by leveraging the high-quality-identity-proofing asset the organization had to perform anyway.

Similar examples can be found in various industry verticals, such as the KYC (Know-Your-Customer) standard in banking, which conforms to the US PATRIOT Act requirements. Hence, if one can verify that the identity of an individual is that of a DDA account holder, this could be evidence of an antecedent high-quality identity proofing, which can be leveraged to issue a high-assurance credential. This could be an effective and scalable approach to proofing the identity of non-employees (i.e., contractors, vendors, suppliers). In this case, the organization could leverage the fact that an individual has a DDA account as a lazy asset (created by banks) to streamline and increase the assurance of the identities of non-employees with whom it interacts.

Employee and Non-Employee Data

Another approach to minimizing risks and increasing identity assurance in the Enterprise is leveraging existing data about active or departed individuals, whether employees or non-employees. The idea here is to leverage information that has already been captured and used about individuals to mitigate risks at the point of entry (i.e., on-boarding, registration).

I was introduced to this concept in 2007, through what is known as NORA (Non-Obvious Relationship Awareness). This technology mines data resources to determine relationships between people. As Tim O'Reilly explained, it has applicability in various real-life scenarios. I later had the chance to meet Jeff Jonas at a presentation on the topic of identity resolution. I was really amazed by the power and applicability of this approach. It leverages existing data assets that organizations may already have (but may not be leveraging in this way), to detect potentially risky individuals based on known data traces that indicate high risk.

Rumor has it that NORA was the technology used to catch the MIT Blackjack Team. For those who don't know them, they're a group of students and alumni from the Massachusetts Institute of Technology, Harvard Business School, Harvard University and other leading colleges that used card-counting techniques and more sophisticated strategies to beat casinos at blackjack worldwide. This was the inspiration for the movie "21".  Some believe this approach is being leveraged by intelligence agencies worldwide in fighting terrorism and organized crime.

NORA or NORA-like technology has matured and is available today, allowing organizations to easily determine who to let in and who to be weary about. Scenarios that immediately come to mind include re-hires, employee-to-contractor moves and vice-versa. Organizations can look back in history to determine if the same individual (or someone closely related) performed fraud, was fired for cause, or had some sort of "unpleasant" departure. At a minimum, having the ability to detect and handle these cases as exceptions could significantly help the organization mitigate possible risks by leveraging information assets it already has.

These are just three, poorly digested examples of how "lazy" assets that most organizations already possess can be leveraged to derive more value in IAM today, at a nominal cost. This approach can prove beneficial given the budget-constrained, fraud-riddled times we live in.

I am most interested in your comments.

Identity Activity Monitoring

Share

 

For some time now, we have been talking about identity activity monitoring. I alluded to it in a previous blog post. I will elaborate on it here.

Earl Perkin's recent blog posting discussion about the intersection between IAM and Security Information and Event Management (SIEM) was very insightful in shaping up this blog post. Especially his statements that the "links between IAM and other disciplines within IT become better defined and richer."

What is Identity Activity Monitoring?

We define it as an approach to identity management by which the organization can gain visibility, albeit on a read-only basis, on what end users are doing within its IT environment by correlating various traces of activity related to these users. This correlation is predicated on the accuracy of the organization's mapping of different identity attributes across the various IT assets that are tracking activity, which in most cases will mean the accuracy and quality of your identity data or your user directory. The latter is a good predictor of your IAM program's effectiveness.

Identity activity monitoring, in most cases, provides a complementary [and non-abrasive] value to an existing IAM infrastructure. From a business standpoint, it enables organizations to derive value from existing "lazy" information assets such as application and system logs. Therefore, it is conceivable, and often advantageous, for an organization to start with an identity activity monitoring initiative before, after or even in parallel with an identity provisioning or access recertification initiative.

Identity Activity Monitoring and time-to-value in an IAM initiative

In working with our clients in various industry verticals, we see identity activity monitoring as a strong trend gaining momentum in the marketplace. It can accelerate their ability to meet compliance related objectives, and significantly mitigate insider security threats by leveraging information assets they already own, even if the controls for managing user access to systems is not automated. This translates into a higher time-to-value for an IAM initiative, which is one of the most important indicators in a successful IAM initiative: how long before you can realize value and meet meaningful business objectives. I will illustrate this point with two examples:

1. In our experience implementing provisioning solutions, our clients have been driven primarily by compliance-related requirements: enforce timely terminations, implement access recertification cycles for critical systems or applications, and streamline internal or external audit needs. Many of our clients' critical systems are either homegrown or legacy, which means that seldom does a commercially available IAM solution that can integrate (out of the box) with it exist, from either a provisioning or access control perspective. In most cases, this means that we need to develop a custom integration for those systems. In the worst case, it means accepting that the system will need to be managed manually from an IAM standpoint. Either way, additional time and effort are required in the IAM implementation process to account for the custom integration work, the change management process and the manual labor supplementation required to effectively reconcile and report on the identity-related activity in that critical system. An identity activity monitoring solution could shorten this time and provide an interim or permanent solution assuming that:
1. The critical system is able to produce logs regarding the user activity it sees.
2. The user directory has a 1-to-1 mapping between the unique identifiers within the critical system and the enterprise identity entry for an individual (i.e., the system's unique ID is kept in an attribute in the user directory entry), and
3. [Ideally] the critical system can log administrative-type operations (such a new account creation, account termination and privilege changes on an account); all of which are often very realistic assumptions. A solution could be implemented which harvests and correlates these logs and produce reports on on-boarding, termination and privilege assignment activity. Identity activity monitoring will help the organization meet their compliance requirements more quickly, meanwhile it devices a more permanent solution (if appropriate) for how to bring this critical system under IAM governance.
2. In the energy sector-especially in NERC CIP and FERC- we have identified a few use cases where identity activity monitoring is the most optimal (if not the only) way to meet specific requirements:
1. NERC CIP requirements around timely termination of access are, as of January 2010, enforced by financial penalties that can be up to one million US Dollars per day. The requirement is that your organization needs to demonstrate that they can terminate logical access to NERC-regulated systems within 24 hours of that access no longer being required (i.e., an employee termination). With identity activity monitoring, organizations can track activity through logs and report on termination events, even if the actual process of terminating the account is done manually. With this ability, it is possible to tackle more applications and demonstrate compliance much faster than deploying a de-provisioning IAM solution, which will require connectors to all NERC-regulated systems, many of which are legacy.
2. In the electric side of the energy sector, many organizations are involved in the generation, transmission, distribution and trading of power. FERC regulations require segregation of duty (SoD) - employees of one side of the business and the other should stay physically and logically separated, and that in the event of transfer, prior access (both physical and logical) needs to be removed immediately to avoid conflicts. This creates two distinct use cases for identity activity monitoring:
1. The ability to demonstrate and report that access to prior systems by the employee has been removed in a timely manner (even if done manually).
2. The ability to monitor physical access events and correlate them to logical access, such that if a user from one side of the business swipes an access card on a facility (referred to as "probing" in the NERC CIP requirements) on other side of the business. This event can be immediately captured, reported and acted upon. There is no practical way to achieve this in a traditional IAM system, as they rarely ever integrate with the Physical Access Control Systems (PACS).

There are a number of other use cases that identity activity monitoring can address, including:

• Monitoring and de-normalizing usage of shared accounts, especially in legacy systems.
• Measuring near real-time per user risk based on behavior, say based on role (trader vs. comptroller), status (user has given a 2-weeks resignation notice), time of day (Saturday at 2 AM local time), location (from home or at the office), etc. This risk could also be aggregated into a role or departmental level.
• Identifying potential fraud by correlating activity patterns (i.e. someone swipes a badge at a site, but is also accessing the network through VPN at nearly the same time).
• Catching possible SoD violations as they occur, even if they are supposed to be prevented.
• Detecting manual overrides by administrators of critical systems, which may go under the radar of an IAM reconciliation cycle, as they may occur only in short windows (i.e. hours).

Bottom line

Identity activity monitoring is an emerging, pragmatic approach to addressing IAM business objectives. After 12+ years in IAM, my conclusion is that most IAM solutions have been conceived from an optimistic, top-down perspective. That is: if everything works according the plan, and follows the established processes and procedures, then what the IAM solution reports should be accurate.

But in practice, this is never the case. There are always exceptions and manual overrides, and often "back doors" that may not be caught. Besides, IAM systems do not often touch or integrate with all critical systems.

Therefore, leveraging system level monitoring tools, which are conceived for pessimistic scenarios and have a bottoms-up approach provides, what in control theory and industrial process automation is referred to as a feedback loop (i.e. the sensor) to the IAM control (illustrated in the diagram below, which I borrowed from Wikipedia). This approach may prove cost effective, particularly if your organization is already collecting logs and has implemented a SIEM solution.

A Windfall for Identity Assurance

Share

 

First off, I would like to would like to express my sympathy to those affected by the terrible earthquake that hit Chile this past weekend.

Envio mi palabra de aliento y de optimismo al pueblo Chileno. Tengo muy buenos amigos Chilenos y a todos les deseo lo mejor en vista de estas circunstancias, a sus familias y a todos los afectados... Las cosas de Dios son sin duda alguna indescrifrables.

In this blog post, I would like to share with you some recent developments in the world of identity assurance, which as you know from my recent blog posts: "Identity Assurance, an everyday life issue" part 1 and part 2, is a top of mind issue for me and for us here at Identropy. Quite frankly, I could not hope for better timing for these blogs to come about.

On Friday February 26th, 2010 the US Federal Government's Identity, Credential, and Access Management (ICAM) Trust Framework Evaluation Team (TFET) reviewed Kantara Initiative's latest submission and granted it Provisional Approval as a Trust Framework Provider at Levels 1, 2 & non-crypto Level 3 under the Open Identity Solutions for Open Government program.  The removal of the provisional status will hinge on the release by TFET of additional guidance for assessors concerning privacy and Kantara's adoption of this guidance.  

This is for me an extraordinary milestone, not only in my role of Chair of the Identity Assurance Work Group, but as an identity assurance activist altogether.  Kantara submitted its application for the US Federal Government adoption of the Identity Assurance Framework (IAF) in November of 2009. Prior to that date, the IAWG has been working very hard, collaborating with Kantara and the Assurance Review Board (who oversees the Kantara Initiative Identity Assurance Certification Program) to achieve this important goal (albeit still under provisional status).

The significance of this milestone is that it represents an important step towards fostering the adoption of identity-enabled Government services at known levels of assurance, relying on identity credentials issued and managed by non-Government parties (referred to as Credential Service Providers in the IAF). It will create the right conditions for the certification program to be adopted in real-life scenarios and for the industry to benefit from a proven, best-of-breed certification program that effectively enables interoperability and trust. This means that the IAF will not be just a "paper" standard, incarnated in a compendium of documents, but an actual technology-agnostic program that organizations can certify against.

With the adoption of risk-based models, identity federation can achieve Internet scale, and facilitate public access to online information at specific levels of assurance.  With adoption will also come economies of scale and further collaboration and interoperability across industries and Governments.

As someone who has been involved in identity management and identity assurance for quite some time, I cannot help but feel excited about the times I live in, and optimistic about what is to come.

I do anticipate and hope for more endorsements of the IAF in the near future by other organizations, and more importantly, the start of a paradigm shift in the way we all think about identity, both within the Enterprise and in a federated environment.  Ultimately, this path will allow the identerati to focus on the real end goal: delivering identity-enabled solutions and services with the level of trust and confidence that is appropriate for the transactions being performed.

But this is just a first step...

Identity Assurance, an everyday life issue (part 2 of 2)…

Share

 

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.

Advice: 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...

Identity Assurance, an everyday life issue (part 1 of 2)…

Share

 

In this 2-part article, I hope to explain the importance of identity assurance in everyday life. I will first level set on terms and definitions in part 1, and then illustrate with real-life examples in part 2.

The notion of identity assurance is to establish, with a level of certainty, that the human being represented by a credential in an electronic transaction is in fact the alleged person. Whether you realize it or not, whenever you perform an electronic transaction, you are making some kind identity assurance tradeoff.

Identity assurance does not only apply to scenarios in the extranet in which consumers or users from one organization interact with systems in another. It also applies within the enterprise where you need to view identity lifecycle management holistically, as opposed to fragmented steps, such as provisioning, authentication, single sign-on, etc.; and how they contribute to creating and maintaining identity assurance.

My Personal History

In late 2006, I was first introduced to the issue of identity assurance as a trend in identity management.  It all started with the FFIEC's October 2005 guidance on Authentication in an Internet Banking Environment. It appeared on my radar as I was strategizing on the future of web access management and the product portfolio for which I was responsible. I was also wrestling with transaction assurance and access management 2.0. At the time I did not realize the profound impact that this concept would have on my career.

In late 2007, as I was managing a high-assurance digital identity service offering at a large global bank, I was introduced to Liberty Alliance Identity Assurance Expert Group. I joined the group as a co-chair which led to my current role as Chair of Kantara Initiative's Identity Assurance Work Group that is responsible for the Identity Assurance Framework. It works closely with the Kantara Initiative Identity Assurance Certification Program, which actually instantiates the framework in an actual program.  So, I guess you can say I have become an identity assurance activist.

It's All About Risk

In any electronic transaction where a human is represented, an implicit identity assurance tradeoff is made. A human may be represented in a transaction by providing a user name, email address, or simply by checking off a box accepting certain terms and conditions. The question is whether we are aware of or comfortable with the tradeoff. In all instances, you and the party with whom you are transacting are agreeing that your identity can be representing in this way for this transaction, and accept the consequences of what might happen if something goes wrong (i.e. your credentials are spoofed or compromised, or you chose to share your credentials with somebody that acts on your behalf and does something wrong).

The higher the sensitivity of the transaction, the higher the confidence (i.e. assurance level) you would like to have.  Therefore, an identity assurance level (AL) should map to the risk level in any given transaction.

All identity assurance documentation that I have read or been involved with converge on four basic levels of assurance:

• Level 1: Little or no confidence
• Level 2: Some confidence
• Level 3: High confidence
• Level 4: Very high confidence

OMB Memorandum M-04-04 illustrates this rationale from the perspective of the US Government. It effectively explains the application of identity assurance to transactions, considering the impact of something going wrong, and also the expected frequency of its occurrence. Below is a table I borrowed from this document that focuses on authentication.

Advice:  Be aware of the sensitivity of a transaction. Think through the mechanism employed to mitigate risk and if it is sufficient enough to convey the appropriate level of confidence. Consider the intersection of identity assurance with your data and risk classification.

It's Not Just About Authentication

Another important realization, particuarly for me given my background as a product manager, was that identity assurance is not just how strongly you authenticate someone. A number of factors come into play. Moreover, identity assurance, like other facets of identity and access management (IAM), is a lifecycle process.   An identity lifecycle includes stages ranging from registration (initial creation, identity verification, credentialing) to contextual access control (authentication, risk and activity monitoring, stronger authentication), renewal and termination.

An IAM solution must account for the fact that identity assurance decays over time and that lifecycle processes, such as renewal or termination, are necessary to either preserve the assurance level or eliminate the risk of a compromised identity.

Even though this concept may seem obvious, traditional IAM deployments do not incorporate identity assurance as a guideline, and thus rely on a static notion of identity.

This approach towards risk and identity assurance allows end users and organizations to gain trust in relying on online channels to conduct sensitive and higher-value transactions.

In my next blog post, I plan to illustrate these concepts with some real-life examples. In the meantime, I look forward to your comments...