More from VMWorld on Virtualization Security

At VMWorld we had the pleasure of meeting with Jon Brodkin from Network World, who published what might be the best-written explanation of how IT administrators can take advantage of the hypervisor yet.

Naturally, as Jon absorbed what our very own Principal Systems Engineer Jordan Bean showed him in a live demonstration and walked it over to VMWare’s booth, his line of questioning on ESX security may have put some of our virtualization partners on the defensive.

What we should add, is that the ability for IT administrators to use the hypervisor to cover their tracks, hide their activities and ultimately get away with data theft is NOT a VMWare vulnerability - it’s a virtualization vulnerability.

With administrative access and a few changes to the process, we could steal data undetected from any virtual server. This isn’t a shortcoming in their software, but a new danger for root-level access.

In many cases measures are already in place to protect the company from abuse of root-level access on physical servers, but awareness and understanding of how that translates onto their virtual counterparts is low.

You saw in our last post that most VMWorld attendees have virtualized at least some of their mission-critical servers and most believe their coworker could steal data from those servers if motivated. Applying ‘least privilege’ to mitigate risk from this kind of privileged access has always been our domain – virtual or not.

BeyondTrust Survey at VMWorld Shows What it Takes to Get Attendees in a Tutu

Right here from the exhibit floor at VMWorld we took a short three question survey of 57 conference attendees and the results are shocking.

• 44% of attendees said their colleagues could steal sensitive information from mission critical servers if they wanted to and another third of respondents said their colleagues "might" be able to


• 37% of attendees say "most" of their mission-critical servers are virtualized and 61% said at least some were.


• When asked what their colleagues would do for $20 million:
  35% would lose their job and leave the country
  35% would leak information to a competitor
  The most popular answer was 40% of attendees believe their colleagues would wear a tutu for $20 million (we believe this number is underreported)

We recently posted that virtualization was creeping onto mission-critical servers, which use to be kept on physical servers for security reasons. This survey shows even further penetration than we may have believed, with almost everyone having at least some sensitive servers virtualized.

So you have (a)sensitive servers in a virtualized environment (b) staff that would steal data for money and (c) staff that CAN steal data and the problem is incredibly clear.

Here's the complete survey results, including plenty of humorous findings in the final question:

Has your company virtualized mission critical servers?

• Most of them: 21 (37%)


• Some: 32 (56%)


• None: 4 (7%)

If one of your colleagues wanted to steal sensitive information from a mission-critical virtual server in the company, do you think they could?

• Yes: 28 (49%)


• Maybe: 14 (25%)


• No: 15 (26%)

What do you think your colleagues would be willing to do to get their hands on twenty million dollars?

• Kill someone: 10 (17%)


• Chop off their own arm: 9 (15%)


• Jump into a water tank with a shark: 10 (17%)


• Lose their job and leave the country: 20 (35%)


• Leak information to a competitor: 20 (35%)


• Wear a tutu: 23 (40%)


• Steak data: 12 (21%)

VMWorld & Virtualization Security

It's been just over three years since VMWare's highly anticipated IPO put the high-tech industry on the edge of our seats. Now virtualization is a staple of IT, VMWorld is full despite dwindling travel budgets and the ecosystem supporting VMWare's technology is bustling.

But virtualization is far from the end of it's growth cycle. A recent survey showed that while 90% of IT environments have incorporated virtualization, security concerns have about 40% of respondents holding back. Over time virtualization has crept up from being an experiment to finding itself running on increasingly sensitive servers

That's why security is the linchpin to the further penetration of virtualization into sensitive servers and to reducing the business risk with the most valuable data in our treasury.

So under that context we'd like to give you a glimpse of what we're demonstrating at VMWorld with technical tutorials that show some key vulnerabilities in virtualized environments and how to address them.

Windows 7 and Least Privilege Application Compatibility

In planning the move to Windows 7, Application Compatibility should be a top priority. The key technology that Microsoft provides for this is the Application Compatibility Toolkit (ACT). Now in version 5.5, ACT has been around for some time, and it is designed to help identify and mitigate potential issues with application portfolios. ACT works by taking an an inventory of your existing applications, and analyzing them to determine if they will be compatible with Windows 7. Once the applications have been analyzed, there are a few different approaches for mitigation. One approach is to use the ACT shims to get the applications to run and another option is utilizing Windows XP Mode on Windows 7. This should make the transition to Windows 7 much easier for most organizations, and also prevent downtime for your end users.

As we have discussed in the past, enforcing least privilege is a critical part of your security posture, and the move to Windows 7 presents organizations with an opportunity to finally move to the least privilege model. While the Application Compatibility Toolkit has the ability to identify Windows 7 Application Compatiblity problems, it does not identify Least Privilege Application Compatibility. Not only do organizations want to know what apps are compatible with Windows 7, but they also want to know what applications will not run properly when a user is not an administrator.

BeyondTrust Privilege Manager has the capability to identify least privilege application compatibility problems and mitigate them. This allows organizations to deploy Windows 7 and ensure that the users no longer need to be local administrators.

For more information on ACT, take a look at the Microsoft Springboard Series videos, they are an excellent resource for making the transition to Windows 7:
http://technet.microsoft.com/en-us/windows/dd981014.aspx

For more information on BeyondTrust Privilege Manager and Least Privilege Application Compatibility, please visit BeyondTrust:
http://pm.beyondtrust.com/products/PrivilegeManager.aspx

Video Tutorials

I recently uploaded some videos to Youtube to help get folks started using Privilege Manager. You can download Privilege Manager from our website, install on a standalone machine, and evaluate the product without a license key. Check them out:

The Swiss Cheese Model

BeyondTrust Privilege Manager was first released in February 2005. Since then we've heard a lot of stories from administrators on how they tried implementing a least privileged model without Privilege Manager. Some folks used scripts to grant/remove administrator rights to the user, others used native settings like Group Policy Files system and Registry ACL policies. I am not speaking bad of these admins and admittedly, I have taken similar steps myself in the past; and in moderation these do have a place. The problem with utilizing this approach to completely address Least Privilege or Least-Privileged User Accounts (LUA) is that you get into what we refer to as, 'The Swiss Cheese Model'. You inherently open up a number of security holes in your enterprise, not to mention risk breaking compatibility with applications, and create an incredible amount of work maintaining these policies and transferring this knowledge to other administrators. Below is an excerpt taking from a Microsoft KB on this:

Extensive permission changes that are propagated throughout the registry and file system cannot be undone. New folders, such as user profile folders that were not present at the original installation of the operating system, may be affected. Therefore, if you remove a Group Policy setting that performs ACL changes, or you apply the system defaults, you cannot roll back the original ACLs.

Changes to the ACL in the %SystemDrive% folder may cause the
following scenarios:

• The Recycle Bin no longer functions as designed, and files cannot be recovered.
• A reduction of security that lets a non-administrator view the contents of the administrator’s Recycle Bin.
• The failure of user profiles to function as expected.
• A reduction of security that provides interactive users with read access to some or to all user profiles on the system.
• Performance problems when many ACL edits are loaded into a Group Policy object that includes long logon times or repeated restarts of the target system.
• Performance problems, including system slowdowns, every 16 hours or so as Group Policy settings are reapplied.
• Application compatibility problems or application crashes.

In contrast, using BeyondTrust Privilege Manager (PM) to facilitate a Least Privileged environment has been proven time and time again to be an effective, easy to use and maintain solution to the issues that arise when going to this type of environment. Using PM has also been the only realistic way to satisfy certain audit requirements which prevents users from running with Administrative Privileges with many of our customers.

You can learn more about BeyondTrust Privilege Manager at our website: http://pm.beyondtrust.com

For more information on the risks involved with File System and Registry Access Control List Modifications see this Microsoft Article: http://support.microsoft.com/kb/885409/en-us

How to elevate Scripts, Batch Files and Registry files

We are often asked if Privilege Manager can elevate other items, those other than the obvious *.exe, *.msc and *.msi. In order to elevate things like registry files, batch files and scripts, you simply need to know the format for the rule. Here are the formats for the most frequently requested items.

To elevate a script, simply create a rule to point to the scripting host, then in the arguments field, scope the rule to the specific script you would like to elevate to prevent the user from elevating any script.


















Alternatively, you could use WindowsServer\Netlogon without a file specified at the end which would elevate all scripts in the Netlogon folder.

To elevate a registry merge, simply add the path to regedit.exe, and in the arguments field, scope down to the reg file you wish to elevate:


















Note: The elevation of the *.reg and script files are scoped to the item in the arguments field, the user can not self elevate any script or *.reg file on their own when an argument is present.

Batch files are applications, so you simply need to point to the path (or HASH) of the batch file:



















With these examples in mind, you should be able to create other rules for similar situations (e.g. KIX scripts, java scripts, etc.)