By Andrew Garcia  |  Posted 2009-08-17 Print this article Print


Windows 7 provides a number of new security options, yet, perversely, many users could potentially have worse base security with the new OS than they did with Vista.

The most compelling security features--application whitelisting and encryption of both full disks and removable drives--are not included with the Professional and Home Premium editions that many will use at work and at home. And, in concessions to user outcry, Microsoft in Windows 7 has scaled back some of the security that was first introduced with Vista.

User Account Controls, or UAC, was probably the most reviled feature of Windows Vista: Users had to become accustomed to acknowledging every system change made to the computer, including application installations, patch installations, and access to system tools such as Computer Management or the network adapter settings.

This acknowledgement was necessary because in Vista the user does not operate day-to-day as an administrator (even if he or she has administrator rights). When performing an administrative action, the UAC prompt bumps up user credentials to admin levels to perform only that task.

Windows 7 keeps UAC in place, but implements a number of changes in an effort to make the alerting and acknowledging system more palatable to users and administrators alike.

The new OS introduces levels of enforcement to UAC, presented via a Settings panel with a slider bar that can easily move the user between four different modes of enforcement.

At the strictest level--analogous to how UAC worked in Windows Vista-the system will always prompt the user when changes are made to system settings or when installed applications try to access restricted parts of the file system.

Windows 7's default level, however, notifies the user when applications try to make changes, but not when the user does. An easy way to experience the difference is by accessing Computer Management. In the strict mode, the user must acknowledge (or approve) to even view the panel, while in the default mode an administrative user can go right in and start changing things.

The third mode is similar to the default, but doesn't require the use of the Secure Desktop--the isolated interface that otherwise appears to the user and can't be tampered with by a program. The fourth mode, meanwhile, never notifies the user or asks for approval. This mode is recommended for use only when accessing a program known to founder under UAC purview.

In truth, the new settings--including the new default--serve to worsen the security protections UAC affords. I've turned UAC in Windows 7 up to the Vista-like maximum on my machine.

An interesting complement to UAC is available to Windows 7 Ultimate and Enterprise customers. Called AppLocker (a descendant of XP and Vista's Software Restrictions Policies), this feature provides application whitelisting--specific authorization for applications to run on a computer. A user or an administrator creates a policy that allows only authorized applications to run at all, and all others (whether malware or simply unapproved code) will not be able to start.

Control over AppLocker policies resides within Microsoft's familiar Group Policy architecture. Using the Group Policy editor, I could view existing policies, create new ones, and decide whether to enforce the policies or simply audit them to find out whether people were using applications that could run afoul of the new security.

According to AppLocker, there are three categories of executable code (windows executables, Windows installers and scripts), and each must be configured separately. I could choose enforcement for one classification and audit-only for another.

Applications can be approved in several different ways. For granular application identification, I could base policy on an application's hash (best for uncertified applications), on an application's publisher (for signed applications) or on the file system path to the executable--either the file or the folder.

Windows 7 makes it easy to get started because the Group Policy editor includes a couple of simple ways to generate rules. I could create default rules with one click, creating basic rules: allowing everyone to run programs located in the Windows and Program Files directories, and allowing local Administrators to run all files.

This usage scenario makes an interesting companion to UAC and least-privilege computing. If AppLocker means a limited-rights user can run only programs found in permitted folders, and a tight UAC implementation bars users from writing to those folders, then it becomes difficult to use social engineering to trick someone into mistakenly installing bad or unwanted code.

For more granular controls, administrators can automatically generate rules.  For example, I could specify a folder (such as Program Files), and a wizard would identify all executable content of the appropriate type, basing the policy either on a hash or on the path. I could further limit the scope of the policy by allowing only digitally signed executables.

These kinds of granular rules are more effective and restrictive, but keep in mind that they will require much more maintenance, as patching or upgrades will necessitate a refresh of policy settings.

One potential problem with AppLocker is that it requires one special service to be running to provide enforcement--the Application Identity service. First of all, administrators must make sure that the service starts automatically, and then they must make sure the service continues running. Often, security providers provide additional watchdog protections to ensure that a critical security service stays up in the face of attack, but I'm not sure Windows takes those measures. It is not noticeable when the service is not active but AppLocker policies are present.

Windows 7 adds removable disk encryption capabilities to the most expensive editions--Ultimate and Enterprise.  Called BitLocker To Go, the utility builds encryption and key management into the USB drive itself, allowing easy sharing of protected data with other Windows 7 instances.  Users need only enter the password they specified when they first encrypted the drive.

BitLocker To Go-protected drives can also be accessed on older versions of Windows, as the utility includes a reader on the USB stick itself. When inserted into an Windows XP- or Vista-based system, the drive shows the reader to the user. Run the reader, enter the protection password, and you can read the data or copy it locally. When inserted in a Mac, on the other hand, you see dozens of files,  but you can't access the protected content or manipulate the visible files.

As with Vista, Windows 7 Enterprise and Ultimate come with BitLocker full-disk encryption.  BitLocker is a little easier to use on Windows 7, however.  Specifically, Vista required planning for BitLocker right at the time of OS installation because a separate boot partition was needed. Windows 7 builds the boot partition automatically and slims it down (to 100MB in Windows 7 from 1.5GB in Vista). This allows users or administrators to add full-disk encryption well after initial installation without complications.

By default, BitLocker requires that the computer have an onboard TPM (Trusted Platform Module) chip in which to store the encryption keys.  Users without a TPM chip can opt to use a USB stick instead, but that will necessitate some changes in Group Policy. 

I tested BitLocker on the Lenovo T60p using the laptop's TPM chip, as well as on the Dell XPS M1330 using a USB stick for the key. Depending on the size of the hard drive and the amount of data that needs to be protected, encryption can take several hours. It took just under an hour to protect my relatively data-free test machine and more than three hours to encrypt a half full 80GB disk. Thankfully, the encryption process can be paused midstream to accommodate a system reboot and will resume after the next boot.

Enterprise administrators will find solid controls over both BitLocker and BitLocker To Go in Group Policy that can be distributed throughout the domain. Administrators can control cipher strength, enforce authentication types and strength, and store recovery keys within Active Directory.

In one detail of note, I found that users running Windows 7 in a virtual machine will have trouble enabling BitLocker disk encryption. (I tried this out in VMWare Workstation 6.5, in my case.) Specifically, the hypervisor would not virtualize the TPM chip, and the OS could not recognize a USB stick early enough in the boot process to work for BitLocker. Those who want to protect data within a VM running on Windows 7 should probably look into file or folder encryption instead of full-disk protection.

With Windows 7, no longer will administrators need boot media to attempt to recover a distressed or broken Windows instance, as the new OS features a Recovery Console that is accessible simply by pressing F8 upon boot. 

During tests, I found that the recovery options differed significantly for administrators and limited rights users.

As a limited rights user, I was able to kick off a diagnostic scan called StartUp Repair that automatically looks at the validity of the file system, the hard disk and the registry, then, as a last resort, offers to let the user recover to the last System Restore checkpoint. 

Local administrators, on the other hand, are presented with several options. They can autofix the same problems scanned in StartUp repair, select from all available System Restore checkpoints, perform a system Image Recovery, run memory diagnostics or access the command prompt.

The command prompt lay at the heart of an irregularity I found with credentials for the Recovery Console. In tests, I found that I could log into the console as the default local administrator, but only when no other local administrator accounts are present. The problem is that, by default, the local administrator account has no password. This isn't a problem in Windows proper, as the account is disabled by default, but in these specific instances, the account suddenly activates.

With access granted via the disabled, no-password administrator account, I found I could easily access the command line and copy any data at all on the main partition to a USB stick.

Andrew cut his teeth as a systems administrator at the University of California, learning the ins and outs of server migration, Windows desktop management, Unix and Novell administration. After a tour of duty as a team leader for PC Magazine's Labs, Andrew turned to system integration - providing network, server, and desktop consulting services for small businesses throughout the Bay Area. With eWEEK Labs since 2003, Andrew concentrates on wireless networking technologies while moonlighting with Microsoft Windows, mobile devices and management, and unified communications. He produces product reviews, technology analysis and opinion pieces for, eWEEK magazine, and the Labs' Release Notes blog. Follow Andrew on Twitter at andrewrgarcia, or reach him by email at

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel