Privileged Access Workstations

One of the most common methods for protecting the cloud is to secure all administrative access to the cloud computing environments used for management. Typical workstations used by individuals with privileged credentials are appealing targets for threat actors. This is because those credentials can be stolen and then used for attacks and subsequent lateral movement. Since these are real credentials, the attack is much harder to detect. Therefore, the best practice for protecting administration of the cloud is to provide a dedicated asset (physical or virtual machine) exclusively for privileged access to the cloud. Such an asset is called a Privileged Access Workstation (PAW).

In a typical environment, an identity (user) is provided a dedicated PAW for cloud administration and unique credentials and/or secrets to perform tasks linked to the asset and user. If access using those secrets is attempted from non-PAW resources or on another PAW, it can be an indicator of compromise.

Operationally, when logging into their PAWs, users still should not have direct access to the cloud. A privileged access management solution should broker the session, monitor activity, and inject managed credentials (to obfuscate them from the user) to enable them to perform their mission securely. When this is set up correctly, all these steps are completely transparent to the end user and only take a few seconds to complete automatically. This approach is a security best practice. Therefore, solutions that provide privileged access management are crucial to managing privileged access through PAWs, especially when connecting to the cloud.

To streamline this approach and avoid using two physical computers, many organizations leverage virtualization technologies (from VMware, Microsoft, Parallels, Oracle, etc.) that allow a single asset to execute a PAW side by side with the base operating system. The primary system is used for daily productivity tasks, and the other serves as the PAW. However, when using this approach, it is preferred that both daily activity and the PAW be virtualized on a hardened OS to provide better segmentation, but this may not always be practical. The PAW, if nothing else, should be virtualized and isolated from the OS (no clipboard sharing, file transfer, etc.) and not the daily productivity machine.

Access Control Lists

An access control list (ACL) is a security mechanism used to define who or what has access to your assets, buckets, network, storage, etc., and the permissions model for the object. An ACL consists of one or more entries that explicitly allow or deny access based on an account, role, or service in the cloud. An entry gives a specified entity the ability to perform specific actions.

The end results are a list of ACLs that restrict access on a “need to know” basis for the data contained in the storage bucket. While this example is simplistic for an enterprise cloud-based application, it forms the basis for our ACL discussion and protecting assets in the cloud.

Consider the n-tier web-based cloud architecture in Figure 7-1.

A model diagram of the structure of the n-tier web-based cloud. The parts are Name Resolution, Application Gateway Subnet, Management Subnet, Web Tier Subnet, Business Tier Subnet, Data Tier Subnet, Active Directory Subnet, and the Storage Account.

With these in mind, all network traffic should always follow a predictable route, and any inappropriate activity should be monitored via alerts, logs, and events for potential indicators of compromise. That is, if any asset is compromised, a threat actor will typically attempt to deviate from the established architecture and acceptable network traffic to compromise the cloud environment. This is almost always true except for flaws in the web application itself that might disclose or leak data due to a poorly developed application. This has been covered in the “Web Services” section of Chapter 6.

Access control lists are your first and best security tool for restricting access in the cloud when access and network traffic should always follow a predefined route and originate only from specific sources. If you consider the cloud has no true perimeter, only certain TCP/IP addresses are exposed to the Internet, and traditional network architectures are virtualized, ACLs help maintain these conceptual boundaries and allow complex architectures far beyond what was ever possible on-premise.

Hardening

Harden, harden, harden your assets. If we are not clear on this recommendation, harden, harden, harden everything in your cloud environment and everything that is connected and performs administration. (Batman learned this when fighting Superman.) While this may seem like the most basic recommendation, improper hardening accounts for some of the most basic attack vectors in the cloud.

First, let’s have a quick refresher on hardening. As covered in Chapter 6, asset hardening refers to the process of reducing weaknesses in your security devices by changing custom and default settings and using tools to provide a stricter security posture. It is a necessary step that must be taken even before assets are placed live on a network and ready for production in the cloud. This eliminates potential runtime issues with hardening and loopholes that can be exploited by threat actors based on services, features, or default configurations present in an operating system, application, or asset.

Next, what does good cloud hardening entail? It is not the same as the controls used for traditional on-premise servers and workstations, since environmental conditions are different. Hardening for virtual machines does mirror on-premise counterparts, but hardening of containers, serverless environments, and virtual infrastructures has different characteristics due to the cloud service provider’s actual implementation of technology and lack of end-user physical access, like USB ports and drive bays.

While these represent some of the best third-party hardening recommendations, it is extremely important to note that almost all of the cloud service providers also provide hardening guidelines for their own technology stacks. These guidelines will specify what settings to change, native tools to use, and auditing capabilities to apply for their unique features, per solution.

As an empirical practice, hardening of cloud assets is a collection of tools, techniques, and best practices to reduce weaknesses in technology applications, systems, infrastructure, hypervisor, and other areas that are cloud service provider independent. The goal of asset hardening is to reduce security risk by eliminating potential attack vectors and condensing the system’s attack surface. By removing superfluous programs, accounts functions, applications, open ports, permissions, access, etc., threat actors and malware have fewer opportunities to gain a foothold within your cloud environment.

Asset hardening demands a methodical approach to audit, identify, close, and control potential security weaknesses throughout your cloud deployment. There are several types of asset hardening activities in the cloud. Consider this word map in Figure 7-2. We have chosen a word cloud for this illustration because it helps emphasize the differences between on-premise and the cloud. Depending on your cloud implementation, this may help you decide on your hardening priorities (especially when you add risk as the variable that chooses a word’s color and size) and help communicate them with team members. One side note: Never underestimate the power of a word cloud when trying to convince teams of your priorities or the importance of a topic. It is a legitimate tool to explain relevance or statistics based on the topic.

An image reads Database, Container, Machine, Operating, Server, Virtual, System, and, Serverless, Application, Network, Hypervisor.

Although the principles of asset hardening are universal, specific tools and techniques do vary depending on the type of hardening you carry out. Asset hardening is needed throughout the technology life cycle, from initial installation through configuration, maintenance, and support to final assessment at end-of-life decommissioning. Systems hardening is also a requirement of compliance initiates, such as PCI DSS, HIPAA, and many others.

Finally, with any attack vector mitigation, test, test, and test your hardening. It is not uncommon for hardening to break an application or disable a service required by a web application in the cloud. It is a bad idea to harden the environment only after it enters production. Hardening should be tested throughout development and quality assurance to verify any exceptions and to document the risk of not hardening them. This is not only a good security practice, but many regulatory bodies also require it.

Vulnerability Management

Like everything else we have been discussing, vulnerability management is a security best practice across any environment, but there are key differences and implications to understand when it is being applied in the cloud. This is mainly due to the methods used for a vulnerability assessment. If you are looking for a good definition for vulnerability management and vulnerability assessment, and the security best practices for each, please reference Asset Attack Vectors¹ by Haber and Hibbert (2018).

As we have stated, vulnerability management in the cloud is the same as on-premise. The goal is to find the risks, but the techniques for an assessment may be different. Another difference is in MTTR (Mean Time to Repair) or, in this case, Mean Time to Remediate. Since the risk surface is larger in the cloud, especially for Internet-facing assets, high and critically rated vulnerabilities should have a tighter SLA (service-level agreement) for remediation using patch and verification methods.

Finally, as discussed throughout this book, vulnerability and patch management should be your highest priority in the cloud, along with credential and secrets management, to mitigate and remediate cloud attack vectors.

Penetration Testing

While penetration testing (pen testing for short) may not sound like a cloud attack vector mitigation strategy, it plays a crucial role in the security of your cloud applications. By definition, penetration testing is an authorized simulation of a cyberattack on a computer system, cloud assets, or other technology performed to evaluate the overall security of the system and its ability to thwart attacks. Penetration testing should never be confused with a vulnerability assessment since, in lieu of using signatures to detect a vulnerability, penetration testing uses active exploit code to prove that a vulnerability can be leveraged (exploited) in an attack. The process is performed to identify exploitable vulnerabilities, including the potential for unauthorized parties to gain access to the system’s features, data, runtime, configuration, and, potentially, lateral movement into assets that are more critical to the organization.

Penetration tests themselves can be conducted live, in production assets, or in a lab to test the system’s resiliency. Security issues that the penetration test discovers should be remediated before a production deployment or in accordance with the service-level agreements based on the criticality of the original vulnerability leveraged.

Individuals who conduct penetration testing are classified as ethical hackers or white hats and help determine the risk of a system before a threat actor (black hat) actually finds the weakness first and exploits it.

Penetration testing your cloud systems, applications, and cloud service providers is a critical component of your cloud attack vector protection strategy. The results will help your organization determine how a threat actor may breach your organization and the ability of your assets to notify and thwart a potential attack. The logged results can serve as indicators of compromise for real-world future attacks and symptoms for other related security issues.

Never forget that penetration testing is one of the most valuable tools in your arsenal for proving, in the real world, that your cloud environment has been properly (with reasonable confidence) implemented to safeguard your business, data, and applications.

Patch Management

One commonality between the cloud and on-premises technology is patch management. While there are literally dozens of ways of applying patches to cloud resources – from templates to instances and agents – the simple fact is that vulnerabilities will always be identified, and the best way to remediate them is to apply a security patch via patch management. Patch management solutions are designed to apply security updates and solution patches, regardless of asset type. If it is software, it should be able to be patched. Some solutions provide automatic updates natively, while others require a third-party solution for features and coverage.

In the end, patch management in the cloud is the same as patch management on-premise. You must apply patches in a timely fashion and with potentially a high urgency due to the risk surface. The difference in deploying a patch is different due to the lack of patch management agent technology and DevOps pipelines. This means you may not patch in production but release a new or patched version as a part of your DevOps pipeline. Both should be well understood and a part of your strategic plan to remediate the threats from cloud attack vectors. Also, remember to monitor and measure your patch management approach to look for improvements and to optimize how quickly your organization can close a security gap. As stated earlier, good asset management can help to ensure that coverage is truly complete.

IPv6 vs. IPv4

Internet protocol (IP) is a standardized protocol that allows resources to find and connect to each other over a network. IPv4 (version 4) was originally designed in the early 1980s, before the growth and expansion of the Internet that we know today. Note: there is a long history for IPv4 development that is worth reading if you are interested in its original roots in military communications.

Outside of the limited number of publicly addressable resources available to IPv4, which can be solved in many cases using NAT (Network Address Translation) in the cloud and on-premise, the extended range of addresses improves scalability and also introduces additional security by making host scanning and identification more challenging for threat actors.

To start, IPv6 can run end-to-end encryption natively. While this technology was retrofitted onto IPv4, it remains a discretionary feature and is not always properly implemented. The most common use case for IPv4 encryption and integrity checking is currently used in virtual private networks (VPN) and is now a standard component of IPv6. This makes it available for all connections and supported by all modern, compatible resources. As a simple benefit, IPv6 makes it more challenging to conduct man-in-the-middle attacks, regardless of where it is deployed since encryption is built in virtually, eliminating an entire class of attacks.

IPv6 also provides superior security for name resolution, unlike the DNS attack vector discussion we had earlier. The Secure Neighbor Discovery (SEND) protocol can enable cryptographic confirmation that a host is who it claims to be at the time of connection. This renders Address Resolution Protocol (ARP) poisoning and other naming-based attacks nearly moot and, if nothing else, much more difficult for a threat actor to conduct. In contrast, IPv4 can be manipulated by a threat actor to redirect traffic between two hosts where they can tamper with the packets or at least sniff the communications. IPv6 makes it very difficult for this type of attack to succeed.

Put simply, IPv6 security, when properly implemented, is far more secure than IPv4 and should be your primary protocol when architecting solutions in the cloud, as well as for hybrid implementations. The biggest drawback here is making sure all your assets, including security solutions like firewalls, can communicate correctly using IPv6. Threats targeting hybrid environments that include IPv4 and IPv6 plumbed together do represent a significant risk for an organization. A pure implementation is best, and it is not without its own tools and does have an administrative learning curve.

Privileged Access Management (PAM)

Finally, it’s time to have a detailed discussion about privileged access management (PAM). Protecting an asset in the cloud entails far more than security patches, proper configurations, and hardening. Consider the damage a single, compromised privileged account could inflict upon your organization from both a monetary perspective and a reputation perspective; Equifax,² Duke Energy³ (based on a third-party software vendor), Yahoo,⁴ and Oldsmar Water Treatment,⁵ to name just a few, were each severely impacted by breaches that involved the exploitation of inadequately controlled privileged access. The impacts ranged from hits to company stock prices and executive bonuses, to the changing of acquisition terms, to even hindering the ability to do basic business, like accepting payments.

A compromised privileged password does have a monetary value on the dark web for a threat actor to purchase, but it also has a price that can be associated with an organization in terms of risk. What is the value and risk if that password is compromised and its protected contents exposed to the wild? Such an incident can have a significant, negative influence on the overall risk score for the asset and company.

A database of personally identifiable information (PII) is quite valuable, and blueprints or trade secrets have even a higher value if they are sold to the right buyer (or government). My point is simple: privileged accounts have a value (some have immense value), and the challenge is not just about securing them but also about identifying where they exist in the first place. Our asset management discussion highlighted this in detail. If you can discover where privileged accounts exist, you can measure their risk and then monitor them for appropriate usage. Any inappropriate access can be highlighted, using log management or a SIEM, and properly escalated for investigation, if warranted. This is an integral part of the process and procedures we have been discussing.

Some privileged accounts are worth much more than others, based on the risk they represent and the value of the data they can access. A domain administrator account is of higher value than a local administrator account with a unique password (although that may be good enough to leverage for future lateral movement). The domain administrator account gives a threat actor access to everything, everywhere, in contrast to a unique administrative account that only provides access to a single asset.

Treating every privileged account the same is not a good security practice. You could make the same argument for a database administrative account vs. a restricted account used with ODBC for database reporting. While both accounts are privileged, owning the database is much more valuable than just extracting the data.

In the real world, a database with sensitive information may have critical vulnerabilities from time to time, specifically in-between patch cycles. This should, however, be as minimal time as possible. The asset may still present a high risk when patch remediation occurs, if the privileged account used for patching is unmanaged. This risk can only be mitigated if the privileges and sessions are monitored and controlled. Criticality can be determined either by the vulnerabilities or the presence of unrestricted, unmanaged, and undelegated privileged access. Therefore, inadequately managed privileged accounts, especially unprotected ones, ones with stale, guessable, or reused passwords, or even default passwords, are just unacceptable in your cloud environments. Thus, implementing and maturing privileged access management plays a foundational role in not only mitigating cloud attack vectors but also unlocking the potential of the cloud.

Vendor Privileged Access Management (VPAM)

One of the most interesting things about information technology is that there are rarely truly original ideas that are game changers for cybersecurity. Often, the next best thing follows the same security best practices we have been engaging with for years, and the new, hot solution is built upon prior art. In fact, one could argue that most modern cybersecurity solutions are simply derivations of previous solutions with incremental improvements in detection, runtime, installation, usage, etc., to solve the same problems that have plagued organizations for years. While some may have innovative approaches that are even patentable, in the end, they are doing the same thing. This is true for antivirus, vulnerability management, intrusion detection, log monitoring, etc.

Vendor privileged access management allows for third-party identities/vendors to successfully access your assets remotely using the concepts of least privilege and without the need to ever know the credentials needed for connectivity. In fact, the credentials needed for access are ephemeral, potentially instantiated just in time, and all access is monitored for appropriate behavior.

What makes VPAM different from any other solution is how it is built upon existing technology. It takes vendors’ identity (including identities managed externally) and successfully merges the best practices for secure remote access, privileged access management, and zero trust into a single solution. VPAM leverages the best attributes of the cloud to provide the control plane for privileged remote access, and it allows the implementation to occur in the data plane, wherever the organization has assets that need vendor remote access or management. Figure 7-3 illustrates this using a standard reference architecture.

A model diagram of the Vendor Privileged Access Management uses the cloud to provide the control plane for authorized remote access. It permits deployment in the data plane, where the organization needs remote access or administration.

When you consider modernizing your vendor remote access as the work-from-anywhere (WFA) movement continues, consider VPAM. It is one new solution category that takes the best of breed from many existing solutions and unifies them to solve significant challenges of vendor remote access – especially with regard to privileges. In fact, when using VPAM, entities do not need to bolt together multiple solution providers to achieve the desired results. VPAM vendors can provide vendor privileged remote access out of the box based on a SaaS solution (control plane) and can provide a rapid time for deployment (data plane). And, as a Sci-fi reminder, the prefix code for the USS Reliant (NCC-1864) was simply 16309, a five-digit numerical code to take complete remote of a starship. Vendors should never have such simplified administrative access.

VPAM can be used for vendors, contractors, or remote employees who need access to assets on-premise, in the cloud, or located within hybrid environments.

Multi-factor Authentication (MFA)

While we have been focusing on passwords as the primary form of authentication with credentials (single factor), other authentication techniques are needed to secure the cloud properly. As a security best practice and required by many regulatory authorities, multi-factor authentication (MFA) techniques are the standard to secure access. MFA provides an additional layer (beyond username + password combinations) that makes it more challenging to compromise an identity. Thus, MFA is always recommended when securing sensitive assets.

The premise for MFA (two-factor is a subset category for authentication) is simple. In addition to a traditional username and password credential, a “passcode” or other evidence is needed to validate the user. This is more than just a PIN code; it is best implemented when you have something physical to reference or provide as “proof” for your identity. The delivery and randomization of “proof” varies from technology to technology and from vendor to vendor. This proof typically takes on the form of knowledge (something the user knows that is unique to them), possession (something they physically have that’s unique to them), and inherence (something they have in a given state).

The use of multiple authentication factors provides important additional protection around an identity. An unauthorized threat actor is far less likely to supply all the factors required for correct access when MFA is in place. During a session, if at least one of the components is in error, the user’s identity is not verified with sufficient confidence (two of three criteria match); in that case, access to the asset being protected by multi-factor authentication is denied.

MFA is an identity-specific layer for authentication. Once validated, the user privileges assigned are no different, unless policies explicitly require multi-factor authentication to obtain step-up privileges. For example, if credentials are compromised in a traditional username and password model, a threat actor could authenticate against any target that will accept them locally or remotely. For multi-factor, even though there is an additional variable required, including physical presence, once you are validated, lateral navigation is still possible from your initial location (barring any segmentation technology or policy) unless you are validated again (step-up) to perform a specific privileged task, like authenticating to another remote asset. The difference is solely your starting point for authentication.

MFA must have all the security conditions met from an entry point, while traditional credentials do not, unless augmented with other security attributes. A threat actor can leverage credentials within a network to laterally move from asset to asset, while changing credentials as needed. Unless the multi-factor system itself is compromised, or they possess an identity’s complete multi-factor challenge and response, the hacker cannot successfully target a multi-factor host for authentication. Hence, there must always be an initial entry point for starting a multi-factor session. Once a session has been initiated, using credentials is the easiest method for a threat actor to continue a privileged attack and accomplish lateral movement.

The continued use of MFA in the cloud is always recommended for step-up authentication, unless you blend it with additional security layers, like Single Sign On (SSO).

Single Sign On (SSO)

Before we dive into Single Sign On, let’s expand on basic authentication. As we have stated, authentication models for end users can be single factor (1FA), two-factor (2FA), or multi-factor (MFA discussed previously). Single-factor authentication is typically based on a simple username and password combination. (Yes – we know, we have stated this multiple times, but you will not forget this based on our repetition, or when it appears on a test). Two-factor is based on something you have and something you know. This includes, for instance, a username and password from single factor (something you know) and a mobile phone or two-factor key fob (something you have). Multi-factor authentication is one step above and uses additional attributes, like biometrics, to validate an identity for authentication.

The flaw with all these authentication models is the something that you know part, traditionally a password. It can be shared, stolen, hacked, etc., and it is the biggest risk to a business when it is compromised. In fact, to manage a cloud environment, you would probably have to remember dozens of unique passwords or use a password manager. LastPass,⁷ for example, caused a large-scale panic regarding a purportedly massive primary password data breach. Fortunately, the incident turned out not to be true, but it did create fears of similar cloud-based cyberattacks using credentials.⁸

If authentication is for cloud assets, then the implications of an unauthorized identity gaining access could be devastating, especially for clients using this type of service for Internet-facing assets. Therefore, it is important for organizations to mitigate the issue by replacing passwords (something you know) with something you know and that can be changed, but which cannot be shared or as easily hacked as a password.

Next, consider how many passwords you have for work. Most organizations have hundreds of applications, and if you have embraced digital transformation, you now have hundreds or thousands of cloud-based vendors supplying these applications. This potentially means credentials – username (most likely your email address) and a password – for each one. As a security best practice, you should not reuse your password, which means you have potentially hundreds of unique passwords to remember. This is not humanly possible. We previously mentioned password managers and their potential risks, but a better approach is SSO, especially when combined with MFA.

So, what is SSO? Single Sign On is an authentication model that allows a user to authenticate once, to a defined set of assets, without the need to reauthenticate for a specified period of time, as long as they are operating from the same trusted source. When 2FA or MFA is also applied for the validation, there is a high degree of confidence that the identity is who they say they are. When these methods achieve this high confidence, the associated applications in the defined set can be accessed, without the user having to remember unique passwords for each one over and over again. This SSO model negates the need for a password manager.

Now apply this SSO model to the cloud and all your users. Notice I did not say identities, since SSO is typically only used for human authentication, and not machine-to-machine authentication. From a trusted workstation, an end user authenticates once and can use all the applications they need until they log out, reboot, change the IP address or geolocation, etc. If their primary password is compromised, then only that password needs to be changed, and not passwords for the potentially hundreds of applications hosted by SSO. In fact, if Single Sign On is implemented correctly within an organization, the same end user cannot (and should not be able to) log directly into an application without using the SSO solution. The SSO user should not even know the passwords for the applications operating under SSO. That is all managed by the SSO solution itself, regardless of whether it is injecting credentials or using SAML.

Single Sign On enables a single place to authenticate for all business applications and a single place for credential management. With this in mind, please consider these dos and don’ts for your SSO implementation into the cloud:

While Single Sign On sounds like a solution to solve the majority of your authentication problems for users in the cloud, a poor implementation can make it a bigger risk than without it. When done correctly, SSO forms a foundation for centrally monitoring, managing, logging, and even directory service consolidation, for all end-user access. And note, we have only been discussing end-user access. Remember, SSO does not apply to machine-based identities, and organizations should not include administrative accounts in SSO unless additional security controls are in place. If SSO for administration is needed, consider a privileged access management solution with full session recording and behavioral monitoring.

Identity As a Service (IDaaS)

The discussion on MFA and SSO is all dependent on the fact that we have a valid identity and account relationship. On-premise, for many organizations, identity management starts with Microsoft’s Active Directory and is linked with multiple, disparate solutions using identity governance and access (IGA) solutions. In the cloud, the proposition is the same, but just like everything else, it is different enough to have substantive implications.

There is a strong need for identity governance to support cloud-based solutions, but also to be compatible with, or even to replace, on-premise technology. The complexity of having multiple directory services is highly undesirable for any organization. This complexity can create challenges around performing a certification for appropriate access or providing an attestation to prove the scope of access within an organization based on role, application, or even data type is accurate. This is where Identity as a Service (IDaaS) has stepped in. It uses the cloud to solve a fundamental problem in the cloud for identity management and governance.

Managing identities in the cloud is crucial to all remote access, automation, DevOps pipelines, administrative access, maintenance, backups, etc.; any one of these can be abused as an attack vector, as we have been discussing. Therefore, managing identities with a solution in the cloud, one that is made for the cloud, represents the best model and architecture to ensure that the management of identities, and all their associated accounts, does not become an attack vector in itself.

Cloud Infrastructure Entitlement Management (CIEM)

Cloud Infrastructure Entitlement Management (CIEM, but pronounced “Kim” – but not Ensign Harry Kim) is the next generation of solutions for discovering and managing permissions and entitlements, evaluating access, and implementing least privilege in the cloud. The goal of CIEM is to tackle the shortcomings of current identity access management (IAM) solutions, while addressing the need for identity management in cloud-native solutions. While the CIEM concept can be applied to organizations utilizing a single cloud, the primary benefit is to have a standardized approach that extends across multiple cloud and hybrid cloud environments and continuously enforces the principle of least privilege and measures entitlement risk in a uniform manner.

CIEM solutions can address cloud attack vectors by ensuring the principle of least privilege is consistently and rigorously applied across a cloud and multicloud environment. Least privilege in the cloud entails enabling only the necessary privileges, permissions, and entitlements for a user (or machine identity) to perform a specific task. Privileged access should also be ephemeral or finite in nature.

CIEM is a new class of solutions, built entirely in the cloud and for the cloud, allowing organizations to discover, manage, and monitor entitlements in real time and model the behavior of every identity across multiple cloud infrastructures, including hybrid environments. The technology is designed to provide alerts when a risk or inappropriate behavior is identified and to enforce least privilege policies for any cloud infrastructure, with automation to change policies and entitlements. This makes it simple for a solution owner to apply the sample policies across what have traditionally been incompatible cloud resources.

With increasing momentum behind digital transformation strategies, the use of cloud environments has exceeded the basic capabilities of legacy on-premise PAM and IAM solutions. Those solutions were never designed and implemented to manage the cloud nor the dynamic nature of resources in the cloud. CIEM is fast becoming a must-have solution for managing cloud identities, alongside PAM.

Based on capabilities and model, a typical CIEM solution is deployed using the architecture in Figure 7-4.

A model diagram of the typical Cloud Infrastructure Entitlement Management solution structure. The parts are User, Identity Access Management, Cloud Security Posture Management, and different policies under A W S, Azure, and Additional C S Ps, and the business objectives,

The primary reason CIEM succeeds over legacy on-premise solutions is predicated on the API-based connectors, which operate in real time. CIEM continuously assesses the state of identities and entitlements, applies them to a policy engine, and supports automation tailored to identify risks in cloud environments. This then allows a user to see attributes for all cloud providers in a single interface using common terminology (much of which has been previously discussed). On-premise technology generally relies on batch-driven discovery over the network using agents, IP addresses, or asset lists that can be resolved using DNS. API discovery provides nearly perfect results compared to the error-filled results of network scanning.

Customer Identity and Access Management (CIAM)

Customer Identity and Access Management (CIAM) is a subset of the larger identity access management (IAM) market and is focused on managing the identities of customers (outside of business) who need access to corporate websites, cloud portals, and online applications. Instead of managing identities and accounts in every instance of a company’s software application, the identity is managed in a CIAM service, making reuse of the identity possible. The most significant difference between CIAM and business (internal) IAM is that CIAM targets consumers of the service to manage their own accounts, profile data, and what information can, and should, be shared with other organizations.

In many ways, CIAM begins to fulfill the mission of BYOI (bring your own identity), but only for the consumer world. It is only a matter of time, in our opinion, before this will enter the business world in lieu of filing our banking information and details for employment history.

As a solution, CIAM is how companies give their end consumers access to their digital resources, as well as how they govern, collect, analyze, market, and securely store data for consumers that interact with their services. CIAM is a practical implementation that blends security, customer experience, and analytics to aid consumers and businesses alike. CIAM is designed to protect sensitive data from exploitation or exfiltration to comply with regional data privacy laws.

With the earlier definition in mind, embarking on a CIAM journey using a homegrown solution is typically out of reach for most organizations due to the complexity, data privacy, and security requirements for such a vast process. Therefore, many organizations will license CIAM as a Service to meet their business objectives in the cloud.

Ergo (and not Star Lord’s father Ego), a well-implemented CIAM solution can achieve the goal of centralized, data-rich consumer profiles that function as a single source of truth about identities and their behavior for consumption by third parties.

Cloud Security Posture Management (CSPM)

Cloud Security Posture Management (CSPM) is a product and market segment designed to identify cloud configuration anomalies and compliance risks associated with cloud deployments, regardless of type. By design, CSPM solutions are designed to be real time (or as near real time as possible) to continuously monitor cloud infrastructure for risks, threats, and indicators of compromise based on misconfigurations, vulnerabilities, and inappropriate hardening. As discussed, these are three critical areas to manage to mitigate cloud attack vectors. Therefore, the primary goal is to enforce your organization’s policy for risk tolerance for these three security disciplines.

CSPM as a solution category was originally branded by Gartner,⁹ a leading IT research and advisory firm. CSPM solutions are implemented using agent and agentless technology (cloud APIs) to compare a cloud environment against policies and rules for best practices and known security risks. If a threat is identified, some solutions have automation to mitigate the risks automatically, while others focus on alerting and documentation for manual intervention.

While it is considered more advanced to use Robotic Process Automation (RPA) to remediate a potential issue, false positives, denial of service, account lockouts, or other undesirable effects can occur if remediation interferes with the normal workload. This is where risk tolerance becomes an important factor in the decision for notification, automatic remediation, or a hybrid model requiring manual approval before automation.

CSPM tools play an essential role in securing a cloud environment by reducing the potential attack vectors that a threat actor can exploit. It is also important to note that some of these tools can be specific to a cloud service provider and, thus, will not operate across other cloud environments unless the solution provider has explicitly added support. So, for instance, some tools may be limited to being able to detect anomalies in an AWS or Azure cloud, but not in a GCP environment.

As a mitigation strategy for cloud attack vectors, all organizations should consider some form of CSPM solution above and beyond their traditional security tools. This is one place where the best practices have stayed the same, but the tool has evolved to solve the problem.

Cloud Workload Protection Platform (CWPP)

Cloud Workload Protection Platform (CWPP) is another solution category coined by Gartner.¹⁰ It is a workload-centric security solution that focuses on the protection requirements of workloads in the cloud and automation present in modern enterprise cloud and multicloud environments.

As we have discussed in length, cloud workloads have evolved past physical servers and virtual machines to containers and even serverless processes and code. Figure 7-5 helps illustrate the current state compared to the previous state of on-premise data centers with physical services.

A model diagram of the transition of computer resources from on-premise systems to those hosted in the cloud and those without servers. The phases are On-Premise, V M, Containers, and Serverless.

These workloads provide the foundation for operating systems, networks, and storage of the data that deliver applications as part of a larger resource. The more things change, the more they stay the same. Monitoring a single process on-premise using a network management solution, or an application performance solution is the same as monitoring for processes or functions in the cloud for serverless environments. Only the runtime environment has changed as we focus on smaller, more specific tasks that lend themselves as a component to the overall resource. It is important to note that, as we discuss this in the context of the cloud, workloads technically could reside in the cloud, on-premises, or be architected using a hybrid model. Only the cloud portion can be managed with CWPP, unless a particular vendor’s solution can accommodate this diversity in use cases. This requirement is a must have for some organizations, but clearly not for everyone.

For organizations considering moving workloads to the cloud, consider these potential roadblocks that would prevent a migration and have implications for modernizing workload monitoring.

Enterprises typically have one (or multiple) legacy applications and infrastructure that prevent a complete movement of functionality to the cloud due to hardware, software, or other runtime infrastructure requirements – including security.

Shadow IT is not only a challenge on-premise; it can happen in the cloud and can become exaggerated in multicloud environments. Understanding where and how a workload is processed end to end, including shadow IT, is critical for successful monitoring and movement to the cloud. Unfortunately, the old story of a server sitting under someone’s desk still does happen.

Custom applications developed line by line in-house are now the exception. Tools like GitHub have made source code reusable and shareable among teams and the public community at large. Using automation, like DevOps and its cycle of “continuous innovation and continuous development” (CI/CD), has helped make the cloud a rapid vehicle for application development and adoption. Older, non-Agile development methodologies, like Waterfall, do not support these methods and are contrary to best practices for code development and support in a cloud environment. Organizations may need to rethink how they develop and publish code before embracing the cloud for workloads.

Security. Mic drop. Okay, that is a little dramatic, but the security for on-premise solutions that rely on firewalls and access control lists does not translate well to the public cloud. The risk can be contained on-premise, but in the public cloud, the exposure can be to the entire Internet. When considering moving workloads to the cloud and the solutions used for monitoring and maintaining them, do not forget about security. It should be your first thought, not your afterthought. This includes all the traditional security best practices, from vulnerability and patch management through anti-malware and identity management.

A comprehensive CWPP solution should give you the ability to discover workloads that have been deployed, whether they are on-premise, hybrid, public, private, or multicloud environments.

Finally, depending on the resources being monitored, a workload may be persistent, nonpersistent, or ephemeral. While a physical server is typically installed and configured for years, virtual machines may reside in any state from powered off, powered on, or even rolled back via snapshots based on use cases like quality assurance, security, or corruption. VMs can be instance templates, or they can even have a shared base operating system that needs to be managed, and that can affect the runtimes of dozens of other virtual machines.

With the trend to apply protection to shrinking workloads that focus on the process or function, workload management needs to resolve and isolate dependencies that affect monitoring itself and be aware that they exist. As a result, CWPP should not be thought of as another endpoint protection platform or network monitoring solution. CWPP specifically focuses on protecting workloads regardless of type, location, cloud, and mission. Thus, it is another valid cloud-based mitigation strategy.

Cloud-Native Application Protection Platform (CNAPP)

Nearly the last acronym, we promise, and it is an easy one. CNAPP (or CNAP, depending on whom you ask about the final “P”; some definitions drop it from the acronym) is a combination of CSPM and CWPP in a single solution. If you consider the capabilities of CWPP and CSPM and their overlapping technology, the combination creates a more robust solution that scans workloads and configurations (vulnerabilities and hardening, too) in development and protects workloads at runtime. It makes natural sense to combine the two disciplines, but as we have learned so far, things are not always that simple in the cloud.

As native cloud-based security solutions mature, expect the lines to blur between them even more. CNAPP is one of the first categories to undergo this transition, and we expect disciplines like vulnerability management and compliance reporting to soon become commodities in CSPM, as compared to their stand-alone on-premise counterparts. It ultimately will be up to your organization to choose whether a merged solution is the best fit or a stand-alone one. In our opinion, this is akin to antivirus solutions and anti-spyware solutions merging over a decade ago to become anti-malware and endpoint protection platforms.

Cloud Access Security Broker (CASB)

A Cloud Access Security Broker (CASB) is typically a cloud-hosted solution (some vendors still use on-premise versions, but that is a fading trend) that provides a connection barrier and broker between users and cloud service providers. The basic design addresses security gaps for any XaaS deployment and connections into an on-premise environment. A CASB also allows organizations to extend and implement their security policies from on-premises infrastructure and apply them to the cloud. This ensures visibility and continuity based on existing controls and develops new policies that are cloud specific.

CASBs have become a critical part of enterprise security, allowing businesses to safely use the cloud, while protecting sensitive corporate workloads and data. This allows a CASB to serve as a policy enforcement center, consolidating multiple types of security policy enforcement engines and applying them to any assets in the cloud. A typical CASB deployment is also asset agnostic and supports everything from BYOD to servers regardless of whether they are managed or not by the business.

As digital transformation continues to dominate business initiatives, supporting visibility and control in these environments is crucial to meeting compliance requirements, protecting your assets from cloud attack vectors, and allowing your trusted identities to safely use cloud services – without introducing more risks to your organization.

Artificial Intelligence (AI)

Artificial intelligence (AI) and, to a lesser extent, machine learning (ML) have become increasingly prevalent as a solution to solve complex information security problems. AI is an approach that allows assets to acquire intelligence in a way that is similar to how living organisms learn to use algorithms. It is important to note that we did not state humans, in this definition, since the learning patterns of insects and rodents have also been duplicated with artificial intelligence, and the results have been quite useful.

AI technology can learn from repeated interactions with situations and events to develop correlations and predictions about current and future behavior. Artificial intelligence algorithms can discern information from a data series, without dependence on a previously determined relationship or characteristics. Training occurs as it does with living organisms, and relationships are further strengthened by repetition and reinforcement. This approach has grown in practical terms, with the increase in computing power available in the cloud, multitenant correlated datasets, and allowing the aggregation, ingestion, and analysis of very large datasets and events from similar data sources. In this way, artificial intelligence enables a level of reasoning that mimics a living brain, since the ability to analyze data at this volume and speed is impractical for living tissue.

To be clear, AI should not be confused with machine learning. Machine learning is actually a subset of AI, where the algorithms have been predefined for a specific data type and expected output. Machine learning is best characterized as fixed algorithms within artificial intelligence that can learn and postulate, while true AI is a step above that develops new algorithms to analyze data. AI is more analogous to a human learning when a new behavior is needed without a previous frame of reference. Therefore, artificial intelligence is more associated with the interpretation of information that is learned to drive conclusions or make decisions, while, to work effectively, machine learning must already have an awareness of the scope of data being processed. Because of this relationship, many machine learning implementations are part of, or afterthoughts, when an artificial intelligence application project has been fully understood and the results can be modeled for better efficiency.

Due to the considerable volume of data created by modern information networks, artificial intelligence can be a useful way to supplement human analysis of security events and identify indicators of compromise. This value is self-evident due to the inability of humans to interpret raw security event data, which can easily overwhelm even advanced security tools when there is a high quantity of data. AI can help security analysts by detecting when a cloud attack has occurred, evaluating identity behavior, assessing vulnerabilities and exposures, and correlating the information from known, and potentially unknown, attack strategies. This analysis is particularly useful in situations where behaviors can be unpredictable, identities and process ephemeral, and where targeted rules defined in policies are problematic in determining if an event was malicious or not.

Artificial intelligence can be used to assess anomalies and build a foundation for these situations. The results can be correlated by other external sources but will serve as a contextually relevant tool to assess what threat actors have potentially impacted an organization and to what degree. AI is useful because it can create initial relationships and then strengthen or weaken those relationships based on continuous analysis.

Artificial intelligence is a useful tool to supplement security best practices in the cloud, but it should not be treated as the only method of detection, prevention, and response. Nothing will completely replace the need for the security basics, security analysts, and forensic information that are needed to dig deep or to hunt for adversaries. One thing that remains certain is that AI will continue to evolve. Once the security basics have matured, AI should be considered a mitigation technology within your cloud strategy.

Single Tenant vs. Multitenant

Today, there are many cloud-native, built and optimized for the cloud, Software-as-a-Service (SaaS) solutions from which to choose. Yet, many competing solutions continue to bear the mantle of “cloud based,” even though they really represent just a lift and shift of their traditional software solution to the cloud. This latter rebranding and stretching of the meaning of cloud is referred to as “cloud washing.”

When it comes down to it, if the price is right, the uptime measures up against a service-level agreement, and the solution is secure, does it matter if the solution is truly “cloud based” in the strictest sense? Does it really matter if the solution is cloud native and multitenant or a re-engineered version to work in the cloud as a single tenant?

Traditional, on-premise technologies are normally considered single-tenant solutions, while cloud-based solutions are generally considered multitenant. However, these are perceptions, not hard rules, and often, these definitions are blurred in an organization’s actual usage of cloud applications. For instance, when you subscribe to a SaaS multitenant solution, the shared resources behind your subscription are utilized by multiple other organizations, but your custom coding and implementation may be a single tenant representing a hybrid tenant environment.

Foregoing these security practices is a trade-off that organizations must weigh in lieu of maintaining the hardware, operating system, maintenance, and security patches for the solution as compared to an on-premise instance or a private cloud deployment.

So, what else is different between a single-tenant and multitenant SaaS solution? If the cost to the end user is acceptable, the choice of 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 SaaS solution, the SaaS solution’s capabilities should be given the most importance as the tenancy model. Hybrid tenancy-based solutions are a good solution for this requirement.

And finally, consider security. All SaaS solutions should allow automatic security patching, but the difference defers back to your change control requirements.

Ultimately, it is up to you to decide if change control, security, and customization are that important when choosing a SaaS solution. While the vendor’s runtime cost should include lower multitenant solutions, well-designed single-tenant solutions can be just as cost-effective for them and for you.

Cyber Insurance

To start, cyber insurance is not a primary cloud attack vector mitigation strategy. In fact, it is not even a secondary mitigation strategy. It is, however, a required mitigation solution based on common contractual requirements. Often, as part of a contract, organizations must demonstrate that they have a financial backstop if an incident does occur. Organizations that rely on cyber insurance to provide compensation are deficient in basic security controls and may even be denied coverage if violations are found in their security implementations.

Monitoring Technology

One of the oppositions to new technology placed on an endpoint is the need for an agent. In fact, for years, one of the biggest objections by companies has been the need for agent technology at all. Time and time again, end users resist adding to their endpoint agent stack due to bloat, incompatibilities, resource consumption, and additional management overhead. In recent years, vendor consolidation and multidiscipline agents have reduced this friction. Yet, agent technology remains one of the least desirable ways to deploy and manage an endpoint.

Now, consider the cloud. Security problems in the cloud can be solved with agent technology when we cloud wash our solutions. However, as we embrace modern cloud implementations with containers, microservices, serverless processes, and ephemeral assets, we find that agent technology is difficult, if not impossible, to deploy and maintain. In fact, performing basic disciplines, like privileged access management (PAM), vulnerability management, file integrity management, and anti-malware protection, requires agents – especially when authenticated access is neither available nor desirable due to security best practices for asset hardening.

The simple factor of enabling SMB, SSH, or even WMI to allow authenticated access in the cloud is a security risk. Therefore, end users were left with agent technology to solve the problem, even when the cloud implementation is best optimized without them. This held true until recently.

Consider what the cloud excels at – automation. Cloud service providers (CSP) have created robust application programming interfaces (APIs) to enable automation and to enable machine-to-machine connectivity. These APIs allow for everything from asset creation through deletion and even running commands and monitoring processes within assets. The APIs accomplish all of this without using agents.

Modern security solutions can now inspect assets during runtime and determine characteristics – just like an authenticated scan or if an agent is running locally all through the hypervisors API. One such technology is called API scanning. API-based scanning technology leverages the CSP API to enumerate the file system, processes, and services within an asset for vulnerabilities, malware, asset discovery, and account management. This approach succeeds where agents are less desirable since the hypervisor has complete asset access (via the API) to enumerate any contents operating virtually. API-based scanning requires a translation layer to perform complex functions via the API and map the results into a typical asset inventory, file system list, and runtime anomalies, like malware, that we see from traditional solutions. Since this is an identification process only, API side scanning can use a read-only API account (operating use best practices like least privilege) compared to network scanning, with authentication that typically needs administrator or root access.

API scanning does not require any remote access protocols, thus reducing the asset’s risk surface. This approach is the first step in removing agent technology from the cloud. API-based scanning technology also optimizes runtime in the cloud and costs based on consumption-based pricing.

As one would expect, API scanning is an emerging technology based on the capabilities available from cloud service providers. As they continue to provide additional automation, new APIs are being created to streamline services. When utilized by third-party vendors, the APIs can be implemented to provide new functionality. In many cases, this functionality can replace legacy network scanning and agent technology-based solutions. This may ultimately spell the demise of agent technology in the cloud, something many security professionals and information technology administrators eagerly await.