How to Protect Web Applications in Containers Using DPI and DLP

Protect Kubernetes Applications with Your Existing Threat Rules

By Fei Huang

The software security industry has grown very quickly in the past decades, and companies large and small are all using some type of network and endpoint security solution. These include solutions for anti-virus, anti-malware, web application firewall (WAF), layer 7 next generation firewall, penetration testing, threat intelligence, SIEM alerting and more.

Recently, the move to Kubernetes container-based platforms is converting applications to hundreds of much more scalable distributed cloud workloads.  This presents a security challenge. From one side (the ‘left’ side of the pipeline), DevOps teams are the main force driving this change. From the security side (the ‘right’ side, protecting against attacks in production), the challenge is how to gain the same level of security protections that existed before? This is a difficult challenge given the dynamic and rapid nature of container deployments.

While the basic visualization and protections for container communications may look the same as workloads scale up and down and get updated, the actual container pod identifiers and their assigned IP addresses will be changing constantly.

The Old Way of Security

Here is one specific example. A company has a web application running behind a next generation (layer 7) firewall and a web application firewall (WAF) from a security vendor. The next gen firewall and WAF could be a network appliance, host agent or Cloud service being routed to it. Protecting such monolithic applications was simple – prevent external attacks from reaching into the data center and hitting the web application. Security teams were more concerned with such ‘north-south’ traffic rather than internal, or ‘east-west’ traffic.

Security Challenges for Application Containers

Continuing with our example, now the web application is being containerized and re-factored into ‘microservices.’ The frontend, backend and database are migrating to microservices on Kubernetes, so that they can scale up and down automatically when there is higher or lower volumes of usage.

To fully leverage the power of the Kubernetes container platform, the company has started to use multiple clusters crossing different clouds and begun experimenting with a service mesh. So the traditional way of doing network security does not work anymore. How could the traditional firewall solutions scale automatically with the clusters to prevent the web applications being attacked? In addition, many public cloud deployments don’t provide these firewalls, or it’s too costly to manually implement so many of these for every cluster.

With so much east-west traffic, how could a WAF solution protect internal services, for example the database layer which is now exposed on the Kubernetes network? Or how can traditional security solutions figure out which internal container was hijacked to do stealthy crypto mining?

Using Deep Packet Inspection and DLP to Enforce Application Security

NeuVector is an automated container security platform which will make security simple to deploy, manage and extend. Core layer 7 container firewalling is included to automatically segment container traffic. Deep packet inspection (DPI) is used to implement Data Loss Prevention (DLP) features in NeuVector, such as credit card and other privacy protections.

In this example of protecting the web application containers with WAF features, NeuVector can be extended using the DLP sensors to provide the same level of traffic inspection on all web application pods. Here are some sample details of how this could be done:

• Define DLP sensors to import existing or 3^rd party Regex (regular expression) patterns into NeuVector. For example, the OWASP WAF SQLi rules. These can be done through the web console or REST API interfaces.
• Enable the DLP policy on the web application containers and apply the related DLP sensors, thereby enabling DPI inspection of incoming and outgoing traffic for these attacks.
  

• Switch the service protection mode to “Monitor” or “Protect” mode, where Monitor will just alert on an attack, while Protect will block the network attack before it can reach the containers.

With these simple steps, the new WAF type of rules will be enabled. NeuVector will start detecting attacks using these new WAF rules on the application pods which have it enabled. These can be seen in the network activity visualization in NeuVector.

If there is a SQLi attack detected, NeuVector will alert and block it immediately. The notification and alerting would look something like this below.

At the same time of the attack, the raw network packet was automatically captured in the log for further download, analysis and forensic use, and available in standard pcap format.

This example and simple demo shows how easy it is to extend the NeuVector protection with any existing Regex based WAF rules or threat rules. With built-in auto-scaling capability, these new rules will scale automatically with the service and don’t require any maintenance or updates. These new rules will also be supported in NeuVector’s “security policy as code” by using the Kubernetes CRD capability. The new WAF rules can be version controlled, tracked and managed through the DevOps pipeline!

In addition to the built-in advanced security capabilities for securing the container lifecycle, the NeuVector platform could also be a bridge used to migrate existing security practices into a Kubernetes environment. Those security practices, including WAF rules, can be upgraded to cloud-native security as code. This will ensure that security teams don’t lose the advanced security capabilities they had before. And DevOps teams will be able to achieve security automation while at the same time supporting both traditional and new security protections.