PRIVILEGED ACCESS MANAGEMENT FOR WINDOWS … · Privileged Access Management for Windows...

PRIVILEGED ACCESS MANAGEMENT FOR WINDOWS WORKSTATIONS

www.centrify.com

https://www.centrify.com/

ABOUT CENTRIFYCentrify is redefining the legacy approach to Privileged Access Management by

delivering cloud-ready Zero Trust Privilege to secure modern enterprise attack

surfaces. Centrify Zero Trust Privilege helps customers 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, Centrify

minimizes the attack surface, improves audit and compliance visibility, and reduces

risk, complexity and costs for the modern, hybrid enterprise. Over half of the

Fortune 100, the world’s largest financial institutions, intelligence agencies, and

critical infrastructure companies, all trust Centrify to stop the leading cause of

breaches — privileged credential abuse.

To learn more visit www.centrify.com.

http://www.centrify.com

©2019 Centrify Corporation All Rights Reserved. www.centrify.com c

Privileged Access Management for Windows Workstations

Workstations – A Neglected Prime Target 1

Workstation as a Base of Operations 1

Primary Target – Administrator Accounts 2

How Can We Mitigate These Risks? 2

Granular Privilege Elevation with Least Privilege Admin Roles 3

Restrict Members of The Local Administrators Group – 4 Empty If Possible

Lock Down the Local Administrator Account Password 4

Multi-Factor Re-Authentication for Additional Identity 4 Assurance Especially for Privilege Elevation

Offline Login 5

PowerShell Remoting Lock-Down to Prevent 6 Lateral Movement

Summary of Best Practices 7


©2019 Centrify Corporation All Rights Reserved. www.centrify.com 1


Workstations – A Neglected Prime Target

Locking down privileged accounts is a basic security tenet and a priority for servers. Unfortunately, in many organizations the same level of concern and control is rarely applied to workstations. Yet for many years, individual desktops/laptops have contained as much sensitive information as servers. As such these systems are a prime target for threat actors, especially Microsoft® Windows® workstations, given their broad use within businesses.

Think about what’s on the laptops of the CEO, the HR director, the software architect, or the CFO in any given organization. This may be information that doesn’t make it to servers, yet is extremely sensitive and potentially as valuable to a threat actor as data on a file or database server.

For attackers, the path of least resistance in many organizations is the overuse of accounts with broad and deep privileges on Windows workstations. The unfortunate reality is that workstation security too often focuses solely on the threat of malware and viruses but ignores the simple threat of unsecured privileged user accounts.

Workstation as a Base of Operations

But it gets worse. The threats and risks rarely end at the individual workstation. Threat actors will use it as a foothold from which to locate additional sensitive information within the broader corporate network. They might typically wait for the workstation to be network-connected (internally or through a VPN connection) in order to reconnoiter, scanning the network to create a map of new candidate systems to breach.

Many open source tools exist to aid in these efforts, such as Mimikatz, to extract account NTLM hashes from memory left behind by prior admin login sessions. These hashes can then be used to move laterally to other systems, looking for more privileged accounts and to discover sensitive data to exfiltrate and monetize.

The diagram below represents a hypothetical attack chain where a foothold on an end user workstation could reasonably be the start of an attack. If that end user already has administrative rights on the workstation – often the case that IT grants users’ local admin rights to their own machine – then the threat actor gains a powerful initial foothold, if they’re able to compromise that account.

What is a privileged account? A local admin user. A user (Active Directory or local) account in the Administrator’s group. An Active Directory account in the Domain Admins group.




A typical example being an end user clicking on an email link and visiting a spoofed web site. Malware is downloaded and because the user is local Administrator, the malware executes in the user’s security context, i.e., with those same local Administrator rights. It’s then able to do whatever the user can: run administrative commands; install software; create backdoor accounts; access shared drives; exploit vulnerabilities on the system; etc.

Primary Target – Administrator Accounts

The prime target account for threat actors on a Windows workstation is this default local Administrator account – the first account created during Windows installation. As stated above, it’s often the case that IT allows end users to login with this account to avoid burdening IT with common tasks like software installation, printer setup, and OS updates. Human nature being what it is, those end users will generally use that privileged account all the time even for non-administrative work and rarely practice good password hygiene.

Some IT shops are more judicious and won’t give the user access to this account, so the workstation is less exposed. When the user needs administrative help, however, the IT helpdesk team must step in to provide assistance, logging in with that account (or a Domain Administrator account if the workstation is part of an Active Directory domain).

There’s a dirty little secret about local Administrator accounts in this scenario:

· They’re often assigned the same password on all Windows workstations across the entire organization to make life easier for IT;

· Their password is rarely rotated;

· Their password is often low entropy, i.e., simple and predictable for IT administrators to remember; and

· Their use is rarely audited.

All this translates to much higher risk for the organization. So, if the password is phished or its hash obtained (see Mimikatz above), the attacker can use it not only to log into the phished user’s workstation with full administrative rights, but to all other workstations on the network.

How Can We Mitigate These Risks?

This is a two-sided coin. On one side, we need to lock down these workstations, removing local Administrator access for end users, to reduce risk. On the other side, we need to minimize privileges for end users and IT administrators, to improve overall security while still granting enough privileges for them to do their jobs.

The answer to this issue is privileged access management (PAM) for workstations. This technology is not very much different to its equivalent on servers – PAM technology that you may already have in place. However, there are a few nuances specific to workstations that don’t typically impact servers.

One is scale – the number of workstations to servers is often an order of magnitude greater, perhaps hundreds or thousands of workstations. So being able to centralize policies, roles, rights, and administration is essential to avoid IT operational overhead, reduce privilege creep, and ensure comprehensive security coverage.




Another is offline state; while servers are part of IT infrastructure and typically network-connected at all times, workstations are often more mobile and off the network. The PAM controls must continue to be equally effective in this situation.

Centrify Privilege Elevation Service (PES) in combination with Centrify Privileged Access Service (PAS) enables you to control and secure the local administrator account on your organization’s Windows workstations using the principle of least privilege. Least privilege is a simple concept but unfortunately, it’s rarely followed. The impact of applying it correctly, however, greatly increases security posture and reduces risk.

Granular Privilege Elevation with Least Privilege Admin Roles

With Centrify PES we can avoid granting full superuser privileges to the workstation end user (as well as IT administrators). Instead, we grant limited rights based on job function. For example, if we want our end users to be able to install or uninstall software, we grant them a role allowing them to perform such actions with elevated administrator rights. (Diagram 2)

Then it’s a simple matter of right-clicking on the application icon and selecting “Run with Privilege” or for less friction, log the user into a Centrify Privileged Desktop where the user only needs to double-click the icon to launch the application with privilege. For some common Windows utilities where you can’t right-click, such as Network Manager and Application Manager, a Centrify version of the utility allows for Centrify role assignment and privilege elevation as described above. (Diagram 3)

This least-privilege access control is managed from Active Directory via Centrify’s patented Zones Technology. Active Directory’s standard management model consists of an organizational unit and container-based tree structure. It offers limited control and flexibility in regard to user, computer, and privilege governance or delegation.

Centrify’s Zone model extends this structure, giving customers much greater flexibility and granularity. Centrify Zones are hierarchical, allowing organizations to define a model that suits their governance needs —

Diagram 2

Diagram 3




one that reflects, say, their internal departmental structure, their geographic locations, or perhaps puts very sensitive resources (e.g., regulated systems such as PCI-DSS) into their own Centrify Zone, one that has highly restrictive controls around their access. It also supports inheritance so that more generic roles, defined at a high level in the hierarchy, will be inherited by all the Centrify Zones below it. This greatly improves security, reduces administration, avoids duplication, and provides organizations with a much cleaner governance and delegation model. (Diagram 4)

IT can manage these Centrify roles and rights from within Active Directory or more conveniently, through Centrify’s UI – a Microsoft Management Console snap-in that gives admins the same look and feel as the native AD tooling.

Finally, Centrify roles can include Active Directory security groups, for organizations who prefer to grant access based on Active Directory group membership.

Restrict Members of The Local Administrators Group – Empty If Possible

After establishing Centrify roles and granular rights to enforce a least-privilege/privilege elevation model, you should now clean up the local Administrators group membership. There should not be a reason for anyone to be a member of this group, except perhaps a single emergency “break-glass” account (see next). Doing this reduces your attack surface. (Diagram 5)

Lock Down the Local Administrator Account Password

Following on from the above point, Workstation end users should never need to know the local Administrator password when we employ a least privilege access control model. In fact, its password should be secured in the Centrify Privileged Access Service (PAS) vault with checkout allowed only via explicit workflow-based access request and approval.

Multi-Factor Re-Authentication for Additional Identity Assurance Especially for Privilege Elevation

So far, we’ve setup privilege elevation for specific tasks, cleaned up the local Administrators group, and locked down the Administrator account. However, many attack scenarios involve non-human activities. A best practice is to ensure your user is at the keyboard (i.e., not a remote hacker, bot, or malware) when an attempt is made to execute a command with elevated privileges.

Diagram 4

Diagram 5




We do this by enforcing step-up authentication via a physical second factor, which equates to NIST SP 800-63-3 Authenticator Assurance Level 3 (AAL3). This can be as simple as plugging in a USB key (e.g., SafeNet eToken Pro USB Key, or YubiKey). Having physical possession of the key, the user only needs to remember a single PIN to unlock the device. Some environments such as the U.S. Federal Government require smart card login (HSPD-12) for PKI certificate-based authentication instead of a password. (Diagram 6)

Further, many organizations have embraced the use of a privileged alternate account, often referred to as a “dash-a” account. These accounts should also be protected via smart

card login (again, for NIST AAL3), and they should never be a member of the Domain Admins group; they should only have the ability to elevate privilege to run specific applications. (Diagram 7)

Microsoft provides all that’s necessary to support smart card login to the workstation; Centrify enforces it via policy and provides it as an optional control both at workstation login as well as at privilege elevation.

Offline Login

For a Centrify-managed workstation that is domain-joined or enrolled in the Centrify Privileged Access Service (PAS), supporting offline login ensures availability of the workstation. Offline login is used when the workstation can’t communicate to its domain controller or Centrify PAS. The end result is the user can’t login to the workstation. (Diagram 8)

Your PAM must support a number of related use cases when the workstation has lost connectivity:

· Offline login with cached credentials. This allows a user that has previously logged into the workstation, to access the system using their previously used credentials. This employs credential caching.

· Offline login with cached credentials and identity validation. This is identical to the previous use-case, with an additional step – the user is challenged for an offline passcode (e.g., from mobile app). This also employs credential caching.

Diagram 7

Diagram 6

Diagram 8




· Offline login with no prior access. Allowing a user (more typically an IT Administrator) that has not previously logged into the workstation, to access the system. This employs a capability Centrify calls account prevalidation, leveraging Kerberos.

PowerShell Remoting Lock-Down to Prevent Lateral Movement

PowerShell is a familiar target for attackers, giving them the ability to execute remote commands and automate tasks across hundreds of servers with a single command. If the prior advice has been followed, however, a compromised local user password hash (for example) will minimize exposure. The legitimate end user can be granted a Centrify role to elevate privilege to (e.g.) run a PowerShell console with administrative rights. (Diagram 9)

PowerShell Remoting is a related capability enabled by default from Windows Server 2012 and on client versions of Windows with PowerShell 3.0 and beyond. It enables the workstation to receive PowerShell commands that are sent remotely from another system on the network. (Diagram 10)

Should a workstation local administrator account be compromised, the attacker can use PowerShell remoting to spread laterally to other Windows computers in the network.

It’s essential, then, to not only lock down the local administrator account as described above for least privilege, but also to use Centrify roles to lock down PowerShell Remoting as another layer of security.

Diagram 9

Diagram 9




Summary of Best Practices

To summarize the above, we recommend you focus on the following to help better protect your business-critical assets against privileged access abuse.

· Lock down all admin accounts by vaulting them in Centrify Privileged Access Service.

· Never allow use of vaulted admin accounts except in emergency break-glass situations.

· Empty all Local administrator groups.

· Empty the Domain Admins group.

· Leverage privilege elevation where necessary for end users and IT admins.

· Require multi-factor authentication (MFA) prior to any privilege elevation.

· Don’t grant permanent rights to privilege elevation.

· Leverage access request tooling and workflow within Identity Governance and Administration (e.g., SailPoint) or IT Service Management (e.g., ServiceNow) to grant temporary privileges.

· Follow a defense in depth approach to security. This means (e.g.) layering Centrify on top of Endpoint Protection Platform technologies and Microsoft App Locker for white-listed application execution controls.

Centrify Privilege Elevation Service delivers the flexibility IT needs while providing the security the organization demands. This enables you to control the elevated permissions for desktop users as part of your organization’s privileged access management program.




Our mission is to stop the leading cause of breaches – privileged access abuse. Centrify empowers our customers with a cloud-ready Zero Trust Privilege approach to secure access to infrastructure, DevOps, cloud, containers, Big Data and other modern enterprise attack surfaces. To learn more, visit www.centrify.com.

Centrify is a registered trademark of Centrify Corporation. Other trademarks mentioned herein are the property of their respective owners.

©2019 Centrify Corporation. All Rights Reserved.

US Headquarters +1 (669) 444 5200EMEA +44 (0) 1344 317950Asia Pacific +61 1300 795 789 Brazil +55 11 3958 4876Latin America +1 305 900 [email protected] www.centrify.com


PRIVILEGED ACCESS MANAGEMENT FOR WINDOWS … · Privileged Access Management for Windows...

Documents

Transcript of PRIVILEGED ACCESS MANAGEMENT FOR WINDOWS … · Privileged Access Management for Windows...