25. Privileged Account Management Implementation – Privileged Attack Vectors: Building Effective Cyber-Defense Strategies to Protect Organizations

© Morey J. Haber 2020
M. J. HaberPrivileged Attack Vectorshttps://doi.org/10.1007/978-1-4842-5914-6_25

25. Privileged Account Management Implementation

Morey J. Haber1 
(1)
Heathrow, FL, USA
 
Organizations increasingly recognize that properly securing and controlling privileged credentials ranks as one of the best defenses against attacks from external hackers as well as from malicious insiders. For optimal results, a privileged access management solution should protect identities, accounts, passwords, and keys at all stages of the privileged attack vector kill chain (Chapter 1) by implementing comprehensive layers of control and audit. The overall objectives for your implementation should include the following:
  • 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.

Implementing an end-to-end privileged access management solution should follow a defined process to minimize costs and distractions, and to speed results. When managing privileges as an attack vector, applying this simple, ten-step approach helps manage risk and provide predictable and documentable results (Figure 25-1). The result of this ten-step process is measurable as you embark on your PAM journey.
Figure 25-1

Ten Steps for a Successful Privileged Access Management Implementation

Throughout the process of selecting and deploying your privileged access management solution, keep in mind these steps are just a guide and do not necessarily need to be followed in sequence. However, it is highly recommended every organization starts with step 1 because, if you have no idea where your privileged accounts are, you have no way of measuring success for any step that you may choose to do next. Figure 25-2 provides a simple graphic for explaining the scope for step 1 within your entire organization considering all the roles and resources that need coverage.
Figure 25-2

Scope of Discovery Within a Typical Enterprise

Step 1: Improve Accountability for Privileged Accounts

The most logical starting point for gaining greater control over privileges is by improving accountability over privileged passwords. In simple terms, discovering every place privileged accounts exist throughout your IT universe and determining which ones are being shared, by whom, and why they are being shared. Ineffective management of shared accounts is a problem that has significant scale and risks. You don’t have to look much further than recent breaches to understand the implications or the challenges. As a reminder:
  • 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?

The answer is something we have touched on several times: automation. Automating privileged account discovery provides accountability that helps drive password and session management, the removal of administrative rights on endpoints (least privilege), and the management of privileged remote access sessions. By improving the accountability and control over privileged access, IT organizations can reduce security risks and achieve compliance objectives. With this goal in mind, consider these additional five subrecommendations for the accountability of privileged accounts:
  1. 1.

    Full network scanning, discovery, and profiling with auto-onboarding of privileged accounts.

     
  2. 2.

    Provide discovery of privileged accounts through third-party integrations and API calls.

     
  3. 3.

    Build permission sets dynamically according to data provided during discovery assessments.

     
  4. 4.

    Apply granular access control, workflow, and auditing for any discovery process to ensure accuracy.

     
  5. 5.

    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.

To aid in this step, consider the top ten subrequirements for desktop least privilege management:
  1. 1.

    Default all users to standard user privileges, while enabling elevated privileges for specific applications and tasks, without requiring administrative credentials.

     
  2. 2.

    Enforce restrictions on software installation, usage, and OS configuration changes based on privileges assigned by rules.

     
  3. 3.

    Eliminate the need for end users to require two accounts to perform appropriate administrative tasks.

     
  4. 4.

    Make dynamic least privilege decisions for applications based on that application’s vulnerability, risk, reputation, and compliance profile.

     
  5. 5.

    Match applications to rules automatically based on asset- or user-based policies.

     
  6. 6.

    Report on privileged access to file systems for all users and document system changes during privileged sessions to prevent malicious tampering.

     
  7. 7.

    Monitor sessions and log keystrokes during privileged access to determine whether or not a local user is using privileges appropriately.

     
  8. 8.

    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.

     
  9. 9.

    Integrate with other privilege solutions to achieve a uniform approach to password management and remote access.

     
  10. 10.

    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

In current information technology environments, business-critical, Tier-1 applications are attractive targets for threat actors. They contain the sensitive data and applications attackers want to compromise, but rarely can a threat actor effectively target the most sensitive resources first. Obtaining privileged user credentials via other assets can provide access to these sensitive systems through privileged attack vectors and lateral movement. Having root passwords, superuser status, or other elevated privileges is important for users to do their jobs. Unfortunately, this practice also presents significant security risks stemming from intentional, accidental, or indirect misuse of those privileged credentials. This is especially true when those credentials are shared or have weak passwords leading to trivial access of Tier-1 systems. The impact can be felt on a server class operating system from Windows to Unix and Linux. For server-based operating systems, privileged attack vectors become exaggerated due to the following:
  • 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.

Therefore, the top ten subrequirements for server privilege management capabilities include the following:
  1. 1.

    Industry-standard support for authentication solutions, including OAuth, SAML, and other multi-factor solutions.

     
  2. 2.

    Advanced control and audit over commands at the system level, even when they are obfuscated in scripts or renamed.

     
  3. 3.

    A flexible policy language and rules to provide a migration path from native tools with the features needed to manage virtually any business requirement.

     
  4. 4.

    Extensive support for many Windows, Unix, and Linux platforms.

     
  5. 5.

    Recording and indexing of all sessions for quick discovery during audits.

     
  6. 6.

    Brokering privileges transparently, ensuring user productivity and compliance.

     
  7. 7.

    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.

     
  8. 8.

    REST API for easier integration with third-party products.

     
  9. 9.

    an architecture that provides high availability and seamless disaster recovery.

     
  10. 10.

    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.

Therefore, for step number 4, consider expanding your application management initiatives to include application reputation and application control services. With these capabilities implented, automated decisions on whether or not an application is too dangerous to execute can be based on:
  • 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

Based on these criteria, information technology and security teams should adopt privileged access management policies to compensate for the risk. That is, the application should be measured against the threat and the runtime of the application should be:
  • Denied execution

  • 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

As we have discussed, almost all attacks involve some form of remote resource access. Only an insider initiating an attack directly on a system’s terminal is not engaged in remote access. In addition, the vast majority of these attacks come from true external threats and can involve threat actors that are specifically targeting your organization all the way through remote contractors, vendors, and even remote employees. Remote access, especially for privileged accounts, provides an entry point past traditional perimeter defenses that a threat actor can leverage to fulfill their nefarious mission. With these characteristics in mind, privileged access management should manage remote access sessions by:
  • 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

The most common username and passwords for network and Internet of Things (IoT) devices within an enterprise are not necessarily the defaults that come with the device. Most administrators change them, but they may choose one that is easily guessable. According to Forbes1 in 2019, the top ten most hacked passwords are (m is for millions):
  1. 1.

    123456 (23.2m)

     
  2. 2.

    123456789 (7.7m)

     
  3. 3.

    qwerty (3.8m)

     
  4. 4.

    password (3.6m)

     
  5. 5.

    1111111 (3.1m)

     
  6. 6.

    12345678 (2.9m)

     
  7. 7.

    abc123 (2.8m)

     
  8. 8.

    1234567 (2.5m)

     
  9. 9.

    password1 (2.4m)

     
  10. 10.

    12345 (2.3m)

     

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.

To summarize, here are some key risks that stem from a simple lack of privileged account management on network and IoT devices:
  • 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.

Like traditional desktops and servers, unknown or undermanaged virtualized and cloud environments can create a significant security gap that opens networks to security breaches, data loss, intellectual property theft, and regulatory compliance issues. The first step in getting control over these assets is discovery as defined in step 1. There are several techniques used to discover assets in virtualized and cloud environments, including the following:
  • 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.

Once cloud and virtualized instances are identified, they must be managed to limit exposure. From a privileged access management perspective, the options to secure these assets are similar to traditional desktops and servers, but with a few extra unique characteristics:
  • 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.

Now that the resources are under control, what about the hypervisor and cloud management platform itself? Here, again, inappropriate or malicious activities at this management level could have a devastating impact on the business. This includes administrators of your VMware, Microsoft Hyper-V, Amazon AWS, and Microsoft Azure environments. To counteract this threat, organizations again have several options:
  • 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

For commercial application developers, or programmers who create automated DevOps processes, consider how beneficial it would be if you never have to enter credentials to begin your automation processes, or hard-coded passwords or keys in scripts to perform tasks. If DevOps tools automatically retrieved the current and proper credentials or queried a management solution to prove authorization (zero trust), any risks to automation based on privileged attack vectors could be mitigated. Management tools for services, remote access, and infrastructure would automatically recognize the logged-on user or automated process, the asset they are executing from, be fully context-aware, and seamlessly request and pass credentials for the needed functions. Privileged access management solutions for password management and secrets storage make this capability a reality using an Application Program Interface (API) to set, retrieve, and process credential and password requests. Some of the benefits of this approach for DevOps are the following:
  • 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

Third-Party Integrations

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.

Therefore, consider privileged account information as a single source of privileged management data. In addition, all PAM solutions should be capable of providing the following ten subcategory integration methods:
  1. 1.

    Correlate low-level data from a variety of third-party solutions to uncover critical threats natively, or via certified third-party connectors.

     
  2. 2.

    Correlate system activity against application risk data and known malware.

     
  3. 3.

    Report on compliance, benchmarks, threat analytics, what-if scenarios, and resource requirements.

     
  4. 4.

    View, sort, and filter historical data from multiple perspectives based on integrated role-based access.

     
  5. 5.

    Integrate with SIEM solutions and provide support for common protocols like Syslog and SNMP.

     
  6. 6.

    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.

     
  7. 7.

    Group, assess, and report on assets by IP range, naming convention, OS, domain, applications, business function, and Active Directory.

     
  8. 8.

    Import from Active Directory, LDAP, IAM, or set custom permissions to provide efficient account integration.

     
  9. 9.

    Support multiple workflow, ticketing systems, and notification to coordinate with IT and security teams.

     
  10. 10.

    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.

Directory Bridging

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.

The top four subrequirements for any bridge solution should include the following:
  1. 1.

    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.

     
  2. 2.

    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).

     
  3. 3.

    Single sign-on for any enterprise application that supports Kerberos or LDAP.

     
  4. 4.

    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

Identity and access management (IAM) plays a critical role in an organization’s identity governance strategy. As organizations grow, so do the number of applications, servers, and databases used. Access to the organization’s resources is typically managed through IAM solutions, which offer capabilities like single sign-on, provisioning, role-based user management, access control, and governance. But securing an organization’s sensitive data and applications requires more. Provisioned users, regardless of privileges, can leave an organization exposed if activity of their usage is not monitored and documented properly. Identity and access management solutions help IT teams answer: “Who has access to what?” But, to achieve complete user visibility, privileged access management solutions are required to address the remaining questions: “Is that access appropriate?” and “Is that access being used appropriately?” That is, PAM solutions should be providing more visibility and deeper auditing of the access and use of privileged accounts. Many times, IAM solutions will add users to a system or applications group, but will not provide the details as to the session activity nor keystrokes collected during the privileged session. As such, PAM extends the visibility of the IAM solution to further tighten security and audit controls. Figure 25-3 provides an illustration of this integration.
Figure 25-3

IAM and PAM 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.