Category Archives: Access Governance

Continuing from my previous entryon this topic, I’m continuing the discussion  about different approaches toward capturing user entitlement information, specifically considering the merits of doing so at the account level versus at the entitlement level. Typically, having a system that provides more insight into the details of which application (or data) entitlements a user has is better – so that the appropriate people in the organization can make better, more informed, and more granular access decisions.

But, in two scenarios, it does make sense to capture and use data just at an account level. The first situation is in a period of transition – where the organization may not yet have the infrastructure or capability to capture, normalize, process, and present detailed entitlements to reviewers (or to users requesting access).  This is a perfectly fine approach, and can be quite useful as a way to put in place business processes for review or access request, and to begin to familiarize end users with them – as long as there’s a concrete plan to ultimately move to reviewing and requesting at an entitlement level. These shouldn’t be left indefinitely at an account level – it simply doesn’t provide enough visibility or control, isn’t audit-proof, and will likely lead to a false sense of security.

The second scenario is when the information about an account’s existence is in fact sufficient for its designated purpose.  For example, one of our customers keeps track of which employees have accounts on their mainframe system. None of the applications on the mainframe are subject to entitlement reviews, so they don’t need to capture the entitlement details. Instead, they use the account information as part of their Leaver process – so that when a person departs the organization, IT has a clear view of whether or not a mainframe account needs to be deprovisioned, and can act accordingly. This is a simple, yet effective scenario, and a great example of the value of having an Access Management Database (XMDB) with complete information about identities and access, even beyond traditional focus of access governance systems

In general, of course, organizations need to capture and operationalize with a detailed view of user entitlements, in order to meet their access-related security and compliance goals.

In my role at Aveksa, I’m fortunate enough to be able to talk to customers and prospective customers on a regular basis. I truly enjoy meeting these folks, asking a few questions, and learning about their Identity Management priorities, challenges, and the business and technology drivers behind them. People love to talk about what they do, and always seem happy to share.

One of the things I’ve noticed periodically is that organizations will review user access at the account level – making access decisions based on whether an individual has an account in a given application, and not on what specific capabilities they have within the app. This is arguably better than nothing, but also arguably worse than nothing!

I’ve tried to summarize the pros and cons of such an approach below:

Access Reviews at the Account Level

Pros

• Satisfies “checkbox” audit requirements
• Will remove some unauthorized access rights
• Increases awareness of this application from a security perspective
• Establishes processes for account data collection, and ownership of review process

Cons

• May not satisfy auditors’ requirements
• Cannot distinguish scope of user access rights
• May lead to false sense of security

While access certification at the account level is less than ideal, on balance it can be quite useful as a transitory state, to help the organization begin to establish access governance processes, ownership, and accountability. For most applications and resources, it shouldn’t be considered as a desired end state**.

The good news is that all the enterprises I’ve spoken with recognize that the correct approach is to perform access reviews at the entitlement level, and are determined to accomplish this.

** as always in life and computers, there are exceptions! I’ll be writing about this in an upcoming blog posting, under the category of “when doing a bad thing is good”