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.

Cloud

11/25/2020
10:00 AM
Liz Rice
Liz Rice
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comments
Threaded  |  Newest First  |  Oldest First
Commentary
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
News
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
News
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Your new device is too complex. Me stick with iWheel.
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
CVE-2021-27940
PUBLISHED: 2021-03-03
resources/public/js/orchestrator.js in openark orchestrator before 3.2.4 allows XSS via the orchestrator-msg parameter.
CVE-2021-21312
PUBLISHED: 2021-03-03
GLPI is open source software which stands for Gestionnaire Libre de Parc Informatique and it is a Free Asset and IT Management Software package. In GLPI before verison 9.5.4, there is a vulnerability within the document upload function (Home > Management > Documents > Add, or /front/documen...
CVE-2021-21313
PUBLISHED: 2021-03-03
GLPI is open source software which stands for Gestionnaire Libre de Parc Informatique and it is a Free Asset and IT Management Software package. In GLPI before verison 9.5.4, there is a vulnerability in the /ajax/common.tabs.php endpoint, indeed, at least two parameters _target and id are not proper...
CVE-2021-21314
PUBLISHED: 2021-03-03
GLPI is open source software which stands for Gestionnaire Libre de Parc Informatique and it is a Free Asset and IT Management Software package. In GLPI before verison 9.5.4, there is an XSS vulnerability involving a logged in user while updating a ticket.
CVE-2021-27931
PUBLISHED: 2021-03-03
LumisXP (aka Lumis Experience Platform) before 10.0.0 allows unauthenticated blind XXE via an API request to PageControllerXml.jsp. One can send a request crafted with an XXE payload and achieve outcomes such as reading local server files or denial of service.