Invision Container Security
When InVision, a New York based innovator in product design platforms, got to try out containers, they immediately saw the value proposition for their business. The company recognized the power that Docker brings, from the consistency of the code across environments, to the ability to cut operation costs, and rolling out code in an efficient and effective manner with zero downtime.
Previously a traditional shop as far as its technology stack, InVision dove head in and started leveraging containers across their applications.
Like many other firms, InVision started with Docker in development. They spent time containerizing local environments, working with Docker primitives, including Docker Engine, Docker Compose, Docker hub, etc. That effort was very successful: Operational costs have gone down; the company saw big benefits in the ability to pack multiple services into a single host. It has also streamlined and improved the company’s CI/CD processes and improved consistency among environments.
Next they moved to incorporating CI/CD processes, also started using Kubernetes in some of their production environment. InVision runs its infrastructure in AWS, with stringent security requirements, enforced by a security team whose job is to shore up everything in their AWS environment.
Even though container deployment was in its early days and container security was a fairly new territory for InVision, the company knew they wanted to make security a priority from the get go in order to deliver the most secure experience to their customers.
When InVision started looking at security solutions for Docker. They made a wish list of what they wanted to have as security requirements, which covered needing to know what is happening in runtime, which images resided in their registries, and how good the images are, etc
Some of the specific criteria, lead site engineering Pat Cox said, is to get beyond image at-rest analysis to cover the runtime environment. In particular, they are interested to know what is happening dynamically in a container and on the host while their applications are running. That was a gap in many products that they have seen. InVision does not want to get one tool for image analysis and acquire yet another for runtime protection.
Twistlock’s solution is soup to nuts, which covered everything that InVision is looking to do. The ability to support Alpine Linux was important to InVision, which Twistlock also provides. In their evaluation, InVision found Twistlock to be the most comprehensive product that hit all the sweet spots and delivered robust functionality that impressed the company.
After InVision deployed Twistlock, Pat said, “the tool has highlighted many best practices that we should be following. With Twistlock in place, we are confident that real-time threats would be covered by implementing best practices and performing runtime analysis.”
As for the next step, InVision container security is working on rolling out Twistlock to all of its environments, including deploying Twistlock with Kubernetes, ensuring that Twistlock is on all the Docker Engines in production.
This is exactly the type of customer success story that we love. Besides InVision, we have many enterprise, government, and startup customers that are going through the same innovation changes from infrastructure to applications. At DockerCon 16, which is happening next week, Pat Cox will be on hand at our booth – G16 – to answer questions on how they deploy Twistlock and their experiences in implementing InVision container security.
See you at DockerCon in Seattle!
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog
GitOps 101: What Is GitOps, and Why Would You Use It?Read the Blog
DevSecOps Learning Resources: How to Learn to Do DevSecOpsRead the Blog