Why Cloud-Native Applications Need Cloud-Native Security

The rise of cloud-native application architectures — and the deployment speeds they enable — are forcing many organizations to prioritize new features and functionalities over security. However, compromises that make security a low priority expose these organizations to greater risk.

Recent discoveries of API vulnerabilities and the commonplace nature of generic container configurations, for example, have combined to make modern applications highly susceptible to attacks. Enterprises cannot afford to let application security be an afterthought.

Unlike traditional applications that consisted of a single workload and required additional resources to ensure speed, today's cloud-native applications are mostly microservices-based. There are probably as many perceptions on the exact definition of the word "microservice" as there are development teams working on modern applications. Typically, however, these types of applications are broken in such a way that each individual microservice can scale independently of the others. 

If you need the application to go faster, you add more instances of the microservice that is currently acting as a bottleneck. This approach works well — except for the high likelihood of risk exposure by human error.

Cloud-Native Vulnerability
It is bound to happen. Human beings, especially when working quickly to meet deadlines, make bad judgment calls. Despite warnings, employees will continue to copy and paste blindly from Stack Exchange, make microservices out of random applications found on GitHub, and even automate these microservices to regularly pull code from a repository maintained by an unknown and only questionably trustworthy third party that the developer in question has never met, or even conversed with.

Even in instances when all code is written in-house, removing the risk of third-party actors, the distributed nature of a microservices-based application means that each component can be "owned" by a different team. Communication barriers between teams can lead to all sorts of problems, among them a lack of coordination regarding testing, quality assurance, and even the resolution of vulnerabilities in the application.

A single cloud-native application can consist of thousands of workloads spread across multiple infrastructures. There can be individual microservices in on-premises data centers, multiple public clouds, edge data centers, and, eventually, in network locations we have yet to develop.

Each developer — and each team of developers — knows how to solve different problems. What they work on determines their focus and shapes their experience. Even if every team were to somehow make their own piece of the larger application "secure," from an internal code perspective, that microservice needs to communicate with others, and that communication is a point of vulnerability. 

The bad guys — and even paying customers — are well known for doing things to applications that developers simply didn't anticipate, often creating vulnerabilities in implementation and execution that aren't visible with a simple code revision. In addition, each infrastructure applications can run on has a different security model, with different controls to be learned. Every difference is scope for further vulnerability in implementation.

This all sounds super scary. But cloud-native applications evolved for a reason. They solve very real problems and are not going away, creating a serious need to secure them. So, what can we do?

Learn, Adapt, Implement
We might call an assemblage of thousands of interoperating workloads a single application, but that doesn't mean that it is one. A cloud-native "application" is, in fact, a whole bunch of individual applications that are stitched together with automation orchestration — and a demographically disproportionate amount of caffeine.

Each and every microservice template (from which the multitude of instances are spawned) needs to be treated like its own application, when considering patching and code sourcing. It needs to be regularly updated, code must come from only known-good places and any changes in code should be tested before being allowed into production. That includes changes made to third-party repositories.

But each microservice instance — or in the worst case, group of similar instances on a single host or pod — needs to be treated like an application to ensure security. Data that flows in and out needs to be analyzed, baselined, and monitored for unexpected deviations.

Dependency management and copy data management applications can help with the template herding, but securing running instances means existing network security defenses — firewalls, advanced threat protection, command-and-control sensing, and so forth — all need to get smaller. They need to fit in containers and be able to run alongside microservices. They need to be as easy to automate and orchestrate as the microservices they defend.

The important part here, however, is that there needs to be more than just the bare-bones firewall offered up at the edge of every virtual data center a public cloud provides. Just as lateral movement can occur when an application in a traditional, on-premises data center is compromised, lateral movement can occur within an application (or at least within the portions of the application that live in that virtual data centers) when one of its microservices is compromised.

Today's cloud-native developers and the enterprises they work for need to prioritize security in order to reap the speed and feature benefits these applications and new architectures provide.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Is Voting by Mobile App a Better Security Option or Just 'A Bad Idea'?."