Shifting security left helps to reduce security related problems too late in the Software Development LifeCycle. Your CI/CD pipelines can include a lot of stages to check IaC templates, Dockerfiles, Helm charts and other scripts which acts as the base for your cloud (native) workloads. However, it’s impossible to prevent every single issue in the cloud. Suppose a third party application contains configuration that is not aligned with your internal security rules. Or you require other exceptions to make sure your container runs in the desired state on your Kubernetes cluster. It can also be the case to monitor your mission critical applications to a greater level of detail. Since you can’t (always) control your end-users and cloud-systems, there is a clear need to secure your cloud runtime environment. In this article we’ll explore what you need to know about Cloud Workload Protection.
What is it?
Based on the shared responsibility model, you are responsible for securing what you are running in the cloud. This means end-users are responsible for their “compute” workloads, whether it be Virtual Machines, containers, serverless applications or anything else. In case of the IaaS deployment model, the end-user is responsible for the Operating System of the Virtual Machine: security patches, controlling the network traffic to and from the VM, monitor for security incidents, etc.
When running a bunch of containers, perhaps in a Kubernetes cluster, things become more complicated since containers come and go as they are needed. Services can spawn on itself without interfering of any system administrator, think about auto-scaling to handle peak traffic. With Serverless architectures, you require a completely new way of thinking, since your functions require “compute” power but this all happens “under the hood”. That does not mean it’s not there, you just don’t see it, but you are still responsible for it.
Cloud providers offer extra security features on top of their native services. Think of a Web Application Firewall, control policies, security controls to check your (static) cloud configurations. However, they rarely offer any kind of threat protection for your actual workloads. Microsoft is the exception to the rule, since it offers Microsoft Defender for various of their other services.
How to protect?
Cloud Workload Protection is a (third party) service or “platform” that constantly monitors your running applications in the cloud. Every application that you run should be trusted and the CWP helps to make sure it stays trusted. It’s important that your workloads are not interrupted by the CWP platform. Besides this, it’s not desired that you need to make any changes to your workloads. Sometimes this is required, in case the actual runtime is not under your control. For example for AWS Fargate or Serverless related workloads.
Key features
From a functional point of view, most workload protection offers the following features:
- Vulnerability management of every service that is dedicated to “compute”.
- Track running workloads for compliance related issues.
- Alert or even block infrastructure related aspects if critical threads are detected.
- Protection of core infrastructure resources such as networking, file systems and other processes.
Advanced features
More advanced features include forensics which let’s you analyze events, configurations and other information that acts as an “audit trail” after a (potential) security incident. With this feature, you can find the actual root cause of issues and it helps to prevent similar issues in the future.
Another advanced feature consists of behavioral modeling. This is a concept that “records” the current behavior of your application. The Cloud Workload Protection Platform learns “normal behavior” and anything that deviates from it, is recorded. Based on your preferences you can alert upon suspicious behavior or completely block your component or application. Not all deployment types support it, but this applies at least to containerized workloads.
Common solutions
As with Container security, the number of solutions to offer Cloud Workload Protection Platforms is growing. Key players on the market offer their tools that emerged on the marked relatively long time ago:
- Aquasec offers the “Integrated Cloud Native Security Platform” to protect VMs, containers and serverless workloads. It enforces immutability of your applications in runtime. It also helps to establish zero-trust networking by detecting and stopping suspicious network activities. Therefore it also acts as a firewall for your containers, monitoring incoming and outgoing traffic.
- Sysdig is based on Wireshark, a popular Linux networking tool to detect suspicious (network) related behavior. The new tool is now called Sysdig Falco and it offers similar features compared to Aquasec. It also includes runtime protection for Fargate tasks and it provides auto-remediate and response actions to threats.
- Quite recently Palo Alto Networks acquired Twistlock container security to incorporate it into their Prisma Cloud suite. In essence this tool offers both Cloud Security Posture Management as well as Cloud Workload Protection for nearly every compute option in the cloud plus in your own data-center.
Besides these, the list of tools and vendors which offer similar solutions is pretty long: McAfee, AtomiCorp, Juniper, Rapid7 and TrendMicro to name a few.
Microsoft Azure
Since Azure is the only cloud service provider that offers some kind of workload protection, it’s important to note that Microsoft now offers “Microsoft Defender for cloud”. Previously, this single service consisted of two independent services: Azure Security Center and Azure Defender. Microsoft Defender has a very broad scope: it does not only protect running containers, container registries and Kubernetes clusters, but it can also detect security issues in storage accounts. Surprisingly it cannot protect containers that are build using Windows based images: these are not supported (yet). The same is true for distroless and super-minimalist images such as Docker scratch. Furthermore, the Open Container Initiative (OCI) image format is also not supported yet. Once these features are implemented, you have a pure cloud native service that offers Cloud Workload Protection for all of your containers that integrates perfectly with your other cloud native services.
Practical examples
To make this topic a bit more practical, the following example use cases help to get a better understanding of what Cloud Workload Protection consists of.
Common Container Threat Detection detectors identify the following threats:
Reverse shell
Exploits using reverse shells: the CWPP detects malicious connections to remote controlled machines. An attackers uses this external machine to control the original workload to execute unwanted commands.
Malicious scripts
Execution of malicious scripts should be prevented all the times. Bash scripts which were injected into in running container AFTER it has been started can be harmful if the owner is not aware of it. Therefore, most Cloud Workload Protection Platforms generate a “model” of the container image which is used to run the container. When a malicious script is added and executed, it raises an alarm.
Sensitive filesystems
Mounting a sensitive filesystem inside a container should not be allowed. Suppose a container mounts the /etc filesystem in read-write mode, various sensitive configuration files of the underlying host can be read. Or what about mounting the /home/user/.docker directory that contains docker.json? Among other information, this file contains the username & password for the (private) docker registries you have successfully logged in into. They are not encrypted, but encoded using base64, it’s extremely easy to decode it and misuse these login details. For example to build a poisonous container image, tag it with the same name as your trusted images and push it out to your trusted registry. Here, also signing has a place to prevent issues like these.
Immutability
A container should be immutable as it’s being rebuild every time something is changed. When adding an extra library (whether it be on the Operating System level or the application level), the signature of the image is changed and this should be prevented. This also applies for any extra added binary. The reverse is also possible: remove a binary for example that generates log files for auditing reasons. When this is the case, an attacker tries to hide it’s traces and discovery of the threat becomes much harder.
Isolation
Runtime protection also helps to make sure containers run in an isolated environment. For example to make sure they do not have access to the processes of the underlying hosts on which they run. It’s best to group containers which belong to the same application in a single (overlay) network. And not all containers need to communicate to the outside world. Cloud Workload Protection needs to check for these kind of issues and trigger alerts to notify SOC team.
Containers come and go on the fly as well as other container related assets such as volumes, network and storage drivers, networks, secrets, etc. To keep an eye on all of these components, micro-segmentation is a key issue in Cloud Workload Protection. Almost all tools support this.
Considerations
Before you decide that you require a Cloud Workload Protection Platform, keep the following aspects in mind.
Know the scope of CWP
Cloud Workload Protection Platforms only protect workloads on-premises or in the cloud. Those platforms do not handle cloud configuration which trigger the deployment of insecure cloud native services. For example, it’s still possible to deploy data storage solutions that are not encrypted or Virtual Machines that have their SSH port open to the entire world. Besides this limitation, Cloud Workload Protection Platforms also do not handle identity and access management for cloud environments. You require a separate CIEM (Cloud Infrastructure Entitlement Management) process to handle this topic. These aspects of cloud security can’t be forgotten and complement each other.
Detect zero day exploits
Very recently, the log4j zero day vulnerability has been detected and caused a storm of panic across the world. Plenty of weekends were ruined and the Monday afterwards was hectic too.
System operators AND development teams were forced to patch their Java logging packages across all applications and other runtime environments that use this fundamental building block. A Cloud Workload Protection Platform scans for vulnerabilities all the time. If it also supports zero day exploits, you would get a security alert with the highest severity. This applies for Virtual Machines that use the Java runtime environment including the log4j dependency as well as containers which inject it into their source code base. But don’t forget serverless functions based on Java which override the default logging method that AWS Lambda offers.
Quality matters
With these examples in mind, it is critical to connect to a very sophisticated database that gathers all kind of security related configuration, security standards such as NIST, CIS, HIPPA and recent CVEs. Those databases run behind the scenes of the above-mentioned tools and are controlled and maintained by the tool vendor. Since this is a proprietary component of the vendor, you don’t get much information about it. This is especially true since dedicated security researchers work behind the scenes to collect, analyze and classify this information. Often, Machine Learning is part of the initial classification process, but it still requires a lot of work to get the right contents. It is often possible to see which security sources form the contents of the database, be sure to check this out for each and every supplier you might select.
Wrap up / Conclusion
Given the number of security breaches in the cloud, it’s vital to monitor and secure the compute workloads you run. Cloud Security Posture Management helps in the first phases of CI, where Cloud Workload Protection (Platforms) help to monitor and detect problems for running Virtual Machines, Containers and Serverless based “compute services”. As of today, a lot of specialized tools do a good job protecting your applications. This article helped to shed some light on the options they offer to help you make an informed decision.
