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

10/29/2019
02:00 PM
Trevor Pott
Trevor Pott
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Why Cloud-Native Applications Need Cloud-Native Security

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

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'?."

Trevor Pott is a Product Marketing Director at Juniper Networks. Trevor has more than 20 years of experience as a systems and network administrator. From DOS administration to cloud native information security, Trevor has deep security knowledge and a career that matches the ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/13/2020
Where Are the 'Great Exits' in the Data Security Market?
Dave Cole, Cofounder and CEO, Open Raven,  10/13/2020
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15256
PUBLISHED: 2020-10-19
A prototype pollution vulnerability has been found in `object-path` <= 0.11.4 affecting the `set()` method. The vulnerability is limited to the `includeInheritedProps` mode (if version >= 0.11.0 is used), which has to be explicitly enabled by creating a new instance of `object-path` and settin...
CVE-2020-15261
PUBLISHED: 2020-10-19
On Windows the Veyon Service before version 4.4.2 contains an unquoted service path vulnerability, allowing locally authenticated users with administrative privileges to run malicious executables with LocalSystem privileges. Since Veyon users (both students and teachers) usually don't have administr...
CVE-2020-6084
PUBLISHED: 2020-10-19
An exploitable denial of service vulnerability exists in the ENIP Request Path Logical Segment functionality of Allen-Bradley Flex IO 1794-AENT/B 4.003. A specially crafted network request can cause a loss of communications with the device resulting in denial-of-service. An attacker can send a malic...
CVE-2020-6085
PUBLISHED: 2020-10-19
An exploitable denial of service vulnerability exists in the ENIP Request Path Logical Segment functionality of Allen-Bradley Flex IO 1794-AENT/B 4.003. A specially crafted network request can cause a loss of communications with the device resulting in denial-of-service. An attacker can send a malic...
CVE-2020-10746
PUBLISHED: 2020-10-19
A flaw was found in Infinispan version 10, where it permits local access to controls via both REST and HotRod APIs. This flaw allows a user authenticated to the local machine to perform all operations on the caches, including the creation, update, deletion, and shutdown of the entire server.