Earlier this year, VMware Inc. polled VMware User Group members to find out how the company's customers approach security and to gather information about possible changes to its patch release process. Through this survey, VMware learned and shared some interesting information about the security habits of its customers.
While the majority of VMware users are up to date on security patches, about one-third of respondents say they don't have a formal maintenance policy, and 10% say they never apply VMware security updates (yikes). Unlike Microsoft's Patch Tuesday, VMware does not keep a regular calendar for security updates, though nearly half of the respondents said they'd like to see a more predictable release schedule. A significant number also said they were unsatisfied with the level of detail and analysis VMware includes in its Security Advisories -- a complaint also held by Tom Howarth, an independent consultant who often uses his personal blog to repost and dissect those advisories. In this Q&A, we talk with Howarth about VMware security updates to learn how he thinks the company should change its approach to those updates.
Are you among the crowd that would like to see more detail in VMware Security Advisories? If so, what detail are you looking for?
Tom Howarth: It is a well-known fact that over the years I have republished the VMware Security Advisories on my personal blog. One thing I attempt to do is to add some gloss to the rather staid release document. VMware makes no real attempt to put any focus on what the exact issue an advisory deals with. The advisories are complicated to understand and very dry.
Yes, they do have all the pertinent information in the release; the only problem is that it's drier than the Gobi Desert to read and about as interesting as watching paint dry.
It is not that the advisories are missing information, they are boring to read. It is almost like an end user license agreement, where everyone just clicks "I agree" without even reading. It is almost as if VMware does not want you to read them, does not want to draw your attention to issues in their product, so they wrap them up in a stunted academic tone more suited to a meeting of professors than their target audience of system admins.
To sum up, VMware tries hard but could do better and needs to lighten up a bit.
Do you think VMware would be wise to have regularly scheduled patch updates, similar to Microsoft's Patch Tuesday?
Howarth: Everybody has heard of Patch Tuesday. It is the day that Microsoft, in its infinite wisdom, decreed would be "business interruption day." True, Microsoft has gotten better at avoiding reboots while patching their operating systems and application stacks, but it is very annoying to open your laptop on a Tuesday morning and within a half hour (assuming that you have accepted the default updating preferences), your machine happily informs you it is going to reboot. This is obviously not good for productivity.
The flip side of this coin is that if I were not forced to install these updates, I likely would not bother, thus leaving me open to potential vulnerabilities. In an enterprise environment, a missing patch on one machine can affect everybody. Patch Tuesday is a massive sinkhole on productivity, hence the rise of Windows Server Update Service and Microsoft System Center Configuration Manager 2012 to manage how these changes move into production.
VMware has a similar tool called Update Manager where you can schedule VMware security updates and create build baselines. This is the perfect halfway house -- VMware can release patches and security updates when needed and those managing the environments can integrate them into production at a time that is least likely to affect business operations. If VMware had a release cycle for patches and updates, that could lead to a culture of forcing them into production immediately rather than at a planned and more suitable time.
What's the danger of not protecting the vSphere management network, and how can using a VLAN help?
Howarth: A very good friend of mine, Edward Haletky, has a phrase that he uses in relation to the protection of the management network: "Consider this your front door and the keys to your kingdom." This is an interesting statement, the analogy isn't perfect, but the thought process behind it is very true.
The management network is more akin to your garden, or to use the American vernacular, your yard. Once you are in the virtual machine [VM] management network, you have direct access to your vCenter server and your hosts. In short, you are one step closer to having the keys to the kingdom. It is a very good design principle to separate your VM traffic from your management traffic, to provide a buffer between services and management.
In the early days of virtualization, this concept was seldom acted on, and many implementations were deployed on a flat virtual local area network. Virtualization design is much more mature now. However, that is not to say that this practice is not still happening. If you do not believe me, try the VMware Scanner program. Small and medium-sized businesses and those that are deploying virtualization for the first time (yes, there are companies that have not virtualized) are still making these kinds of mistakes.
Did anything else from the survey results catch your eye or surprise you?
Howarth: The results of the 2013 VMUG security poll really did not throw up any surprises for me -- the results are so indicative of the real world. Some people have scheduled maintenance windows, some have maintenance windows as needed, and, yes, there are still those that wing it and live on a hope and a prayer. Thankfully, that's an ever-decreasing number. But it is proof of the maturity of the virtualization space that the majority of respondents have some sort of process in place to manage patching and VMware security updates.