Process whitelisting is a simple concept. In the K8s context, the basic idea is to create a list for each pod of all the processes that the pod is expected to run. Every time a process runs in your cluster you check if it is in the list. If an attacker manages to gain access to your cluster and starts running a malicious process then you can identify it immediately because a new non-whitelisted process is running. It doesn’t matter whether that process is a known bitcoin miner, a custom RAT (Remote Access Tool), or even a legitimate process like ssh. If the new process isn’t in the whitelist and isn’t part of the pod’s regular behaviour then it should be flagged immediately.
Process Whitelisting Complements Network-Oriented Security
There is an overlap in the defenses provided by process whitelisting and traditional firewall-oriented security. Let’s say you are worried an attacker will find some way to bypass your defenses and gain access to your cluster. If they manage to do so, you still want to stop them from running a RAT and exfiltrating confidential information. Should you stop them by adding firewall rules which prevent the traffic from leaving your cluster? Or should you stop them with a process whitelist that prevents the RAT process from running in the first place? Each solution provides a different type of security and the combination of them will let you sleep even better at night. This is similar to installing both a firewall and an antivirus on your desktop PC. One focuses on network traffic and the other on the malicious code that generates that traffic.
The same approach is relevant for protection against bitcoin miners: do you implement a reputation-based network policy that blocks the ips and domains that the bitcoin miner contacts, or do you focus on stopping the process that does the mining? If you choose the right security solution you don’t need to choose between the two approaches. Alcide’s Runtime, for example, supports both.
The following diagram shows how process whitelisting works together with a network based-firewall to block attacks at every stage including the infiltration stage, the execution stage, and the exfiltration stage. This way a sophisticated attack that manages to bypass one stage will still be caught by the other two.
Image: Process whitelisting works together with a network based-firewall to block attacks at every stage
Process Whitelisting Provides Zero-Trust, Process-Based, Security for K8s
Let’s take a closer look at how process whitelists compare to antiviruses. Both of them limit which processes can run, yet process whitelists provide a stronger guarantee. A traditional antivirus engine scans processes for known viruses. Modern antivirus engines go one step further and use heuristics to try and identify unknown viruses. Process whitelisting goes one step further still and rejects every process as unwanted unless it was whitelisted in advance. Process whitelisting is the ultimate zero-trust security guarantee when it comes to process security.
Process whitelisting is applicable to PCs too, but it is less practical for PCs than it is for Kubernetes clusters. A typical PC runs hundreds of processes and lets the user install and remove programs as they wish. This makes maintaining a whitelist difficult. On the other hand, a typical Kubernetes pod runs one main process in a controlled and predetermined environment – that is the whole point, after all. Therefore you can easily determine which processes a container should be able to run. This applies to your own containers as well as 3rd party containers. You can whitelist 3rd party containers to protect yourself from scenarios where new malicious processes are added to those containers without your knowledge.
There are also regulatory and compliance reasons to implement process whitelisting for Kubernetes. We’ll look into that more in a future blog post.
Process Whitelisting Complements Container Scanning
Process whitelisting is complementary to container scanning because it allows you to catch unknown malicious code which doesn’t yet have a known signature. With process whitelisting, any process that you didn’t explicitly whitelist won’t be allowed – known signature or not. Even for known viruses, process whitelisting and container scanning can complement one another. Container Scanning tells you what the state was at given snapshots in time – at the CI stage, at the CD stage, or at timed intervals afterwards. On the other hand, process whitelisting is a runtime protection which continuously monitors your cluster. Let’s look at an example of why that matters:
Let’s say you have a container which passes all of your container scans but contains an unnecessary yet legitimate wget binary. After the container is scanned and deployed, someone runs wget and downloads a dns-based exfiltration tool into the container, runs it for an hour to extract a large amount of sensitive information, and then deletes the exfil tool. The container is then scanned using a typical container scanner. All the container scans would find nothing. Each time the container was scanned there was nothing to see. On the other hand, a process whitelisting solution would have seen everything because it continuously monitors the runtime. In fact, process whitelisting could have caught the breach before it happened: If your container doesn’t actually need the wget binary, then it wouldn’t be in the process whitelist and process whitelisting would have identified the breach when the wget command ran before the exfil tool was downloaded.
Implementation Decisions for Kubernetes Process Whitelisting
You can choose to implement process whitelisting on Kubernetes in various ways. One weak way of implementing it would be to define a whitelist of process paths at runtime. This is a weak implementation because it can be bypassed if an attacker replaces legitimate whitelisted processes with malicious processes at the same allowed path. The Alcide Process Whitelist feature works by whitelisting processes at container build-time. You add a few lines to your Dockerfile and let Alcide take care of the rest. We attach a cryptographically signed whitelist to your container. That whitelist contains a hash of the whitelisted binaries as they existed when the container was built. If a process in the container is modified post-build then we can identify that change and issue an alert.
If you’re still trying to decide whether you should implement process whitelisting for your cluster or not, think about this point: The typical network administrator goes to inordinate efforts to prevent malicious traffic from leaving their network. However, outbound malicious traffic never causes a breach. It is the result of a breach. There is always some binary in your network generating that malicious outbound traffic. If you can stop the process that runs this binary, then you can stop the problem at a much earlier stage and you can stop it even if the attacker uses the exact same ports that are open in your firewall. That is the purpose of process whitelisting.