Вы находитесь на странице: 1из 29

Licensed for Distribution

Market Guide for Cloud Workload


Protection Platforms
Published 8 April 2019 - ID G00356240 - 40 min read
By Analysts Neil MacDonald

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.

Overview
Key Findings
■ 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.

Recommendations
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.

Market Definition
This document was revised on 9 July 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.

Market Description
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).
Figure 1. Increasing Granularity and Abstraction of Workloads

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 (see Note 2) 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).

Market Direction
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.

Market Analysis
Figure 2 shows the major elements of workload protection strategy in a modern, hybrid
multicloud data center architecture.
Figure 2. CWPP Controls Hierarchy

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
5
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 (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 seccomp 7 , 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.

Evaluation Criteria
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
microsegmentation 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.

Licensing Flexibility
■ 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.
Figure 3. Cloud Security Posture Management

■ 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.

Representative Vendors
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.

Market Introduction
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 lists representative vendors in the CWPP market that have broad, multi-OS capabilities.

Table 1: Broad, Multi-OS Capabilities

Vendor Product, Service or Solution Name

Atomicorp AtomicWP Workload Protection

Bitdefender GravityZone platform

Carbon Black CB Protection

CloudPassage Halo
Kaspersky Lab (see Note 6) Hybrid Cloud Security

McAfee Cloud Workload Security


Application Control
Change Control

Microsoft Azure Security Center

Qingteng (China only) Adaptive Security Platform

Sophos Intercept X for Server

Symantec Data Center Security


Cloud Workload Protection

Trend Micro Deep Security

VMware AppDefense

Source: Gartner (April 2019)

Table 2 lists representative vendors that focus on vulnerability scanning, configuration and
compliance.

Table 2: Vulnerability Scanning, Configuration and Compliance

Vendor Product, Service or Solution Name

Amazon Inspector

CloudAware CloudAware

Cloud Raxak Raxak Protect

HyTrust CloudControl

Trusted Access Technologies (was Security Code) vGate

Tripwire Tripwire Enterprise


Source: Gartner (April 2019)

Table 3 lists representative vendors that focus on application/service network firewalling,


visibility, microsegmentation and control.

Table 3: Application/Service Network Firewalling, Visibility, Microsegmentation and Control

Vendor Product, Service or Solution Name

Alcide Microservices Firewall


Microservices Anomaly Detection

Aporeto Cloud Network Security


Microservices Security

Beijing Zhixiang Technology (China only) ZShield Intelligent Security Agent (ZS-ISA)

Cisco Tetration

Cloudvisory Cloudvisory Security Platform

Edgewise Zero Trust Segmentation for Hybrid Cloud

Guardicore Centra

Illumio Adaptive Security Platform (ASP)

TrueFort TrueFort

Source: Gartner (April 2019)

Table 4 lists representative vendors that focus on memory and process integrity/protection.

Table 4: Memory and Process Integrity/Protection

Vendor Product, Service or Solution Name

Morphisec (Windows only) Morphisec


Palo Alto Networks Traps

Polyverse (Linux only) Polymorphic Linux

Virsec Virsec

Source: Gartner (April 2019)

Table 5 lists representative vendors that focus on server EDR, workload behavioral monitoring,
and threat detection/response.

Table 5: Server EDR, Workload Behavioral Monitoring, and Threat Detection/Response

Vendor Product, Service or Solution Name

Capsule8 (Linux only) Capsule8

Carbon Black CB Defense

Crowdstrike Falcon Endpoint Protection

Lacework (Linux only) Lacework

Jazz Networks Jazz Platform

Qualys Cloud Platform

Threat Stack (Linux only) Threat Stack

Source: Gartner (April 2019)

Table 6 lists representative vendors that focus on container protection.

Table 6: Container Protection

Vendor Product, Service or Solution Name

Aqua Security Aqua Cloud Native Security Platform

Aporeto Microservices Security


Qualys (acquired Layered Insight) Container Security

NeuVector Container Firewall Security Solution

Twistlock Twistlock

StackRox Kubernetes Security Platform

Sysdig Sysdig Secure

Source: Gartner (April 2019)

Table 7 lists representative vendors that focus on serverless protection.

Table 7: Serverless Protection

Vendor Product, Service or Solution Name

Nuweba Nuweba

Protego Labs Proact, Observe, Defend

PureSec Serverless Security Platform

Source: Gartner (April 2019)

Market Recommendations
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.

Evidence
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.

10
“The Big Hack: How China Used a Tiny Chip to Infiltrate U.S. Companies,” Bloomberg.

11
“Amazon EBS Encryption,” Amazon Web Services (AWS).

12
“Azure Disk Encryption for IaaS VMs,” Microsoft Azure.

Note 1
Representative Vendor Selection
The representative vendors listed in this Market Guide have a shipping offering at the time of
this publication that is specifically designed for the in-workload protection of server workloads
in on-premises and public cloud IaaS. To get detailed visibility into the OS itself (where
applicable), agents are used. For container environments, host OS agents or privileged
containers may be used. For serverless workloads, layering, wrapping or injection may be used.
API-based integration into the cloud fabric they are protecting is a requirement. The most
common API integrations requested by clients are VMware, AWS, Azure, OpenStack, Red Hat
OpenShift and Kubernetes. The CWPP offering cannot simply be a desktop-oriented offering
that will run in a server. The offering must be designed and optimized to support the server
workload protection use cases described in this research in an enterprise hybrid, multicloud
architecture. CWPP provided as a managed service is outside the scope of this research.

Note 2
Cloud-Native Applications
Gartner research “How to Assess Your Application to Adopt Cloud-Native Architecture” outlines
the characteristics of cloud-native applications to support:

■ Agile and distributed development

■ Deploying code frequently as a way of reducing risk and delivering faster (continuous
integration/continuous development [CI/CD])

■ The ability to build and operate complete, full-stack systems

■ Developing and testing on configurations that are identical to production, deploying the
same artifact across all life cycle stages and infrastructure through provisioning of new
instances (immutable infrastructure and containers)

■ Designing applications to be resilient and scalable when running on cloud-based


infrastructure, which has a unique combination of characteristics

The Cloud Native Computing Foundation has a broad definition for what defines a cloud-native
application: 9

■ They empower organizations to build and run scalable applications in modern, dynamic
environments such as public, private and hybrid clouds.

■ They enable loosely coupled systems that are resilient, manageable and observable.

■ Combined with robust automation, they allow engineers to make high-impact changes
frequently and predictably with minimal effort.

■ Containers, service meshes, microservices, immutable infrastructure and declarative APIs


exemplify the cloud-native approach.

Note 3
Key Differences Between EPP and CWPP
Some of the key differences CWPP offerings have from end-user EPP-focused offerings
include:

■ The protection profile. Server workloads shouldn’t execute arbitrary code. VMs tend to host
a single application, containers host a specific microservice, and serverless PaaS hosts a
single process. Thus, it is much more practical to implement a default deny/zero trust
application control posture on server workloads than on end-user devices.

■ Microsegmentation. To protect from the lateral spread of attacks, the ability to deliver
workload-to-workload/service-to-service network segmentation is often a requirement for
CWPP, but is rarely a requirement for EPP.

■ Cloud platform support and integration. CWPP offerings need to integrate into the native
cloud fabrics where the workloads reside. This requires specific integration with the
programmable public cloud infrastructure APIs of AWS, Azure and Google Cloud Platform
(GCP), and for on-premises workloads, it requires integration with VMware APIs.

■ The OSs supported. Linux OS support is a key requirement of CWPP. However, EPP vendors
rarely support Linux well, and if they do, the distributions used are different — for example in
public cloud IaaS, AWS Linux is a requirement. Likewise, Mac support is not needed for
CWPP.

■ Support for containers. Along with need for CWPP to protect Linux workloads comes the
need to protect Linux containers. Linux containers are rarely used on end-user endpoints
except for developers.

■ Support for DevSecOps. In most cases, containers are used within highly automated CI/CD
DevOps pipelines. CWPP offerings should support CI/CD scanning of development artifacts
to prevent vulnerable workloads from being released into production and to better build
runtime protection profiles. EPP offerings do not have this requirement.

■ Scale, speed and automation. CWPP offerings require full API enablement. In modern,
cloud-native application development and DevSecOps environments, all infrastructure is
programmable and driven by automation. CWPP offerings should be fully API-enabled.

■ Integrity of server OS, hypervisor and BIOS. Reported motherboard hacks in China have
raised awareness of the importance of workload system integrity and the need for full-stack
root of trust measurements. 10 Likewise, once the workload is running, file integrity
monitoring is a common requirement for server workloads, but rarely on end-user systems.
Note 4
Data at Rest Encryption
Encryption of data at rest should be a standard best practice for workloads running in public
cloud IaaS (see “How to Make Cloud IaaS Workloads More Secure Than Your Own Data
Center”). With the use of Intel’s AES-NI for cryptographic operation acceleration, the impact on
performance is minimal. In addition, many enterprises are making this a standard requirement
in their on-premises data centers. We have removed this as a criterion for CWPP selection
because many OSs now provide full drive encryption for free and support a “headless” mode
specifically for server protection scenarios.

Amazon also provides free full-volume encryption in AWS, 11 as well as free solutions for
Relational Database Service (RDS) and Simple Storage Service (S3). Microsoft provides a
similar capability with Azure Disk Encryption. 12 With any encryption, there is a need for secure
storage and management of encryption keys, as well as a need to support customer-managed
keys. More advanced solutions support features such as key management, cross-cloud
encryption and automatic key rotation.

Note 5
CWPP Vendors Offering CSPM Capabilities
■ CloudAware

■ CloudPassage

■ Cloudvisory

■ Crowdstrike

■ Lacework

■ McAfee (via its CASB offering)

■ Sophos

■ Symantec

■ Threat Stack

Note 6
Kaspersky Lab and U.S. Government Dispute
In September 2017, the U.S. government ordered all federal agencies to remove Kaspersky
Lab’s software from their systems. Several media reports, citing unnamed intelligence sources,
made additional claims. Gartner is unaware of any evidence brought forward in this matter. At
the same time, Kaspersky’s initial complaints have been dismissed by a U.S. District of
Columbia court.

Kaspersky has launched a transparency center in Zurich where trusted stakeholders can
inspect and evaluate product internals. Kaspersky has also committed to store and process
customer data in Zurich, Switzerland. Gartner clients, especially those who work closely with
U.S. federal agencies, should consider this information in their risk analysis and continue to
monitor this situation for updates.

© 2020 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc.
and its affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior
written permission. It consists of the opinions of Gartner's research organization, which should not be
construed as statements of fact. While the information contained in this publication has been obtained from
sources believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or
adequacy of such information. Although Gartner research may address legal and financial issues, Gartner
does not provide legal or investment advice and its research should not be construed or used as such. Your
access and use of this publication are governed by Gartner’s Usage Policy. Gartner prides itself on its
reputation for independence and objectivity. Its research is produced independently by its research
organization without input or influence from any third party. For further information, see "Guiding Principles
on Independence and Objectivity."

About Careers Newsroom Policies Site Index IT Glossary Gartner Blog


Network Contact Send Feedback

© 2018 Gartner, Inc. and/or its Affiliates. All Rights Reserved.