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
Russia Hacked Clinton's Computers Five Hours After Trump's Call
Robert Lemos, Technology Journalist/Data Researcher,  4/19/2019
Why We Need a 'Cleaner Internet'
Darren Anstee, Chief Technology Officer at Arbor Networks,  4/19/2019
4 Tips to Protect Your Business Against Social Media Mistakes
Guy Bunker, CTO of Clearswift,  4/22/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-16558
PUBLISHED: 2019-04-25
Contao 3.0.0 to 3.5.30 and 4.0.0 to 4.4.7 contains an SQL injection vulnerability in the back end as well as in the listing module.
CVE-2018-18369
PUBLISHED: 2019-04-25
Norton Security (Windows client) prior to 22.16.3 and SEP SBE (Windows client) prior to Cloud Agent 3.00.31.2817, NIS-22.15.2.22 & SEP-12.1.7484.7002, may be susceptible to a DLL Preloading vulnerability, which is a type of issue that can occur when an application looks to call a DLL for executi...
CVE-2018-19442
PUBLISHED: 2019-04-25
A Buffer Overflow in Network::AuthenticationClient::VerifySignature in /bin/astro in Neato Botvac Connected 2.2.0 allows a remote attacker to execute arbitrary code with root privileges via a crafted POST request to a nucleo.neatocloud.com:4443/vendors/neato/robots/[robot_serial]/messages Neato clou...
CVE-2019-9135
PUBLISHED: 2019-04-25
DaviewIndy 8.98.7 and earlier versions have a Heap-based overflow vulnerability, triggered when the user opens a specific file that is mishandled by Daview.exe. Attackers could exploit this and arbitrary code execution. .
CVE-2019-9136
PUBLISHED: 2019-04-25
DaviewIndy 8.98.7 and earlier versions have a Heap-based overflow vulnerability, triggered when the user opens a malformed JPEG2000 format file that is mishandled by Daview.exe. Attackers could exploit this and arbitrary code execution.