Bitlocker was hyped a lot in Windows Vista and it appears here as well.
It was meant to prevent unauthorized access to your hard drives by "locking" the information from unauthorized eyes.. It's back in Windows 7.
My primary method of transferring data is to use one of the half dozen or so USB sticks I carry around in my backpack. Over time, these USB sticks end up with all sorts of different data and documents on them.
As a security guy, I worry about what would happen if I lost one of these USB sticks. What if I have some confidential or customer data on one of them?
Windows 7 helps address the continued threat of data leakage with introduction of BitLocker To Go: an extension to BitLocker in Windows Vista that allows me to encrypt the disk volume of removable storage devices with a password and/or a digital certificate stored on a smart card.
BitLocker To Go was designed to facilitate the secure sharing of data on removable storage devices and was designed to work on any standard removable storage device. No special, proprietary hardware is required.
So now, whether you are traveling with your laptop, sharing large files with a trusted partner, or taking work home, you can feel secure that your data is safe. Both traditional BitLocker and BitLocker To Go protected devices help ensure that only authorized users can read the data, even if the media is lost, stolen, or misused.
Once deployed, the software configuration of a typical desktop begins to drift away from its desired state.
The inconsistencies come more often than not from the installation and execution of non-standard software within the desktop environment. Users bring software into the environment from a variety of sources: home, Internet downloads, peer-to-peer file sharing, and through e-mail.
The result is a higher incidence of malware infections, more help desk calls, and difficulty in ensuring that your desktops are running only approved, licensed software.
In addition, many non-productive applications installed by end users cause incompatibilities with business applications, cause performance degradation on the local desktop, or needlessly consume network bandwidth.
As a result, many organizations are looking to exert more control over their desktop environment through a variety of lockdown schemes. A leading analyst predicts that fifty percent of organizations with over 1000 desktops will deploy some desktop lockdown mechanism by the end of 2010.
As a first step in locking down their desktop environment, organizations typically look toward removing administrative privilege from their users.
Running as a standard, non administrative, user is a step in the right direction, because it does help limit the configuration changes that can be made in the desktop environment; however, running as a standard user does not eliminate unknown / unwanted software in your organization.
It is not uncommon for standard users to download and install applications that do not require any administrative privileges. Users are also able to download and run single file executables, like web browsers or malicious greeting cards that continually make the rounds. These threats put organizations at risk from malware that targets user data.
Once administrative access is removed, many organizations realize that it is not a total solution. In addition to the issues called out above, organizations also find that there is great benefit in allowing users the ability to install innocuous or approved software themselves but they still have a need to prevent users from installing software that is considered risky.
Application control solutions provide an alternative approach for allowing organizations to exert more control on the software that is executed in their desktop environment. Software Restriction Policies (SRP), in Windows XP and Windows Vista®, was one of the first application control solutions in the marketplace.
SRP gave IT administrators a coarse mechanism to define and enforce application control policies.
However, SRP could become a management burden in a very dynamic desktop environment where applications were installed and updated on a constant basis because they predominantly utilized hash rules. With hash rules, every time an application needs updating a new hash rule needs to be created.
Windows 7 AppLocker
Windows 7 addresses the growing desire for application control solutions in the enterprise with the introduction of
AppLocker: a simple and flexible mechanism that allows administrators to specify exactly what is allowed to run in their desktop environment.
As a result, AppLocker provides not only security protections, but also operational and compliance benefits by:
- Keeping unlicensed software from running in your desktop environment
- Preventing vulnerable, unauthorized applications from running in your desktop environment, including malware
- Stopping users from running applications that needlessly consume network bandwidth or otherwise impact the enterprise computing environment
- Preventing users from running applications that destabilize their desktop environment and increase helpdesk support costs
- Easing enterprise software deployments and maintenance through effective desktop configuration management
- Allow users to install and run approved applications and software updates based upon their business needs
- Helping ensure your desktop environment is in compliance with corporate policies and industry regulations such as PCI DSS, Sarbanes-Oxley, HIPAA, Basel II, and others
AppLocker provides a simple and powerful structure through three rule types: allow, deny, and exception. Allow rules limit execution of applications to a "known good list" of applications and block everything else.
Deny rules take the opposite approach and allow the execution of any application except those on a list of “known bad” applications. While many enterprises will likely use a combination of allow rules and deny rules, the ideal AppLocker deployment would use allow rules with built in exceptions.
Exception rules allow you to exclude files from an allow/deny rule that would normally be included. Using exceptions, you can create a rule to “allow everything in the Windows Operating System to run, except the built-in games.” Using allow rules with exceptions provides a robust way to build a “known good list” of applications without having to create an inordinate number of rules.
AppLocker introduces publisher rules that are based upon application digital signatures. Publisher rules make it possible to build rules that survive application updates by being able to specify attributes such as the version of an application.
For example, an organization can create a rule to “allow all versions greater than 9.0 of the program Acrobat Reader to run if it is signed by the software publisher Adobe.” Now when Adobe updates Acrobat, you can safely push out the application update without having to build another rule for the new version of the application.
AppLocker supports multiple, independently configurable policies: executables, installers, scripts & DLLs. The multiple policies allow an organization to build rules that go beyond the traditional executable only solutions, providing greater flexibility and enhanced protection.
For example, an organization could create a rule to “allow the Graphics Department to get updates directly from Adobe for Photoshop as long as it is still Adobe Photoshop version 14.*”.
This allows IT to retain control but empower users to keep their systems up to date based upon their business needs. In addition, each of these policies can be individually placed into an audit only mode allowing you to test your rules before they start blocking applications from running and potentially hurting end user productivity.
AppLocker rules can be associated with a specific user or group within an organization. This provides granular controls that allow you to support compliance requirements by validating and enforcing which users can run specific applications.
For example, you can create a rule to “allow people in the Finance Department to run the Finance line of business applications.” This blocks everyone who is not in your Finance Department from running your finance applications (including administrators), but still provides access for those that have a business need to run the applications.
AppLocker provides a robust experience for IT administrators through new rule creation tools and wizards. Using a step-by-step approach and fully integrated help, creating new rules, automatically generating rules and importing / exporting rules is intuitive so that rules are easy to create and maintain.
For example, IT administrators can automatically generate rules using a test reference machine and then import the rules into a production environment for widespread deployment. The IT administrator can also export policy to provide a backup of your production configuration or to provide documentation for compliance purposes.
AppLocker is a new technology in Windows 7 that will be part of the Enterprise SKU, while the legacy Software Restriction Policies will be available in the Business and Enterprise SKUs.
Windows 7: Enterprise Security
There is a lot of buzz about the security features in the upcoming release of Microsoft’s Windows 7 operating system, especially User Account Control (UAC).
Microsoft designed UAC to control the elevated “administrator” privilege that is so dangerous from an IT security perspective.
UAC debuted in Windows Vista to help reduce privilege levels of all users, non-IT and IT employees alike, when tasks were being performed that did not require elevation.
Despite these good intentions, however, Vista’s UAC received a tremendous amount of negative feedback due to the number of “pop-up” windows that occur during routine use of the desktop.
Windows 7 features a new approach to UAC, providing a “slider” to control how often UAC pop-ups occur and for which actions they are monitoring.
The questions these changes raise include:
- What exactly does UAC do?
- How should UAC be set in order to protect your desktops?
- Is the “slider” a good decision?
What UAC is designed to do
When UAC is enabled in either Vista or Windows 7 the goal is the same - to protect the user from unknown malware and viruses running in the background, as well as from unauthorized changes to the operating system files and Registry.
When a task is triggered that causes a protected part of the operating system to be modified, UAC will prompt the user for consent (if an administrator) or prompt the user for the credentials necessary for the privilege to perform the action (if the user is a standard user).
For standard users, UAC is not an ideal solution. With the prompt for credentials that UAC provides, there are only two possible solutions to allow the action to be performed. The first is the “over the shoulder input from an IT employee” when there is a prompt, which is not feasible due to mere logistics.
The second is to give the user alternate credentials, which in essence grants the user administrative privileges to the entire computer. Both options provide poor solutions to the issue.
However, for administrators, UAC provides an excellent solution for protecting the computer against actions that were not launched by the user, but were launched from malicious code running in the background.