Ransomware exacts a huge toll on organizations, and the average successful attack costs an enterprise nearly $4.5 million to remediate. Ransomware will likely continue to rise and sap the global economy of billions of dollars in value over the next few years.
Attacks are up, and ransomware payouts continue escalating. Among the most likely victims are public-facing institutions such as universities, hospitals and government offices. This is likely because mission-critical agencies have the most to lose and are less likely to have invested in keeping their countermeasures up to date.
If anything, these high costs are under-reported because most companies don’t want to admit they were hit by ransomware or paid a ransom, lest more attackers learn they are an easy target.
Source: Adobe Image Create
Like getting a stubbed toe, it would be easier for most to limp away like nothing happened. Indeed, one bad toe would be tolerable if the business didn’t have to perform at a professional athlete’s level of agility, and every step could cause immense pain and poor performance.
Since most companies turn to Kubernetes and cloud native applications to gain agility with fast deployment speeds and scalable performance, it’s easy to predict their IT security teams will be stress-testing every cloud native connection for ransomware.
Of the organizations surveyed for the Veeam 2023 Data Protection Trends Report, 85% said they experienced a cyberattack in the prior 12 months. These attacks are not limited to legacy systems either. Kubernetes is increasingly a target for malware attacks, including ransomware.
In all these scenarios, it’s critical to have an immutable backup and a disaster-recovery strategy in place, so business can quickly return to normal operations if an attack hits home. What are some of the novel forms of cloud native ransomware attack patterns to look out for?
Open Source and Stack Concerns
Kubernetes is an open source software project, as are its underpinning control plane, scaling, security, data management and other components (the Cloud Native Landscape gives the big picture).
By the time a project like Kubernetes is approved for graduation and made available for download by the CNCF, it is battle-hardened and thoroughly tested. In addition, it has several software vendors and cloud platform providers offering supported enterprise and managed service versions.
That doesn’t mean there’s a commonly agreed-upon, ideal way to configure, deploy, manage and protect Kubernetes clusters and its underlying container images and components.
The open source community has excellent white-hat contributors working to resolve common vulnerabilities and exposures (CVEs) — usually as a part-time endeavor. While they do a great job at tracking down solutions, they’ll never be able to move as fast as the black-hat ransomware community, which also has access to the full open source code and plenty of time to experiment on the next zero-day exploit.
Further, due to the complexity of setting up a complete Kubernetes-based application stack, many developers download tools, config recipes, components and example code to move their work along. There is no way to be sure that the thousands or millions of downloadable items in even well-run libraries and repositories aren’t compromised with malicious code or malware.
The Supply Chain Replication Crisis
In some ways, a monolithic stack is far easier to protect at its boundary. And, in the worst-case scenario of a doomsday encryption attack, data is technically easier to recover from a physical backup.
Vulnerabilities spread within fully automated Infrastructure as Code (IaC) configuration and deployment workflows, and since potentially outdated or suspect packages can be horizontally scaled across cloud environments, the stakes are much higher.
Kubernetes still has some security advantages. Dynamic namespaces, secrets management and the seemingly stateless nature of microservices workloads that spin up and disappear when finished can make it harder for attackers to find handholds in some cases.
Unfortunately, when a Kubernetes-based application replicates its work across hundreds or thousands of clusters, it is no less susceptible to ransomware than good old network-fenced on-premises servers, virtual machines (VMs) and their attached storage resources.
Kirsten Newcomer, director of cloud and DevSecOps strategy at Red Hat, shares one refreshing playbook for evading supply chain problems:
“Quite a few customers have automated their OpenShift deployments so that they can (and do) redeploy from scratch on a regular basis. That might be every six weeks or every three months. Of course, containerized apps also need to be redeployed. However, managing everything this way minimizes what you need to back up. Just retain stateful data for your apps. You don’t need to back up, etc.”
“Of course, you have to secure access to the repositories where you store your playbooks (or Terraform files) and config files. Also your container repo for your images. And, ideally, you would sign all such files so you can verify their integrity.”
Permissioning Problems
Permissions are as much a practice problem as a technology problem.
Companies explicitly move to Kubernetes because they want to move quickly. In doing so, they create extensive libraries of application, infrastructure and deployment code. To accompany all of this automation and architecture, you need to decide exactly who (or what) can have access.
One of the hardest aspects of achieving full deployment automation is setting up access and identity management (AIM) rules, which are complex enough when you’re dealing with just session tokens and user access policies.
In Kubernetes environments, most signals and messages are machines talking to machines. Operators lose sight of the statefulness of user sessions, as API calls and data get passed among ephemeral, possibly widely distributed microservices that each perform their own functions as workloads. Since the location where the physical implementation lives is no longer relevant, authorization rules are usually custom-built.
AIM provides the most common vector for hackers, as virtually every ransomware attack involves a scan for inconsistent permissions and then an escalation of privileges, as happened in the recent Siloscape remote code execution exploit for Windows containers.
To put a lid on permissions, try implementing consistent, highly granular role-based access control (RBAC) and attribute-based access control (ABAC) policies, with the guiding principles of least-privilege access and zero trust models limiting unauthorized and even unexpected types of activity.
When AI Assists Attackers
Artificial intelligence (AI) chatbots are very good at personalization, and through researching business communication, they understand how to interface with humans and business systems. Thanks to readily available conversational AI and a chatbot’s moral ambiguity, bad actors now have the perfect cybernetic partner in crime.
Scarily, even unskilled script kiddies can use ChatGPT or other AI-based automation routines to write malware code and adapt and run sophisticated attacks, once trained using a universe of existing code and shell scripts found on the Dark Web.
With machine learning, bad bots are only getting smarter at social engineering. They can write up a convincing phishing email or chat dialogue based on past tech support and customer service conversations that can fool employees and effectively social engineer their way into an account or get someone to download an item that grabs network privileges to deliver payloads.
Worst of all, there’s almost zero human effort or incremental cost to bots constantly scanning for exploits and hammering away with automated attacks, so expect their frequency to multiply exponentially.
Immutable Backups Are the Best Insurance
In the face of so many ways to exploit critical cloud native data, the best insurance policy is a proactive approach to generating regular backups that are immutable — meaning they cannot be erased, encrypted or changed, no matter what an attacker tries to do on the network.
Kasten by Veeam offers a backup solution built specifically for Kubernetes-based application data, providing both immutable backups and automatic, policy-driven creation of those backups.
As more of the global digital backbone is supported by cloud native development, companies will continue to rush to deliver new application functionality and data services to market. At this rate of change, it’s inevitable that some innovative ransomware attacks will be missed and Kubernetes deployments will get hit where they hurt.
Still, there’s no point in supporting ransomware peddlers by paying them off. These days, some bad actors aren’t even bothering to encrypt data, since no one should believe a hacker will clean up the mess they leave behind. Cybercriminals are instead extorting second or third payments to not destroy impacted data or infrastructure.
The best way to protect your critical systems and data and prevent deadly downtime? Assume a novel ransomware attack is likely to happen tomorrow, and always have strong, immutability-based backup and disaster recovery in place to maximize your chances of successful data recovery.
The post Managing Ransomware Threats in Kubernetes-Based Applications appeared first on The New Stack.
Kubernetes is an increasingly common ransomware target, but immutable backups are the best antidote for attacks on cloud native infrastructure.