Enterprises across virtually all industries are adopting cloud native technologies to enable business growth and ship applications faster than ever.
Even as container adoption rates surge, the cloud-native infrastructure continues to evolve, and now includes Container-as-a-Service (CaaS) and Serverless functions. Even VMs can now be deployed using a DevOps pipeline in a cloud-native model. These developments have been both beneficial and disruptive, and they require an evolution of security practices and tools. Security practitioners need to rethink both the approach and technology to be used in these newer architectures.
To the external user, an application looks exactly the same whether it is running in a container, a function, in the Cloud or on premises. Applications, regardless of where and how they are deployed, are still vulnerable to cyber threats such as privilege escalation, zero-day attacks, hostile takeover and data exfiltration.
Internally, the way that cloud-native applications are delivered gives developers a lot more say in component selection, security settings and overall risk posture. DevOps and information security teams must work together to "Shift Left" good security practices towards the beginning stages of the development cycle.
With that, security must also “Shift Up” to focus on protecting the application tier after deployment. Success requires making these new controls and processes mandatory and to automate them whenever possible. There are a number of models for deploying cloud-native applications:
- Entire virtual machines, usually in the cloud, which are managed as stateless assets, provisioned with automation and require minimal or no manual administration.
- Containers managed in the data center or on a cloud provider’s infrastructure, using clusters of hosts that run nothing but containers, often with an orchestration layer.
- Serverless containers, where the cloud provider manages the entire container infrastructure, including the underlying hosts and orchestration.
- Serverless functions that provide an even more on-demand, infrastructure-less way to run code.
- Hybrid deployments which could combine all the methods above to deliver a complete application, implementing each component where it fit best in the technology stack.
Regardless of the underlying technology, it is required to secure these applications, especially when they handle sensitive data (like credit card details or personally identifiable information) or provide mission-critical business services. While each deployment model poses unique challenges, they all share common properties that need to be considered when implementing an effective security policy.
One common challenge is the dynamic nature of these computing environments. The infrastructure used to support application deployments is constantly provisioned and torn down. With cloud providers assuming a larger portion of the technology stack, the IT operations team no longer has complete control over the physical network infrastructure, choice of host operating system and even placement of services as they are moved across data centers in different locations. In some cases, IT operations and security teams don’t even know where workloads are running, as is the case in serverless models.
For security, this goes to the heart of the disruption. Most capabilities for application protection and risk reduction were developed with the assumption that enforcement points can be deployed on the perimeter, inside the internal network and on host operating systems.
Another assumption is that workloads and IT assets are known and their location mostly static. These assumptions are no longer valid, as more organizations shift from deploying in on-premises server environments to cloud-native and serverless. There, the control of the infrastructure tiers no longer rests in the hands of the organization that owns 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 apply the required controls in these new computing environments.
Closing this gap calls for the security team to work with DevOps to Shift Left: identify and remedy potential issues with applications before they move into production. Because once a cloud-native workload is deployed, it cannot change, and any risk from the early stages of the pipeline will carry over into production. Some controls will Shift Left easily, including understanding and remediating risk in components and configuration of the image. Other controls must be executed at runtime, such as monitoring what workloads are doing and protecting the software running in them against misuse or hostile takeover.
A larger gap is at runtime, and it results from the loss of enforcement points on the underlying operating system: controls like preventing rogue deployments and malicious code injections, securing user credentials, guarding network connections and thwarting zero-day attacks. Now, as application micro-services are spread across environments where the operating system has largely been abstracted, those controls need to go somewhere - ideally inside the container or function, closer to where the application processes execute. This is Shift-Up.
Organizationally, Shift Left and Shift Up mean that security needs to be embedded along the application development cycle, and not just bolted on at the end. Security, by its nature, is meant to slow things down and provide an opportunity for assessment and review. In a highly automated and fast-moving DevOps environment, security by observation and response is not sustainable. Security tooling needs to match the speed of application development and the deployment cycle, and the only way to do this is through automation.
Automating risk scanning on the early (left) side of the pipeline has now become best practice, and it is certainly an improvement. But implementing only Shift Left ignores the upper layers of the application stack. 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. Once confronted with how much control DevOps has over the entire stack, it becomes clear that security needs to focus protection on the container and application layers. Doing so enables the organization to harness the benefits that technologies like containers and serverless offer, while reducing risk.
Cloud native environments offer several traits that make them easier to secure if managed correctly. Containers are created from images and are deployed, rather than installed. They are meant to be immutable - i.e. not undergo any changes or patching in runtime and only be refreshed from original images.
Containers are often used in microservices applications, which means that each container performs a simple function, so behavior can be more easily profiled to prevent improper activity. And finally, container images are declarative - meaning that their contents can be used to learn of their intended use. Functions follow similar concepts but are often even more constrained in scope.
Embracing Shift Left and Shift Up to create an entirely new approach to application security will enable an organization to create a highly controlled environment where the attack surface is greatly reduced before the application is deployed, and then during runtime it’s easy to detect and automatically respond to threats in a very granular way. The net result is that the next generation of applications will be more secure by design and more reliable without interrupting DevOps workflows.