User access controls are the simplest, but often the most tedious part of maintaining system security. It's a group of administration practices that restricts system access to only those that require it. The increasingly prevalence of single-sign-on authentication tools like Okta and Google, is simplifying the way this is managed.
The starting point is to have a register of key systems; that should include in-house developed product(s) as well as third-party vendor software and your infrastructure. It's a good practice to identify which systems hold sensitive data as you will likely apply a different rigour of access control to the systems accordingly.
For the systems that require restricted access, you should apply user access controls. For SOC 2 and similar standards, this should include your software product(s), core infrastructure, any software development tools, authentication software, customer relationship management software, and other systems with sensitive customer data.
The user access controls that should be applied to these systems, include the following:
Strong authentication: Multi-factor is really an expected minimum authentication control for cloud software in particular. There should also be strong minimum password settings enforced.
New user approval: Before granting new access, ensuring an independent and appropriate level of approval is provided to verify that access is appropriate. This is commonly tracked through a ticketing system, and approval provided users line manager, the defined system owner, or an authorised representative for external organisations. In modern companies, it's often managed more simply through an onboarding checklist and approvals can be less formal with a responsible administrator that adds access, which implies approval (ie. no need for separate approval if the admin is authorised to be the approver).
Terminations process: Access needs to be revoked for terminated employees or users. Sounds simple, right? This fails so often in practice based on the lack of clear process to notify system administrators, identifying all access of the terminated personnel, and carrying out the removal of all access effectively. A terminations checklist is common practice and effective.
Role-based-access-control (RBAC): Designing access privileges to align to user roles, helps ensure the access provided is appropriate. More complex systems may have more variables to the access privileges, which can cause confusion and increases the importance of ensuring the privileges are aligned to each roles requirements.
Segregation of duties: Incompatible duties should be segregated to reduce the risk of fraud or error. If the same person can perform two tasks; eg. develop and release to production, or approve their own actions, they may bypass and undermine the established process requirements.
Periodic access review: Conceptually, a periodic access review is the catch-all for any errors or required changes in the access privileges. It reviews the system access at a point in time to confirm it's correct; including the users and their access rights. It can identify if terminated users weren't removed, the incorrect privileges were given, or just role changes were the access is no longer required.
Restricted privileged access: Every system needs a super-user to be able to administer other users access and troubleshoot any issues in the system. However, the more users have this access, the greater the risk of inappropriate use. This should be restricted to the extent possible, while still ensuring a super-user is always available to support the system(s).
The SOC 2 Perspective
User access controls are an important part of achieving SOC 2, and commonly one of the areas that requires further formalisation to be able to demonstrate the controls for the audit. It's a quite specific area, but has as many related criteria (5 of 33) as we explored in the Perimeter Security post with its much broader technical security controls.
Common Criteria 6.1: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
Common Criteria 6.2: Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.
Common Criteria 6.3: The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.
Common Criteria 6.4: The entity restricts physical access to facilities and protected information assets (for example, data center facilities, back-up media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives.
Common Criteria 6.5: The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity’s objectives.
AssuranceLab's Best Practices Series
AssuranceLab's best practices series, is about highlighting the "real operational benefits" that comes from effective control practices. At best, they support your company culture, provide structure and clarity, and enable scalable growth. At worst, they tick the box of what your customers expect, reduce the reactive "firefighting" and time-wasting, and help you demonstrate your compliance with leading standards like SOC 2 and ISO 27001.
