Why Containers are Susceptible to Ransomware

No application is safe from ransomware. In 2022, IDC conducted a study to understand the evolving requirements for ransomware and disaster recovery preparation. This study uncovered a demand for data that has never been greater, and yet the vulnerability and risks to data integrity are escalating, with ransomware attacks growing in both severity and scale. The IDC study found that 79% of those surveyed activated a disaster response, 83% experienced data corruption from an attack, and nearly 60% experienced unrecoverable data.

This vulnerability is particularly alarming for organizations that are refactoring their applications for Kubernetes and containers. “Refactoring” an application means breaking it down into many different “services” which can be deployed and operated independently. This breakdown allows for a more efficient use of the application’s underlying hardware and increases scalability, as each “service” making up the app can scale as necessary without interrupting other services. While the benefits may seem great in theory, refactored applications must first overcome unexpected challenges.

Challenges with Refactoring Applications

Another IDC study that examined container adoption highlights this issue. The study shows that most containerized applications are refactored legacy applications, meaning they are already operational on either a bare-metal server or a virtual machine. Refactoring for containerized environments has proven to be complex, and the most-cited challenge was adapting existing processes to support the newly containerized applications. There’s a gap between the perceived benefits of containerization and the realization of those benefits. Those adopting containers expect improved security and operational efficiency, but they have quickly realized that data protection and security concerns are the biggest challenges after they refactor their applications to operate, usually using Kubernetes and containers.

Ensuring containerized applications are protected against ransomware, malware, and other security threats will have the most impact on repatriation (or reverting to how the application was running before). Those responsible for refactoring applications should specifically address the top container security risks by either working with native features or seeking integrations with a data protection solution that helps address these concerns.

Here are a couple of examples of Kubernetes vulnerabilities which can act as entry points to malicious actors:

• Pods are an integral part of Kubernetes deployments, as they host the containers running each application process. Inter-Pod communications run the risk of being attacked. In Kubernetes, each Pod has an IP address. A Pod can communicate with another Pod by directly addressing its IP address, but the recommended way is to use Services. A Service is a set of Pods, which can be reached by a single, fixed DNS name or IP address. Most applications on Kubernetes use Services to communicate with each other, which can expose access to the Pod or, since they are frequently restarted, creates a networking issue within the cluster.
• Supply Chain Attacks – containerized applications are designed to be automated, and this is true especially for updating code. Some Kubernetes deployments may be coded to keep pulling the “latest” Pod of an application without checking what updates were made or possible vulnerabilities exposed.

Heightening these known vulnerabilities is a skills and knowledge shortage of those who develop and deploy production applications with containers. An application lacking data protection and security as part of developer workflows leaves containerized applications susceptible to a myriad of vulnerabilities ransomware could exploit. To help mitigate against ransomware attacks, organizations need to not only carefully identify which applications should be refactored but consider the integration of data protection solutions early on. Developers should integrate data protection into their workflows, layering inherent security and recoverability into the application.

The IDC study indicates that organizations refactoring legacy applications to containerized ones are encountering a couple of other challenges. Legacy data protection won’t work with newly containerized apps without some heavy adjustments, but many related processes, such as analytics and security, also need to be modified. These efforts seem futile. Most concerning is that over half of respondents plan on reverting most of what they already containerized. This means undoing work, wasting both time and money. It’s interesting that the most likely candidates for repatriation are databases and other critical workloads, making the effort particularly painful because there is a strong connection between security concerns and criticality of these containerized applications.

=> If you want to read more about the State of Ransomware for Kubernetes, check out the IDC whitepaper The State of Ransomware and Disaster Preparedness.

Protect Your Containerized Applications and Clusters with HPE GreenLake for Backup and Recovery

HPE GreenLake for Backup and Recovery is a hybrid cloud-based backup solution that can protect containerized apps and clusters running on Amazon Elastic Kubernetes Service (EKS). It can also protect on-premises and cloud native workloads, including VMware VMs, Microsoft SQL databases, and Amazon EBS, EC2, EKS, and RDS.

Amazon EKS Components Protected by HPE GreenLake for Backup and Recovery

The following is a list of all the supported components of Amazon EKS that HPE Backup and Recovery can help you protect:

1. Inventory sync & refresh of EKS Clusters (versions 1.25 & above) and applications in a customer’s account
2. Listing of AWS EKS Clusters in a customer’s account
3. Listing of AWS Applications within an EKS Cluster in a customer’s account
4. Register/Unregister an AWS EKS Cluster to enable protection
5. Support deletion of inventory contents when the corresponding backups are deleted or when Account is unregistered
6. On demand and Policy driven protection of EKS applications
   1. Native & Cloud backup of EKS Applications
   2. Backup of PVCs backed by EBS CSI Storage Class only
   3. Restore of native and cloud backups to a new namespace

Amazon EKS Kubernetes Resources Backed Up by  HPE GreenLake for Backup and Recovery

More specifically, here is a list of the supported Kubernetes resources that users can backup (Namespaces and Cluster-wide).

HPE GreenLake Backup and Recovery can be a great solution to protect your containerized applications running on Amazon EKS. To learn more,  watch this demo video to see it in action.

Anthony Dutra