CIS Controls™ for SaaS – Part 2: Account and Access Control Management
You are reading the second post in our series on applying CIS Controls™ to SaaS. If you are only joining now, here is what you have missed:
While SaaS takes away many controls that you would be responsible for in on-premise and even cloud systems, account and access control management largely still remains your domain as the user. As the security of the infrastructure and the software itself lies with the SaaS provider, account and management become the most important responsibility of yours when it comes to essential hygiene.
Control 5: Account Management
Safeguard 5.1: Establish and Maintain an Inventory of Accounts
An inventory of SaaS accounts is important but not quite as straightforward as it might seem. Not only is it hard to maintain visibility of accounts across many SaaS applications but members of your organization may also have signed up to SaaaS application without prior approval and the SaaS application itself may not be listed in your inventory of service providers (cf. Control 15: Service Providers).
The ideal solution is an automated process which monitors for both new SaaS connections as well as the accounts in all SaaS applications in use. While a manual inventory is possible, it is important to keep it up-to-date.
Safeguard 5.2: Use Unique Passwords
As you don’t have control over password policies in the SaaSes, you will have to address this on an organisational policy level. Due to the nature of global availability of SaaS applications, it is important though that passwords are not reused to thwart credential stuffing attacks using credentials from past breaches. The recommendation in the official CIS documentation is a password of at least 8 characters in the presence of MFA and at least 14 characters in the absence of MFA.
Safeguard 5.3: Disable Dormant Accounts
With the large number of SaaS applications modern organisations make use of, overprovisioning of accounts is a common problem. A user may get an account in a specific SaaS application due to policy or accounts aren’t removed after temporary use. If possible, configure the SaaS application to disable dormant accounts automatically if at all possible. If the SaaS application does not support automatic disabling of dormant accounts, use an external solution for monitoring account activity and disabling dormant accounts or conduct regular audits at least once every 45 days.
Safeguard 5.4: Restrict Administrator Privileges to Dedicated Administrator Accounts
The main concern here is that administrator accounts should only ever be used for administrative tasks. When users who fill these administrator roles are not acting as administrators, they should be using accounts of lower privileges.
While it is not always feasible in SaaS applications to separate accounts like this because of insufficient granularity of permissions, this rule should still be applied wherever possible.
Control 6: Access Control Management
Safeguard 6.1: Establish an Access Granting Process
Wherever possible, access should only be possible via federated accounts preferably with SaaS accounts being managed via SCIM. If federation is possible, fall back to provisioning and deprovisioning local accounts in the SaaS via SCIM. If SCIM is not supported, a central account monitoring process is preferred over periodic manual auditing of SaaS accounts.
Safeguard 6.2: Establish an Access Revoking Process
If you use identity federation or SCIM, you can revoke access centrally. If you only have a central monitoring solution, use it to ensure that no access to SaaS applications is accidentally retained.
Safeguard 6.3: Require MFA for Externally-Exposed Applications
As SaaS applications are externally-exposed by definition, this safeguard requires all SaaS accounts to have MFA enabled. Ideally, this also covers guest accounts even if they have limited access.
Safeguard 6.4: Require MFA for Remote Network Access
As Safeguard 6.3 already requires MFA for all accounts, this does not introduce any new requirements.
Safeguard 6.5: Require MFA for Administrative Access
As Safeguard 6.3 already requires MFA for all accounts, this does not introduce any new requirements.
