Zero Trust Privilege redefines legacy Privileged Access Management (PAM) for the modern enterprise IT threatscape. Organizations must discard the old model of “trust but verify”, which relied on well-defined boundaries. Zero Trust mandates a “never trust, always verify, enforce least privilege” approach to privileged access, from inside or outside the network.
Zero Trust Privilege requires granting least privilege access based on verifying who is requesting access, the context of the request, and the risk of the access environment. By implementing least privilege access, organizations minimize the attack surface, improve audit and compliance visibility, and reduce risk, complexity and costs for the modern, hybrid enterprise.
Legacy PAM Is Not Enough for the Expanded Threatscape
Legacy PAM has been around for decades and was designed back in the day when ALL your privileged access was constrained to systems and resources INSIDE your network. The environment was systems admins with a shared “root” account that they would check out of a password vault, typically to access a server, a database or network device. Legacy PAM served its purpose.
However, today’s environment is different, privileged access not only covers infrastructure, databases and network devices, but is extended to cloud environments. It also includes big data projects, it must be automated for DevOps, and it now needs to cover hundreds of containers or microservices to represent what used to be a single server.
On top of this, we now all live in a world of Advanced Persistent Threats (APTs) that create a growing and changing risk to organizations’ financial assets, intellectual property and reputations. Expanding access and obtaining credentials is an essential part of most APTs, with privileged access being the crown jewels. Forrester (see Forrester Wave: Privileged Identity Management: Q3 2016) stated that “80% of security breaches involve privilege credentials.”
Cloud-ready Zero Trust Privilege is designed to handle requesters that are not only human but also machines, services and APIs. There will still be shared accounts, but for increased assurance, best practices now recommend individual identities, not shared accounts, where least privilege can be applied. All controls must be dynamic and risk-aware, which requires modern machine learning and user behavior analytics. Now PAM must integrate and interoperate with a much broader ecosystem including IaaS providers like AWS and Azure, with DevOps CI/CD Pipeline tools such as HashiCorp and Ansible, and with Container solutions such as Docker, Kubernetes and CoreOS.
The Six Tenants of Zero Trust Privileged
A Zero Trust Privilege approach helps enterprises grant least privilege access based on verifying who is requesting access, the context of the request and the risk of the access environment. By implementing least privilege access, Zero Trust Privilege minimizes the attack surface, improves audit and compliance visibility, and reduces risk, complexity and costs for the modern, hybrid enterprise. Zero Trust Privilege is built on six tenants, which are covered in detail below:
Today, identities include not just people but workloads, services and machines. Properly verifying WHO means leveraging enterprise directory identities, eliminating local accounts and decreasing the overall number of accounts and passwords, reducing the attack surface. Many large organizations have standardized on Microsoft’s Active Directory, but with Zero Trust Privilege you don’t have to standardize on any particular directory. In fact, you can keep different populations of identities in different directories. The important part is to establish identity for users via HR-vetted enterprise directory identities, meaning these identities are automatically disabled when the person’s employment is terminated. The last thing you want is a database administrator (DBA) to leave, but still, retain their privileged access rights.
A best practice for privileged access is to establish unique accounts for each administrator to use for admin purposes. Microsoft suggests that these be “Alternate Admin Accounts” (commonly referred to as “dash a” due to the typical “-A” appended to the user’s account) that are associated with the admin user but are separate from the admin’s end user identity, which is typically a publicly-known account with an email address. This way, if the public email account gets compromised, it does not expose their Alternate Admin Account.
To verify who, we must also apply Multi-Factor Authentication (MFA) everywhere. During login, upon password checkout, at privilege elevation — anytime there is a new request. With privileged access we must know with certainty who is on the other end before granting access. MFA is a must-have, passwords are not good enough. Let’s face it, 10% of you probably have the word “admin” as your password – that’s not going to cut it. The good news is MFA is way easier than before, when you used to have to wait for 120 seconds for a new 6-digit code to come up and type it in. Now users just get a push notification to their phone and/or just touch their FIDO key.
When implementing MFA, it is critical to enforce National Institute for Standards and Technology (NIST) Assurance Level-2 at a minimum for admin functions. This means a dual challenge: something you know, and something you have. A good example is a password combined with a push notification to your phone, or an OTP generated by your phone. For most critical assets it is recommended to increase even further to NIST Assurance Level-3, where possible. This includes two-factor authentication with a password in addition to a hardware-based cryptographic token, such as a smart card or FIDO key. Google claims they have not had a single successful phishing attack since they implemented FIDO keys for all users.
First, we need to start with why it is important to have a “request and approve” access process. It makes sense that a database administrator (DBA) should not have default rights to access all databases, only to the ones they need to work on that day. That way, if that DBA’s credentials are compromised, we have limited the attack surface. For each request, it is important to know WHY somebody, or something is performing privileged activity. To do this, we must understand the context behind the request for access, and review and approve the request based on the context provided.
The concept of least privilege is to only provide the needed level of privilege to perform a certain task and only for the amount of time necessary to perform that task. To execute least privilege, the granter of access must understand the context to be able to make the appropriate access decision.
Recording the request context typically includes associating the request with a certain trouble ticket and providing a reason, as well as what is being requested and for how long. Once the request is contextualized, then it must be routed for approval and this workflow can be as simple or complex as you would like to make it. For larger companies to best achieve this step, it’s likely going to involve the integration of a PAM solution with an enterprise grade ITSM (IT Service Management) solution like ServiceNow or IGA (Identity Governance Administration) platform like SailPoint Technologies.
Secure Admin Environment
When accessing privileged resources, it is critical that we do not either enable malware access to servers or introduce infections during our connection to servers. To achieve this, we need to make sure access is only achieved through a clean source. Zero Trust Privilege means preventing direct access from user workstations that also have access to the Internet and email, which are too easily infected with malware. Access should only be granted through approved Privileged Admin Consoles, which can be achieved in many ways, including web-based access to sensitive systems via an administrative jump box, such as the Centrify Zero Trust Privilege Services with its Connectors.
Modern cloud jump boxes with distributed connectors are a great way to achieve a secure admin environment for distributed organizations. In the past you only had to secure access from inside your network. But the beauty of a properly designed Zero Trust Privilege Admin Environment is it not only allows remote staff to access resources 24x7, but it is well-suited for outsourced IT or outsourced development users because it alleviates the need for a Virtual Private Network (VPN) and handles all the transport security between the secure client and distributed connectors.
Distributed jump hosts or “connectors” serve the dual purpose for load balancing in the same network and for supporting multiple, different private networks. These connectors go where the resources are located, such as DMZ, IaaS, or Virtual Private Network with private, mutually authenticated connections. These secure connections allow Web-based SSH or RDP that works from any location. For outsourced, third-party users it includes federated in-bound authentication, meaning authentication can depend on a partner’s directory of authorized employees, providing much higher identity assurance.
Grant Least Privilege
Least privilege as a concept is more common than you realize. Think of physical access control at your office: different levels of users have different access rights, and to get access to certain areas you must request and be approved. This is all very well recognized in the physical security space, and the same logic applies for logical security. It applies when granting granular role-based access to privileged resources.
Another objective to granting least privilege is to limit lateral movement across the network. This is the primary way attackers get access to sensitive data: they start in one location and move laterally until they find what they are looking for. If we zone off what they have access to then we can stop lateral movement. Just like nobody should have a single key/badge that accesses everything, you really don’t want to use the root account on a server, as it gives too much access and has no attribution to the actual user, who we’ll call “Bob.” Instead Bob should login directly to the target system with his alternate admin entitlements that give him access to restart only a particular set of servers. If he needs to change the configuration or access a different target system, then he must request access for a specified period of time through something like ServiceNow and may be asked for Multi-Factor Authentication (MFA). Once complete, Bob’s entitlements will reduce back to just what is needed.
For privileged sessions, it is of course best practice to audit everything. With a documented record of all actions performed, audit logs not only can be used in forensic analysis to find exactly the issue, but also to attribute actions taken to a specific user. Because these sessions are so critical it is also best practice to keep a video recording of the session that can be reviewed or used as evidence for your most critical assets or in highly regulated industries. There are multiple regulations including PCI-DSS for payment card data that specifically requires this level of auditing.
Monitoring and session recording can be achieved through either a gateway- and/or host-based technique. Host-based ensures that sessions cannot be bypassed, as well as to also provide process launch and file system change auditing, which is a highly desired technique for your most critical resources.
If you have a security department, a good practice is to integrate this audit data with your existing Security Information and Event Management (SIEM) system or Cloud Access Security Broker (CASB) service for automated mining where risky activities can be identified and alerts raised.
Zero Trust Privilege controls need to be adaptive to the risk-context. Gartner promotes CARTA – Continuous, Adaptive, Risk and Trust Assessment – and it’s absolutely required for Privileged Access too. Zero Trust Privilege means knowing that even if the right credentials have been entered by a user, but the request comes in from a potentially risky location, then a stronger verification is needed to permit access. Modern machine learning algorithms are now used to carefully analyze a privileged user’s behavior and identify “anomalous” or “non-normal” (and therefore risky) activities and alert or notify security.
Adaptive control means not only notifying of risky activity in real time, but also being able to actively respond to incidents by cutting off sessions, adding additional monitoring or flagging for forensic follow up.
Machine learning allows companies to pore through millions of events and scan for that needle in the haystack on an ongoing and continuous basis, which would never be achievable by manual forensics. Even more valuable is performing machine learning-based analytics inline and in real time and thus being able to enforce truly adaptive preventive controls and not just after-the-fact detective controls.
To deliver Zero Trust, today’s Privileged Access Management (PAM) solutions cannot rely on simply vaulting away shared accounts. They must cover, in detail, both Privileged Account and Session Management as well as Privilege Elevation and Delegation Management. But clearly that is not enough. To sufficiently verify who (or what) a requester is, today’s cloud-ready Privileged Access Management (PAM) must include Privileged Identity and Access Management, Multi-Factor Authentication as well as Privilege Threat Analytics.
Legacy Privileged Access Management (PAM) did a great job of serving yesterday’s threatscape, but in a modern enterprise IT world, to protect yourself, your company, your customers, and your investors, a Zero Trust Privilege approach should be applied.