As work winds down with the usual year-end slowdown, now is a good time to review user roles and privileges and remove anyone who doesn’t have access as well as trim unnecessary permissions. In addition to saving some unnecessary license fees, a clean user inventory greatly improves the security of your SaaS applications. From reducing risk to protecting against data leaks, here’s how you can start the new year with a clean user list.
How Offboard Users Still Have Access to Your Apps
When employees leave a company, they trigger a series of changes in the backend systems when they get up. First, they are removed from the company’s identity provider (IdP), which begins an automated workflow that deactivates their email and removes access to all internal systems. When businesses use SSO (single sign-on), these employees will previously lose access to any online properties – including SaaS applications – that require SSO for login.
However, that does not mean that former employees are completely deprovisioned from all SaaS applications. Enterprises must manually deactivate or delete users from their SaaS applications for all apps that are not SSO connected, as well as any user who has local access to an app that is connected in SSO. This issue is especially severe for users with high privileges. Many apps require that they have local access when SSO goes offline.
Any users who are not on board with access to corporate SaaS apps retain their ability to login and use the application. That means they can download data, make changes, delete files, or even share their login credentials with competitors.
Ensure the Right Size Permissions
Over-authorizing any one user unnecessarily widens the attack surface and unnecessarily introduces a higher level of risk to the application. These are user permissions that control each employee’s level of access within an application. If a user account is compromised, the threat actor has the same level of access as the compromised user.
A team leader may need administrative permissions to add new users, open projects, and otherwise control application usage. Employees using the application may need read/write permissions to perform their role, while support staff may only need read permissions or the ability to download reports.
With the end of the year, it’s a good time to review user permissions and make sure they match their role. Businesses must implement the principle of least privilege (POLP), to ensure that employees have the right level of access to do their work. For apps that include group functionality, assign similar users to groups with preset permissions to standardize the permission set. For other apps, it’s worth reviewing user permissions and restricting access to only essential features.
Remove Dormant Accounts
Dormant accounts, which are accounts that are not used, usually fall into one of three categories.
- Admin accounts – used to initially set up the application, usually for multiple users. These dormant accounts have many privileges.
- Unused internal accounts – accounts of employees who no longer need or use the application. Access is based on the employee’s role.
- Inactive external accounts – external user accounts that are not in use. This access is based on the permissions granted by the user.
The risk inherent in these accounts is significant. Admin accounts used by multiple users tend to have easy-to-guess usernames, easy-to-remember passwords, and local access. It’s a combination ripe for abuse. Unused employee accounts can give access to threat actors after a phishing attack, where the employee may not even remember all the applications they had access to. On the other hand, security teams have no visibility of external users and whether they are still involved in the project.
As businesses operate during the holiday season, they should review dormant accounts and take the necessary steps to assess and assess their risk. If indicated, these accounts should be disabled or canceled.
Implement Account Sharing Prevention
When teams use a shared username to reduce license fees, they unknowingly create an additional security risk. Shared accounts are nearly impossible to fully secure. As employees join and leave the team, the number of users who know the account credentials increases. In addition, the use of shared login prevents the use of MFA and SSO, two critical tools used to secure SaaS applications.
Shared accounts also make it difficult to identify threats originating from a single account. The data used to detect threats is based on normal usage. However, if an account is frequently accessed from multiple locations, it is unlikely to trigger an alert when accessed by a threat actor.
Although it is not easy to detect shared accounts, businesses can put measures in place to prevent and detect account sharing. Requiring MFA or SSO, for example, makes it difficult for users to share accounts. Security teams can also review user behavior analytics that indicate account sharing. Monitoring IP address logins or delving into user behavior analytics are two ways to identify shared usernames.
Spending time now to discover shared accounts will help keep SaaS applications more secure in the coming year and into the future.
Automating Monitoring and User Management
Reviewing the application rosters manually and comparing them with the IdP is a tedious task. So is checking permissions, reviewing dormant accounts, and looking for signs of account sharing. Introducing a SaaS Security Posture Management (SSPM) platform automates the process.
|Figure 1: User Inventory provides an in-depth view of each SaaS user
Use an SSPM user inventory, such as Adaptive Shield’s, businesses can easily identify user accounts that have not been accessed for a specified period of time, find external users with elevated permission sets, and detect user taken from the IdP. SSPMs can also associate users with tools to further limit risk.
As you prepare for 2024, introducing SSPM is the most effective and efficient way to monitor users and know who has access to what within your SaaS stack.