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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: -when I told you that our cyber-defense was from another age
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-3349
PUBLISHED: 2019-11-19
lightdm before 0.9.6 writes in .dmrc and Xauthority files using root permissions while the files are in user controlled folders. A local user can overwrite root-owned files via a symlink, which can allow possible privilege escalation.
CVE-2019-10080
PUBLISHED: 2019-11-19
The XMLFileLookupService in NiFi versions 1.3.0 to 1.9.2 allowed trusted users to inadvertently configure a potentially malicious XML file. The XML file has the ability to make external calls to services (via XXE) and reveal information such as the versions of Java, Jersey, and Apache that the NiFI ...
CVE-2019-10083
PUBLISHED: 2019-11-19
When updating a Process Group via the API in NiFi versions 1.3.0 to 1.9.2, the response to the request includes all of its contents (at the top most level, not recursively). The response included details about processors and controller services which the user may not have had read access to.
CVE-2019-12421
PUBLISHED: 2019-11-19
When using an authentication mechanism other than PKI, when the user clicks Log Out in NiFi versions 1.0.0 to 1.9.2, NiFi invalidates the authentication token on the client side but not on the server side. This permits the user's client-side token to be used for up to 12 hours after logging out to m...
CVE-2019-19126
PUBLISHED: 2019-11-19
On the x86-64 architecture, the GNU C Library (aka glibc) before 2.31 fails to ignore the LD_PREFER_MAP_32BIT_EXEC environment variable during program execution after a security transition, allowing local attackers to restrict the possible mapping addresses for loaded libraries and thus bypass ASLR ...