12. PAM Architecture – 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_12

12. PAM Architecture

Morey J. Haber1 
(1)
Heathrow, FL, USA
 

A successful privileged access management (PAM) architecture should secure privileges across every user, session, and asset. Traditionally, the first significant piece of a PAM solution that organizations look to implement is an automated credential management solution that provides secure access control, auditing, alerting, and recording for any privileged session. Other central pieces of PAM include least privilege management and remote access management. These three solutions should all be integrated and work together for your entire privilege universe.

Privileged credential management technology is designed to manage a local or domain shared administrator account, a user’s personal administrative account, service accounts, application-specific accounts, network devices, database credentials, and automation accounts, regardless of being on-premise or in the cloud. By improving the accountability and control over privileged passwords, IT organizations can minimize privileged threats and achieve compliance objectives.

However, how this technology is deployed depends on the management of the use cases listed previously and the connectivity to resources on-premise, virtual, or in the cloud. In addition, environments need to consider high availability, disaster recovery, break glass, and time to recover once a fault occurs in the solution itself, or any component in the supporting infrastructure—from networks to Internet connectivity—that could cause an outage. These are all architectural considerations for a Tier-1, mission-critical application.

Therefore, many different configurations need to be supported to scale from single site installations to multisite, geographically dispersed environments. If we consider a traditional on-premise deployment first, PAM architectures can be configured using the following paradigms:
  • Active/Active: Sometimes called multiactive, this deployment type allows multiple nodes (distributed heads) to be active at one time. Each node is connected directly to the database.
    • Advantages:
      • Unlimited scalability, only inhibited by database performance and network bandwidth.

      • Redundancy of components for high availability.

      • Targeted password change events for specific locations and network zones.

    • Disadvantages:
      • Redundant external database configurations, such as Microsoft SQL Always On, can be costly and require dedicated staff for administration. And, open source database solutions may not be suitable for a Tier-1 application of this nature.

      • It is the responsibility of the customer to ensure that the database and supporting servers are securely hardened, monitored, and protected.

  • Active/Passive: Two installations are required for active/passive. The internal databases are replicated, and a missing heartbeat sent from the primary to the secondary installation indicates if it should take over operations.
    • Advantages:
      • Easy to set up.

      • All high availability is incorporated within the solution.

    • Disadvantages:
      • An external load balancer is required for auto-switching users to the active appliance.

      • The failover process is not instantaneous and can take time to initiate.

      • Cold Spare versions can have databases that are out of sync or in a split-brain configuration if their age from initial backup is too large.

  • Third-Party Failover: For deployments where only one installation is desired, virtualization technology can be used to keep the installation continuously available via replication, even if the physical server running the instance goes offline for any reason.
    • Advantages:
      • Cost-effective high availability with a single instance.

      • Provides high availability and continuous operation during host server outages.

    • Disadvantages:
      • Relies on virtual replication technology to be licensed, set up, and configured correctly.

      • Does not provide redundancy in the event of a software failure.

Regardless of the selection for PAM availability and fault tolerance, the model needs to be adjusted depending on the deployment location, and it should consider if a hybrid model is required as well. Since these architectural variations address PAM as an on-premise deployment, clients additionally could deploy PAM in the cloud as an infrastructure as a service (IaaS), platform as a service (PaaS), or software as a service (SaaS) solution. These will be addressed later in this chapter since deployment architectures are different when hosting “as a Service” is involved. To that end, consider the PAM Maturity Model contained in Table 12-1. It will help you understand your journey in implementing PAM and which architecture and deployment model (cloud or on-premise) you may need to satisfy your desired goal and mission.
Table 12-1

PAM Maturity Model

The Privilege Maturity Model

Level 1

Absent

Level 2

Ad Hoc

Level 3

Standardized

Level 4

Managed

Level 5

Advanced

Shared Accounts

Limited controls to verify who is using which account and when

No shared account password management

Lack of accountability for access and activity

Manual controls and processes

Audit trail is not reliable and may have missing or inconsistent information

Automated discovery, inventory, and onboarding

Centralized password management with workflow approval and automated rotation

Privileged account usage reporting and certifications

Passwordless session access and management

Context-aware privileged access using RBAC, ABAC, and MFA

Identity integrated (IAM, SSO, AD Bridge, and AD Audit)

Advanced coverage (cloud, SaaS, apps)

HSM integration

User behavior analytics

Application and Service Accounts

Unknown and unmanaged

Stale accounts

Potential for default or guessable passwords

Loosely documented

Hard-coded and potentially exposed

Rarely changed, if ever

Targeted application-to-application management

Eliminated targeted hard-coded passwords

API-driven retrieval

Centralized application-to-application management

No hard-coded passwords

DevOps-integrated

High volume and highly available

Caching for redundancy and performance

Active Monitoring and Threat Detection

No monitoring

Distributed logs

Lack of tracking individuals’ use of shared accounts

Centralized audit controls

Individual accountability over use of shared accounts

Deep visibility over sessions and keystrokes

Advanced threat detection and UBA

SIEM integration

Automated keyword and activity indexing

Automated Privilege-Active Response (Deny, Disable, Quarantine, Alert)

IAM integration

Platform independence

Desktop Privilege Management

Unmanaged users have local administrative privileges or access

Remove or restrict some administrator rights

Provide basic desktop tools for ad hoc elevation

Centralized Password Management

Limited whitelist and blacklist proxy access

Reputation services

Fine-grained access to privilege elevation

Controlled remote access sessions

File integrity monitoring (FIM)

Controlled and monitored lateral movement

Context-aware access policy (user risk, asset risk, ITSM validation, MFA)

IAM integration, with separation of duties by role

Desktop asset and user policy independence

Server Privilege Management

Unmanaged users have root, local, domain administrative access

Siloed

Open source (SUDO) management

Centralized Password Management

Limited whitelist and blacklist application access

Communications regulated by a proxy or jump server

Platform-dependent

Fine-grained access by account, identity, and applications

Privileged shell

Controlled remote server sessions

File integrity monitoring (FIM)

Controlled and monitored lateral movement

Context-aware access policy (user risk, asset risk, ITSM validation, MFA)

IAM integration, with separation of duties

Server asset and user policy independence

Infrastructure and IoT Privilege Management

Unmanaged users have root access

Credentials are potentially reused and guessable

Siloed management by department

Vendor-dependent security, hardening, and tools

Centralized Password Management

Limited command level whitelist and blacklist

Bastion host for proxied access

Fine-grained access based on context and user

Monitored remote sessions

Controlled and monitored lateral movement

Context-aware access policy (user risk, asset risk, ITSM validation, MFA)

IAM integration, with separation of duties by role

Secure Remote Access

Internet-exposed remote access protocols

No centralized account management model

Remote access is provided over secure tunneling technology like VPN or reverse proxies

Activity and sessions are not monitored

Devices delegated for remote access are segmented and a bastion host is provided for remote access

Activity is monitored based on context-aware principles

A workflow is implemented with managed accounts to access internal resources

Activity and sessions are monitored for inappropriate behavior and lateral movement

Just-in-time access is provisioned to users only when appropriate or needed

Activity and sessions are monitored for inappropriate activity

Direct resource communication is allowed without remote access protocol tunneling

On-Premise

On-premise deployments of privileged access management solutions operate within the confines of an organization’s firewalled perimeter. They can be configured to manage resources externally as long as they are allowed to have outbound connectivity to the cloud from the data center or an authorized management node. Essentially, using any one of the paradigms previously discussed, software, appliance, or virtual appliances are deployed within the corporate data center to meet business objectives and some components are configured appropriately for external communications. Regardless of whether or not outbound communications are a requirement, the implementation can be air-gapped (no Internet access), but must have a logical network route to target systems, or through remote management nodes, to conduct password changes remotely, record sessions, capture events, or manage communication with agent-based technologies.

The final architecture is very similar to an on-premise email solution or antivirus system with centralized management. The primary difference is that the PAM manager needs to resolve hostnames and route to each managed object for password changes, and each node needs to be able to resolve the server and have a network route for any agent technology that may be a part of the PAM deployment for password changes, remote access sessions, or least privilege management.

If the network has stability issues with DNS, NTP, AD replication, routing, or performance, the integrity of any PAM deployment can be an issue. A well-architected and stable network is absolutely required since PAM relies on the infrastructure to onboard, manage, and change passwords efficiently with session monitoring and least privilege.

For a threat actor, a weak infrastructure is a perfect place to get lost in the noise. Errors from DNS, AD replication, as well as poorly managed logs can help conceal their identity, even with a PAM deployment. Think of Waldo if he can hide behind infrastructure errors that would normally not be present in a properly functioning environment. Errors should be the exception, and layering on security technology when the environment has poor cybersecurity hygiene will not make the infrastructure safer, just more complex.

Cloud

Cloud-based deployments of privileged access management can take on several different forms:
  • Cloud-to-cloud for privilege management, including application-to-application (IaaS) in the form of secret storage

  • Cloud-based privileged access management for all key functions: password management, session management, remote access, auditing, reporting, and least privilege (SaaS)

  • Hosted privileged access solutions in support of hybrid deployment models (PaaS)

If this was a multiple-choice question, your strategic business initiatives might require more than one of these categories. It is highly uncommon for privileged access management to be used in only one silo of the business without any plans to expand the technology to all sensitive systems and privileged accounts. While initial deployments may start out small, the cloud may be needed later for management everywhere. This is critical when selecting PAM on-premise, in the cloud, or a hybrid approach. For hybrid approaches, they can be any combination of the three plus an on-premise implementation to link them all together. The size, complexity, and geographical dispersity of your organization will help drive which solution is right for you. And, as you begin to figure this out, be mindful of local and regional laws governing personal data privacy and the storage of secrets in the cloud. That alone may force one deployment model over another.

Infrastructure as a Service (IaaS)

Whether your organization chooses to operate within a single cloud provider, multiple vendors, or has to meet geographical requirements-based regulations, cloud environments need to authenticate applications and users like any other information technology implementation. Application-to-application (or cloud-to-cloud and any applicable combinations) privileged access management has unique requirements compared to an on-premise implementation:
  • High-availability architectures may warrant additional cloud instances to provide high availability in case of a cloud or infrastructure outage that is out of the end user’s control.

  • Regulations may require separate, but duplicate, instances and filter data based on region or local laws.

  • Environments may have public and private IP ranges to provide the required services and require special provisions to secure them.

  • Environments may have internal IP and hostname collision domains due to poor network designs or acquisitions that cannot be properly resolved from the cloud.

  • Vulnerability management due to public services takes a higher priority to mitigate threats vs. managing privileged access.

  • API access requires special, extensive management for secure access and to limit exposure from authorized sources.

  • Sensitive data in the cloud, such as passwords, require additional database security, such as HSM, to protect information. This may be a basic feature for a SaaS implementation, but not present in a PaaS implementation.

For organizations looking to perform PAM only in the cloud, there are multiple technology vehicles to implement a solution. The most common is to use black box technology based on PAM solutions hosted in cloud marketplaces (Amazon AWS, Microsoft Azure, Google Cloud, Oracle Cloud, or third-party managed service provider). These allow for hardened PAM deployments based on a variety of licensing models and cloud runtime costs. Some PAM vendors also offer solutions that can be instantiated as a software implementation in a cloud operating system template. These provide the most flexibility for a client, but security, hardening, and operating system configuration are the responsibility of the client, not the cloud provider or PAM vendor. The risks are higher for these types of implementations due to any internal lapses the environment may have in basic cybersecurity hygiene, but the benefit is that they can be highly customized to meet unique requirements.

Software as a Service (SaaS)

Privileged access management solutions deployed as SaaS can operate solely in the cloud and can require an on-premise management node to route password changes, perform remote access, deploy policies, and aggregate events. These implementations are entirely managed by the PAM vendor and share cloud resources with other PAM clients in the vendor’s single-tenant or multitenant installation. While there are currently very few PAM solutions in the cloud using SaaS, the trend suggests businesses are gaining the confidence of storing passwords, policies, and management tools for PAM in the cloud. This trend is being led by individual vendors and managed service providers (MSPs) that are providing cost-effective services based on commercial PAM offerings, with little to no expertise needed by end users.

As with any SaaS solution, consider the following for managing passwords, remote sessions, and least privilege access from the cloud:
  • Is the SaaS offering single tenant or multitenant? Changes in the offering may cause unexpected outages or affect your change control windows.

  • Which regions does the SaaS solution support? Can they provide coverage for a worldwide deployment?

  • How does the solution handle data privacy, and are they compliant with initiatives like GDPR?

  • Is the SaaS vendor SOC, PCI, or ISO compliant? Do they offer a FedRAMP certified version for federal clients?

  • What is their SLA for uptime and performance?

  • What is their SLA for mitigating security threats, and do they publish the results from public penetration tests?

  • What is their financial standing? Are they public or private?

  • What is their high availability model if a crisis arises?

Respectfully, there are probably dozens of additional questions you should ask when licensing a Tier-1 solution from a vendor as a SaaS application. You are putting the lifeblood of your privileged accounts and remote sessions in the management of a third party and you need to be reasonably certain that their security is better than yours to prevent them from becoming the source of an incident.

Platform as a Service (PaaS)

Think of a platform as a service as a black box. It provides all the functions and features you need to perform a task, but without the maintenance headaches a software solution provides. It is different than SaaS because it is your platform to manipulate and customize, but similar in that upgrades and security patches can be deployed as a packaged solution for the entire platform vs. the operating system and applications as separate entities.

In many cases, PaaS is a lift and shift of on-premise software to the cloud with some enhancements to make it more of a black box than it was as an on-premise technology. Virtual appliances are a perfect example of this philosophy when applied to privileged access management. Vendors have taken their on-premise solutions and created a black box version that is available in the marketplaces of leading vendors like AWS, Azure, and Google to provide the same experience as on-premise, but without the need to deploy the solution yourself. Your on-premise platform for PAM is now available in your private cloud instance with just a few mouse clicks. Like anything, however, there are caveats that this deployment model uniquely possesses:
  • While you maintain the platform, you do not control the hypervisor and its security. Make sure your cloud provider is actively staying vigilant with cloud security since this instance has the keys to your kingdom.

  • Be mindful of the runtime costs for the platform. PAM solutions converted to PaaS need to be operational 100% of the time and may incur significant CPU and image size costs per month. In many cases, it may be more expensive than running a similar VM on your own hypervisor.

  • PaaS PAM solutions typically do not take advantage of modern development concepts like containers and micro-segmentation. They are a monolithic shift from on-premise to the cloud. While they will function correctly, they are not optimized for cost, scalability, and fault tolerance. All need to be considered, just as with an on-premise architecture.

  • Finally, be mindful of the gray area between PaaS, IaaS, and SaaS. Many solutions can operate across all three and it is up to the business to determine if the vendor’s implementation actually meets the security and business objectives for their organization . Just because it is hosted in the cloud does not mean it is actually any one of the three. In the end, it could be a butchered implementation of all three.

These three types of PAM architecture will be discussed even further in Chapter 15.