At the 2023 RSA conference, Tracy Walker, Senior Security Engineer from SUSE NeuVector, shared with us a transparent (business- and environment-neutral) approach to blocking 0-Day attacks in K8S environments – Zero Trust Principle and demonstrated it using an open source tool, NeuVector. Based on Tracy’s zero-trust viewpoint and the SUSE solution, NSFOCUS security researcher explores more new security ideas in this article.
I. BACKGROUND
Tracy’s sharing focuses on why zero trust can defend against 0-Day attacks. Figure 1 shows that unknown attacks cannot be detected based on known scanning and detection methods such as CVEs. But Zero trust, by which all actions are denied by default except those in the allowed list, will make all known and unknown threats under control. Let’s see the open-source tool Tracy uses, NeuVector.
Figure 1 Comparison between Traditional Control and Zero Trust Control
SUSE is a global open-source software company that provides enterprise-class Linux operating systems and related solutions. The basic support for Tracy’s concept is from NeuVector. Next, let’s take a look at the history of NeuVector.
NeuVector was co-founded by Fei Huang and Gary Duan in California, United States of America, in 2015. The company was founded to focus on container security, specifically network monitoring and container firewalls. The company developed rapidly after its establishment and was acquired by SUSE in late 2021. This greatly enhanced Rancher’s security compliance section, and since then NeuVector has officially become part of SUSE as an open source, zero trust container security platform.
II. What is Zero Trust
Traditional network security models usually adopt boundary defense, that is, establish firewalls between internal and external networks to protect internal resources. However, with the blurring of network boundaries and the continuous evolution of attack technologies, boundary defense is no longer sufficient to provide adequate security. As shown in Figure 2, Fei also showed in a webinar that with the continuous advancement of business cloudification, the security model has gradually evolved towards zero trust.
Figure 2 Evolution of Security Model
As Tracy put it in a webinar, the core principle of Zero Trust is “Never trust, always verify.” It is based on the assumption that neither internal users, external users nor devices can be trusted by default.
Figure 3 Tracy Walker’s Explanation of Zero Trust
Zero Trust is a security model, not a specific product or technology. Its core philosophy is to distrust any device, user or application and put access control and security policies at the application level. The zero-trust security model considers that every user and device can become an attacker, so they must be authenticated, authorized, and access controlled to protect sensitive data and applications. Such fine access control based on authentication and authorization can reduce the potential range of influence of attackers and provide higher security.
Therefore, the Zero Trust Security Model emphasizes continuous authentication, access control and monitoring to ensure that only authenticated and authorized users and devices can gain access. It does not just focus on network perimeters, but extends security to the application, data and user levels to provide more comprehensive security protection.
III. Relationship between NeuVector and Zero Trust
NeuVector’s products offer container-based security solutions that help users protect their container environment. It includes real-time threat detection, intrusion detection and prevention, runtime security policy, automatic response and other functions, which can help users identify and prevent various attacks, including internal and external attacks, unknown attacks and advanced threats.
NeuVector products can provide real-time security protection and threat detection for container environments as part of the implementation of a zero trust security model. However, other technologies such as multi-factor authentication and data encryption are needed to implement the Zero Trust Security Model.
IV. Building Zero-trust Cloud Native Security Base
4.1 Components of SUSE security base
After NeuVector joins the SUSE family, it can basically form a trusted security environment together with other products such as SUSE Linux, Harvester and Longhorn, which we can call it zero-trust cloud native security base (security base for short). It also was mentioned in NeuVector’s online webinar, as shown in Figure 4. Let’s take a brief look at the composition of this solution and the role of these products in the security base:
Figure 4 Structure of SUSE Zero Trust Environment
NeuVector: A container firewall solution for securing containerized applications. It provides container-level intrusion detection and defense through deep packet inspection (DPI) and container runtime protection to monitor and prevent malicious traffic and attacks. NeuVector helps secure the container environment and provides visibility and control of container network traffic.
Rancher: It is an open-source container management platform that provides cluster management, application orchestration, monitoring and logging, identity authentication and access control functions to help users deploy a feasible security base simply and quickly.
SUSE Linux, Harvester: As an enterprise-class Linux operating system, SUSE Linux provides a reliable, secure and scalable infrastructure for building and deploying applications. It provides powerful security functions and tools, including access control, authentication, file encryption, etc., to help establish a secure infrastructure and provide a system image that reduces the attack surface for the environment; Harvester is an open source virtualization platform based on Kubernetes, providing high-performance and simplified virtual machine management solutions for containerized applications. It leverages Kubernetes’ automation and scalability to provide a reliable virtualization infrastructure that helps build secure application environments.
Longhorn: Longhorn is an open-source distributed block storage system that provides persistent storage solutions for containerized environments. It protects the security and reliability of data stored in containers by providing functions such as data encryption, snapshot and recovery.
Comprehensive security protection and management of containerized environment can be realized through the container firewall function provided by NeuVector, the security infrastructure provided by SUSE Linux, the virtualization management provided by Harvester and the data storage provided by Longhorn. This combination can help users quickly establish a secure base based on the principle of zero trust, ensuring the security and confidentiality of applications and data.
4.2 Zero Trust Practices for SUSE
As shown in Figure 5, through the combination of the above components, NeuVector has sorted out the practical zero-trust controls for cloud-native applications. Let’s take minimizing the attack surface as an example to make some brief explanations:
Figure 5 Practical Zero-Trust Control for Cloud Native Application
4.2.1 Vulnerability, risk and status management in the life cycle
I (NSFOCUS security researcher) understand that this requires managing vulnerabilities and risks throughout the lifecycle of an application to ensure timely patches and updates to reduce potential attack surfaces, as shown in Figure 6. I will briefly analyze from the following aspects:
Figure 6 Full Life Cycle Security Diagram of NeuVector
Operating System and Virtualization: This is provided by SUSE Linux and Harvester.
Code layer: Due to the official integration description of Sonatype Nexus, I guess that NeuVector combined with Sonatype Nexus can detect whether there are known security vulnerabilities in the components used in the project during CI/CD stage and add access rules to ensure the security of project components.
Mirror level: NeuVector’s automatic response rules are combined with JFrog Xray mirror scanning capability, and NeuVector allows to configure automatic response rules according to the scanning results of JFrog Xray. Depending on security vulnerabilities or compliance issues found in the image, specific rules and actions can be defined to protect the container environment. As shown in Figure 7, rules can be set. If there are high-risk vulnerabilities in the image, the reference of the image will be automatically rejected, and the scanned image repository will be defined as a legal repository, allowing only the legal repository to be used.
Figure 7 Image Specification Admission Control
Runtime: Combining process and file system monitoring with layer 7 network inspection, unique real-time identification and blocking of networks, packets, zero-day attacks and application attacks (such as DDoS and DNS) can prevent unauthorized container activity or connections from containers without interrupting normal container sessions, which is actually transparent and has no impact on the normal environment.
4.2.2 Default rejection
All entities are regarded as untrusted by default and require authentication and authorization to access resources and services, which is actually the default denial policy of container firewalls.
4.2.3 Enforce minimum privileged access
The principle of least privilege is adopted, and only the minimum privileges required by entities are granted to reduce potential risks and attack surfaces. It includes three aspects: data collection, rule generation and application.
NeuVector shows that it uses Layer 7 network detection technology instead of eBPF and Istio technologies to collect traffic. The reason why Istio is not used is that it cannot analyze encrypted traffic (such as HTTPS protocol requests), which can easily fail to obtain plaintext or leave a masquerade path for attackers. However, Istio Egress Gateway needs to add additional network policies to ensure that all egress traffic flows through the gateway, which will increase configuration complexity. As for the reason why eBPF is not used, I did not find a clear reason in the official data. I only saw that they thought that traffic analysis on the network side could be more comprehensive in the webinar. There is probably another reason: eBPF has mandatory requirements for system versions, which means that this technology will not be available in the old version of the system environment. The Layer 7-based deep packet inspection (DPI) technology can identify multiple application layer protocols. In the official introduction, it is briefly explained that traffic identification of encryption protocols indirectly parses traffic content by tracing allowed NDS and contacting context information. Therefore, based on the DPI technology, NeuVector can resolve and track all traffic including Istio as shown in Figure 8.
Figure 8 Visualization of Istio Traffic by NeuVector
By parsing the detailed traffic, NeuVector can easily obtain the original behavior information of the environment. The original information matching various rules as shown in Figure 9 can generate corresponding types of security events.
Figure 9 Policy Specifications
The raw information is combined with the Open Policy Agent (OPA) to generate a CRD policy (this is what NeuVector claims as security-as-code), and applied to the environment to validate the policy.
V. Conclusion
Before the RSA Conference, I had some discussions with my colleagues on the Zero Trust Cloud Security Base. At that time, I tended to do zero trust in cloud scenarios at the kernel level. I expected not to pay too much attention above the kernel layer and only limit it from the bottom. The digging behind Tracy’s sharing broadened my horizon. I have two concerns about NeuVector’s zero-trust cloud-native security base solution:
First, when an enterprise decides to implement NeuVector in a real-world environment, judging which policies should be allowed will be a headache. Although they claim that the environment has a certain consistency and rules can be exported to other environments, it is unknown who will make legal judgments and who can do them for tens of thousands of microservices in cloud scenarios. Tracy claims that they do not use machine learning technology, but I believe that it might be a good idea to use machine learning to automatically determine which actions of the service are legitimate and thus give policy advice.
Second, if the attacker has controlled the environment before NeuVector, for example, the attacker has obtained some CRD resource management permissions of the cluster, or the attacker has hijacked at the kernel level, all control policies issued by NeuVector based on CRD will be ineffective. Based on this, I still retain my suggestion on kernel-based control.
REFERENCES
[1] SUSE.Zero-Trust Security for Kubernetes and Container Workloads
[2] SUSE.Zero Effort Zero Trust for Blocking Zero Days in Kubernetes
[3] https://neuvector.com/about/events/
[4] https://neuvector.com/wp-content/uploads/2020/08/NeuVectorPipeline.png
[5] https://neuvector.com/products/integrations/
[6] Neuvector. How to Enforce Egress Container Security Policies in Kubernetes, OpenShift, and Istio
[7] Neuvector. Use Cloud-Native Tools OPA and CRD to Protect Applications from Pipeline to Production
