Seven years after kicking off its Trustworthy Computing initiative, Microsoft launched Windows 7 last October. The software giant touts the operating system, which builds on the security features of Vista, as key to its "End to End Trust" vision for a more secure Internet. With Windows 7, Microsoft also aims to make security easier to use; Vista, which debuted three years ago, caught criticism for security functionality users and administrators...
alike found clunky and obtrusive.
Let's take a look at several of the security features of Windows 7, including a more flexible BitLocker for data protection, auditing enhancements to help meet compliance requirements, an improved User Access Control with fewer prompts, and new functionality to ensure system integrity.
In today's fast-paced, mobile environment there is more opportunity than ever before for data to fall into unauthorized hands. Hundreds of thousands of laptops containing sensitive information are lost, stolen or decommissioned every year. Additionally, portable USB devices are inexpensive, easy to use, and everywhere. Failure to protect corporate data can result in critical consequences, including lawsuits, regulatory penalties, loss of brand reputation and consumer confidence, and even criminal prosecution. As such, organizations are implementing data encryption technologies to help mitigate the risks of data loss or exposure. Windows 7 helps organizations on this front with enhanced Encrypting File System protection and an easier to install BitLocker Drive Encryption (BDE).
EFS can be used to encrypt individual files or folders that have been stored on NTFS-formatted drives to protect them from unauthorized access. In Windows 7, EFS has been enhanced to support Elliptic Curve Cryptography (ECC), a second-generation Public Key Infrastructure algorithm. For protection of "top secret" documents, U.S. government agencies must comply with encryption requirements referred to as Suite B. Because Suite B does not permit the use of RSA cryptography, organizations with existing RSA implementations must find a streamlined transition path toward compliance. Windows 7 facilitates the transition because it permits the concurrent use of both RSA and ECC algorithms, thus promoting regulatory compliance while maintaining backward compatibility.
In Windows Vista, Microsoft introduced BitLocker Drive Encryption (BDE) to protect computer hard drives (operating system volumes and fixed data volumes) from unauthorized access. In addition to drive-level encryption, BitLocker provides pre-boot verification and integrity checking to ensure that a system has not been tampered with and that the drives have not been moved between computers. This built-in technology was exciting from a cost and security standpoint, but administrators were less enthused about its implementation. For instance, installation often required that a system's hard drive be repartitioned.
In Windows 7, BitLocker is available in the Enterprise and Ultimate editions, and has been updated in a variety of ways to improve both administrative and the user experiences. Full implementation requires a computer with a Trusted Platform Module 1.2 chipset and a compatible BIOS. It's possible to implement BitLocker on a computer that doesn't support TPM 1.2 if the BIOS supports USB devices during startup, but you'll lose the pre-boot checks and system integrity verification. To configure BitLocker encryption to work without a TPM, you must enable the "Require additional authentication at setup" Group Policy setting and select the "Allow BitLocker without a compatible TPM" checkbox. After the setting is applied, all non-TPM BitLocker settings will be visible in the BitLocker Setup Wizard in the Control Panel.
BitLocker encryption capabilities now extend to removable media in a feature called BitLocker To Go. For a detailed review of Windows 7 changes to BitLocker, see below.
In addition to facilitating encryption, Windows 7 aims to ease compliance requirements related to IT security through new policies and a greater level of detail in security logs. Enhancements include:
- Advanced Audit Policy settings: In Windows XP there were nine categories of auditable events that could be monitored for success, failure or both. In Windows Vista the number of available categories was expanded to 53 to provide better targeting and granularity of data collected. This helps to eliminate unwanted data which makes log files large and difficult to analyze. Unfortunately, these categories and settings were not integrated with Group Policy for centralized management. In Windows 7 (and Windows Server 2008 R2), all 53 new auditing event categories have been integrated into Group Policy under Local PoliciesAudit Policy.
- "Reason for access" reporting: The list of access control entries (ACEs) provided in logs shows the privileges on which the decision to allow or deny access to an object was based. Forensic analysis is improved because auditors can determine the reason why someone had access to specific resources based on specific permissions.
- Global Object Access Auditing: Administrators can define system wide per-object type system access control lists (SACLs) for the file system and the registry, which will automatically be applied to all objects of that type.
AUTHENTICATION AND AUTHORIZATION
Windows 7 includes several features to help in the critical areas of authentication and authorization. For example, previous versions of Windows had the built-in Administrator account that was intended to facilitate setup and disaster recovery, but because the account was always called "Administrator," had the same security ID on all computers and was often given a consistent password throughout the enterprise, was a prime target for attacks. If a system was compromised, an attacker would have access to the password hash, which could then be used to authenticate to any other computer which used that same account. With Windows 7, the Administrator account is now disabled by default. Only local accounts specifically created with administrator privileges or domain accounts that are members of the Domain Admin group can log on locally to a Windows 7 computer. In addition, the built-in domain Administrator account in Windows Server 2008 R2 (first account created) will not run in Windows 7 Admin Approval mode, but subsequently created domain administrator accounts will.
Other ways in which Windows 7 helps facilitate authentication and authorization include:
Managed Service Accounts
For application services or processes to function, they must be assigned an account under which to interact with the operating system and other applications. Sufficient privileges must be granted to a "service account" for it to function, but granting unnecessary rights increases security risks. Windows operating systems have long provided local computer accounts that can be used to run services on the computer (Local Service, Network Service, or Local System). Managing local accounts across multiple computers in the enterprise would be a nightmare; as such, administrators frequently create domain-level accounts to be used as service accounts across the enterprise. Unfortunately, this solution does not eliminate the need to manually manage the account passwords or perform Service Principal Name (SPN) maintenance. Failure to timely manage these accounts can result in a disruption of services.
To alleviate this problem, Windows 7 supports a new type of account called a managed service account. This allows administrators to create a group of domain accounts that can be used with services and specialized applications (like IIS and SQL) on local computers. The accounts provide security isolation for services and applications, but do not require SPN or password maintenance (passwords are reset automatically). In addition, management of these accounts can be delegated to non-administrators.
Each application and service on the Windows 7 computer can have its own managed service account or a single account can be used by multiple applications; however, the account cannot be shared across multiple computers. In a domain environment, the managed service account can be created and managed from a new Active Directory container called "Managed Service Accounts." This means that accounts on multiple machines throughout the enterprise can be centrally maintained. When using these domain-level accounts, support for both password and service principle name (SPN) management is automatic when the account is on a Windows Server 2008 R2 Domain Controller and the domain is at the Windows Server 2008 R2 functional level. Regardless of the functional level, if the Domain Controller is running Windows Server 2008 or Windows Server 2003, SPN management will still be manual.
User Account Control
User Account Control is a feature which was introduced with Windows Vista to improve security by allowing organizations to deploy operating systems without granting administrative rights to the accounts under which users would function on a daily basis. While UAC achieved this objective, its implementation created frustration among users who were forced to respond to multiple prompts. Even administrators (who know better) were tempted to disable the feature. Windows 7 includes changes to UAC that maintain its security benefits while improving the usability experience for both standard users and administrators.
The number of prompts presented to users has been greatly reduced in the following ways:
- The following tasks will no longer trigger a prompt: Reset network adapters and perform basic network diagnostic and repair tasks; install updates from Windows Updates; install drivers that are included with the operating system or are downloaded from Windows Updates; view windows settings; and connect to Bluetooth devices.
- Prompts for multiple tasks within an area of operation have been merged. As a result, there are fewer prompts to respond to when performing file operations, running Internet Explorer application installers or installing ActiveX controls.
New security policies give administrators greater control over UAC behavior, including control of the UAC messages presented to both standard users and local administrators (when they are working in Administrative Approval mode).
Users with administrative privileges can configure the UAC through a control panel applet. A simple slider allows a choice of four levels of protection ranging from always notify to never notify. Always notify essentially duplicates a Windows Vista UAC experience. Never notify provides an alternative to completely disabling UAC: While it will suppress the prompts, core UAC protections such as protected mode Internet Explorer will remain functional.
In Windows 7, issuance of certificates is simplified with support for new HTTP enrollment protocols based on open Web services standards. Because remote users, business partners and customers can perform certificate enrollment over the Internet or across forest boundaries, fewer certificate authorities will be required for the enterprise.
To take advantage of this new enrollment capability, the Windows 7 computers must connect to a Windows Server 2008 R2 server running the Active Directory Certificate Services (AD CS). Lightweight Directory Access Protocol (LDAP) support is also provided for enrollment compatible with existing CAs running Windows Server 2003 or Windows Server 2008. Administrators can use Group Policy to distribute Certificate Enrollment Web Services locations to domain users.
From a user perspective, Windows 7 makes certificate selection easier. Many applications and Internet browsers utilize a certificate selection dialog box to prompt users when multiple certificates are available. Unfortunately, users are often uncertain which selection to make. Windows 7 improves the user interface and underlying filtering logic to reduce the number of certificates presented to users; the ideal result is a single certificate that requires no action from the user.
As the use of smart card technology increases, administrators are demanding more simplified methods for deployment and management. Windows 7 includes new features designed to both simplify deployment and expand smart card capabilities, including better support for plug-and-play devices. Any software developer who adheres to the Personal Identity Verification (PIV) standard can publish their drivers through Windows Updates. When a user inserts their smart card, Windows will attempt to download the driver from Windows Update; for PIV compliant smartcards, if a driver is unavailable, a compliant minidriver will automatically be used. As a result, in these types of scenarios middleware is no longer required for domain authentication using PKINIT, email and document signing, unlocking Bitlocker protected data, etc.
Security professionals have long championed the need for multi-factor authentication, but because biometrics requires special hardware many organizations have hesitated to implement it with client computers. Fingerprint readers are becoming more common in computer systems, particularly portable computers, making it more feasible for organizations to utilize them as part of their authentication design. Windows 7 includes a Windows Biometric Framework which helps to provide a consistent user experience when utilizing a variety of devices. Provider support enables biometrics devices to perform UAC elevation when logging on to a local computer.
Driver management for biometric devices is now supported under Device Manager, but there is also a Biometric Devices Control Panel item that allows control over biometric devices and whether they can be used to logon to a domain or local computer. Policy settings have been added to Group Policy to ensure that administrators can easily enable, disable or limit the use of biometrics. With Group Policy, it's possible to prevent the installation of biometric device driver software or force it to be uninstalled.
DirectAccess is a new Windows 7 connection capability that securely connects remote users to a Windows Server 2008 R2 server on which the Direct Access feature is installed. Once connected to the Direct Access server, enterprise applications, Web sites and network shared folders points are available. Direct access eliminates the need to first connect to a VPN before being granted access to internal resources. The goal is to securely and transparently provide a remote user with the exact same experience they would encounter while working in their office. Every time a user connects their portable computer to the Internet (even before they log on), DirectAccess establishes a bi-directional connectivity with the user's enterprise network using IPSec and Internet Protocol version 6 (IPv6). IPSec is used to authenticate the computer allowing it to establish an IPSec tunnel for the IPv6 traffic which acts as a gateway to the organization's intranet. IPSec is also used for user authentication, but smart cards can be required for stronger authentication. With DirectAccess, administrators can manage remote computers even when they are not connected to a VPN.
To establish a direct access connection, a Windows 7 computer must be a member of a domain with a Windows Server 2008 R2 Direct Access server. The client machine must be configured for IPv6 and be issued a certificate for use when connecting to the Direct Access website. While there are a number of elements that need to be configured on the server side (IIS, PKI, etc.), it's not complex or difficult, especially since Microsoft has provided a step-by-step deployment guide.
SYSTEM AND INFRASTRUCTURE INTEGRITY
Each time a user downloads or installs unauthorized items to a computer, the attack surface of the system is increased, along with corresponding risks to the organization. Controlling what users can download and install to client computers is essential for maintaining the health and security of an enterprise infrastructure. Windows 7 has features to help with on this front, including:
Software restriction policies were used in Windows XP and Vista to control which applications could be installed on users' computers. Because the rules were predominantly based on hashes, new rules had to be created each time an update to an application was released. This created a major management burden for administrators. AppLocker is a Windows 7 technology which eliminates this management burden.
AppLocker can be used to achieve three primary security objectives:
- Prevent installation of malware.
- Prevent users from installing and using unauthorized programs.
- Meet compliance requirements regarding application control.
AppLocker provides flexibility and is easily implemented through new rule creation tools and Group Policy. Traditional allow and deny rules are expanded through the ability to create "exceptions." For example, you can specify a rule which allows Microsoft Office Suite but creates an exception to block specific users from using Microsoft Outlook 2010. New "Publisher Rules" are based on digital signatures and allow for creation of rules that will survive changes to a product; for instance, a rule that allows users to install updates and patches to an application as long as the product version hasn't changed.
The ActiveX Installer Service (used to managet deployment of ActiveX controls) is now installed by default in Windows 7 and is configured to allow automatic startup when standard users access sites on the Trusted Sites list. Administrators can easily control the trusted sites list through Group Policy, but must also configure Internet Explorer trusted zones such that users cannot edit the Trusted Sites list. This is simple to implement but be aware that the site to zone list must have at least one entry to prevent standard users from installing arbitrary ActiveX controls.
Multiple Active Firewall Policies
Beginning with Windows Vista, firewall policies were based on the type of network connection (home, work, public or domain). While this simplified the configuration of appropriate firewall rules when mobile computers moved between locations, unfortunately it presented an entirely different security problem for administrator to overcome. If a user connected first to a home or public network and then connected to the corporate network through a VPN, the corporate firewall settings will not be applied. Windows 7 overcomes this obstacle by supporting multiple firewall policies on a single system. This allows domain-based settings to be applied to the computer regardless of what other networks it may be connected to.
Overall, the changes to Windows 7 are good steps that will assist enterprise administrators in better securing their environments while reducing the corresponding effort involved. In particular, the changes to BitLocker promise to increase client-side data protection to a higher level than previously possible. And enhancements to auditing capabilities allow an organization to more easily comply with regulatory requirements without implementing costly third-party solutions.
While Microsoft has made significant improvements in the ability to control what information is downloaded or installed to a computer, Windows could still benefit from a more robust built-in firewall. The basic protection of a system should not be largely dependent on third-party products, even those available from Microsoft.
Still, Windows 7 is a clear indication that Microsoft continues its commitment to security but that the company is equally committed to finding ways to simplify implementation and ease the burden on administrators.
Beth Quinlan is a trainer/consultant in infrastructure technologies and security design. Most recently she was the Project Manager and contributing author of Microsoft's Windows Server 2008 "Jumpstart Clinics." Send comments on this article to email@example.com.
Windows 7 makes BitLocker easier to manage and provides encryption for portable devices
A major security feature in Windows 7 is a new and improved BitLocker that removes the management headaches previously associated with the data protection functionality. When combined with policies that control the use of portable media devices, BitLocker provides a level of control over data on the client side that wasn't previously possible, without being overly intrusive to users. Among the improvements:
- In Windows 7, fixed hard drive requirements for BitLocker implementation have been reduced and simplified. The computer's hard drive must be formatted with a 100 MB hidden system drive separate from its encrypted operating system drive, a drastic reduction from the 1.5 GB required by Vista.
- It's no longer necessary to pre-create the system drive because the BitLocker installation creates it automatically. The drive is hidden by default and not assigned a drive letter, so files cannot be inadvertently written to it; however, it can be used by administrators to store recovery tools, etc.
- While operating systems drives must still be formatted with NTFS to be encrypted using BitLocker, data drives can now be formatted as exFAT, FAT16, FAT32 or NTFS.
- While premium editions of Windows 7 are required to create and write to encrypted drives, any version of Windows 7 can be used to unlock them. When a BitLocker-encrypted device is connected, Windows 7 will automatically detect that the drive is encrypted and prompt for the information necessary to unlock it. Windows Vista and Windows XP systems can use a BitLocker to Go Reader to read encrypted files if they are stored on FAT-formatted devices. Users need to be warned that if an encrypted removable drive is formatted as NTFS, it can only be unlocked on a computer running Windows 7 or Window Server 2008 R2.
- BitLocker To Go extends encryption capabilities to portable data storage devices (IEEE 1667 compliant USB devices), including removable devices that contain FAT partitions. Even if the media is lost, stolen or misused only authorized users can access its data.
- BitLocker To Go can be utilized separately from traditional BitLocker encryption; the fixed drives on the system need not be encrypted.
- Users can easily encrypt their removable media by right-clicking on the drive and selecting "Turn on BitLocker." They will then be asked for either a password or a smartcard; upon providing the requested credentials they will be asked to print or save their recovery password. Policies can be set to allow the recovery password to be stored in Active Directory Domain Services and used if other unlock methods fail.
- Members of the Local Administrators group (or the Domain Admin group) can control how removable devices can be utilized within their environments along with the strength of protection required. Policies can be enforced which restrict the ability to write to portable devices, while still retaining the ability to read from unprotected drives.
- Windows 7 includes new Group Policy settings to improve upon an administrator's ability to centrally manage BitLocker.
- Policies can be implemented to set requirements for use of passwords, domain user credentials, or smartcards when users attempt to access a portable or fixed drive. Fixed drives can also be set to automatically unlock after the initial use of a password or smartcards to unlock them.
-- BETH QUINLA