Blocking Attacks in Runtime with Drift Prevention
Drift prevention is the cloud native answer to malware, worms and zero-day exploits. It’s also one of the best things to happen to security since the firewall, and finally a departure from the defeatist “we can’t really stop attacks so let’s not try” approach that’s been plaguing the mindset of security professionals in recent years and, quite frankly, is depressing to a security professional like me. Read on to understand why.
A Reminder: Why We’re Here
Running your own program on someone else’s computer. That is among the primary goals of any person or entity who wants to attack an IT infrastructure. An attacker may want to propagate a virus, steal data, encrypt data for ransom, disrupt operations or use the resources for their own needs. And for all of these, somehow, somewhere in the environment the attacker’s program needs to run.
At its very core, the purpose of IT Security is to stop that from happening. The work to implement physical controls, authentication, authorization, firewalling, patching, antivirus, vulnerability management, logging and incident response –is mostly done to address the eventuality of an unauthorized user running unauthorized code. After all those years, you’d think we would be better at it.
There are many reasons why attacks keep happening--whether these are ransomware or cryptocurrency miners, or information theft or, even worse. Weak security controls and human factors are often chief contributors. However, the truth is that Security is fighting a losing battle. The reality of most IT systems is that of complexity. Huge numbers of disparately located, interconnected systems keep changing by many system administrators. Computers are performing multiple tasks all at the same time, serving multiple users in complicated multi-tier applications. It is unreasonable to expect one could protect them from outside attacks using even “next gen” firewalls or be able to get sufficiently good information from the log files to separate the good events from the bad ones. Attempts at modeling all the permutations of authorized access in distributed computing have mostly failed as well. Due to complexity, effectively preventing intrusions from happening is a proposition that Security has mostly given up on.
Cloud Native Immutability is a Gift to Security
There is, however, one aspect of IT management where the fundamentals have changed. Cloud native is a methodology that aims to change the very structure of applications, their development, packaging and deployment. It also removes a big piece of the human factor along the way. Cloud native applications comprise of independent microservices. Each service does one thing only. Each service is built, then deployed, and then replaced by another. No inline management, no human fingers in the pot, and no changes allowed while the service is up and running. This is the holy grail of immutability.
To IT Security, cloud native is a godsend, not a headache. It simplifies reality, making it predictable, immutable, and most of all, defendable. In a world where workloads come from images (whether container images, functions or even VMs), where workloads perform a single function and persist little data, an attacker has a limited opportunity to hide their code. Instead of finding a bad person in a busy train station, you can now easily point out that person in a sculpture museum. If all the software of an application is predetermined and unchangeable, it is easy to find what doesn’t belong. If no software can be added to a running workload, it is immaterial if the software is a virus, or a crypto miner, a data theft program, or even something benign. It is not important who is trying to add it. No software should be added to cloud native workloads at run time. Period.
What is Drift Prevention?
Which brings us to Drift Prevention. In drift we mean the difference between the software that came from the image, and the software that is running in the workload. In prevention we mean the ability to immediately stop any software that doesn’t belong. By stopping we only block what doesn’t belong – not the entire container, function, or the application. No questions asked, no signature matching, no machine-intelligence, no resource overhead. If it didn’t come from the image, it should not run. Plain and simple.
That is power of the Aqua CSP Drift Prevention. It’s one control, a single check box in the Aqua CSP console that is enforced by the Aqua runtime enforcement point. With Aqua CSP deployed in the environment, and Drift Prevention enabled, there is clear identification of which executables belong and which do not. Those that do not belong are stopped. We are, effectively, enforcing the noble principle of immutability.
How can we be so decisive? Because of our ability to track a workload from its inception to runtime, to compare its current payload to its original state, to identify every difference, and to surgically block those from executing. It’s a deterministic ability that doesn’t rely on statistics, heuristics, or signatures. It relies on knowledge and not on guesswork.
Drift Prevention is not simply a way to identify running containers that didn’t come from your pipeline or weren’t scanned – this is a more rudimentary ability also provided by Aqua CSP, called Image Assurance. What we are referring to are changes, such as code injection, to a container that was authorized at the time it was deployed. Tools that look for processes on the host will not detect this – they do not have the ability to follow changes that happen inside the container.
In practical terms, this means that your workload is protected from vulnerabilities, zero-day exploits or even a rogue system administrator. Yes, Drift Prevention also stops internal threats.
In the example below, we have a workload, a WordPress Server running as a Kubernetes Pod, that contains a vulnerable plug-in. This plug-in can be used to download and run arbitrary code remotely. The attacker is attempting to exploit this weakness to run a cryptocurrency miner. As soon as the crypto miner is downloaded, Aqua CSP identifies it as software that did not come from the original image and blocks its execution. Attack thwarted. Problem solved. Even if this specific miner is new and has never been seen before, it doesn’t matter. All that matters, is that it wasn’t part of the image from which the container was deployed. Aqua CSP also provides valuable data about this intrusion attempt, collecting the series of events that led to the download of the crypto miner, and the networking activity that was generated.
In every deployment model, application should still be coded with security in mind so that the transactions themselves are not hijacked. Every infrastructure still needs adequate protection from denial of service and other disruptions. Vulnerability management and security operations are important supporting functions that help lower overall risk. But when it comes to cloud native applications and environments, if you’re going to put in the effort to secure them, do it with the goal of preventing bad things from happening. Do it with the single control that stops attackers from getting what they want.
When it comes to cloud native, secure it like you mean it.
Start here, learn more about Cloud Native vulnerability management