There are several obvious basic steps to securing a computer: Keep it current with the latest operating-system and application updates, ensure you’ve installed the latest antispyware and antivirus software, and use complex passwords, changing them regularly. In this article I’ll cover some security tips that go beyond these basic strategies and help you better utilize the security features of Windows 7.
One of the most notable security improvements in Windows 7 is in BitLocker, the technology for hard-disk encryption and boot-environment integrity-protection that debuted in Windows Vista. In Windows 7, the Enterprise and Ultimate editions include BitLocker. The technology ensures that unauthorized users can’t recover data from the hard-disk drives of stolen or lost laptops, as long as the computer was powered off when it went missing.
One challenge BitLocker presents, though, is recovering data after a hardware failure that locks protected volumes. So although BitLocker offers excellent protection, many IT professionals find it problematic because they tend to encounter it only when they must perform recovery operations.
Data recovery requires access to the BitLocker keys or passwords associated with the locked volumes. While it’s relatively easy to keep track of these for a small number of computers, doing so for several hundred is much more challenging.
Group Policy helps IT professionals configure BitLocker so it can be activated only when the recovery keys and passwords have been successfully backed up to Active Directory. Extracting this recovery data has been vastly simplified by improvements to the Active Directory Users and Computers console in Windows Server 2008 R2 and to the Remote ServerAdministration Tools for computers running Windows 7. Locating recovery passwords and keys is much easier than with the tools in Windows Vista.
Instead of having to download, install and configure special tools, you can access BitLocker recovery keys and passwords from a BitLocker Recovery tab. You’ll see this when viewing computer account properties in Active Directory Users and Computers. Ensuring that BitLocker keys and passwords are backed up is a three-step process:
1. In the Group Policy for the computer accounts of the system BitLocker will protect, navigate to Computer Configuration | Windows Settings | Administrative Templates | Windows Components | BitLocker Drive Encryption.
2. Now, if the computer has only one storage drive, navigate to the Operating System Drives node and edit the Choose how BitLocker-protected operating system drives can be recovered policy. If the machine has more than one storage drive, you should also go to the Fixed Data Drives node and edit the Choose how BitLocker protected fixed data drives can be recovered policy. Note that although you can configure their settings identically, the policies apply to different drives.
3. To configure BitLocker so that passwords and keys are backed up to Active Directory when BitLocker protection is activated, make sure to enable the settings:
· Save BitLocker recovery information to AD DS for OS drives (or fixed data drives, where appropriate)
· Do not enable BitLocker until recovery information is stored in AD DS for OS drives (or fixed data drives, where appropriate)
Keys and passwords will be backed up for protected volumes only after the policy is applied. Volumes configured for BitLocker protection prior to implementing the policy will not have their keys and passwords automatically stored in Active Directory. You’ll have to disable and re-enable BitLocker on these computers to ensure that this recovery information makes it to the AD DS database.
There’s another option available if you need to recover BitLocker protected volumes without entering unique passwords or pins for a particular computer account—a Data Recovery Agent (DRA). This is a special type of certificate associated with a user account that can be used to recover encrypted data.
BitLocker data recovery agents are configured by editing group policy and specifying a DRA certificate through the Add Data Recovery Agent wizard, which I’ll discuss shortly. To use the wizard, though, there must be a DRA certificate available on an accessible file system or published in Active Directory. Computers that host the Active Directory Certificate Services role can issue the certificates.
When you have to recover data, a user account that has the DRA certificate installed locally will be unable to unlock the BitLocker protected volume. You can access the Add Data Recovery Agent wizard by navigating to the Computer Configuration | Windows Settings | Security Settings | Public Key Policies node, right clicking on BitLocker Drive Encryption, and selecting the Add data recovery agent option.
To use BitLocker with DRA, you must also select the Enable data recovery agent checkbox in the Choose how BitLocker-protected operating system drives can be recovered policies (as well as in the fixed data drives policy where appropriate). You can use both DRA and Active Directory key/password backups for the recovery of the same BitLocker-protected volumes.
DRA recovery will work only on BitLocker-protected volumes where BitLocker was enabled after the policy was enforced. The advantage of this method over password/key recovery is that a DRA functions as a BitLocker master key. This lets you recover any protected volume encrypted under the influence of the policy, rather than having to locate a unique password or key for each volume to be recovered.
Many of today’s removable storage drives have the average storage capacity approaching that of most small and medium-size departmental-level file shares from ten years ago. This presents several challenges.
First, when a removable storage device is lost or stolen, a significant amount of organizational data can be compromised. And perhaps a bigger problem is that while users will quickly make the IT department aware of a missing laptop computer, they don’t feel the same urgency when a USB storage device that may contain gigabytes of organizational data has gone missing.
BitLocker To Go, a new feature introduced with Windows 7, lets you protect USB storage devices in a way similar to what BitLocker offers for operating-system and fixed drives. Through group policy, you can restrict computers in your organization so that they can only write data to removable storage devices protected by BitLocker To Go. This increases security by ensuring that if a user does lose a removable device, at least the data on it is encrypted and can’t be easily accessed by unauthorized third parties.
The relevant BitLocker To Go policies are located in the Computer Configuration | Administrative Templates | Windows Components | BitLocker Drive Encryption | Removable Data Drives node of a group policy object. These policies include:
· Control use of BitLocker on removable drives. This lets you configure how BitLocker is used on removable drives, including whether ordinary users can enable or disable the facility on removable devices. For example, you may want to let specific users store data on removable drives already configured with the protection capability, but block them from configuring their own devices with it.
· Deny write access to removable drives not protected by BitLocker. This policy lets you restrict users so they can only write data to devices protected by BitLocker To Go encryption. When this policy is enabled, an unauthorized person can’t easily access data written to a removable device, as it will be protected by encryption.
· Choose how BitLocker-protected removable drives can be recovered. This policy lets you configure a data recovery agent or save BitLocker To Go recovery information within Active Directory. This policy is important, because if you choose to implement BitLocker To Go to protect data on removable devices, you should have a strategy to recover data for the inevitable case where a user forgets his or her BitLocker To Go password.
When you’ve configured BitLocker To Go for a removable storage device, a user must enter a password to unlock the device on another computer. When the password is entered, the user will have read/write access to the device on a computer running the Enterprise or Ultimate editions of Windows 7. You can also configure BitLocker To Go to allow the user read-only access to BitLocker To Go protected data on computers running other versions of Microsoft operating systems.
If your organization is going to use BitLocker To Go, you’ll need some sort of data recovery strategy in the event of lost or forgotten passwords. Configuring BitLocker To Go recovery is similar to configuring BitLocker recovery. In this case, you’ll have to set the Computer Configuration | Windows Settings | Administrative Templates | Windows Components | BitLocker Drive Encryption | Removable Data Drives | Choose How BitLocker-Protected Drives Can Be Recovered policy.
You can have the BitLocker To Go passwords backed up to Active Directory, where they’ll be available to administrators who have access to the Active Directory Users and Computers console and the computer account where the device was originally protected. You can also configure a policy so that data is protected with a DRA, allowing a user assigned the DRA certificate to recover data from the drives without necessitating the recovery of individual passwords.
No anti-malware utility can catch every malicious program. AppLocker can add another layer of protection. This technology lets you create a list of applications known to be safe and limit execution to those that are on the list. While this type of approach to securing a computer would be cumbersome to someone who regularly runs new and unusual software, most organizations have a standard system environment where changes to applications occur more gradually, so allowing the execution of only green-lighted applications is more practical.
You can extend this set of AppLocker authorization rules to include not only executable files but also scripts, DLLs, and files in MSI format. Unless the executable, script, DLL or installer is authorized by a rule, it won’t execute.
AppLocker makes creating the rule list for authorized applications simple with a wizard that automates the process. This is one of the significant improvements of AppLocker over software restriction policies, a technology in prior Windows versions that has similar core functionality.
AppLocker can also use rules that identify files using the file publisher’s digital signature, so you can create rules that include the current and future versions of the file. This saves administrators the chore of updating current rules after applying software updates. The revised executable file, script, installer or DLL will still be covered by the original rule. This wasn’t possible with software restriction policies, which forced admins to update rules when software configurations changed.
To create a reference set of AppLocker policy rules you can apply to other computers, perform the following steps:
1. Configure a reference computer running Windows 7 with all the applications you want to execute in your environment.
2. Log on to the computer with a user account that has local Administrator privileges.
3. Start the Local Group Policy Editor by running Gpedit.msc from the Search programs and files textbox.
4. Navigate to Computer Configuration | Windows Settings | Security Settings | Application Control Policies | AppLocker | Executable Rules of the local GPO. Right click on the Executable Rules node and then click automatically generate new rules. This will launch the Automatically Generate Executable Rules wizard.
5. In the textbox labeled Folder that contains the files to be analyzed, enter c:\. In the textbox labeled Name to identify this set of rules, enter All Executables and then click Next.
6. On the Rule Preferences page, select Create publisher rules for files that are digitally signed, and in case a file isn’t signed, also select File hash: rules are created using a file’s hash. Ensure that the option Reduce the number of rules by grouping similar files isn’t selected, and then click Next.
7. Rule generation will take some time. When they’ve been generated, click Create. When prompted as to whether you want to create the default rules, click No. You don’t have to create these—by creating rules for all executables on the reference computer, you’ve created the equivalent of more-comprehensive default rules.
8. If the computer has applications stored on multiple volumes, repeat steps 5 through 7, entering the appropriate drive letter when running the automatically generated executable rules wizard.
9. Once rules have been generated, you can export the list of allowed applications in XML format by right-clicking on the AppLocker node, then clicking on Export Policy. You can also import these rules into other group policy objects, such as those that apply to portable computers in your organization. By applying these rules through policy, you can limit the execution of applications so only those present on the reference computer are allowed.
10. When configuring AppLocker, you need to ensure that the Application Identity service is enabled through the services console and that executable rules are enforced through policy. If this service is disabled, AppLocker policies will not apply. Although you can configure service startup status within Group Policy, you must limit which users have local administrator access so that they are unable to circumvent AppLocker. You enable executable rule enforcement by right-clicking on the Computer Configuration | Windows Settings | Security Settings | Application Control Policies | AppLocker node and then clicking on Policies. Enable the Configured option under Executable Rules and then ensure that Enforce Rules is selected.
Hopefully this has helped you learn how to implement and recover BitLocker, to use BitLocker To Go and to configure AppLocker Policies. Using these technologies along with normal housekeeping tasks (such as ensuring that computers are kept current with updates, antivirus software and antispyware programs), will enhance the security of computers in your organization running Windows 7.
Orin Thomas (email@example.com) is a systems administrator and Windows Consumer Security MVP based in Melbourne, Australia. He’s written and coauthored more than a dozen textbooks for Microsoft Press.