This technical deep dive highlights key capabilities released as part of Twistlock 19.07. To learn more about what’s included with Twistlock 19.07, check out our full release blog post.

Twistlock’s Cloud Native Network Firewall (CNNF) already provides a solution to segmenting traffic between containers by learning expected container-to-container traffic. In this release, we’re building on these capabilities to address larger, more complex deployments and scenarios, allowing you to create deep policy sets on top of the learned models, to visualize the combination of these learned and created policies, and to easily manage it all.

The latest update to CNNF

Real-world deployments are often complex, including both container-based microservices and external resources. Controls such as network security groups in a cloud service don’t provide sufficient granularity to segment individual containers. Network policies applied to the overlay network are static and require ongoing maintenance.

With CNNF in Twistlock 19.07, you can combine the power of learning expected inter-container traffic with the flexibility of defining policies that control traffic both container-to-container traffic and container-to-external-IP traffic. Additionally, you can visualize the combination of these policies so that you’re always aware of, and in control of, traffic flow. Finally, you can manage these sets of rules, both by defining network entities that can be reused in multiple rules and by exporting and importing rules.

An example scenario

I often use the Sock Shop as an example of a microservices application as it’s a great illustration of how a cloud native application should be structured. If we deploy it and generate typical traffic, Twistlock will learn the way that the individual microservices should communicate, as shown in the screenshot below:

This is a powerful start to securing our traffic inside of this application; however, if we’re dealing with credit cards and user data, we may want to create some additional controls.

For example, the user-db service is where all of the user data is stored. I may want to apply a rule to prevent any unauthorized traffic leaving user-db:

In this rule, I’m only allowing the traffic that has been learned by CNNF—I’m not adding any additional exceptions. However, I’m indicating that _any_ unexpected traffic will be prevented by CNNF.

I may also have resources that interact with external, non-containerized services. For example, my payment gateway may pass information to an external service to verify transactions. In this case, I can create a new network entity to allow connectivity to a range of IP addresses or, in this example, a single IP:

Now, I can define a set of allowed traffic to this destination:

Once again, I want to prevent any unexpected traffic from leaving the payment microservice. I’ve turned off learned connections. Now, the _only_ thing that a container in the payment microservice can initiate connections to is the external payment gateway.

With these changes made, I can now see that Radar illustrates the combination of learned and defined policies:


Microsegmentation is an important tool to limit the impact of a compromised resource, limiting how an attacker can move laterally and exfiltrate data. Doing this at the container/microservice level makes it much harder for the compromise of a tiny piece of the solution to lead to a wider breach.

With the improvements to CNNF, Twistlock positions you to apply, monitor, and understand the impact of your microsegmentation strategy.

← Back to All Posts Next Post →