A typical organization has far more privileged accounts than most people realize. The no-brainers are what I call built-in superuser accounts like “Administrator” and “root”. These accounts exist on every device and system at the OS or firmware level, at the domain level in Active Directory (AD), and in some applications, like the sa account in SQL Server.
But then there are the custom superusers that have the same level of authority as root or Administrator, but are customer created accounts. These accounts exist at the same levels as built-in superusers. We are talking about members of the Administrators group on Windows computers, members of Domain Admins at the domain level, users with ALL authority in the sudoers file in Linux at the application level, users in the SQL Server role Sysadmin, SharePoint farm administrators group, and similar administrative roles in Exchange.
But don’t overlook the cloud security implications. Cloud applications and accounts have superusers too. For instance Azure has administrator roles at the tenant, account and subscription levels, and even within resource groups.
Finally, there are the subsidiary admins. These are privileged users with less than superuser ability, but who still have a powerful subset of admin permissions like:
- Password reset
- User account maintenance
- System maintenance operations
- Group membership maintenance
- Control over permissions to certain resources
- Audit log access
All of these are privileged accounts – within the IT department. The granularity of delegation and how it works varies greatly between different systems, applications, and clouds.
But privilege isn’t unique or limited to the IT department—even though you might think so based upon most of what’s written about privilege management and the scenarios usually discussed. Those admin accounts reflect an arbitrary limit on what we consider privileged accounts that corresponds to the boundaries of the IT department. There’s no good reason for this. Risk and privilege remain risk and privilege regardless of the department involved.
Here are some examples of things outside the IT department we should regard as privileged and for which we should extend the same level of protection as we do for accounts with a similar risk level inside IT:
- Banking transactions
- SCADA
- Software build servers
- Automated process and manufacturing control systems
- Commodities and securities trading
The pyramid below portrays not just the relative ranking of privileged account types, but also conveys the proportion in terms of account quantity at each level.
Here’s something that makes some of these scenarios even more critical to protect--the applications are frequently old and never designed to withstand today’s threat actors and other cyber risks. Some of these process control and manufacturing systems have no security at all. So how do you protect them other than putting them on an isolated network and controlling access with physical security?
Privileged access management (PAM), including privileged session management (PSM) technology, typically used to protect admin accounts inside the IT department is actually the perfect solution to extend to privileged users outside of IT and for protecting vulnerable applications as well. If you’re interested in learning more, BeyondTrust’s Jason Jones and I explored this issue in depth in our recent webinar, which you can now watch on-demand here: Securing Privilege Outside the IT Department: High Value Transactions, Vulnerable Applications and Access to Critical Information.
