Twistlock was created specifically to ensure security and compliance for containerized applications – and specifically because traditional solutions do not extend to containerized environments. Here are some examples:
1. Vulnerability Scanning: Static registry scanning solutions were built to scan application components in a world before containers. They are working to add more components of modern Docker images, but come up short compared to Twistlock. Twistlock uses specific sources for every element of a Docker image – nothing will fall through the cracks. Twistlock sources its CVE, threat and malware data from over 30 different upstream providers. This gives Twistlock’s data much better coverage than you typically see from existing scanners. Additionally, we source CVE data directly from vendors which gives you contextual information about the vulnerability and how it affects a specific OS and version. By having this better data, we reduce the number of false positives to near zero.
2. Prioritization: Twistlock generates a risk score for each of the vulnerabilities we find that are actually running in your environment. We take in to account not only the CVSS score, but also a whole host of other metrics. For example: “Is this container connected to the internet”, “Does it have open listening ports”, “Does it have a security profile attached”. This allows us to stack rank your vulnerabilities specifically for your environment and let you know where you are most likely to be exploited. This helps to prioritize the mitigation of vulnerabilities for your most vulnerable assets.
3. Prevention: Twistlock doesn’t just tell you the issues, it can actively halt the lifecycle promotion of an image if it fails a policy. For example, failing a build and thus preventing the push to a registry if high vulnerabilities are found in the image or blocking the deployment of a container if its image contains a critical vulnerability. Our alerting and enforcement policies cover the entire CI/CD process from build, ship to runtime.
4. Compliance with Configuration Best Practices: It is equally important to ensure containerized applications environements are using best practices for security and configuration – registry scanning systems do not do this. Twistlock embeds all the Docker CIS Benchmarks right in the product, out of the box, and enforces or alerts on policy violations for the entire customer environment. Much like our Vulnerability Prevention – policies can be created to ensure containers are deployed in a secure fashion, for example: “Block the deployment of a container if the root file system is not mounted as read only” or “Block the deployment of a container if there is no security profile attached to it.”
5. Runtime Vulnerability Management: What happens when a new and very critical CVE is announced and affects a container’s image in your runtime environment? A customer needs to know everywhere that CVE exists so that they can roll out an updated image to replace it. No static registry scanning solution would have that insight into the running container environment.
6. Runtime Whitelist: Even if a customer succeeds in promoting relatively clean images into a relatively compliant environment, without Twistlock they lose visibility into those images the moment they begin running as containers. A host IDS, or legacy firewall product, only understands host activity – and nothing within the container environment: with no visibility into container network activity or container processes/file system activity/system calls. Twistlock models each container and only allows the container to do what the model allows. This protects the container from intrusion, use as an attack vehicle or modification from an insider.
7. Runtime attack forensics: Twistlock captures and correlates attack events and shows them with easy visualization, including a lasting record of the attack events. Without Twistlock a customer will lose all attack data when the containers are replaced.
8. Runtime Active Threat Protection: Twistlock feeds include constantly updated Malware and APT data and check that against running containers to block such attacks. Without runtime protection, a customer’s existing security solutions will not have visibility into running containers and attacks being targeted against them.
In summary, Twistlock believes in multiple layers of defense. And, we believe all non-container specific solutions will be missing a critical layer that Twistlock provides – container specific vulnerability management, compliance with container configuration best practices, and runtime protection that is automated and easy. That last layer, the runtime layer, has been so hard for security products to deliver – until now with containerized applications and Twistlock.
To learn more, contact us for a demo today.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
What Service Meshes Mean for Enterprise Security
Service meshes: Heard of them? By now, you may have. Service meshes ar...
The Business Value of Cloud Native Cybersecurity
“Software is eating the world,” Marc Andreessen wrote in 2011. Fiv...
How To Operationalize DevSecOps Practices
DevSecOps is not as much about the tools as it is about the people and...
Enhanced Visibility: Container Vulnerability Management from Build to Runtime
Earlier this year, I was at a large industry event and ended up speaki...
How Serverless Changes the Security Paradigm
Serverless architectures are quickly becoming a major technology withi...