The Dark Side of Microservices: How to Brighten it With Next Gen WAAP
Hello and welcome back to my blog series on the dark side of microservices. In the previous blog, we delved into the intricate web of microservices architecture and how it gives rise to challenges in safeguarding applications. We explored the concept of the Cyber Kill Chain attack and examined the expanding threat surface that requires comprehensive security solutions. As we journey deeper into the realm of microservices security, we now turn our attention to the limitations of current security measures and what the next gen Web and API protection (WAAP) shall provide and support.
Let’s explore 2 of the most popular protection approaches: perimeter protection and micro segmentation.
Perimeter Protection: In the context of monolithic architecture, Web Application Firewalls (WAFs) stand as robust guardians, effectively filtering and monitoring incoming network traffic to thwart well-known attack patterns. Their reliability is evident in safeguarding against established threats within this traditional structure. However, as we transition to the intricate landscape of microservices architecture, the limitations of traditional WAFs become more pronounced. While they continue to offer valuable protection at the perimeter, their effectiveness diminishes in the face of rapidly evolving attack vectors unique to the dynamic microservices environment, such as third-party code, DevOps tools, and the CI/CD pipeline. This exposes applications to data breach risks, enabling attacks via concealed malicious code within third-party elements or infiltrating through DevOps tools. Moreover, the complexities of inter-microservice communication and the decentralized nature of microservices expose potential blind spots in traditional perimeter defense, necessitating a more adaptable and comprehensive security approach to adequately address the evolving threat landscape.
Micro segmentation: Micro segmentation, a promising security strategy within microservices, involves partitioning an application’s infrastructure into isolated segments, each meant to operate independently. This technique, controlling communication flows between segments, aims to curtail lateral threat movement, reducing potential attack exposure.
However, there are several limitations that micro segmentation cannot address, such as:
Application-Level Vulnerabilities: Micro segmentation does not address the application-level vulnerabilities or misconfigurations that may exist in the microservices, which means that an attacker can exploit them to compromise the application logic or data such as mass assignment. Mass assignment is a vulnerability that allows an attacker to modify or overwrite any attribute of an object by sending a request with a large number of parameters. For example, an attacker can change the role or password of a user by sending a request with those parameters. Micro segmentation cannot prevent such attacks, as it only controls the network layer, not the application layer.
Dynamic Nature of Microservices: Micro segmentation is hard to follow the rapid changes nature of microservices architecture and update frequently the policies. Microservices architecture is dynamic and agile, which means that services can be added, removed, or updated frequently. This requires constant monitoring and updating of the micro segmentation policies, which can be challenging and error prone. If the policies are not updated correctly, they can either block legitimate traffic or allow unauthorized traffic.
Concealed Attacks: Attackers can use legitimate traffic connections between segments and standard protocols to hide their attack. For example, an attacker can compromise a service that has access to a database and use it to exfiltrate sensitive data or execute malicious commands. Micro segmentation cannot detect or prevent such attacks, as they appear as normal traffic.
Lateral Movement Within Segments: Micro segmentation does not prevent lateral movement within a segment or zone, which means that an attacker who compromises one microservice can still access other microservices in the same segment.
After examining the challenges and gaps encountered by perimeter protection and micro segmentation in safeguarding application with microservices architecture, let us now outline the essential features and support that a next-generation Web Application and API Protection (WAAP) solution should encompass to effectively secure applications within a microservices architecture.
Advanced security capabilities
To protect applications in microservices architecture, the next generation of WAAP needs more than just the standard security capabilities, such as full OWASP web and API top 10 coverage and RFC and schema enforcement. It also needs to inspect and enforce service to service protocols, such as gRPC, and service to service authentication, based on advanced authentication tokens like JWT (JSON Web Token). Moreover, it needs to treat services as potential bad actors and identify them not only by IP, but also by other parameters like service id. Finally, it needs to have a deep understanding of the microservice context and behavior, especially when protecting the “Crown Jewel” microservices.
Flexible Deployment Options for Varied Contexts
This evolved WAAP version is designed to seamlessly fit into different deployment scenarios. It adapts to both North-South (N-S) and East-West (E-W) protection strategies. It can be stationed at the application perimeter to safeguard the entire incoming traffic, it can also be integrated within the microservices landscape close to “Crown Jewels”, providing context-specific protection. Its compatibility with service-mesh architectures allows it to operate effectively in dynamic microservices environments, ensuring consistent security coverage. The WAAP should be able to integrate with various load balancers, ingress controllers, service meshes, and cloud platforms.
Kubernetes-Native Design for Modern Environments
With the rise of Kubernetes as the de facto standard for container orchestration a Kubernetes-native WAAP (Web Application and API Protection) solution offers significant advantages due to its alignment with Kubernetes’ capabilities. It enables the inheritance of Kubernetes benefits, including self-healing mechanisms, probes for health and readiness, horizontal scaling, and custom resource definitions. This integration ensures continuous application availability and responsiveness, even during unexpected issues or traffic spikes. Moreover, the native WAAP solution can seamlessly cater to different DevOps maturity levels—low maturity environments benefit from streamlined deployment and management, while high maturity settings integrate security assessments into the CI/CD pipeline. This minimizes vulnerabilities and enables version-controlled security policies. Enhanced visibility and control over security risks are achieved through integration with existing Kubernetes dashboards, simplifying monitoring and proactive risk mitigation.
You can read more about on subject in the following blog “Empowering the Benefits of a Native Kubernetes Integration in Application Security”
Optimized Performance for Efficient Security
In a microservice environment where numerous microservices interact with each other, statistics show that, for each incoming request, the internal communication generates 6 other requests. Effective WAAP implementation requires strong performance, minimal latency, and precise inspection control. These attributes play a vital role in preserving user experience and minimizing any negative impact on response times. Through targeted traffic analysis and well-defined policies, WAAP can further reduce latency while maintaining a harmonious balance between robust security measures and the expectations for a seamless user experience.
Radware Kubernetes WAAP (KWAAP) offers a comprehensive solution that addresses all the discussed needs and more. KWAAP is a Kubernetes-native solution designed to provide comprehensive protection with high performance and very low latency, while also ensuring data privacy through a 100% air-gapped approach. In the upcoming and final part of this blog series, I will delve into key features, architecture, and deployment options of KWAAP.
Your digital assets deserve the best defense – stay informed, stay safe and contact us to get more information about Radware’s application protection for Kubernetes.
