Identity and access management (IAM) is a critical component of cloud security. A key part of IAM is ensuring that user access is promptly updated when users change roles or leave the organization. This article explores the CSA CCM control IAM-07 which provides guidance on de-provisioning and modifying user access in a timely manner.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full CCM here. The CCM provides a controls framework for cloud computing and is considered an industry standard. This specific control falls under the Identity & Access Management domain.

For more background, check out the AWS IAM documentation:

• IAM Users
• IAM Best Practices

Who should care?

This control is relevant for:

• Cloud security engineers responsible for designing and implementing IAM solutions
• IT managers overseeing employee onboarding/offboarding processes
• Auditors assessing the effectiveness of IAM controls
• Business owners worried about unauthorized access to sensitive cloud resources

What is the risk?

Failing to promptly update user access introduces several risks:

• Ex-employees retaining access to sensitive systems and data
• Users accumulating excessive permissions over time as they change roles
• Attackers compromising dormant accounts to gain a foothold
• Regulatory non-compliance (e.g. SOX, HIPAA, PCI DSS)

While unlikely, a disgruntled ex-employee with lingering access could cause significant damage by stealing IP or deleting critical resources. More commonly, unused accounts with excessive permissions are a prime target for attackers.

What's the care factor?

For most organizations, prompt de-provisioning and access modification should be considered essential, not optional. The risks of lingering access are simply too high to ignore.

However, the level of effort required depends on your scale and sensitivity:

• A 10 person startup can probably get by with a manual checklist
• A 1000 person enterprise will need automated processes to keep up

The more sensitive the data and resources, the more critical it is to get this right. Healthcare and financial firms should be especially diligent.

When is it relevant?

This control is relevant in almost any situation where you have employee turnover or internal transfers. That covers the vast majority of organizations.

It may be less critical if:

• You have very low turnover
• Employees don't have direct access to cloud resources
• Your resources are mostly public facing (e.g. a static website)

What are the trade-offs?

Implementing rigorous de-provisioning and access modification has several costs:

• Engineering effort to integrate HR systems with IAM
• Reduced agility as access changes require more process
• Productivity loss if access is removed prematurely
• Increased support burden as users request access

In general, the security benefits outweigh these costs. But taken to an extreme, overly restrictive policies can become counterproductive. The goal is prompt updates, not draconian lockdown.

How to make it happen?

1. Define a standard offboarding/role change process with HR and IT
2. Identify all systems and resources that require de-provisioning
3. Set a target time frame for access removal (e.g. 24 hours)
4. Integrate your HR system with your IAM solution via SCIM or SAML JIT
5. Configure automated de-provisioning rules based on HR attributes
6. For systems that don't support integration, assign clear owners
7. Establish manual de-provisioning procedures with SLAs for those owners
8. Implement an exception process for cases that require longer access
9. Set up regular access review and certification campaigns
10. Monitor and alert on accounts that violate age and usage policies

For AWS specifically:

• Use AWS IAM Identity Center (formerly SSO) for centralized access management
• Integrate IAM Identity Center with your IDP via SAML
• Use permission sets and assignments to grant access
• Automate de-provisioning by managing assignments via SCIM
• Enable AWS CloudTrail and send logs to a SIEM for monitoring

What are some gotchas?

• IAM Identity Center requires specific permissions to automate provisioning:
  • sso:CreateUser
  • sso:UpdateUser
  • sso:DeleteUser
  • identitystore:DescribeUser
  • identitystore:DescribeGroup
  • identitystore:ListGroups
• Automated de-provisioning can cause outages if not thoroughly tested
• Some systems may require local account cleanup beyond IAM
• Certain high-privilege users (e.g. C-suite) may need exceptions to policy
• Shared/generic accounts cannot be de-provisioned without coordination

See the IAM Identity Center API Permissions for more.

What are the alternatives?

If full automation is not feasible, you can still improve with:

• Detailed offboarding checklists and SLAs
• Scheduled access review and cleanup campaigns
• Proactive monitoring for unused or excessive access

These alternatives are more manual and error-prone but still better than nothing.

Explore further

• AWS IAM Identity Center Provisioning
• CIS AWS Foundations Benchmark - IAM controls
• Zero Trust: Rethinking access control

The CIS benchmark includes specific IAM hardening recommendations that complement this CCM control. Zero Trust principles can also inform your overall approach to IAM.

‍