VMware Security Blog

The Common Vulnerability Scoring System (CVSS) is an standard for assessing the severity of computer system security vulnerabilities. CVSS is composed of three metric groups: Base, Temporal, and Environmental, each consisting of a set of metrics. For those not familiar with CVSS, here is a blog post Common Vulnerability Scoring System (CVSS) Explained.

1. Base: represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments.
2. Temporal: represents the characteristics of a vulnerability that change over time but not among user environments.
3. Environmental: represents the characteristics of a vulnerability that are relevant and unique to a particular user's environment.

A software vendor can typically fill out the base metrics score because things are supposed to be constant. But it turns out that VMware products break the definition of a CVSS base score. A base metric is comprised of the following:

• Access Vector (AV)
• Access Complexity (AC)
• Authentication (Au)
• Confidentiality Impact (C)
• Integrity Impact (I)
• Availability Impact (A)

Now consider only the Access Vector (AV) metric. Here is the definition:

In this blog post I intend to show with VMware products the CVSS Access Vector (AV) can be different depending on how virtual networking is setup, and is thus affected by the user environment. Perhaps CVSS should consider moving the Access Vector metric from the Base metric set to Environmental metric set. I will show why it is so important to isolate your management network, because when using VMware's best practices the CVSS base score of many vulnerabilities will be reduced.

Consider the following scenarios.

In the following scenarios we'll take a look at an ESX system with several virtual machines. The virtual machines are connected to the Internet.

Scenario 1

This is where both the ESX Service Console (or the ESXi management network) and the virtual machine network are both on the same vSwitch which connects them to the Internet. Note this is NOT recommended! Most Operating Systems don't have virtual switches or layer 2 network isolation, and so they would fall under Scenario 1 where all networking is exposed to the Internet. This Leaves the CVSS Access Vector value to be Network.

Scenario 2

Here the management network is on a different vSwitch and on a totally different network then the virtual machines which are connected to the Internet. There is NO direct route from the Internet to the management interface, nor to the ESX Service Console. This is VMware's recommendation for platform security best practices and it provides an additional layer of protection. In this scenario using the CVSS definitions, the management network is on a local IP subnet or Adjacent Network, and the virtual machine port group is on the Internet or CVSS defined "Network."

Vulnerabilities

Now consider a vulnerability in the ESX Service Console. Let's take CVE-2008-4309, "a denial-of-service flaw was found in the way net-SNMP processes SNMP GETBULK requests. A remote attacker who issued a specially-crafted request could cause the snmpd server to crash."

The National Vulnerability Database rates this CVE as:
CVSS v2 Base Score:5.0 (MEDIUM) (AV:N/AC:L/Au:N/C:N/I:N/A:P)

But this also assumes the Access Vector is Network (AV:N). If you are following VMware's best practices, then your management network is isolated. There is no way an attacker from the Internet/Network can get to the management network stack, even if there is a flaw in the management network stack, thus the only Access Vector is through the Adjacent Network (AV:A). This adjustment in the Access Vector to (AV:A) from (AV:N) changes the CVSS score to:

CVSS v2 Base Score:3.3 (LOW) (AV:A/AC:L/Au:N/C:N/I:N/A:P)

This is just one example where a base metric Access Vector doesn't meet the CVSS criteria of "the characteristics of a vulnerability that are constant with time and across user environments" because of virtualization. While looking at CVSS we noticed a few other interesting conditions that need to be considered because of virtualization. But we'll leave that to another post.

All ESX Service Console vulnerabilities and ESXi management service vulnerabilities can also be modified when using VMware security best practices as shown above. The Access Vector is no longer just Network (AV:N), but it becomes Adjacent Network (AV:A) when using multiple virtual switches

So when evaluating security risk using CVSS consider how you have deployed your machines, consider how the networking is setup and if you are following VMware's best practices you may be able to lower your CVSS score to better reflect your risk. If you NOT following VMware's best practices, perhaps it is time to re-evaluate your security setup and consider isolating your management network.

A small contingent of VMware folks will be staffing a booth at the SANS Network Security 2009 event in San Diego on September 17 and 18.  Stop by and chat if you want to learn more about virtualization networking, security, and compliance, including what's new in vSphere 4 such as the vNetwork Distributed Switch and vShield Zones.  

If you are at VMworld next week and you are interested what we are doing to make our products more secure, come to our talk on VMware’s Secure Software Development Life Cycle (follow link, click "Content Catalog" and search on "secure"). The first part of the talk will spell out our security training, architectural reviews, security testing, code analysis, and the Product Security Policy. The second part of the talk will feature the security response activities and take you through a real-world disclosure scenario.

We hope to see you in room 301 at 2.30 pm on Tuesday September 1!

Are you interested in security and virtualization? We made a summary table listing the VMworld sessions on product security, compliance, hardening, secure architecture, VMsafe, and securing the Cloud.

Many people have been interested in knowing when vSphere 4 will achieve Common Criteria certification, as was the case for ESX 3.0 and vCenter 2.0 and as will be the case for ESX/ESXi 3.5 and vCenter 2.5.  Common Criteria is important for government and defense customers, since it is often a requirement for many of their IT environments, but it is also valuable for other customers, since it represents an objective measure of a software product’s security.  Having Common Criteria certification, especially at the higher levels, is often used by security professionals and auditors as a way to gauge whether or not a product should be considered for use in security-sensitive environments, such as credit-card transaction systems.

I am happy to report that VMware vSphere 4 has begun the Common Criteria certification process for vSphere 4.0 at EAL4+.  This specifically includes: ESX 4.0, ESXi 4.0, and vCenter 4.0.  We have received the letter of intent from the security consulting firm hired by VMware for the evaluation; unfortunately, we cannot post it here, but interested customers should contact their sales representatives directly if they want to see a copy of it.

As you might be aware, the journey towards final certification can be a long one, due to the extensive documentation requirements and rigorous tests that the products must undergo.  We’ll provide updates at major milestones of the certification process, but the expectation is that final certification will be achieved in the 2nd half of 2010. 

Those of you who went to the RSA show in April and who visited the RSA booth may have seen a proof of concept showing an integration between VMware vShield Zones and RSA's DLP product. It showed how these products working together can prevent leakage of sensitive data in email, web traffic, etc., right from within the fabric of the virtualization layer itself.  There is now a video posted which was taken during the show and has VMware's Allwyn Sequeira and RSA's Magnus Nystrom going over the demo.

I will be presenting on a joint webinar with Reflex and TrustNet on PCI Compliance and Virtualization.  The presentation will cover the following:

*  The top challenges enterprises face when it comes to addressing PCI DSS compliance. 
*  The benefits of virtualization that bring reduced cost, efficient application, more business continuity and automation to organizations. 
*  The latest best practices for visibility, segmentation, and policy enforcement to control and audit changes in the virtual infrastructure. 

This paper tackles the subject of DMZ security and virtualization. It covers a number of DMZ security requirements and scenarios, presenting how vSphere users can implement the Cisco Nexus 1000V virtual switch in a DMZ.

With the general availability of VMware vSphere 4 a few weeks ago, I just wanted to highlight for the security community that VMware vShield Zones is also part of that release and now generally available!

vShield Zones is a new product for VMware and one of the newest members of the vSphere 4 product family, based on technology from our acquisition of Blue Lane Technologies.  We had a lot of interest from customers around vShield Zones and had over 200 customers around the world registered for our recent private beta.  It is part of the vSphere package starting with the Advanced Edition and above.

VMware vShield Zones 1.0 offers the following key features and benefits for vSphere 4 environments:

Central Management of Logical Zone Boundaries and Segmentation

• Leverage existing virtual infrastructure containers –  hosts, virtual switches, VLANs – as logical trust or organizational  zones
• Define policies to bridge, firewall, or isolate network  traffic between zone boundaries
• Manage and deploy policies across entire VMware vCenter  Server deployment
• Integrate with VMware vCenter Server and automatically  deploy on existing virtual networks
• Scan and discover existing applications running on  virtual machines to identify application protocol
  

Network Enforcement and Flow Monitoring

• Classify traffic by network or application protocol (e.g.  HTTP, RDP, SNMP)
• Performantly filter traffic with stateful packet  inspection (SPI)
• Track dynamic port connections for protocols such as  FTP
• Track network connections across VMware VMotion migration  events.
• Easily convert observed network flows into precise  network enforcement rules.
• Monitor both allowed and disallowed activity
  

Management and Reporting

• Access the Web-based vShield Manager interface remotely  from any Web browser
• Configure administrators to be common with VMware vCenter  Server or distinct for separation of duties and roles
• View activity hierarchically at individual virtual  machine or aggregate levels and generate graphical or tabular  reports
• Retain log data for archival and compliance  purposes
• Export events and data using syslog format
  

More information about vShield Zones can be found at the product page here: http://www.vmware.com/products/vshield-zones/ <http://www.vmware.com/products/vshield-zones/>
 
vShield Zones 1.0 is downloadable as part of the VMware vSphere evaluation at: https://www.vmware.com/tryvmware/index.php?p=vsphere&lp=1 <https://www.vmware.com/tryvmware/index.php?p=vsphere&lp=1>
 
Documentation and release notes about vShield Zones 1.0 can be found at: http://www.vmware.com/support/pubs/vsz_pubs.html <http://www.vmware.com/support/pubs/vsz_pubs.html>
 

Just in case anyone missed the news from VMworld Europe 2009 last month, VMware launched a new security offering called VMware vShield Zones for our vSphere (formerly VI) platform.  We think this is pretty exciting, as it's the first datacenter security product from VMware, and highlights Security's elevation to one of the six key pillars of our Virtual Datacenter OS architecture.  (For those keeping score, I don't count vCenter Update Manager as a security product only because the patch management vendors themselves tend to more self-identify with system and configuration management....)

vShield Zones is based on our acquistion of Blue Lane Technologies last October.  It is based on Blue Lane's mature application-aware network stack, but instead of offering virtual patching, it has all-new modules providing network flowing monitoring/auditing as well as network firewalling.  Of course these are packaged as a virtual appliance and provides inter-VM visibility and enforcement specifically for logically partitioning the interior of the virtual datacenter.  This is great for meeting security and compliance policies around virtualizing DMZ's, meeting PCI network segmentation requirements, or isolating multiple tenants in the cloud.  For more information about vShield Zones, visit the product page at http://www.vmware.com/products/vshield-zones/.

vShield Zones will be shipping in the vSphere 4 teimframe.  We just entered a private beta that is open to all vSphere 4 beta community members; look for a forum post in the vSphere 4 beta community on how to sign up to download the software and documentation.  We appreciate your time and feedback!