Blog

Identity Activity Monitoring

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

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 Busy Week at Both HIMSS and RSA Conferences

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

 I am just returning from a week of travel and conference activity, which start for me in Newark, NJ on Monday March 1, from there to Atlanta, GA for the HIMSS Conference 2010 (north of 25,000 attendees), and then on to San Francisco, CA on Wednesday March 3 for the last 2 days of RSA Conference 2010 (about 16,000 attendees), and then back home in NJ on Friday March 5. In all, last week was very busy but very productive for me.

It was good to see a lot of familiar faces as well as new ones, and to see that despite the economy, both of these conferences seem to be well-attended, with tons of vendor participation, and great sessions all around. Maybe this is an uncommon economic indicator (worthy of mention in the NY NPR radio show by Brian Lehrer). This time around I must confess that I spent most of my time outside of the conference session and exhibits meeting with colleagues, prospective customers and friends. For me, this was one of the most productive conference trips I've had in a few years.  Since my focus is always on identity and access management, it is exciting to see the convergence of business [and in many cases technical] requirements and various trends across industries, which drive the need for identity and access management as both an enabler and risk mitigation approach.

At the HIMSS conference, a theme that was very top of mind was "meaningful use" which is driving a lot of vendors and healthcare providers towards electronic health record (EHR) technology, and specifically, the 45 CFR Part 170 specifications. It is clear the US Government incentives for those providers (both professionals and hospitals) that can demonstrate adherence to the meaningful use guidelines is generating momentum.

I had the opportunity to present at HIMSS, thanks to our partner Novell. My topic was "Identity Assurance in Healthcare: what does it mean to you?" (below is my slide deck)

While the 45 CFR Part 170 criteria was published on December 30, 2009, it is interesting to see that at the heart of the requirements regarding authentication, specifically §170.210 "Standards for health information technology to protect electronic health information created, maintained, and exchanged", is the issue of identity assurance, which was captured very cleverly in the 1993 New Yorker cartoon by Peter Steiner, where one dog with a paw on a computer's keyboard tells another: "On the Internet, nobody knows you're a dog".  For well over 15 years, this very issue: knowing, with certainty, who is at the end of the keyboard, has been one of the biggest challenges in the enablement of true paperless transactions and trusted online services in all industry verticals. And healthcare has been no exception.

Inevitably, these requirements and standards will impact the way healthcare information systems will operate and interconnect, whether they are new or legacy, and inaction will most likely not be an option.

A Windfall for Identity Assurance

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

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

Why Do Most IAM Projects Fail? (Hint: Lack of Executive Sponsorship!)

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

In continuation of my last post about the "business" aspects of an IAM project, this post will discuss two of Mark Dixon's "Ten Best Practices for Identity Management Implementation." Specifically, points 2, "Secure Sponsorship" and 4, "Select Project Leadership".

Projects, by their very definition (according to the PMI), require a sponsor. After all, the sponsor authorizes the execution of the project and funds it.  So without a sponsor, you don't officially have a project. But, if you dig into Mark's point on sponsors a little deeper, you'll see that there's more involved in being a sponsor than just funding the project and showing up when it's complete. Indeed, if you have a complex, enterprise wide IAM project, this model of Executive Sponsorship will certainly protect your project should it encounter turbulent waters that may well sink it. While it isn't your Executive Sponsor's responsibility to directly manage the project, he or she must be involved enough to provide the necessary leadership to the Project Manager so he or she can successfully navigate the many diverse challenges and obstacles in implementing a IAM solution.

In today's IT environments, it seems we're constantly on the move; updating the company's key applications, replacing old hardware, or putting new security measures into place, etc... Because our environments are in constant flux, it can be particularly difficult to successfully implement enterprise wide projects that are also cross functional in nature. This potent combination, competing agendas and uncertainty, make enterprise IAM projects more complex from the onset. Strong Executive Sponsorship is required to overcome the obstacles that seem to come built-in with an IAM solution.

On the other hand, poor Executive Sponsorship makes a tough environment for your project significantly more difficult. In an informal poll I conducted of IAM and Project Management professionals - colleagues with many years of experience in the field, the fall-out from poor or absent Executive Sponsorship is clearly seen. It typically results in a lack of visibility for your project, a reduced priority among the sea of competing initiatives, failed escalation paths and a strong potential for cost overruns. As a PM, you must ensure your Executive Sponsor understands the full scope - from a technical and business process perspective - of your IAM implementation. The Executive Sponsor must know where the potential troublespots are and where leverage is needed to "move" obstacles to the project. Often, Executive Sponsors will appoint a representative from senior management to act in their stead. As a PM, ensure he or she is involved in your project and is apprised of risks and issues on an on-going basis and able to take action and act effectively. Ideally, as PM's, we must be aware of the "quality" of leadership we are getting from our Executive Sponsor and the resulting impact - good or bad - to our IAM implementations. It is our job to keep them apprised on a regular basis and to provide that information in a format easily consumable by Executive Sponsors. Think Red-Yellow-Green (RYG) charts, regular status reports etc...

By taking proactive action to keep the Executive Sponsor informed and in the loop, we can significantly improve our odds of a successful implementation.

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

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

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 Management Words of Wisdom in 4 Words or Less

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

Working on a Sunday, and I decided to take a break. While procrastinating going back to work, I started thinking about how effective pithy advice can be.  In the spirit of doing more with less, I drummed up Identity Management advice in 4 words or less.  I came up with 38.  Leave your advice (in 4 words or less) in the comments section...

1. Roadmaps Before Design [tweet]
2. Start with Deprovisioning [tweet]
3. Recruit Evangelists Early [tweet]
4. Recruit Techies Later [tweet]
5. Get Executive Sponsorship Early [tweet]
6. Process Over Technology [tweet]
7. Provisioning is Hard [tweet]
8. Who's Gonna Manage This? [tweet]
9. IT, Don't Fly Solo! [tweet]
10. Stakeholders Are Your Friends [tweet]
11. Learn From Botched Implementations [tweet]
12. Virtual Directories Solve Problems [tweet]
13. Beware of Misleading POCs [tweet]
    
14. Automate Access Governance [tweet]
15. Socialize Business Drivers Early [tweet]
16. Manage Expections:Dollars Ratio [tweet]
17. PMs Need Tech Crashcourses [tweet]
18. Identify Risky Accesses Immediately [tweet]
19. Invest in Experience [tweet]
20. Data Cleansing's a Pain [tweet]
21. Identity Assurance is Coming [tweet]
22. Tech Rockstars are Invaluable [tweet]
23. Avoid Too Much Software [tweet]
24. Evangelize Your Vision Constantly [tweet]
25. SSO is Achievable, Really [tweet]
26. Resist Temptations to Rush [tweet]
27. Product Suites are Overrated [tweet]
28. Don't Skip Integration Testing [tweet]
29. Consider Managed Identity Services [tweet]
30. Make Attestation Multi-Layered [tweet]
31. Iterate, Practice Makes Perfect [tweet]
32. Pick a Good Partner [tweet]
33. Deliver Functionality Incrementally [tweet]
34. Investigate SIEM Integration Possibilities [tweet]
35. Leave Time for Training [tweet]
36. Respect Your End-Users [tweet]
37. Minimize Behavior Changing Processes [tweet]
38. Plan Strategically, Act Tactically [tweet]
    

So, do you have any brilliant identity management words of wisdom that can be summed up in 4 words or less? Let's hear them...leave a comment with your inventions...

[Thanks to Dharmesh Shah and his blog post for the inspiration for this entry.]

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

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

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

A Project Manager’s Take on Initiating an Identity Management Program

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

As a Project Manager here at Identropy, I've been given the challenge and opportunity to share my thoughts and experiences with you regarding Identity and Access Management from the eyes of a Project Manager with on-the-floor experience. While Ash has shared his expertise regarding IAM roadmap development and how to determine if your company needs one or not, and Frank has shared his thoughts on the direction of IAM-as-a-Service and where it's going and how it's evolving, I'd like to spend a little time in these first posts talking about the "business" side of IAM.

Ideally, my life as a PM of an IAM project starts where the IAM workshop leaves off. I am handed the organized findings of the workshop that include business drivers, use cases/general requirements, a high level architecture and Identity Management roadmap. My first order of business is always challenging: to orchestrate interview sessions with client stakeholders in order to create an RTM, or Requirements Traceability Matrix. A good way to define stakeholders is to think through the processes that were defined in the workshop, and identify all the "touchpoints" throughout your organization, for example HR, Support Center, Desk-side Deployment, System Engineers, etc., and begin to involve them.  (We also have a stakeholder definitions doc you might benefit from.)

For each of the interview sessions, prepare questions that can unearth (and differentiate) business requirements, functional requirements and technical requirements from the project stakeholders. It is absolutely critical to remember that the goal here is not to architect the solution, but rather to define just how big the elephant is. Don't let your organization be the blind man that defines the elephant based only on sensing the trunk or tail of the elephant.

For example, you might choose a self-service component of IAM to develop a use case that would walk through the process your end user will go through upon first logon after successfully being provisioned to a new LAN account. Using our first logon example, we would expect the Support Center would have requirements for the process related to delivery of the initial password, or perhaps what information is relayed to the user regarding Support Center services. We would expect that your HR department might have a requirement of the process that the user not be able to logon until they have been fully processed in the company's HR system. Perhaps your Information Security team will have requirements that place certain constraints on how your end users are initially provisioned to various target systems. Each use case that is developed to meet the needs of your business drivers will have requirements. These requirements should be listed in an RTM to include the requirement itself, the originator and/or owner, prioritization and general summary of what business driver it can be traced to and how it addresses this driver. As a note of suggestion, requirements should be as succinct and discrete as possible. IAM programs tend to have many moving parts, and tracing requirements necessitates that each requirement be a discrete element. Following this advice may balloon the overall number of requirements you have, but increase your visibility and traceability, which is extremely valuable.

The importance of an RTM cannot be overstated. It directly feeds your Work Breakdown Structure (WBS) and will be invaluable down the road in your IAM project as a guide to the scope of the program and who owns which requirements.

Lastly, I benefited from a few blog entries on the subject in the blogosphere I'd like to share:

10 Best Practices for an IDM Implementation by Mark Dixon

2 Approaches to IDM Project Methodology

In our next discussion, we'll continue discussing the business aspects of an IAM solution and the pitfalls/roadblocks your company will need to look out for in order to increase your chances of a successful implementation.

Considerations for an Identity Management Initiative in 2010

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

First off, I would like to express my sympathy to victims of the terrible earthquake that hit Haiti. I can only wish that the rescue and recovery efforts yield positive results.

Thanks to the recession, we have learned a lot (or so we would like to think) on the importance of sound business decisions, have we not?

This blog post is my attempt to bring some of the lessons learned, along with scar tissue, that I have been able to sum up from the last 24 months, as it relates to identity and access management initiatives. Last year, I spent time reading some Harvard Business Review articles, and recall reading a blog post titled: "6 Lessons Learned in the Downturn" by Anthony Tjan, which were very influential in shaping my thoughts for this post.

At the risk of stating the obvious, I would start by saying that the last 24 months have forever changed the way in which Identity initiatives will be carried forward.

It is clear that identity and access management systems are, more than ever, critical parts of any IT infrastructure. Organizations will always need to grant application and system access to those who need it and eventually remove that access once it is no longer needed. This is a recession-proved observation. The circumstances of today's economy highlight the need to tackle these activities in a more efficient, transparent and scalable way, and in most cases, automation is about the only choice you've got. Manual labor is way too expensive today, even when outsourced. This should be an encouraging statement for any identirati.

5 Lessons Learned

Below are five points that best capture the essence of this change.  These are based on experience working with clients across many industry verticals:

1. Your dollar needs to go a much longer way than before - If you even have an approved budget, you really need to maximize the value you will get from your initiative, and be ready to show how. Consider getting a second opinion before you buy new IDM technology. Ask yourself some questions:
• Have you done proper due diligence?
• Do you or your team have the cycles to invest in carrying out the proper due diligence?
• Are you relying only on what the vendor says or what you read on an analyst report?
• Do you have enough insight on how to negotiate with the vendors you have selected, based on what is important for your initiative?

We have seen from experience that even a nominal 2-week investment in an Identity Management Workshop that assesses your current state, identifies business drivers, high-level requirements, and formulates an implementation roadmap can go a long way.

A case in point: One of our clients allocated $750,000 in budget to acquire IDM technology in 2009.  Before moving forward, they invested in a workshop and in the end, identified a set of previously unknown requirements and ultimately saved 40% ($300,000) in their purchase, all within 8 calendar weeks. Considering what they spent on our services, this is an ROI in excess of 450%. Not bad in any type of economy if you ask me.

2. Minimize capital expenditure if you can - Consider lease vs. buy scenarios. The maturity of IDaaS today provides options for customers to avoid procuring software and hardware products that require capital expenditure, and instead consume them on an on-demand basis as an operating cost. This of course will maximize your cash-at-hand. Evidently, not all of your identity and access management needs can be met with an IDaaS approach, at least not today, but I would argue that 24 months ago this was not even an option to consider. There are several approaches to IDaaS, which can be appropriate to your initiative. It may be worth exploring these and engaging with providers that specialize in these kinds of models. Not all organizations are ready or comfortable with an all-in-the-cloud approach, but there are managed services models that work on-premise that should be explored.
3. You have to have metrics - For identity and access management initiatives, there is no longer room for soft ROI; hard dollar is king. As you define your Identity initiative, you need to think about how you can measure value and ROI to the organization. For some organizations, which adopt internal chargeback models for managing budgets, this should be relatively easy. The idea is not to stop at simply measuring costs, but ensure that you are measuring returns. In a way, try to make your metrics meaningful to the lines of business that you support (i.e. your internal clients). A metric that is often overlooked is time to value - everything being equal in cost, you should look to shorten the wait until you can show measurable value to the organization. In practice this will help you decide how you undertake your initiative. Maybe shorter phases are better than longer ones. Perhaps rather than a pure waterfall project management approach, you start to introduce agile methodology concepts. We have seen initiatives whose budget is cut in mid-flight. Even though you cannot fully prepare for this, you want to consider what you will show for if it ever happens, and whether or not delivering value early is the key to preventing your funds from being cut in the first place.
4. Let's demystify identity management - This may get controversial, but after 14 years of experience in IDM, I would like to demystify it. I agree that IDM is complex, requires specialized skill sets, and above all, is unforgiving if you do not have the right experience, but at the same time it is not unattainable, and settling for less is not the right posture. There are many ways to meet compliance requirements, even if you have not automated all of the access granting flows in your environment.

I applaud the advent of identity activity monitoring (the term we like to use to describe this new trend) in 2009, and while the analysts have not yet coined a particular name for it, there is a great report by Gartner's Mark Nicolett and Earl Perkings that focuses on this area, separate from just SIEM or just IDM, more as a separate niche in its own right.

I intend to further discuss identity activity monitoring in a future blog post, but for now, I would describe it as an approach to tracking user activity in various IT systems and applications that is correlated to the definition of a digital identity; thus creating a closed feedback loop that allows you to more confidently determine if your IDM controls are effective, regardless of whether they are automated or manual. In this way, organizations have a way to extract value out of lazy assets (such as application, database or system logs), which otherwise are used only for security event monitoring, and leverage them to increase visibility into what users are doing within the IT infrastructure. This is a very clever and effective way to approach some of the compliance requirements that Identity initiatives often try to address, in a faster and cost effective way. Moreover, it does not conflict with a traditional IDM implementation, but rather complements it.

5. Understand and embrace identity assurance - this is not limited to scenarios in the extranet in which users from one organization interact with systems in another - scenarios that some would deem esoteric and not as business critical. Even within the same organization, you need to pay attention to identity lifecycle as a whole and not just as discrete steps: provisioning, authentication, single sign-on, etc. Consider the intersection of identity assurance with your data and risk classification, and 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? Strong authentication alone is useless from an identity assurance perspective (a good friend assures me that a well-trained Labrador could figure out how to use a smart card - although I have not seen the documentary on TV yet). 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.

To illustrate, here is a real life example: a client has a request/approval process in place to manage the issuance of access cards (with no picture ID) to various facilities in their organization. When an employee first comes on board, to issue an access card, they undergo a process of vetting their identity against information in HR, and that the request that has been 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, and literally keep them in a drawer. When a new employee comes onboard, the manager recycles the access card and increases the employee's productivity by orders of magnitude, 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 would love to hear comments and feedback on these points, particularly if you disagree.

Identity Assurance in the Nationwide Health Information Network (NHIN)... a cross roads of sorts

 digg it |  reddit |  delicious |  StumbleUpon |  Twitter 

On Thursday January 7, 2010 (last week), I had the privilege of representing Kantara Initiative, in my role as Chair of the Identity Assurance[1] Work Group (also proxying for the Healthcare Identity Assurance Work Group) as a panelist in the Nationwide Health Information Network (NHIN) Workgroup hearings.

NHIN focuses on the definition of standards, guidelines and specifications on both technology and legal areas to enable the secure exchange of health information over the Internet. The focus of last week's session was authentication.

It was a great experience for me, particularly given the significance that NHIN's efforts will have in the way healthcare services are provided in the US over the next few years. The session made it clear that we are reaching a convergence of various efforts in identity management, which have reached the maturity level needed to address very real and critical business problems, and that the time to execute has come. Many of these efforts have been evolving over many years thanks to extraordinary contributions and leadership in both private and public sectors. This realization conveyed a sense of purpose and responsibility that quite frankly was not evident to me until the session actually started. Yes, I realize that at times I get very existentialist.

The format NHIN adopted for the hearings was very effective. It started with a viewpoint from US Government panelists followed by two sets of private sector panelists (I was part of the last round).  My fellow panelists did a really good job of providing their viewpoints in a clear and focused manner, and engaging in a very productive and dynamic round of Q&A after each round. This format made the sessions more productive, covered a wide range of viewpoints, and also helped identify themes and synergies. I commend NHIN on this.

Transcripts of the entire session, including audio voice-over and written testimonies, are available online. Also, Kantara published my written testimony in their blog area.

In this blog post, I intend to provide my summation of the event, and speculate on its potential outcomes.

Salient points

1. Panelists discussed the definition of authentication and reached a common understanding. In the context of the panel, authentication consisted of three distinct processes:
   • Proofing or verifying an identity,
   • Issuing a credential to the individual once her identity was proofed, and
   • The real-time event of confirming the validity of the credential as a digital proxy of the individual during a digital transaction.
   GSA's David Temoshok clarified that this definition excluded authorization - the ability to determine the kind of operation or data the individual can access.
2. I believe that the various panelists, including myself, converged on the notion that different assurance levels, as defined by NIST SP 800-63, provided a proven and practical approach to addressing different transaction risk levels. They also agreed that there is not a "one size fits all" approach that can address the broad range of use cases in scope for electronic healthcare. The discussions centered around the need to classify transactions and applications based on the risk profile, and avoiding the polarization on the highest assurance level for most use cases since it may be excessive and overkill.
3. Some recommended to NHIN existing frameworks that have been in use and proven for many years should be leveraged, rather than creating a brand-new, healthcare-centric framework for authentication. Leveraging existing Government programs and partnering with private sector players will help NHIN reach its goals in a more scalable and faster manner. NIH's Peter Alterman recommended that NHIN avoiding creating a healthcare-specific framework, highlighting the benefits of adopting cross-industry, best-of-breed standards.
4. There were great discussions on how to pragmatically reach the adoption rate required for the programs that HHS is driving forward. I particularly enjoyed the perspective provided by David McCallie, from Cerner Corporation; specifically, the statistics that show that in their network of 8,000 facilities, ~2,100 hospitals, 3,300 physician practices, 30,000 physicians, 500 ambulatory facilities, 600 home-health facilities, and 1,500 retail pharmacies; less than 30% of the systems use any form of SSO, and that provided the choice, less than 10% of the system adopt any sort of strong authentication technology. David also explained some of the challenges involved in achieving interoperability and federation across disparate system which were not designed to cross reference, and how much effort is truly involved in effectively mapping identities across different organizations.
5. Peter Alterman pointed out that Assurance Level 3 (AL3) is the minimum required to protect transactions that may expose personally identifiable information (PII), according to the Privacy Act. Later, Anakam's J Brent Williams talked about the ability to provide AL3 solutions that can scale both in terms convenience and cost, which can reach high levels of adoption, and are already in use at some large Government internet facing services. SAFE BioPharma's Mollie Shield-Uehling, made good points on the use of antecedent identity proofing as a scalable approach to AL3 remote identity proofing, based on SAFE's experience in the pharmaceutical community. My viewpoint on this topic was that AL3 should be demystified from being unaffordable and overkill, to being more attainable nowadays, particularly with remote identity proofing options, as well as evolving options for two-factor authentication options that could leverage mobile phones as authentication devices.
6. Brent raised two very good points that are worth mentioning:
• There are scenarios in which being able to provide identity proofing at a specific level of assurance level, but not necessarily having to issue a credential at that level or at all, will be beneficial, especially in cases in which a patient is granting permission to a physician to access her own electronic health record.
• PKI and SAML based authentication should not be viewed as orthogonal or in isolation in the context of identity federation and assurance levels. They are different ways to conduct and carry an authentication event, but in practice, they are techniques for conveying an authentication token. The real challenge in federating comes after the token is consumed, and particularly how the identity is actually "enrolled" in the target application (relying party).

My thoughts about the outcome

This was a worthwhile session with valuable insights and a broad range of important perspectives that rarely get discussed in a single sweep. I am very optimistic about the direction that NHIN could take in the aftermath of this event, and my read on some of the deliberations by the NHIN work group following the hearing fuels that optimism. My hope is that we do in fact see the convergence of approaches in healthcare that will allow for a faster pace of evolution and adoption, rather than a separate, healthcare-specific approach to authentication that may prove too ambitious and demand much longer timelines.

Here are my speculations on what may come out of this:

• NHIN will not reinvent the wheel in the area of authentication, but rather provide guidelines that leverage existing programs, such as the Federal Government's Identity, Credential, and Access Management (ICAM). This direction will help NHIN to increase adoption and use of digital credentials at various levels of assurance, by partnering with both the government and the private sector, thus removing barriers to entry and immediately tapping into established networks and communities that already have large numbers of credentials issued. It will allow the programs to hit Internet-level scale much faster.
• NHIN will focus on mapping various use cases and transactions to specific risk levels, equating them to assurance levels. It will also provide specific guidelines that will foster the development and rollout of digital solutions that leverage identity assurance within healthcare. These guidelines will lay a foundation for interoperability and risk-based models for these solutions.
• NHIN will define minimum assurance level requirements for its most critical use cases. For instance, NHIN may require that physicians obtain at least one AL3 credential that complies with an accepted identity assurance framework to be able to digitalize common transactions. It may focus on scenarios in which a credential may need to be upgraded from one assurance level to the next.
• NHIN will define acceptable models for performing identity proofing conforming to assurance levels for its most common actors. The idea here will be to clearly define options available to a physician for getting their identity proofed prior to obtaining credentials; likewise, to define acceptable models for how patients will get identity proofed [and credentialed], whether it is a responsibility that can be delegated to the patient's physician or some other stakeholder in the use case.
• Several requirements that NHIN will define for authentication will help advance and evolve existing identity assurance programs both in the government and private sector, as there will be new services or more granular scenarios that will require special handling. Having said this, I predict that these requirements will not be specific to healthcare. Instead, they will have applicability on other industries. A good example will be the need to separate identity proofing from credentialing as consumable rather than encapsulated services.

I would love to hear your comments and feedback.

[1] Identity assurance, in an online context, is the ability for a party to determine, with some level of certainty, that an electronic credential representing an entity - whether a human or a machine, with which it interacts to effect a transaction, can be trusted to actually belong to the entity.  In the case the entity is a person, identity assurance is the level at which the credential being presented can be trusted to be a proxy for the individual to whom it was issued and not someone else.