The Power of Application Intent Analysis for Container Security [I] - John Morello, Twistlock
Abstract
As containers gain mainstream momentum and cloud-native applications surge, practices such as DevOps culture, continuous delivery, cloud development and containerization require a reinvention of security. The threats targeting organizations only continue to increase in severity and frequency, and even simple attacks can cause considerable damage. Cloud-native development is a vital evolution for security in the enterprise, as it equips organizations with the same tools and processes that modern fast-moving organizations rely on. Cloud-native needs to be considered a new culture, not just a technological shift, when it comes to IT. This is because cloud-native changes the processes of DevOps, which requires automated security processes and application awareness. With cloud-native culture, security needs to be truly application aware and based upon developer intent. Using application intent analysis, developers have a new way of looking at applications, specifically containerized apps. They can produce produce a more predictable and secure container environment that can be effectively enforced. The unique nature of container technology allows the developer intent-based security model to capitalize on the following pillars: 1. Containers are declarative. When a developer writes the code, he/she does not just write the code, he/she writes a manifest that describes how this code should work and how it should interact with its environment. While the developer does not provide you with a real security manifest, you can translate the extra information that you have and try to create a security profile. With containers, you have a Docker file, you might have a pod, and you might have an application group if you’re running on top of mesosphere. There is a lot of information in the system that you could use in order to understand what is supposed to happen. 2. Containers are predictable. When you look at containers, they contain less specific logic and more common building blocks because containers are typically made out of downloadable layers that someone else created. 3. Containers are immutable. In the past, it was hard to understand if something happening with the application was really an attack or not. But in the case of containers, whenever you patch a container or change its real intent, it should not happen in real time. What happens is the developer changes things and then he/she pushes in a new version. He patches the OS or adds new functionality and then pushes in a new container and scratches the old one. This gives you a lot of power from a security standpoint because, for the first time ever, if you see a polymorphic change in the behavior of the application (if it starts behaving differently) that means it’s either a configuration drift or a real attack. By leveraging these three pillars – declarative nature, predictability and immutability – there’s a powerful opportunity to use whitelisting, for example, to approve known good processes. In combination with application intent analysis, enforcement measures help support the intent-based security model and preserve the original intent of the application.