Five tips for Privileged Access Management metrics

"If a privileged account is accidentally compromised or maliciously used, there is a much greater risk to the organisation. It can lead to data loss, system outage, and more. The risk to your environment, if not managed well, can be catastrophic." - David Fairman

In this instalment of Metric of the Month, we caught up with David Fairman to discuss privileged access management (PAM) metrics. David is an experienced CISO, having run several successful security programmes across the globe. He's a valued member of our advisory board, Continuous Controls Monitoring advocate, and security metrics expert. In this article, he talks about PAM in general, then digs a bit deeper to highlight some particularly useful privileged access management metrics and provide a quick 5 step guide to improving your PAM programme.

What is privileged access management?

As a very basic, fundamental concept, privileged access management (PAM) is about managing accounts with a higher than normal level of privilege. One of the key tenets of cybersecurity is ‘least privilege’, meaning no user or service should have more privilege than it requires. PAM is a huge part of achieving that. "It’s important to note", says David, "that PAM is a subset of identity and access management (IAM). All accounts, whether human or non-human, need to be managed in some way." These accounts are typically used by what we would consider privileged staff, such as IT systems administrators, network administrators, or application developers. Many people think that the most important accounts belong to executives, but the reality tends to be that admin accounts with much broader access privileges pose a greater risk to the business. A typical end-user will log into an application with traditional credentials (usually via a GUI) and they are constrained by the application they’re using. But a privileged user is generally at a system level and has direct, significant access that allows them to do or change multiple things on a system (an operating system or host application), including configuration and security changes, or manipulating data. "If a privileged account is accidentally compromised or maliciously used, there is a much greater risk to the organisation. It can lead to data loss, system outage, and more. The risk to your environment, if not managed well, can be catastrophic." Most regulators and frameworks specifically require effective PAM systems to be in place and operational. In NIST, for example, PAM would generally come under the Protect function (Identity Management and Access Control), or CIS Controls 5 & 6 (Account Management and Access Control Management). That’s the concept, but in practice, it can be particularly difficult to manage.

Challenges of privileged access management

You need to find every privileged account across the environment. Go back and specifically analyse what commands can be executed by an account, regardless of naming conventions or labels.

"Part of the challenge", says David, "comes from defining ‘elevated privilege’. Who determines what privileges are normal and what are significant or risky? I worked for an organisation that said anything over read-only access to a system that wasn’t controlled through an application interface was classed as privileged access. That’s a very broad, wide-sweeping statement. And it means there is a lot of privileged access to manage in that use case." Managing ‘everything that’s more than read-only' is probably too much for any organisation that’s not extremely mature. But there are different levels of privilege. So where do you find the balance of what's privileged or what’s standard? What should be governed under the traditional IAM programme and then what needs to fall under a specific PAM programme? They may be simple questions, but there are often complex answers. Once you have defined what is considered privileged, there is a further challenge in identifying the accounts that fulfil those criteria. "You need to find every privileged account across the environment. Go back and specifically analyse what commands can be executed by an account, regardless of naming conventions or labels. There are some easy wins. Typically root accounts and Windows admin accounts are highly privileged, but beyond that there are many in between. For example, a backup operator who’s been given delegated privileges – still risky, but not as much as a full admin. But on the whole, this is a very analysis-heavy, generally manual activity.’"

Building that inventory is not a one-off activity. It needs to be constantly updated and reviewed so you know how complete and accurate it is.

There are a few metrics to keep top of mind here, too. "Building that inventory is not a one-off activity. It needs to be constantly updated and reviewed so you know how complete and accurate it is." How are you identifying new accounts that pop up on the system? How do you validate whether these are classed as privileged? Can you track and prove that they have been created and approved under the correct governance process? "Similarly, you need to know the coverage of your controls across those accounts – are they all implemented with the appropriate controls?" Again, these kinds of questions can be difficult to answer.

What are your top privileged access management metrics?

David highlighted two particularly valuable PAM metrics.   First: Privileged accounts without an identified owner.  

When you are provisioning privileged accounts, you need to be able to have an accountable owner and ensure you have traceability back to the use by an individual.

Someone needs to be ultimately responsible for each privileged account. They should be able to advise whether it is being used appropriately and is still necessary. If you are able to delete the account, it can help support ‘least privilege’, as well as minimising the attack surface and therefore reduce overall risk to the organisation.   It’s important to get accountability for all accounts and furthermore, ensure there is an audit trail for the use of accounts, especially shared accounts. "When you are provisioning privileged accounts, you need to be able to have an accountable owner and ensure you have traceability back to the use by an individual." Second: Privileged account sessions without a corresponding ticket. 

You want to reconcile each use of a privileged account with a ticket. Fundamentally, a privileged account being used without a corresponding ticket indicates suspicious activity or potential compromise.

Nobody should ever change anything in a production environment unless a change control ticket (in the event of planned maintenance) or incident ticket (in a break-glass scenario) has been created. In the ideal process, a ticket is created. An admin gets issued credentials to a privileged account for X time. They fix what needs to be fixed. They hand the credentials back. The credentials change so the admin no longer has access.   It’s all about controlling the windows where the accounts are being used. There are extra controls in place, such as session recording, keystroke logging, or electronic vaults. Ideally, the credentials are never given and the PAM tool such as CyberArk will proxy the use of the account at the time of use so the end user never has the details of the accounts credentials.  "You want to reconcile each use of a privileged account with a ticket. Fundamentally, a privileged account being used without a corresponding ticket indicates suspicious activity or potential compromise." Here’s an example dashboard of what these metrics might look like. The goal for this dashboard is to highlight the number of privileged accounts (usually, the fewer the better) and help to trend privileged accounts without owners and sessions without tickets down to zero.   David shared an example of a major financial institution breach that really highlights why these metrics are so important to measure for a PAM programme. A privileged account was compromised and used to laterally move across the network, leading to significant data loss. Once this breach was identified, the ensuing investigation found that there was no corresponding ticket for the account accessing hundreds of systems and the owner was unknown. "But if you are proactively identifying, tracking and reconciling those tickets with account sessions, and account owners, you can really reduce the risk of an event like this."

In pretty much every breach ever, at some point in the attack chain, an account has been compromised.

5 tips to get started on PAM

As we said at the top of this article, privileged access management can be hard, but "it’s always one of your high priorities", says David. "In pretty much every breach ever, at some point in the attack chain, an account has been compromised". While there are levels of maturity in organisations both large and small, some people out there will be looking for some tips. I asked David what he would recommend for a new PAM programme starting out, or some elements that could help to develop a less mature programme.

1. Define privilege

Spend some time figuring out how you’re going to define ‘privileged access’. There’s a balance to be struck between what’s realistically manageable, risk appetite, maturity, and budget.

2. Discover accounts

Find all your privileged accounts. Host by host. Application by application. It’s long, but necessary. Ensure there’s a defined process that allows you to gain access to those accounts moving forward.

3. Separate duties

"Think about separation of duties around how the accounts are created, managed and governed, versus actually used."  There’s an element of toxic combinations of privilege here. When you’re managing privileged accounts, you want to make sure the person responsible for that process doesn’t have access to any of them. For example, if you’re using CyberArk, your CyberArk admin shouldn’t have access to the destination accounts, because then they’d be able to get privileged access whenever they like.

4. Ensure ownership

Ensure you have ownership on each and every one of the accounts you have discovered. If you don’t, there is no-one ultimately accountable for that account.

5. Implement enhanced controls on privileged accounts

Because it’s so risky for a privileged account to be compromised, it’s important to monitor and protect them as best you can. That means enhanced controls like keylogging, session recording, enforcing multi-factor authentication, recycling passwords. There are good tools out there to help with this.

How does Continuous Controls Monitoring support privileged access management?

A big part of Continuous Controls Monitoring (CCM) is embedding automation into the security measurement process, and that can help in a lot of ways with privileged access management. In particular, the two metrics above can be continuously measured and automated via CCM. It will continuously determine privileged accounts, so you know that the overall inventory is current and up to date. And then it will automatically determine ownership and highlight those that don’t have an owner. Similarly, CCM could reconcile incidents and change tickets to account sessions without the manual process, to help ensure access is being granted to authorised individuals. "Automating your privileged access management metrics and measures provides massive value."   

The bottom line...

Cybersecurity in general isn’t easy, but PAM can be one of the tougher things for an organisation to keep on top of. Hopefully this article will provide you with bit of insight into some useful privileged access management metrics and best practices. If you are enjoying our Metric of the Month content, subscribe to the monthly newsletter below.