I had a conversation with a colleague this morning about the tension between two sales approaches:

1. Focusing on business value derived from implementation certain technology
2. Focusing on technical capabilities (AKA speeds and feeds) of certain technology

Our unified position was that the the second position only really made sense if aligned with the first.  Technology by itself is certainly interesting, but in real world markets, it is becoming increasingly difficult to justify purchase of any technology unless it is very clear how that technology can deliver business value.

Therefore I spend most of my time focused on the business value of various Identity and Security technologies, rather than the technical details of how they are implemented.  Unless we can really make a positive impact on the business whom buy our products and services, our market is not sustainable.

To support recent discussions about Identity Management and Cloud computing, I divided the types of Identity Services that might be needed to support Application services into three major categories as shown in the following diagram and explained in a bit more detail below:

The specific services provided in each category could include:

Identity Administration Services

• Create, update, delete identities
• Password/credential management
• Entitlement definition/management
• Provision/de-provision access privileges
• Role engineering/management
• Policy definition/management

Identity Enforcement Services

• Authentication
• Authorization
• Access control
• Federation
• Web services security

Identity Audit Services

• Reporting
• Evaluation
• Attestation
• Validation
• Remediation

Did I miss any services that you think should be present?  Any input on the categories or types of services?  Any input or criticism would be most welcome.

The following chart may be helpful as we consider the different types of users that should be addressed by Identity and Access Management (IAM) technology and processes in cloud computing.

At the Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) layers, the only users are administrators of the platform or infrastructure services, respectively.  However, these administrative users may be either on the provider side or on the recipient or enterprise side.  End users, whether within the enterprise (employees or contractors) or external to the enterprise (customers and partners), only exist at the application layer or Software as as Service (SaaS) layer.

This illustrates how cloud computing introduces increased complexity into IAM. Not only do the different layers (PaaS, IaaS and SaaS) have unique requirements, but multiple organizations (e.g. provider and enterprise) need to be considered.

For example, the nature of PaaS services will require provider administrators to have root access to the operating system, while enterprise administrators at the SaaS level may only need access to application configuration functions and external SaaS users only need to access to selected application functions.

Hopefully, this provides food for thought as we explore IAM in cloud computing.  I’d be grateful to hear your comments.

Last Thursday, January 21st, I gave a presentation at the Sun Horizons conference, “Healthcare Integration Through a New Perspective.”  The title of my talk was “Identity Management: Securing Information in the HIPAA Environment.”  I explored how the complementary functionality of Identity Management and Master Patient Index technologies can enable effective Patient Consent Management, a vital requirement for online health information networks.

A copy of my presentation deck is available for download here.

At the heart of my the presentation was the following diagram, which illustrates major components required in a Patient Consent Management system:

A brief explanation of key components follows:

Identity and Role Repository

IAM technology and methods provide the foundation for an effective patient consent management system.  An Identity and Role Repository contains Identities, roles and access control credentials necessary to support the consent system.  This repository includes:

• Patients
• Providers
• Access Rights
• Roles (map business responsibilities to access rights)
• Override Rights (Only users with specific roles can perform override without consent)

Consent Registry

A consent registry is required to specify what permissions have been granted by patients, within the allowable limits specified by each applicable jurisdiction.   Some of the key attributes include:

• Consent Permissions for
• Patients
• Organizations
• Users
• System-wide mask (everyone)
• Fine gained access
• Include or exclude attributes
• Accommodation for multiple jurisdictions

Master Patient Index

A Master Patient Index enables correlation of patient data across multiple repositories.  This is essential because patient records are typically help in multiple locations.  In other cases, if patient records exist in the same physical data warehouse, they are often logically separated. 

Federated Data Access

If patient data is located in physically or logically separate locations, Federated data access controlled allows access across domain boundaries without compromising the privacy or integrity of individual patient record repositories.

Data Access Services

By providing a set of centralized data access services governed by IAM, the Consent Registry and the Master Patient Index, a secure method of patient data access is possible.

Semantics: “The study of meaning”

This morning I read a thought-provoking article by my associate Mark Montgomery entitled “Systemic failures, by design.” The article proposes that in many high-profile cases, catastrophes could have been averted or moderated if appropriate semantic-based analysis and action had been taken, based on data that existed prior to the event:

Over the course of the past dozen years the U.S. has experienced a series of dangerous and costly systemic failures throughout our security and regulatory framework. The unfettered bubble in technology, missed opportunities to prevent 9/11—leading to two ongoing wars, the tragic response to Katrina, the largest financial crisis in history, the Fort Hood massacre, and the ‘underwear bomber’ incident on Christmas Day all share one commonality.

In each of these cases, data had been collected by U.S. government agencies that contained a high probability of either entirely preventing or substantially mitigating each event, if only the information had been recognized and acted upon within the window of time allowed by circumstances. In case after case, repeated warnings by recognized experts, sourced internally and externally, were ignored or suppressed.

In the past few months, I blogged a couple of times about the use of data analytics with Digital Identity:

• Identity Trend 9: Identity Analytics

• Anonymized” Data Really Isn’t

In his address at Digital ID World, Jeff Jonas’ discussion about using data analytics to discover space-time-travel characteristics of individuals was both challenging and disturbing. He proposed that advanced analytic techniques could be effectively used to pinpoint the identities of people of interest based on patterns of use of mobile phones and other data sources readily available today.

While there is certainly danger of loss of freedom to ordinary citizens due to government surveillance, it is apparent that a much better job of identifying and acting upon potential threats and the identities of people involved is quite possible if existing data, lawfully acquired, is more effectively analyzed in meaningful (aka semantic) ways.

Next Thursday, January 21st, I will be giving a presentation at the Sun Horizons conference, “Healthcare Integration Through a New Perspective.”  My topic will be “Identity Management: Securing Information in the HIPAA Environment,”  I will explore how the complementary functionality of Identity Management and Master Patient Index technologies can enable effective management of Patient Consent Management, a vital requirement for online health information networks.

If you would like to discuss the topic or meet me in Washington, DC, please drop me a line.  After the event, I’ll post my presentation deck for review.