Cloud workload security platforms operate like SIEM systems. The tools watch over the activity of cloud workloads and look for sudden changes in behavior. Several other defense strategies qualify as cloud workload security. The truth is that cloud workload security is a new field and there isn’t one standard strategy to implement it.
What is a cloud workload?
“Workload” is a general term that encompasses all software that doesn’t run on a site but is hosted on a cloud server. As such, this includes the software that makes up the platform itself. So, it includes systems such as the operating system of the virtual server and the virtualization packages that segment server space to prevent cross-account movements.
The systems that allocate processors to the tasks required by a particular account are also regarded as workloads as are the software packages that those processors run.
Many cloud-based services are workloads. Examples of these include Microsoft 365 elements and email servers. Cloud-based edge services, such as DDoS protection systems, Firewall as a Service products, and load balancers are also workloads.
Even the services that implement cloud workload security are themselves workloads.
Why is cloud workload security important?
Until recently, a typical business system was created by a network that connects endpoints, such as servers and desktop computers. Hackers have developed a range of strategies to intrude into IT systems either manually or through malicious software called malware.
Systems administrators know that they need to protect their assets with firewalls and antimalware packages. Hackers can sometimes still get past these defenses and so intrusion detection systems and Security Information and Event Management (SIEM) tools are needed. Cloud workload security fulfills the tasks that antimalware, firewalls, IDSs, and SIEMs offer for on-site systems, only for cloud-based assets.
No business would leave its endpoints without antimalware and firewall protection and, increasingly, SIEM systems are considered essential. Now that cloud computing is becoming more widespread, it is obvious that the same level of protection is needed for those systems. This is where cloud workload security systems come in.
Microservices and offloading
Everyone knows that you should watch over activity on a server where applications and services run. However, today, many Web applications are built from pre-written services. These supplied systems are embedded in development environments or supplied by function libraries or APIs. You don’t know where the functions behind those systems actually run and so you can’t monitor the server that hosts them.
The processors in mobile devices are powerful. However, they use a lot of power if they are run at anywhere near full capacity. This situation can make a mobile app unpopular because users hate having to recharge their smartphones and tablets. To get around this problem, mobile app developers have come up with the strategy of offloading. This means that the app does hardly any work on the device on which it is installed. All the app does is operate as an interface to the real application that runs on the cloud.
The need to offload processing has caused a boom in the supply of handy utilities. These services are also commonly used in the creation of websites and cloud-based Software-as-a-Service systems. The modules that run behind these APIs and offloaded functions are known as microservices. They are also known as serverless systems. That term is a little misleading because they are hosted on servers. However, the cloud platforms that host them run those modules without the owners needing to subscribe to a virtual server package.
As these offloaded systems and microservices provide functions for SaaS systems, you don’t need to be a Web application developer to encounter them. Most of the software services that your company uses by subscribing to SaaS packages include these microservices.
Many services are now built on containers. This technology bundles an operating system in with the software that the package supports. These systems are meant to be resilient against hackers because they can’t be broken into. However, that also means that they can’t be examined internally by a security monitoring system.
Detecting workload activity
We can now list microservices, containers, APIs, development frameworks, cloud platforms, cloud-resident services, and SaaS packages as workloads and you need to find a tool to discover all of the interlinked modules that create Web applications and mobile apps.
Services that implement the work of tracking all of the contributing workloads to the system that you know about are called distributed tracing packages. These systems run a base application as a starting point – the application that you know about. It then traces the components that lie behind each called-in function. It can then scan for other components, ultimately building up an application dependency map. That map includes all of the services that contribute to the application, not just microservices. This means systems such as databases.
Once all of the backend modules for an application have been mapped, distributed tracing systems attempt to follow their execution. This is performed with a method called telemetry. This is a process that runs alongside the modules and picks up the log messages that they output. Several open standards lay out how these messages can be formatted within a program and how a monitor can capture them.
The most widely used standard for telemetry is called OpenTelemetry. You can read more about the use of telemetry for system monitoring in my guide, The Best Distributed Tracing Tools.
Security monitoring for workloads
A big problem that cloud workload security systems face is that not all Web application developers implement the telemetry messaging methodology. Hacker code certainly won’t include debugging or progress messages. So, while distributed tracing is one technology used by cloud workload security platforms, it isn’t the only method that they deploy.
Cloud workload security platforms can be seen as very similar to SIEM systems. Cloud-based SIEM systems are available but these rarely drill down through layers of services to discover backend microservices. Many cloud workload security platforms use the same monitoring methods that SIEMs use – once all contributing modules have been traced. This method is baselining and anomaly detection.
Anomaly detection relies on behavior analytics. This tracks the behavior of software over time. There might be many different conditions that alter the way each unit behaves. However, these variations could be legitimate. Once the monitor has recorded standard behavior, it is prepared to spot differences from that standard.
Early in operations, a machine learning system might be over-active – alerting for activities that are not malicious. However, this is part of the learning process and each time that a problem is reported, your feedback adjusts the record of standard behavior and that type of activity will not be flagged again. Once the anomaly detection system has bedded in, you can leave it to watch over cloud workloads and the tool will notify you by email or SMS when a problem is detected.
Zero trust protection
Zero trust systems are new solutions to the problem of securing cloud workloads. These systems address the problem that just monitoring activity on a server is no longer a valid strategy.
A zero-trust system secures an application rather than an infrastructure resource. The logic behind this protection method is that access to each application is controlled and so outsiders and malicious software cannot get into the workload or chains of workloads.
Zero trust systems enforce security through the use of VPNs. This protects the data exchanges, shared variable values, and data cohesion that passes between contributing and interdependent microservices.
The method of zero trust protection doesn’t block insider threats or account takeover. Thus, zero-trust security is usually paired with anomaly detection systems.
Extended Berkely Packet Filtering (eBPF)
eBPF is another technique that some cloud workload security platforms use. This methodology can also be used for testing in CI/CD pipelines. Some cloud workload security systems are marketed for DevOps testing as well as for operations monitoring.
The eBPF system offers two strategies. This is a way to trace the calls that programs make out to external services. Those calls could also be to other modules. Thus, eBPF is a method that can be used for discovery and application dependency mapping.
The eBPF system is a sandboxing tool. So, security packages can run Web applications safely for the first time without the risk that any malware triggered by that software could attack the test environment. This technology allows a security platform to preview an application, catch all of the systems that it depends upon, crawl onto each of those supporting modules, in turn, run them, and then discover the next dependency layer down.
An eBPF strategy can also be used to run through all use case scenarios and preview the behavior of the module in each case. This can be a fast-track way to let an anomaly detection system learn a baseline for normal behavior.
Using cloud workload security platforms
When choosing a cloud workload security platform, you will read of combinations of the techniques outlined here above. Ultimately, you don’t specifically need to know all of the nuts and bolts of each package. What you need is an assurance that the package that you choose will protect your cloud workloads and notify you of any attempts to hijack their functions.
You can start your investigation into this cloud protection technology by reading our report on the The Best Cloud Workload Security Platforms.
