Kurt Johnson at Courion blogged about a ruling in a case (LVRC Holdings v. Brekka) regarding wrongful use of enterprise accounts by an employee after being terminated. Read his post for a more detailed description of the case and the ruling, but it basically boils down to this: It is the employer’s responsibility to terminate access, and therefore the (terminated) employee did no wrong by using it since their access was not taken away.

I’ll stay out of the moral/ethical implications here, but what this means to a business is that making sure you take away access from your employees/contractors when they shouldn’t have it any more has suddenly become a much higher priority. Because if that person uses their accounts to do anything when you no longer want them to, it is not their fault, it’s yours. Ensuring prompt revocation of access was always good business practice, but now it becomes a business imperative because your legal protections (employee contract be damned) are greatly weakened.

When compliance became a bigger driver for IAM than IT efficiency, the approach to rolling out identity management projects did evolve to reflect this kind of thinking. But this case is as good a reason as any to reiterate what we have been preaching for years now – that your IAM deployment must have both proactive and detective controls in place to ensure compliance. The proactive control in this instance is Deprovisioning, while the detective control is Attestation.

A common best practice staged approach (thought not the only one) to IAM projects that incorporates this idea is:

• Start by building up your Who-Has-What database (either in your provisioning product or in your identity governance product)
• Put in place a periodic attestation process to force review and sign-off of user access by those in the know (managers, application owners)
• Create a deprovisioning project. Start off with manual processes that are triggered off your HR and Contractor management systems. Evolve to an automated process over time, which should include linking your attestation process to your deprovisioning process for handling rogue accounts
• Start rolling out request-based provisioning for application access. Start with manual processes and evolve to automated processes in a phased manner
• Start working on a role management project as a way to implement role-based provisioning. Again, follow a phased approach.

The stakes in the IAM game just got a little bit harder. Make sure your project has these goals in its sights.

Tags: Attestation, Audit & Compliance, Compliance, Deprovisioning, Risk Management, Rogue Accounts

What Is Cloud Computing?

You’d think this would be easy, given how much everyone is talking about it. But a search on google will show you that there is actually a lot of debate on what the term stands for. Cloud Computing is a fairly elastic term that has been shape-shifting over time to encompass more and more disciplines in the area of IT operations. For a detailed explanation, I would suggest checking out this (free) research paper by the Burton Group. For the purpose of my discussion, I am going with the basic view that Cloud Computing encompasses all those *aaS concepts we have been hearing about for years now that allow every single layer in the architecture of an application (including hardware) to be utilized as a service over the internet:

• SaaS (Software as a Service): through which application services are offered (examples abound like Gmail, Salesforce.com, Zoho)
• PaaS (Platform as a Service): through which application platform/middleware services are offered (like the Google App Engine)
• IaaS (Infrastructure as a Service): through which underlying computing resources like processing,storage and networking are offered (think Amazon’s EC2)

Gartner has said that there are 5 basic attributes of a cloud computing model:

• It is service-based
• It is scalable and elastic
• It shares a pool of resources
• It is metered by use (aka pay-as-you-go)
• It uses internet technologies

Different Types of Clouds

There has also been some controversy around the concept of private clouds, with different folks defining it differently, or even positing that there is no such thing. I think Private Clouds are real and different from traditional data centers, and essentially refer to cloud computing environments dedicated to a single tenant (thereby not adhering to the sharing attribute). The waters get muddied even further when you bring up the concept of Hybrid Clouds. We’ll see how this is relevant later.

What Does This All Mean For Identity?

When we start to think about applications being delivered over the cloud, or enterprises relying on a cloud computing model instead of a data center model, we start to see certain implications for the identity architecture within.

• What is the identity model for these services? Can it co-exist with the enterprises existing identity model?
• Fundamentally, how will the users of these cloud services authenticate? And how will their access rights be managed and enforced?
• Will the cloud services have access to the enterprise identity stores (that are likely not in the cloud)? Is there a integration approach? Is there a replication strategy?
• What security controls exist around the identity data gathered, stored or used by these cloud services? Will they be in compliance with applicable regulations (like jurisdictional regulations on geographic location of data, PCI DSS) and an enterprises internal controls?
• Who (from the service provider side) will have access to the data? How will that be managed?
• How will the enterprises data be effectively segregated in a shared environment?
• What audit controls exist to allow investigation and discovery?

Generally speaking, the reason companies are considering cloud computing is to avoid the expense involved in building or acquiring the infrastructure, and to some extent managing it. However, without paying attention to the security and governance implications, those cost savings will actually evaporate when they either try to retrofit their existing business policies and controls into the cloud environment, or when they have to deal with the fallout from a breach or issue. I think we’ve all seen this particular movie before, so the question is whether we are paying attention to the lessons learnt. Lets talk about this, and examine how externalizing identity is crucial to making cloud computing viable.

Tags: Cloud Computing, Compliance, IaaS, Identity Services, Oracle_IDM, PaaS, SaaS

Also, I will be connecting with a number of folks who are coming out to DIDW, both one-on-one and in some interesting group settings. Matt Flynn has organized a blogger meet, which I look forward to, since my attempt at a Tweetup sort of fell flat. Should be interesting. Again, grab me if you see me at the opening reception or at the demogrounds, or while I am rushing from one session to another, if you want to chat.

Continuing something I started as an experiment at Burton Catalyst, I will be twittering extensively during the conference, sharing what I am hearing, my thoughts and the experiences of DIDW (provided I can snag a power outlet and/or AT&T 3G can avoid going down again). Be sure to follow me at http://www.twitter.com/NishantK if you are interested in my perspective on the proceedings.

Tags: Compliance, Digital ID World

Maarten Stultjens (of Bhold company, which is a vendor of RBAC solutions) agreed with Roberta that role management systems will become the central point of compliance shortly. But he further qualified his perspective: “of course (this is) ‘only’ with regard to authorization management. The main reason for this is not so much the IT perspective Nishant is mentioning in his blog, it is the business perspective which is driving Role management systems. To find patterns and get these approved via attestation is an IT perspective towards authorization management.”

Now, one thing I take great pride in is my being able to always maintain a business perspective of the IAM problem. I have never thought of it as an IT problem (but one that requires and impacts IT infrastructure). So I promptly challenged Maarten to duel for besmirching my reputation (Just kidding).

Maarten further elaborated: “The main reason why role management systems are so important to achieve compliance with regard to authorization management is that role management systems are able to (1) store and maintain the company policies and (2) enforce these policies (through provisioning engines or manually) and (3) audit if the policies are actually implemented. Compliance is all about ‘defining a policy’, ‘enforce the policy’ and ‘proof that the policy is implemented’. There is nothing to audit when there is no clear policy. Sometimes we – IT people – overrate ourselves by talking about compliance and audit. This is the job of auditors.”

Again, I have no argument with the statement that RM systems are “important” to achieving compliance, just with the notion that they are the focus. Roles have long been viewed as the Holy Grail of IAM – true role-based identity management will solve all problems. But like the Holy Grail, it is really hard (nearly impossible) to achieve. So I tend to have approach blanket statements with some perturbation. I don’t disagree with Roberta or Maarten on how important role management is to compliance. I just want the message to be balanced, and not get exaggerated to the status of “all important”.

Looking at Maarten’s position, I agree with point (1), but disagree with (2) and (3). RM systems will not be able to do those because they present only a partial picture of the reality of a business. If I can simplify an example to make my point, it is fairly common for people to be given privileges in an ad-hoc, but entirely proper, manner. This is invariably done through a request-based, approval enforced mechanism that today is handled by provisioning systems (OIM, for instance). These privileges are therefore out of policy, yet are not exceptions. And a role management system should not have to deal with this kind of scenario (even if it could).

Yes, compliance is the job of the auditor, but an auditor is only as good as the tools they are given, which is where the various IAM solutions come in. Auditors care about the roles because knowing the roles a user has tells them about what access the user has and does not have. But they also care about the out-of-policy privilege grants, and want to know that the correct procedures for approving, tracking and attesting those privileges are being followed. They care that audit trails are being maintained, and that there are no loopholes in the business processes.

Another person sent me an email saying “Role management is vital method to achieve compliance while user provisioning is a method to deliver proper user- and permission-information to distributed environments and applications. (yes, UP also collects information from distributed sources for the centralized Role Management)”. This points out one of the main misconceptions that I have been trying hard to fight, and which is probably at the core of the misunderstanding of the space. Too often, provisioning is viewed simply as (to quote) “the bus to deliver this user-permission information, with all required attributes, to all those environments where it is needed.” This really is the IT-centric view. Provisioning systems today (OIM in particular) are actually much more of a business solution than an IT solution, providing rich policy definition and enforcement, and end-user and administrative request-based, approval driven tools for managing privileges in a fluid business environment.

To me, role management is an essential part of IAM. In fact, in today’s environment it is probably the most important part of a compliance-driven IAM solution. It should not, however, be the focus of a IAM-based compliance project. Any good IAM strategy must be a mix of role-based, rule-based and request-based management (think of the old 80-20 rule, just broken down to 50-30-20), with a good overlay of audit and compliance tools. At Oracle, we feel that Identity Administration, Provisioning and Role Management are the three pillars on which (the newly emerging) identity GRC tools are overlaid to provide the foundation of a good identity audit and compliance practice.

(Of course, knowing how IAM is constantly evolving, I am sure we will be adding more “pillars” to this diagram soon, so take this position with a pinch of salt)

This is driven by the reality of modern business – one that is fluid, ever-changing and way too complex to only codify in the structured system that role-based management represents. Over the last few years, I have dealt with a number of customers that have made the effort to incorporate role management into their IAM projects. Invariably I encountered the following:

• No one agrees on the definition of a role
• Most of them only manage to use roles in a limited manner

The mantra of the day is balance. I think Dave Kearns response to my post was best: “While I do agree that RBAC is the ‘wave of the future’ and is, indeed, necessary to good IdM and compliance, I think of it as being one of the foundations of compliance, not the tool that compels or insures compliance. And certainly not a tool for attestation…”

Tags: Compliance, GRC, Role Management