Understanding IAM Governance (AKA: How we monitor, control and decide)

Image by  Benjamin Child <https://unsplash.com/@bchild311> via <https://unsplash.com/photos/GWe0dlVD9e0>

I remember when I first heard about Corporate Governance as a young engineer fresh out of college. I simply could not make sense of the concept and what it meant. It seemed to me like empty words which ultimately meant "ensure we do the right thing".

Pffff. Useless! Of course we will do the right thing! Every employee and every organization makes plans to do the right thing! Anything else would be ridiculous, right?

Right now, many of my readers are shaking their heads in pity for the naivety of my younger self. Because we now know that "doing the right thing" does not happen magically, and it certainly does not persist magically. It needs to be carefully defined, planned, communicated, enforced, controlled, monitored, and reviewed.

However, I'd ask for a little bit of compassion for this younger (and dumber) version of me because, in my current experience, I have seen that so many people fail to grasp the meaning of Corporate Governance and, in our current concern, IAM Governance. Maybe not with so crude arguments as the ones I once had, but with similar and equally dangerous results when the role of IAM Governance is not properly understood.

In previous articles we defined IAM Governance (also known as Access Control) as the set of practices for ensuring that all the IAM pillars (Identity Management, Authentication, Authorization and Entitlement Provisioning) work as expected towards reducing the risk that the organization is exposed to. I'll go now a little further and expand this definition in the following way:

IAM Governance is the set of practices for Defining, Planning, Communicating, Enforcing, Controlling, Monitoring, and Reviewing the IAM processes in order to ensure that all the IAM pillars (Identity Management, Authentication, Authorization and Entitlement Provisioning) work as expected towards reducing the risk that the organization is exposed to.

In other words IAM Governance it's about:

  • Formalizing how the organization thinks IAM must be run
  • Plotting how it will get there
  • Making sure everyone properly understands their role in the framework
  • Ensuring the required health-checks are in place and properly run
  • Measuring how effective these health-checks are
  • Iterating and improving on the plan and the approach

(You can easily remember these points by their acronym FPMEMI. Or... maybe you can't.)

How to establish an IAM Governance Framework

Ok. So now that we know what it is, how do we do this? How do we plan IAM Governance? Actually, there is a very well-accepted Governance structure for a ground-up approach to putting those aforementioned items in place:

According to this graph, the process goes a little bit like this:

  • We create our IAM Policy, which defines the organization's high-level approach and stance to IAM. Why it's important and what the scope of IAM will be.
  • We formulate our IAM Control Objectives, which state the best practices that we want to comply with (i.e. strong authentication, enhanced by biometric MFA, prevents attackers from impersonating our employees).
  • We define our IAM Standard, which defines actual requirements that we want to achieve for each Control Objective (i.e. all authentication will be do through our Identity Provider with SSO enabled, and using MFA at least once per day).
  • We specify and formalize our IAM Controls, which represent specific actions and processes that will help us meet the requirements in our standards (i.e. any new system being deployed in our corporate environment needs to be reviewed and signed-off by the IT Services team, who will ensure SSO and MFA are enabled).
  • We document our IAM Procedures or Control Activities, which detail each flow involved in the execution of a control. What are the actual steps to complete each flow within a control (i.e. How IT Services team will conduct their review and sign-off).
  • We collect our IAM Guidelines, which provide additional context and information as for why the Control is required, how to run it, what to consider, what "good" looks like, what can go wrong, etc (i.e. Training materials, user guidelines, etc).

Once we have all of the above, we are already more mature than 95% of the organizations, from an IAM point-of-view. Still, this is not complete. In order to make this a reality that provides actual value, we're missing 2 key processes:

  • Identify the gaps between the current state and the target state, and feed this gap into our objective setting and planning process. In future articles we will look at how to define an IAM roadmap from the ground up.
  • Regularly measure the effectiveness of our controls and iterate on the plan if needed. While the 3 lower steps of the above pyramid should very rarely change, the 3 higher ones are much more likely to require changes as needed. Assessing our maturity and effectiveness should be a continuous improvement process. In future articles we will look at how to define relevant KPIs (Key Performance Indicators) that allow us to improve our IAM posture.

The Controls

Now that we know how to define, plan and measure an IAM Governance framework, the only question that remains is identifying the IAM Controls that we will want to implement within this framework. There is no easy answer to this, of course. The controls that we need to implement entirely depend on what our IAM Control Objectives and IAM Standards are, as well as the risk appetite of our organization (how much risk are we willing to accept), and the options available are virtually infinite. So, for now, I'll close this article with some quite common and often applicable IAM Controls areas. In future articles we'll cover each and every one of these areas (with examples) in detail:

  • Training users about their roles and responsibilities
  • Capturing snapshots and audit logs about IAM activities
  • Access recertification. This involves reviewing permissions to assess the appropriateness of user access, permission metadata, etc
  • Segregation of Duties, for ensuring that users don't have access to permissions enabling conflicting critical functions of the same process
  • Access request and approval process
  • Permission creation, update and deletion process
  • Temporary access process 
  • Emergency access process
  • Authorization modelling validation, for assessing whether the permissions used are the right ones at all, whether they're too broad, etc
  • Access provisioning and reconciliation, for synchronizing entitlements across sources and identifying and correcting access discrepancies


Popular posts from this blog

How to establish a trust anchor (AKA: Digital onboarding of remote employees)

Of Entities, Identities and User Accounts (AKA: I need to know who IAM)