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

2/5/2019
04:10 PM
Dror Davidoff
Dror Davidoff
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Mitigating the Security Risks of Cloud-Native Applications

While containers can create more secure application development environments, they also introduce new security challenges that affect security and compliance.

Containers represent the most significant computing advancements for enterprise IT since VMware introduced its first virtualization product, Workstation 1.0, in 1999. They enable organizations to build, ship, and run applications faster than ever, fueling the rise of the DevOps movement. It's important for CISOs to realize that while containers can create more secure application development environments, they also introduce new security challenges that impact security and compliance when rolling them out in production.

When talking to our customers, many cite a common challenge: how fluid and dynamic the landscape has become. Three years ago, container technologies were almost exclusively used in development, and in the move to production the live systems running in the data center were refactored to address operational requirements. In this window, the security team had plenty of time to evaluate risks and provide late-stage guidance to ensure compliance. At the time, Docker was by far the dominant technology in use.

Fast forward to today, when enterprises are implementing multiple technologies like Kubernetes for orchestration and alternate technologies such as serverless functions from all of the big cloud vendors, then deploying them "continuously" into production. The window for the security team to properly review the application and its infrastructure has become much shorter, if it still exists at all.

Security Issues
Traditional security tools cannot handle the velocity, scale, and dynamic networking capabilities of containers. Taking this a step further, serverless functions prioritize simplicity and agility by abstracting infrastructure concerns to provide a simple execution environment for applications and microservices. Attackers may leverage a vulnerability in base images used for containers, outsourced libraries or in serverless function code; or take advantage of vulnerabilities inside the cloud infrastructure's permissions settings to reach services that contain sensitive information.

The reliance on open source applications or code snippets creates another security vulnerability. No one's writing new code from scratch; everyone is grabbing components from GitHub, Docker Hub, and other open source repositories, leveraging other code written earlier for other projects inside the company. The people writing the code may not be as familiar with what they're starting with, nor with any vulnerabilities that may be present (or show up later after they embedded the borrowed code). They also use general-purpose apps that encompass many more capabilities and privileges than their specific applications actually require — creating an unnecessarily large attack surface.

Shift Left, and Then Shift Up
DevOps and information security teams should work together to address these challenges by facilitating security's "shift left" to the beginning of the development cycle. Shift left is a well-understood concept in developer circles, and it needs to become just as familiar from a security perspective in order to identify and remedy potential security issues before they move into production.

Security must also "shift up" to focus on its new priority — protecting the application layer — and success requires making these new controls and processes mandatory. The shift-left concept can't fully address the new security issues that containers and serverless functions can create. For example, shifting left does not provide for effective detection and incident response in the case of a new zero-day attack on a running container. Effective incident response requires identifying the incident, understanding its causes and potential effects, then making a decision regarding appropriate action — something that is only possible with controls over the runtime environment.

Consider concern for securing the runtime environment. In a traditional server infrastructure on-premises or in the cloud, the application runs on a virtual machine (VM), and anti-malware is installed on the VM operating system. If the application is compromised, the anti-malware solution stops it. But if you are using AWS Fargate or Azure ACI, where do you install anti-malware?

The traditional location for executing security policies in the middle layers is no longer under your control. The serverless model exacerbate the problem, and security organizations are realizing these controls remain critically important to address even after they have worked with DevOps to facilitate the shift left. The "enforcement point" on the underlying operating system has to go somewhere — ideally inside the container where you will execute the controls, manage incident response controls, etc. All the controls that were once executed in the operating system: Preventing rogue deployments and malicious code injections, securing user credentials, guarding network connections, and thwarting zero-day attack are still critical. Shifting up requires you to spread these controls among the container, orchestration, and development environments.

You must decide what controls need to be executed, and where. Some things will shift left, including understanding what potential vulnerabilities or deficiencies in application code as well as the configuration of the image. Others should be implemented in the runtime, such as monitoring what containers are doing and understanding what software is running in them, requiring a shift up to protect these new infrastructures. That's how security becomes a facilitator to the DevOps movement and seen as an ally in releasing secure applications quickly on these newer cloud-native infrastructures.

Related Content:

Dror Davidoff is co-founder and CEO of Aqua Security. Dror has more than 20 years of experience in sales management, marketing, and business development in the enterprise software space. He has held executive positions at several emerging IT security and analytics companies. ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
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-2019-16772
PUBLISHED: 2019-12-07
The serialize-to-js NPM package before version 3.0.1 is vulnerable to Cross-site Scripting (XSS). It does not properly mitigate against unsafe characters in serialized regular expressions. This vulnerability is not affected on Node.js environment since Node.js's implementation of RegExp.prototype.to...
CVE-2019-9464
PUBLISHED: 2019-12-06
In various functions of RecentLocationApps.java, DevicePolicyManagerService.java, and RecognitionService.java, there is an incorrect warning indicating an app accessed the user's location. This could dissolve the trust in the platform's permission system, with no additional execution privileges need...
CVE-2019-2220
PUBLISHED: 2019-12-06
In checkOperation of AppOpsService.java, there is a possible bypass of user interaction requirements due to mishandling application suspend. This could lead to local information disclosure no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVers...
CVE-2019-2221
PUBLISHED: 2019-12-06
In hasActivityInVisibleTask of WindowProcessController.java there?s a possible bypass of user interaction requirements due to incorrect handling of top activities in INITIALIZING state. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction ...
CVE-2019-2222
PUBLISHED: 2019-12-06
n ihevcd_parse_slice_data of ihevcd_parse_slice.c, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android...