In July of last year we launched the first application firewall built specifically for modern cloud native environments — Cloud Native Application Firewall (CNAF). We followed up on that release with our Cloud Native Network Firewall (CNNF) in September of last year, allowing customers to automatically microsegment their container environments using artifacts native to the container ecosystem, regardless of orchestrator. This month, we released the next evolution of Twistlock Cloud Native Application Firewall, version 2: CNAFv2.

With CNAFv2, we’ve expanded on the capabilities in the firewall bringing protection against a wider range of attacks against your application infrastructure. Twistlock now offers enterprise-grade protection against the following attacks: SQL injection, Cross-site scripting (XSS), Malformed request protection, Cross-site request forgery, Clickjacking, and Shellshock exploitation.

Why cloud native applications require a new approach

We’ve previously discussed how cloud native applications are different than legacy applications both in terms of the number of entities under management with monolithic applications being decomposed into multiple services; and how those entities are referenced, with a move away from the layer 3 addressing typically used to define an endpoint that you are protecting.

This change in how applications are delivered moves the security needs both up a layer in the technology stack and into the infrastructure being protected.

Let’s take a look at how this works in a cloud environment running microservices, and how it differs from traditional edge-based security tools:

  1. Every individual microservice and component can be protected in an application tailored way because Twistlock understands not just the traffic but the actual app itself.
  2. Twistlock can operate more efficiently and scale to greater demand because it closely aligns the protection characteristics to each specific app; our app knowledge allows us to create policies that are highly optimized for each specific component based on the machine learning driven model we begin building all the way back in the CI process.
  3. Twistlock can protect your apps without you having to change anything about the way you build and run them — your Dockerfiles, images, Kubernetes configurations, and other artifacts all stay exactly the same.
  4. Twistlock can protect your app anywhere it runs, regardless of the underlying networking topology and without requiring any perimeter devices; every node runs a highly optimized and tailored app firewall within Defender that’s self contained and doesn’t require any ingress devices or service layers.

An example attack scenario

Let’s take a look at how this works in a microservices application running on Kubernetes. In this example, Twistlock has automatically learned about the the application by observing how the microservices are composed and deployed. We have an understanding of how our application is composed and what connectivity should exist between the individual services. Twistlock uses this knowledge in Twistlock Runtime Protection and in Twistlock Cloud Native Network Firewall.

For this example, I’ll configure a rule to protect the “front-end” service in our application. The front-end service is what listens for http requests from the internet, and I want to make sure those requests are filtered regardless of where containers in the front end service are spun up.

Now that I’ve configured this rule and assigned it to the image, no matter where Kubernetes spins up a front-end container, Twistlock will defend this service.

When we attempt to exploit the service, Twistlock will identify, alert on, and block a variety of attack types. Below you can see where I’ve launched a few attacks against the front-end service.

In this example above, we’ve attempted a directory traversal attack. Twistlock alerted on and blocked the attack. Below, let’s look at the detail level available from the audits associated with some of these attacks:

When a CNAF rule is configured to block traffic, the request never makes it to the container we’re protecting. Twistlock Defender drops the request, and the error message below is sent back to the requestor.

This fairly simple example really shows the power of CNAF. With a single rule I created in one place, I was able to automatically protect containers running across nodes, with different IP addresses, with protection closely aligned to the specific service running. For customers, this means it’s much easier to provide protection for your apps wherever they run with purely software-defined tooling.

In addition to blocking traffic based on our built-in filtering logic, CNAF also enables you to create your own custom filtering rules using both HTTP headers and IP ranges (in CIDR notation). CNAF gives you the ability to restrict file upload types and prevent information leakage to a potential attacker.

We also use our Twistlock Advanced Threat Protection (TATP) data within CNAFv2. TATP is a collection of IP reputation lists and malware signatures that we’re constantly updating in real time via the Intelligence Stream with data from our research team and global sensor network. For CNAF, Twistlock automatically filters inbound traffic from reputation lists that include Tor exit nodes, DDoS nodes, and botnet members.

CNAF, when combined with the Twistlock lifecycle approach to vulnerability management, compliance, and runtime defense, provides a comprehensive and integrated approach to securing workloads designed to be run in the cloud, regardless of cloud provider or underlying infrastructure. To learn more about other Twistlock features and capabilities, please see our deep dives below:

← Back to All Posts Next Post →