We’ve often talked about what’s different about securing containers and cloud native apps.  A couple of those differences are the much larger number of entities under management and the frequency with which they change.  An app that historically may have run across a few VMs that were updated quarterly when decomposed into microservices may involve 10s of containers that change daily.  Traditional network security tools aren’t well optimized for this model and using them often incurs significant management overhead and manual configuration.  This problem is especially acute for application layer traffic since those tools need to not only route traffic to the right microservice but also understand how to protect each of the apps within.

For example, in old world security tools, if I wanted to provide SQL injection protection for my WordPress app, I’d need to configure my WAF with a rule like ‘for HTTP traffic to wordpress.company.com, reverse proxy to vm-wordpress at’.  As long as the WordPress VM didn’t move from, the filter could inspect and filter traffic destined to it.  In the new world of cloud native apps, though, such a model doesn’t work as well.  Now, WordPress runs in a container and my orchestration tool like Kubernetes or Swarm may schedule it to run on any one of many nodes in my cluster based on real time performance demands.  Further, my orchestrator may scale my app up and down based on load which means the total number of containers I need to protect is always in flux.  While you can address some of the routing problem by using platform specific services or building your own reverse proxy layer into the app, it’s additional complexity and fragility to manage.  Sometimes it can also decrease your security because your filtering layer grows more disconnected from your app and less tailored to protecting it.

Because Twistlock is running on every node in your cluster and because we deeply understand your apps through our machine learning models, we can combine these capabilities to do application layer firewalling in a new way.  We call this our Cloud Native App Firewall (CNAF) and it’s designed specifically to leverage our proximity to the app and our knowledge of how it should behave to dynamically create application layer filters that automatically protect your apps regardless of where they happen to be running.  CNAF dynamically routes traffic sent to your app through our filtering engine and ensures only safe, clean traffic ever makes it to the app.  This all happens without requiring you to change the way you build, deploy, or run the apps we protect.

CNAF deep dive

CNAF provides several advantages to protecting cloud native apps that aren’t practical with traditional tools:

  1. Every individual microservice and component can be protected in an application tailored way because we understand not just the traffic but the actual app itself
  2. We can operate more efficiently and scale to greater demand because we closely align 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. We 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. We 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

Let’s take a look at how CNAF works in our WordPress example.  I’ve deployed WordPress using a simple Docker Compose file that looks like this:

root@vm-web:/home/john/cnaf_demo# cat docker-compose.yaml
version: '3'

image: mysql:5.7
- db_data:/var/lib/mysql
restart: always
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_USER: wordpress

- db
image: wordpress:latest
- "9000:80"
restart: always

Twistlock immediately sees that deployment, begins building the runtime models for it and displays it on in our Radar view:

Note that there’s an overlay icon of the number 2 on each container. This is because I took that same Docker Compose file and deployed it into 2 completely separate clouds. One deployment is in Google Cloud Platform, the other is on a Hyper-V host in a private datacenter. Neither of these environments has any WAF or other app filtering protection in place, just simple layer 3 ingress firewalls that allow traffic to each deployment. Also note that each deployment uses a different publishing port:

On Google Cloud:

root@john-test:/home/john/cnaf_demo# docker ps --format "{{.ID}}   {{.Image}}   {{.Names}}   {{.Ports}}" | grep cnaf
445fae833b51   wordpress:latest   cnafdemo_wordpress_1>80/tcp
aae9c212f127   mysql:5.7   cnafdemo_db_1   3306/tcp

In the private datacenter:

root@vm-web:/home/john/cnaf_demo# docker ps --format "{{.ID}}   {{.Image}}   {{.Names}}   {{.Ports}}" | grep cnaf
8047f24c35f9   wordpress:latest   cnafdemo_wordpress_1>80/tcp
02f9484a5d02   mysql:5.7   cnafdemo_db_1   3306/tcp

The reason this is cool is because we’re going to create a single CNAF rule that will automatically protect all WordPress containers, regardless of what datacenter they’re in or what ports they’re listening on.

Creating the rule is pretty simple, I just target it at any container called <em>wordpress*</em>:

CNAF deep dive

No matter where that container is running or how traffic ingresses to it, Twistlock will dynamically reroute that traffic through CNAF and filter it, with no change required to the app itself or how you’ve deployed it. Because we know that the containers in question are running an image that our machine learning has built a model for, we can also apply very specific app tailored protection. A rule protecting WordPress can be highly optimized specifically for WordPress because of our comprehensive knowledge of how WordPress should behave under normal conditions.

Let’s start with just an alert action by default. First, I visit the environment on GCP, and enter a search string that attempts SQLi:

CNAF deep dive

Twistlock will detect and alert on that violation:

CNAF deep dive

Let’s change the rule from alert to block and now try the same attack against the container in the on-premises datacenter:

CNAF deep dive

When a CNAF rule is configured to block traffic, the request never makes it to the container we’re protecting.  It’s dropped by the Twistlock Defender and the above error message 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 multiple cloud providers, with different IP and port configurations, with protection closely aligned to the specific app they’re 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).  We also use our Twistlock Advanced Threat Protection data within CNAF.  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, we automatically filter inbound traffic from reputation lists that include Tor exit nodes, DDoS nodes, and botnet members.

CNAF deep dive

We have many more cool networking defense features planned for upcoming releases that I look forward to blogging about.  Until then, though, stay tuned for more deep dive blogs on the other big features in 2.1, and follow @Twistlockteam on Twitter for real time updates.

← Back to All Posts Next Post →