Some privileged accounts have human users, while machine accounts (applications, services, etc.) are associated with non-human identities. Additionally, other privileged accounts may only provide slightly higher levels of access and entitlements as compared to a stand user account. Other privileged accounts, such as the root account in Unix and Linux, may enable the user to takeover an entire system and perform any action. Here are some of the most common types of privileged accounts:
1. Domain Admin Accounts
The most important privileged accounts in your environment are admin accounts with unrestricted access to virtually any and every asset. These are typically domain administrator accounts and are the highest value to a threat actor. Organizations should strive to minimize the number of domain administrator accounts, who has access to them, and place all of them under privileged access management.
2. Privileged User Accounts
This represents a broad category that includes accounts with a range of different entitlements. Privileged user account access can be broad or granular and can also change over time. These accounts may also provide vendor access.
3. Local Administrator
This is the default user account for system administration on Windows. Each Windows computer has an administrator account (SID S-1-5-domain-500, display name Administrator). The administrator account is the first account created during the Windows installation. However, macOS devices may also use a local administrator account. Local admin accounts provide far more privileges than needed for routine computing (word processing, emailing, gaming, internet searches, etc.). This excess privilege provides a massive attack surface, particularly when you consider all such accounts that may exist across the enterprise. The annual Microsoft Vulnerabilities Report has found removing local admin rights alone can mitigate 75% of vulnerabilities--even in the absence of patching.
4. Non-human Automation Accounts
These accounts are associated with an application, operating systems, database, service, network device, etc. that is shared among multiple assets to enable functionality. While non-human automation accounts generally do not have blanket administrative rights, the compromise of one asset with the shared account can easily be used for lateral movement. In general, the existence of shared accounts represents a poor security practice. Yet, shared accounts persist because they are offering the most practical method to enable a use case.
5. Service Accounts
Service accounts are used for running services and related operations in a Windows environment. Service account credentials often lack the ability to log in locally, yet can be abused or misused to compromise the operating system or an application. As non-human accounts, these accounts often fly under the radar when it comes to security oversight.
Service accounts are generally a form of shared account that, depending on the application, can be shared on multiple assets to operate as a single resource.
When service accounts are placed under management by a PAM solution, changes (such as for credentials) must be synchronized, otherwise, connected resources will not correctly stop and restart their services. It’s imperative to identify all the locations for service accounts and link shared ones together automatically so the accounts can be managed as a group. Otherwise, some accounts could be missed, fail to correctly rotate credentials, and new assets that utilize the same service account will not be placed under proper management, each of which can contribute to security holes and cascading outages.
6. Cloud Accounts
When using the cloud to manage your workloads, accounts created to manage instances, runtime, and resources are based on an identity, entitlements, and permissions model. The dynamic, and often ephemeral nature of computing, can create many planes of cloud privileges. As a function of discovery, cloud accounts should be enumerated across multicloud environments and represented in a common format for risk assessment. By uncovering and onboarding these cloud accounts, you can manage cloud account entitlements and determine when accounts are over-provisioned, stale, or even misused during operations.
7. Application Accounts
Application-to-application (A2A) and application-to-database (A2D) communications and access requests require Application accounts. These requests typically occur autonomously. The application will request (or call) for credentials to log in and the controlling application, database, or server will authenticate and grant the credential request, if defined requirements are satisfied. Application accounts and credentials often suffer from unsecure practices, such as using default and/or embedded credentials.
8. Management Solutions
Technology used to manage, monitor, configure, automate, and install /modify the environment—from directory services to security solutions—should never have shared accounts. Security best practices dictate that access from a user to these solutions should always have a one-to-one relationship.
Thus, all the accounts used by application, network, security, and operating system administrators should all be placed under management. Monitoring this can ensure the one-to-one relationship is kept and all access has appropriate behavior. This encompasses any access that occurs on premise or in the cloud, and any work performed remotely by employees, contractors, vendors, auditors, etc.
9. Specialty Accounts
Specialty privileged accounts created on endpoints, locally, to support re-imaging, the help desk, and other information technology functions, are commonly created. Often, these accounts are created as a local administrator and represent a backdoor into the host by authorized sources.
Due to the ad hoc nature by which they are often provisioned, specialty accounts often lack unique passwords or may have passwords shared with similar devices based on age, geolocation, or owner.
As a security best practice, each one of these specialty accounts should have a unique password. Access should be monitored and managed for each device. This represents a unique challenge since password management solutions are typically unable to establish a network route to a remote host to manage these credentials. Endpoint hardening can also improve security, such as by preventing any inbound connection that could administer these accounts.
10. Accounts with Embedded Credentials
Numerous rationales exist for why a developer, administrator , or even an application, may have credentials embedded in scripts, configuration files, or compiled code. The files could be scripts created by any department looking to automate a task (business logic, etc.), or a third-party program that self-compiles code once a credential is set.
The practice of embedded secrets is well-recognized as a high security risk, so it’s important to discover and onboard these credentials for management. However, once discovered, secrets and passwords stored in files and need added management techniques to replace them or have code recompiled. In addition to identifying embedded secrets during discovery and the associated accounts, PAM solutions can onboard them for management and replace the embedded secrets with API calls or dynamic secrets.
11. Break Glass Accounts
These accounts are also referred to as emergency accounts or firecall accounts. Break glass accounts enable the user immediate access to an account they may not normally be authorized to access. Access may be provided to the highest-level system accounts, such as root accounts for Unix / Linux, or SYS/SA for a database. As these accounts are only meant to be used during emergencies, access is typically time-limited via password expiration, or other measures.
