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
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
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
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...