Protection requirements for securing virtual machine, container and serverless workloads in public and private clouds continue to evolve rapidly. Security and risk management leaders should develop a strategy for addressing the unique and dynamic requirements for protecting hybrid cloud workloads.
- Enterprises using EPP offerings designed solely for protecting end-user devices (e.g., desktops, laptops) for server workload protection are putting enterprise data and applications at risk.
- Most enterprises are purposefully using more than one public cloud IaaS.
- The majority of enterprises are now piloting or using container-based applications and are experimenting with serverless PaaS.
- With cloud-native applications, workload protection must start proactively in development.
- Some CWPP vendors focus only on one or two use cases such as microsegmentation.
- Increasingly, container and serverless workloads are deployed without runtime protection because organizations don’t see the value.
Security and risk management leaders responsible for cloud workload security should:
- Architect for consistent visibility and control of all workloads regardless of location or size.
- Replace antivirus (AV)-centric strategies with a “zero-trust execution”/default deny/application control approach to workload protection where possible, even if used only in detection mode.
- Require CWPP offerings to expose all functionality via application programming interfaces.
- Extend workload scanning and compliance efforts into development (DevSecOps) especially with container-based and serverless function PaaS-based development and deployment.
- Require CWPP vendors to support containers now with planned solutions for serverless.
- Architect for scenarios where runtime CWPP agents cannot be used or no longer make sense.
Strategic Planning Assumptions
By 2022, 60% of server workloads will use application control in lieu of antivirus, which is an increase from 35% at YE18.
Through 2020, due to the immaturity of incumbent CWPP offerings, 70% of organizations will use a different CWPP offering for container and serverless protection than they use for virtual machine protection.
This document was revised on 8 April 2019. The document you are viewing is the corrected version. For more information, see the Corrections page on gartner.com.
The market for cloud workload protection platforms (CWPPs) is defined by workload-centric security offerings that target the unique protection requirements of server workloads in modern hybrid, multicloud data center architectures. CWPPs should provide consistent visibility and control for physical machines, virtual machines, containers and serverless workloads, regardless of location. CWPP offerings protect the workload from attacks, typically using a combination of network segmentation, system integrity protection, application control, behavioral monitoring, host-based intrusion prevention and optional anti-malware protection.
The market for endpoint protection has bifurcated into offerings focused on end-user-focused endpoint protection platform (EPP) device protection and CWPP, the market discussed in this Market Guide. CWPPs protect server workloads from attack, regardless of the location or granularity of the workload. CWPPs provide security and risk management leaders with consistent visibility and control of all server workloads. However, the composition of the modern data center, the granularity of workloads and the speed of development are changing rapidly. CWPP offerings and security and risk management leaders responsible for cloud security must evolve to support these trends.
A modern hybrid data center is composed of workloads (units of back-end compute work) running on-premises and also in IaaS. In most cases, enterprises are using multiple IaaS providers by design.1 Even though the percentage of workloads running on-premises is shrinking, most enterprises believe that at least some amount of their on-premises data center will still be around for years to come.2 The reality is that most enterprises will have workloads to protect distributed across a combination of on-premises, colocation and multiple public cloud IaaS platforms. We refer to this as a hybrid, multicloud architecture. The composition and location of enterprise data center workloads are changing. Cloud workload protection strategies must evolve along with these changes.
At the same time, the granularity of the workloads, their life span and how they are created are also changing. The majority of enterprises now have at least one Linux container-based application in development, pilot or production.3 There is also increasing adoption of serverless PaaS (also referred to as function PaaS or fPaaS). A CWPP strategy should be adopted to provide consistent visibility and control of workloads, regardless of the granularity of the workload (see Figure 1).
Workloads are becoming more granular — with shorter life spans — as development organizations adopt DevOps-style development patterns. DevOps is designed for multiple small iterations, often several times per week and in some cases, several times per day. The best way to secure these rapidly changing and short-lived workloads is to start their protection proactively in the development phase (see “10 Things to Get Right for Successful DevSecOps”) so that when a workload is instantiated in production, it is “born” protected.
Further, “cloud-native” applications are often composed of a combination of virtual machines (VMs), containers and serverless PaaS to deliver the application service — all of which need protection. As the granularity and dynamism of workloads are changing, CWPP strategies and offerings must evolve.
Occasionally, we see enterprises using end-user-focused EPP (see “Magic Quadrant for Endpoint Protection Platforms”) offerings designed for desktops, laptops and tablets on server workloads. These are ill-suited for the requirements of dynamic hybrid, multicloud workload protection. The risk profile and threat exposure of a server workload is markedly different than an end-user-facing system. Enterprises that use an EPP offering designed for end-user supporting devices are putting enterprise data and applications at risk. CWPP offerings focus on the protection needs of server workloads in a modern hybrid, multicloud data center. Indeed, several of the larger CWPP vendors such as Trend Micro, Symantec and McAfee offer distinct and separate offerings for EPP and CWPP to address the unique requirements of each of these markets.
Even though some of the same capabilities may be leveraged across a vendor’s EPP and CWPP offerings, they are different offerings. Example differences include CWPP requirements such as full programmability of the platform and the importance of application control, microsegmentation and cloud platform integration. CWPP differences also include the critical need to support Linux and Linux containers with continuous integration/continuous deployment (CI/CD) scanning in a DevSecOps environment (see Note 3).
CWPPs provide enterprises with a way to protect hybrid, multicloud workloads and provide consistent visibility and control of all server workloads, regardless of the location or granularity of the workload. At YE18, we estimated that the CWPP market was in the range of $600 million to $700 million in revenue with aggregate double-digit year-over-year growth. Currently, the three largest vendors — McAfee, Symantec and Trend Micro — represent approximately half of the yearly revenue in the CWPP market.
There are multiple trends behind the increased adoption of CWPP offerings by enterprises:
- Workloads are being moved from on-premises to public cloud IaaS, and the overall number of IaaS workloads is growing.
- In public cloud IaaS, workload-centric host-based CWPP solutions provide an easier architectural option for enforcing security policy than traditional in-line network-based security controls. Workload-based offerings automatically scale out and back as the number of workloads increases and decreases.
- Likewise, the need for pervasive Secure Sockets Layer/Transport Layer Security(SSL/TLS) decryption and inspection is performed more easily at the host workload where the session is terminated versus having to decrypt traffic in line using “man-in-the-middle” approaches. This is especially true for inspecting traffic that moves laterally east/west from service to service in microservices-based architectures.
- The shift to cloud-native application development using container-based application architectures, microservices-based applications and adoption of serverless PaaS will require new CWPP capabilities both in development and at runtime. Cloud-native apps require solutions designed to address the protection requirements of cloud-based systems.
Other key CWPP market trends include:
- Encryption of all data at rest in public clouds using cloud-native encryption. This capability was previously a common feature of CWPP offerings, but most enterprises use the built-in encryption capabilities of the OS or the underlying cloud fabric (see Note 4). We have removed encryption as a CWPP requirement in this 2019 Market Guide.
- Requests from enterprises for workload threat detection and response capabilities.Organizations that adopt Gartner’s CARTA strategic framework and adaptive security architecture (see “Zero Trust Is an Initial Step on the Roadmap to CARTA”) acknowledge that CWPP strategies cannot rely solely on preventive controls. Thus, server workload behavioral monitoring is becoming a critical requirement of CWPPs. Vendors such as Crowdstrike (well-known for end-user endpoint detection and response) are now actively targeting the server detection/response use case. Indeed, some CWPP vendors focus only on the detection/response use case.
- The increasingly short life spans of workloads. With cloud-native development using containers and serverless computing, processes and threads that compromise the application come and go quickly. There is no time for traditional loading of signature files or anti-malware scanning. Behavioral monitoring solutions that rely on observing a running workload may need dozens of instantiations before a reliable model can be created. Workloads need to be “born secure” from the moment they are instantiated. This places a critical need on development scanning and modeling.
- The shift to an immutable infrastructure mindset. This is an operational model in which no configuration changes, patches or software updates are allowed on production systems. Patches and updates are applied to the base (“golden”) images and layers, then the production workloads are built fresh from these images and replaced, rather than serviced. With immutable infrastructure, CWPP protection strategies will shift to a focus on application control and container lockdown (default deny/zero trust) at runtime, with a stronger emphasis on scanning for vulnerabilities before deployment. These strategies will also shift to building the application control/whitelisting models in development, before workloads are deployed into production.
- The shift to agentless protection in container environments. There is no guarantee that an enterprise will be able to place agents in the Linux host OS in a container-based deployment. This is increasingly the case with locked-down minimal kernels and with some managed Kubernetes services. The answer is to provide an architectural option to run the CWPP offering as a privileged container (or run it as a sidecar in Kubernetes pods and in service mesh architectures). Some CWPP startups focus only on the protection requirements of containers.
- The shift to CWPP code layering, wrappering or insertion in serverless environments.In serverless PaaS environments, agents and privileged containers/sidecars will not work. New approaches are needed such as layering in security controls,4 injection of security protection and creating a parent/child relationship from a security wrapper to the serverless function. Some CWPP startups focus only on this use case.
- Running without runtime protection agents. With containers and serverless architectures, if the workloads are scanned in development and the foundational requirements (such as application control) are met, why burden containers/serverless with any runtime protection? Assuming prescanning, the core runtime protection needs — such as segmentation and behavioral monitoring — may be delivered outside of the workload. This is increasingly the case with the adoption of immutable infrastructure and container/serverless PaaS life spans, which are measured in minutes, not hours.
Figure 2 is drawn as a hierarchical pyramid with a rectangular foundational base. Security of server workloads is rooted in the solid operations hygiene best practices shown in the shaded base. Any workload protection strategy must start here, ensuring the following conditions:
- It is difficult for anyone (attacker or administrator) to access the workloads physically and logically.
- The workload image has only the code it needs. Browsers and email usage should be banned from server images.
- Changes to the server workloads are only possible using a managed, disciplined process with auditability, and administrative access is tightly controlled with mandatory strong authentication (typically using a privileged access management product, see “Magic Quadrant for Privileged Access Management”).
- The OS and application logs are collected and monitored as part of overall enterprise log management/security information and event management (SIEM) effort.
- The workload is hardened, minimized and patched, reducing the surface area for attack.
Above this foundation is the hierarchical pyramid of controls recommended for server workload protection — a combination of preventive and detection/response controls. Collectively, these provide a comprehensive workload protection strategy. However, not every layer will be needed for every server workload based on the usage profile of the workload, the workload’s exposure and the enterprise’s tolerance for risk.
CWPP Controls, Layer by Layer
There are eight layers of CWPP controls. Because of its critical importance, the first layer — hardening, configuration and vulnerability management — spans both operations hygiene and CWPP.
Hardening, configuration and vulnerability management. Unnecessary components, such as Telnet, FTP and other services, should be removed. Images should be hardened using industry-standard guidelines as the starting point. These specific steps may be maintained and executed by IT operations (thus the inclusion of this layer in the base). However, information security is responsible for ensuring that systems are hardened and configured according to the organization’s guidelines, and systems are kept patched and up-to-date in a timely manner according to the organization’s policies and industry best practices.
In many cases, this functionality will be achieved using an external scanning tool or service — for example, Cavirin, Qualys, Rapid7 or Tenable.io (Nessus). However, some of the CWPP solutions in this Market Guide can also assess the system configuration, compliance and vulnerability status from the “inside out,” using their agents to provide this visibility. In these cases, CWPPs should provide specific policy recommendations for the workload hardening, based on the workload’s contents.
Network firewalling, visibility and microsegmentation. A key requirement of solid workload security is firewalling/segmentation of the workload’s ability to communicate with other resources. Some CWPP offerings provide their own firewalling capabilities, whereas others manage the built-in firewalls of Windows and Linux. Some CWPPs also manage the built-in segmentation of Amazon EC2 Security Groups and Microsoft Azure Network Security Groups. The solution should support the growing requirement for “microsegmentation” (more granular, software-defined segmentation also referred to as zero trust network segmentation; see “Zero Trust Is an Initial Step on the Roadmap to CARTA”) of east/west traffic in data centers.
In addition, several of the solutions provide visibility and monitoring of the communication flows. Visualization tools enable operations and security administrators to understand flow patterns, set segmentation policies and monitor for deviations. Finally, several vendors offer optional encryption of the network traffic (typically, point-to-point IPsec transport mode security associations) among workloads for the protection of data in motion, and provide cryptographic network isolation among workloads.
System integrity assurance. Capabilities here span two areas:
- Preboot — The ability to measure the basic input/output system (BIOS), Unified Extensible Firmware Interface, firmware, hypervisor, VMs and container system images before they are loaded, which is typically achieved using trust measurements rooted in hardware for physical systems. In the public cloud, this will be limited to measuring the integrity of the system images and containers before mount and attestation of geographic location.
- Postboot — The real-time monitoring of the integrity of the workload including critical system files and configuration after the workloads are booted. Like stand-alone antivirus, the value of file integrity monitoring (FIM) alone is minimal. However, it may be required by auditors because FIM is a requirement of multiple regulations such as the Payment Card Industry Data Security Standard (PCI DSS). Advanced solutions also monitor the integrity of the Windows registry, startup folders, drivers, boot loader and other critical system areas. Another area of significant interest is monitoring for workload configuration drift from its desired operational state. This is especially true with immutable infrastructure. Several CWPP offerings can monitor the workload for unexpected state changes and reset these back to desired settings.
Application control/whitelisting. Most workloads in on-premises VMs and in public cloud IaaS run a single application. This is almost always the case with containers hosting microservices-based applications and with serverless functions. The use of application control (also referred to as whitelisting or allow listing) to control what executables are run on a server provides an extremely powerful security protection strategy. This allows enterprises to adopt a default deny/zero trust security posture for executables. All malware that manifests itself as a file to be executed is blocked by default. Many CWPP solutions provide built-in application control capabilities, or dedicated point solutions offer them.
Alternatively, the built-in application control capabilities of the OS might be used such as software restriction policies: AppLocker and Defender Device Guard with Windows, Security-Enhanced Linux (SELinux) or AppArmor with Linux, or AppDefense with VMware. Some of the application control vendors can further constrain the runtime behavior of whitelisted applications using more granular policy enforcement.
Exploit prevention/memory protection. Application control solutions are fallible and must be combined with exploit prevention and memory protection capabilities, either from the OS — for example, address space layout randomization (ASLR)6 and seccomp7,8 — or with supplemental capabilities from the CWPP vendor. We consider this a mandatory capability to protect from the scenario in which a vulnerability in a whitelisted application is attacked. The injected code runs entirely from memory and doesn’t manifest itself as a separately executed and controllable file (referred to as “fileless malware”). In addition, exploit prevention and memory protection solutions can provide broad protection against attacks, without the overhead of traditional, signature-based antivirus solutions. They can also be used as mitigating controls when patches are not available. Another powerful memory protection approach used by some CWPP offerings is referred to as moving target defense — randomizing the OS kernel, libraries and applications so that each system differs in its memory layout to prevent memory-based attacks.
Server workload EDR, behavioral monitoring, and threat detection/response. This layer should also be mandatory; however, this capability may be achieved via monitoring from outside the workload. Server EDR goes beyond the system integrity monitoring discussed previously (a basic form of EDR) and beyond legacy host-based intrusion detection systems (HIDS). Server EDR monitoring looks at behaviors such as network communications, processes launched, files opened and log entries for behavior patterns that indicate malicious activity, including within containers. Another technique is to establish patterns of expected behaviors from whitelisted applications and to look for deviations in behavior.
Several of the end-user EDR point solution vendors specifically target server workload protection use cases for behavioral monitoring (see “Market Guide for Endpoint Detection and Response Solutions”).
These capabilities are focused on detection and response, rather than prevention of attacks. Some organizations will achieve this with network-based and cloud-based monitoring, rather than host-based agents (for example, using the built-in network flow log data of the major cloud providers, avoiding the resource overhead of continuous workload-based monitoring). Thus, we have not made this a core requirement of CWPP. Another common use case for server EDR will be to quickly scan all systems for the presence of a specific file by name or hash in the event of an outbreak. This is similar to signature-based antivirus scanning, but is used in detection/response scenarios.
Host-based IPS with vulnerability shielding. Here, the CWPP vendor deeply inspects the incoming network traffic stream for attacks against known vulnerabilities and prevents them. If network-based intrusion prevention systems (IPSs) protect the workload, this layer may be redundant. However, network-based IPS may not protect from inter-VM or inter-container-based attacks. Also, since the traffic is terminated at the host workloads, host-based intrusion prevention system (HIPS) inspection may be a better architectural option since it is performed at the host rather than in the network. HIPS becomes a valuable defense in depth control to shield from attacks on a zero-day vulnerability, until the patch can be applied or the workload’s code is rebuilt from a patched image. HIPS is used by some organizations to reduce the frequency of server patching. HIPS may also be critical for protecting server workloads that are difficult to patch or that are no longer supported with patches by the vendor (such as Windows Server 2003, which fell out of support in 2015).
Anti-malware scanning. Signature-based antivirus and anti-malware scanning provide little to no value on well-managed server workloads. Use an application control whitelisting model supplemented with memory protection and exploit prevention as the primary control for server workload protection. In some cases, signature-based file scanning makes sense — for example, if the server workload is serving as a general-purpose file repository such as a file share, a Network File System (NFS) server, an FTP server or a Microsoft SharePoint server. In these cases, the file repository should be scanned; but this can be performed externally outside of the CWPP offering (for example, several cloud access security broker [CASB] vendors offer this). The same is true with storage services such as object stores in public cloud IaaS, which should also be scanned. Ideally, these would replace legacy network file shares and shift out of workloads.
Another exception requiring antivirus would be a situation where regulatory requirements specify the use of antivirus and this is not negotiable with the auditor. Here, basic file system scanning to meet compliance requirements using a minimal open-source software (OSS) engine such as ClamAV is a possible strategy. Alternatively, use your incumbent endpoint antivirus solution and configure it to minimize the impact on server performance. This can be achieved by disabling real-time scanning, reducing the frequency of scheduled scans and reducing the scope of the scans to areas of the file system that are allowed to change, for some examples. Using the same anti-malware vendor on end-user endpoints and server workloads has the advantage of being managed under the same policy management system and, ideally, the same contract for higher levels of discounting.
Some CWPP vendors focus on offering full-stack protection by offering more of the layers shown in Figure 2 for comprehensive protection. Based on the enterprise’s requirements, they let the customer pick and choose which controls are needed for their specific use case (for example, FIM may only be required on PCI-related workloads). In contrast, some CWPP vendors focus on only one or two layers of the pyramid to address specific use cases — for example, network visibility and control with microsegmentation, or server workload behavioral monitoring for threat detection and response. We have separated the list of vendors and offerings in the Market Introduction section based on the most common use cases. Finally, with the emergence of cloud-native application development using containers and serverless functions, several cloud-native CWPP vendors have extended their scanning back in to the CI/CD pipeline.
As enterprises evaluate the large number of offerings in the CWPP market, we recommend the following evaluation criteria:
- Diversity of workload types supported
- Use of analytics and machine learning
- Console and integrations
- Integration into the development pipeline
- Licensing flexibility
- Other CWPP market adjacencies
Diversity of Workload Types Supported
- OS support. Very few CWPP vendors support legacy UNIX (e.g., AIX, HP-UX and Solaris) but some enterprises may want the same vendor to protect these as their public and private cloud-based workloads. Some CWPP vendors only support Linux. Others support only Windows. Some vendors have explicit support for out-of-support OSs, such as WS2003, providing a compensating control for systems where patches are no longer available. This requirement may be critical for embedded systems, process controllers and IoT/OT/cyber-physical systems that cannot be upgraded or patched. In Amazon Web Services (AWS), explicit support for AWS Linux should be considered a mandatory requirement.
- Container support. If a vendor will support Linux, it has become a mandatory market requirement that its CWPP offering supports Linux containers. At a minimum, the Linux agent needs to talk to the Docker and Kubernetes APIs to understand the container context. Some of the vendors in this Market Guide support only container-based systems. There are two primary architectures for container protection — deployed as an agent in the Linux OS or running as a privileged container.
- Monolithic container support. In an ideal world, containers would be small and single-purpose supporting microservices architectures. The reality is that software vendors are taking what was a legacy virtual appliance in the form of a VM and creating large monolithic containers. Container-based protection solutions must be able to understand and protect these monolithic containers.
- Container-as-a-service support. Kubernetes has become the de facto container orchestration platform. Explicit support for Kubernetes and the major managed Kubernetes services should be considered mandatory including Amazon Elastic Container Service for Kubernetes (Amazon EKS), Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE), and on-premises with Red Hat OpenShift. Depending on the vendor and the managed Kubernetes offering, there may not be an ability to use a host OS-based agent of a traditional CWPP vendor.
- Orchestration-as-a-service support. Beyond managed Kubernetes as a service, some enterprises are exploring managed orchestration as a service that removes the need to have Kubernetes expertise (e.g., AWS Fargate and Azure Container Instances [ACI]). These services are harder to protect because there is no exposed host OS to use an agent with, and further, there is limited to no ability to run a privileged container.
- Serverless function protection options. There has been significant client interest in the adoption of serverless functions along with the need to secure these. The approaches here vary as privileged containers and host-based agents simply will not work to protect these. Some CWPP offerings focus only on this use case.
Use of Analytics and Machine Learning
Many of the CWPP capabilities shown in Figure 2 can be improved with the use of advanced analytics and machine learning. In all cases, it is important to understand the amount of data collected and the impact on resource utilization, including network bandwidth and where the data will be stored. Some vendors keep the data local to the enterprise; others send all the data for cloud-based analytics. Specific examples include:
- Network segmentation. By observing patterns of network communications over time, machine learning can cluster workloads of similar requirements and propose micro-segmentation policies to implement. Advanced offerings can identify applications based on the application’s communications profile. When patterns of network communications deviate from expected behaviors, these communications can be blocked or alerted on, serving as a form of threat detection.
- Application control. By observing patterns of process behaviors, machine learning can build models of expected application behavior and propose application control policies to implement. When observed application behaviors deviate from baselines, these processes can be blocked or alerted on, serving as a form of threat detection.
- EDR for servers. Similar to application control, CWPP offerings that focus here are designed for deep visibility into workload behaviors. Correlation and analytics can be used to identify indicators of attack (IOAs) in the exhibited behaviors. Likewise, models of expected behavioral patterns can be established and alerted on or blocked when the behavior deviates in ways that represent excessive risk or are indicative of an attack.
- Anti-malware protection. The use of machine-learning-based static analysis of code pre-execution to identify malware without the use of signatures is becoming a mainstream capability. If anti-malware protection is needed, the CWPP vendor should offer this in addition to traditional signature-based scanning. If the CWPP vendor provides independent proof of efficacy, this could replace the need for traditional signature-based scanning.
- Community integration and threat intelligence sharing. Advanced CWPP offerings share threat intelligence across their community of users, helping to identify interenterprise patterns that are not visible in a single organization alone. By sharing telemetry and analysis, there is value in broader “community immunity.” By obfuscating the telemetry that is shared, CWPP vendors can balance the enterprise need for privacy with the community need for protection.
Console and Integrations
- The console of the CWPP provider should support the logical grouping and application of policy by workload type. The ability for the customer to define its own logical naming and tagging to workloads is imperative. In addition, the console should be able to import and understand the tagging of the underlying cloud platform for the simplification of policy formation (for example, directly integrating with AWS APIs and using its labels directly in the CWPP console).
- The console of the CWPP provider should optionally be available as a cloud-based service. This allows the organization to define its own policies, without the complexity of having to set up a management server and database to support the management console.
- As an alternative to using the console, increasingly CWPP configuration and deployments are being driven entirely by scripts and CI/CD pipeline tools. Every capability in the CWPP vendor’s console should be exposed as an API. Ideally, the vendor has built its CWPP console entirely on its own APIs to ensure this.
- The CWPP offering should provide native integration into public cloud environments to take advantage of the programmatic capabilities of the underlying cloud platform. In IaaS, this means integration with the APIs of AWS, Azure, Google and others.
- On-premises integration into the VMware environment is a common requirement. Examples include optional agentless anti-malware scanning on vSphere, NSX Data Center integration and possible integration into VMware AppDefense. Other on-premises cloud platform support requests include Kubernetes distributions such as Red Hat OpenShift. Occasionally, support for OpenStack is a requirement; but very few CWPP vendors support this.
- The CWPP offering should be integrated into the app store of the cloud environment. There are multiple customer benefits to this such as ease of testing, purchase and installation, and usage-based pricing. Some vendors offer consolidated billing.
Integration Into the Development Pipeline
- In addition to full API enablement, the CWPP offering should offer native CI/CD toolchain integration. Examples include integration with Ansible, Chef, Jenkins, Puppet and Travis CI. In public cloud deployments, the CWPP offering may need to integrate with the IaaS provider’s code pipeline tools such as AWS CodePipeline and Azure DevOps. For serverless integration, toolkits such as Serverless are needed.
- Ideally, the CWPP offering would offer the ability to scan any development artifacts (e.g., containers, VMs and serverless code) for vulnerabilities. Many of the container-centric CWPP vendors do this for containers and container registries based on market demand. Very few of the incumbent CWPP providers have added scanning in development. An ideal CWPP solution would offer the same ability to open and scan containers as well as VM-based images in development. Scanned artifacts should be digitally signed and verified to ensure they haven’t been tampered with when they are instantiated in production.
- A few innovative CWPP vendors can gather the intended state of a workload by analyzing development artifacts for developer intent. Through analysis of AWS CloudFormation, Chef, Puppet, VMware vRealize Automation and other declarative scripting environments, CWPP vendors can develop an expected state model for the workload before it is deployed. This allows the workload to be “born protected” with a whitelisting protection profile already in place. Several of the CWPP vendors use exactly this approach to minimize manual configuration requirements.
- CWPP offerings are typically licensed per server workload OS protected. For most systems, this is per VM per year. The cost per year varies depending on the number of capabilities provided, but ranges from $75 to $350 per VM per year.
- For VMs in public clouds that may expand and contract based on demand, enterprises typically want more granular pricing. Per VM per minute pricing is available from the more advanced solutions, with pricing based on the machine image capacity.
- With containers, the pricing is typically based on the underlying host OS, not the total number of containers, as the actual container count can be highly variable. There is a premium for container-based protection for vendors that support development scanning and runtime protection.
- With serverless function protection, pricing models are still in flux. The most common model is based on the average number of serverless functions that will be protected over a period of time. To account for the variability and growth in the number of functions, bands of functions are typically used.
- For VMs, containers and serverless protection in public clouds, the more advanced CWPP vendors coordinate with the IaaS provider so that security protection billing is shown as a line item on the overall IaaS bill. This is a useful feature if the cost of security protection is charged back to the business owner.
Other CWPP Market Adjacencies
- Extension into cloud security posture management (CSPM). Several CWPP providers have entered the CSPM market as a logical adjacency (see “Innovation Insight for Cloud Security Posture Management” and Note 5). CWPP offerings protect workloads from the inside, while CSPM vendors protect workloads from the outside by assessing secure and compliant configuration of the cloud platform’s control plane (see Figure 3). In addition, McAfee and Symantec are two large CASB providers that also have CWPP and CSPM capabilities, providing visibility, risk and security protection for all three cloud security markets — CWPP, CSPM and CASB. With the growing complexity of cloud-based configurations, complete protection strategies will require a CSPM to ensure continuous, correct and compliant cloud configuration and identification of excessive risk.
- Web application firewalling. Some CWPP vendors may provide basic web application firewall (WAF) capabilities as a part of their in-line network inspection. This is not a substitute for a full north/south web application firewall, but can provide basic Layer 7 filtering and simple WAF capabilities for defense in depth, especially for distributed, east/west traffic flows.
- Log collection and monitoring. Typically, this capability is provided by an IT operations solution or a SIEM. However, for organizations that don’t yet have a solution for log monitoring, some CWPP vendors offering this capability provide a low-cost option for enterprises with regulatory requirements (for example, PCI DSS) for log monitoring.
- Privileged access management (PAM). PAM tools help organizations provide secure privileged access to critical assets and meet compliance requirements by managing and monitoring privileged accounts and access. Some CWPP vendors include basic PAM capabilities such as time-based logins, time-limited passwords and stronger authentication options for enterprises that do not have a full PAM offering.
- Deception. Deception has an important role to play on servers, but is typically provided by dedicated deception vendors, rather than CWPP providers. For this reason, deception was removed in this 2019 Market Guide. This emerging security protection capability creates fake vulnerabilities, systems, shares and cookies on the server (sometimes referred to as “honey data” or “honey tokens”). If an attacker tries to access or use these fake resources, this is a strong indicator that an attack is in progress, because a legitimate workload should not see or try to access these resources.
The vendors listed in this Market Guide do not imply an exhaustive list. This section is intended to provide more understanding of the market and its offerings.
The number of vendors providing workload-centric protection offerings is quite large. Some vendors focus on providing as many of the capabilities in Figure 2 as possible across multiple OSs. Others focus on specific capabilities such as microsegmentation, memory protection and behavioral monitoring, or focus only on container or serverless protection.
To help potential customers identify which CWPP offering addresses their use case best, we have grouped the vendors into seven categories (see Tables 1 through 7).
Table 1: Broad, Multi-OS Capabilities
Product, Service or Solution Name
AtomicWP Workload Protection
Kaspersky Lab (see Note 6)
Hybrid Cloud Security
Cloud Workload Security
Azure Security Center
Qingteng (China only)
Adaptive Security Platform
Intercept X for Server
Data Center Security
Cloud Workload Protection
Source: Gartner (April 2019)
Table 3: Application/Service Network Firewalling, Visibility, Microsegmentation and Control
Product, Service or Solution Name
Microservices Anomaly Detection
Cloud Network Security
Beijing Zhixiang Technology (China only)
ZShield Intelligent Security Agent (ZS-ISA)
Cloudvisory Security Platform
Zero Trust Segmentation for Hybrid Cloud
Adaptive Security Platform (ASP)
Source: Gartner (April 2019)
Table 4: Memory and Process Integrity/Protection
Table 5: Server EDR, Workload Behavioral Monitoring, and Threat Detection/Response
Table 6: Container Protection
Product, Service or Solution Name
Aqua Cloud Native Security Platform
Qualys (acquired Layered Insight)
Container Firewall Security Solution
Kubernetes Security Platform
Source: Gartner (April 2019)
The need for CWPP offerings continues to grow as enterprise requirements continue to evolve. We recommend the following best practices when evaluating CWPP offerings:
- Develop a specific strategy for the protection of cloud workloads that meets the unique requirements of server workload protection. Cloud-native apps require solutions designed to address the protection requirements of cloud-based systems.
- Do not use an offering designed to protect end-user endpoints and expect it to provide adequate protection for server workloads.
- The future of most enterprise data centers is a hybrid, multicloud architecture. Require CWPP offerings to protect physical machines, VMs, containers and serverless workloads — all from a single console and managed from a single set of APIs.
- Require the CWPP offering to expose all of its functionality via APIs to facilitate automation in cloud environments.
- Make container protection capabilities a mandatory requirement in your CWPP evaluation. If you are using Kubernetes and considering a managed Kubernetes service, make explicit support of this environment a mandatory requirement as well.
- Start asking your CWPP vendors now about their roadmap and architecture for serverless function protection. This is expected to become a mandatory requirement within 12 to 18 months.
- If your legacy CWPP vendor does not yet have support for containers or serverless functions, or these capabilities are immature, be open to purchasing a CWPP point solution. Point solutions may be required that specifically address these needs with 12- to 24-month contracts recommended. Alternatively, switch CWPP vendors to one that provides these capabilities.
- Proactively extend CWPP testing into the CI/CD pipeline. CWPP offerings that focus on runtime protection only are missing the critical shift in how applications and the workloads that host them are being developed.
- Whether or not your CWPP vendor provides CSPM capabilities, plan to make CSPM a priority project in 2019 (see “Top 10 Security Projects for 2019”).
- Prepare for a future where CWPP agents may not be needed. Properly implemented containers and serverless functions scanned for vulnerabilities predeployment are short-lived. When deployed within immutable infrastructure and monitored from the outside for unusual behaviors, they may not warrant any embedded runtime protection.
1 A recent audience poll taken at the end of 2018 showed that 65% of enterprises had adopted a multicloud IaaS strategy. This poll was taken at the Gartner IT Infrastructure, Operations and Cloud Strategies Conference in December 2019 (n = 168).
This survey “State of Enterprise Cloud and Container Adoption and Security” by DivvyCloud showed that 77% of enterprises had adopted a multicloud IaaS strategy.
2 At the December 2018 Gartner IT Infrastructure, Operations and Cloud Strategies Conference, an audience poll (n = 176) showed that 76% expected some amount of on-premises data center to be around at least five years or longer, with 33% of these believing it will never go away.
3 At the December 2018 Gartner IT Infrastructure, Operations and Cloud Strategies Conference, via an audience poll (n = 76), 54% indicated they had a container-based application in pilot or already in production. An additional 22% indicated they were actively experimenting with containers.
4 “AWS — Layers,” Serverless.
5 Standard configuration baselines are available from organizations such as the Center for Internet Security. This group has established baselines for AWS (“Tag: CIS AWS Foundations Benchmark”), Azure (“CIS Microsoft Azure Foundations Benchmark v1.0.0 Now Available”) and environments, such as Docker (“CIS Docker Benchmarks”). Other organizations such as the U.S. Defense Information Systems Agency have established guidelines as well.
6 “What Is ASLR, and How Does It Keep Your Computer Secure?” How-To Geek.
7 “Seccompsandbox — Overview.wiki,” Google Code Archive.
8 “A Seccomp Overview,” LWN.net.
9 “CNCF Cloud Native Definition v1.0,” GitHub.
11 “Amazon EBS Encryption,” Amazon Web Services (AWS).
12 “Azure Disk Encryption for IaaS VMs,” Microsoft Azure.