25. Privileged Account Management Implementation
Reduce the attack surface by limiting the use of privileged accounts and by controlling privileged access to resources across the enterprise. This is especially true regardless of whether the remote access session starts from trusted internal resources or from authorized external entities.
Monitor privileged user, session, and file activities for unauthorized access or changes that inappropriately affect the organization’s sensitive data or normal business operations.
Analyze asset and user behavior to detect suspicious or malicious activities, and to help secure operations in accordance with security best practices and regulatory guidance.
Low Impact approach for maximum adoption of PAM across the enterprise, and to protect privileges without obstructing productivity or overburdening operations.
Step 1: Improve Accountability for Privileged Accounts
Systems can have embedded or hard-coded passwords, leaving opportunities for misuse. These need to be discovered for management.
When human interaction is required for credential entry, it can lead to credential exposure. Discovering where manual entry of privileged accounts is occurring will assist with automating privileged credential injection.
Passwords and keys are needed for application-to-application and application-to-database access and should never be hard-coded. These should be identified and placed under management
End-user passwords are generally static, so there must be protections against passwords being leaked or reused outside of the organization. Discovery of local administrative credentials will identify assets that should have those rights removed. Least privilege should be implemented as a mitigating control.
Manual password rotation is unreliable and time-consuming. Humans will always make mistakes by missing an account password change or reusing a password. Discovery and automation of management for these accounts removes the human element.
Manual auditing and reporting on access is complex and error-prone. Discovery of all privileged accounts and automation will help ensure reporting, auditing, and analytics are as accurate as possible.
So, how exactly do organizations ensure accountability of shared privileged accounts to meet compliance and security requirements without impacting administrator productivity?
Full network scanning, discovery, and profiling with auto-onboarding of privileged accounts.
Provide discovery of privileged accounts through third-party integrations and API calls.
Build permission sets dynamically according to data provided during discovery assessments.
Apply granular access control, workflow, and auditing for any discovery process to ensure accuracy.
Enforce role-based access to discovered data to ensure results are not misused against the organization.
With these requirements, organizations can discover all the accounts in their environment, place those accounts under management, and satisfy auditor requests that accounts are now managed or properly offboarded.
Step 2: Implement Least Privilege on Desktops
Once accounts and assets have been discovered and are being consistently managed, the next step to complete privileged access management is implementing least privilege on end-user machines. That is the removal of local administrative rights potentially invoked by the local or remote user. As a security best practice, organizations should reduce the risk on desktops before servers (such as Microsoft Windows Server, Unix, or Linux as indicated in step 3) as the endpoint is typically the last mile of security, but the primary target for a threat actor. Some organizations may choose to reverse this order and do servers before desktops. This depends on the organization’s business requirements and risk appetite, but as discussed, step 1 should be done first to even determine the scope of any deployment.
To that end, the process for IT to restrict or disable end-user privileges potentially can be complex and time-consuming, but it must be done to support audit or compliance mandates for the removal of unnecessary administrative rights. When environments have standardized desktop images and applications, the process is relatively trivial. If every machine is different, then prioritizing which users, roles, and assets to manage first becomes a larger business and technical discussion. And although users should not be granted local administrator or power user privileges in the first place, sometimes certain applications require elevated privileges just to execute correctly. So, how do IT departments reduce the risk of users having excessive privileges and subjecting the organization to potential exploitation or compliance violations without obstructing their productivity?
The answer is only through least privilege access for applications. This requires a rules-based PAM technology to elevate application privileges without elevating user privileges. By eliminating end-user desktop administrator privileges and instrumenting application control, applications can operate with the required privileges, but neither impact the user nor provide them with excessive privileges that are a liability.
Default all users to standard user privileges, while enabling elevated privileges for specific applications and tasks, without requiring administrative credentials.
Enforce restrictions on software installation, usage, and OS configuration changes based on privileges assigned by rules.
Eliminate the need for end users to require two accounts to perform appropriate administrative tasks.
Make dynamic least privilege decisions for applications based on that application’s vulnerability, risk, reputation, and compliance profile.
Match applications to rules automatically based on asset- or user-based policies.
Report on privileged access to file systems for all users and document system changes during privileged sessions to prevent malicious tampering.
Monitor sessions and log keystrokes during privileged access to determine whether or not a local user is using privileges appropriately.
Provide a technique for using real domain or local privileges when required, including multi-factor authentication for applications that must authenticate to a remote directory store.
Integrate with other privilege solutions to achieve a uniform approach to password management and remote access.
Leverage an integrated data warehouse and data analytics across the privilege universe for accurate reporting, regardless of where privileged activity occurs for a user.
Step 3: Implement Least Privilege on Servers
Role-based access controls are inefficient and incomplete (such as native OS options), lacking the ability to delegate authorization without disclosing passwords.
Default tools are not secure enough (such as open source sudo or local administrator accounts) to address risk or compliance requirements and lack the ability to record sessions and keystrokes for audits.
The default operating system cannot restrict activity inside scripts and third-party applications, leaving a shortcut to unapproved applications.
Open source solutions and native tools do not offer an efficient migration path away from sudo or shared accounts if it is being used throughout the organization.
Therefore, how do IT organizations limit who has access to root accounts to reduce the risk of compromises without hindering productivity? We are literally full circle again on the observer effect.
Organizations must be able to efficiently delegate server privileges and authorization without disclosing passwords (or even the credentials required) for root, local, or domain administrators, or other accounts. Recording all privileged sessions for audits, including keystroke information, helps to achieve privileged access monitoring requirements without relying on native tools that are deficient.
Industry-standard support for authentication solutions, including OAuth, SAML, and other multi-factor solutions.
Advanced control and audit over commands at the system level, even when they are obfuscated in scripts or renamed.
A flexible policy language and rules to provide a migration path from native tools with the features needed to manage virtually any business requirement.
Extensive support for many Windows, Unix, and Linux platforms.
Recording and indexing of all sessions for quick discovery during audits.
Brokering privileges transparently, ensuring user productivity and compliance.
Change management of all settings and policy configuration, allowing full audit of who has changed what, version control, and rollback of all existing configuration files.
REST API for easier integration with third-party products.
an architecture that provides high availability and seamless disaster recovery.
Leverages an integrated data warehouse for centralized reporting and analytics across all managed systems.
With this capability, you gain complete control over root and administrator access on any type of server operating system and meet virtually any business or regulatory requirement for privileged access.
Step 4: Application Reputation
Application whitelisting, blacklisting, and greylisting are forms of application control and a subset of application reputation services. Once shared credentials are under management and end users have the privileges they need to perform their jobs (and nothing more), organizations can move to a better understanding of risks to help make better-informed privilege elevation decisions. The challenge, though, is that most risk assessment solutions do little to help security leaders put vulnerability, attack, malware, and application risk information in the context of business. Saddled with volumes of rigid data and static reports, the security team is left to manually discern real threats and determine how to act upon them when users execute an application.
The source location of the application by determining if it was loaded from a trusted share vs. downloaded from the Internet or copied from a secure location on the file system
Real-world threats based on known hashes for vulnerable or exploitable versions
Improperly digital signing/signing using a stolen certificate
Outdated versions or a missing security patch
Software not licensed to the organization therefore blocking shadow IT
Automatically limit the privileges assigned to the application (i.e., no child processes or denied access to the file system)
Event logging and alerting, including automatically opening a support ticket based on the application and risk
This not only stops exploits from becoming a privileged attack vector, but also blocks drive-by social threats that can leverage vulnerabilities within the environment until mitigation or remediation steps are available.
Step 5: Remote Access
Automatically injecting authorized credentials into a session without ever exposing them the to the user
Providing secure connectivity deep into an organization or the cloud without the need for dedicated clients, special applications, or protocol tunneling
Allowing for complete privilege monitoring to determine if the session was appropriate
Enforcing a workflow that applies just-in-time access and includes ticketing solutions to grant the appropriate privileges
Integrating with a variety of third-party services, from directory stores to SIEMs, for visibility and authentication within an environment
Providing connectivity as a bastion host, eliminating the need for VPN solutions and costly VDI deployments
Support for all major remote access protocols, including RDP, SSH, VNC, and HTTP(s), as well as agent technology to provide secure remote access connectivity to any type of device
If you consider steps 1 through 4 of this chapter for identifying privileged accounts and managing the endpoints and applications on them, the next logical step is controlling who can access them remotely and with what specific privileges. It is a logical progression. Secure the target and then secure who can access it, especially if the communication needs to originate from outside of your organization.
Step 6: Network Devices and IoT
In parenthesis is the number of times they have been compromised in the wild. This list not only pertains to network devices, but any device in a corporate environment. It is important to mention here because, with potentially hundreds or thousands of managed network and IoT devices in an environment, assigning a complex, unique password to each device and securely storing each password is a logistical nightmare without a password management solution. So, it’s not uncommon for administrators to choose a simple, common, and guessable password and assign it to every device for ease of management. Unfortunately, threat actors can easily guess or brute force these devices to gain access. In addition, as we have discussed, the second most common privilege flaw is reuse of the same password across the entire infrastructure. And rarely are these passwords changed en masse. This holds true even if you have outsourced the management or have had employee turnover. These oversights and shortcuts lead to a variety of malicious activities, including recent vulnerabilities we’ve seen that can exploited to replace the device’s bootstrap loader with a piece of custom malware.
Default or common passwords that are misconfigured
Shared credentials across multiple devices for management simplicity
Excessive password ages due to fear of changing them or lack of management capabilities
Compromised or insider accounts making changes to allow exfiltration of data
Outsourced devices and infrastructure where changes in personnel, contracts, and tools expose credentials to unaccountable individuals
Professional services provided by a vendor that sets the passwords and which are not changed after their engagement is complete
Any one of these could lead to excessive risk for your infrastructure. As such, organizations should look beyond desktops and servers when planning their PAM journey by including any network or IoT device. Additionally, with newer privileged access management solutions, organizations can move beyond the Boolean “access” or “no access” authorization models commonly used in many network devices. That means organizations now have access to proxy gateways that can enforce command whitelisting and blacklisting, session monitoring, and active alerting, and can control and limit root access.
Finally, a new generation of distributed denial of service attacks, often leveraging IoT, has emerged that represents a significant risk to all organizations. The number one vulnerability with IoT devices is the use of hard-coded, default, and weak passwords. Even when administrators change default passwords, most credentials can be still guessed via brute force attacks. While newer laws like CCPA plan to restrict this practice, there are still millions of devices already deployed that are susceptible to these attacks. Therefore, it is recommended to get all of these devices under management and ensure each one has a unique and complex password stored in your PAM solution and is properly managed for session (or remote access) activity .
Step 7: The Cloud and Virtualization
With the growing use of virtualized data centers and cloud environments for processing, storage, or application hosting and development, organizations have opened up new avenues for threat actors to access sensitive data and cause disruption. organizations must secure access to these environments to mitigate security risks, while meeting the cost and efficiency promises of hosting more applications and services in the cloud.
Performing standard network discovery or scanning from a host machine with “line of sight” access to the virtualized environment. This should support discovery using IPv4 and IPv6 fingerprinting.
Querying the hypervisor or cloud management platform to retrieve the inventory of virtualized assets, including containers, or configuring an active notification upon inventory updates.
Using agents that are preinstalled on the base image library or that are installed during the normal server provisioning process.
Querying a third-party asset management solution that provides a record of authority for what is operating in the environment.
Utilize a password management solution to manage the passwords across all virtualized machines, containers, and deployed management interfaces.
Use a remote access solution with privileged session monitoring capabilities to control and monitor virtual machines and application-specific management console access.
Use native delegation capabilities of the underlying hypervisor to reduce the privileges associated to users interacting with the system. This can include zero trust as well.
Use a privilege management agent with a least privilege architecture to reduce exposure to administrator, root, and privileged developer accounts. This is especially important when linked with DevOps.
Integrate with the native cloud or virtualization API for management of accounts and identities that can interact with hosted services.
For virtualized non-Windows systems, consider using a directory bridging technology to centralize authentication and credentials in a single platform-agnostic directory store, like LDAP or Active Directory.
Use a privileged password management solution to automatically manage the passwords across all hypervisor and cloud management platforms. This encompasses everything from cloud-specific management consoles to API keys.
Use a remote access and privileged session monitoring solution to control and monitor all user-based cloud management activities.
Use native or third-party delegation capabilities of the hypervisor and cloud management provider to reduce the privileges associated with users that are interacting with the system.
The cloud and virtualized resources are essential to any organization embarking on a PAM journey and utilizing these technologies to streamline costs, provide quicker time-to-market of services. Privileged attack vectors are arguably a higher risk in these environments, and managing them should become part of your standard operating procedure.
Step 8: DevOps and SecDevOps
Secure Applications: Privileged access management APIs are designed to provide better security for all applications that require automation to enter credentials for normal operations. Developers can call a PAM API and retrieve the latest credentials for any user, application, infrastructure, cloud solution, or database to authenticate, perform automation, and ultimately release the credentials upon termination of the task. This can trigger automatic, randomized cycling of the password or additional automated processes to meet business objectives. Developers and IT never see, or know, the latest credentials for any given DevOps task, nor are the credentials ever hard-coded.
Privileged Attack Vector Mitigation: Using a PAM API secures the runtime of applications and avoids hacking techniques like pass-the-hash that may be looking for persistent privileged credentials in memory. This approach is far more secure than single sign-on (SSO) since the password is constantly being rotated per task, application, or session, even if it is shared through multiple DevOps processes.
Developer Simplification: This approach improves the agility and responsiveness of developers and IT by never requiring the entry of credentials for connectivity, automation, and execution of DevOps tasks. A simple API call is all that is referenced to ensure that the right credentials are always used.
Step 9: Privileged Account Integration
It is no secret that IT and security professionals are overloaded with privilege, vulnerability, and attack information. Unfortunately, advanced persistent threats (APTs) often go undetected because traditional security analytics solutions are unable to correlate diverse data to discern hidden risks. Seemingly isolated events are written off as exceptions, filtered out, or lost in a sea of data. The threat actor continues to traverse the network, and the damage continues to multiply. So how do security and IT operations teams gain an understanding of where threats are coming from, prioritize them, and quickly mitigate the risks?
By integrating privileged account data with other sources of security information, teams can identify a potential security incident typically missed by single sources of security information alone. Based on basic correlation, analytics, machine learning, or even artificial intelligence, integrating privileged account data with other solutions can pinpoint specific, high-risk users and assets by correlating low-level privilege and threat data from a variety of third-party solutions.
Correlate low-level data from a variety of third-party solutions to uncover critical threats natively, or via certified third-party connectors.
Correlate system activity against application risk data and known malware.
Report on compliance, benchmarks, threat analytics, what-if scenarios, and resource requirements.
View, sort, and filter historical data from multiple perspectives based on integrated role-based access.
Integrate with SIEM solutions and provide support for common protocols like Syslog and SNMP.
Profile IP, DNS, OS, Mac address, users, accounts, password ages, ports, services, software, processes, hardware, and event logs to accurately judge the risk for an asset or application.
Group, assess, and report on assets by IP range, naming convention, OS, domain, applications, business function, and Active Directory.
Import from Active Directory, LDAP, IAM, or set custom permissions to provide efficient account integration.
Support multiple workflow, ticketing systems, and notification to coordinate with IT and security teams.
Provide archiving and auditing capability of all collected privileged account information for modeling, threat hunting, and forensics.
By unifying privileged access management and other IT management solutions, IT and security teams have a single, contextual lens through which to view and address user and asset risk by activity, asset, user, and privilege.
Next, as a critical privileged account integration, please consider step 3 again for a moment. Once you have greater control over privileged access in server environments, the next logical step is to bring those systems under consistent management, policy, and single sign-on. Unix, Linux, and Mac have traditionally been managed as stand-alone systems, each a silo with its own set of users, groups, access control policies, configuration files, and passwords to remember. Managing a heterogeneous environment that contains these silos, plus a Microsoft or cloud environment, leads to inconsistent administration for IT, unnecessary complexity for end users, and a vast sprawling of alias accounts. These are known threats and areas of interest for a threat actor.
Therefore, how do IT organizations achieve consistent policy configuration to achieve compliance requirements, a simpler experience for users and administrators, and less risk from improperly managed systems?
The ideal solution is to centralize authentication for Unix, Linux, and MacOS environments by extending a directory store like Microsoft’s Active Directory with single sign-on capabilities to these platforms. By using a directory bridge and extending Group Policy to these non-Windows platforms, IT environments gain centralized configuration management for accounts and stop the sprawl of local alias accounts.
No requirement to modify a directory stores schema to add Linux, Unix, or MacOS systems to the network. This provides stability as the technology evolves.
Provides a pluggable framework with an interface similar to Microsoft’s Management Console (e.g., Active Directory Users and Computers, ADUC) on Linux or MacOS, and full support for Apple’s Workgroup Manager application to allow for seamless management with tools administrators are currently familiar with (low friction).
Single sign-on for any enterprise application that supports Kerberos or LDAP.
Allows users to leverage their Active Directory credentials to gain access to Unix, Linux, and MacOS, consolidating various password files, NIS, and LDAP repositories into Active Directory and removing the need to manage user accounts separately.
These concepts will enable simplified configuration and policy management for non-Windows systems and enhance the user experience by consolidating the number of credentials any one user needs to remember. Therefore, the lower the number of accounts, the less to correlate during an audit per identity, and the lower the risk surface for a threat actor to target.
Step 10: Identity and Access Management Integration
As organizations mature along their PAM journey, they will more clearly understand how identities can be used as an attack vector and why the integration of PAM and IAM provides the best level of protection for any organization today against identity- and account-based attack vectors.