New Role and Security in a Virtualized Environment

I've accepted additional responsibility in VMware’s CTO Ambassador program so in addition to working with the Office of the CTO on advanced projects around vHPC and vHadoop I will be working to get more visibility and feedback from customers directly to the PMs and R&D engineers responsible for our products.

Despite not officially being in VMware’s Network and Security business unit (NSBU) for the past year, I am still constantly called in to customers to discuss security in a virtualized environment.  In the past, I was responsible for establishing security documentation and baselines for many military branches such as the USMC and how they could achieve their security accreditation for any given site.  This effort to be able to apply DISA STIGs to virtual environments predated VMware’s standard security hardening guidelines.

Now, all of VMware’s security information can be found at http://www.vmware.com/security.  Customers want security reference architectures but they also want more detail about how to customize those for their specific environment.  If you take a vanilla installation of vSphere and apply the latest security hardening guide, you have the basis for the reference configuration that was submitted for Common Criteria certification.  For example, vCloud Networking and Security (vCNS) v5.5 recently achieved EAL 4+ certification.

Two of the biggest issues I still see in virtualized environments are inconsistency and complexity, which have a direct bearing on companies’ security posture.  One would think that with standardized templates, tools and scripts that consistency would be much easier.  However, production IT departments have to support a wide range of applications and this can quickly devolve into catalog sprawl and managing a fairly complex array of templates.  In addition, security policy becomes increasingly specific to each VM or application and again too complex to manage.

I believe the idealized notion of hackers sitting in front of their keyboard elegantly dissecting a target environment is more than a bit disingenuous.  Malware toolkits, or “Sploits”, built to do all of the tedious work are getting even better at spotting inconsistencies and exploiting them before the IT and security admins who should be most familiar with a given environment.  We used to make fun of “script kiddies”, those who ran scripted attacks without understanding why they would be effective, but the threats have evolved as always.  In an autonomous fashion, attacker toolkits can explore a local OS and network, probe for weaknesses, and evade detection in running memory.  One of their typical tasks besides evasion is to compromise any local security controls, antivirus, etc.  So why not only base security policy in the network at a different layer?  Those local controls do provide the best amount of context to what is actually going on within the OS, but without appropriate isolation, they can be easily bypassed.  Why should the IT and security admin toolkit be any less dynamic and automated?

The “Goldilocks Zone” first discussed by NASA and reinterpreted for security by Martin Casado of VMware and Nicira fame keys into leveraging virtualization as being “just right” to support security in a virtualized environment.  To me, and many customers I’ve spoken with, the virtualization layer, along with providing the baremetal abstractions, delivers the right amount of context for local apps and OS while isolated from potential malware that would otherwise corrupt or compromise those local controls.  ESXi can be this trusted layer, with TXT, and appropriate application of the security hardening guide recommendations.  This can also be audited via 3^rd party tools such as Hytrust.

Within vCNS, you can configure security groups to be the logical container for policies.  You can start with static security groups that are defined pertaining to the standard virtual infrastructure layout that vSphere admins are already familiar with such as at the virtual datacenter, clusters, or port group.  The next step is to allow security groups to be dynamic by leveraging the object model AND enable partner solutions to interact with those objects to affect security policy in real-time and coordinate security response to violations.  NSX allows this through essentially creating security tags for VMs that may be read by NSX as well as NSX ready partners, for example Trend Micro and Palo Alto Networks.

Much more to be said about this, but needless to say, excited to be working more directly with customers on next-gen apps with NSX.  I will actually be discussing this live with Trend Micro and Accuvant on 4/18/14 and will post a link to a recording when it is available.

Additional links:
http://blogs.vmware.com/networkvirtualization/2014/03/goldilocks-zone-security-sddc.html
http://www.vmware.com/security/certifications
http://www.forrester.com/No+More+Chewy+Centers+Introducing+The+Zero+Trust+Model+Of+Information+Security/fulltext/-/E-RES56682
http://www.vmware.com/products/nsx