The Director's Guide: IAM Security at Scale

[kylenowski]

Identity and Access Management (IAM) is one of those areas of enterprise security that’s hard. 

IAM is simultaneously very visible to users, and also a critical step in preventing cyber attacks like ransomware or account compromise. When done correctly, it helps make users’ work easier and secures the enterprise — a rare combination in security. This makes it a great choice for organizations that want to make a splash — especially after a major organizational change (e.g., post-breach, new CISO). 

But when IAM is done poorly, it creates a major cyber risk while damaging relations with the business. Let’s look at “what good IAM looks like” and then talk through best practices for getting there. 

What Good IAM Looks Like 

Table Stakes

• We’re talking about an enterprise with tens or hundreds of thousands of users (there is user scale)
• The enterprise has been around a while (there is application scale) 
• The organization has made some acquisitions over the years (there is tech debt)

The Tech Stack

• Identity Provider (IdP) (e.g., Okta, AzureAD / EntraID) — Storing and managing user identities
• Identity Governance and Administration (IGA) (e.g., Sailpoint, Saviynt) — Assigns end user access, processes user access requests (e.g. approvals, denials, etc.), and provisions permissions
• Directory Service (e.g., Active Directory, or another on prem directory service) — handles all your on-premise authentication/authorization needs

Automated IAM Lifecycle 

1. Identity Creation: When a new person is hired, the HR system triggers creation of an identity, which is synced to the Identity Provider. 

Figure 1. When a new person is hired, the IGA system detects it and creates an identity that then syncs down to the Directory Service.

2. Onboarding: A “birthright” set of minimum privileges is utilized for all users, then Role Based Access Control (RBAC) gives access to systems for more specific families of jobs (HR, Finance, Technology, etc.) or even job families (Retail Manager, Web Developer, Database Administrator, etc.).

Figure 2. The IGA system utilizes the information returned from the HR system to add each new user to the birthright groups then to the mapped RBAC IdP groups and Directory Service groups.

3. Privilege Management: When a user needs additional permissions which haven’t been granted through birthright access or role-based access, that user can request those permissions through IGA’s service catalog. Access approvals are handled through the IGA, and are simple to approve (e.g., email). Speed of access is prioritized over lengthy lists of approvers. Application group permissions are requested and approved at the application role level (when supported through System for Cross-domain Identity Management [SCIM]).

Figure 3. A user requests access to specific applications and application privileges through the IGA system, which then adds users to IdP and Directory Service groups.

4. Adaptation to Changing User Roles: Automated user access reviews completed by current user and/or user’s manager. Triggered at least annually and (when the capability exists) when an HR job title changes. The IGA system typically has the capability to automate the process of scheduling access reviews, sending notifications to reviewers, and tracking completion responses. 

5. User Off-boarding: A change in the HR system triggers account disabling, deletion, and license revocation in the IAM systems.

Figure 4. When a user’s employment status is changed, the IGA system detects it and disables/deletes an identity.

Benefits of an Automated IAM Program

An automated IAM program improves enterprise security through the following controls. 

• Secure protocols are used. Integration with the Identity Provider (SAML and OIDC protocols) are prioritized over legacy protocols (LDAP). 
• Multi-factor Authentication (MFA) is enabled for (nearly) every identity. 
• Access reviews are being conducted for every user (by themselves and/or their manager). 
• Password policies on length are set.  
• Privileged Access Management (PAM) is integrated with the IdP and provides “Just-in-Time” (JIT) admin access to workstations and servers with automatic password rotation policies. 
• Force IdP authentication whenever possible (don’t also allow simultaneous local authentication). 
• Out-of-Band Management (OOBM) accounts are used on critical IT infrastructure systems as the exception to the above rule. They ensure access in the event a ransomware attack impacts the ability to log in to apps through IdP. 
• Improved Threat Detection from centralized access logging enables faster detection of suspicious behaviour. 
• Role Based Access Control (RBAC) helps ensure least privilege is granted, preventing over-assignment of access which limits the potential impact of an attack. 

Figure 5. The different levels of access control help simplify management overhead while ensuring resources have access to the least privileges necessary.

An automated IAM program improves operational efficiency through the following measures. 

• Reduced administrative overhead frees up the IAM team to advance important initiatives faster.  
• Faster access request lead times allow users to access resources with minimal delays which increases user productivity. 
• Simplified compliance audits through centralized audit trails and reporting capabilities free up the IAM team to progress important initiatives more quickly.
• Improving the user login experience through Single Sign On (SSO), self-service access requests, and self-service password resets increase user productivity while potentially reducing the need for Tier 1 support personnel.

Getting to “Good”

Project Structure

If the organization has the luxury of choice, it is recommended to get IGA and end-to-end automations in place before migrating huge amounts of users to SSO. Otherwise the IAM team’s capacity will be significantly lowered while dealing with operations. Here’s the ideal tech stack rollout order: 

Figure 6. A very rough timeline of how to structure the IAM Initiatives. The longest item is typically onboarding applications to the system (SSO Onboarding & Rollout). 

1. Identity Provider (IdP): Start with the IdP as it forms the foundation of the IAM system. 
2. IGA (Identity Governance and Administration): Once the IdP is in place, implement the IGA solution. This allows automated user lifecycle management, access certifications, and enforced policies for privileged access. 
3. PAM (Privileged Access Management): Implement PAM last, as it builds upon and extends the foundation established by IdP and IGA. 
4. Onboard a foundational application (e.g., M365) and incrementally roll out security controls (e.g., MFA rollout) 

Once the tech stack is set up and security controls are enabled, efforts shift to migrating applications and authorization to the Identity Provider (e.g. Federated Access, Single Sign-On, etc.)

• First ensure the tech stack is set up correctly to automate most of the IAM lifecycle and the security controls are automatically enforced through the toolset
• Migrate several of the easiest applications without many (or any) users first to build up team muscle memory
• Migrate applications that are easy technically, but have progressively more users
• Save difficult, critical application migrations with lots of active users for last
• Track applications that are unable to integrate with IAM for technical or business reasons in a risk register

Common Mistakes

Application onboarding to an Identity Provider is still a very manual process, with a wild-west of different business applications supporting different levels of integration, features, and self-service onboarding. Some applications are a breeze, while some require a degree of teamwork and performance on par with game 7 of the NBA Finals. Here are some common mistakes to avoid: 

• Not prioritizing Identity Provider / SSO application onboarding effectively — Don’t start with the most critical, high visibility, difficult applications. Practice makes perfect. 
• Getting stuck on hard application migrations — skip it and come back when the team is more experienced. 
• Ineffective communication — Communication is what makes or breaks relationships for this kind of project. When possible, decouple it from the engineering work (set up authentication in parallel and communicate after testing is validated). 
• Not partnering effectively cross functionally — the team that meets daily should include cross-functional team members from Corporate Communications, Cyber Risk, Help Desk, the specific application team, and anyone else that touches the project. 
• Doing big “go lives” — when supported, always prefer a soft transition where the old authentication method continues to function alongside the new. 
• Not tackling tech debt — If there are already several existing IdP providers across the environment, aggregate them early, free up licenses, and show tangible savings to the business
• Not automating enough— automate everything possible to free up the team’s time for important work

Final Notes

Creating an IAM program that is automated is the reasonable way to handle IAM at an enterprise with scale. It increases security effectiveness, increases the capacity of personnel to support other security initiatives, all while increasing user productivity and happiness. Done well, it is a “win-win” and is utilized to build strong relations between security and the rest of the business, enabling more effective partnership on future projects.