Published: May 26 2008, 11:11 AM | 1 Comment(s)
by Sumner Blount

I work with many members of the CA IAM sales and technical teams to help them understand and communicate the business values of IAM.  As a general rule, this is fairly straightforward since the benefits of IAM have become quite clear over past few years.  The tried-and-true benefits, include (each one is linked to a CA whitepaper on that topic):  a) reduces IT costs, b) reduces security risk, c) enables easier compliance, and d) enables new business opportunities.  There are certainly variations on these themes (such as "IT process automation" as a component of "reducing IT costs", or "providing a better user experience" as a component of "enables new  business opportunities"), but these four key points generally cover the primary drivers for the IAM market, and illustrate why it has been growing so fast for so long.

But, when talking to customers who are considering adopting IAM, sometimes these broad benefits don't hit home as much as we'd like them to.  It's not that they don't constitute very compelling business benefits of IAM.  It is just that the IT people who quickly understand the value of IAM often need to get funding or resources from people in their organization who don't live the problems every day and thus need to discover more intense pains to get the IAM projects prioritized

I have found that sometimes what I will call "the embarrassing question" can be very effective at driving home the pain that IAM systems can help to alleviate.  An "embarrassing question" is one that

a) highlights a problem that the customer almost certainly has,

b) involves information that the customer *should* know, but often doesn't, and

c) for which the answer, in and of itself, is an excellent selling point for IAM. 

Let me show you what I mean. One of the benefits of automated de-provisioning is that it helps to eliminate the problem of orphan accounts.  In this case, an orphan account is one in which the owner has departed the company (and is possibly disgruntled and interested in getting access to corporate information for nefarious purposes).  In many IT environments, orphan accounts can be a significant problem.  

Example: a study of 850 IT, security, HR, and C-level executives found that:

• 27% reported more than 20 "orphaned" accounts on their systems.
• 38% said they have no way of knowing if terminated employees have accessed systems through their orphaned accounts;
• 15% said they have experienced it at least once.
• 30% said it takes more than three days to terminate an account after an employee leaves; 12% said it takes more than a month.

http://www.eweek.com/c/a/Security/Old-User-Accounts-Pose-Current-Security-Risks-for-Enterprises/

A related condition is when an account has a live owner (employee), but the account hasn't been accessed for a very long time.  That is typically called an inactive account, but for the sake of simplicity, let's call them both orphan accounts.  In the former case (the terminated employee), the risk of damage is much greater than in the second case, but the basic problem is the same - an account that should be terminated is still active.

A question I have used to drive home the value of IAM is "if I looked on your systems right now, how many orphan accounts would I find?"  Statistics have shown that upwards of 30% of all accounts on most systems don't have active owners, so this is clearly a widespread problem.  There are several possible answers to this question, and the corresponding logical conclusion that the customer might reach:

• "I don't know" -- "I don't even know the answer to this question...this could be a significant, undetected risk for me. I better deploy IAM to help get this under control quickly."
• <any non-zero number> -- "I deserve credit for knowing that I have this problem, but...I still have it. I better deploy automated de-provisioning to help reduce this risk"
• "zero" -- if truthful, this is an unlikely answer....unless of course they already have excellent identity management processes in place

The reason that I call this an embarrassing question is that either of the first two responses are, by far, the most likely, and both imply a lack of sufficient control within the IT organization.  In effect, either one of these truthful answers indicates that the IT processes are not effective or not under control.  And, presumably the person in this discussion is responsible for the IT processes.  Hence, a question that can be awkward to answer truthfully.

Another example of this type of embarrassing question is "How many Superusers do you have on your systems, and do any of them have any access rights that they don't need or shouldn't have?"  The answer to the second part of the question, in virtually all IT environments, is "Yes".  I've never seen an IT environment in which at least some of the Superusers did not have excessive entitlements for their job responsibilities.  Sometimes, the impact might be minimal (e.g., they can control the printer even though they never need that access right), but in other cases it can constitute a significant risk (e.g., they can stop the system logging process so as to mask all events for a short period).  Merely answering the question will show conclusively that the customer has a security risk, and potentially a compliance problem that they may not have wanted to face before. 

In my discussions with customers, I have found that the problem of excessive entitlements for Superusers, as well as the related "superuser anonymity" problem (whereby all superusers are denoted as "root" in the audit logs so that specific security events cannot be associated with a specific individual) are two of the most common deterrents to a smooth IT security audit.  The first problem allows improper actions to be taken, and the second problem prevents their detection.  And, only when faced with a direct question like this do many people start to really internalize how exposed they might be.  If the Superuser is careless, then results can be very damaging.  If the Superuser is malicious, the results could be catastrophic.   (more detail on this issue)

While I certainly don't like selling on fear...the reality is that there are risky practices out there in the real world.  Sometimes the most effective way to show a customer that they have a compelling need for IAM is to highlight the "clear and present danger" of some aspect of their existing IT environment.  I have found these two areas - orphan/unowned accounts and excessive superuser entitlements - to be among the most common problems that scream out for an IAM solution (automated de-provisioning and a host access management solution, respectively). 

Do you have thoughts or comments on this issue?  Feel free to post them here, or send them directly to me at sumner.blount@ca.com