The Cloud Native Security Reboot

Are we proper focusing our efforts on securing cloud native deployments correctly?  

It’s a big question and potentially, a disruptive one.   

What if I were to suggest a shift-right just for a moment before shifting left?

What if our shift-left obsession can fool us into creating yet another silo that does not take into account the holistic security of our applications. A byproduct of shifting left can be neglecting what happens on the right.

Then and Now

Let’s consider the old and familiar world of application development and deployment starting with the "infosec" world.  Our assets were servers in data centres and developer and employee systems like laptops and PCs.  

Firewalls, intrusion detection systems, malware and virus detection systems and other endpoint detection systems were our critical defences against a constantly adapting cyber attack. 

Information security has been keeping us safe from the baddies since the the floppy disc enabled the average computer to spread viruses on a global scale.   

Over the past 5-20 years the world has been awoken to the vulnerabilities, not just of the computers themselves, but the applications which run on them.  New and exciting application security challenges gave rise to OWASP and its infamous top 10.  As web applications have advanced, so have the complexity of the attacks.  Somehow injection is still topping the charts but nevertheless, new entries such as deserialisation attacks and the disappearance of CSRF are showing us that as quickly as we find new ways to compensate for one attack vector, we pivot our coding choices to new languages and architectures to enable two more.   

Vulnerability management has become a nightmare at best.  Point solutions which identify potential cracks in our defences are expanding such that we are aggregating them into a somewhat unmanageable “single pane of glass”, or as a colleague once said in comedic error, "single glass of pain". From there we can all gaze with a triumphant slow single tear at the incomprehensible blinking lights, pies and histograms of our security debt.  

Security tools are great at providing vulnerability data but generally poor at telling us what to do with it.  We talk about shifting left because we have acknowledged the cost of our efforts and our mental health are factors of 10 larger on the right. 

Head in the Clouds

Shifting gears to take a look at the advent of cloud native, we have a new prevalent architecture and a new stack.  The cloud and its micro-service architectures have empowered applications and businesses with the ability to scale on highly reactive and very granular requirements.  This transformation has not only given a home to containerisation (which sat in a lonely contemplative corner throughout the 2000s), but one might argue it has changed the way we should be thinking about how we secure our new world. 

Containerisation has for better or for worse, disrupted the silos of information and application security.  It has given justification and strengthened the culture of DevOps as well as its elusive futuristic shadow that is DevSecOps.

As security professionals, we are doing the right thing.  We are applying the skills and methods that we know.   It’s all we can do.  I would suggest however that we consider our options within the cloud native stack and attempt to assess whether we are prioritising our efforts correctly.

Let’s start with micro-services and ask ourselves what a good microservice looks like.  Ideally minimal.   One process with minimal encrypted and authenticated interactions with other services.  Our service is running within a container exhibiting least privilege, created either from scratch or using a base image with no more than what is required to execute its singular function.   

Unlike the old complex, multi-functional monolithic applications, running on a server with a densely populated operating system trying to be all things to all programs, we now have an easily characterisable building block whose capabilities are limited and “contained” by a runtime environment.  We are more often than not also executing on a virtual machine somewhere on a server in the cloud.   

Let’s assume the cloud configuration of the host is solid but acknowledge this is a big assumption!   

The advantages we gain in terms of being able to profile a container’s purpose and behaviour are large.  Add to this the possibilities of automating our awareness of any potential known vulnerabilities such that compensating controls or developer container redesign can be a fast flowing part of our CI/CD workflow and culture. 

Imagine if we can harness the container runtime environment to use the profiling of our container to automatically whitelist good behaviour.  This could be anything from providing runtime process immutability to automating micro-segmentation of our new network paradigm within the micro-service application (a.k.a. the cloud native firewall).

What is the end result?  

Securing the building block to secure the application.

Your application is no longer a single complex monolith, but a complex and loosely coupled mesh of ideally quite simple building blocks. A Rube Goldberg machine comes to mind. Let’s realise that we have new security super powers under our belt.  

• Micro-services (the building blocks) are more secure in their simplicity.  (Smaller code bases are proven to be better codebases.)
• We have the isolation of namespaces and a runtime.  
• It is possible to learn the inventory and its risk profile of an image early in the container lifecycle.  
• We can characterise our workloads and image with tactical metadata.
• It is possible to confine the behaviour of a container at runtime (both network behaviour and process and system calls) 

Conclusion: If we extend this capability across all services which now define the full functional business behaviour, we can secure the business logic of the application by proxy of securing the granular capabilities of each component piece.  The resulting security posture is in fact greater than the sum of our security parts.  

Via granular runtime controls which can be applied and reused independent of the application end purpose, many of the known and unknown security vulnerabilities present in our running workloads/services are rendered inert out of the box. Certainly attack vectors which require the cascading of vulnerabilities are even considerably negated.  

This is what I meant by briefly shifting right before shifting left.  Implementing runtime controls to a micro-service architecture early in the process could actually be considered priority one before we get distracted by scanning images, hosts or other compliance requirements. Whilst bringing an awareness to the SOC is essential, in may serve in the short term only to complicate the already overwhelming vulnerability management behemoth. 

We can provide security first, before compliance.  We can shift right to breathe easier and then we, the security, development and operations known sparingly as DevSecOps, can shift left to consider the known vulnerability inventory.  If we can do this in combination with awareness of the external threat landscape to allow for the amplification and prioritisation of our security debt, the result a tangible focused mitigation of real risk.