Imagine installing a new home security system that includes cameras, door alarms, window alarms, and maybe even one of those new robots that patrol your house. If someone breaks into your home, the system captures the intruder. If it aims at the entry point the intruder chose to exploit, the entry alarms should alert anyone inside, and the alarm notifications forward to a 24-hour monitoring company. Everything operates as designed. The monitoring company tries to contact anyone inside and then calls your local police department so they can respond. For argument’s sake, let’s say this happens within 15 minutes, and the police are now inside your house, threat neutralized.
Now, would you say you PROTECTED your house, or you MONITORED your home? Are your valuables inside your house protected from theft or damage? Was your family protected from harm? Of course not. The system and all its parts were meant to monitor your home and enable response as quickly as possible.
Let’s apply this thinking to Linux-based (most all, by the way) containerized environments. The question to ask is, are you protecting or monitoring? A trend has emerged where vendors use words like cloud or runtime protection while delivering only a monitor-only solution. The hard truth is monitoring is not protection.
Linux offers one of the most robust, flexible operating systems, resulting in global adoption. It’s the most portable operating system available, with the ability to run on various hardware and software architectures thanks to the system’s core. In this Linux kernel, all these capabilities emerge. Given the system’s open-source nature, developers continually find security issues and vulnerabilities in the Linux kernel, contributing to rapid and regular updates. Unlike other operating systems, Linux receives updates far more frequently, resulting in multiple new Linux kernels becoming available throughout the year.
Most anti-malware applications initially integrated with hooks into the kernel. Operating from within the kernel allows for greater control of the overall system and provides a more straightforward method to implement security controls. However, if the kernel changes rapidly, then that requires rapid evolution of the anti-malware solution to stay current, which is an almost impossible task. The anti-malware solution must be tested across old and new kernel versions, and the incredible scope often leads to unknown stability issues and negative performance impacts.
Want proof? Ask your team if their Linux solutions are currently set to monitor/detect or full blocking mode. Many Linux systems use security tools only set to monitor due to the negative impact these kernel-based solutions deliver. It is like not using seatbelts in a car. Sure, they are available, but you are only protected during a crash if they are correctly used.
Look for a coming article on performance limitations resulting in unused applications due to system instability concerns.
Due to the constant challenge of trying to keep up with Linux kernel development, many security vendors have celebrated eBPF as the new standard in Linux security applications. eBPF is a “revolutionary technology with origins in the Linux kernel that can run sandboxed programs in a privileged context such as the operating system kernel. It is used to safely and efficiently extend the kernel’s capabilities without changing kernel source code or loading kernel modules.” As a result, most security applications shifted their development away from the kernel to applications developed leveraging eBPF. The uniformity and robustness of eBPF brought about a revolution in monitoring on Linux systems. eBPF watches and reports on the system’s activity and can be a powerful MONITORING tool.
Containerized architectures are a bigger problem. Most run on Linux. All have a blast radius that includes every container on each node. So, the monitoring vs. protecting trend carries a much higher risk regarding containerized architectures. Attackers only need to attack one thing, the node, and they have unrestricted access to every workload. Most solutions for Linux, and therefore containers, favor collecting data from all sources available (logs, APIs, cloud configuration, network traffic, etc.) to form an opinion of the attack and then respond after the attack.
Let’s return to the original statement: Words matter
Remember the analogy above about monitoring your house? Monitoring does not protect. ANY solution relying solely on eBPF, or worse yet only logs and external indicators, is not PROTECTING the system. eBPF was not created to protect. Like the home analogy, eBPF can see the data, data can be analyzed to alert of an incident, and something else can respond. It takes time for all those actions to happen. Will it be fast enough to save what is valuable on that system? Probably not.
Likewise, any endpoint protection solution in a detect-only state is not protecting your system. You are not protected if the solution causes more instability and requires you to set it to monitor-only mode. Like the seatbelt analogy, the mechanism only works if it is used.
Linux administrators face a challenging reality: forced to adopt a reactive stance post-attack, with inadequate protective solutions–that is, until Vali Cyber’s ZeroLock, a reliable solution provides protection without degrading system performance.