What is Privileged Access Management?

Check your Privilege

Privileged Access Management (PAM) is a hot topic at the moment in the security world. In 2019, the number of administrator accounts in Azure with MFA enabled was a lowly 1.7%. More recently, this has risen to around the 20% mark but is still astonishingly low. So let’s look at what PAM is, why it’s important and what measures we can take to protect our most valuable accounts.

What is a Privileged Account?

Well, let’s first of all look at our user accounts. The majority of our user accounts will have access to basic tools like e-mail, word processing, or an expenses system. We should be protecting these accounts in the usual ways – implementing multi-factor authentication as a minimum, and centralising our identity management function to get a grasp on account creation and deprovisioning.

But a privileged account is the next level up, one with elevated rights to resource, applications, or to administrative functions. Some of these privileges will be role-based, for example, our finance team will have access to a finance solution which allows them to make payments, or our marketing team may have access to a corporate social media account so they can post relevant content. We may provide service or application accounts to software to perform automated tasks. And let’s not forget our administrator accounts, the ones used by our IT personnel, allowing them to set up users, delete files and folders en-masse, create new networks and install software.

For the purposes of this article, and to keep it short and sweet, we’ll focus on the last category but we all should be aware that it’s important to take a holistic approach to privileged access management and ensure we’re covering all of our bases!

What’s The Risk?

Our privileged accounts are, by virtue of them having more rights within our network than any other, highly prized targets for attackers. When conducting security workshops with clients where we monitor phishing and malware attempts against accounts within client environments, the global administrator accounts, board-level directors and the accounts of the IT team always come out on top, i.e. they are the most targeted people.

Hackers like to hit accounts that have the “keys to the castle” so to speak. Having the ability to install software (read: malware), move large amounts of data (read: data exfiltration) and provision users (read: create their own accounts) is, unsurprisingly, an attractive set of skills. So why, then, do organisations have separate accounts that are “always on” with these exact capabilities?

One company I heard of recently provided a huge clue to attackers, as to which accounts to target, by putting a different letter in front of their administrator accounts. The premise being that the IT team needed two accounts – one for everyday use and one for performing admin tasks, so to help them differentiate, they added the letter “A” in front of the administrator credentials e.g. joe.bloggs@company.com and a-joe.bloggs@company.com. This seemingly “helpful” addition was like adding a flashing beacon to any bad actors as to which accounts to target. It is not an approach we would recommend.

Having separate administrator accounts for users only serves to inflate our attack surface. When one of the aims of our security strategy should be to reduce entry points for bad actors, we need to come up with a way to combat this.

And finally, it’s not just external threats we need to protect ourselves against, in a study conducted by Accenture in 2018, nearly a quarter of people surveyed in the healthcare industry knew someone who had sold their credentials or provided illegitimate access to a third party. Inside risk is growing, with malicious internal actors, genuine user error, and badly managed identity management processes completing a trifecta of internal threats it’s important we get a handle on, but that’s for another day.

What Should We Be Doing About It?

As we’ve all been adopting cloud technologies rapidly over the last few months, thrown into the deep end of remote working and the “new normal”, identity has truly become the control plane of our security models. As such, we should be looking to enforce more granular controls over our privileged accounts, so what should we be doing?

In an enterprise environment, we should be looking to implement a PAM solution, and at the very least we should be looking to control our privileged identities in the cloud via a solution like Azure Active Directory Privileged Identity Management which is available as part of Azure AD Plan 2, in line with some more manual controls if budgets won’t stretch to a full-blown PAM implementation.

Whichever solution we go for, it should have the ability to elevate user privileges on a Just in Time (JIT) and Just Enough Access (JEA) basis, allowing users to perform specific tasks for a set period.

Using JIT and JEA, organisations can provide their IT personnel with a single user accounts, which can have additional privileges granted when the user needs them. This not only reduces our attack surface by having fewer user accounts to protect, it also means that when the user is not completing an administrative task, their account is no longer as highly-prized.

To elevate their account, users can request elevated access via a portal and their activity is recorded once they’ve temporarily upgraded, meaning if a bad actor does manage to get into the environment, there is an audit trail of the tasks undertaken, helping the security team to understand the scope of any malicious actions.

Another top recommendation from the security gurus at Microsoft is ensuring that we limit our Global Admin accounts to no more than five. All except the break-glass account should be protected with Multi-Factor Authentication, or Risk-Based Conditional Access for even more brownie points, and should be monitored with Azure AD Sign-In Logs and Audit Logs for any unusual activity.

I have worked previously with a client who provided Global Administrator accounts for all 36 members of their outsourced MSP to “save time”. This is not good practice and makes it difficult for the organisation to trace the source of any malicious activity. Finding the right balance between productivity and security is key.

This leads us on to why it’s important to enforce a least privileged model. It can be difficult for the team provisioning identities (usually the IT team) to know exactly what a user needs access to, so they fall into the trap of providing too many privileges to users to avoid additional calls to the service desk, inadvertently leaving themselves open to accidental or malicious data breach.

It can therefore be useful to leverage role-based access control (RBAC) to simplify the process for IT and provide users with a baseline profile. Implementing self-service capabilities for groups, resources and applications can then allow users to access any additional services without the need to always send requests through to IT.

Finally, having a strong attestation process is critical when managing privileged identities. We know that over time, the number of privileged accounts can grow as users may request elevated access for specific projects or one-off tasks. If we don’t have processes in place to recertify user access, then we leave ourselves open to threats through an inflated attack surface.

Manual recertification is an option for smaller organisations, and should certainly be manageable for the privileged accounts, however there are also tools available out to automate processes, such as Access Reviews in Azure AD Plan 2 which allows you to set up scheduled recertification processes and keeps an audit log of approved and denied access for specific resources.

In the same way that we should be protecting our sensitive data with more vigour than our non-sensitive data, we should be implementing additional granular controls to protect our privileged accounts. Limiting our attack surface is key to reducing the number of successful attempts at breach and reducing privileged access sprawl therefore reduces our security risk of data exfiltration in the event of a breach.

If you’d like to understand more about Privileged Access Management and how we can support you in building a cyber security plan to help secure your organisation, get in touch with me by dropping an e-mail to sales@cognisys.co.uk.