How to Secure Cloud Non-Native Workloads

This blog was originally published by Intezer here.

Not All Applications are Cloud-Native

Companies are adopting cloud at a faster pace but not all applications are born cloud-native. Many traditional applications are simply “lifted and shifted” to the cloud as a first step in the cloud transformation journey.

Such deployments often use monolithic architectures, where all of the application components are packed in one or two servers. They aren’t refactored to use the scale of the cloud or to leverage modern PaaS solutions and microservices.

Your cloud security strategy should be adaptable to cloud non-native workloads and cloud-native ones. We’ll look at the differences between securing them and also dive into key considerations to protect traditional cloud non-native workloads.

Traditional Workloads in the Cloud

While you can find a number of advanced cloud-native services, legacy applications can’t always take advantage of them. Because they aren’t designed with cloud integration in mind, legacy applications often start their digital transformation by being deployed to the cloud as is. There are many reasons for this.

There’s a lot of complexity in refactoring an application for the cloud when its components have been designed to be deployed as single units in a machine. The time and effort required for the change could offset the benefits of a cloud migration. That’s why organizations tend to stick to a safer, “if it ain’t broke, don’t fix it” approach.

When organizations are finally ready—or forced—to migrate to the cloud, hosting in virtual machines is usually the easiest option. Thus applications will continue to have the traditional monolithic design, even though they’re deployed in the cloud.

In order to reap the full benefits of the cloud, organizations should strive for cloud-native applications as a long-term strategy; the only exception being applications where transformation isn’t possible due to legacy code dependencies. This process can even start after the initial migration/deployment to the cloud.

Here are a few steps to help you initiate that process:

• Start small by decoupling components in a monolithic application one by one. You can then transition them to modern cloud services like PaaS, DBaaS, and containers.
• A well-defined security strategy is your most important part of the journey. This strategy should cover all relevant controls for securing your workloads in the cloud, whether they’re cloud-native or not.
• A relentless focus on reducing the attack surface, detecting and responding to breaches, and constant visibility are all imperative for protecting your non-native cloud workloads. This is also true of cloud-native applications, though the implementation process and tools would be different.

Secure Your Traditional Workloads in the Cloud

In addition to its many benefits, the cloud also brings with it advanced threat vectors. Luckily, tools are already available in the cloud to up your runtime threat detection game with very little configuration overhead.

Security for IaaS Workloads

In the Infrastructure-as-a-Service (IaaS) model, the workloads are deployed in VMs and connected to cloud networks. While network layer security through microsegmentation, application layer firewalls, and DDoS protection are all relevant here, they don’t protect you from every threat.

Runtime security provides full visibility to your workloads hosted in VMs. Pre-runtime vulnerability scanning alone is not enough to prevent unauthorized or malicious code from being executed during runtime. Not all vulnerabilities are known. On top of that, operating systems and third parties have their own vulnerabilities, and ultimately not all vulnerabilities have a fix. This means you can’t eliminate all software vulnerabilities.

Detecting and responding to attacks while they happen in runtime is therefore essential to protect your workloads.

Integrate with Deployment Process

Security best practices and guidelines should be a part of your code deployment process for both application and infrastructure through Infrastructure as Code (IaC).

It would be clumsy to make security-related configuration changes after deployment, especially for large-scale deployments. Adopt a security-as-code approach to implement an IaaS deployment of cloud non-native workloads.

While securing your code helps, you should also leverage a Cloud Workload Protection Platform (CWPP) to protect your workloads against vulnerable third party plugins, Living off the Land (LotL) attacks and other threats.

Focus on the Code Along with the Infrastructure

Security guardrails for your infrastructure do not protect you from unauthorized code execution. Attackers are now targeting legitimate software and distribution channels to inject malicious code.

The SolarWinds supply chain attack is an example of this. Attackers leveraged the software’s update channel to evade detection and launch their attack. That’s why securing your own code with code scanning processes is simply not good enough.

Adopting an “assume-breach” strategy will better position you to respond to actual attacks by ensuring code accountability and full runtime visibility. This way you’ll know what applications are running at all times. Integrate solutions that detect unauthorized code in real time in agile and fast-scaling cloud deployments.

Cloud Non-Native Container Security

If your workloads are already containerized, you can choose from managed container orchestration services in the cloud or deploy your own container management solutions. This would again follow a lift-and-shift approach with minimal changes. An example of this would be using the same images as on-premises and deploying them in a cloud container platform.

As with Linux systems, the attacks on containerized workloads have also evolved, as demonstrated by the Doki malware that targets containers in the cloud.

Your containerized workloads need layered, in-depth protection. As part of updating your security strategy, you should integrate practices like container image scanning, threat monitoring, and container configuration monitoring to eliminate security loopholes. Tools can also ensure end-to-end protection by monitoring the container runtime and the container orchestration platform for unauthorized code execution.

Conclusion

Not all applications are designed and built for the cloud, but they may still end up on your digital transformation charter. You’ll want to make sure your long-term cloud strategy is able to accommodate such cloud non-native workloads and to ensure airtight security.

Enabling network-level protection and integrating security baselines into the code can help to an extent. But your focus should also be on runtime protection through in-memory threat detection and prevention of unauthorized code execution.