The future of technology, and thus security, is changing. Business innovation and digital transformation are changing the pace and scale at which business applications are being developed. To stay agile, application development is employing new processes, such as DevOps, and new technologies, such as containers. You hear the chants for cloud native security, but what does that mean for application security?
With the focus on portability and scalability of infrastructure and applications, containers provide the flexibility you need to adapt quickly to ever-changing business requirements. However, securing containers is a completely different problem. Containers abstract the application from the underlying operating system. Since traditional security approaches rely heavily on agents, a new approach to container security is required. It’s time for a container native approach to application security.
The Old, Traditional Way to Secure Applications
As vulnerabilities continue to shift from the host to the application, application security is continually evolving. The first phase in this evolution is Static Application Security Testing (SAST). The goal of SAST is to scan source code looking for known vulnerabilities in the Open Web Application Security Project (OWASP) Top Ten. This analysis includes custom source code, but also includes open source software. Although effective in identifying known vulnerabilities in source code, SAST does not provide runtime analysis or protection of the application in production.
The next phase is Dynamic and Interactive Application Security Testing (DAST/IAST). Initially, the goal of DAST is to scan the running application from the outside looking for known vulnerabilities in the OWASP Top Ten. This black-box approach has its limits, as it does not fully understand the business logic of the application, thus limiting its results. To improve the results, IAST instruments known details of the application to address aspects of the business logic. DAST and IAST improve the results of runtime analysis, but still fall short in protecting applications. Even integration of the DAST/IAST results with web application firewalls (WAFs) falls short in protecting applications.
Realizing that black-box, and even gray-box, testing wasn’t enough, the next phase in the evolution focuses on embedding security into the application. Initially leveraging IAST capabilities, a new market known as Runtime Application Self Protection (RASP) emerges. The goal of RASP is to analyze and protect the running application from within. By integrating directly with the application via a software development kit (SDK) or running an agent in the runtime environment, RASP can control the execution environment of the application. Just as RASP starts to gain traction, containers disrupt application development.
The Proliferation of Containers
Docker’s introduction of a standardized platform for developers and operators to build, ship, and run applications is fueling tremendous interest in the use of containers. Although not limited to Docker, containers allow you to quickly assemble applications from individual components. These container applications eliminate the friction that comes with shipping large, legacy applications. Combined with a microservices architecture, containers enable your applications to be tested and deployed into production as quickly as possible.
The use of containers creates new challenges for application security. SAST solutions have evolved to address static analysis of containers. However, runtime analysis and protection needs to evolve beyond DAST, IAST, and RASP. The limitation of existing DAST and IAST results only increases with container based applications, as the application is no longer a single piece of code. It’s a highly distributed set of microservices and containers that complicate the business logic, thus making it harder to analyze externally.
Even RASP solutions will struggle, as each container can now be a different programming language. Instead of integrating one SDK, developers will need to integrate multiple SDKs, one for each language. If the RASP vendors use an agent for protection, the RASP solution is now dependent on the underlying infrastructure. The future of IT infrastructure is quickly shifting away from dedicated hardware. Container-as-a-service (CaaS) and serverless computing trends will eliminate the dependency on the underlying hosts, thus making it harder for agent-based solutions to survive. It’s time for a new approach to container security, and thus, application security.
Three Approaches to Container Security
Knowing that securing the application from the outside has not been effective, three primary approaches for securing containers are emerging. The first two approaches rely heavily on the underlying infrastructure. These two approaches are typically known as kernel plugins and privileged security containers. Kernel plugins are pretty self explanatory, as they load a kernel module on the host to monitor container calls. Since it runs in the kernel, this approach needs access to the host and has root access, which means it has no portability to CaaS or serverless computing offerings.
Privileged security containers have a similar limitation, as they require root access to the host to gain visibility into all of the other containers running on the host. Since it relies on the host, this approach also has no portability to CaaS or serverless computing offerings either. This approach also requires the other containers to be redirected through the privileged security container to monitor container activity. This redirection adds a scalability limitation to this approach. The privileged container can only monitor approximately 10-15 other containers on that host, regardless of the compute capacity of the host. And finally, the entire deployment under this approach is less secure. By adding root privileges to the layer exposed to the external, hostile environment, privileged containers will become a target for malicious activity.
The third, and last, approach is completely different, as it embeds security within the container itself. By adding security within the container to monitor network, storage, and application calls, this approach does not require root privileges or access to the underlying infrastructure. It’s the only approach that provides infinite portability, as it supports all container environments, including CaaS and serverless computing. It also provides elastic scalability, as security moves with the container.
It’s Time for a Container Native Approach
If your organization is adopting containers, then you need to unify DevOps and SecOps by providing complete visibility and control of containerized applications through the entire lifecycle. By embedding security within the container, a Container Native Approach solves the three key challenges facing both DevOps and SecOps:
- Accurate insight into container images, including software composition, vulnerability assessment, and compliance validation;
- Adaptive analysis of running containers, including runtime activity, container communication, and behavior profiles; and
- Automated enforcement of container behavior, including behavior policies, anomaly detection, and runtime protection
In addition, it’s the only approach that provides these three key benefits for your organization:
- Zero-touch, seamless integration – No impact to the existing build, continuous integration, or continuous deployment pipelines by integrating with your existing tools;
- Infinite portability – No dependency on the underlying infrastructure, as it supports all container registries, engines, orchestrators, and orchestration platforms across any environment, cloud or on-premise; and
- Elastic scalability – Embedded enforcement moves with the containers, providing unparalleled scalability for superior real-time, continuous protection across all containers and microservices