Security

First Look: New Security Features in Windows Vista

Chris Corio

At a Glance:

• User Account Control
• Consent and Credentials
• Code Integrity
• Data Encryption
• Application Isolation
• Data Redirection
• Cryptography
• Credential Providers
• Service Hardening
• Windows Defender
• Rights Management Services

Windows Vista

Security

The upcoming release of Microsoft Windows Vista will introduce an entirely new generation of security technologies

for the desktop. Some of these security technologies are aimed at strengthening the overall Windows infrastructure so that it is even more reliable and trustworthy, and others are aimed specifically at helping you keep control of both your system and your data.

To showcase the security enhancements for this upcoming Windows® release, I’m going to highlight 11 new security features slated for Windows Vista™ you should know about when planning a system rollout in your enterprise, or even for your home. Some of the features I highlight here may be more relevant to you than others—everyone has different needs and biases. Be aware that some details of these features could change between now and the final release of Windows Vista. So, without further ado, let’s get started.

User Account Control

Code Integrity

Code Integrity (CI) protects Windows Vista by verifying that system binaries haven’t been tampered with by malicious code and by ensuring that there are no unsigned drivers running in kernel mode on the system. CI starts as Windows starts up. The boot loader checks the integrity of the kernel, the Hardware Abstraction Layer (HAL), and the boot-start drivers. After these binaries have been verified, the system starts and the memory manager calls CI to verify any binaries that are loaded into the kernel’s memory space. The binaries are verified by looking up their signatures in the system catalogs. Aside from the kernel memory space, CI verifies binaries loaded into a protected process and system installed dynamic libraries that implement core cryptographic functions.

One of the first technologies you will likely encounter in Windows Vista is User Account Control (UAC). This suite of technologies is aimed at bringing the standard user to the forefront of Windows Vista. In the past, companies were often forced to run their users as administrator so they could perform various system functions, such as changing the time zone, or because a critical line-of-business (LOB) application required administrative privileges. When UAC is enabled, all users on a given computer, including administrators, will be running most applications with a standard user access token by default.

There are several technologies that make up UAC including: the Application Information Service (AIS), the credential/consent prompt, installer detection, and data virtualization. These technologies all share the goal of helping users move away from always running with administrator privileges. Developers will be able to mark which applications will require administrator privileges on Windows Vista. AIS will run only these applications with administrator privileges and only when the user consents to do so. Also, the Installer Detection and Data Virtualization features will help legacy applications work in the new environment.

The UAC technologies begin working the moment a user logs into the system. Let’s consider what happens when a member of the Administrators group logs onto a computer running Windows Vista. During login, the Local Security Authority (LSA) service notes that the user is in the Administrators group and creates a filtered access token for this user. This filtered access token looks like the access token of a user in the Users group, what I call a standard user access token (see Figure 1).

Figure 1** Login Token Creation **

The default access token that is used to launch the desktop, the explorer.exe process, is a standard user access token, and any child processes of explorer.exe will inherit this standard user access token. If a user who is a member of the Users group were to log on, that user’s access token would not be affected and the token used to create explorer.exe would also be a standard user access token.

Obviously, there are certain operations that should fail when running with a standard user access token, such as modifying user permissions. In these cases, the apps can be marked with an attribute in the application manifest denoting that the process must be created by a user with administrator privileges. Another option is to run the application with the highest access token available.

Consent and Credentials

A primary feature of UAC is that users cannot run with their full administrator access token without giving explicit consent. When Windows Vista determines that the process should be created with the full administrator access token, the service alerts the user that this service requires consent to run with the user’s full access token (see Figure 2).

Figure 2** Consenting to Run an App **

What would happen if the user is only a standard user and tries to run something that required administrator privileges? In this case, the user would be prompted to input the credentials of an administrator user (see Figure 3). When the user enters valid credentials, she is allowing AIS to use the specified administrator access token. For added security, the consent dialog box is protected from receiving messages from other processes that are not running as an administrator.

Figure 3** Providing Credentials **

If you are an IT professional, you may find that certain apps require the full administrator token when running because they directly impact the system. These apps must be marked as requiring administrator privileges, which you do in the app compatibility database. After these privileges are specified, the app will prompt the user for consent when run next. You can then deploy the app marking to all machines throughout an enterprise by using Group Policy.

Data Encryption

Application Isolation

Mandatory Integrity Control (MIC) allows Windows to control communication between processes by defining various integrity levels in which processes execute. An application running as a standard user in Windows Vista would typically be created at the medium level, whereas an application running with the full administrator access token would be running at the high level. Process isolation provides a way to extend the authorization model to common extension points for interprocess communication. For example, if an application running at medium integrity were to register a hook to process Windows messages, this hook would not be active in a process running at the high integrity level.

Currently in Windows Vista, Internet Explorer 7.0 will be running at the low integrity level and therefore will only be able to modify objects marked with a low integrity level in their system ACLs. Any code running at low will not be able to modify any of the user’s data or the Windows binaries on the machine, unless the ACL is changed from the default. Also, the application can only write to locations marked as low, such as the Temporary Internet Files folder, and any files that are written will be marked with the low integrity level. So if you were to download a piece of software from the Web, save it in the Temporary Internet Files folder, and then execute it, the downloaded app would in turn be running at low integrity. The app would not have access to any of the user’s data, adding an extra layer of security to downloaded content from the Web.

Let’s switch gears a bit to talk about technologies that are designed specifically to protect user data. Windows Vista includes technologies to protect the files on your system whether they reside on a local drive or a network server, or even if you share them with others. And the new BitLocker™ feature introduces full system volume encryption, making the data on your hard disk even more secure.

The redesigned Encrypting File System (EFS) in Windows Vista includes full support for storing users’ private keys on smart cards. If a user logs on to Windows Vista with a smart card, EFS can seamlessly use it for file encryption as well. Administrators can even store their domain’s recovery keys on a smart card. Recovering files is then as easy as logging on to the affected machine, locally or using Remote Desktop, and using the recovery card to access the files. You no longer need a dedicated workstation for data recovery!

The new user interface includes convenient tools to back up keys and prevent data loss, and to migrate your existing EFS files to your new keys. For administrators, a new policy interface provides the control to set requirements such as minimum encryption strength and use of smart cards. You can even use EFS to encrypt the Windows page file. EFS is also more tightly integrated with enterprise Public Key Infrastructure (PKI), and supports using PKI-based key recovery, data recovery through EFS recovery certificates, or a combination of the two.

You can find the new BitLocker feature in the Security category of Control Panel. There you will see the BitLocker control panel applet. When you open the applet, a wizard walks you through the process of creating startup and recovery keys, which will enable you to encrypt the drive. Volume contents are encrypted with a Full Volume Encryption Key (FVEK), which in turn is encrypted with a Volume Master Key (VMK). In the basic use scenario, the VMK is bound, or sealed, to the Trusted Platform Module (TPM) security chip found in today’s newer PCs (see Figure 4).

Figure 4** BitLocker Encryption Architecture **

BitLocker can be configured with more advanced settings to increase the security of the system. The TPM chip can require the user to enter a PIN before releasing the VMK. The user can also create a startup key that can be stored on a USB flash drive and that is used to release the VMK while starting the computer. If a TPM chip is not installed on the machine, you can just use the USB drive to hold the startup key, which would then be used to decrypt the FVEK on startup.

However, if you’re going to rely on a USB drive for multifactor authentication, it is important to note that a user would need to insert a USB storage device every time she wanted to boot the machine. Just in case, though, it is possible to access the encrypted volume by entering the recovery password.

Now that you have generated all the keys and know where they live, let’s look at how they work. The keys are used the moment the computer has booted. Initially, the bootloader looks in the TPM chip to see if BitLocker is enabled. When it finds that the feature is enabled and the proper multifactor authentication has been performed (if configured), the bootloader will release the information necessary to unlock the VMK. The VMK is then used to retrieve the FVEK, which in turn is used by a file system driver to decrypt the data on the hard disk. Just like magic, your data is free. However, if the startup configuration of the environment has changed, or the encrypted volume is started in another computer or with another operating system; BitLocker enters recovery mode until you provide the recovery password.

Data Redirection

Credential Providers

There are a number of other core security infrastructure upgrades to look out for in Windows Vista. First, the Graphical Identification and Authentication (GINA) credential input extension model has been deprecated in favor of a more simple and straightforward credential provider model. This new model allows vendors to write credential providers with ease compared to writing a GINA. Previously, there could only be one GINA on a system, which sometimes made deployment difficult and limited the flexibility of the system. Windows Vista now enables you to have multiple providers and select a particular one as the default. For example, you can easily deploy a multifactor authentication credential provider method while not overwriting a default single-factor authentication provider. To add a provider, all you need to do is to put registration information for the DLL in the registry and export the entry points for the credential provider APIs.

With so much emphasis on running as a standard user, there’s some concern about whether common LOB applications will function correctly. To address this concern, the data redirection feature facilitates application compatibility. Data redirection, also known as data virtualization, provides a driver for the file system and registry that will redirect writes targeted at certain protected locations, such as HKEY_LOCAL_MACHINE\Software or %ProgramFiles%, to the user’s profile.

For example, if a member of the Users group is logged onto a machine and runs an application that writes a log file back to the Program Files directory, this write will fail. Why? Because the access control list (ACL) on the Program Files directory does not allow standard users to write to that location. When the data redirection file system driver receives the failed return code from this write, it redirects the write to a copy of the file made in the virtual store, a location in the user’s profile. An application that is marked with a run level in its manifest or that is a natively compiled 64-bit app is assumed to not require virtualization, so data redirection is disabled for that app. Windows binaries are marked with a run level, thereby disabling virtualization, and it is a requirement of the Windows Vista logo program that certified apps can run without data virtualization.

Another technology designed to flag legacy applications as needing elevation is installer detection. Installer detection tells AIS that an app needs to be elevated based on certain predefined criteria, such as the executable name containing "setup" or the binary resources containing "installer." There is currently no facility within Windows Vista to delegate elevation of an app to certain users or groups.

Cryptography

Crypto NextGen (CNG) is the next version of the Crypto API (CAPI) that provides a much more flexible and agile cryptographic development platform in Windows. In this case, flexible and agile means that CNG can be pluggable to an unprecedented degree, allowing users to create custom cryptography algorithms and implementations that fit seamlessly into the overall CNG infrastructure. Microsoft is also introducing Elliptic Curve Cryptography, which is becoming the industry’s cryptographic algorithm of choice, to the Windows Vista CNG suite.

To make smart cards more accessible on Windows Vista, Microsoft is planning to include the Base Smart Card Cryptographic Service Provider (Base CSP) as part of the platform. This means smart card vendors no longer need to write a complex CSP, and instead can simply write a lightweight card module that plugs into the smart card architecture. This will help reduce the development effort. The new CNG infrastructure also includes a smart card Key Storage Provider (KSP). The card module written for the Base CSP will also work for the smart card KSP (see Figure 5).

Figure 5** Base CSP Infrastructure **

Service Hardening

Finally, Windows Service Hardening technology limits the privileges of services and restricts the resources services can directly affect. There are several degrees to which Service Hardening can help protect the system. The minimum level ensures that the Service Control Manager will obtain an access token with fewer privileges than would have been given out in previous versions of Windows when a service starts. For example, services running under the LocalService account now will no longer have SeTCBPrivilege. An even more secure use of Service Hardening is to define a security identifier (SID) for each service, which allows the service to secure resources through ACLs based on the service’s SID. The most secure method is for developers to mark their services as write-restricted so they only have write access to objects that specifically allow that privilege. This extension of the security model for services will dramatically enhance your ability to secure ser-vice behavior and limit the impact of service vulnerabilities.

Windows Defender

Spyware is a general term used for software that does things like producing annoying pop-up ads, slowing your computer’s performance, changing machine configuration settings, and snooping on your personal data. And to top it all off, spyware typically doesn’t ask the user for permission to install itself.

To help combat the growing spyware problem, Microsoft made the Windows AntiSpyware Beta available, and it has been one of the company’s most successful beta releases yet. Microsoft will be incorporating this technology directly into Windows Vista with Windows Defender.

Windows Defender represents a complete rewrite of the Windows AntiSpyware Beta that is designed to have the same ease-of-use as the original product (see Figure 6). The first place you will want to look for Windows Defender is the Control Panel or the Start menu. The Windows Defender interface was designed to make scanning a quick, easy task that any user, regardless of computer experience, can perform. Aside from running a quick scan, users can also schedule recurring scans or clean spyware and other potentially unwanted software from their computers. Windows Defender helps to stop spyware in its tracks with continuous protection by guarding files, services, and other interfaces attacked by spyware.

Figure 6** Windows Defender **

Under the covers, Windows Defender uses the aptly named Windows Defender service, which provides all of the facilities for managing signature data, scheduling scans, and performing operations such as data removal and quarantine. The user interface sends configuration data to the service through RPC. This allows the Windows Defender user interface to function in the standard user environment and send pertinent data to the service running under the LocalService account.

Obviously, the first thing you will want to do with Windows Defender is schedule a scan on the computer. Thankfully, Windows Defender is set to Autoscan by default and its Autoclean settings will remove any threats noted to be Severe or High. By default, Windows Defender asks the user to specify what action to perform on threats marked Medium or Low. The Autoclean and Autoscan settings are also fully configurable. When a scan finishes, Windows Defender presents the results so that users can make decisions about the threats found on the computer. The user can also save the results in an encrypted file for use later.

As part of the scan process, Windows Defender checks applications installed on the system against a list of app definitions. Each app definition contains plenty of information about an app including the application name, the version number, both short and long threat descriptions, and a recommended action (Ignore, Remove, Quarantine, and so on) should that app be found. These definitions are used to find any known threats running on the machine.

After performing a scan, you need to deal with the results—especially if you’ve found something potentially malicious on the system. This is when you make use of the removal and quarantine features in Windows Defender. You choose the action you would like performed on the various threats, then the Windows Defender service takes this list and executes the actions you specified. Obviously, if you chose to ignore a threat, no action will be performed. But if you elected to remove the threat, the service employs the appropriate resource managers to remove each type of resource listed in the scan result. If you decided to quarantine the threat, it would be moved to an alternate location and not allowed to execute. In both cases, the service creates a restore point that you can roll back those changes to if necessary.

Rights Management Services

To facilitate sharing and collaboration, the Rights Management Services (RMS) client is now part of Windows Vista. RMS is designed to secure data against unauthorized use when it is sent in e-mail or used in any other rights-enabled application, such as Microsoft Word or Microsoft Excel®. There are three components to the RMS solution: the server, the desktop, and the platform. For the server part of this equation, Windows Rights Management Services for Windows Server™ 2003 is required. This information protection service of Windows Server 2003 establishes user account certificates, issues use licenses, enables the creation and storage of the rights policy templates, and so on.

The desktop tier performs the actual data security operations like encrypting data, and is planned for inclusion by default on Windows Vista. This allows you to use applications that integrate with RMS technologies and immediately take advantage of the feature without incurring the cost of an additional deployment.

Windows Vista also provides a significant update in the RMS platform for creating rights-protected information. This update comes in the form of Windows Presentation Foundation, which delivers a set of APIs that allows developers to rights-enable any file built using the Open Packaging Conventions. This defines a file format for application information that will be used by XML Paper Specification (XPS) Documents and the next version of Office. Windows Vista will also include an RMS-enabled XPS Viewer that can rights-protect any data published in this format.

Chris Corio is a Program Manager on the Windows Security team. His interests are primarily application security technologies and management technologies for securing Windows.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.