SOC 2 access control boilerplate policies come with the mention of least privilege access control as the guiding principle for granting access. The language may vary, but generally it’s to the tune of, “Company shall determine the type and level of access granted to individual users based on the principle of least privilege.” Conceptually, it is simple. Just grant people access for what they need, when they need it, and then remove it after they no longer need it. In practice, there’s a lot of gray area and room for interpretation. Namely:
- What does it mean to need something? For example, does an engineer need production access while they sleep?
- What does it mean to give “just the right” access?
- How do you track and remove sensitive access that’s no longer needed?
- How do you grant users access just in time without incurring undue ticketing and manual click-ops calories?
As with most security controls, the first principle is easy but the practical implementation can feel out of reach. With that in mind, we’ve found a few best practices for implementing this control. Here they are:
1 - Birthright access should be minimal and focused on productivity-centric access
Users shouldn’t get access to sensitive systems by default unless they absolutely need that access on a regular and on-going basis. In that case, the access should be extremely right sized; the user should have just the specific role or permission needed for the specific job. We believe birthright access is broken and that, due to the lack of automation, access is generally over provisioned today. Reducing access provisioned on day one will force your company to invest in more automation over time to drive to just-in-time access.
2 - An access control matrix should dictate who can access what
Maintain an access control matrix that references job titles, teams, departments, user types (e.g. employee, contractor), and maps relevant access and permissions into those respective roles or attributes. This access control matrix should also provide for correct approval policies based on the access rights being requested. This access control matrix should be versioned and reviewed by security on an on-going basis with app and resource owners to ensure it remains current.
3 - Sensitive systems and permissions should be gated through requests and provisioned just in time
Automation is necessary here. Sensitive access requests should be gated by role, team, or project. The access should be provisioned when needed. Approvals should be policy driven to ensure that the right person(s) approve access. Everything MUST be logged and auditable on demand.
4 - Remove sensitive access once the justification is lost
Identity compromise is a leading cause of data breaches. The access rights a user has provides the authorization for that identity to access sensitive data or infrastructure. Unused or inappropriate standing permissions are the blast radius that a compromised identity can cause. Think about sensitive access as requiring justification: what’s the person’s role, what project are they working on, are they helping a customer, etc? It’s common, for example, for a customer success manager (CSM) to have access to a customer environment while they’re troubleshooting an issue or on-boarding the client. Once that period is passed, the CSM should not retain access to said environments.
5 - Periodically review sensitive accounts and access rights
Periodic user access reviews (UARs) are a practical and effective security control for discovering and eliminating inappropriate or unused access. At a minimum, UARs should be run on a quarterly basis, but ideally they are executed more frequently for sensitive systems or access rights. Best case, they are contextually executed based on significant events such as changes in a user’s role or in response to a security event.
Moving forward
In addition to being simply a great security practice, implementing least privilege access control is essential for SOC2, ISO, and SOX based compliance frameworks. It can be a bit of work to truly implement these controls and stick to them, but it’s well worth the effort and is justified by the security outcome.