The Dark Side of Microservices: How to Protect Your Data from Breach Attacks

Hello and welcome back to my blog series on the dark side of microservices. In the previous blog we discussed the challenges that microservices architecture presents for protecting applications. In this blog, I will explore one of the most serious threats that microservices face: data breach attacks.

Data breach attacks are malicious attempts to access, steal, or compromise sensitive data from an organization or its customers. Data breaches can have devastating consequences for both the victims and the perpetrators, such as financial losses, reputational damage, legal liabilities, and regulatory fines.

The 2022 Cost of a Data Breach Report by IBM Security and Ponemon Institute revealed that the average cost of one data breach globally was $4.24 million, the highest in the 17-year history of the report. The report also showed that data breaches involving cloud-based services increased by 18% compared to the previous year, and that 48% of data breaches were caused by malicious attacks.

How do data breach attacks happen in a microservices environment? And what can you do to prevent them? In this blog post, we will examine the data breach attack cyber kill chain and the threat surface in a microservices architecture.

Attack Kill Chain & Threat Surface

The attack kill chain is a model that describes the phases of a cyberattack, from reconnaissance to exfiltration. It can help us understand the attacker’s goals and methods and identify the weak points in our defenses. The attack kill chain for data breach attacks in a microservices environment can be simplified into three stages: penetration, lateral movement, and strike.

Penetration is when the attacker gains initial access to the target system or network. Lateral movement is when the attacker explores and exploits the internal environment to reach their desired destination. Strike is when the attacker executes their final malicious action, such as exfiltrating data, encrypting files, or destroying systems.

The threat surface of microservices is the sum of all the possible attack vectors that an attacker can use to penetrate, move laterally, or strike in a microservices architecture. The threat surface of microservices is much larger and more dynamic than that of monolithic applications.

Penetration

Microservices are small, independent components that work together to form an application. However, having too many microservices can also pose security risks. An average application may have dozens of microservices, while a large one may have hundreds. This creates many potential points of attack that increase the vulnerability of the application, such as:

Application vulnerabilities: Microservices are composed of multiple independent components that communicate via APIs. Each component may have its own vulnerabilities that can be exploited by attackers, such as injection flaws, broken authentication, or insecure deserialization. Moreover, microservices often rely on external libraries or frameworks that may introduce additional vulnerabilities or dependencies.

3rd party code: Microservices often use 3rd party code or services to provide functionality or integration with other systems. For example, microservices may use cloud providers, open-source projects, or commercial vendors to host their infrastructure, store their data, or perform certain tasks. However, 3rd party code or services may also pose security risks if they are not properly vetted, configured, or updated. Attackers may compromise 3rd party code or services to gain access to microservices or their data. The Log4J attack, which occurred in 2021, is a well-known example of such an attack vector.

DevOps 3rd party tools: Microservices adopt DevOps practices and tools to enable continuous integration and delivery (CI/CD) of their code. DevOps tools help automate and streamline the development, testing, deployment, and monitoring of microservices. However, DevOps tools may also become targets or entry points for attackers if they are not secured or monitored. Attackers may exploit vulnerabilities in DevOps tools or hijack their credentials to manipulate or compromise microservices or their data. The SolarWinds attack that occurred in 2020 is a prime example of this type of attack vector.

CI/CD pipeline: Microservices use CI/CD pipelines to deliver their code from development to production in a fast and reliable way. CI/CD pipelines consist of multiple stages and steps that perform various actions on the code, such as building, testing, scanning, deploying, and verifying. However, CI/CD pipelines may also introduce security risks if they are not designed or implemented with security in mind. Attackers may tamper with the code or its artifacts at any stage of the pipeline to inject malicious code or alter its behavior. The Codecov breach that occurred in 2021 exemplifies this type of attack vector.

Social engineering: Microservices involve multiple teams and stakeholders that collaborate and communicate across different domains and boundaries. For example, microservices may involve developers, testers, operators, managers, customers, partners, and regulators. However, human factors may also be exploited by attackers to gain access or information from microservices or their data. Attackers may use social engineering techniques such as phishing, baiting, or impersonation to trick or persuade people into revealing credentials, clicking links, or downloading files.

Lateral Movement

Microservice architecture consists of many microservices that communicate with each other through numerous connections. This means that a single external request can trigger six internal requests among the microservices on average. Most of the traffic uses standard ports like HTTP via port 80. Since 86% of the attacks exploit standard ports, malware can easily propagate among the microservices until it reaches your “crown jewels” the most sensitive data of the application. This is why attackers can take months to strike after infiltrating the system, as they want to maximize their profit and access as much sensitive data as possible. This creates the following attack vectors:

Low internal traffic visibility: The attacker can take advantage of the lack of visibility and monitoring of the internal traffic between your microservices. The attacker can then perform reconnaissance activities, such as scanning ports, enumerating services, or discovering dependencies.

Misconfiguration leads to access rights: The attacker can exploit misconfigurations in your microservices architecture, such as weak encryption, default credentials, or excessive permissions. The attacker can then gain access rights to other microservices or resources that store or process sensitive data.

Unrestricted API calls: The attacker can abuse the API calls that your microservices use to communicate with each other or with external services. The attacker can then perform unauthorized actions, such as reading or modifying data, invoking functions, or triggering events.

Multiple entry points to sensitive data: The attacker can leverage the multiple entry points that your microservices architecture provides to access sensitive data. For example, the attacker can access the same data from different microservices that have different security levels or controls.

Certainly, every application has its own set of “crown jewels” that attackers are after. The complex nature of microservices architecture creates multiple attack vectors that make it easier for hackers to breach the application and eventually reach its most valuable data. Despite the alarming increase in data breach attacks year after year, the existing industry solutions are not keeping pace. In my next blog, I will discuss the limitations of current solutions and how Radware KWAAP can protect your crown jewels against potential security threats.

Until then, stay informed, stay safe and contact us to get more information about Radware’s application protection for Kubernetes.