Frequently Asked Questions

here are many features of HardenedVault’s security-enhanced Linux, two of which are particularly important: 1) Built-in security baselines, most of which are based on CIS and STIG, and can be customized by users according to their own security compliance needs. 2) Integrated with VED-LTS, a Linux kernel runtime protection that can defend against 0-day and N-day vulnerability exploits and rootkits, most of the container escape vulnerabilities in the last three years can be defended against.

HardenedVault’s solution can be developed and adapted based on any GNU/Linux distribution, and does not compete with commercial distribution vendors such as RedHat or SuSE. We have also completed the same security enhancements for a client running a Debian derivative system on arm64 edge computing devices. Our decision to adapt to the Ubuntu LTS version was based on market research and user feedback. Those who have purchased commercial open source subscription from RedHat/SuSE/Canonical can also work with HardenedVault if they need full-stack Hardened Linux solution.

Although it’s a feature of the HardenedVault solution to achieve security compliance more easily, we also offer other conveniences. For example, there are about 120 public Linux kernel vulnerabilities (with CVE numbers) disclosed every year, and a large number of vulnerabilities can be used for container escape. The full version of VED can defend against most exploitation methods, and even VED-LTS can greatly reduce security risks caused by patching delays.

Using VED will not have any impact on the stability and continuity of the OS and business, but will instead improve system security and business continuity. Firstly, the deployment and upgrading of VED are very convenient. From operational team’s perspective, according to the current vulnerability disclosure situation, there is an average of one CVE vulnerability disclosed every 2.5 days, which requires customers to upgrade and fix in a timely manner. However, using VED technology can extend the time to patch vulnerabilities to an average of 90 days or longer.

While many host defense products, such as HIDS/EDR/XDR, offer baseline scanning features, implementing corrective actions based on the results can be a challenging and time-consuming process. HardenedVault’s security-enhanced Linux has already deployed the necessary baselines and audit rules, making the implementation of corrective actions more efficient. Moreover, VED can extend SOC/SIEM/XDR monitoring to the kernel level, which is critical even in scenarios where cloud native/containers are not involved. In addition, current HIDS/EDR products lack the ability to protect the Linux kernel at runtime, leaving nodes vulnerable to attacks. Vault Labs found that a PoC/Exploit, publicly available for 15 months, can still compromise nodes running HIDS/EDR. Overall, EDR/HIDS and HardenedVault’s solution can complement each other, as SIEM/XDR threat platform servers also require security protection. Although the industry is hesitant to discuss the need for self-protection in security products, the Tetragon incident is not an isolated case.

From a risk assessment perspective, VED is particularly suitable for various scenarios. In cloud-native environments, all containers share the same Linux kernel, which can lead to a cluster-wide compromise in case of container escape, making VED an essential tool for mitigating such risks. Similarly, vehicle-side systems based on AUTOSAR AP, such as the entertainment system and T-Box running Linux kernel, are exposed to significant threats from WiFi and Bluetooth firmware, making VED an ideal solution for protecting these systems. From a perspective of protecting important assets, VED is also highly effective. For example, it is useful for zero-trust servers using SSO (Single Sign-On), which are particularly vulnerable to attacks. Additionally, control nodes in cloud environments, such as Kubernetes master nodes and OpenStack Nova schedulers, require robust protection to prevent unauthorized access. Finally, key management servers, such as nodes for generating and distributing AK (Access Key) and Keystone, the identity authentication service node for OpenStack clusters, are critical assets that require maximum protection.

Linux kernel has roughly 120 public vulnerablity (with CVE number) each year. The memory corruption mitigation can be done in 3 separate stages: Pre-exploitation stage, Exploitation stage and Post-exploitation stage. VED is highly focus on the later twos and can’t do anything about Pre-exploitation stage. We evaluated many exploit techniques in large number of vulnerablities from MITRE’s CVE + Ubuntu security tracker + public PoC. Our evaluation ratio is greater than the public PoC/Exploit, but less than Ubuntu security Tracker. VED’s current mainline development and testing is based on the Linux kernel v4.19 and v5.15. Some users are still running VED on CentOS 7.x (v3.10).

We continue to develop protection features against new attack methods.

Yes, if the attacker use a container as a foothold and try to take control over the host by launching the attack on Linux kernel, e.g: CVE-2021-22555.

VED has less than 1% of performance impact in small-plt (CPU-Intensive) test while the impact could be more than 30% in I/O-intensive scenario.

Yes.

VED uses kprobe/ftrace to implement the hook mechanism. Debian enables AppArmor by default and CentOS enables SELinux by default. VED works with Debian and CentOS perfectly. VED offers a full-featured LKM version and an eBPF version for cloud-native auditing purposes, the latter of which does not need to be implemented through a hook.

x86_64 and arm64. Arm64 is only used on AWS Gratiton2 (armv8.2) and Raspberry 4 (armv8.0).

From risk assessment’s perspective, 1) The containers in a cloud-native environment share the Linux kernel, in which container escape will lead to the compromise of the whole cluster. 2) Linux kernels running on Infotainment and T-Box (AUTOSAR AP) face huge risks from the independent SoC, e.g: WiFi and Bluetooth. There are some assets are more important than others, e,g: 1) SSO (Single Sign-On) based Zero Trust solution. 2) Control nodes in the cloud environment such as Kubernetes master node, OpenStack Nova scheduler, etc. 3) Key management servers, such as nodes that generate and distribute AKs (Access Keys), identity service nodes (Keystone) in OpenStack clusters, etc.

VED uses the same open source subscription model as SuSE, RedHat and PaX/GRsecurity, that is, HardenedVault will sign an open source subscription agreement with the customer, some of which includes: 1) HardenedVault shares the VED code with customers 2) HardenedVault will terminate the service if the customer violates the agreement. But the source code customer received is still GPL.

Open source subscription terms are similar, but not all products are based on the GPL, such as VaultFuzzer, which is based on the Apache license 2.0.