The perimeter approach to securing networks is fundamentally flawed, and it’s been known to be broken for some time now. This approach fortifies the edge of the network, separating the Internet from your organization’s core IT infrastructure using devices such as firewalls and Intrusion Detection or Protection Systems (IDS/IPS).
The problem with the perimeter-only approach is that once the perimeter is breached, the soft underbelly of your core is left exposed with little protection. The perimeter model assumes internal networks are trusted and external networks are untrusted, but the truth is that threats exist on both sides of the perimeter.
Once attackers breach your perimeter defenses and establish a pathway for remote code execution, they can launch attacks from hosts that reside on the internal network, exploiting the flawed assumption that hosts on the internal network are inherently trusted. They can move laterally from host to host, because hosts in the same security zone typically have permission to communicate with each other. It’s from this vantage point that attackers can advance to establish footholds on hosts in higher security zones.
Twistlock 2.2 introduces a new feature called Cloud Native Network Firewall (CNNF) to impede lateral movement though your network. CNNF is a Layer 3 container-aware virtual firewall that utilizes machine learning to automatically identify valid traffic flows between app components in your cluster. CNNF works as an east-west firewall between containers. It limits damage by preventing attackers from moving through your environment when they have already compromised one part of it.
At Twistlock, we often highlight the differences between securing containerized cloud native apps and legacy apps. With containers, traffic is usually encapsulated and encrypted between nodes in an overlay network typically opaque to traditional tools. The IPs of endpoints are ephemeral and largely irrelevant; you can’t rely on a manually maintained rules, such as
“from 192.168.1.100 to 192.168.1.200, allow tcp/27017” because you usually don’t know, or even care, what IPs a container is using at any given point in time. Finally, with containers, there are a much larger number of entities under management. The total number of endpoints can scale by an order of magnitude, from a few hundred VMs for legacy apps to a few thousand containers for containerized apps. Tools that rely on fragile, manually maintained rules simply can’t scale to handle a container environment.
Automation is a key enabler for CNNF. Automatically mapping, identifying, and whitelisting valid traffic flows is what makes securing intra-cluster traffic in a constantly changing container environment even possible. Because Twistlock is running on every node in your cluster and because it deeply understands your apps through machine learning models, we can combine these capabilities to do Layer 3 firewalling in a new way.
CNNF is designed to leverage our proximity to the app and our knowledge of how it should behave to dynamically create filters that automatically allow valid connections and drop suspicious connections, regardless of where your containers are running in the cluster. This all happens without requiring you to change the way you build, deploy, or run the apps we protect.
Twistlock Defender (deployed as a container, one per node in your cluster) acts as the control plane. When containers are first launched in your environment, Defender automatically learns the valid traffic flows. Source to destination mappings are coded using image identifiers; there is no dependency on IP addresses. After the learning phase is completed, the model is activated, and depending on your policy, Defender can take one of three actions when anomalous connections are established:
- Do nothing.
- Raise an alert and log an audit when anomalous connections are established.
- Block anomalous connections from being established.
Twistlock Console (our management portal) provides a tool called Radar that helps you visualize the flows between entities in your cluster.
Radar isn’t new (it’s been part of the product for several releases now), but up until now it has only supported Kubernetes. Now in Twistlock 2.2, we can identify, map, and enforce all network flows in your cluster regardless of the underlying orchestrator. That means CNNF supports not only Kubernetes, but also Docker Swarm, DC/OS, and anything else that might be invented in the future.
CNNF provides a way to ensure that only good traffic flows on your container network.
By applying machine learning, CNNF lets you centrally model, view, and enforce safe traffic flows across your environment, and automatically block anomalies without human involvement.
Subscribe to our blog for cloud native cybersecurity updates, or get in touch for a demo.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Multiple Registry Scanners: 2.4 Deep Dive
At Twistlock, we’ve watched our customers implement security through...
The Challenges of Securing and Protecting Containers During Runtime
Containers deliver many advantages over virtual machines, but they als...
Infinite Scale and Multitenancy with Projects: 2.4 Deep Dive
At Twistlock, we’re working with enterprises across almost every ind...
Twistlock 2.4 Release Notes
Announcing Twistlock 2.4 We just signed off on Twistlock 2.4, the 13th...
5 Ways to Solve for Enterprise Cloud Security Challenges and Risks
Infrastructure as a Service (IaaS) clouds present a somewhat unique se...