Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:00 AM
Liz Rice
Liz Rice
Connect Directly
E-Mail vvv

Prevention Is Better Than the Cure When Securing Cloud-Native Deployments

The "OODA loop" shows us how to secure cloud-native deployments and prevent breaches before they occur.

Renowned military strategist John Boyd conceived the "OODA loop" to help commanders make clear-headed decisions during the Korean War. We'll look at how one might apply the OODA loop OODA — that stands for observe, orient, decide, and act — specifically to secure cloud-native deployments and prevent breaches before they occur.

Related Content:

IDaaS: A New Era of Cloud Identity

The Changing Face of Threat Intelligence

ISP Security: Do We Expect Too Much?

The OODA loop begins with observing how a battle is unfolding, determining all available options, making a decision, and acting on that decision. The chaotic nature of battle requires the leader to constantly reconcile and repeat that process.

We can see the same logic in a cloud-native environment, where it describes how Kubernetes reconciliation works. A Kubernetes controller:

  • Observes and orientates: Monitors the current state and compares that to expectations (that is, the state that the user has defined for this resource, perhaps through a YAML file).

  • Decides: Determines whether any resources need to be added or taken away.

  • Acts: Takes steps to constantly bring the current state in line with expectations.

For example, if you have a deployment, the controller checks how many pods there are, and whether that number matches the replica count for that deployment. Each pod is a collection of containers that acts as a "deployable unit" of application code, and the replica count defines how many pods should be running at this point in time If the current number of pods doesn't match this count, the controller creates or destroys some pods to bring the numbers into line.

You can apply the same OODA loop model for security behaviors. You can detect behavior, compare it with what you expect to see, decide whether that's something you want to allow, and take remedial action if you see something unexpected. The question is, how can you detect whether an unexpected behavior has occurred?

Containers are really helpful for simplifying the problem of detecting anomalies, especially if you architect your applications using a microservices model. Each container typically performs only a small function and that means the range of normal, expected behaviors is small. For example, it's often true that you only expect to see one specific executable running inside of a given container. If you can observe the executables running in each container, you can see whether they match your expectations.

During my presentation at the Cloud Native Computing Foundation's Kubernetes Forum Sydney 2019, I walked attendees through a live demonstration which illustrates this. You can find a video of this demo, along with all the other presentations from the event, here.

As part of this demo, I showed a script using a tool called Tracee to alert me about new executables that start in containers. My script is a native security tool that applies the OODA loop model by monitoring the new executables, looks at their names, decides whether one is bad, and, if so, kills the pod — basically, pulls an emergency rip cord. However, should enough time lapse between when the bad executable is discovered to when you take remediation action, the attacker may be successful in exfiltrating data or dropping some sort of malicious payload that takes action later. Not so secure after all!

Here's another problem with relying on security tools that react to bad behavior after it happens: The Kubernetes reconciliation loop kicks in and recreates all those pods that my script destroyed; they're doing the bad thing again, and so they're destroyed again, and on and on it goes. My native security tool is at odds with the Kubernetes reconciliation loop.

What would be better is gaining the ability to prevent those bad pods from being deployed in the first place. If you can determine the intention is to run something bad, you don't have to try to stop it after it runs. So, better that the OODA loop looks at the intention, compares it with the expectation, then decides whether or not to allow or prevent that behavior.

The key is to look earlier in the deployment pipeline for places where you can insert preventative measures. If you can prevent bad software from being deployed at all, it can't do any harm. Therefore, anything we can do before runtime is preventative and more effective.

Scanning images is how we can look inside images for known vulnerabilities. Depending on your scanner, you may also be able to detect malware and prevent those images from being deployed — perhaps blocking them from being pushed into your registry. You can use rule-based access control to stop unauthorized users from deploying software as another method to prevent malicious code from spreading. And you can use admission control like Open Policy Agent (OPA) to check the YAML as it's being deployed and prevent it from running if it doesn't meet your criteria. Some security tools can even provide preventative measures within a running container, by preventing unauthorized programs from executing (as opposed to killing them after they have already started). [Editor's note: The author's company is one of a number that offer such a tool.]

If you're thinking about securing your home or your office, which would you do first: Put a lock on the door, or invest in video surveillance cameras and systems? Of course, you install the door lock first — it's the easiest and most effective thing to do. That's access control, and the perfect example of an effective preventative measure.

It's a good thing to have multiple layers of defense, so you might want to add video surveillance on all the doors. But you should always prioritize access control over observation tools. The same applies to securing your Kubernetes environments.

Liz Rice is VP Open Source Engineering with cloud native security specialists Aqua Security, looking after projects including Starboard, Trivy, Tracee, kube-hunter and kube-bench. She is chair of the CNCF's Technical Oversight Committee, and was Co-Chair of KubeCon + ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-17
The overlayfs implementation in the linux kernel did not properly validate with respect to user namespaces the setting of file capabilities on files in an underlying file system. Due to the combination of unprivileged user namespaces along with a patch carried in the Ubuntu kernel to allow unprivile...
PUBLISHED: 2021-04-17
Shiftfs, an out-of-tree stacking file system included in Ubuntu Linux kernels, did not properly handle faults occurring during copy_from_user() correctly. These could lead to either a double-free situation or memory not being freed at all. An attacker could use this to cause a denial of service (ker...
PUBLISHED: 2021-04-17
A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS Build 20210202 and later Q...
PUBLISHED: 2021-04-17
An SQL injection vulnerability has been reported to affect QNAP NAS running Multimedia Console or the Media Streaming add-on. If exploited, the vulnerability allows remote attackers to obtain application information. QNAP has already fixed this vulnerability in the following versions of Multimedia C...
PUBLISHED: 2021-04-16
jose-node-esm-runtime is an npm package which provides a number of cryptographic functions. In versions prior to 3.11.4 the AES_CBC_HMAC_SHA2 Algorithm (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) decryption would always execute both HMAC tag verification and CBC decryption, if either failed `JWEDe...