3 Challenges Holding IAM Programs Back (And How to Solve Them)

Florian Pouchet

Senior Manager

Toby Felton

Consultant

Todd Hintze

In this second article on Identity and Access Management (IAM), we look at why many organizations face difficulties transforming their IAM ecosystems and how IAM programs should be approached and structured.

In our previous article – Fortify Your Security Perimeter and Reduce Risk of Human Error with IAM – we identified the main drivers of IAM improvement and four key maturity levels. We established that dedicated, proactive programs are essential in climbing this maturity ladder.

IAM is a far-reaching concept. This understanding must be put into practice when running such a program to avoid quickly falling into common pain points. Let’s take a closer look.

3 typical examples of IAM program challenges

Three main drivers put demands on IAM – business change, cybersecurity, and user experience. However, organizations often undertake IAM programs driven, exclusively or primarily, by the desire to migrate to a new solution. With technical debt or tooling as the only real concern, IAM programs can quickly face issues.

Broad impacts of migrating to a new solution

Often the desire is to simply migrate to a new tool or perform a major upgrade of the existing technical asset while leaving all other elements of the IAM service unchanged. This can have unwanted effects.

For example, a new tool will likely bring about new approval processes, which will require staff training on a new user interface. It could even require entirely new leavers and joiners’ processes for HR. This pain point ultimately boils down to a lack of assessment of the impact of the technology change (in the context of the broader IAM ecosystem.)

An ever-growing list of requirements

When an organization realizes that IAM change is not limited to the tooling, this can often open the floodgates to an unrealistic number of new objectives. Stakeholders end up demanding more of the program (such as better user experience and increased ITSM integration) – despite these new objectives not being identified initially and catered for.

The program can become a vehicle to voice dissatisfaction with the existing end-to-end IAM service, causing scope creep. This dynamic can quickly bring pain to the program across change management, budget, and solution architecture.

Forcing a like-for-like implementation

Once interactions between the new IAM solution and its perimeter services are fully functioning, you still need to consider differences in design philosophies between the new and the old tool. Key product design differences must be catered for. If not, organizations can end up requiring custom code and complex configurations on the new solution simply to match the previous setup.

This can impact vendor support, maintenance, and overall performance, not to mention the need to retain a considerable body of knowledge on the complex customization. By going down this road, you can cause more trouble than what you are trying to fix. A butterfly effect of issues can be on the cards when trying to force a like-for-like on different tools.

The key to avoiding these common pain points is acknowledging that IAM must be viewed as a transversal topic, impacting technology, people, and processes.

What is the recommended approach?

The key to success is acknowledging that IAM improvement is a far-reaching program. Implementing new solutions is only the tip of the iceberg, and key impacts should not be underestimated. Under the hood, we believe the key streams of the transformation are:

• IAM solution renewal: The deployment (or upgrade) of the new IAM solution. This includes solution architecture, engineering, and technical migration.
  
  
• Modeling of rights: Existing access rights must be translated into the new IAM ecosystem, such as business roles and application profiles.
  
  
• IAM data cleansing: The stream to review, cleanse, and validate the reliability and correctness of existing user data. For example, recertifying the role of a user and validating their line manager to ensure the correct person is approving access requests.
  
  
• New processes and change management: This includes new ways to request and review access to applications, new processes to manage leavers and joiners, and training staff.
  
  
• Interoperability with other services and assets in the IS: For example, integrating the new IAM tooling with the SOC may require re-engineering the log ingestion into the SIEM and API calls. Another typical piece of work is to coordinate with concurrent AD migrations or upgrades.

We recommend structuring the IAM program such that each of these topics is covered by an individual project. The design authority of IAM policies should operate at the program level, with clear inputs to help guide all streams.

Finally, flexibility is key to managing changing circumstances and constraints. Here are additional tips to ensure the program can remain on track to meet its intended objectives:

In this article, we have seen how defining key objectives is vital for the program’s success. Understanding the breadth of IAM change is crucial for structuring the program and delivering on time and on budget. This approach will also allow program managers and each stream lead to implement flexible measures to migrate from a legacy ecosystem and legacy applications to the new solution, all without losing sight of the guiding principles of identity and access management.

Author

Florian Pouchet

Senior Manager

Florian Pouchet is Senior Manager at Wavestone with over 15 years’ experience in cybersecurity. He leads the Cybersecurity and Operational Resilience Practice for Wavestone UK, providing oversight across cybersecurity strategies, remediation programs, crisis management exercises, and recovery planning

Toby Felton

Consultant

Based in London, Toby Felton is part of Wavestone UK’s Cybersecurity and Operational Resilience team. He holds a First Class BSc in Mathematics from the University of Exeter.