Practical App
Windows 7 Security Tips: Keep Your Files Safe with BitLocker and AppLocker
Keep your files safe with BitLocker and AppLocker.
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 anti-spyware and anti-virus 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.
Prepare for BitLocker
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 a stolen or lost laptop, as long as the computer was powered off when it went missing.
One challenge BitLocker presents, however, 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 (ADUC) console in Windows Server 2008 R2 and to the Remote Server Administration Tools for computers running Windows 7. Locating recovery passwords and keys is much easier than with the tools in Vista.
Instead of downloading, installing and configuring special tools, you can access BitLocker recovery keys and passwords from a BitLocker Recovery tab.
Ensuring BitLocker keys and passwords are backed up is a three-step process:
- In the Group Policy for the computer accounts of the system BitLocker will protect, go to Computer Configuration | Windows Settings | Administrative Templates | Windows Components | BitLocker Drive Encryption.
- 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.
- To configure BitLocker so that passwords and keys are backed up to AD when BitLocker protection is activated, make sure to enable the settings:
- Save BitLocker recovery information to AD Domain Services (DS) for operating system 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 won't have their keys and passwords automatically stored in AD. 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.
Configuring a DRA
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 DRAs 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 AD. 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 a DRA, you must also select "Enable data recovery agent" 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 AD 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.
BitLocker To Go
Many of today's removable storage drives have an average storage capacity which approaches that of most small and midsize departmental-level file shares from 10 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. 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 is a new feature introduced with Windows 7. It lets you protect USB storage devices in a way similar to what BitLocker offers for OS 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 (GPO). 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.
- 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 DRA or save BitLocker To Go recovery information within AD. 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 OSes.
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 AD, where they'll be available to administrators who have access to the ADUC 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.
Configuring AppLocker
AppLocker 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. To create a reference set of AppLocker policy rules you can apply to other computers, perform the following steps:
- Configure a reference computer running Windows 7 with all the applications you want to execute in your environment.
- Log on to the computer with a user account that has local Administrator privileges.
- Start the Local Group Policy Editor by running Gpedit.msc from the Search programs and files textbox.
- 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.
- 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.
- 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.
- 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.
- If the computer has applications stored on multiple volumes, repeat steps five through seven, entering the appropriate drive letter when running the automatically generated executable rules wizard.
- 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 GPOs, 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.
- 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 won't 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, anti-virus software and anti-spyware programs, will enhance the security of computers in your organization running Windows 7.
About the Author
Orin Thomas is an MVP, a Microsoft Regional Director, an MCT, and has a string of Microsoft MCSE and MCITP certifications. He has written more than 30 books for Microsoft Press on topics including Windows Server, Windows Client, Azure, System Center, Exchange Server, Security, and SQL Server. He is an author at PluralSight and is a contributing editor at Windows IT Pro. He has been working in IT since the early 1990's and regularly speaks at conferences in Australia and around the world. Orin founded and runs the Melbourne System Center, Security, and Infrastructure Group and is a candidate in the Doctor in Information Technology program at Charles Sturt University. You can follow him on twitter at http://twitter.com/orinthomas