A Tale of Access Governance: Ownership vs. Facilitation – Part 1 of 2
Once upon a time, an organization was confronted with the fact its IT group was consumed in answering auditors' questions, as well finding and resolving issues found by auditors. The IT group, responsible for the Identity and Access Management (IAM) team was constantly overworked and barely had any cycles to advance their IAM initiative outside of addressing questions and requests from internal and external auditors…
This is the start of many tales I could write, based on first-hand recent experience working with diverse clients in various industry verticals. After several interesting and often intense discussions, it dawned on me that at some point in time, the client’s IAM program had morphed. As a result, the IAM team was seen as the party responsible for answering the auditor’s questions (i.e. “why does such and such user have this access?” “These users apparently have more access than they should, your team should remove the unauthorized/unnecessary access etc…”).
I realized that their IAM program’s goal was no longer the facilitation and automation of the identity and access lifecycle management processes. The IAM team became the owner of access governance, and thereby responsible for answering why access anomalies existed.
This is a subtle but very significant difference. Based on this anecdotal evidence, I wonder if this is endemic in the industry. Are organizations confusing the purpose of an IAM initiative with who is responsible for approving access decisions for its workforce?
So, I decided to write this short article to shed some light that may help the IAM program managers and the Identerati in general in setting their programs for success since at the end of the day, if the program does not deliver on its goals, it is dead. Regardless of how sophisticated the technical IAM infrastructure is.
Symptoms
Let me ask you (assuming that you are an IAM stakeholder for your organization) a few questions…
- Let’s say your organization centralizes the access request processes in a common interface, whether they are automated or manual, such that the IAM infrastructure enforces a workflow and captures the desired approval.
- Are most approvers people who work in IT? Should they be?
- Is IT stepping in to do approvals because the business stakeholders refuse to own this responsibility?
- Does your IAM team spend a significant part of its day-to-day tending to issues around terminations? Are termination issues the most common, recurring deficiency found in audit cycles?
- Have the business stakeholders in your organization reviewed and approved the termination process your IAM infrastructure currently streamlines? Or was this process defined by IT, at the time in which the IAM technology was being implemented, since there was no formal definition, or simply because nobody else came to the table at the time?
- How is your organization managing emergency terminations (i.e. those that require the terminated individual to be escorted off the premises)?
- How about mass terminations that need to be processed on a given date, is this a well-scripted procedure or does it best resemble a Cirque du Soleil show full of trapezes?
- In your experience, how effective do you think your access recertification control is? How often does it run (i.e. annually, quarterly bi-annually)? And how effective is it in mitigating the risk of access accumulation?
- Do you find that the IAM team is having a tough time reconciling a high volume of exceptions that result from access recertification rejections?
- Does the IAM team spend a significant part of its limited bandwidth answering to the auditors about “why does this user have this access?” and then spending time justifying why is it so?
- Do you believe the access recertification control, while being enforced and perhaps automated, results in “rubber stamping” by the approvers, who are trying to protect their ever-scarcer bandwidth? By the way, this particular symptom to me resembles the “the password post-its around the screen” syndrome: your auditors may not identify a gap and you can pass the audit with flying colors, but effectively, you are not mitigating the risk the control is trying to reduce – Oh boy, which one should I go for: the one that makes the auditors go away and reduces my work load, or the one that generates more work for me and my team?
If your answers to these questions reflect a scenario in which IT is truly bearing the burden of addressing and responding to these inquiries, then your organization may have crossed the line that separates facilitation from ownership of the access governance processes.
Why does this happen?
There is no single explanation as to why this situation happens, somewhat endemically in organizations. My best answer is it is the result of a combination of factors, including human nature – the latter relating to the tendency for humans to not change their behavior, and to default to the path of least resistance. This can be seen in many ways:
Overworked managers and stakeholders throughout the organization refuse to take on the added responsibility to approve access requests coming from users. “Heck, I was never consulted whether this cumbersome IAM interface was OK for them to use for this purpose? This is the IAM team’s responsibility, it is their system anyway…”- IT embarked on a multi-million dollar IAM initiative, and once nearing the production rollout stage, the project lead realized that the workflows from testing were routing approvals to the IT team, and since it was too late to socialize and get buy in from the lines of business to change those to business owners, the decision was made to proceed forward anyway. The project completed, the project lead was promoted, changed jobs, left the organization, and now this is someone else’s problem. Meanwhile IT is stuck approving things.
- The auditors do not have a clear idea of who is the owner of what, so they always start by asking the IAM team for evidence of approval and other supporting data eventually identifying the business owner, after spinning some of the IAM team’s productive cycles.
In many instances this is construed as a by-product of the organization’s culture (i.e. ever heard the expression “that’s the way we have been doing things around here for many years”?).
Either way, it is important to recognize this is not a healthy condition and one that, if left unattended, will seriously compromise the effectiveness of the IAM program to address the business objectives that the organization set out to achieve, regardless of technology maturity or sophistication.
In Part 2 of this 2-part article, we will continue this discussion, and center on how to re-focus the IAM program to increase its effectiveness.
