Published 13 November 2020 

Abstract

A consistent set of well thought out Privileged Access Management (PAM) controls that are aligned with a comprehensive cybersecurity framework is an imperative for most organizations. This enables the automation and enforcement of controls over privileged credentials in any system, platform, or environment.  As we’ve worked with our clients in developing IAM/Security strategies and reference architectures, PAM continues to be a top priority, and this will continue for the foreseeable future.

While most organizations at least claim to have a “least privileged access” strategy, the challenges associated with executing on this strategy are not insignificant.  No matter how far along you are (or aren’t) in PAM deployment, don’t delay developing a Reference Architecture for PAM, which includes documented business and technical requirements, a comprehensive, defensible set of patterns mapped to existing and required capabilities and, ultimately, vendor solutions. By developing this foundation your organization will be able to select the appropriate vendor(s) and deploy the solution that best fits into your IAM environment and with the appropriate security controls. This process is intended to put your organization in the best position to make vendor choices, to determine your deployment priorities and strategy based on a solid requirements and business; not simply responding to vendor marketing programs and promises.

This report provides a solid framework for developing a PAM Reference Architecture. We review common enterprise requirements for PAM, then describe how to build a Reference Architecture for PAM that can fit well within the context of leading vendor offerings/directions in an effort to help you understand how to match vendor solutions to your needs and how to deploy those solutions thoughtfully and effectively.

Authors:

Doug Simmons Principal Consulting Analyst [email protected]

Gary Rowe CEO/ Principal Consulting Analyst [email protected]

Executive Summary

In reviewing most of the high-profile breaches over the past decade or so, it is apparent that the ultimate targets for most hackers are the administrative accounts used by systems administrators and administration-centric applications. System administration accounts for Operating Systems like Windows and Linux, network and security devices, cloud platforms, databases such as Oracle and SQL Server, and web servers – as well as privileges embedded within applications to perform administrative functions in application-to-application communications are the top prize for hackers and thieves. These administrative accounts are privileged accounts, in that they enable the human or system to configure environments and access the data contained therein. Once a hacker has administrative access to a single server or device, the path often opens to move laterally within the infrastructure to hack deeper and deeper within the enterprise – or beyond.

TechVision Research feels that PAM is one of the more critical elements of an enterprise security posture. Hackers and thieves want your privileged account access rights because that is the way to your data – whether in your data center or in the cloud. No matter how far along you are (or aren’t) in PAM deployment, don’t delay developing a Reference Architecture for PAM, which includes documented business and technical requirements, a comprehensive, defensible set of patterns mapped to existing and required capabilities and vendor solution capabilities. With these elements all addressed, you will be able to select the appropriate vendor and deploy the solution to fit your IAM environment and address specific information security risks.

As we state in this report, Reference Architectures are standardized frameworks that provide a model for a domain, sector, or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution designs and as such are not meant to be implemented directly. Rather, they are used to guide more concrete efforts. Typically, a Reference Architecture includes common architecture principles, patterns, building blocks and standards. A Reference Architecture for PAM is crucial to help identify the areas that require more stringent protection mechanisms for administrative access management. Once a Reference Architecture that defines common architecture principles, patterns, building blocks and standards is developed, your organization can better evaluate vendor solutions and their ability to address the critical needs of your organization.

Introduction

As we described in our report titled “Privileged Access Management: More Necessary Than Ever as Cloud-Shift Intensifies”, published in July 2019, a consistent set of well-thought out Privileged Access Management (PAM) controls that are aligned to a comprehensive cybersecurity framework is an imperative for nearly every organization, enabling the automation and enforcement of controls over privileged credentials in any system, platform, or environment.  PAM also identifies all known exceptions that require special control implementation. This is particularly important considering the large number and dynamic nature of resources many organizations are deploying in the cloud, coinciding with requirements to provide on-going support for multi-cloud environments. Most of these cloud environments (e.g., Azure, AWS, Google) have powerful management consoles and APIs that can expand the available attack surface requiring protection and defense.

While most organizations recognize the importance of getting PAM right, the challenges we have seen revolve around where, how and what PAM services to deploy are not insignificant. Most PAM solution vendors have numerous modules that provide privileged management capabilities for specific types of environments, whether in the form of privileged password vaults, various user and administrative interfaces for requesting, approving and monitoring privileged access, session management, policy management, privileged threat analytics and so forth. Often, end user organizations begin deploying PAM solutions and their various modules in a reactive fashion, striving to address what they perceive to be their IT assets that pose the highest risk. This is, of course, valiant and necessary. However, like most IT initiatives, it is extremely advantageous to have a strong Reference Architecture for identity and access management (IAM) in general, as well as for PAM in particular.

That is the objective of this report – to help you develop a viable Reference Architecture for your PAM Program. As we describe in the TechVision report titled “IAM Reference Architecture”, published in September 2020, we provide guidance for how to develop and use a Reference Architecture to:

• Organize business requirements
• Tie the requirements to capabilities
• Identify strengths and gaps
• Measure progress

As we state in this report, Reference Architectures are standardized frameworks that provide a model for a domain, sector, or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution designs and as such are not meant to be implemented directly. Rather, they are used to guide more concrete efforts. Typically, a Reference Architecture includes common architecture principles, patterns, building blocks and standards. A Reference Architecture for PAM is crucial to help identify the areas that require more stringent protection mechanisms for administrative access management. Once a Reference Architecture that defines common architecture principles, patterns, building blocks and standards is developed, your organization can better evaluate vendor solutions and their ability to address the critical needs of your organization. In retrospect, trying to deploy a vendor solution with a Reference Architecture acting as a functional map specific to your organization is like trying to drive cross-country without a map – or GPS.

Before we dig into the specifics of developing a Reference Architecture for PAM, let’s quickly review ‘what PAM is’.

A Review of the PAM Technology Landscape

Simply put, most current-day PAM solutions take privileged account credentials, such as systems administrator and application service accounts, and put them inside a secure repository typically called a ‘vault’. Once inside the vault, system administrators and application service accounts need to go through the PAM system to access the credentials in the vault, at which point they may authenticate to the target system and their access is monitored and logged. When the credential is checked back into the vault, it is reset to ensure administrators must go through the PAM system next time they want to use a credential from the vault. This method of vaulting credentials (or ‘secrets’) and checking credentials in and out on a real-time, as-needed basis accounts for the majority of PAM approaches today. (There are more capabilities and new approaches, and we’ll get to them later.)

Stepping back a bit, we recognize that the first word in the term Privileged Access Management is the word ‘privileged’. A privileged account is one that has the ability to perform various types of configuration and operational activities – and these activities can vary quite a bit and can yield devastating consequences to enterprise systems, applications and networks if not tightly controlled. For instance, some privileged accounts, such as Windows Administrator, have more system rights than a ‘standard user’, as defined by Microsoft Windows. The Administrator type allows complete control, which means that the administrator can change settings globally, install applications, run elevated tasks, and do pretty much anything else on the server or workstation he or she is authenticated to.

On the other hand, the ‘standard user’ account type is more restrictive. Users with this type of account can work with applications, but they are not allowed to install new applications. They can change settings, but only settings that will not affect other accounts. If an application requires elevation of privileges, they will need administrative credentials to complete the task. This simple scenario highlights the ‘principle of least privilege’, which means “give the administrator or user only the capabilities needed to perform their job”.  In the case of an end (standard) user as just described, the principle can be somewhat easy to apply – give them next to nothing in terms of admin privileges.

However, when looking at the multiple types of systems administrators – or, sysadmins, that an enterprise typically has, the granularity required to appropriately affect the principle of least privilege can be quite daunting. What typically occurs, unfortunately, is that sysadmins of all types are granted or acquire over time much more administrative capabilities than they need to perform their day-to-day administrative duties. As a result, when it comes to effectively managing access to important resources and infrastructure, it is critically important to pay special attention to the accounts that have the most privileges, what can be done with those privileges, and who has access to those accounts.

PAM isn’t one monolithic ‘thing’. It is a set of capabilities that are focused on the type of administrative functionality being acted upon. Therefore, PAM solutions typically address four primary types of privileged access activities:

1. System Administrator Privileged Management (SAPM), which is focused on SysAdmin system administration, such as Windows Server or Azure Service administration, database administration, etc. The privileges associated with SAPM are usually restricted to administration and configuration services related only to the server, application, database, network device or platform to which the administrative account is associated. In other words, a Windows SysAdmin should only be able to run with administrative privileges on the associated Windows environment – he or she should not be able to use Windows SysAdmin credentials to configure
2. Privileged Session Management (PSM), which involves establishing and monitoring sessions to multiple systems.  Authenticating users (e.g., using two-factor authentication) and then providing the users access to shared accounts from which all actions will be monitored.
3. Application-to-Application Privileged Management (AAPM) is focused on what are often referred to as ‘service accounts’ associated with application identities and credentials used for system-to-system communications, such as a web application that interacts directly with a backend database. Service accounts typically have a username and password that is programmatically sent on the network when connecting to the target system (e.g., the backend database). The passwords associated with service accounts are not often managed in accordance with the Enterprise Password Policy that is focused on end users (i.e., people, including SysAdmins) and are all too often simple passwords, such as “password” that are not even rotated periodically inline with the Policy.
4. Super User Privileged Management (SUPM) is focused on “root” accounts (e.g., root is the superuser on Linux systems). Root / superuser accounts are most often used to make system configuration changes and can override user file protection. These are very powerful, often-human-associated privileged accounts that provide the basis for configuring almost everything deployed in the enterprise IT infrastructure, including in the cloud.

5. With this PAM level-set in mind, we’ll now start delving into what it takes to build a Reference Architecture to help your organization make more consistent and better future state architecture, product, service and deployment decisions.

Building a Reference Architecture for PAM

There are some logical steps to follow in order to develop an appropriate Reference Architecture for your organization, namely:

1. Identify and organize your key business requirements
2. Tie the requirements to specific capabilities that are necessary
3. Develop Reference Architecture patterns
4. Socialize the PAM Reference Architecture across your organization
5. Map the PAM Reference Architecture to specific vendors’ functional capabilities
6. Begin deployment
7. Measure progress

In subsequent sections of this document, we’ll dig into each of these steps in more detail.

Identify and Organize Your Key Business Requirements

Embarking on a major IT / security initiative such as PAM without key stakeholder input is typically a recipe for disaster. Key stakeholders are most often those people within the organization who ‘run the business’ in conjunction with those who ‘secure the business’ IT’. Together, this broad group of stakeholders contain members who may each have a vision for what needs to be done. Requesting their input – and being sure to address their requirements is necessary to build ‘buy in’. Without stakeholder buy-in before embarking on the journey of solution procurement, deployment and operations, one is left wide-open for possibly catastrophic misunderstandings down the road. Know who you are building and operating this for and why.

Most organizations have multiple lines-of-business (LOBs) that have very specific operational mandates, driven by a number of factors, including time-to-market, profitability, brand reputation and so forth. Thoughtlessly deploying a security solution that impedes their ability to succeed is not appropriate. Discuss business and functional requirements with them, as well as key executives, department or division heads, relevant system architects, operations staff and anyone else who may have important input. As an example, stakeholder input from several TechVision customers has commonly yielded the following requirements to be addressed in an enterprise PAM Program:

Business User Centricity	The PAM infrastructure must balance the requirements for risk-based access controls vs. business-enablement. It is important to note that, in most cases, the business creates risks while the requisite security controls tend to slow the business down. If properly implemented, PAM technology and processes can not only put the proper controls in place, but also help the business function more efficiently.
Improved User Experience	There must be a major focus on the User Experience such that security must be minimally invasive – if not fully transparent to the user. This includes: a.     Customizable user experience – The user interfaces supporting workflow automation supporting access requests and approvals must be extended to incorporate additional areas including IoT devices, mobile devices and privileged account administration requests. b.     Improved authentication capabilities – migrating to more effective forms of user authentication, such as multi factor authentication (MFA) and passwordless authentication must not impede end user efficiency in any way but must instead streamline the login experience. c.      Response time and performance experienced by end users must be strong and not impact usability in any way.
Improved lifecycle (change) management	Difficulty managing changes in employee and contractor status results in accumulation of privileges and slower, less accurate provisioning and de-provisioning of accounts and access rights that are commensurate with current responsibilities. This Includes being able to address a transition period where old and new rights are maintained, without violating SOD or other restrictions.
Improved de-provisioning	De-provisioning is inconsistent and often not complete (especially regarding cloud-based applications), leaving enterprise information vulnerable to misuse. This is applicable to both employees and contractors and key IT managed service providers.
Cloud aware	While the current PAM environment may be deployed largely on-premise and not readily conducive to migration or seamless integration with the cloud Infrastructure as a Service (IaaS) and Software as a Service (SaaS) options, the future state PAM environment requires: a.     Cloud extensibility – PAM needs to protect cloud resources better. b.     Just In Time Privileged Access Management (JIT PAM) for cloud and hybrid security.
IoT integration strategy	The PAM strategy for supporting administrative access to the growing landscape of Internet of Things (IoT) must be established.
Access governance and re-certification	Identity Governance and Administration (IGA) provides the lens into entitlements. Privileged users have much higher entitlements than typical end-users, and it is imperative for the IGA solution to intersect with PAM so that crucial capabilities like JIT PAM can be properly and securely enabled.
Audit framework	PAM should enhance the organization’s auditing framework so that Legal, Audit and others can be assured that “all” applications are evaluated consistently and efficiently. Regulatory compliance is a minimum standard of due care compounded by stricter data privacy laws continuing to be established.
Privacy regulation compliance	The PAM environment must support and enable a Privacy by Design model and support the EU’s General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA) and so on.
Risk Reduction	The PAM environment must reduce the organization’s exposure to risks resulting from aggregation of privilege that violate least-privilege and need-to-know principles. The highly fluid and distributed nature of the organization’s non-employee end users (e.g., contractors, managed service providers, etc.) must also be central to managing risks.
JIT PAM	JIT PAM for cloud and hybrid IT security should be uniformly and vigorously deployed.  JIT PAM means that system administrators – whether human or application functions, can be assigned privileges in near real time using their existing, or creating temporary, end-user accounts. JIT PAM limits the duration for which an account possesses elevated privileges and access rights in that the creation and deletion of an appropriate privileged account is assigned only to meet that specific period’s mission objectives. The goal is to eliminate the risk surface of having privileged accounts that are “always on”.
Provisioning administrative rights	The PAM environment must improve consistency in handling PAM and administrative accounts through a customizable delegated administrative interface.
PAM + MFA+	The PAM solution must support and in most cases require Multi-Factor Authentication (MFA) or stronger passwordless authentication, for all system administrators using PAM.

Table 1: Typical Business and Functional Requirements for PAM

Again, the above table represents a set of typical stakeholder requirements for PAM. These can be used as your own starting point in developing business and functional requirements, but the main point is that building and deploying anything without your stakeholder requirements firmly captured, documented and socialized is never a good idea. Please also note that we have provided a very thorough list of PAM functional / technical requirements in our report titled “Privileged Access Management: More Necessary Than Ever as Cloud-Shift Intensifies”. TechVision strongly recommends that this requirements collection and prioritization process and preferably the complete reference architecture process occur BEFORE evaluating and selecting vendor solutions. This allows your enterprise to be driving the dialogue based on your needs/priorities, not just accepting the path a vendor wants you to take.

In the next section, we’ll dive into TechVision’s IAM and PAM Reference Architecture Capabilities and how to map requirements to these capabilities.

Tie requirements to Specific Capabilities

As we describe in the TechVision report titled “IAM Reference Architecture”, the TechVision Research Reference Architecture for IAM is a master template that identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. ­­­This high-level template starts the journey.

Figure 1: IAM Reference Architecture master template

These IAM capabilities are described at the highest level as:

1. Interact: Interact is a layer of user interaction (UI) and application programming interfaces (API) that simplify consumer and application developer interaction with the rest of the IAM infrastructure. In this way, non-experts can follow the best practices of IAM without having to be experts in the field.
2. Access: Access is the layer that answers the “Who has access to what?” question. It ensures customers can confidently exchange information and get the services they need to buy and use your products. It ensures employees and partners have all the digital resources they need to get the job done, nothing less and nothing more.
3. Change: Change manages the relationships between all the moving parts within the digital environment. Change establishes the connections between people, devices, applications, and data when they enter the environment, manages the connections while the relationship exists, and disconnects when access is no longer necessary.
4. Manage: Manage is where the administrators of the IAM platform upgrade, configure, tune, troubleshoot, document, and audit the platform and its components.
5. Measure: Measure is the lens into the digital environment. It allows live behavior observation, anomaly detection, platform health checks, and deeper analysis of usage and threats. It also provides the audit and reporting capabilities necessary to prove you are performing your duty to protect.
6. Store: Store is the shared place where the identity profiles, attributes, and relationships are kept and maintained.

The next level of the architecture outlines the functional capabilities that are the foundation for a best-in-class IAM Reference Architecture. Each category is broken up into multiple capabilities at a level of greater detail. For example, interfaces can be for applications / developers (APIs, messaging services), Lines of Business, self-service or even robotic processes. This applies to each category and, based on stakeholder input, use cases and priorities can be further developed into Reference Architecture patterns or templates for specific services.

It is important to understand that these functional capabilities consider all type of objects and use cases within the IAM foundation. For example, identifying, securing, and collecting data pertaining to IoT devices is expected to be accommodated within the IAM Reference Architecture.

As ultimately implemented, different enterprises use different IAM capabilities in different ways to meet different protection needs. And they do so differently for different content and business functions because of the different risks and potential consequences associated with failures and costs associated with protection. One size does not fit all.

Once the required business capabilities are identified, the next layer of the TechVision Research Reference Architecture for IAM allows us to explore each of the specific technology or process elements comprising each capability in the form of a combined portfolio architecture. This is illustrated in Figure 2, below.

Figure 2: Combined Portfolio Architecture

In the template below, we’ve now illustrated the IAM capabilities required for a typical organization’s Privileged Access Management, removing all other IAM capabilities that are not directly supporting the PAM service. Note that this representation includes a typical ‘user story’ in the form of “As an Application Administrator, I want to…”. User stories help keep the focus on the capabilities necessary to support it and we highly recommend you work though your key user stories.

Figure 3: Typical PAM Capabilities Map

Note that this is intended to give you a sense for how to apply the reference architecture to PAM specific capabilities and to give you a sense for typical relative timing. In our example, we have determined that the IAM-related capabilities necessary to support the PAM Service for a large organization can be been color-coded as follows:

• Rose – requires significant investment over next 2 years. This typical organization does not currently support these IAM capabilities. An example is JIT PAM (Just In Time access).
• Orange – requires investment over next 2 years. The organization either currently does not support these IAM capabilities or they may require additional investment and deployment in order to achieve a requisite level of functionality. For example, most organizations currently support some form of MFA, but additional investments will generally be required.
• Grey – indicates capabilities that the organization IAM has in place in some capacity, although it could be likely that some augmentation may be required to improve functionality and ubiquity to fully meet the organization’s requirements. An example here is Federation/SSO which may be relatively mature in many organizations – but could be enhanced over the next few years.

Please recognize that your Capabilities Map is likely going to be different than the one shown in Figure 3. The important point is to start with the complete list of capabilities building blocks as shown in Figure 2, and pare that down to represent what PAM requires, color-coding to show where you will likely need additional investment or attention. TechVision can – via dialogues or full consulting engagements, work through this process with your team.

The PAM Service IAM capabilities are used as input to the development of the Reference Architecture pattern illustrated and described in the next section.

Develop PAM Reference Architecture Patterns

As we described above, PAM looks to provide an additional layer of security in support of administrative and other high-risk access. The policies maintained in the PAM control service dynamically evaluate the risk of a given operation based on a variety of environmental and risk factors and filter access if risk exceeds a defined threshold. This extends from the internal network to external connections. As the example PAM Reference Architecture pattern illustrates below, the intent is to draw ‘what good looks like’ for your organization. This pattern should be indicative of what you want. It is completely vendor-agnostic in this instantiation so that you have the vision ready to query multiple vendors about how they can support this pattern via Request for Proposal (RFP) or Request for Information (RFI).

Figure 4: Example PAM Reference Architecture Pattern

This pattern supports the use case in which an application programmatically ‘checks out’ the service account credentials from the PAM service, eliminating the need for setting up hard coded credentials for the service account and guaranteeing that the service account credentials are continuously recycled. The overall PAM environment should be viewed as the gatekeeper to privileged operations.  Also, even though not static, PAM still need to Authorize as to who can access and make requests via JIT PAM.

JIT PAM means that system administrators – whether human or application functions, can be assigned privileges in near real time using their existing, or creating temporary, end-user accounts. JIT PAM limits the duration for which an account possesses elevated privileges and access rights in that the creation and deletion of an appropriate privileged account is assigned only to meet that specific period’s mission objectives. The goal is to eliminate the risk surface of having privileged accounts that are “always on”. We believe that JIT PAM is a key direction in this space and will dedicate future reports to this topic.

Using JIT PAM, the journey begins with ‘triggers’ associated with workflow requests taken in context with other information including existing entitlements (e.g., RBAC, ABAC) associated with the user, MFA usage, etc. These triggers act as input to the programmatic ‘methods’ for assigning elevated privileges that include on-the-fly administrator account creation and deletion, assignment to privileged security groups, impersonation by means of attaching an existing user account to a privileged account and tokenization of the application to raise privileges on a local system. Policies are applied to the request and the actual session to monitor activity and ensure it falls within identified ranges. Once the privileged session is concluded, the entitlements are immediately removed. Limiting the length of time associated with these elevated privileges mitigates risk.

When JIT PAM is combined with role-based or attribute-based access control policies (RBAC and ABAC, respectively), organizations can better ensure control and gain insight as to every user’s systems access at any point in time. Coupling Multi-factor (or passwordless) Authentication (MFA) with JIT PAM processes also adds a significant element of trust that the individuals requesting elevated privileged access are who they say they are, and with added contextual information such as device, geo-location, previous requests/approvals and so forth, an organization can provide better guard against multiple threat vectors.

If administrative actions were attempted that fell outside the associated policies, session recording enables alerting and the escalation of remediation processes. Note that privilege definition needs to be maintained at the time of newly updated and retired assets, so ongoing governance and monitoring is essential.

Your organization will need to determine the prioritization of and the criteria for what is considered privileged operations requiring additional measures to protect, control and track as well as determining what would be considered less risky administrative operations where the additional measures are not warranted. The key is finding this balance.

Once you and your team have settled on appropriate Reference Architecture capabilities mapping and developed one or more patterns, it is important to socialize the PAM Reference Architecture across your organization. This is typically done by presenting at your organization’s periodic Architecture Review Board meetings, as well as sharing drafts of your work with key stakeholders throughout the process in order to solicit feedback and enhance their engagement in the entire process.

Map to Vendors’ Functional Capabilities

There are a number of very capable vendors of PAM solutions on the market today. This mapping is where your organization can better control its own destiny in both selecting vendors that better meet your needs and making deployment decisions in your best interest. In our report titled “Privileged Access Management: More Necessary Than Ever as Cloud-Shift Intensifies”, we reviewed many of these vendors, who include:

• CyberArk
• BeyondTrust
• Microsoft
• MicroFocus
• Okta
• One Identity
• Saviynt
• Thycotic
• Centrify
• Google
• Amazon

These are all PAM “short list” vendors worth of considering, but for the purposes of illustrating this mapping process we’ll look at a single leading vendor, CyberArk, and map this vendor’s capabilities to our PAM Reference Architecture pattern (previously shown in Figure 4). This is where the rubber meets the road – and it becomes more evident how you will be able to deploy a chosen vendor’s PAM solution to match your ‘what good looks like’ pattern.

We’ll now look at CyberArk – perhaps the leading PAM vendor (at least by market share) and see how their offering maps to our pattern. CyberArk provides centralized, tamper-proof audit records for all privileged access activities, with personal accountability for any access or usage of shared privileged accounts.

The CyberArk PAM solution is intended to provide a ‘safe haven’ for the organization where all administrative passwords can be securely archived, transferred and shared by authorized users, such as IT staff, on-call administrators, and local administrators in remote locations. CyberArk encompasses multiple security layers, including firewall, VPN, authentication, access control, encryption, and more. The PAM interface is accessed and managed through a Windows Client, a Web interface, or a variety of APIs.

The CyberArk solution architecture consists of two major elements. One is the Storage Engine (also referred to as “the Vault”), that holds the data and is responsible for securing the data at rest and ensuring authenticated and controlled access.

The second element is the interface (Windows interfaces, Web interfaces, and SDKs) that communicates with the Vault on one hand and provides access to users and applications on the other. The Vault and the interface communicate using CyberArk’s secure protocol – the Vault protocol. The Vault is used on all CyberArk solutions, and has been designed to discover, secure, rotate, and control access to privileged account passwords used for accessing systems throughout the organization. At a high-level, the components that comprise the CyberArk PAM solution are as follows:

1. The Vault – secure repository that holds the data and is responsible for securing the data at rest and ensuring authenticated and controlled access.
2. The Password Vault Web Access Interface – a fully featured web interface that provides a single console for requesting, accessing and managing privileged passwords throughout the enterprise by both end users and administrators.
3. PrivateArk Administrative Interfaces – a regular Windows application that is used as the administrative client for the CyberArk PAM solution.  It can be installed on any number of remote computers and can access the Vault by any combination of LAN, WAN or the Internet.
4. The Central Policy Manager – automatically enforces enterprise policy and can change passwords automatically on remote machines and store the new passwords in the Vault, with no human intervention, according to the organizational policy. It also enables organizations to verify passwords on remote machines and reconcile them when necessary.
5. Privileged Session Manager – enables organizations to secure, control and monitor privileged access to network devices. Using Vaulting technology, it manages access to privileged accounts at a centralized point and facilitates a control point to initiate privileged sessions. This component enforces policies that specify which users are entitled to access privileged accounts, when, and for what purpose. In addition, it controls which connection protocols a user can access, enabling organizations to filter restricted protocols. It can also provide secure remote access to sensitive network resources by third party vendors, without disclosing sensitive passwords or keys, and while recording the entire session. All of this can be done either through HTTPS protocol, without the need to open the enterprise firewall to native protocols such as SSH and RDP, or by using standard RDP clients which allows the user to connect directly from their desktop to the target machine. This component can also restrict unauthorized commands if they are executed by a privileged user on a network device or any SSH-based target system.
6. Privileged Session Manager for SSH – same as above including administrator access using the SSH (Secure Shell) protocol.
7. Privileged Session Manager for Web – provides proxy-based session isolation for secure access for SaaS/IaaS/PaaS administrators and privileged business users. Key features of this component also include enabling native access to cloud applications and transparent user experience, providing a risk-based approach to monitoring user activities within cloud applications.
8. On-Demand Privileges Manager (ODPM) – enables organizations to secure, control and monitor privileged access to UNIX commands by using Vaulting technology to allow end users to perform super-user tasks with their own personal account, while maintaining the least-privilege concept.
9. Privileged Threat Analytics (PTA) – continuously monitors the use of privileged accounts that are managed in the CyberArk platform, as well as accounts that are not yet managed by CyberArk, and looks for indications of abuse or misuse of the CyberArk platform. It also looks for attackers who compromise privileged accounts by running sophisticated attacks, such as Golden Ticket.
10. The Password Upload Utility – uploads multiple password objects to the Vault.
11. SDK Interfaces – eliminates the need to store application passwords embedded in applications, scripts or configuration files, and allows these highly sensitive passwords to be centrally stored, logged and managed within the Vault. The Application Password SDK provides a variety of APIs, including Java, .Net, COM, CLI and C/C++.
12. Administrative APIs – CyberArk Vault’s Command Line Interface (PACLI), enables users to access PAM from any location using automatic scripts, in a command line environment.

With this overview of CyberArk’s capabilities in mind, the design considerations for implementing PAM across the organization must encapsulate CyberArk within the vendor-neutral PAM Reference Architecture pattern established previously. Because the organization, like many other organizations is moving more and more of its IT workload to the cloud – whether SaaS, PaaS or IaaS, the PAM strategy must be increasingly cloud-capable. Given the movement to more dynamic, JIT PAM models, this must be taken into considering as well. The following design recommendations leverages the original, vendor-neutral PAM Pattern and overlays this with the CyberArk Capabilities yielding the following illustrative pattern.

Figure 5: CyberArk Overlaying the Example PAM Reference Architecture Pattern

As can be seen, the CyberArk solution components map cleanly to the future state, vendor-neutral PAM Reference Architecture pattern. This pattern should be the template for expanding CyberArk deployment across the organization, in order to meet the following overarching objectives:

• Zero trust – deployment that follows this pattern will facilitate the zero trust direction that is a fundamental concept within the data protection strategy.
• MFA – this pattern will enable MFA to be deployed across the privileged administrator spectrum, whether target resources are on-premise or in the cloud.
• JIT PAM – this pattern provides the necessary fundamental infrastructure for enabling Just-In-Time PAM across cloud, hybrid and on-premise infrastructure – further supporting zero trust principles.
• Persona based IAM governance – by deploying JIT PAM, the organization can provide more flexible-yet-secure administrator privileges based on its own IAM policies and processes.
• Provisioning administrative rights – the recommended pattern improves consistency in handling PAM and administrative accounts through a customizable delegated administrative interface.

You and your team can do this type of vendor solution-to-reference architecture mapping using any PAM solution and leverage TechVision Research as appropriate, to support this process. In fact, your RFP and/or RFI instructions should demand that responding PAM vendors do this initial mapping for you as a means of evaluating their solutions. Then, when a vendor makes a presentation to your stakeholders, this level of thinking has already been addressed by both you and the vendor, making the entire solution selection process much cleaner and easier.

Begin Deployment and Measure Progress

You can see that there is a logical progression of steps necessary to implement PAM properly. Now that the Reference Architecture pattern(s) have been identified, the IAM-related capabilities necessary to support the patterns have been identified (and where deficient- being addressed), and a vendor solution has been identified and procured, your team may now begin deployment. There are far too many horror stories that tell of teams that ‘picked a vendor and deployed’ in the absence of this pre-work. In these sad tales, the PAM solution deployment typically becomes almost completely vendor-driven, based on what the vendor or Systems Integrator feels they can do easiest and most profitably. Careers have been derailed by not doing this pre-work.

Your own organization’s deployment roadmap will depend on a number of factors specific to you:

• Business and functional requirements
• Risk levels germane to important information assets
• The existence and maturity of IAM capabilities that will need to support PAM

While there may be finer-grained inputs driving the deployment roadmap, these 3 factors will lead the way. Using your vendor-solution mapped pattern (i.e., Figure 5) as a visual cue, you can more readily decide which PAM solution module to deploy where and for what purpose.

Summary

We hope you have found this report useful. TechVision Research feels that PAM is one of the more critical elements of an enterprise security posture and is becoming increasingly important. Hackers and thieves focus on privileged account access rights because that is the way to your data – whether in your data center or in the cloud. No matter how far along you are (or aren’t) in PAM deployment, don’t delay developing a Reference Architecture for PAM, which includes documented business and technical requirements, a comprehensive, defensible set of patterns mapped to existing and required capabilities and vendor solution capabilities. With these elements all addressed, you will be able to select the appropriate vendor and deploy the solution to fit your IAM environment and address specific information security risks.

About TechVision

World-class research requires world-class consulting analysts, and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include: Identity and Access Management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, AI, new IT/business models and organizational strategies.

Prior to starting TechVision Research, he was President of Burton Group from 1999 to 2010, the leading technology infrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President (now Gartner for Technical Professionals) at Gartner.

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM. Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.