Shift Up: New Security Considerations for Containers-as-a-Service and Serverless Architectures

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!

While containers can create more secure application development environments and dramatically speed up development, they can also introduce new security challenges. Containers are applications vulnerable to privilege escalation, zero-day attacks, hostile takeovers, and data exfiltration, and the later you discover a problem, the more difficult it is to mitigate the damage. This compelsDevOps and information security teams to facilitate security's"shift left" to the beginning of the development cycle. However, shifting left does not address the fact that deploying containers and migrating to cloud-native environments also necessitates the security team to “shift up” to focus on its new priority: protecting the application tier.

The world is quickly moving away from the on-premises environment to cloud-based and serverless environments where control of the middle — i.e. the network, host, and enforcement points —is no longer in the hands of the organization that’s producing the workload. This creates a gap between what security organizations are able to do with the tools they have, and their ability (or rather, inability) to execute those controls in the computing environment.

Shift Left, Then Shift Up

The security team works with DevOps to shift left in order to identify and remedy potential security issues with applications before they move into production and throughout the development cycle. Yet, while shifting left is absolutely necessary, that alone is not sufficient to address the new security issues containers can create.

For example, shifting left does not provide for an effective incident response because that has everything to do with what controls the security team has over the runtime environment. Effective incident response requires identifying the incident, understanding its causes and potential effects, then deciding on whether or not to take action.

However, shifting left does not address the fact that deploying containers and migrating to cloud-native environments also necessitates the security team to“shift up” to focus on its new priority: protecting the application tier.

Consider just one aspect of how security is managed in the runtime environment. In a traditional server infrastructure on-premises or in the cloud, where you have an application running on an operating system, the standard approach is to install anti-malware on the operating system of a VM so that if the application is compromised and the malware tries to impact the OS, the anti-malware stops it.

If your organization is using AWS Fargate or Microsoft ACI, where do you install anti-malware? You don’t, because the traditional location for executing security policies in the middle layers are no longer in your purview. More security organizations are realizing those controls are important to address even after they have worked with DevOps to facilitate the shift left. This represents a sea change from the days when security had to concern itself primarily with securing networks, hosts, and endpoints.

Effective incident response requires identifying the incident, understanding its causes and potential effects, then deciding on whether or not to take action.

How to Shift Up?

The first step is to come to the realization that you can’t execute controls and policies in the traditional way. There has to be more thought put into what controls need to be executed and where. Some tasks will shift left, like understanding what potential vulnerabilities or deficiencies exist in somebody’s code and how the configuration of the image could create a potential takeover situation. Others remain in the runtime, such as monitoring what containers are doing and understanding what software is running in them.

Another major change is the loss of the enforcement point on the underlying operating system. Of course, it has to go somewhere— ideally inside the container where you will execute the controls, manage incident response controls, etc. A different solution is required because you’re operating in a different environment.

Consider all 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 attacks. Shifting up requires you to spread these controls among the container, orchestration, and development environments. You can’t execute that with your existing security tools because all of those tools were based on being embedded into the underlying operating system, which is no longer available.

Strengthening Your Security Posture

One primary benefit of shifting left is that you reduce the surface area for an attack. Containers and cloud-native applications enable the use of thin, hardened hosts that only require those resources needed for the container engine. Their smaller perimeters make identifying anomalies and suspicious activities easier because you’re analyzing data from a much smaller pool of permitted actions.

Shifting up further minimizes the attack surface by allowing only what the application needs, and preventing users from adding any other processes, benign or not. This requires implementing a solution that enables you to maintain the container’s single purpose and user, thereby ensuring that even a compromised container is useless to attackers.

Shifting up further minimizes the attack surface by allowing only what the application needs, and preventing users from adding any other processes, benign or not.

Another key similarity between shifting left and shifting up: don’t leave security to the very end. The first step to solving any problem is realizing one exists. Disappearing enforcement points, changing areas of responsibilities, and the increased speed of application development are all forces driving the need for the security organization to shift up. Security can’t ignore the upper layers of the deployment stack. Once confronted with how much controlDevOps has over the entire stack, it becomes clear that security needs to shift up to focus on protecting the application layer.

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!