Access Rights versus Access Usage

Having been in the IAM space for enough years to remember when the idea of a metadirectory was still "cool", I spend a lot of time thinking about where the industry is going, and more specifically, how we can enhance the value that IAM brings to our customers. Recently, one such customer articulated a requirement for an identity governance solution that not only provided them with a global view of access privileges, but allowed them to see who was accessing a particular server or file share.

It occurred to me that most modern identity solutions do a great job of providing a view into who has access to what, but not what they are actually doing with that access. These are two completely different concepts, but from a technical perspective, they don't necessarily need to be.

A standard identity management suite ships with a connector framework that exposes a common interface to abstract the logic that interacts with the target system. These interactions generally comprise standard IdM events such as account creation, modification, enablement, disablement, retrieval and deletion. Obviously, each connector "type" is required to invoke native API calls.

Since vendors are already building connectors that manage accounts across a wide range of target systems, how difficult would it be to extend these connectors to inspect logs on those same systems, and then correlate each log entry to an identity object in the same way that we already do for native accounts? For example, in addition to pulling a list of local accounts from a UNIX server and correlating them to a person's identity, a UNIX connector could expose a method to pull the server logs and update identity records with information about what actions each user had been performing on that server.

It's just a thought, but it strikes me that being able to see who is doing what is as foundational to robust identity governance as being able to see who has access to what.

More Thoughts on Cloud Identity

Unfortunately, I haven't had much time to blog lately, as November was essentially a wash. First, we were left without power for a couple of weeks by the epic Halloween storm that crippled much of New England early in the month. Then I took off on my annual pilgrimage to visit relatives in England. And then, of course, it was Thanksgiving. Next thing I know, the malls are filled with Christmas shoppers and the drone of those annoying seasonal tunes to which we are thankfully subjected for only a few weeks a year.

Anyway, I'm back now. While catching up on my favorite blogs, this comment on cloud-based identity by Sean O'Neill---who I consider to be one of the best minds in the business---caught my eye, mainly because it echoes my own sentiments on the topic.

Sean notes that from a technical perspective, there is nothing earth-shatteringly new about cloud computing itself, except that we now give it a fancy name. No argument from me there. But his more important point is that the increasing adoption of cloud services creates a whole new set of governance headaches for CIOs. To illustrate this point, he quotes the CIO of a major insurance company:

“One thing I have come to realize is that when I move my application to the cloud, all of the security of my networks and firewalls that I have invested in over the years disappears. The only defense I have left is identity and data security in the application”

In my experience, that sentiment is probably not unusual among CIOs and CISOs, particularly in highly regulated verticals such as financial services, pharmaceuticals and healthcare. Entrusting identity management to the cloud may seem like a good idea to analysts, vendors and techies, but they are not the ones who would be laying awake at night, worrying about the legal and regulatory implications of their cloud identity provider suffering a catastrophic breach.

As Sean explains:

Even if you can sue the pants off of your cloud provider, the basic problem is a breach would have occurred and your people are not involved at the security level.

In other words, if you are a CIO and sensitive personal information about your customers and employees is leaked due to a breach at a third-party identity provider, the victims aren't going to give you a pass because you entrusted security to a cloud service. If anything, they will hold you even more liable for gross negligence. Not to mention that "not my fault" will do nothing to mitigate damage to your company's brand reputation.

The increased adoption of cloud computing is inevitable, but it is both reckless and unrealistic to view IAM as just another one of those services, particularly for large organizations.

Currently, everybody seems to be focused on the idea of moving IAM tools to the cloud (which, by the way, does nothing to alleviate the process and governance issues that make IAM projects so notoriously complex---it simply moves these problems somewhere else). Instead of viewing IAM as just another commodity, we should be thinking about how to help organizations evolve robust governance strategies for managing cloud identities. I know this isn't as sexy as the idea of cloud-based IAM products, but it is far more relevant to the average CIO.

Is Logical/Physical Convergence the Next Big Thing in IAM?

Traditional identity and access management describes the processes, systems and policies that are used to identify individuals to information systems, control what privileges they have, and what they are doing with those privileges. By now, this is all well understood.

But why should IAM be restricted only to systems? For most large organizations, the need to control physical access to secure facilities and locations is every bit as relevant to a holistic security strategy as controlling access to applications and data. Corporations spend millions of dollars on physical security systems such as CCTV, electronic barriers and identification cards, designed to prevent unauthorized personnel from accessing restricted areas. Typically, these systems are centrally managed by a Corporate Security department, so that individuals are only granted the physical access required of their jobs, and any attempted security breaches can be immediately detected.

You see where I'm going with this, right? Conceptually, physical security represents the most basic IAM use case. One could almost think of buildings as applications and areas within those buildings as fine-grained entitlements, and the paradigm for physical security is identical to that of I.T. security. Once you make that connection, there is no reason why physical security could not be assigned using RBAC. Indeed, most commercial physical security systems already provide for role-based access.

Yet, for some inexplicable reason, physical and logical security are still generally viewed as two separate disciplines, which makes no sense to me. I suspect this is because in most organizations, I.T. Security and Corporate Security are distinct organizations, and there is often very little cross-pollenation between the two. IAM vendors, for their part, clearly haven't felt any pressing need to address this gap, and still focus almost exclusively on managing access to I.T. systems.

Some of the advantages to logical/physical convergence seem glaringly obvious:

• Reduced TCO achieved by centralized management of all access policies, instead of having to maintain separate systems and processes for logical and physical access.
• Greater compliance with regulatory mandates such as HSPD-12, GLBA, SOX and FIPS-201.
• Streamlined offboarding processes, which is particularly important when dealing with a sensitive termination scenario.
• Smartcards can serve a dual purpose of granting physical access to corporate facilities and providing a second factor of authentication to sensitive systems and data.

Of course, a converged IAM offering would need to be sold in a different manner from traditional IAM solutions. In many cases, IAM products are pitched at the Director/VP level of an I.T. organization, and sometimes at an even lower level than that, particularly when the solution is being acquired to address an urgent tactical need. But only a CIO, CEO, CTO or CCO usually has the appropriate authority over both I.T. and Corporate Security to appreciate the value of a converged offering, and has the political muscle to mandate its implementation. This is yet another reason, as I've argued before, why IAM needs to be positioned more as a corporate governance asset than a back-office I.T. function.

From a technical standpoint, supporting logical/physical convergence should not require a significant re-engineering effort for most IAM vendors. So I find myself asking, why hasn't this happened so far, and who will be the first to address the gap?