As work ebbs with the typical end-of-year slowdown, now is a good time to review user roles and privileges and remove anyone who shouldn’t have access as well as trim unnecessary permissions. In addition to saving some unnecessary license fees, a clean user inventory significantly enhances the security of your SaaS applications. From reducing risk to protecting against data leakage, here is how you can start the new year with a clean user list.
When employees leave a company, they trigger a series of changes to backend systems in their wake. First, they are removed from the company’s identity provider (IdP), which kicks off an automated workflow that deactivates their email and removes access to all internal systems. When enterprises use an SSO (single sign-on), these former employees lose access to any online properties – including SaaS applications – that require SSO for login.
However, that doesn’t mean that former employees have been fully deprovisioned from all the SaaS applications. Enterprises must manually deactivate or delete users from their SaaS applications for all apps that aren’t connected to the SSO, as well as for any user that has local access to an app that is connected to the SSO. This issue is particularly acute with high-privilege users. Many apps require that they have local access in the event that the SSO goes offline.
Any offboarded user with access to corporate SaaS apps retains 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.
Download this Offboarding guide for step-by-step instructions in offboarding employees from your SaaS stack
Overpermissioning any user unnecessarily expands the attack surface and needlessly introduces a higher level of risk to the application. It’s the user’s permissions that control the level of access each employee has within an application. Should a user account be compromised, the threat actor would have an equal level of access as the user who was compromised.
A team leader would likely need administrative permissions to add new users, open projects, and otherwise control usage of the application. Employees using the application might need read/write permissions to fulfill their role, while support personnel might only need read permissions or the ability to download reports.
With the year winding down, it’s a good time to review user permissions and ensure that they are aligned with their role. Enterprises should implement the principle of least privilege (POLP), to ensure that employees have the right level of access to do their job. For apps that include group functionality, assign like-users to groups with preset permissions to standardize permission sets. For other apps, it’s worthwhile to review user permissions and trim access to only those functionalities that are needed.
Dormant accounts, which are accounts that are unused, typically fall into one of three categories.
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. This is a combination ripe for abuse. Unused employee accounts could provide access to threat actors following a phishing attack, where the employee doesn’t even remember all the applications to which they have access. Meanwhile, security teams have no visibility into external users and whether they are still involved in the project.
As enterprises move through the holiday season, it behooves them to review dormant accounts and take the necessary measures to investigate and evaluate their risk. When indicated, these accounts should be disabled or canceled.
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. Furthermore, using a shared login prevents the use of MFA and SSO, two critical tools used to secure SaaS applications.
Shared accounts also make it difficult to detect threats stemming from an account. The data used to detect threats is based on normal usage. However, if an account is often accessed from multiple locations, it is unlikely to trigger an alert if accessed by a threat actor.
While it isn’t easy to detect shared accounts, enterprises 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 closely reviewing user behavior analytics are two ways to detect shared user names.
Spending the time now to discover shared accounts will help keep SaaS applications more secure in the coming year and long into the future.
For the full Offboarding Guide, click here.
Reviewing application rosters manually and comparing them to 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.
Using an SSPM’s user inventory, like Adaptive Shield’s, enterprises can quickly identify user accounts that haven’t been accessed over a set period of time, find external users with high permission sets, and detect users who have been removed from the IdP. SSPMs are also capable of associating users with devices to further limit risk.
As you prepare for 2024, introducing an SSPM is the most effective and efficient way to monitor users and know who has access to what within your SaaS stack.
