The history of passwords dates back to the Roman military. Initially, they were carved into wood and soldiers passed them around via the active guard on duty. They were a shared resource. Today, the most common storage medium of a password is the human brain. We assign a password to a system or application, recall it when it needs to be used, and remember it each time we change it. Our brains are full of passwords and, often, we forget them, need to share them, and are forced to document them on Post-it notes and spreadsheets, and even communicate them via email or text message (a very poor security practice in itself). These insecure methods for sharing passwords have caused the press to report front page news articles on data breaches and compelled organizations to educate employees on the insecure methods for password storage and sharing. Humans should not be expected to verbally or typographically share a password, nor is it safe to communicate them using traditional business collaboration tools. Therefore, a better method to document passwords is needed that is highly secure, documents distributed access, and promotes sharing and collaboration with minimal risk—no matter where the access occurs, and from virtually any medium. The cloud is ideal for this situation when passwords need to be available outside of the organization, across multiple geographical locations, for small- to medium-sized businesses, and when on-premise technology is incapable or cost-prohibitive for meeting business objectives. Ergo, if the Romans had the cloud, Jupiter would have just updated everyone with the proper passwords and not left it to humans to scribe them on wood and accept the risk of physically passing them around.
Cloud Service Models and the Technology Available to Each One
Mobile Workforce: The ability for remote team members to access current passwords, obtain policies, modify rules, and securely connect to remote resources.
Distributed or Outsourced Information Technology Support: The ability for outsourced, contracted, or remote information technology team members to access credentials and initiate secure remote sessions for resources they are responsible for, using context-aware methodologies.
Information Technology Collaboration: Team members often need to share credentials (due to resource limitations) for assets and applications to perform a task or maintenance. A central repository for password storage allows collaboration without the risks of rogue password storage on documents.
Break Glass: The technology-independent storage of passwords for key systems and applications in case of a crisis or break glass incident.
Cloud Models: The organization has embarked on a cloud strategy and needs to secure the credentials for cloud resources. This includes everything from third-party SaaS applications to social media and cloud-based hypervisors.
With all of this in mind, there is a truth about XaaS (X referring to any type of cloud as a service offering) solutions that twists the definition of cloud-based technology. Is the solution being offered by the vendor a lift and shift of their traditional software solution offered in the cloud (normally a PaaS solution) or is it truly cloud-native (IaaS or SaaS), built from the ground up, to be optimized as a cloud solution? Now the twist. Do you actually care? If the price is right, the uptime is measurable against a service level agreement, and if the solution is secure, why do you care? Does it really matter if the solution is cloud-native and multitenant, or a reengineered version to work in the cloud as a single tenant? The answer is—it does matter, but not for the reasons you may be thinking. Moreover, being cloud-native may not be the right choice for your business after all despite all the marketing around multitenant PAM-based cloud solutions.
To understand the problem, let’s establish a few definitions. The first is single tenant vs. multitenant. A single-tenant solution is the installation of an application that does not share backend or database resources with another operating instance. That is, the runtime and data are dedicated to a single company, department, or organization and a role-based access model is used to control permissions and isolate datasets. A multitenant solution shares common resources, including potentially a backend database, to provide a logical separation of data and permissions to isolate information, configurations, and runtime from other groups of users. It provides a method to scale the solution efficiently and, if properly implemented, prevents improper data bleed from one tenant to another while consuming shared resources. Traditional on-premise technologies are generally thought of as single-tenant solutions, while cloud-based solutions are generally thought of as multitenant solutions. That is not always true and, in many cases, not always good for your business. Here is why.
Change Control: A multitenant XaaS vendor controls when your version is upgraded and patched. They will provide a maintenance window for the upgrade and you will be forced to accept the changes—even if it is not in a desirable timeframe for your business. If the upgrade introduces an undesirable change (bug or incompatibility), there is no way to roll back the changes since multiple organizations (businesses) are sharing the same multitenant shared resources.
Security: With any multitenant solution, there is always a risk of data bleed with another organization or a vulnerability affecting one organization being used to expose data from another. This can even be true with a simple backend misconfiguration, or an insecure third-party add-on that risks the security of the multitenant model. In essence, this is out of your control.
Customization: Outside of a few multitenant XaaS vendors that have designed customization directly into their platform, most multitenant solutions do not allow extensive customization to meet individual business requirements due to the number of shared resources they consume. While this may also be perceived as an advantage to avoid customized obsolesce, it can also cause distribution and unnecessary rework when APIs or features become deprecated as the service releases newer versions.
Change Control: In a single-tenant XaaS model, the end user can decide when to upgrade to a new version as well as whether they want to skip a version. The risk is waiting too long to upgrade and potentially operating with an end-of-support or end-of-life version. An XaaS-based single-tenant version needs to be managed within your current change control procedures and policy. This requires effort not normally associated with an XaaS solution—even if the upgrade is fully automated.
Security: Your XaaS-based single tenant is your own. Any misconfigurations or missing security patches that need to be manually authorized can introduce unnecessary risk. Even though it is an XaaS-based solution, you still have the change control responsibilities of patching and maintenance, just like full versions, even though the vendor will fully automate their installation. Again, while this is probably fully automated, the organization will need to maintain this just like any other application for patch management. Since the solution is a single tenant, there is a very low risk of data bleed unless the hosting company is compromised.
Customization: A single-tenant XaaS solution allows for the most possible customization since any changes will not affect any other tenants or organizations. However, there is a risk since compatibility with future versions might break when the version is upgraded. Luckily, since you can control the version, you may test customization before any upgrade and stay on an older version until you are ready.
So, what else is different between a single tenant and multitenant XaaS solution? If the cost to the end user is acceptable regardless of model, multitenant vs. single tenant is really just a trade-off between change control and acceptable security risk. If you always want to be on the latest version, either model is acceptable. You just have to manage the change control yourself. If you want to customize the XaaS solution, then it becomes the capabilities of the XaaS vendor that should be evaluated and not the tenancy model—and, finally, its security. All XaaS solutions should allow automatic security patching, but the difference defers back to your change control requirements. It is truly up to you to decide if change control, security, and customization are that important when choosing an XaaS solution for privileged access management.
Cloud Models
Growing use of cloud environments for processing, storage, and application hosting and development has opened new avenues for hackers and malicious insiders to access sensitive data and disrupt organizations. As cloud adoption continues to accelerate, organizations must secure access to these environments to mitigate security risks, while meeting the cost and efficiency demands of hosting more applications and services in the cloud.
Cloud-to-cloud, application-to-application, or cloud-to-application for privileged management using an API primarily for implementation (IaaS). This is generally performed with a secret safe or a full password manager in the cloud.
Cloud-based privileged management, asset-based least privilege management, and secure remote access for users (SaaS) and applications. This can be deployed as a single tenant or multitenant depending on the vendor.
Cloud-based platform as a service to deploy your own solution based on an existing technology using your own virtual machines, or one provided in a cloud provider’s marketplace for your private cloud instance (PaaS).
Privileged access management for any resources by using any method in conjunction with an on-premise deployment (hybrid).
If this was a multiple-choice question, your strategic business initiatives might require more than one of these categories, thus a hybrid deployment. It is highly uncommon for privileged access management to be used in only one silo of the business without plans to expand the technology to all sensitive systems and privileged accounts. While initial deployments may start small, the cloud is also used for management everywhere. This is critical when selecting PAM on-premise, in the cloud, or a hybrid approach. Hybrid approaches can be a combination of IaaS, SaaS, PaaS, or on-premise, or a combination using remote management nodes to route and aggregate data securely.
Infrastructure as a Service (IaaS)
With regard to PAM, infrastructure as a service (IaaS) refers to the delivery of computing capacity for PAM use cases. In this model, another company operates the data center infrastructure and privileged access management is programmatically available via an API to integrate into other resources. For PAM to succeed as an IaaS solution, it needs to provide its own permissions model to provide delegated access to accounts and applications programmatically. These permissions are typically banded together in built-in or custom-defined roles that provide the required access. They can also be integrated into a cloud-based directory store or identity governance solution for centralized management. Given the power and possible business impact should these accounts be compromised, proper security and control of these permissions is paramount and must be included within the scope of an organization’s multilayered security program. This includes the privileged access layer by rotating any keys or passwords used programmatically to secure them in the first place.
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 container technology to store secrets in the cloud as an infrastructure component—essentially an API secret safe. This allows for a hardened PAM deployment catered specifically for cloud usage and using cost models that take advantage of cloud environments. This approach is typically used for SecDevOps and DevOps when implemented within the cloud. In addition, some PAM vendors also offer solutions that can be instantiated as a virtual machine based on a cloud operating system template. These provide the most flexibility for a client and are hardened and patched by the PAM vendor too. The risks are lower for these types of implementations, but may have a higher runtime cost if the infrastructure requires the virtual machine to be operating all of the time.
Software as a Service (SaaS)
Software as a service (SaaS) is a delivery model where a service is centrally hosted by the provider and licensed to customers on a subscription basis. Organizations and end users typically interact with these services via a web console or programming APIs. This allows you to consume a small part of an application without the cost and complexity of building servers and maintaining application software. Examples of corporate SaaS solutions include Salesforce, Workday, Concur, ServiceNow, Office 365, and even LinkedIn. In a SaaS model, an organization’s core security responsibility is the application itself. This includes who can access the application, what authentication is required, and what access users should have. Each application may have its own access model with varying levels of granular provisioning available based on the vendor. Some SaaS applications have traditional business services and may have fine-grained permission models to provide flexibility and permissions to specific groups of users based on tasks or use cases. These applications may also have built-in governance features, such as separation of duties and fine-grained auditing to enable organizations to control and audit access to sensitive features and data. Other SaaS applications that have been traditionally consumer-focused, such as Facebook or Twitter, have minimal granularity in their permissioning models. In some cases, users share a common corporate account to manage the system on behalf of the company. While these SaaS applications may not have the same level of sensitive information, such as customer lists or financial data, these accounts do represent a significant risk to an organization. Issues could include inconvenience; for example, if the sole administrative user is on leave, updates would come to a grinding halt. Another issue could be a disruptive one, such as if a hacker uses a compromised account to post or tweet inappropriate material that could impact the company’s reputation. In either case, proper management and control over these accounts should be considered when designing an overall security program. And, it is important to note that based on previous discussions, these SaaS applications can be single tenant, multitenant, or some hybrid implementation to overcome the business challenges and costs of hosting a cloud solution.
With this in mind, SaaS-based PAM solutions not only need to manage the privileged access to your cloud resources, but potentially manage your PAM requirements on-premise as well. PAM solutions deployed as a SaaS solution can operate solely in the cloud or require on-premise management nodes to route and aggregate policy and events and manage remote access sessions. These implementations are completely managed by the PAM vendor, hosted in the provider’s cloud environment, and may operate using shared cloud resources with other companies. Only the business can determine whether or not the risks inherent with this shared model are acceptable, and whether or not the provider has implemented adequate controls to secure your privileged data from any potential leak or breach.
- 1.
Secure agent-based technologies deployed on virtual machines or remote assets (laptops or other mobile user devices) running within the cloud or remotely connected to the Internet to meet PAM requirements.
- 2.
Secure communications with on-premise management nodes to communicate with the cloud for remote sessions, password management, and managed least privilege endpoints.
- 3.
Localized data obfuscation, filtering, or purging to maintain regulatory compliance.
- 4.
Complete role- and attribute-based access for all data, reporting, and auditing.
Platform as a Service (PaaS)
Privileged access management, when delivered as a platform as a service (PaaS) , provides an added level of abstraction to existing on-premise solutions. These cloud services provide a platform allowing customers to develop, run, and manage privileges based on technology they may already be familiar with on-premise. Examples of PaaS vendors that have shifted to on-premise solutions that are similar to their on-premise solutions include Oracle and Microsoft. In fairness, some may argue that PaaS does not strictly imply a lift and shift of on-premise technology to the cloud. For the sake of this conversation, I would loosely agree, but operating systems like Microsoft Windows, Red Hat Linux, and even your favorite database in the cloud originated from an on-premise solution and share similar capabilities. If they were built natively in the cloud and have no on-premise equivalent, I would argue it is a SaaS solution and not a PaaS. This is a semantic discussion worthy of a late night, beer, and a deeper discussion of whether the Death Star was a platform to destroy planets, or a space station as claimed by Tarkin. Regardless, PaaS-based PAM solutions are typically used to provide privileged management to an organization’s critical applications and services and are rarely different (outside of cost) than moving your on-premise implementation of PAM into the cloud.