Windows 7 security primer, part one

Windows 7 has enjoyed favorable adoption, yet many IT admins are now struggling with the platform’s new security features. I’ve received plenty of e-mails to that effect with readers asking about the security changes (or deltas) between Windows Vista and Windows 7, as well as for my configuration recommendations.

I typically avoid Microsoft-only columns, as I’m a full-time employee of the company. However, because security is my area of expertise, and given the overwhelming number of requests from readers, I’ve decided to do a three-part series on Windows 7 security. This week, I’ll take a look at some of the aforementioned security deltas, and I’ll share my recommendations.

[ Here are five more things you should know about Windows 7 security. ]

User Account Control UAC is one of the most notable updated features in Windows 7. It prompts less frequently for low-risk administrative actions by default, but it allows admins to modify the prompt sensitivity using a slider bar.

Recommendation: Your domain environment should already be at the highest and most secure level. If it isn’t, make it so. That way, users will be prompted to input their passwords to perform high-risk administrative actions. No matter what else, UAC should be enabled.

BitLocker In Windows 7, BitLocker Drive Encryption technology is extended from OS drives and fixed data drives to include removable storage devices such as portable hard drives and USB flash drives. This expansion is called BitLocker to Go.

In Windows Vista SP1, Microsoft added official support for encrypting fixed data drives, but it could only be done using command-line tools. Now you can encrypt operating system volumes, fixed data drives, and USB flash drives via the Windows Explorer GUI. Moreover, you can use smart cards to protect data volumes, and you can set up data recovery agents to automatically back up BitLocker keys.

If you’re using a Trusted Platform Module (TPM) chip, you can enforce a minimum PIN length; five characters should suffice for most environments.

In Windows 7, there is no need to create separate partitions before turning on BitLocker. The system partition is automatically created and does not have a drive letter, so it is not visible in Windows Explorer and data files will not be written to it inadvertently. The system partition is smaller in Windows 7 than in Windows Vista, requiring only 100MB of space.

BitLocker to Go Reader (bitlockertogo.exe) is a program that works on computers running Windows Vista or Windows XP, allowing you to open and view the content of removable drives that have been encrypted with BitLocker in Windows 7.

Recommendation: You should enable BitLocker (preferably with TPM and another factor) on portable computers if you do not use another data encryption product. Store the BitLocker PINs and recovery information in Active Directory and/or configure a domain-wide public key called a data recovery agent that will permit an administrator to unlock any drive encrypted with BitLocker. Require BitLocker to Go on all possible removable media drives.

Suite B Cryptography Support Suite B comprises a group of cryptographic algorithm standards that’s approved by the National Security Agency and National Institute of Standards and Technology for use in general-purpose encryption software. Microsoft added Support for Suite B cryptographic algorithms (AES, ECDSA, ECDH, SHA2) to Windows Vista (and later). Windows 7 allows Suite B ciphers to be used with Transport Layer Security (TLS), referred to as TLS v.1.2, and Encrypting File System (EFS).

Recommendation: Suite B ciphers should be used whenever possible; however, it’s very important to note that Suite B ciphers are not usually compatible with Windows OS’s prior to Windows Vista.

DirectAccess DirectAccess allows remote users to securely access enterprise resources (such as shares, Web sites, applications, and so on) without connecting to traditional types of VPNs. DirectAccess establishes bi-directional connectivity with a user’s enterprise network every time a user’s DirectAccess-enabled portable computer connects to the Internet, even before the user logs on. The advantage here is that users never have to think about connecting to the enterprise network, and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.

Once DirectAccess is enabled, when a user’s computer connects to the Internet, it’s as though he or she is on the organization’s local network. Group policies work, remote management tools work, and automatic push patching works.

Unfortunately, DirectAccess has fairly involved requirements, including Windows Server 2008 R2 (to act as the RAS server); Windows 7 (and later) Enterprise or Ultimate clients; PKI; IPv6; and IPSec.

Recommendation: Companies should look into using DirectAccess as their default VPN technology for Windows 7 and later clients.

Managed Service Accounts Service accounts are often highly privileged, but difficult to manage. Best-practice recommendations dictate changing service account passwords frequently, so as to avoid the risk of password attacks. However, Windows service accounts often require two or more coordinated, synchronized password changes in order for the service to continue running without interruption; prior to Windows 7 and Windows Server 2008 R2, service accounts were not easy to manage. If a service account is enabled as a Managed Service Account, Windows will take over the password management and simplify Kerberos SPN (Service Principal Names) management.

Recommendation: Like Direct Access, Managed Service Accounts have a lot of requirements, including a schema update and mandatory PowerShell 2 use. Still, if service accounts are a hassle in your environment — and you know they are — consider enabling this new feature when your infrastructure is prepared.

Virtual Service Accounts Virtual Service Accounts (VSAs) are related to Managed Service Accounts in that Windows takes over the password management. However, VSAs are for local service accounts and don’t require a schema update or nearly the amount of effort to configure and use.

When a VSA controls a service, the service accesses the network with the computer’s identity (in a domain environment), which is much like what the built-in LocalSystem and Network Service accounts do, except that VSAs allow each service to have its own separate security domain (and subsequent isolation).

Creating a Virtual Service Account is pretty easy. Open the Services console (services.msc) and modify the service’s logon account name to be the same as the service’s short name, such as ex. NT SERVICEServiceName$. Then restart the service. That’s it.

Recommendation: When the infrastructure can support it, consider using Managed and Virtual Service Accounts functionality to manage service account password security.

That wraps up part one of my three-part series on Windows 7 security. Part two will cover some of the more exciting features, such as XP Mode and AppLocker.

This story, “Windows 7 security primer, part one,” was originally published at InfoWorld.com. Follow the latest developments in security at InfoWorld.com.