BeyondTrust

Attention Auditors! Visit ISACA Today at Caesar's Palace in Las Vegas, NV

2010-09-14T10:03:00.000-07:00

Don't forget to stop by ISACA Booth # 25 today to learn how PIM ensures auditors meet compliance risks & satisfy audits.

http://ow.ly/2E5ZE

This conference builds on and includes the key elements of information security management practices and information security practices. It also covers related business, program and technical issues, and the impact of risk management.

BeyondTrust is located at Booth #25, and will discuss Privileged Identity Management (PIM) and the importance for auditors to learn how PIM solutions:

Securely manage privileged accounts and the risks posed by such accounts
Help satisfy audits
Effectively manage compliance risks within an enterprise
Produce audit reports with ease

---

13-15 September 2010 | Las Vegas, Nevada, USA
Caesars Palace
BeyondTrust Software, Inc. -- Booth 25

More from VMWorld on Virtualization Security

2010-09-09T10:22:00.000-07:00

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

2010-08-31T15:08:00.000-07:00

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

2010-08-30T12:27:00.001-07:00

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

2010-03-09T06:29:00.000-08:00

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

2010-02-17T07:42:00.000-08:00

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

2010-01-29T08:07:00.000-08:00

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

2010-01-22T07:55:00.001-08:00

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.)

Microsoft Windows 7 AppLocker Does Not Address Least Privilege

2009-11-24T08:44:00.000-08:00

The recent release of Microsoft Windows 7 has raised a lot of questions regarding its use in a Least Privileged environment. Working at BeyondTrust, one of the more common features I am asked about is the Microsoft Windows 7 AppLocker settings and if they use it, do they still need to remove admin rights.

From what I see, AppLocker is just Software Restriction Policies (SRP) with some improvements and as a stand-alone solution is not enough to protect an enterprise.

So the answer is, "yes, you sill need to remove admin rights." Below is some history of the feature and my testing results to explain the reason why.

SRP had a bad reputation for some due to its cumbersome setup and maintenance. It was also very easily circumvented. Just run a restricted program from inside a .zip file and voila, there's your restricted application running.

AppLocker has made improvements to both, but maintenance is still an issue.

Behind The Scenes, Why You Still Need to Remove Admin Rights:
For AppLocker, the policies require the Application Identification Service (AppIDSvc) to be be running on the client machine. If you are running Windows 7 with Administrative Rights, this service is easily disabled as well as your AppLocker policies. What's more, as a service, it can be controlled with Registry Settings. I'll talk more about this further on in this post.

Testing:
I wanted to see what it took to initially setup AppLocker, and if it would truly protect my environment by not allowing certain software applications to run. Here's the blow-by-blow:

Logged on as Administrative User
Setup two of the three Default AppLocker Path Rules
Allow: All apps from Program Files Folder
Allow: All apps from Windows Folder
Created C:\Tools and C:\Program Files\InstallsAfterAppLocker Folders
Copied notepad.exe to C:\Tools & C:\Program Files\InstallsAfterAppLocker Folders
Run notepad from C:\Tools - Got an AppLocker message, notepad doesn't start
(Expected)
Run notepad from ..\InstallsAfterAppLocker - No Message, but notepad doesn't start
(Not Expected)
Run winzip installer from ..\InstallsAfterAppLocker - Install starts but fails half-way
through (Expected but quarky)
Downloaded a scientific calculator
Run from C:\Tools - Got an AppLocker message, Calculator doesn't start (Expected)
Run from ..\InstallsAfterAppLocker, Runs Fine (Expected)
Booted in SafeMode
Set AppIDSvc to Disabled
Downloaded the GooglePack and installed it
Reset AppIDSvc to Automatic, rebooted in normal startup mode
After a short time messages began to pop up from the SystemTray from Spyware Doctor
(Part of the Google Pack)
Some GooglePack apps didn't run, other worked no problem (Not Expected)
Created several Windows Installer App Rules, Apple was not on the approved publisher list.
Downloaded the iTunes installer, wouldn't run (Expected)
Set the AppIdSvc to disabled and rebooted
Installed iTunes without issue (Expected)
Reset AppIdSvc to automatic and rebooted
iTunes still runs without issue

Then I began to think about an Administrator who utilized 'System Services' MS GPO Policy. With this policy you can set a service's startup type. In my testing, even after I disabled the AppIdSvc, I still needed to reboot for the AppLocker policies to be disabled. If GPO set this service to startup when my machine rebooted, I would still have been limited by the AppLocker policies.

As I mentioned above, services can be controlled via Reg Keys. By default, System and Administrators have full rights to HKLM\System\CurrentControlSet\services\AppIDSvc. By removing these rights you effectively negate the ability for Group Policy to alter the settings, thereby ensuring the service will not be started when you reboot.

Summary:

Users running with standard user rights would still need a solution to allow apps requiring admin rights to run/install without having the administrator password.
User running with Admin Rights can easily circumvent AppLocker.
AppLocker is somewhat easier to setup than SRP was, but maintaining a white list of applications is tedious and time-consuming.
In my experience, SRP was used to prevent users from running certain applications because they were running as Admins. Often times it wasn't that the company didn't want the application to be run, they were just concerned with what could be done with the application if given admin rights.
Using AppLocker alone as a solution for Least Privilege would not be enough to protect your enterprise however, AppLocker and BeyondTrust Privilege Manager used together enable users to run with standard user rights complement each other nicely

Windows XP Mode in Windows 7

2009-10-06T10:19:00.001-07:00

Microsoft has taken an interesting approach to the application compatibility problem by introducing Windows XP Mode in Windows 7. The idea is that Windows XP mode will allow older applications that refuse to run on Windows 7 to simply run on Windows XP virtual machine running in the background on the Windows 7 machine. Instead of the end user being presented with a separate Windows XP virtual desktop, the applications running on the virtual machine will be published to the Windows 7 desktop. So it will seem like the application is running on the Windows 7 OS, but in reality it will be running on the virtual XP machine. On the surface, this seems to be a good solution to the application compatibility problem, but it raises a number questions. What about managing the virtual machine? Do we now need to manage twice the number of machines now? Does it need to be domain joined? Does it need to be patched? Does that mean Microsoft is going to extend support for Windows XP? What about virus protection? What about licensing?

Here at BeyondTrust, we’re very interested in the least privilege problem. Applications that require administrative rights to run are a huge problem from an application compatibility perspective. So, if you have an application that requires admin rights, and also refuses to run on Windows 7, you’re going to have to install the app on the virtual XP machine and allow the user to log onto that Windows XP virtual machine as an admin! So, you’re back to square one, the user is now an admin on a domain joined machine. Even if the user is logging in as a standard user on the Windows 7 desktop, they are going to be an admin on the virtual machine. The bottom line is that when you move to Windows 7, you will likely have application compatibility issues and you will likely also encounter least privilege problems on both the Windows 7 OS and the Virtual XP OS. The move to Windows 7 presents a great opportunity to look at both problems and how you might solve them.