Reference no: EM133511126

CASE STUDY

An Identity and Access Management (IAM) case study depicting challenges and opportunities from the eyes of a CIO.

It was 4:00 p.m. on Thursday afternoon, and Mark Renshaw was still sitting at his desk, soon to be late for his team meeting. This would be the third meeting in as many weeks to discuss recent application access management flubs, and the technology team's apparent lack of support in administering and maintaining effective access operations for the business applications.

Renshaw was the CIO of Intersure, Inc., a leading global financial services company based out of Ohio. He had been in the job for nearly two years, taking on the job after a surprise departure of his then-boss. In one of his first meetings with Beth Olivio, she recalled that IT had recently been more of a problem, rather than a solution. This was particularly true when it came to access management and operations. His primary tasks, which she had made very clear, were providing top-notch service to the business team and, most importantly, getting a handle on their applications and how to support them. Intersure saw an opportunity to grow through acquisitions during the financial downturn, and integrating new applications to the existing mix was a task Renshaw was expected to tackle without major hiccoughs.

These concepts were not new to Renshaw. In his previous position as an up-and-coming CISO at a national commercial bank, he had been tasked with establishing a consistent set of access procedures for multiple business units. His project included the implementation of new identity and access management (IAM) software with the ability to support access request, approval and provisioning workflows for multiple enterprise applications and platforms, creating a unified user experience. From there, he was able to consistently track access requests, approvals, audit documentation, and enable timely provisioning. He had learned a lot from the project and had been ready for similar challenges in his new role at Intersure.

As Renshaw walked out of his office toward the team conference room, he started to recall the sequence of events that had led up to this meeting.

The First Missteps

Eight months earlier, things had looked very different. Renshaw's boss, Beth Olivio, had praised his team for their work on a technology integration project, as they absorbed the infrastructure of a recently-acquired life insurance company. Although it added yet another set of systems for the team to oversee, he had finally started to feel that he was getting a handle on the glut of applications that had been added over the years. The infrastructure continued to support over 300 applications, and a series of smaller IAM projects had created a web of access procedures to meet the differing needs and capabilities of each application. His experienced team had done well with the resources that they had and had led the training and implementation of the required security tools.

That was, until his team started to leave the company six months ago. The departures had started to expose inconsistencies in the processes the team used. The web of access procedures, although documented, still required in-depth knowledge and experience with the process. Procedures for one application would frequently vary, sometimes considerably, from another application. For this reason, overall policy and procedure documentation was overly vague such that it could be applied across applications. At the individual application level, procedures were not consistently followed.

Access Problems Start Snowballing

Renshaw continued to see turnover among his team, and continuous pressure from the business and internal audit urged him to get a full grasp of the access issues the company had been experiencing. With so many diverse business applications and silo'ed access operations processes, these problems weren't a surprise to him, but the business certainly acted like proper access procedures should be a "given." He didn't disagree.

One of the known deficiencies in their access processes were the consistent tracking of a user's access requests and approvals across multiple applications. The main worklows and ticketing system (ReadyTicket!) managed requests for only a handful of applications. During an access modification, such as an employee termination, ReadyTicket! would list the user's current access only from these on-boarded applications, and none others. It was the business unit's responsibility to scan each application for terminated user access and make the appropriate de-provisioning request to IT. This manual process was not reliable recently, and Renshaw felt like he was in the cross-hairs of auditors for having a broken process.

A Path to the Future

Renshaw enlisted his CISO, Julia Bradford, and a handful of security analysts in her team to define the future state design and develop a roadmap to achieve it. The task at hand was to define the business and IT requirements for an IAM request, approval and provisioning tool that would most effectively integrate the applications at Intersure.

Through a series of discussions with Renshaw, Bradford had been wishfully thinking that she could scrap the hodgepodge of silo'ed access procedures and help implement a centralized IAM tool. Now that she had the chance to finally put pen to paper, she jumped at the opportunity.

Renshaw asked that the draft roadmap be presented to him within three weeks. After they had finalized it internally, he and Bradford would present their proposal around the organization to gain support. Most importantly, he needed Olivio onboard.

In the following days, Bradford with her team started sequencing the steps of where the company had to go with their IAM program. What should they consider, and what was most important? They clearly needed to prioritize the most valuable initiatives first. So what, then, would an implementation schedule look like? These questions and others continued to roll around in her head, as she worked through with her team to build a high-level plan.

CASE STUDY QUESTIONS

1. Who are the typical key stakeholders for an enterprise-wide IAM transformation program? Consider the key business and IT stakeholders.

2. What are the components of an IAM future state design?

3. What's Renshaw's IAM vision entail? What should he expect to see in an IAM roadmap aligned with his vision?

4. Why is Renshaw focused on self-service and giving more control to business?

5. What are the common access request and approval steps? Who are the key access owners in the organization, or who should they be, to carry out these approvals?

6. What technology components are required to implement the desired capabilities in this case study? Why could Renshaw and Bradford be focusing on having an IAM product with the greatest amount of support out-of-the-box?

7. What could Renshaw have done differently prior to focusing on IAM product selection?

8. Why is user experience important in access request, approval, and provisioning systems? What other business drivers beyond user experience should be considered?