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

Microsoft Windows 7 AppLocker Does Not Address Least Privilege

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:

1. Logged on as Administrative User
2. Setup two of the three Default AppLocker Path Rules
   Allow: All apps from Program Files Folder
   Allow: All apps from Windows Folder
3. Created C:\Tools and C:\Program Files\InstallsAfterAppLocker Folders
4. 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)
5. 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)
6. 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

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.