Windows 7

Groovy Security in Windows 7

Steve Riley

At a Glance:

• Easier corpnet access with DirectAccess
• Encrypt even removable drives with the new BitLocker
• Manage access to applications with AppLocker
• Protect against DNS poisoning and spoofing with DNSSEC

Contents

DirectAccess
BitLocker and BitLocker To Go
AppLocker
DNSSEC
More Improvements
This Is the Windows You Want

As I put the finishing touches on this article, the day many of us have been waiting for finally arrived: Windows 7 was released to manufacturing. I spent a good deal of time using the beta and release candidate as my production operating system and have enjoyed the changes and improvements Windows 7 offers. Now I would like to take you on a tour of some of my favorite security features.

DirectAccess

If you're like every other geek I've met, work doesn't end when you walk out the door of your office. Why do you think most employers provide laptops rather than desktops? Because they know you'll work for free! That's how they recoup the investment in more expensive hardware. Set up some VPN servers, publish instructions for how to access the corporate network, and you'll get a whole lot more productivity out of your staff.

Or so the thinking goes. VPNs almost always require extra steps to get onto the corpnet, sometimes very convoluted steps. You have to carry around easy-to-lose hardware tokens. Pokey logon scripts drag on forever. Internet traffic gets backhauled through your corpnet, slowing responsiveness. If it's been a while since your last connection, your computer might receive several megabytes of software updates. So if you have only one minor annoying thing to do—say complete an expense report—you'll probably put it off. If only there were a way to eliminate the separate VPN connection steps, so you could use your computer at home or in the airport lounge exactly as you do at work, well, that would be cool.

Along with Windows Server 2008 R2, DirectAccess in Windows 7 gives you exactly that experience. From the perspective of a user, the difference between the corpnet and the Internet evaporates. For example, suppose when you're in the office you navigate to https://expenses to complete an expense report. With DirectAccess enabled on your network, you'd follow the exact same procedure anywhere you can find an Internet connection: simply enter https://expenses in your browser. No extra logon steps, no re-training, no help-desk calls to troubleshoot balky VPN client software. DirectAccess allows you to connect computers to your corpnet and the Internet at the same time. This removes the friction between you and your applications, making it even easier for you to get to your data.

There are two communications protocols that make this possible: IPsec and IPv6. An IPsec Encapsulating Security Payload (ESP) transport mode security association (not a tunnel, despite the continued misuse of the phrase "IPsec tunnel") authenticates and encrypts the communications between the client and the destination server. Bidirectional authentication mitigates man-in-the-middle attacks: using X.509 certificates issued by authorities both sides trust, the client authenticates to the server and the server authenticates to the client. Advanced Encryption Standard (AES) encryption provides confidentiality so that anything intercepted during communications is meaningless to the eavesdropper.

Traditional VPNs use IPsec, too; it's the addition of IPv6 that makes DirectAccess novel and exciting. Eliminating the VPN requires better end-to-end connectivity than what IPv4, with its plethora of network address translators and overlapping address ranges, is capable of. IPv6 configures a globally unique, routable address on every client and segregates corpnet traffic from regular Internet traffic. IPv6 is required for DirectAccess, so your corpnet must support IPv6. This isn't as daunting a task as you might think: many of your servers probably already have or can be configured to run IPv6, and any networking gear made in the last half-decade supports IPv6. Protocol transition technologies can help, such as Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) and Network Address Translation/Protocol Translation (NAT-PT) at the edge of your corpnet.

A client configured with DirectAccess is always connected to your corpnet, but probably not over native IPv6; the client is likely behind an IPv4 NAT and the Internet itself is still mostly IPv4. Windows 7 supports 6to4 and Teredo—transition technologies that encapsulate IPv6 traffic inside IPv4. And on the rare occasion when neither of these protocols works, DirectAccess falls back to IP-HTTPS, a new protocol that encapsulates IPv6 inside HTTPS over IPv4. (Yes, the scheme to turn HTTP into the ultimate universal bypass protocol has reached its nadir!)

Applications don't need any modification or special treatment to work over DirectAccess. Group Policy assigns to clients a name resolution policy table (NRPT) containing two bits of information: the corpnet's internal DNS suffix and the addresses of IPv6 DNS servers resolving the namespace (see Figure 1). Suppose your internal DNS suffix is inside.example.com and your IPv6 DNS server's address is FEDC:BA98:7654:3210::1. When you browse to https://expenses, your computer's resolver appends the DNS suffix and attempts to resolve expenses.inside.example.com. Because this matches the DNS suffix entry in the NRPT, the resolver sends the request to FEDC:BA98:7654:3210::1. DNS replies with the IPv6 address of the expenses server; DirectAccess follows the necessary steps (native, transition, IP-HTTPS) to connect you to the server. If your computer is domain-joined and if the server requires authentication, the domain credentials you logged on with will authenticate you to the server without prompting. Suppose in another browser window you're navigating to a public Internet Web site; because the DNS suffix isn't in the computer's NRPT, the resolver performs a normal IPv4 lookup (using the DNS servers configured on the network interface) and connects to the site completely independently of DirectAccess.

Figure 1 Setting name resolution policy for DirectAccess. (Click the image for a larger view)

Take a moment and think about the implications of always-on corpnet access. Sure, as a user, it's rather addictive, and makes it (almost) painless to complete that expense report. However, I know my audience: administrators and security dudes. What could it mean to have all your clients connected to the corpnet all the time, no matter where they are? I'll mention a few:

• Configuration maintenance with Group Policy
• Continuous updating with Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM)
• Health checking and remediation with NAP
• Protection with the Windows firewall and Forefront Client Security or other centrally administered anti-malware

Sounds a lot like what you do on your corpnet, right? Exactly. DirectAccess extends your corpnet to the entire Internet while enabling you to keep your computers well-managed and secure. It's arguably the most exciting bit of network technology I've seen in a long time and definitely makes upgrades compelling.

BitLocker and BitLocker To Go

Alright … I'm going to do what authors are never supposed to do and ask you to interrupt me briefly. Take a look at the chronology of data breaches at the Privacy Rights Clearinghouse (privacyrights.org/ar/ChronDataBreaches.htm). It started tracking breaches in January 2005. As of this writing, a breathtaking 263 million records have leaked. The Ponemon Institute LLC and PGP Corp. conducted a study, "The Fourth Annual U.S. Cost of Data Breach Study: Benchmark Study of Companies", that reports an average recovery cost of $202 per record. Let's do a little math, shall we?

263,000,000 records × $202/record

$53,000,000,000

Organizations have lost an astonishing $53 billion in five and a half years! It's fair to surmise that misplaced and stolen laptops are among the costliest exposures most companies face. The cost to replace equipment is negligible—most of the exposure is direct or indirect costs related to data recovery/reconstruction, fines, reputation damage and lost business. In many instances a simple mitigation would have eliminated the exposure: encrypting portable data.

Microsoft added BitLocker to Windows Vista to protect the operating system from offline attacks by encrypting the drive volume from which Windows runs. When a Trusted Platform Module (TPM) hardware component is present, BitLocker also provides integrity for the boot process by validating each step along the way and halting if any part fails a hash check. Customers, of course, always have their own ideas, and during the beta period they quickly realized BitLocker could also protect their data. Microsoft added a few more Group Policy Objects (GPOs) and a user interface for configuring BitLocker, but it remained challenging to deploy (especially on computers already built) and was supported only on the system volume.

Windows Vista SP1 extended BitLocker's support to all hard drive volumes, allowed encryption keys to be protected by all three methods in combination (TPM, USB startup key and user PIN), and included a tool to prepare existing installations with the necessary additional drive volume.

Windows 7 simplifies BitLocker setup by assuming it's a feature you'll want to use. The installation process automatically creates the necessary boot partition. Enabling BitLocker is easy: right-click the drive volume and select the BitLocker option from the menu (see Figure 2). Even if your computer lacks the second partition, the preparation process will repartition your drive. Key management and data recovery is easier now, with support for an IT-administered Data Recovery Agent (DRA). The DRA is an additional key protector that provides administrator access to all encrypted volumes. Using the DRA is optional but I strongly urge you to create one. Put it on a smart card, keep the card locked in a safe in the computer room, and be very judicious with whom you share the lock combination.

Figure 2 Enabling BitLocker on a removable drive. (Click the image for a larger view)

Previously, the BitLocker Control Panel applet, the manage-bde.wsf command-line script and the Windows Management Instrumentation (WMI) provider offered non-matching sets of configuration options. In Windows 7, all of BitLocker's options are available in all three methods. For non-OS volumes, you can control automatic unlocking and require smart-card authentication (see Figure 3).

Figure 3 Using a password to unlock a BitLocker-protected drive. (Click the image for a larger view)

Data leakage continues to be a major headache for many organizations. That handy little devil, the USB drive, is a major culprit (but certainly not the only one; data can export itself from your organization in myriad ways). Restricting the use of USB drives or completely disabling USB ports is a non-starter for most companies—the convenience is sometimes a necessity.

BitLocker To Go is Windows 7's answer to this problem: right-click a drive, select BitLocker, create a password, and BitLocker To Go encrypts the drive regardless of its format, even the FAT format. This primarily addresses the risk of people losing their drives; lost drives always seem to contain critical confidential information and are purloined by thieves with nothing better to do than post your secrets to WikiLeaks.

But BitLocker To Go is more than just a USB protector. It protects any type of removable drive and it works independently of the OS's BitLocker, so "regular" BitLocker isn't required. Administrators can configure a policy to force all removable drives to be read-only unless they're first encrypted with BitLocker To Go, after which the drives become writable. Another policy can require authentication (length- and complexity-selectable password, smart card or domain) to access a protected device. And DRAs behave on removable devices just like on hard-drive volumes.

Users can read from, but not write to, protected devices on Windows Vista and Windows XP. BitLocker To Go overlays a "discovery volume" on the physical drive, which contains the BitLocker To Go Reader and installation instructions. The reader is also available for download. Only password-protected volumes (not smart card or domain) are usable with the reader, as shown in Figure 4.

Figure 4 The BitLocker To Go Reader allows read-only access in prior versions of Windows. (Click the image for a larger view)

AppLocker

Have you ever worked with Software Restriction Policies (SRP)? Or even heard of SRP? Available since Windows 2000, SRP allows administrators to control whether a computer operates in default-allow or default-deny state.

Default-deny is preferred, of course: you define a collection of software allowed to run, anything not in the list is denied. SRP is a pretty decent way to stop the spread of malware. It's also a pretty decent way to create a whole lot of work for yourself: path and hash rules must include every .EXE and .DLL comprising an application, and hash rules must be replaced whenever an application is updated. Discovering and tracking every application an organization uses is a daunting challenge, not to mention the testing required to ensure that the usually massive set of SRP rules didn't cause any inadvertent malfunction. SRP never received much attention because it was unfriendly to configure and too inflexible to be practical.

Still, application listing remains an important element of any security design. AppLocker improves on SRP by adding more flexibility to the rules you can create. Along with the usual allow and deny rules, you can create exception rules. This makes a default-deny stance much easier to define and manage. The common example is this: "allow everything in %WINDIR% to run except the built-in games." I think this rather silly, like preventing people from changing their desktop background to purple—who cares? With a bit of planning, you can compose a decent list of known good applications using a manageable set of allow-with-exception rules.

Another rule type specifies permitted publishers, as shown in Figure 5. When a user runs an application, AppLocker compares the digital signature of the application's publisher to your defined allow list and checks other conditions you specify. This requires far fewer rules than SRP's hash-checking: rather than a lengthy collection of hash rules for every executable in the application, AppLocker needs only the single publisher rule. Publisher rules also eliminate the need to create new rules when an allowed application is updated. For instance, this rule: "allow any version of Acrobat Reader equal to or higher than 9.0 and only if it's signed by Adobe." Next week, when Adobe updates the application, you can push it out to clients without having to update the rule. Along with version numbers, you can create rules specifying entire applications or certain files or collections of files. In some instances AppLocker can even create rules automatically (see Figure 6).

Figure 5 Creating an AppLocker publishing rule. (Click the image for a larger view)

Figure 6 AppLocker can automatically generate certain types of rules. (Click the image for a larger view)

SRP's rules applied only to machines. AppLocker's rules can apply to users also. This feature helps you satisfy increasingly burdensome compliance requirements, such as this rule: "allow only those in the human resources department to execute human resources applications" (though, to be more precise, the rule includes Active Directory security groups containing user accounts of employees in HR). This rule blocks anyone not in HR, including administrators—but remember, malicious administrators can still change the rule. Recall my old axiom: if you don't trust your administrators, replace them.

Probably the biggest improvement AppLocker offers is that it's actually something you can trust. Frankly, SRP wasn't very robust. You'd think the operating system would be the policy enforcer, but you'd be wrong. During application launch the application's parent process, not the OS, checks the SRP. If the user—whether admin or not—had control of the parent process, the user could circumvent SRP; see Mark Russinovich's blog entry "Circumventing Group Policy as a Limited User" explaining how. Here's a blindingly obvious notion: to be an actual security feature, the feature has to be secure. AppLocker consists of a service and a kernel-mode driver; its rules are evaluated in the driver, so now the OS really is the enforcer. If for some odd reason you wanted to continue using SRP rules rather than AppLocker rules, at least they're stronger: in Windows 7 the SRP APIs are redesigned to bypass parent processes and hand rule enforcement and binary file verification to the AppLocker service.

The ability to test policies is critical. AppLocker's audit function (see Figure 7) shows how applications would behave if your rules were enabled. It displays a list of all affected files from which you can spot any problems that might occur before deployment. Rules can make distinctions between .EXEs, .DLLs, .MSIs and scripts. AppLocker keeps statistics of how often a rule is triggered, which is useful to know over time, especially as people's responsibilities change and they need new or different applications.

Figure 7 AppLocker’s audit mode lets you test your rules before deploying them. (Click the image for a larger view)

DNSSEC

Curiously, IPsec is spelled with a small "sec," while DNSSEC is entirely capitalized. No one ever said standards bodies were the epitome of consistency. But I digress …

At one time I was a DNSSEC doubter. The claim is that attaching cryptographic authentication to DNS replies renders DNS poisoning impossible, thus thwarting phishing attacks. DNSSEC attempts to answer the question "Can I trust the answer I receive in response to my name resolution query?" I believed this was the wrong question. The right question was "Can I trust I'm going to the real server?" SSL already took care of this quite well, thank you: only the actual bank could get an SSL certificate for its public Web site, right? An attacker could redirect your request to his site but he can't get the SSL certificate the real bank uses to authenticate its Web server to your browser. IPsec is similar: its reliance on digital certificates for authentication ensures no one can spoof your destination.

After carefully evaluating the gentle prodding and cajoling of others, I've come to believe DNSSEC is an important addition to our defensive arsenal. True, SSL and IPsec confirm you're connected to a legitimate site—although this is of questionable value because most users have "trained" themselves to ignore warnings. They don't, however, prevent you from being denied access to a legitimate site. DNS poisoning can be a very effective denial of service attack (DoS), which can't be mitigated with SSL or IPsec. DNSSEC removes the conditions allowing such attacks: replies from DNS servers include digital signatures, which resolvers can validate. Given I'm no fan of security "features" that enable attacks (account lockout is another DoS attack vector), I've changed my mind and now favor the rapid adoption of DNSSEC throughout the Internet, starting with the root servers that attackers frequently attempt to hijack.

DNSSEC provides:

• Origin authenticity: the reply is from the server it claims to come from
• Data integrity: the reply hasn't been maliciously modified in transit
• Authenticated denial of existence: an unspoofable "destination does not exist" reply

When a DNSSEC-capable server receives a query for a record in a signed zone, the server returns its digital signatures along with the reply. The resolver obtains the server's public key and validates the reply. The resolver needs to be configured with a "trust anchor" for the signed zone or its parent; DNSSEC on the Internet's root servers allow all DNSSEC-capable resolvers to have a trust anchor "rooted at the top."

The DNSSEC client in Windows 7 is a non-validating security-aware stub resolver. It acknowledges DNSSEC queries and processes DNSSEC resource records, but relies on its local DNS server to validate replies. The resolver returns the reply to the application only if validation succeeded. Communications between the client and its local DNS server are protected by SSL: the server presents its own certificate to the client for validation. DNSSEC settings are configured in the NRPT, as shown in Figure 8, and should be populated through Group Policy.

Figure 8 Confi guring name resolution policy for DNSSEC. (Click the image for a larger view)

One other important point: Historically, public certificate authorities have abdicated their responsibility to verify applications for X.509 server certificates. I've read of instances where attackers posed as legitimate representatives of real companies and successfully obtained fraudulent but trusted certificates. So in some respects SSL could be considered "broken" in that public certificates lack some trust value. The DNSSEC standards require much more stringent identification and verification before an organization can receive DNS signing certificates, which will help restore trust to online transactions.

More Improvements

While the security capabilities I've covered thus far are my favorite, I should mention a few more enhancements that improve the overall "securability" of Windows.

Multiple Active Firewall Profiles I've written in the past about third-party firewalls, with all their "scare-ifying" warnings, posing as nothing more than security theater (see "Exploring the Windows Firewall." I still believe this. The Windows Firewall is perfectly capable of protecting your computer. It had only one limitation: while three profiles are defined, only one is active at any time. In the office, your domain-joined computer automatically uses the domain profile, which allows inbound management communications. In your hotel room, your computer uses the public profile, which blocks all unsolicited inbound communications. The computer remains in this profile when you VPN into your corpnet, which makes your computer invisible to management tools. Windows 7 removes this limitation: you can separately define the public, private or domain profile on each physical or virtual network interface.

Windows Biometric Framework Fingerprint readers are everywhere—even the cheapest laptops sport the shiny swipe spot. Although the lack of built-in support in prior versions of Windows left the devices unused, PC makers delivered systems with the drivers installed anyway. The poor quality of much of this code caused a fair number of blue-screen crashes, many of which dutifully reported themselves to Microsoft.

Armed with this knowledge, Microsoft added native biometric support to the OS. Now the drivers must conform to a higher-quality level and users have more options for authenticating to their computers. I'm still convinced it's important to maintain the distinction between identity (a public declaration) and authentication (validated possession of a secret). A fingerprint is inarguably public. But there are some scenarios where fingerprint logon is superior: imagine a warehouse dock teeming with big burly guys huffing around huge crates and containers. Every so often they need to update inventory information on a computer in a rolling cart. Do you really think someone using gross motor skills most of the day can efficiently switch to the fine motor skills necessary to insert a wafer-thin smart card into its sliver of a slot while positioning it in the one correct of four possible orientations? No way. With fingerprint authentication, he doesn't have to switch muscle modes: a quick swipe on the reader logs him in. (Yes, this is a real customer scenario.)

The Windows Biometric Framework (WBF) is an extensible foundation for supporting biometric authentication. In the initial release of Windows 7, only fingerprints are supported. WBF defines several components meant to increase the reliability of biometric hardware and its associated drivers and enrollment software. When a user initially enrolls his or her fingerprints, the biometric service encrypts the representational data stream along with the user's credentials and stores this blob in a data structure called the vault. The encrypted password is assigned a GUID, which acts as a handle. Crucially, the service never reveals the user's password directly to an application but instead exposes only the handle. Depending on the capabilities of the reader, fingerprint authentication is available for local logon, domain logon and UAC authentication. Several GPOs exist for administrative control of WBF.

This Is the Windows You Want

When I re-imaged my computer with the first beta build last year, I never looked back. Windows 7 feels snappier in every regard and the overall fit and finish is impressive. With its multifaceted approach to securing access, people and data, it's a worthy addition to your infrastructure. Your road warriors definitely will thank you and—who knows—maybe you'll finally get that phone call we've so far only dreamed of: "Hey, I just wanted to tell you that everything's working. Groovy!"

Steve Riley is an evangelist and strategist for cloud computing at one of the world's foremost providers. He specializes in enterprise requirements for security, availability, reliability, and integration. You can reach him at stvrly@gmail.com.