3 Types of Privileged Accounts to Secure in a Transforming Enterprise

August 24, 2023 Ryne Laster

Privleged Access

For security teams managing their enterprises’ privileged access management (PAM) programs, times have changed and what’s considered a privileged or high-risk account has drastically shifted. In turn, the way organizations not only manage privilege, but comprehensively secure it, must also shift.

Historically, organizations have managed their PAM programs by vaulting and rotating credentials on privileged accounts. Security controls are put in place for specific users, such as admins and specific accounts like a domain admin account. This approach no longer satisfies organizational needs.

According to 2,300 IT security decision-makers surveyed in the CyberArk 2023 Identity Security Threat Landscape Report, there’s a significant gap. Sixty-three percent say that the highest-sensitivity access for their organization’s employees is not adequately secured at a time when they expect both human and non-human identities to grow roughly 240% in the coming year.

Security professionals feel this way because privileged access as we know it has evolved (you can have a look at our blog post on this same subject from PAM’s 2017 scrapbook to see an earlier take on that evolution for yourself). The big change catalyst: the types of privileged accounts that need to be secured have expanded in scope and scale, as enterprises made moves to become more digital and cloud based. A fresh approach to PAM programs means understanding the wide range of accounts and their vulnerabilities.

These days there are three categories for classifying privileged accounts:

  1. System accounts
  2. Operational accounts
  3. Application accounts

All these accounts encompass human and non-human identities, each with distinct levels of privilege that require separate management to restrict the attack surface.

Visual breakdown of the three privileged account categories with examples. The three categories are: system accounts; operational accounts; and application/machine accounts.

Let’s dive into the different privileged account types organizations must secure and dynamically provision:

1) Accounts with System-level Privileged Access

System-level privileged access accounts are administrative accounts, often established by the operating system or cloud provider. These accounts possess inherent high-risk characteristics, featuring persistent privileges and predefined passwords, necessitating secure vaulting, deployment in emergency access situations and ongoing monitoring for authorized user access.

Here are a few examples of these accounts:

  • Domain administrator accounts have complete privileged access to all resources, servers and workstations within the domain. The domain admin is the most powerful account in the domain and is installed automatically on the first domain controller and created for Active Directory.
  • Linux root accounts have unlimited access to all programs, files and resources on a designated Linux system, VM or cloud instance running Linux services.
  • AWS root accounts are the first identity created by default in a cloud service provider (CSP), and all CSPs have some root account. They control everything in the instance and are a prime target for bad actors. It’s best practice to vault these accounts and never use them for day-to-day tasks. Instead, keeping the AWS example, create an AWS IAM user account with varying privileges to adhere to the principle of least privilege (PoLP). You can replace the accounts with federated identities and grant permissions using zero standing privilege (ZSP) platforms.
  • Azure active directory (AAD) global admin accounts are like AWS Root accounts – they are the most-privileged account tied to your Azure tenant. Avoid using these accounts for day-to-day tasks; instead, vault and centrally manage them using a PAM solution.

2) Operational Accounts with Privileged Access

Operational accounts with privileged access roles are created for SaaS applications and CSPs and they should be used for day-to-day tasks that have varying permissions levels. Following a ZSP north star, these accounts do not need standing privileges and should be provisioned just-in-time (JIT).

These accounts include:

  • SaaS business application accounts are created administrative accounts used for, cloud consoles, CRMs, or ERP systems privileged accounts because they can access sensitive data and business-critical information. These accounts can be accessed by employees, vendors and contractors, and they hold varying entitlements and access levels, making them significant threat targets.
  • Privileged personal accounts, such as personal admin or -A accounts, are used for server administration, deployment and infrastructure support.
  • AWS IAM user accounts are created by an AWS root user with varying levels of entitlements and attributes to carry out day-to-day tasks. These accounts can be used by humans, applications or machine-based identities and can be assigned to role-based access groups. Users needing access to the AWS console should have an IAM account to adhere to the principle of least privilege and avoid sharing credentials.

3) Application or Machine Accounts – Non-Human Accounts with Privileged Access

Application or machine non-human accounts are used for machines to communicate, applications, RPA bots, container services and IoT/OT devices. These accounts also bring out additional threats to the organization.

A few types of these accounts are:

  • Service accounts, which are found in Unix and Linux, Windows and CSPs. They’re created to manage tasks, application pools, run virtual machines (VMs), scripts, automated services and interact with operating systems. Service accounts and their dependencies should be centrally managed, vaulted, and their access should be monitored and audited.
  • Robotic process automation (RPA) accounts emulate humans and are used to build, deploy and manage software robots to carry out automation tasks. These non-human accounts are privileged and often share credentials to extract data, interact with cloud services and APIs. RPA technology introduces a new attack surface given the level of privilege needed to do their job.

Secure Identities and Shutdown Attackers

High-risk access is an ongoing issue as organizations scale. Whether that be on-premises, cloud consoles or SaaS-based applications – privilege is everywhere and managing an evolving PAM program means securing access for modern use cases.

With this in mind, today’s attack surface has evolved and become more complex – and how organizations secure their privileged accounts must remain in step with effective security controls. Implementing an identity security framework with intelligent controls at the center will allow you to secure the keys to the kingdom and enable operational efficiencies for your users and extended workforce.

Learn how CyberArk can help you address modern use cases for your PAM program – and keep your organization safe from identity-based threats.

Ryne Laster is a product marketing manager at CyberArk.

Previous Article
Using Kubelet Client to Attack the Kubernetes Cluster
Using Kubelet Client to Attack the Kubernetes Cluster

In this blog post, we are going to look at the Kubernetes agent, kubelet (see Figure 1), which is responsib...

Next Article
Introducing the CyberTalk with CyberArk Podcast Series: On-the-Go Cybersecurity Insights
Introducing the CyberTalk with CyberArk Podcast Series: On-the-Go Cybersecurity Insights

Ninety-one percent of cybersecurity practitioners agree they must keep up with their skills, or the organiz...