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
Newest First  |  Oldest First  |  Threaded View
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
How Security Vendors Can Address the Cybersecurity Talent Shortage
Rob Rashotte, VP of Global Training and Technical Field Enablement at Fortinet,  5/24/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7068
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7069
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have a type confusion vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7070
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7071
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.
CVE-2019-7072
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .