InfoSec-Specific Executive Development for CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive labs to build you and your team's InfoSec skills
Identity and access management (IAM) should be treated as a complex, long-term program with an open-ended set of deliverables. As such, an IAM program requires strong executive sponsorship, incremental deliverables, effective project management and strong
technical resources to design, deploy, operate, support and upgrade multiple software products. This piece details those requirements and explains how to create an effective IAM program and operational structure.
It’s not uncommon for IAM implementations to be long or indeed endless, as deliverables are continually added over the life of multiple systems. Organizations go through both business and infrastructure changes, including re-organizations, mergers,
acquisitions, divestitures, OS upgrades, cloud migrations, new application deployments, etc. These changes trigger matching requirements in IAM systems and consequently lead to implementation and maintenance effort. In other words, ongoing investment
is a good thing – it means the business benefits from a constantly expanding set of capabilities.
This is not to imply that individual deliverables cannot be implemented quickly or operated efficiently. Rather, successful implementation of one feature or integration usually triggers interest by new stakeholders, who request additional features or
It is helpful to think of IAM process automation as iterative optimization. Ongoing expansion in the scope of deployed systems should be the responsibility of a permanent team, rather than implemented by a team assembled for a single set of deliverables
and then released to other, non-IAM projects.
Successful organizations create a permanent IAM program, rather than staffing for a short-term deployment project.
IAM is a complex set of capabilities. A useful definition for IAM is the set of processes and technologies used to effectively and consistently manage the identity lifecycles, attributes, entitlements and credentials of human users and non-human software
agents, across systems and applications. IAM systems are deployed to meet regulatory obligations and internal control objectives, to make IT access administration and user authentication more efficient and agile, and to reduce IT operating costs.
The functional product categories within IAM include:
Each of these categories tends to be automated with distinct software products.
IAM’s many stakeholders include: IT, audit, compliance, application owners and business users. These stakeholders may have conflicting or at least non-overlapping objectives. Without a mechanism to synchronize priorities, IAM programs can degenerate
into ongoing conflicts about what to do and where to begin.
A strong executive sponsor with both the authority to resolve disputes and the funding to deliver outcomes is essential to IAM program success. Because IAM stakeholders are so widely
distributed across different parts of the organization, it’s critical the sponsor resides higher up in the organization hierarchy to have authority over as many of them as possible.
The concept needing an executive, or leadership-level sponsor for IAM may be surprising, because IAM is relatively small compared to other highly-placed IT initiatives or programs, but it is important nonetheless.
IAM incorporates both business process automation and integration with a wide variety of systems and applications. Typically, multiple software products are involved, each with its own architecture, extensibility mechanisms, etc. This complexity means
significant technical expertise is required to move IAM ahead.
A best practice is to have at least one dedicated, strong technical resource per IAM product. Ideally, the same person is not responsible for multiple IAM software components, because each one
will require one or more full-time employees (FTEs) to deploy, integrate, configure, support and extend. Assigning the same technical expert to multiple IAM products could potentially dilute this individual’s availability and extend deployment
or feature-addition timelines.
Consider managing IAM as a program, rather than a project, because there is a lengthy sequence of deliverables. Within the overall IAM program, each deliverable should be organized as a project. Each implementation project should be assigned a project
Inside this structural framework, project managers are responsible for delivering new capabilities on time and on budget. It is a good idea to also leverage project managers when prioritizing new capabilities, once each deliverable is complete.
A rule of thumb to consider is between 0.5 to 1.0 project managers per concurrent deliverable. If an organization plans to work on, for example, four initiatives at any given time, then it makes sense to have from two to four project managers in the IAM
IAM is a complex topic and it's helpful for project managers to understand not just resources and timelines but also the subject matter at hand. It is therefore a best practice to send project managers to relevant product training and retain them in the
IAM area for a long time, rather than pulling a fresh PM from a project management office for every new initiative.
While it is a good idea to draw up a long-term IAM roadmap with strategic deliverables that may require years to complete, consider a periodic approach, where the roadmap is examined every 6 or 12 months and:
Repeat this prioritization exercise as work is completed, rather than trying to plan out deliverables years in advance.
In some organizations, different people are responsible for:
These silos can create perverse incentives. Architects select technologies that fit well into an overall picture but may not have required features. Procurement teams could choose products with attractive features but that may be difficult to deploy.
Deployment teams might focus on installation and upgrade, but disregard operational support.
Consider a single team that lives with the IAM system for its entire lifecycle, engaged early in the architectural design and tasked with long-term support of the system. This team can pull in architecture, procurement specialists and systems integrators
when required, but it should "own" the system from cradle to grave.
Similarly, consider the teams responsible for different IAM functions – such as directories, onboarding, deactivation, review/recertification, password management, privileged access, MFA, federated access, etc. – to coordinate and integrate.
This does not mean they must buy from a single vendor or run on the same platform, but they should evaluate business processes with a big picture in mind and implement integration between IAM components whenever possible.
IAM is big and complex. There is always a lot going on. There are many stakeholders, each with their own priorities. It's helpful to communicate clearly with all stakeholders what IAM capabilities are already deployed, what outcomes they are generating,
what's planned and in what sequence. The same venue can be used to share information about the health of IAM-related systems.
Because priorities evolve and system health is real-time, this data is "live." A best practice is to build an IAM portal and publish all this information. It should be open to the entire organization and updated both:
Transparency aids collaboration and reduces conflict between stakeholders.
The overall IAM program should include:
For each IAM software product, an implementation and support team should include people with specific responsibilities and skills (see Figure 1).
For each deployment initiative (new product, feature or integration), consider assigning a team that might include:
Effective IAM programs have multiple prerequisites. To be successful, consider focusing on:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.
September 23, 2021
By IANS Faculty
In this piece we share insights into what security teams want to know about ransomware prevention as well as tips from our Faculty on how to prevent ransomware attacks.
September 21, 2021
Gain a better understanding of the different types of CISO reporting structures and examine reasons for having a CISO report to technical director instead of a chief information officer (CIO) or another C-level executive.
September 16, 2021
Compare traditional AD vs. Azure AD, gain an understanding of how the two tools differ from a security perspective and find advice on how to deploy them successfully.