Rethinking Security at NeuVector – Micro-Perimeters
By Gary Duan
The application revolution has witnessed the traditional ‘hard-to-change’ monolith that is now broken down into smaller pieces, forming a focused microservices cloud-native architecture which requires ‘micro-perimeters’ for protection. The containerization of applications and their deployment into production are what really led to the introduction of the NeuVector next-generation container firewall.
This forms a new model of security that primarily focuses on how the application is deployed, managed and operated. The traditional way has now become insufficient, and new thinking is needed to secure these micro-perimeters.
The Cloud-Native Application
Containerized workloads are different, rather more advanced than the traditional workloads. They are elastic and dynamically growing on demand, typically running everywhere with a runtime that is shorter than the traditional workloads.
Now we have orchestration systems, containers, service meshes, ephemeral and dynamic services. We are equipped with changing functionality besides the capability to both scale up and scale down in an instant. Each unit can scale independently, thereby driving scalable application architectures.
As a result, there are many more moving parts and paths of communication. This ultimately introduces more complexity that must be secured and managed. Not to mention, there are multi-development teams that can individually upgrade applications, often operating with security being an afterthought. Ideally, they should know what is connecting to what and what protocols are being used.
These above-mentioned factors pose challenges to security. As a matter of fact, a security solution must keep pace with the application changes. Hence, for an effective posture, the security has to be more elastic. The security solution should be adaptive to the underlying services whether they require scaling or are evolving in functionality. To gain all the benefits of the cloud we can not wait for security.
Complicated Traffic Patterns
Now, as the application architecture has more components, the communication patterns have become more complicated. Today’s traffic patterns are very different from those of the past. There are a lot of application programming interfaces (APIs) connecting inbound and outbound along with an array of internal communication. Kubernetes networking is also not well understood, so how can you protect it? It is expected that in the coming times these connections will cross hosts, clusters, networks and eventually, clouds, all of which need to be protected.
Time to Rethink Security
The adoption of these containerized technologies – while bringing tremendous advantages – requires a new approach for container network security. We need to rethink security to effectively secure the new environments from both internal and external threats.
Let’s face it! The modern dynamic cloud-native infrastructure invalidates the existing network security approach which assumes a relatively static configuration. Virtually, the containerized application environments are fluid and constantly changing with multiple teams operating in silos.
As a result, the old way of using the network as a security control point is not only operationally challenging but a security hazard is likely to be introduced inadvertently. This could further result in unlocking many doors for compromise. In such a situation, the attempt to secure a complex deployment using the existing tools does not work. This leads to a complicated security solution that is often ineffective, compounded with complex manual policy administration and lacking automation.
Issues with Perimeter Firewalls
Initially, for protection, we had a perimeter firewall located at the strategic network points either on-premise or in the cloud. However, the network perimeter was born in a different time to satisfy the requirements of that particular time.
Rationally, the traditional constructs that we used to protect applications and network traffic are now ineffective in the new containerized environment. Security mechanisms based on traditional constructs, such as Internet Protocol (IP) and 5-tuple no longer suffice. From an architecture and feature set point of view, traditional security falls short in many ways. Let’s review some of the significant drawbacks.
Lack of Visibility
The location of the firewall at the perimeter does not have the required visibility of all the workloads and the way they are changing. Without visibility how can you protect applications? Logically, you can’t protect what you cannot see. Full visibility is the core building block for effective security.
We also have host-based security, where security products are installed local to the devices. However, they don’t have the visibility of the container network or of the entire application communication patterns.
Essentially, all these traditional security mechanisms miss the bigger piece to the architecture of the application and the traffic flowing between the endpoints. A container firewall has some similarities but many important differences from a next generation firewall (NGFW) or web application firewall (WAF).
How Does a Service Mesh Impact Security?
These days, there’s a ton of buzz about the benefits of a scalable service mesh, such as ISTIO and linkerd2. Implementation of a service mesh provides dynamic service discovery, routing, load balancing failure recovery, and other application services.
However, this also injects more complexity into the network connections between application workloads which must now be monitored and secured. It’s even more difficult when the service mesh extends beyond container clusters and clouds.
There’s no way you can expect the traditional perimeter firewalls to understand and solely keep up with the threat detection and segmentation required in such a dynamic environment. Besides, although Istio and other service mesh’s offer some authentication and encryption features but they are NOT security technologies.
You can’t expect a service mesh to provide the level of network threat detection, multi-protocol security, and segmentation that are required for the modern cloud deployments. However, a service mesh can exist together with a security mesh and utilizes the same concepts, as I talked about in this post. We also announced an integration with service meshes to inspect encrypted application and system connections.
The Shrinking Perimeter
Traditionally, the perimeter had clear demarcation points. Traffic would enter the demilitarized zone (DMZ), get sanitized and then either permitted or denied to the internal local area network (LAN) where it was granted full access. However, this is no longer useful in the modern cloud environments.
Today, there is a high percentage of cloud users, using hybrid and multi-cloud to deploy applications. A virtual private network (VPN) can be used as a tunnel between clusters in which that tunnel is trusted.
However, although the tunnel is trusted if one cluster gets compromised, the other clusters can also get compromised. This is a common occurrence as the majority of attacks are now internal, be it a malicious employee or a malware infected host. Once an internal device is compromised, the lateral movements can propagate to other clusters and workloads.
Since the perimeter is no longer defined with clear demarcation points, therefore, one must assume that the perimeter is breachable.
Micro-Perimeters
A sensible solution could be that we must shrink or collapse the perimeter in each workload. Security applied to each workload is the most reliable and effective way to protect the application. We need to move to a more granular micro-nano segment level. The perimeter should be tightened to be close to the workload itself.
I call these ‘micro-perimeters.’ Realistically, the idea of moving the perimeter to protect the internal assets with a micro-perimeter is a mandate for the zero-trust security model and is the only effective way to protect the new cloud environments.
The NeuVector Solution for Ever-Changing Perimeters
In the past, security products had to be injected or be host dependent or the agents that were kernel dependent. As a result, they were difficult to be updated and were often in conflict with other processes.
Contrarily, the NeuVector Kubernetes security solution operates as an independent security container. It can run anywhere, be portable, deployed and managed like any other application workload.
Once you deploy NeuVector on Kubernetes (or any of its flavors such as OpenShift, Rancher, or Docker EE), as a daemon set the orchestration system installs the container firewall on every host. Now, it has the capability to see all the network traffic between Pods and containers with the ability to detect violations and threats. It will also monitor all the processes and file system activities within every container to detect any suspicious activity.
From here we are able to automatically build a whitelist-rule-set at layer 7 to micro-segment and isolate connections. In real-time, the NeuVector container starts inspecting the network traffic and monitors the containers and hosts for suspicious activity. This layer 7 network inspection is able to function even if the connections are encrypted, by intercepting traffic before the encryption takes place (in the case of service meshes). This NeuVector integration with service meshes provides unique visibility into application and system network traffic.
The firewall can run in a monitor (network tap) mode or a protect (inline) mode where attacks or unauthorized connections can be blocked while keeping the container up for valid traffic. Not only can the NeuVector container see network traffic, but also the processes and file system activity. This enables the solution to monitor the suspicious processes and file system changes. The combination of network, container, and host security is what we call ‘multi-vector’ container security.
This positions the NeuVector technology at a unique location where we can track all those activities and combine them together for better protection. Ultimately, this enables the control of false positives and negatives to give more accurate alerts to the security operations team.
It’s a complete solution for the runtime security of containers that easily integrates with orchestration and management platforms. There is also an added capability of the threat detection feature using deep packet inspection (DPI). The NeuVector solution enables the teams to look at, for example, domain name system (DNS) and distributed denial of service (DDoS) attacks within the payloads.
The solution doesn’t just look at the first TCP SYN. In order to detect early attempts and workload compromises, you have to look further, not just at the header, but at the actual payload and also look for a variety of protocols.
The NeuVector solution offers intent-based intelligence that allows the user to decide the expected behaviors that the system should follow and then monitor the system. The policies can be declarative and then the behavior is monitored to ensure that the expected is met.
Threat Detection and Network Segmentation
The core feature of the NeuVector solution is the ability to execute threat detection and network segmentation on any application workload, thus forming the micro-perimeters that I mentioned earlier. Micro-segmentation signifies segmenting the containerized types of communications, allowing you to segment on a micro level. Only NeuVector is truly able to create micro-perimeters around workloads because this requires deep network visibility and protection.
Objectively, while there are other ways to do segmentation, they are often limited in protocol support and lack integrated threat detection. For example, if a container is exploited and initiates an attack using a trusted connection to another container, only a true layer 7 container firewall will be able to detect such an attack. Attacks can also come through protocols such ICMP and UDP, or custom applications built on TCP.
The NeuVector solution uses a behavioral learning module to discover the normal behavior in terms of networking between the workloads. From this, the baseline is constructed from which violations can be detected. This technology is critical for automation if your applications and services will need to scale.
The deep packet inspection technology gets applied to the learning process. This is not only between container identifiers and endpoint IP addresses but is one level higher. The model not only constructs security policy based on the application endpoints but also on the basis of the protocols that the applications are using and how they are using them. This policy is created by looking deeper than ports and IP addresses.
In addition to layer 7 network policy, the model can also construct baselines on process running, file system access, scanning registries, and the CI/CD integration. As a result, the entire container pipeline from build-to-ship to run-time is protected.
Automation is Crucial
An automated solution is crucial in the dynamic nature of how containerized applications are developed and deployed. The security solution must keep up with dynamic and changing environments. Automation is the only way to do this.
The frequency of developing, deploying and updating containerized services is high, often with over a thousand new or updated containerized services released each week. Therefore, one can not manually change firewall rules and update Linux IPtables at this scale in an efficient way. Hence, the security solution needs to be fully automated and scalable.
The first type of automation that NeuVector offers is the behavioral learning engine, where we learn the behavior of the service to create a security policy.
The second part of automation is where development teams can specify the connection whitelist as a part of their deployments. This is what is known as the declarative security policy. It allows the development teams to declare what the security policy is as they deploy the application where NeuVector is going to inject and enforce those rules.
Finally, as workloads start crossing clusters as well as clouds, we really need automation as security professionals and legacy security tools will not be able to keep up.
The Transition to the Cloud Needs to Be Secure
It is clear that all new applications will be built using containers, but what about legacy ones? In such a situation, it makes sense to migrate some legacy applications to containers and extend some legacy applications with new container-based features. However, not all legacy applications will be containerized.
Traditional applications are often now complemented with additional cloud-native capabilities. As a result, the legacy is often combined with the new, but they do not always mesh well. We are left in a situation where we need to protect both the container workloads and the legacy application.
Ultimately, we not only need to protect the east-west traffic within a container network but also the ingress and egress connections to legacy applications.
DevOps & Security
DevOps have been asked to manage the fully automated pipeline for releasing containerized services and incorporate security into that workflow.
DevOps teams aren’t necessarily experts in network security and the security teams sitting in the enterprise don’t necessarily know about new container orchestration and DevOps processes. This situation creates a clash. Rationally, we need to have the same security posture and visibility in the Kubernetes environment as we do in the traditional on-premise environment.
Does this pose questions, such as to who owns container security? DevOps? The same questions surfaced with the birth of the virtual machine (VM). Who owns the security, who is defining the requirements? This often gives way to complexity and we all know that complexity is the number one enemy of security.
For these reasons, we see that the most successful teams have security and DevOps experts who collaborate to integrate security into their pipeline, automating where possible but always making sure that once these containers get into production there are ways to monitor and protect the container network, container orchestration system, and containers themselves.
Where is Security Going From Here?
As the layers of infrastructure and applications continue to become virtualized and portable, security must continue to surround and protect the most granular atomic member. Each workload needs to have a micro-perimeter which offers the same protection and visibility as we expect physical data centers to have today. Workloads need to be dynamically able to deploy across clouds or other physical infrastructures without impacting security.
When security is granular enough to be close to and perhaps even attached to the workload unit, it provides the flexibility for developers, operations, and security teams to run fast and independently. Even secure serverless workloads become practical for enterprise applications because security surrounds their applications with micro-perimeters.
NeuVector will continue to innovate to bring the container network security as well as application layer security required to secure future workloads with micro-perimeters.
