Subscribe to our blog

Your email:

Posts by category

Blog

Current Articles | RSS Feed RSS Feed

Identropy Adds New Advisory Offering: the Identropy IAM Primer Series

Identropy adds a new offering as part of its well-known Advisory Services: the Identropy IAM Primer Series.  This offering not only provides access to Identropy's IAM best practices library, but also provides direct access to an Identropy IAM professional.

Our seasoned Identity and Access Management (IAM) professionals, each with over 10 years of experience in IAM, have created IAM best practices reference documents that capture practical and empirical knowledge in various aspects of the identity and access management landscape, spanning business processes and technologies. They are intended to educate IAM initiative stakeholders of industry best practices and facilitate their adoption in a cost-effective, self-paced manner, thus helping organizations improve their business processes by making optimal use of IAM.

In addition to the best practice documents, the offering includes five hours of direct access to an Identropy IAM professional.  Rather than read a static document, customers can also engage in a live conversation regarding the practical aspects of an IAM initiative. This approach will help organizations get started with a specific IAM topic with the practical hands-on guidance that is often missing in IAM initiatives, thereby leading to a more effective approach to adopting and implementing the solution specific to the customer's environment.For more information on this Identropy's IAM Primer Series, click here: http://www.identropy.com/iam-primer-series/

Getting Started with IAM Co-Sourcing: Operations Management (Part 2 of 2)

In part 1 of this two-part article, we provided the context and motivation for organizations to adopt a viable model for handling its IAM infrastructure operations. In this article, we will discuss options available to address this need.

What Are the Options?Insource vs. Outsource

Symptoms such as the ones described in part 1, indicate that your IAM operations are not optimal, and that perhaps your organization is not well poised to optimally run the environment.   They are also, entirely common to any IAM deployment of any size and scope; particularly, Enterprise deployments.  So what options do you have?

Here is what has been traditionally available:

  • Insourcingthis was the de facto option up to five years Insourcingago. The organization bit the bullet, hired expensive and specialized talent, trained these resources on the IAM product, invested in their ramp-up, often shadowing during the implementation cycle, and retained them to support, maintain and evolve the infrastructure.  For the most part, this model has only worked well at large organizations, which can afford having dedicated staff that can be groomed to take over the operations management role.  But for the majority of organizations, the operations staff is not dedicated and rarely has the right skill set and experience to take on IAM. For the most part, the resources are either too expensive or not available in the geographic location where [and when] the organization needs them. With luck, the organization will retain these resources long enough to realize a return on the investment, before seeing them go to an IAM consulting firm or an IAM vendor company.
  • Outsourcingthis option is more predominant nowadays. OutsourcingThe organization contracts with an external provider who assigns a support engineer onsite or remotely to look after the IAM operation. They are typically focused on break-fix and remediation of issues, not on the ongoing evolution and configuration changes to the IAM infrastructure. The experiences tend to be mixed according to what we have heard from customers:
    • On one end of the spectrum you have offshore outsourcing, which is great from a cost perspective, but is a nightmare from a cultural and organizational fit standpoint. There are varying degrees of overall satisfaction with the level of competency of these resources, and the effect of the time zone and communication barriers.
    • On the other end, you have the onsite consultants who work alongside the customer staff. This scenario tends to work better from a customer satisfaction standpoint, even though attrition is an issue. Cost tends to be high, making this a less appealing option to executive management.

The Answer, well... Our Answer

At Identropy, we propose a different model to address this need: IAM co-sourcing.

The idea is to have a mix of staff and technology working together to optimize the operation of the IAM infrastructure. This model is delivered as a co-sourced managed service that combines a lightweight on-premises footprint with a cloud-based backend to provide a best-in-class operations management solution for IAM infrastructures. The organization can outsource monitoring, reporting, maintaining and remediating issues in their on-premises IAM infrastructure via a scalable service that is governed by defined service level agreements (SLAs), managed by a team that specializes in – and has a deep pool of IAM knowledge to draw from – IAM infrastructure and delivery.

This model enables the organization to scale operation management of their IAM infrastructure cost-effectively and with sound IAM expertise, without having to increase their Operations staff.

How is this Different from Traditional Monitoring and Support Models?

Difference between support modelsThis co-sourced model provide much more than traditional system monitoring (i.e., monitoring that a system is up and running). It specializes in the IAM functionality that the customer cares about: Are events being synchronized to the target system?  Are the LDAP queries returning the expected values in the appropriate time? Are there events being queued up in a particular workflow? Is the Acces Request web interface available and can users log in to it?  Through a specialized correlation engine, it determines whether that behavior is abnormal for a given organization. All of these considerations go above and beyond pure system monitoring.

Additionally, the co-sourced model offers more than a break-fix service for issue remediation, since it also includes the notion of proactive up-keeping of the environment and incremental evolution, configuration changes, patching and preventive maintenance of the IAM environment.

It alerts customers when their IAM vendor releases a software update, whether a patch or an actual release. Which helps them stay on the upgrading or patching treadmill.

Lastly, it offers location independence for the IAM infrastructure, allowing customers to decide whether they want to host their IAM infrastructure in-house, or elsewhere, without trading off the operational efficiency they require.

Where to Go from Here?

Where to go from here?We believe that this model introduces a paradigm shift in IAM thinking, and one that makes the deployment location choice a moot point from an operations perspective, addressing the organization’s concerns with the ongoing support and maintenance of the IAM infrastructure. Hence reducing the IAM operational risk for the organization.

An organization can adopt this model today with an in-house IAM environment and evolve into a managed services, hosted model later on, all while preserving the operational efficiency it requires.

As we announced recently, we are introducing a set of Identity Services under the SCUID framework that provide specific IAM functionality in a co-sourced model.  All of these Identity Services hinge on [and include] SCUID Operations for operational management, which allows us to scale effectively and offer a cost-effective and SLA-governed service offering to our customers.

In future articles, we will discuss the merits and rationale behind some of the other services that are part of the SCUID framework. I would love to hear your thoughts.

Getting Started with IAM Co-Sourcing: Operations Management (Part 1 of 2)

For some time, we have been discussing the advantages of a co-sourced model for Identity and Access Management (IAM).  In this two-part article, I will focus on the first logical step for migrating from a traditional IAM deployment model towards a co-sourced, managed service model: IAM Operations Management.

Operations ManagementLet’s face it, while there are lots of merits to “ identity-in-the-cloud” services models, they are not yet a mature technology so organizations are somewhat reluctant to fully embrace and adopt them.  Another reason is many organizations today already have some sort of IAM footprint in their environment.  Therefore, for the foreseeable future, organizations will continue to deploy IAM infrastructures on-premise.  I use the term “on-premise” to also include – co-located or hosted IAM environments that are considered part of the “internal” IT environment or the organization.

For it to succeed, any new deployment model for IAM would need to provide flexibility and allow for the IAM infrastructure to be hosted on-premises as a starting point, even if it is managed remotely or delivered via an appliance-based model.  Forcing organizations to move IAM infrastructure off premises from the onset will most likely not succeed.

This flexibility is what we refer to as location independence – it does not matter where the organization wants to host its IAM infrastructure.

The Question

So, how can organizations start shifting from traditional IAM deployment models towards a co-sourced, managed services model in a location-agnostic manner? Our answer: start with a managed services approach for IAM operations management.

This is something we have learned, and validated from over two years of working closely with customers across various industry verticals, such as Government, Retail, Financial Services and Healthcare. A managed services approach to operating and maintaining the organization’s IAM infrastructure is very appealing.

This is what we offer through our SCUID (Secure, Co-Sourced, Unified IDentity) Operations service.  It provides a cost effective solution that enables organizations to optimize the operations and maintenance of their IAM infrastructure.

Symptoms and Behavioral Patterns

Over the years, helping customers implement their on-premise IAM solutions, we have learned that traditional deployment models for IAM have very common behavioral patterns once the deployment is transitioned into production:

  • Call for help - Most customers approach IAM implementations as projects, so once the implementation is completed, the Call for Helpteam is dissembled and the know-how is diluted. The implementation team, often an external consulting firm, disengages. Despite good documentation and knowledge transfer, the customer’s operational staff still ends up needing to ask questions about their environment.  For the most part this need is only realized during an emergency/outage or during a change [gone wrong]. In these cases, the operations staff calls on our consultants directly asking: “do you remember what was the command we used to make X happen?” “Which configuration parameter was the one I needed to change to make Y happen?”   These questions did not exactly go away over time but kept coming. This indicates that the organization may not be ready to optimally maintain and operate its IAM infrastructure.
  • Fall off the upgrade treadmill – When the IAM implementation is rolled into production, the software products involved are typically up to the current and recommended patch level.  But as with any software, and especially Enterprise software, the vendors release fixes and patches,Falling off the treadmill which customers then need to apply, and in some cases are required to, in order to continue to receive support.  Or worse yet, when an issue is found and the customer calls the vendor support desk, the first question from the support personnel is: “what version and patch level of the product are you running?”, and almost immediately after the answer, comes the dreaded: “you need to be on patch level X [typically the latest or thereabout]. Please apply this patch and call us back”. And voila, now the customer needs to make a decision: undertake the upgrading or patching on its own, or start a consulting project to bring in external expertise to plan and carry out an upgrade.  And in many, many cases, these decisions need to be made while the “house is on fire”.  Definitely not the best situation to realize that an IAM environment needs to be actively nurtured to stay operational.
  • Need to make minor changes – AfterMinor Changes the IAM environment has been in production for some time, customers’ needs evolve incrementally. A few weeks after deployment,
    • the approval group for a given workflow has to be updated,
    • a new user attribute needs to be added to the profile,
    • a new application is being integrated for provisioning,
    • a target system is being upgraded or patched and the provisioning connector now needs to be updated and/or reconfigured.

In most cases, these changes are reactive (i.e., the situation presented itself without much warning), and the impact to the interested line of business or stakeholder needs to be dealt with promptly (i.e., I cannot delay my ERP upgrade simply because you don’t have the provisioning connector for this version or it has not been certified by your IAM vendor). Now what do we do?

Has your organization experienced any of these symptoms?

In part 2 of this article, I will discuss traditional and new options available to addressing these symptoms.

Identropy Launches Innovative Co-Sourced Identity & Access Management Offering

Today, Identropy, an Identity-enabled solutions provider, announced the public availability of its co-sourced Identity & Access Management (IAM) solution platform known as SCUID (Secure Co-Sourced Unified IDentity).  SCUID is a co-sourced managed services platform that provides a complete suite of Identity & Access Management services that includes Identity Governance and Compliance and Identity Lifecycle Management services – all managed and monitored by Identropy’s services for IAM operations management: SCUID Operations (formerly iMIS).   The co-sourced services are built on pre-configured virtual appliances, that can be deployed either on-premise or hosted in Identropy's private cloud -- a SAS 70 Type II facility that is connected to the client’s infrastructure based on a secure site-to-site VPN connection.

"With SCUID Operations, we are able to achieve both multi-tenancy and location agnosticity for our IAM reference architecture. This allows our customers the flexibility and deployment options that makes the most sense for their IAM infrastructure, while SCUID Operations will monitor the solution regardless of where it is deployed," said Frank Villavicencio, Identropy's Executive VP.  "Our SCUID Operations customers in Retail, Government, Healthcare and Financial Services have benefited from this proven reference architecture that we have developed from over 100 IAM implementations."

The SCUID Identity Lifecycle service is built on Identity User Provisioning software with 8 pre-configured use cases spanning automated employee on-boarding to workflow-driven non-employee provisioning.  Based on Identropy's extensive experience deploying User Provisioning solutions, the most common configurations and use cases were selected in order to substantially shorten deployment time in a tried and tested reference architecture. "We are confident that this new model will accelerate time-to-value for our customer, and will represent a paradigm shift in the identity marketplace", added Villavicencio.

For more information, visit our website at identropy.com or email us at info@identropy.com.

4 Steps Towards Taming your Identity Management Initiative

Based on feedback received from nearly 100 IAM projects (and counting), it's abundantly clear to us that organizations that have taken the up-front time to set-up an IAM Governance Body prior to detailing the specifications of the solution are typically far more successful than those that have chosen to 'play it by ear.'  Unfortunately, too many organizations shy away from establishing an IAM Governance Body because of its 'large company stigma'.

This article aims to lay out the practical few first steps that can be taken to form the IAM Governance Body for your IAM Program, regardless of the size of your organization.  (Based on ourGovernanceTool02 resized 600 experience, the scope of the project is a better indicator of the need for an IAM Governance Body than company size.)

An IAM Governance Body is a grouping of individuals that are collectively responsible for creating organizational policies, establishing authority to see those policies to fruition, and ultimately the execution of those policies.  It goes beyond simple executive sponsorship in order to create a process for defining the appropriate policies, process and execution team for your company's IAM Program. Here are four guidelines that could provide your organization some direction while thinking about IAM Program Governance:

 

Do I Really Need a Governing Body?

The first step is to ask yourself if you really need a Governance Body.  The answer is pretty simple: if the project is long enough to require a vision and a roadmap, then it's probably not appropriate to call it a project.  You most likely have an IAM Program on your hands that will become a permanent feature of your organization.  If this is the case, establishing a Governance Body will be a tremendous help.  

 

Defining an IAM Governance Framework

We've put together an IAM Governance Framework that is practical and has worked for many organizations.  We've purposefully kept it simple yet flexible.  It is meant only as a framework for organizations to adopt and adapt based on their specific requirements.  

describe the image

In Identropy's IAM Governance Model Framework, Key Members of the Governance Body define policy (such as Provisioning/ Deprovisoining Policy, Separation of Duties Policy, Recertification Policy, Authentication/Authorization Policy,  SLAs, Enterprise Standards, etc.), while Supporting Members provide feedback regarding the policy as well as implement/enforce it.  Certain supporting members may be tasked with the responsibility of defining/re-engineering processes in order to implement the policies laid out by the Governance Body.

Based on our experience, the optimal time for defining who's who in your IAM Governance Body is towards the end of an IAM workshop, but prior to the development of Functional Specifications for how the IAM system will work.  At this point in time, your organization has laid down a vision and roadmap for your IAM Program, delineated its scope, and have identified drivers and related key use cases - although detailed requirements would yet to have been defined. That is the opportune time to communicate roles and responsibilities to your stakeholders in relation to the IAM Program, specifically the Key Members of the Governance Body.  

 

Recruiting Supporting Members

As the Functional Specifications are being drawn up, it will be important to recruit the appropriate Supporting Members.  If the Key Members are the legislative component of the Governance Body, the Supporting Members compose (albeit not exclusively), the executive component.  Process Stakeholders are a special type of Supporting Member that works closely with the Key Members in order to define the business processes necessary to make the IAM Policies come to life.  The PMO (or its equivalent in your organization) will be tasked with implementing the policies and process suggestions provided by the Key Members and the Process Stakeholders.

It is also the Supporting Members' responsibility to educate their respective constituencies regarding SLAs and process changes, enlist executive aid where necessary, and put the IAG policies into action.

 

Meetings & Maintenance

During the Functional Specifications phase of the Program, it will be important for the Key Members of the IAM Governance Team to provide support in the form of promptly making the appropriate policy decisions as needed.  Because of this, we suggest a lean body (2-3 members should suffice) to meet weekly or bi-weekly with the Functional Specifications Core Team as various IAM Policy questions arise.
Towards the end of the Functional Specifications phase, the technical Supporting Members of the Governance Body should be identified in preparation for the Technical Requirements & Design phase of the Program.  It will be their responsibility to work with the Key Members in order to define operational issues, identity data management policy, and other technical standards within the organization.

 

Disclaimer

The IAM Framework defined above is a centralized model.  Although we've come across companies where this structure needs to be shifted due to the decentralized nature of the organization, we've found that in most cases, this framework is effective.  Based on your organizational needs, you should make the necessary adjustments that makes sense for your organization.  

 

Will Strong Authentication ever Reach a Mass Scale? (Part 2 of 2)

Back to the initial point of this article...

Antiquated, paper-based processes should be decomposed and replaced by a modern, electronic solutions. Authenticating a digital identity will be an essential building block in the development of such a solution. Just like the electric battery will be a building block in the rise of the electric car (ala Shai Agassi). And here is where I commend the vision and entrepreneurship of Brent and Sal. They have both come up with multi-factor authentication solutions that meet Kantara Initiative's Identity Assurance Framework Assurance Levels 3 (AL3) and 4 (AL4) credential management requirements from a technical standpoint. In addition, and more importantly, they employ novel business models that make them feasible, thinking in Internet scale (and not in expensive, non-scalable models such as HSPD 12).

It is only with this kind of perspective that the next generation of strong authentication solutions will become a reality. The focus needs to be well beyond technology: how can organizations benefit from economies of scale, mass adoption and leverage ubiquitous 21st century infrastructure such as cell phones and telephony in general?

Resolving this issue will be far more important to identity-enabling high-value services, than whether the credentials and claimes are exchanged via SAML, OpenID, CardSpace, good old X.509, or one-time passwords (OTP) via SMS. At this point in time, this is the easiest piece of the puzzle.

Disclaimer for the Identirati: I really don't mean to trivialize federated identity technology, or offend those producing great work and advances in this area;  it is just that these technological challenges are dwarfed by those in the business area. Hopefully I won't be stoned to death for making this statement.

It is all about the business model

We are on the brink of a tipping point. But for a significant change to take place, we need to stop thinking about the obvious business model that has been attempted for years on how to provide strong authentication in large scale: the end user [or its sponsoring organization] pays.

OTP Device Let me illustrate: In order to mitigate risks in accessing sensitive information, many organizations sponsor their user base (employees, contractors, vendors, suppliers, consumers, etc.) strong authentication credenSmart Cardstials, along with the identity proofing and issuance process that each user needs to go through to get the credential. For instance, employers issue OTP devices to their employee for remote access into their Intranet, banks issue OTP USB Tokendevices, USB tokens or smart cards to their customers for sensitive transactions, pharmaceutical companies issue high-assurance X.509 certificates to their R&D staff for electronic submissions to the FDA and US Patent Office, and similarly aerospace and defense companies issue high-assurance certificates to their workforce to encrypt and authenticate when accessing DoD-sensitive data.

In most if not all cases, the organization foots the entire bill, and limits the use of the credential to the purposes intended and nothing more (even in the cases of federated use, such as SAFE-BioPharma or CertiPath). While this contains their risk and liability exposure, it also increases the cost involved in the digitalization of theToken    Necklace process, and severely constrains the possibility of mass adoption. Also, for the fashion and public health conscious, creates the dreaded "token necklace" syndrome. Burton Group's Mark Diodati published an article on this topic in October 2009, which I found interesting.

A look into the future

OK, so let's fast track to the 21st century - all right, not exactly... maybe beyond the first or second decade. After several false starts by several developed countries' governments, entrepreneurs finally figured out business models that made strong authentication economically viable at Internet scale.

The world has understood that charging organizations or even end users for a digital credential simply does not work. Instead, successful identity-enabled services leverage ubiquitous OTP via SMSinfrastructure such as cell phones, and do not charge on a per credential basis, but instead for the use of the service. Operators exist who are willing to give out strong-authentication devices for free or for a nominal service fee. These devices can carry more than one digital identity credential in a FIPS 140-2 certified compartment. The same form-factor and even the same credential can be leveraged across multiple services. Service providers collectively subsidize the cost of the credential and form-factor, similar to the 20th century credit card and ATM networks (oh my God, did I say this out loud?). For many services providers, the cost of providing strong authentication at AL3 and AL4 is much less than the cost of fraud they would face with lower levels of assurance.

The average citizen carries a strong-authentication physical device that contains their most sensitive digital credentials; the ones that they use to perform the most sensitive transactions (AL4) such as

  • Perform high-value financial operations
  • Pay taxes
  • Gain access to healthcare services
  • Play in their online casino
  • Be able to buy liquor by proving that they are over 21-years old
  • Digitally sign their now-electronic mortgage application (wouldn't this be nice?).

They rely on their PDA or cell phone, and in some cases on other voice-based channels such as an old-fashion land line), to securely authenticate and gain access to other services, which may not be as sensitive (AL3) such as buying personal items online, bidding on eBay for some memorabilia, checking in for a flight, confirming a stock purchase transaction, and accessing consumer online banking sites. All without having to pay for the issuance of the credential, or for the authentication event.

The futureI envision a near future, in which society will enjoy some basic benefits at no direct cost: access to breathing air, access to the Internet, and access to strong and legally enforceable authentication in a digital context which will enable secure access to day-to-day electronic and online services. High value identity-enabled services will be so popular, trustworthy and successful, that the regular user would not even remember that at some point in time, strong authentication was doubted to ever reach mass scale.

Wow, that sounded a lot like Isaac Asimov. I strongly encourage you to read and provide feedback to Department of Homeland Security's [Draft] National Strategy for Trusted Identities in Cyberspace,

Your comments are most welcome.

Why IAM Consulting Firms Love Complexity

The best part of my job is customer interaction.  In the past 4 years, I've interacted with nearly 100 customers, and had the opportunity to see the inner workings of where the IAM rubber meets the road.  Real problems, real projects, real solutions.  Based on my experiences, I've decided to start a series that shares customers experiences that make a case for Identity-as-a-Service.

Last quarter, Identropy was engaged by a large healthcare provider who had a familiar story.  In the previous year, they awarded the services portion of a large IAM initiative to one of the "Big 4" (are they still called that?) consulting firms.  After a year and burning through nearly double their original budget, the system was still not functioning as initially planned.  Identropy's team was engaged to analyze where the system fell short, make the necessary changes, and get the system up and running (which we did in about 3 months).  Last week, Identropy's CEO received an email from the executive sponsor stating how thrilled they were that we helped get them through the finish line.  A satisfying feeling indeed, although it left me unsettled.

Consulting Firms Love Complexity

The point of the story (besides tooting our own horn) is that the goal of a traditional consulting firm is to maximize services revenue.  In sales meetings, they'll typically focus on their implementation methodology and expertise.  Behind closed doors, the story is all about utilization rates and change orders.  That's why Consulting Firms love IAM projects.  They are complex, and can justify large implementation teams and multiple change orders.

The problem is that I've never met a customer who wanted a long, complex, over-budgeted project. Corporations typically look for predictability in terms of cost, resources and project length. This causes inevitable tension in IAM projects between the consulting firm and the engaging corporation.

Now, I know that I'm generalizing.  Many projects are successful and many consulting teams do right by their customers, but that doesn't change the inherent drive of senior partners of the firm demanding consistent billing time from their consultants.  After all, that's their business model.

Alignment: A Case for Identity-as-a-Service (IDaaS)

As Frank Villavicencio pointed out in a previous post, a co-sourced IAM model allows for stronger alignment between the service provider and the customer.  In this model, the service provider prefers to provide functionality without complexity, since it's their responsibility to build, integrate, deploy and ultimately operate the overall solution.  Since the relationship is a long-term partnership, the service provider doesn't feel the need to take all the money on the table up front.  Since the service provider knows that they will be providing post-implementation management of the solution, they opt for a simpler (and in my opinion more elegant) architecture.   Ultimately, both parties seek shorter implementation cycles so that they can both benefit from a functioning IAM system sooner rather than later.

For all of these reasons (and more), I believe the days of the "Big 4" approach to identity implementations are numbered.

Frank himself will be at the Identity Infused Enterprise: Intelligent, Cloud-Ready, Secure, an event we are co-sponsoring with Novell, on August 17th (from 8:30 am to 11am) in Boston, MA; and will be able to talk and showcase some of our work in the co-sourced IDaaS area. If you are interested, please sign up for some complimentary, 1-on-1 time with Frank.

Will Strong Authentication ever Reach a Mass Scale? (Part 1 of 2)

It has to, there is just no other way...

The motivation for this article came from the recent publication of Department of Homeland Security's [Draft] National Strategy for Trusted Identities in Cyberspace, on which I collaborated; as well as conversations I had with Brent Williams at Anakam and Sal Khan at Atrust. Both consider authentication and digital identity as essential components to enabling digital trust in an electronic and online context at Internet scale.

Background

For many years, I have been pondering digital identity (an electronic representation of humans in a digital environment) and identity and access management (IAM): how can they truly enable trust in electronic and online transactions, allowing us to fully seize the benefits of the Internet age?

As I alluded to in a past article, I have some history on this topic going back to 2006. I label myself an identity assurance activist.

Pony ExpressDespite the great advances in technology over the last two decades, as a society, we are still being held back from fully realizing the benefits of the 21st century Internet. This is primarily due to the issue of trust (or lack of it) in online and electronic channels, which are highly dependant on reliable authentication.

Allow me to illustrate: If you ever buy real estate in the US, you would have go through a process that hasn't changed much since the 19th century, minus the Pony Express courier service. You would have enjoyed the slow, error-prone, labor-intensive and highly irritating, paper-based process of inspecting, appraising, transacting, registering, insuring and financing the property followed by an 18th century process of contracting services for construction or home improvement. For your sake (and mine), will not get into this highly satisfying, ulcer-generating process. All of this, on the average, employs 12 different parties ranging 19th  Century Real Estatefrom appraisers, lenders, local and state government, brokers, insurers, sellers, attorneys, cousins, siblings, party-crashers and the like. I believe that the founding fathers used more sophisticated technology to write the United States constitution, than the average county clerk utilizes to register a property deed. Have you ever stopped to wonder why, in the 21st century, the age of web 2.0, federated identity, facebook, twitter, and the online social networks, we still have to endure and subsidize such an inefficient way of doing business?

The US Constitution SigningCouldn't I leverage my PayPal account to take care of this? How about my facebook or gmail account? Heck, aren't we supposed to buy everything through eBay or Amazon nowadays?

What's going on here? Is it perhaps the generational clashes and dilemmas of losing our ancient traditions and values in this fast-paced society that makes us hold on to these relics? I think not.

Ancient TraditionsI could point out other day-to-day examples in healthcare, social security administration, insurance claim processing, cross-border trade, and bank accounts, but that would make this article way too long.

Why are these processes so archaic even today?

I do not have a good answer. There are a multitude of factors, including history and habit. One reason is the fear that moving toward an electronic or online process increases the risk of fraud to levels that we cannot manage or understand.

Nonsense. I would say that the paper-based processes we have today are more fraud-prone. We have all suffered from such fraud in one way or another. By migrating to electronic processes, we won't be worst off, so we must take the leap forward. Fear of risks is no justification holding back.

Paperwork

These processes must be modernized. It's just simple physics: manual labor is no longer scalable or sustainable. It cannot keep up with the backlog of paperwork required in our society. As the baby boomer generation retires and veterans come back from war, this will only get worse. Therefore, automation and process redefinition are essential.

 During my days in banking, I learned that the back office processing of mortgages and foreclosures is even more daunting, manual and inefficient. The recent subprime crisis has revealed our inability to keep up with the paperwork backlog.

We have not fully identified the economic benefit and the market opportunity of digitizing these inefficient processes. That is why they have stayed the way they have up until now.

What does it have to do with Identity or Authentication?

It has everything to do with [digital] identity. Identity is the cornerstone of the issue at hand.

If you followed my train of thought to this point, then you are ready for this realization: couldn't we apply the same constructs of IAM that we typically utilize in the Enterprise or Internet consumer worlds to automate these processes and advance as a society? Of course we can.

Then why don't we? Wouldn't we, as a society, be better off without these inefficiencies, which are carbon-footprint heavy and costly? Of course we would.

So why haven't we modernized these processes?

MutationThis is not a simple problem to solve. Moving our everyday business processes from paper to electronic will require a quantum leap evolution (e.g. from horse to automobile). When Henry Ford introduced the automobile, people no longer wished they had faster horses.

Some of these processes will need to be decomposed to atomic pieces, and reassembled in the appropriate way, in ways that reflect today's reality. This change will be drastic, simply because we have exhausted the physical limits to bear a gradual shift. Just like we have not yet realized that a gradual shift from fossil fuel vehicles, to hybrid or fuel cell, to truly zero-footprint energy sources will never occur.

I am not talking about PDF'ing paper forms and using document management systems and workflows with electronic or digital signatures. I am talking about forever forgetting that the document would ever be printed, or whether it fits in a Letter or A4 sheet of paper. This will force us to think about digital identities in 21st century style.

Technology will be an integral part of this shift. More important is the definition of standards for brokering and establishing trust at the desired level for the kind of transaction being performed. Having the appropriate legal framework to ensure that provisions and protections can be enforced is also essential. On this topic, I applaud Tom Smedinghoff's efforts with the American Bar Association IDM Task Force, which are necessary and critical. In addition, the business model that will make strong authentication viable, and will be the focus of part 2 of this article.

[To be continued...]

Ripping and Replacing Identity Management Software. Ouch!

As with any market, IAM software vendors vie for business by positioning and re-position their software in front of potential customers. Ultimately, the customer selects a vendor, implements the software, and walks into the sunset...right? Wrong.

In reality, things go wrong: Hardware doesn't arrive on time. Design decisions are delayed. Conflicts arise between the software vendor, the customer, and the consulting firm. The software's actual capabilities (read 'limitations') come front and center.

By the end of the first phase, some customers are looking for a way out. That's when the project owner starts googling, "Identity Management Project Pitfalls", and "Failed Identity Management Projects," and starts listening to the sweet nothings of the incumbent sales person who got wind of the project's difficulty. That's when the option of ripping and replacing becomes real.

I can't tell you how many times Identropy is engaged in order to perform a feasibility study on a rip-and-replace project. Unfortunately, due to the limitations of delivery methods available in the market today (as Earl Perkins noted in a recent blog entry), most of the time our advice to the customer is to make specific tweaks to their approach and 'stay the course'. Although it is true that sometimes we may find a real reason to switch, it still has to justify the pain of ripping and replacing an IAM solution. Here are a few reasons why:

  1. IAM is Invasive! There are connectors from the IAM system to all the target systems in your environment. Many times, we'll find poorly architected (and overly customized) solutions that place a tremendous amount of dependency on the target systems.
  2. Lack of Standards: Unfortunately, there is no generic industry standard for interacting with target systems. Each IAM vendor has their own 'Connector Framework'. A rip and replace would have to 'recreate' many of nuances specific to the platform that was just deployed.
  3. Re-Educating End-Users: Getting end-users to change their behaviors the first time was hard enough!
  4. Trading Deficiencies: For many customers who have gone through a rip-and-replace, they have come to find out that the deficiencies they were running from from the replaced software vendor exist in another form in the new software.
  5. They're Expensive: Replacing IAM software is more expensive than most customer's initial estimation. After taking into account the new skills that have to be learned, changes in hardware, software, the investment in end-user training, etc. the cost is often equivalent (if not more than) the cost of implementing it the first time.

For these reasons and others, we strongly suggest our customers to perform a workshop feasibility study on the effort of ripping and replacing before pulling the trigger. Get an outside consulting firm to take a look and validate your approach.  It shouldn't take very long (a week or so), and their insight may save you significant time and money.

IAM Assets Often Overlooked in the Enterprise

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.

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

Lazy assetSo, 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)

Form I-9I 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.

Know your customerSimilar 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).

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

All Posts