Home > Blogs > VMware Security & Compliance Blog > Tag Archives: vshield

Tag Archives: vshield

“Let’s get out of the weeds”

As part of VMware’s Security & Compliance Specialist team, we’re brought in to speak about a very wide range of concepts that extend from CPU architecture all the way up to the traditional tools like Firewalls, IPS’, Anti-Virus, and many others. Usually there’s some type of compliance question or concern driving the need to have a security conversation. And what most people don’t explicitly realize is that a discussion about security, whether physical or computer, always distills to the lowest common denominator being ‘trust’.

The concept of trust is an interesting notion. Trust is usually a faith or belief based emotion, and the hope that we hold for one another is that in matters of science and technology that trust is based upon some empirical evidence and well-informed reasoning. So obviously education is often our best methodology to assist customers with building that trust around our products.

Often the questions I receive are not about things like virtualized security products, like vShield, or the various API’s that have been developed. Instead the focus is most often on the vSphere platform itself. The reasoning behind this is mainly a lack of accurate information of sufficient detail available in the market. For several years VMware did a great job of building a secure architecture of vSphere but did not focus on advertising much of those design decisions, not because it wasn’t important but because it was not a topic our customers were expressing a need to have with us. Obviously as customers move through their own unique virtualization journey and move into Phase 2, Business Production, they are tackling security and compliance concerns around the more mission critical applications and data that are beginning to be virtualized. Having these conversations are also a pre-cursor  of things that need to be resolved prior to a company investing in a private, public, or hybrid “cloud” solution as it all relates back to how well a company can trust the technological controls that have been put in place.

Since I am so often asked questions about vSphere, that tell me the asker does not trust vSphere, or any hypervisor platform, I am frequently having a discussion on what I call “building a pyramid of trust”. Like any structure, the foundation is the most important part because without a well-formed base, in this case with regards to knowledge, it is highly unlikely the other pieces layered on top will be stable enough to continue adding more layers. In my pyramid, my base consists of the core constructs of virtualization. These are the Core Isolation Principles that describe exactly how the hypervisor is designed to separate out itself from the virtual machines and also what keeps each VM separate from one another.  Should these principles be violated, so would the isolation described by the very definition of virtualization.

To help explain the core principles I break apart the functions of the hypervisor into 4 key areas, CPU, Memory, Storage, and Networking. Each of these describe the physical functions that are abstracted into the VM’s themselves. The ways in which this abstraction occurs are very key concepts to fully grasping and understanding how we’ve developed our platform from the ground up with security in mind. It shows through in how we isolate specific CPU instructions, how our memory is layered, abstracted, and allocated, through the storage platform, and most importantly the protections guarding against remote exploit and arbitrary code execution. All of these things build defense in depth techniques that layer security in a virtualized environment.

Many security practitioners have built their careers focusing on more up leveled concepts of security, and their primary attention was never much directed to the physical hardware interfaces themselves. Much in the same way that server admins were not familiar with centralized storage and networking when we taught them how to virtualize over the last 10+ years. We are helping the security admins also break down their traditional barriers of understanding and now helping them to understand all of these other disciplines in the context of their day-to-day activities.

The interesting part is the resistance we face in educating security teams about all of these technologies and helping to build their trust in the technology. The experience thus far has shown that the typical US corporation is full of cliché terminology, which we’ve already known for years. Dilbert, The Office, SNL, all have made us laugh for hours at what we have become. Even with all this exposure to the ludicrousness of business clichés, I was taken aback a few weeks ago when an attendee at a meeting said we needed to “get out of the weeds”. It was obvious with that one statement that this person was not able to see the foundation of the pyramid being built. They were not willing to connect the dots and see how knowing the information being presented was able to answer all of their questions. Instead, they were using their pre-conceived notions that were founded on mis-information and FUD in the market to limit their ability to absorb the material in an educational context.

I don’t blame this person for their comment. In the day and age we live, time is precious and things happen so quickly it’s hard to keep up with changes in business without sacrificing too much personal time. We’re constantly being asked to make value judgments on which information is worthwhile to absorb vs deciding when it’s time to move on. For some of us, our thread of patience is stretched to the breaking point already.

After a few days had passed, the meeting organizer came back to me and said how grateful they were to have the conversation. They said the discussions that were sparked both during our meeting and in the days following has caused some very positive decisions to be made, mostly because of the comment made by that one individual to “get out of the weeds”. That was a key indicator for many other attendees that their co-worker was resistant to change and to use another cliché “unable to see the forest for the trees”.

This is not an all-too unique situation for us. In fact, it’s become more of a norm for our team to have initial education meetings followed a week or two later by another meeting to review the information again. The reason is that we’ve got to come back and reinforce and inspect that foundation of the pyramid so our audience fully builds their trust of our solution. We’re having great success in this education endeavor and we look forward to meeting with you and your teams in the future.





Rob Babb is a Senior Systems Engineer on the Security and Compliance Specialist team at VMware. 

Using the vShield API

One of VMware's senior Cloud Security Architects, Michael Haines, has started a multi-part blog series on using the vShield API.  He has taken the approach of showing how the vShield API can be used in the daily life of a Network and Security Admin.  In his words

In these series of blogs the Network and Security System Administrator will get hands on programming experience with the vShield API and learn how to consume the API in their own programs and applications. The Network and Security System Administrator does not need to be a developer, although basic programming concepts will help them understand the vShield API better.

He has already posted the Introduction, as well as Part 1 and Part 2.  To keep up with the rest of the series (and to learn more about cloud security), bookmark the VMware vCloud Blog.

CP&C Releases vCM PCI 2.0 Content, Combine this with vShield & WOW!

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

PCI 2.0 is right around the corner 2k12 and many of you should be preparing for these audits yesterday!

Are any of you starting to prep for PCI 2.0? Please share your concerns, we want to help! Get CP&C in touch with your QSA.

Here is a sample of what has changed, for more information check out the PCI DSS v2 Summary of Changes doc.

Scope of Assessment for Compliance with PCI DSS Requirements

  • Added “virtualization components” to the definition of “system components.”  

Network Segmentation

  • Added clarifications including that segmentation may be achieved through physical or logical means 

What’s new in this package? Platform support for:

  • Windows 7,
  • Windows Vista
  • Windows XP
  • Windows 2003,
  • Windows 2008
  • vSphere/ESX

How does this help you address your compliance needs?

This is at the core of what VMware offers as part of our Trusted Cloud Solution. At VMworld, we announced our PCI self healing Virtual environment around CDE and auto segmentation of VM’s based upon data, defining relationships to those VM’s and continually applying policy & remediation to the entire environment. The Combination of vCM, vShield & VIN make for a Compliance Solution that is unmatched in the market and works for other use cases like HIPAA. (See Diagram Below)


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

Be on the lookout for a free PCI 2.0 checker to be released by CP&C later this year!

Also, feel free to hit us up at:

George Gerchow VMware Director, Center for Policy & Compliance

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!

Quick Note on a Nice Blog Post from our Friends at Sourcefire

Rob Randell here with a quick note to point folks at a nice blog post from Sourcefire PM Richard Park.  He does an excellent job here outlining what it takes to integrate to vShield through the vShield REST API.  In this post he focus' on "…how to use the API to programatically make firewall rule changes."  He points also points out a few other things you can do with the API like:

  • List the current firewall ruleset
  • Add new rules
  • Get a list of past firewall revisions
  • Revert back to a previous ruleset revision

These capabilities are just the tip of the iceberg.  This REST APIs is key to the vShield product line because it allows for our partners to integrate their products very easily and customers to automate the security policy enforcement within their vSphere implementations. 

For more information on the API here is a quick link to the vShield API Programming Guide.  We'll revisit the APIs in much greater detail in a future post.

vShield App and View Desktops: Desktop Security Zones and the Desktop DMZ

Hi…Rob Randell here again.  In an earlier posting on the partner announcements at the RSA and HIMSS Conferences, I promised that I would go into detail on how we can leverage VMware View to provide what I like to call Desktop Security Zones and the Desktop DMZ.  In this blog I am going to illustrate this in a use case on a hospital network. 

Specifically, in this use case we have two primary sets of users: Doctors and Hospital Administrators.  The doctors need to have access to the medical records of their patients.  These records reside in a medical records app on the hospital’s internal network that they access via a browser. 

The hospital administrators on the other hand need access to the billing and insurance information of these patients.  This data resides on another set of servers also served up via a web application on the local hospital network.

The doctors have no reason to access the billing or insurance info for their patients and the hospital admins don’t need access to the medical information.  Both the doctors and the hospital admins need access to the web though so they can do research and check on personal matters. 

So based on this case study we are going to have three sets of virtual desktops:

  1. Doctor Desktops
  2. Hospital Administrator Desktops
  3. Web Browsing Desktops

We have two different users that we are going to demonstrate this use case for.  The first is Doc Jones and the second is Hoss Admin.  You can probably guess who is the doctor and who is the hospital admin. 

The first step we need to take in our configuration is to put Doc Jones and Hoss Admin into Active Directory groups that match them to their roles.  In our case, the AD groups are simply “Doctors” and “Hospital Administrators.  These can be seen in the screenshot below.


The next step happens in vCenter where we need to create some resource pools for the housing of our different desktop pools.  These will be necessary for our vShield App rule creation later.  We need to create three resource pools for our different virtual desktops: “Browsing Desktops”, “DoctorDesktops”, and “HospitalAdminDesktops”.  The screenshot below shows the three resource pools we created for our virtual desktops. 

Now that we have created our groups in AD and resource pools in vCenter, we need to create the Desktop Pools within the View Manager.  We will create three desktop pools to matchup with the roles we talked about earlier, BrowserDesktops, DocDesktops, and HospitalAdminDesktops.  You can imagine having additional pools here for other roles within a hospital like nurses, pharmacists, etc… For our use case we will focus on the Doctors, the Hospital Admins and the browsing desktops.  These can be seen in the screenshot below.


Next we configured the entitlements to give the user access to their desktop specific to their roles and the browsing desktop.   




OK, now that we have our desktop pools provisioned.   We need to create the rules necessary for the desktops to work properly.  This includes ensuring that Windows works properly and can communicate with everything it needs like DNS, AD, NTP, etc…  Lots of Windows rules to create as can be seen in the screenshot below.   Click on the screenshot to see the full image.


Communication with the View Server needs to be opened up to allow for PCoIP, USB redirection (if needed), etc…  We have up to 4 rules per desktop pool.  TCP and UDP for PCoIP to allow the View Client to connect to the View Desktop to allow the PCoIP display protocol to work, JMS to allow the View Agent to communicate with the View Manager, and USB Redirection that is tunneled through the View Manager.  Of course in a most cases I would argue that it is a good idea to block this traffic unless it is absolutely necessary.  In this case, it would be reasonable, and likely that we would disable and block the USB Redirection as we probably wouldn’t want the Doctors and Hospital Admins to be able to copy data off of their virtual desktops to a USB drive.   So in our case we will only have three rules per desktop pool (PCoIP (both tcp/udp) and JMS.  Click on the screenshot to see the full image.


Note that the creation of these rules can be scripted so as new desktop pools are created, we can then run a quick script to add the necessary rules. 

Next we need to create the rules to allow the doctors access to the medical app and the hospital admins access to the billing and insurance app.  In this case, albeit very simple, it shows that the Doctors are entitled to the “Doctor Desktops”, which are restricted by vShield App to only have access to the Medical Servers.  The Hospital Admins are entitled to the “Hospital Admin Desktops”, which are restricted by vShield App to only have access to the Billing Servers. 

We used vApps to group the Medical Servers and Billing Servers.  Doing this made creating our rules very easy as we just choose the “Medical Servers” and “Billing Servers” vApps for our destinations and the “HospitalAdminDesktops” and “DoctorDesktops” Resource Pools as opposed to doing some sort of IP subnet based rules.   Both the medical app servers and the hospital app servers provide access via SSL.  


Both need Internet access from the browsing desktops, as the other desktops are not allowed Internet access.  Notice that we deny the “Browsing Desktops” access to all Internal IP Addresses.  If a rule does not match these two rules, it means that the IP address is an external IP address where we allow these desktops HTTP and HTTPS access.  If we wanted to we could allow additional protocols, but for the purposes of our hospital, they should only need these basic protocols.  Also, if we wanted to send a syslog message anytime one of the browsing desktops attempted to access an internal resource and was denied we could check the “Log” checkbox in those rules.  In this case we didn’t choose to do that.


The doctors and hospital administrators now have access to their desktop and any of the resources that their particular desktop is capable of connecting to. This network access is controlled through vShield App where the View Connection Server controls the access to the desktop.  In this case, you can see the vShield App firewall rule that shows the DoctorDesktops have access to the Medical Servers.  Notice that we created these rules based on the resource pool where View Composer deploys the doctor’s desktops (DoctorDesktops) as the source and the vApp that contains the medical application (Medical Servers) as the destination.  Pretty simple, huh?  

Interestingly, it was pointed out to me by Rob Babb that we could make this even simpler for the browsing desktops by setting up a proxy server.  This could be the single point of access to the Internet and would make setting up the rules even simpler as we wouldn’t need the “Deny” rules to the internal networks for the BrowsingDesktops.  All we would need is an allow rule for these desktops to the proxy server, as the deny to the rest of the network would be handled by the default deny rules we have setup at the bottom of our rule set.

Now it is time for the users to login.  We will show the instance of a doctor logging in.  The doctor will run the View Client on their iPad, Thin/Zero Client, laptop, or any other device.  In this case we will show the login with the standard View Client from a Windows machine.


Doc Jones will then authenticate to the connection server.  In this case he is using a standard AD Credentials, but we could use a Smartcard or SecureID as well.


Once authenticated the doctor will have a choice of whether they want to login to the “Doctor Desktops” or the “Web Browsing Desktop”.  Once they decide on the desktop their login credentials they provided to the View Client will be automatically passed through using the single sign-on capabilities of VMware View.


In this case we are logging them into their main desktop so they can gain access to the medical server, but are not allowed access to anything else.   This can be seen in the screenshots below.



Here we can see both the allowed and blocked connections for the docvm2, which is the desktop that Doc Jones was using.


So to summarize, in a minimal amount of work, we were able to setup two desktop pools that are entitled to specific sets of users, which protected with vShield App are restricted to access only a specific set of resources.  Make note that these rules are good for one desktop or 1000 desktops as they apply to the resource pools as opposed to creating the rules for individual desktops.  So we don’t have to constantly add rules as new desktops are added or old desktops are removed.

The cool thing about this is that we can automate this even more to make it even easier which I didn't address in this posting.  I also didn’t talk about how we could use vShield Endpoint and vShield Edge in this use case.  Not to mention adding in partner solutions for IDS/IPS protections as well.  Stay tuned for more on all of this.

Security FAQ: My vShield Endpoint SVM is not responding, what do I do?

Hey…Rob Randell here again.  A new feature that we will be sprinkling into the security blog is entries that will talk about some interesting or frequently asked questions that we feel deserves some more explanation to more than just the person who asked the question.  

Recently we had a question come up a few times as to the resiliency of the vShield Endpoint SVM and what happens if it fails or if the app itself stops responding.  Specifically, the question is: “What kind of availability capabilities do we have for the vShield Endpoint SVM?”

The issue obviously is that if it does fail the VMs being protected by the SVM for AV scanning will be vulnerable to virus’ during the time it is down.  So because of this issue, we’ve built in “health monitoring” of all of its components through standard vCenter Events and Alerts.  These events can trigger an alert in vCenter, which in turn can trigger an action.   This is well documented in the vShield Admin Guide staring on page 81.  That said, we thought it would be worthwhile to discuss this in deeper detail to bring it to folks attention.

The vShield Endpoint SVM that is provided by our partners is constantly monitored by the vShield Manager.  If for some reason the SVM stops responding the vShield Manager will send an event to vCenter that will trigger an alarm.   The screenshot below shows the prebuilt alarm for alertling on the status of the SVM appliance itself.

Alarm Setting - General

These alarms can be used to perform a number of actions like send a notification email or SNMP traps, reset the SVM, or reboot the VM.  In addition, the host can be put into maintenance mode, which will force all VMs to migrate to other hosts in the same resource container that have working SVMs providing protection.  It can be configured to even run a command.  For example, because the SVM is stateless, a standby SVM can even be configured (by cloning the original SVM after registration) to take over in case of a failure.  This can be accomplished through a script which can be run should the alarm be triggered.  This allows us to minimize the downtime of an SVM as well as get notified should an issue such as this should arise so it can be responded to very quickly.  The screenshot below shows a subset of the list of actions that can be taken.

Alarm Settings - Actions

So in short, there are a number of options to provide resiliency and redundancy into the deployment of the vShield Endpoint SVMs.  Expect more of these FAQ type blogs in the future on the VMware Security Blog.