Ben Bernstein, CEO, Twistlock, shares six runtime threat detection and response tips for container security.
Security for containers has evolved quite substantially over the past year, but there is still a lot of education that needs to be done. The key point being that the biggest difference in this new paradigm is that everything is based on continuously delivered, micro-service based, applications. The fact that the technology enabler for that paradigm is containers is less of an issue.
When it comes to containerised applications, everyone needs to be in agreement – statically analysing what an application can do inside a container and rejecting non-security compliant images and/or vulnerable images is a must. However, no matter how good a job you do with vulnerability scanning and container hardening, there are unknown bugs and vulnerabilities that may manifest in the runtime and cause intrusions or compromises. That is why it’s so important to outfit your system with real-time threat detection and incident response capabilities.
One might point out rightfully that there are good tools for limiting what an application can do in the form of SELinux and AppArmor. While these are good tools for some tasks, and limit several aspects of what an application does at runtime, expecting your development team to create deep and thoughtful security manifests for all micro-services they create is not realistic and does not scale. I’ve yet to see a large development team adopt this type of security solution for containers at scale.
Here we find ourselves back at the core of the problem – as more and more critical applications move to the container environment, organisations need a scalable and proactive defense layer that allows them to get ahead of the threat curve. At the same time, this defense layer should enable innovation and the adoption of container technologies. The following six tips outline how runtime threat detection and response should be designed to detect real-time threats, anomalies, and active compromises, with a lower false-positive rate than what is seen with traditional anomaly detection:
* Use the declarative nature of the new stack. While developers don’t have the bandwidth to care much about security, they are now required to provide more information as part of the development process. They know which processes are going to run, they know which binaries are going to be used, and they implicitly tell the system about the interactions between containers. That information might exist in the Dockerfile, or it might be in the one of the YAML files that describes how the system is to be orchestrated. One should take that information and automatically translate that into a security profile of what the endpoint should and shouldn’t do.
* Identify the Lego pieces. Developing containers is fun and easy. While you do have more responsibilities, you can easily reuse layers of operating systems and services that are ready made for you, which require you to only tweak some of their configuration. For security baselining, this makes life much easier. If you recognise that 90 percent of the container is actually a known backend application, doing a relatively simple scan of the changes in the 10 percent that is left, you can easily see what these lego pieces are up to.
* Establish baseline behaviour. You’ve likely heard about machine learning a lot recently, but the truth is, it’s a complicated business and hard to get right. Luckily, containers can actually help. With machine learning, you typically need to have a baseline from which you learn from, and containers are the perfect candidate. They are minimalistic in nature and involve a more limited set of actions then a virtual machine. Security solutions should baseline the application and make use of that.
* Immutability. Immutability means killing an unpatched container, and then pushing a new patched container into production instead of updating it ‘in the field’. While this might sound like a minor detail, this actually allows the endpoint security, for the first time, to treat any polymorphic change in the behavior of the containers as an indication of threat or an indication of a configuration drift.
* Automate runtime threat detection. Doing each of the preceding steps is no trivial matter, and one can not expect to do each one manually, so you must make sure that any process that qualifies to make it into production gets automatically secured. To emphasise the point, it is virtually impossible to ask an IT person to work with each owner of a micro-service and make sure the container is secure. You must adopt a system to automatically “wrap” the container at runtime with security.
* Don’t interfere with application logic. Unlike traditional endpoint detection, you can’t just install an endpoint detection mechanism on each container. Best practice is to have your solution look into running containers from the “outside”. The reason for that is, in order to play by the rules, you are not allowed to modify the containers that developers handed to production. If you change an image, you’re breaking the ability of developers to directly analyse problems with it and must quickly provide resolutions to any issues.
Organisations who implement container-based workflows or run containers in production must consider security from the very beginning or risk suffering security vulnerabilities. Luckily, better security tools exist today, and by leveraging the tips listed above, any business can make their container stacks secure.
