Home > Blogs > VMware Security & Compliance Blog > Monthly Archives: June 2011

Monthly Archives: June 2011

Analogies and The Principle of Least Privilege

Ana Seijas here — one of the newest members of the VMware Security & Compliance team.  So I've been doing security for a long time…started as an external systems auditor and then onto internal audit, consulting, training, CISO, but the one thing I've enjoyed the most was being a Systems Engineer.  So I've been an SE as they are most commonly known for a number of years and for several very large companies.   As SE's we play consultant, sales person, techy or plain listener for our customers…and with all of these hats the one thing in common is that we do a lot of presenting!  As soon as there's even just one person in the room, we're ready to present….be it a Powerpoint, whiteboard, or napkin!  So over the years I've taken many presentation classes….and although I've learned many cool techniques, the one thing that stands out and I try to do most of all is create analogies of technical stuff to real-world stuff.  Its how I can make people remember what this stuff really does!

So when I joined VMware a few months ago and was introduced to our vShield products, I knew that I would be presenting them soon enough. So as I learned the features, functions, and use cases…I started to think of the analogies…so here goes…

Customers secure their data and assets from all those bad guys out on the internet with firewalls, IPS, switches, routers, load balancers and whatever new technology they can find.  For the most part they've learned to build a very "hard shell" around the outside of their company.  In most cases its very hard to get inside a customer's network from the internet (although these days its seems like everybody is being hacked!)…for the most part that "hard shell" exists…but once I'm on the inside as an employee with access, its a "soft and chewy inside" and that's where the problems exist.  Its way too expensive ($$$, people, process and complexity) for a customer to completely isolate every application, group, line of business, or piece of data they have and so for the most part…access on the internal network allows me to probably see or poke around more than I need to.   Curiosity kills the cat or more likely leads to data leakage or stolen information.

VMware's vShield products can help customers maintain that "hard shell" around their virtual datacenters, but also provide "crunch for the soft and chewy inside"…its like sticking a pretzel in it!

Let me explain further!  vShield Edge is a stateful inspection firewall that can provide perimeter security for the virtual datacenter.  It provides the same guiding principles of firewalls but also includes site to site VPN and load balancing capabilities for securing your different tenants, companies, countries, lines of business, stores, offices, etc that exist in your virtual infrastructure.   Adding vShield App allows the customer to now define security groups inside of the virtual datacenter for different trust zones (i.e. PCI, DMZ, HIPAA, etc), applications (web servers, SAP, oracle, etc.) or groups (finance, HR, development, etc.) and define security rules based on their actual business needs as opposed to how the infrastructure or network was created and thus providing that crunch on the inside. 

With vShield App, organizations can become more secure by limiting the ability for the curious employee with "the roaming eyes" to access or see information that they don't need.  It’s the ability to apply the principle of least privilege in a logical manner at the network layer. 

So what is the principle of least privilege: As per PCMag's Encyclopedia – A basic principle in information security that holds that entities (people, processes, devices) should be assigned the fewest privileges consistent with their assigned duties and functions. For example, the restrictive "need-to-know" approach defines zero access by default and then opens security as required. All data in a corporate network would be off-limits except to specific people or groups based on Role Based Access Controls.

Now the principle of least privilege implies getting down to as granular access as possible so the vShield products only provide another layer of granular access control at the network and inter-vm traffic.  You still need to provide granularity using Role Based Access controls in vCenter, your network devices, at the guest OS and applications to name a few.

So if you're Security team is coming down on you to protect more and more of your data for PCI, HIPAA, or whatever the reason, show them how smart you are on security and tell them you're going to virtualize more so you can provide more access controls and enhance the principle of least privilege by using vShield!

Updated DISA Guidelines for VCM

The VMware Center for Policy and Compliance is pleased to announce our latest content update for DISA in vCenter Configuration Manager ™ (VCM).

What’s new in this package?

  • Windows XP       v6.1.21
  • Windows 2000   v6.1.12
  • Windows 2003   v6.1.21
  • Windows 2008   v6.1.14
  • Windows 7          v1.4
  • Windows Vista  v6.1.21
  • UNIX & Linux     v5.1.29

How does this help you address your compliance needs?

As a combat support agency, The Defense Information Systems Agency (DISA)  plays a vital role in the delivery of information technology services and capabilities to the warfighter. From the fundamental to the tactical, DISA's mission touches all facets of the DoD IT environment. The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems. This content and guidance is adopted by SOX, GLBA, HIPAA & FISMA. In fact, most Healthcare Providers are now adopting DISA Guidelines for best practices within their Enterprise. Using VCM you can now Continuously apply this content to your Virtual & Physical environment and quickly remediate Delta’s.

How do you get it?
Customers wishing to harden their vSphere environment can download the new content via the VCM Content Wizard

George Gerchow VMware Director, Center for Policy & Compliance

Follow-up Analysis from “2010’s Trend and Risk Report from a VMware Perspective”

As promised from my blog back in April (sorry it took so long!), here is a follow-up examination to the vulnerabilities announced from 2010 as they relate to ESX and ESXi. As I mentioned before there were 106 different CVE’s that came out of the X-Force DB with the search I pulled. I tried to be as thorough as possible and only focused on vSphere’s ESX and ESXi as opposed to the entirety of our product lines. I also found that several of the items returned were actually for Workstation and were only detected because there was a combined VMware Security Announcement (VMSA) that covered multiple patches. So all of the stats have been updated to reflect the new total of 99. Of those 99, only 7 applied to VMware’s owned code and of those, only 3 applied to ESXi’s code. Another interesting stat was that 1 of those 3 applied only at version 4.1 of ESXi, and the other 2 only applied to version 4.0. Lastly, 6 of those 7 applied to ESX versions 3.0 and 3.5 and 2 of those 6 applied to ESXi version 3.5. That’s a lot of numbers, but what it tells me is that by moving to ESXi as a sole platform, we’re moving in the right direction because there are less overall patches and less patches in each subsequent version.

So looking at the breakdown of the announcements in the chart below you’ll notice the pretty even split between specific linux exploits for the ESX COS and open source libraries used heavily in the ESX COS. There were also a lot of Java vulnerabilities announced last year. The common thread here is that these hit us just as they did for every other vendor in the industry using those tools. And they are very common tools like OpenSSL, Glibc, Java, Linux kernel, etc.  The fact that we’re not unique here should be an important factor to consider since you would have these same types of patches on other platforms.



The next important set of stats to look at is the classification. X-Force uses CVSS just like many other vendors to assign their risk ranking. One thing that was interesting though was when looking at items like vmware-libraries-code-execution (57663) it was assigned a “High Risk” classification, but the CVSS base score was only 4.4 and the temporal score was a 3.3. But when looking at vmware-web-requests-spoofing (57312) it was given a “Medium Risk” with higher CVSS scores for both rankings. It’s these interesting skews that mean we need to consider the real impact as it directly relates to each individual organization and deployment. Below is a breakdown of those risk ratings, but knowing what we do now I would recommend taking these with a grain of salt. One point to consider is that inside VMware we use CVSS for scoring, but have also added a few components for calculating potential severity in a virtual environment. These are value that the original CVSS spec never considered. For example, in a reported escape of any kind we score that a 10 (the highest value) which means it receives the most critical severity. We do this for a few other possible attack vectors. Which means we’re laser focused on making sure we produce the most secure products we can for our customers.



Lastly I think it’s important to look into the sensationalism in the security research industry. Frequently we hear of “exploits” to virtualization, but there is usually a lack of evidence as to the critical nature of the vulnerability. In typical general purposes OS’s we’re used to seeing buffer overflows that are able to fully compromise the entire computing environment. That perception continues to pervade the rest of the computing industry as if it is gospel. Yet, the environment created by a Type-1 hypervisor is drastically different than the direct hardware access a regular OS has. There are multiple layers of abstraction that I previously discussed and each of those layers builds upon themselves to create defense in depth computing for the virtual environment. It is because of this that I attribute the results of the chart below. Greater than 86% of all of those vulnerabilities were listed as “Unproven” and all 7 of the vmware vulnerabilities I listed before fell into that category.


Now I won’t sit here and tell you to not be vigilant with your examination of newly announced CVE’s, in fact I’ll tell you to examine each one of them very closely and thoroughly. Also I won’t say that someone won’t someday come out with some exploit code and release it in the wild, because that would be giving you a false sense of security. This is software and all software has its defects from time to time. What I will tell you is the importance of being up to date on ESX and ESXi. In fact I’m going to drop ESX entirely because soon we will be moving to an entirely ESXi offering and your only option will be the more secure ESXi platform.

We need the industry to drop the stigma that’s been adopted over the last 20 years of OS patching. It’s incredibly unfortunate that we’ve all grown up in IT in an age when certain vendors updates required the “early adopters” to test them for 6 months or years before large IT shops felt comfortable applying them. We at VMware have a very different approach. We want you to update early and often and stay on top of every update that comes out. When you move to the ESXi platform I would seriously encourage you to start looking at stateless implementations of deploying ESXi where every time you reboot the host you’re able to give it the latest and greatest update automatically. This will help you reduce the patching/updating time to your VMware vSphere environments on the whole and you’ll be better off for it in the end as you’ll be assured your hosts are running on the latest and greatest for both features and security!



If you'd like to do your own analysis or review the same CVE's I did, here is a CSV file with links to each of them in the X-Force DB.  Download XFDB Query