Blog

Advantages of a Hybrid Co-Sourced IDaaS Model

Share

 

Earlier this year, I published a blog article entitled Approaches to Identity-as-a-Service (IDaaS) for Enterprise Identity Management.  In this article, I will focus on the advantages of one of the approaches discussed: co-sourced IDaaS (a.k.a.  identity management co-sourcing), and, more specifically, the 3 model or "Hybrid: on-premise and in the cloud".

Motivation

So, why focus on this hybrid co-sourced IDaaS model?  I predict this model will become the de facto approach to Identity and Access Management (IAM) in the future (in two years or so).  Here's why:

1. It provides an approach that is more palatable to the organization. It doesn't take everything to the cloud, or turns everything to a Managed Identity Service Provider (MISP). Rather, the organization will have options for how many, and which services, can be migrated to the cloud. This will resonate better with risk, security and compliance officers, who may have some reservations about the migration. It gives them time to get more comfortable with the MISP.
2. The model allows for more flexible integrations with internal identity assets, such as Active Directory or HR databases, which might not even be exposed to the cloud due to risk concerns. Having an on-premise footprint alleviates these concerns, and provides for an enforcement point in which data can be filtered, secured and transmitted with the appropriate level of risk mitigation. Likewise, this approach avoids the undesirable side effect of exchanging data files (typically via batch), which then increases the risk of data being leaked. The on-premise footprint (or appliance) can implement a message-driven data exchange model with the internal Identity repository and with the cloud-based Identity service.
3. From a connectivity standpoint, the on-premise footprint (i.e., the appliance) provides secure communication with the Identity service through the public or private cloud. It may provide caching and queuing to increase the reliability and responsiveness of the service and build high-availability and load-balancing logic, making it easy to determine with which Identity service to connect (provided the Identity service is deployed in a highly-available and hot-swap disaster recovery architecture).
4. Architected properly, it allows the MISP to scale its managed service model by being able to funnel existing and new services that can be offered to the same client by leveraging the existing architecture. In other words, adding a role management service onto an existing user provisioning service would not require deploying another appliance or opening new ports in the organization's network to be able to provide the service. The on-premise appliance would be able to syndicate these services transparently. This translates to less overhead for the organization (no additional burden on IT or the auditors) and for the MISP (no additional appliances and re-architecting needed)
5. It still achieves the goal of simplifying and reducing the IT footprint that the organization would need to deploy and maintain.

The Business Side

From the organization's standpoint, the co-sourced IDaaS model, in general, can alleviate the need for:

• selecting, purchasing, and depreciating IAM technology
• building, maintaining, and operating the IAM infrastructure
• customizing and integrating various products
• staffing, training, and retaining personnel to manage the IAM environment.

All this immediately translates to cost savings.

The MISP is responsible for building, integrating, deploying, and operating the Identity service that suits the organization's requirements.  This approach will reduce upfront costs (not needing to procure hardware and software, and their respective maintenance annuity), which are now blended as part of the managed service "lease."  Likewise, by not having to recruit, train, and retain specialized staff to operate the environment, the model expedites deployment timelines and reduces operational costs and risks to the organization.

In this approach, the MISP is involved in the delivery of the IAM solution, which is then governed by established parameters and service standards (i.e., SLAs).  Whether it's hosted on premises or outsourced (in the "cloud"), in the end, the organization sees immediate and measureable value for the services they purchase-in a predictable and simpler manner.

For the MISP, the need to reduce the implementation timeline and create the capability of a repeatable model forces it to streamline the deployment process and ensure that it is done with such quality that its' operation after deployment requires minimal involvement.  In the end, these elements accelerate time-to-value.  In a past blog post, I discussed time-to-value as one of the key points to consider in any IAM initiative.  It is a metric that is often overlooked - everything being equal you should look to shorten time-to-value for the organization. 

The MISP will be motivated to shorten and streamline implementation so clients can consume its Identity service(s) much more quickly. Clients will also be able to scale operation and profit from the MISP's efficiency. This distinct synergy in the co-sourced IDaaS model is worth noting: both parties, the organization and the MISP, are motivated to reduce the time it takes to be up and running.  This is why we believe that this deployment model will succeed, as it aligns more closely with the interests of the parties involved.  Moreover, the need to shorten the implementation timeline and create the capability of a repeatable model forces the MISP to streamline the deployment process and ensure that it is done with such quality that its operation after deployment requires minimal involvement.

The charts to the left compares, at a very high level, a typical flow of value and cost that occur in a timeline between the two models,  and illustrate why the co-sourced IDaaS model will exhibit a shorter time-to-value.

Furthermore, for current IAM initiatives, there is no longer room for soft ROI; hard dollar is king. Organizations need to think about how to measure value and ROI from IAM.  We see that in a co-sourced IDaaS model these metrics can be easily tracked and gauged at any given point in time.

Organizations can also benefit from implementing charge backs from IT to other internal organizations to effectively determine TCO, and possibly ROI, and from shifting their expenditure from capital to operation expense.

In the end, from a business standpoint, the MISP and the organization engage in a long-term contractual relationship, jointly committed to successfully operating an environment with tight controls on scope and complexity.  The net result is that the client measures value immediately and continues to see value on an ongoing basis, through relatively simpler and more transparent metrics.

I hope these points are thought provoking. Your comments are most welcome.

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

Managing IdM, Unique or Just Plain Vanilla

Share

 

I recently read a number of posts where managers were fighting it out about how unique an Identity Management Project really is and sometimes I truly think that people forget that this is an Enterprise Implementation with many diverse moving parts. Dealing with an entire enterprise no matter how small the subset of users brings a large number of difficulties that could lead even the best of project managers to lose their hair. 

The most successful managers have a combination of soft skills, analytical skills revolving around business process management and a high level understanding of security and directory technologies. Some would consider these skills plain vanilla but when you disect each deliverable sometimes being dependant on so many areas which you have no control over and the task of plotting out deliverables such as connector development which will have end user visibility only when workflows or other features are in place leads me to think otherwise. These constant transitions could be quite tricky and from the way I see it could be considered quite unique.

In a nutshell the conclusion on all of the posts was that IdM Projects are unique but so are projects in other industries.  Basically paraphrasing an old saying..."if you have to ask how much something costs you probably can't afford it" just the same as if you have to ask why an Identity Management Project is unique...

Identity Management Project Scoping, Part II

Share

 

In my last entry on Identity Management Project Scoping, I wrote about putting together a "PUT" chart, and creating Business Process Correlation sets. If you have been following along, at this point you should have a pretty telling matrix of processes, user populations and target systems, along with correlations and priorities.

Here is the next step...

Step 3: Provide a Non-Technical Description of Each Process

This one could be a bit time-consuming, but well worth it. For each Business Process Correlation Set, provide a short non-technical description of the process flow from beginning to end. For a more detailed method of describing the workflow, create a table that follows the template below (a sanitized example from one of our clients):

...

 At the end of this excercise, you should have a pretty good handle of what business processes you are looking to automate, the target systems, the user popuations, the priorities, and a good grasp of the process as it stands today.

Typically, the total set of data that you have completed will need to be broken down into a phased implementation.  An Identity Management Consulting firm should be able to guide you in the process of translating the results of the scoping excercise above into an Identity Management architecture, help you find a solution that works for your specific requirements, as well as help you put together your very own Identity Management Roadmap (yipee!).  All fun stuff, and good practice when engaging in an Identity Management project.

Identropy's Identity Management Solutions 101 Series

Share

 

Our goal is to keep you informed and highly educated on identity management solutions, trends and business.

Identity Management Solutions 101: User Provisioning 

Identity Management Solutions 101: Password Management 

Identity Management Solutions 101: Enterprise Single Sign-On 

Identity Management Solutions 101: IaaS (Integration as a Service)  

Stay tuned for more sessions about topics such as Deprovisioning, Cloud Computing, SOA and others.

Identity Management Workshop: Critical Ingredients

Share

 

An Identity Management Workshop can be a fantastic way to start an IdM Project - if it has all the right ingredients.  Unfortunately, with the wrong ingredients an Identity Management Workshop could erode the valuable goodwill of the participants, making the critical starting phase of your Identity Management project all the more difficult.

We've compiled a checklist of some of the right ingredients for a successful Identity Management Workshop. Enjoy!

Give Yourself Some Prep Time 

Prep time means gathering some information about your Identity Management initiative such as business drivers, technical drivers, high level business processes, budget parameters, current technology infrastructure, resource limitations, etc. If you get your hands on a Pre-Workshop Questionnaire, spending time with your team filling it out should help unearth some valuable information and help you set your parameters.  

Heaps of Stakeholder Participation 

A workshop should not be an IT-only initiative (since IT-only Identity Management initiatives tend to fail). The appropriate representation from various departments and business segments of your organization will ensure that the discussions will be balanced and couched in terms of real-life business processes.  Do your level best identifying the stakeholders that should be present, and who in your organization best fits those roles. 

A Pinch of Skepticism and a Bunch of Conversation

Too much skepticism can be a barrier to communication, but just a pinch might enhance the conversations during the Workshop.  A few things to be skeptical about:

• A one-size-fits-all solution
• A 6 month roadmap
• A lecture (the value of the workshop is the conversation it initiates)
• Someone trying to sell you something. (This should be about your organization, not an "offering"!)

Mix in Some Business Processes Analysis

At the heart of an Identity Management project is enhancing identity-related business processes. The absolute wrong way to begin analysis of your environment is to start talking about data synchronization and go up. Start by analyzing the relevant business processes, then analyze how they impact the systems/applications in your environment, and finally analyze how those interactions impact the underlying data.

But Hold the Software Vendors

A workshop led by an Identity Management software vendor will most likely lead to skewing your requirements to match the vendor's capabilities.  It would be more appropriate to use a neutral third party Identity Management Consulting firm that can help you unearth and refine your requirements first, and then provide you the relevant information regarding vendor capabilities to help you make an informed decision.

So there you have it. I'm sure we missed something, so feel free to add in the comments section!