How to easily identify shared privileged user accounts among staff?
Sharing privileged user accounts among staff is one of the most critical SaaS risk blind spots. Find out why and how to avoid it.
What’s a shared privileged user account for SaaS?
This is when staff share logins to access admin and global admin accounts for productivity suites such as Office 365 and G Suite, and other SaaS platforms, e.g. Salesforce, bambooHR, so that they can have easy access to do their jobs. It usually happens in businesses with distributed staff working from different locations or lean IT teams working on different shifts. It also happens in larger organizations where admins in business units share credentials to external consultants and contractors to access SaaS applications to perform tasks, because it would take a lot more administrative steps to go through IT to have them set up as internal users.
This may not sound like a big deal, but the potential consequences could be severe while the issue itself can easily be avoided.
What’s the big deal?
Security audit and incident investigation
Think about a scenario where George, Amanda and Lucy in the Finance department shared a Highly Privileged User account, say email@example.com, to log into quickbooks and a common Gmail inbox to take care of invoices and billing. From a business perspective, this may make sense because it gives each of them flexibility to act independently while the other is not available or off-shift. These privileges minimize codependency to respond to critical tasks. But then the credentials of the account were stolen through email phishing, leading to a series of fraudulent transactions. It would become very challenging to prove what happened, who did what and who was accountable for audit and investigation purposes. Who would then be responsible for the data breaches?
Protecting the account credentials and preventing hacking attempts
Most of us have probably seen a post-it-note stuck on a PC screen with a shared login username and password written on it at some stage in our career. We are all now aware it’s not safe to do that, not to mention the number of passwords an employee has to store or remember has increased, so it’s not practical to have so many notes posted around. Many end up using the same passwords across accounts, or record them in shared spreadsheets and docs. Hackers only need to compromise one account in a SaaS platform to get access to other SaaS platforms because they can use the same credentials. There are also internal threats. Using the example above, if George leaves the Finance team and his email access is correctly deprovisioned from the company’s G Suite domain, he could still log in firstname.lastname@example.org, using the shared privileged credentials. He could even have set up an auto email-forward rule from this email account to an external email address. The IT department would not know about this. Neither would Amanda and Lucy.
Another security challenge with shared privileged accounts is the inability to enforce MFA, which is widely recognised as being the most effective control in preventing Business Email Compromise & Password Reuse attacks. When MFA is turned on, a breached password does not immediately lead to a system compromise and you can address it before it escalates.
What are the signs to spot shared privileged accounts?
Common signs are:
Non-named accounts: common non-named accounts such as email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org. These are “non-named” as they are not attached to specific users (e.g. George, Lucy, Amanda) within the organizations but tend to be shared amongst small groups of users. Often, shared non-named accounts have access privileges such as: the ability to edit and change settings; add, delete users; authorize transactions.
Non-federated / cloud backdoor accounts: these are accounts in a SaaS solution that are not federated because they were created by admin before federation was enabled and tend to be default admin accounts, they are also often external and guest accounts. They will often be missed in privileged user audits.
No MFA enabled: as mentioned above, shared accounts often have MFA disabled for easy access.
Use Detexian to find out:
all non-named accounts and non-federated accounts that are still enabled;
if they have recently been active;
if they carry administrative privileges;
with or without MFA being enabled or enforced.
We also recommend customers replace these non-named privileged accounts with individual named accounts with MFA enabled and enforced. For example, Lucy who previously was a shared privileged account owner of email@example.com, can now have an additional named privileged account firstname.lastname@example.org in addition to a non-privileged account email@example.com.