By Steve Mowll and Chris Williams
Question: When it comes to the complexities of identity management, is what we try to do in identity management the problem or is it just inherently hard?
Point: We might be making it harder than it needs to be. Setting complex requirements may affect long-term suitability and success.
Chris Williams –Advisory Architect, RSA Identity
Visiting with security and identity practitioners, talking about their missions, histories, and achievements, I sometimes see their eyes glaze with a temporary haze of “hesitation.” In these moments, I believe what races through their minds is the sudden resolution that perhaps what they have set out to accomplish may not actually have been attainable within a singular discipline project.
It’s no wonder, given how identity and access management (IAM) has evolved over the years from its core purpose focused on simple system-level account and privilege administration to include password synchronization and single sign-on (SSO), multi-factor authentication (MFA), compliance, governance, policy management, event and behavioral analytics, fraud detection and risk management. And with all of this advanced functionality, we exponentially increase process and the likelihood of ineffectiveness.
Multi-discipline process accommodation is the dark shadow-lurking beast that can destroy an IAM project from within – actually derailing the project and crushing it under its own weight. If we accept the premise that managing identities requires more than just creating accounts and reporting on access, how do we achieve success?
Perhaps our best route to success lies within a simple truth we’ve all heard from Mick Jagger and friends: “You can’t always get what you want, but if you try sometimes well you might find, you get what you need.”
How do we get what we need? Let’s take a page from other IT projects and align the IAM project to a service:
- Determine the most critical success factors resulting from the project and prioritize them against risk mitigation process efficiencies, and user impact.
- Create attainable expectations and goals from the output of the project. Pre-determine advancements in capabilities, savings in resources, expansion in capabilities – all of which may be leveraged by adjacent technologies and disciplines.
- Think about long-term flexibility, sustainment, maintenance and support.
In summary, don’t try to boil the ocean, focus on what matters most. And remember, the more complex you build the environment, the least likely it will serve a long-term purpose or adhere to fulfilling its core purpose and functionality.
COUNTERPOINT: IAM is inherently hard, but to be successful in the long run, you need to look at the problem from a business-driven perspective and start with the end in mind.
Steve Mowll, Identity Architect, RSA
While I agree with Chris to some degree – you do need to setup your IAM program in the right way – however, I believe that identity and access management is, by its very nature, inherently hard. This is because people rarely, if ever, look at the actual business problem in a holistic way.
For example, a company starts an IAM project and they define the top 100 business-critical applications. (Side point: you should just know to do this, but I am still amazed how many companies have not defined their most critical business applications).
Next, you want to gather access information about these applications to understand who has access to what and maybe provision access automatically, perform segregation of duties (SoD) against them, etc. However, the challenge you face is that each application is completely different in EVERY way. So the program goes down the road of creating 100 processes to collect the data, 100 different sets of rules for SoD, 100 different provisioning adapters, and strangely enough, they either completely fail at or only partially achieve what they set out to do taking a huge amount of time, effort and money.
All of this because we do not think about the problem in the right way, from a strategic business-driven perspective.
The way to solve this problem is to think about IAM as a foundational component of your business and not as an afterthought. To do this, you must:
- Define IAM standards and guidelines for any technology you bring into, or create in your business. Defining key expectations such as:
- It must have the ability to provide access information to a centralized IAM platform;
- It must have an interface for automated provisioning, or interface with a common authentication and authorization repository such as Active Directory; and,
- Providing business definitions of all available access.
- Define a standard common authentication and authorization platform such as Active Directory, or LDAP, so that you can standardize your management of IAM where possible.
- Define a standard process and approach for all technology to follow including terminology, common SoD & privilege classifications and track exceptions to the standard.
- Lastly, if you take this approach, make sure to track your success. This could be based on key performance indicators including:
- Applications developed, or onboarded for the business much faster than before;
- Reduction and removal of new orphan accounts; and,
- Applications automatically consuming services to control risk, manage access and automate what were previously manual processes.
Any company can do this, even if they have the most mixed-up environment imaginable, and stop the IAM pain and suffering as new technologies are onboarded or old ones reengineered.
If you are moving to the cloud, this effort should be at the top of your “things to consider” list as it will make a huge difference in the speed of adoption and your control of those services in the future. You will likely not retain the same cloud provider indefinitely, so how easy will it be to change and maintain the same level of service when you transition?
I urge you to change the nature of the problem and begin with the end in mind.