Based in Mountain View, CA, vArmour, a data center and cloud security company, provides vArmour DSS Distributed Security System—software to help protect critical applications and workloads. The company was recently awarded patent number 9,521,115 from the USPTO for security technology for container microservices. Marc Woolward, CTO of vArmour, who is the inventor of the technology, described what’s changing in the world of clouds, containers, and microservices, and the issues that need to be addressed now.
What does vArmour provide?
We provide security for cloud environments. We have a distributed security system that is 100% in-software that allows you to wrap every workload, every microservice, every host, with security policy and that security policy allows you to define the interactions that are allowed based on the relationships an application can have. This gives you the flexibility to implement the security policy that you need to, based on risk and business requirements, without having to reconfigure your network or install agents on your endpoints. Our customers tend to be in businesses that are seen as critical infrastructure—financial service providers, carriers, providers of utilities, such as power and water, and healthcare providers—so they tend to be very high value targets with data that is incredibly valuable and confidential.
What is the need that this patent addresses?
This patent is really designed to provide security automation for container microservices and platform-as-a-service environments. The patent name is “security policy generation using container metadata.”
Is this applicable to all cloud environments?
Most container deployments are being installed through platform as a service stacks such as OpenShift, Cloud Foundry, and Mesosphere. One value of these stacks is that they allow you to provide dynamic cloud services in AWS, Azure, and your own private cloud in a way that completely abstracts and hides the differences in how the infrastructure is provided in these environments. As a result, this patent is relevant to public cloud and private cloud, as well.
What has changed?
For architects and CTOs in large enterprises over the last year, the focus has moved away from developing applications so they can be deployed in the public cloud to a focus on developing apps so they can be deployed within a microservices framework upon a platform as a services layer in order to deploy them in any of the public cloud vendors or in a private cloud. That abstraction and control means that they don’t get locked into public cloud provider A or B which could be a concern.
What requirement did you identify?
We saw the need to combine the security benefits of high-level policies with the dynamic operations that were enabled by DevOps and cloud models. This innovation addresses the need to enable very strong security that is driven by the requirements of an organization in a world where things change very fast.
How did your technology evolve?
Before containers, we pioneered this approach for clouds with our group-based policy models which combine attributes and labels defined at the data center orchestration layer, or scheduler. The container DevOps models have institutionalized the use of labels to pass metadata at run time. Our invention defines the model to integrate this metadata into flexible policy models leveraging container orchestration tools such as Kubernetes and Mesos that allow you to pass hints or statements about the application that is being instantiated.
How is this different than what has been done in the past?
Until now, policy engines have either been relatively static or pretty graphical interfaces which failed to provide the real power and flexibility that you require at scale. With this new invention, we are able to build powerful and flexible templates that predefine approved security models and then plug the microservices into them as they spin up.
For example, an investment banking organization defines a model for their MongoDB service and the relationship that it is permitted. That is like saying: This is my security architecture for MongoDB in my business unit. Then, when the MongoDB instance spins up, we learn that it is owned by that organizational unit - investment banking—and we provide it dynamically with this security model which has been defined in the template. That is the essence of what this patent describes.
How does this affect companies with regard to regulatory compliance?
In the finance industry, there is a framework that that has been put in place by regulatory agencies in the U.S. called FFIEC [Federal Financial Institutions Examination Council]. There are about five or six agencies that are now using it to address the security posture of systemically critical financial institutions and within that, there are several clauses that require applications and businesses to be segmented so that you can apply controls between different types of applications and different types of business and also to very explicitly to separate pre-production resources from production resources. To meet those requirements in the really dynamic world of microservices, where they are being instantiated and deployed very quickly and there is a high volume of change, is a challenge.
This technology allows you to do that?
We can learn that a new microservice that has spun up is as part of the application group, or part of pre-production, and as soon as it is spun up, we can ensure that it inherits the right set of security policies.
Another example of a regulation in financial services is the CBEST framework, which is being run by the Bank of England in the UK, and our understanding is that is going be replicated in multiple places. CBEST is an exercise to run a threat model against a given financial institution to look at the data they have and the businesses they have, and how an attacker would strike. There is also some penetration testing with it so it actually goes one step further to test how vulnerable the institution is. One of the big areas within that requirement is to keep non-privileged users from being able to access services within the data center—for instance, databases that store customer information, and to provide compartmentalization at the network layer.
How is this more difficult with microservices?
As soon as you get to microservices and things become dynamic, it is very difficult to say whether a microservice has a certain property: Does it store customer information, and does it store confidential financial information? Because we can plug the metadata about the microservices that are being spun up into the security model, we can meet that requirement, as well.
Is this potentially relevant for the new EU General Data Protection Regulation (GDPR) which is expected to go into effect in 2018?
Most organizations are trying to become compliant before that. GDPR is an interesting regulation. It puts in place some high-level requirements about the protection of individual information and data within the EU. I emphasize high level. It describes outcomes as opposed to getting too deep into the methods to achieve that. Our understanding, having worked with a number of our customers, is that the ability to segment the databases that store individuals’ information and put controls around them is seen as a compensating control. It is one of the approaches that you would use to meet GDPR. And, again, the fact that we can recognize at runtime that this system processes individuals’ information is really important.