Steve Riley on Security : Windows Vista

Directly connect to your corpnet with IPsec and IPv6

Steve Riley — Wed, 25 Jun 2008 23:55:00 GMT

Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual rumors, but hey, one can dream, huh? My spring calendar was full of events in Asia and Australia, then TechEd US seemed to suddenly appear out of nowhere! So I've been kinda swamped. I've missed writing here; it's good to get back into the swing.

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

Windows Vista Enterprise or Ultimate editions (those with Business edition and Software Assurance can upgrade to Enterprise)
That are domain-joined
Users run as non-admin
Group policy applies numerous settings
UAC is enabled
BitLocker is configured to protect confidential information stored offline
The Windows Firewall is enabled
NAP is used for checking health
Forefront Client Security for keeping malware off the box
Smart cards for strong authentication of users
IPsec is required for connection authentication and traffic encryption
IPv6 is required for worldwide Internet connectivity
A DNS suffix search list represents the data center name space
Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Plan now to eliminate "power users" from your domains

Steve Riley — Mon, 11 Feb 2008 21:03:17 GMT

I've seen some conversations lately about the Power Users group -- how powerful is it, really, and why did we remove the group from Windows Vista?

That group had rights install software and drivers. And if you can install software and drivers, then you can elevate yourself to Administrator or SYSTEM. Vista includes a signed installer that allows standard users to install packages signed by a trusted root. (The "Trusted Installer" is a service that has a SID, so you'll see it in the permissions list on various objects throughout the operating system.) The installer validates the signature chain, then elevates itself to perform the actual installation. Now, standard users can install and update approved software without having to grant membership in the too-powerful Power Users group.

We deprecated the Power Users group and removed it wherever we detected it on ACLs. We recommend that you do the same.

Changing the SSL cipher order in Internet Explorer 7 on Windows Vista

Steve Riley — Wed, 07 Nov 2007 08:37:47 GMT

Recently, the question of using AES for SSL has come up in the newsgroups and at some conferences. When IE makes an HTTPS connection to a web server, it offers a list of cipher supported cipher suites. The server then selects the first one from the list that it can match. The default order that IE follows is this:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

When you study the list, you'll see that IE presents the algorithms in decreasing order of strength, but places the shorter bit-lengths first. Why? If longer bit lengths are more secure, shouldn't they be listed first?

Remember, encryption is the thing that buys you time against Immutable Law #3. But performing encryption itself takes time. So when choosing an algorithm and a bit length, one important consideration is to ask yourself this question: "How long do I need for my secrets to remain secret?"

We configure IE to use shorter bit lengths -- but never shorter than 128 bits, except for the last two that use no encryption -- because it gives you better performance than the longer bit lengths. In almost all cases, a 128-bit key is more than sufficient to protect the information you're exchanging over HTTPS.

However, if you require something longer, and want to change the default, you can. Here's how.

Open your group policy editor by entering gpedit.msc at a command prompt.
Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
There's only one item here: SSL Cipher Suite Order. Open it.
Select Enabled.
Now here's where you need to tread carefully. You'll see that the list is the same as above, but rather than formatted nicely with carriage returns, they're simply separated with commas. The first item in the list is:
TLS_RSA_WITH_AES_128_CBC_SHA
And the second item is:
TLS_RSA_WITH_AES_256_CBC_SHA
Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128.
Feel free to change other orders, too, but keep your changes within algorithm types.
OK your way out, close the group policy editor, and reboot.

Most of you probably won't need to do this -- I haven't. But for those who have regulatory requirements for using 256-bit AES, follow these steps and you'll be compliant.

The bad guys will use BitLocker, too

Steve Riley — Fri, 13 Jul 2007 21:03:36 GMT

Got an email today from a customer asking about how BitLocker will affect the ability of law enforcement to conduct forensic analysis of a protected hard drive. Specifically, the person was asking about any back doors that law enforcement could use to bypass the encryption.

The answer is very simple, and I'm sure not what he wanted to hear: there are no back doors. Period.

Think about it for a moment: if there were a back door, would you trust the technology? Of course not. If Microsoft incorporated a mechanism to bypass the encryption, then we'd be weakening the technology for 99.9% of the population to favor the needs of 0.1%. And, surely, the bad guys would find out how to exploit the bypass -- meaning that BitLocker becomes completely useless for you.

Here's a similar example: some people have advocated that cell phones be disabled in certain public places (movie theaters, tunnels, sports stadiums, and so on) because terrorists might use them to remotely trigger bombs. What a bunch of nonsense this is. Communications tools are far more beneficial to the millions of good guys who use them every day (perhaps to save lives?) than to the few bad guys who also use them. Why destroy beneficial utility for everyone just because someone might misuse the technology?

Encryption is amoral. Good guys will use it, and bad guys will use it. We've got to accept that fact. It does no one any good to render beneficial technology useless just because there's the potential that someone might misuse it.

Windows Integrity Mechanism: more than you ever wanted to know

Steve Riley — Fri, 13 Jul 2007 20:49:09 GMT

A while back, the technology in Vista called mandatory integrity control got a new name: Windows integrity mechanism. Recently the folks responsible for developing the technology have posted a good amount of documentation on it. Read the Windows Vista Integrity Mechanism Technical Reference for all the details.

TechNet: Exploring the Windows Vista Firewall

Steve Riley — Wed, 30 May 2007 02:01:00 GMT

New article up...

Back in the days of the paleocomputing era, no one ever thought about installing firewalls on individual computers. Who needed to? Hardly anyone had heard of the Internet, TCP/IP was nowhere in sight, and LAN protocols didn’t route beyond your building or campus. Important data lived on the mainframe or file servers—the information people kept on their desktop computers was rarely mission critical and the computer’s own weight afforded a certain amount of decent physical security. If there was a connection to the Internet available, there were likely some protocol translators in the way and a packet-filtering router (I mean "firewall") at the edge, probably configured with too many rules and exceptions.

Modern computing environments wildly diverge from those ancient times. Everything is connected to the Internet (and talks TCP/IP now) and portable devices are now the standard. Your employer has likely given you a laptop, not because they care about you, but because they care about getting more out of you—they fully expect you to work anytime you’ve got five spare minutes and a Wi-Fi connection. Laptops might cost more than desktops, but that investment is surely repaid in productivity. You see, it’s the portability that makes them so alluring—to you and your adversaries.

...continued: http://www.microsoft.com/technet/technetmag/issues/2007/06/VistaFirewall/default.aspx

Curious about the ways Windows talks to the Internet? Here's your answer.

Steve Riley — Thu, 21 Dec 2006 02:32:00 GMT

I was browsing through the Microsoft download pages today -- yeah, even we employees occasionally find little nuggets interspersed among the usual updates and such. I noticed a pair of whitepapers that will answer a common question I hear from many of you in emails and at conferences. You'll want to keep these handy.

Using Windows: Controlling Communication with the Internet

Windows Vista and the Windows XP include a variety of technologies that communicate with the Internet to provide increased ease of use and functionality. Browser and e-mail technologies are obvious examples, but there are also technologies such as automatic updating that help users obtain the latest software and product information, including bug fixes and security patches. These technologies provide many benefits, but they also involve communication with Internet sites, which administrators might want to control.

These white papers for Windows Vista and Windows XP with Service Pack 2 provide information on the communication that flows between operating system features and sites on the Internet. The white papers also describe steps to take to limit, control, or prevent that communication in an organization with many users. The white papers are designed to assist you in planning strategies for deploying and maintaining these Windows operating systems in a way that helps to provide an appropriate level of security and privacy for your organization’s networked assets.

BitLocker command line interface

Steve Riley — Sun, 26 Nov 2006 07:39:00 GMT

Last week at TechEd Europe I showed the BitLocker command-line interface. At other TechEds I've mentioned it but didn't show it. The CLI provides full control over BitLocker, including enabling it on any NTFS volume on the system (the Control Panel UI displays only the volume containing the operating system).

To run it:

Open an elevated command prompt
Change to %WINDIR%\System32
Enter cscript manage-bde.wsf

For the curious, "bde" expands to "BitLocker drive encryption."

With no parameters, the output is:

Description:
    Configures BitLocker Drive Encryption on disk volumes.

Parameter List:
    -status     Provides information about BitLocker-capable volumes.
    -on         Encrypts the volume and turns BitLocker protection on.
    -off        Decrypts the volume and turns BitLocker protection off.
    -pause      Pauses encryption or decryption.
    -resume     Resumes encryption or decryption.
    -lock       Prevents access to BitLocker-encrypted data.
    -unlock     Allows access to BitLocker-encrypted data.
    -autounlock Manages automatic unlocking of data volumes.
    -protectors Manages protection methods for the encryption key.
    -tpm        Configures the computer's Trusted Platform Module (TPM).
    -ForceRecovery or -fr
                Forces a BitLocker-protected OS to recover on restarts.
    -ComputerName or -cn
                Runs on another computer. Examples: "ComputerX", "127.0.0.1"
    -? or /?    Displays brief help. Example: "-ParameterSet -?"
    -Help or -h Displays complete help. Example: "-ParameterSet -h"
Examples:
    manage-bde -status
    manage-bde -on C: -RecoveryPassword -RecoveryKey F:\
    manage-bde -unlock E: -RecoveryKey F:\84E151C1...7A62067A512.bek

Enjoy!

Must be a slow news day: reporter writes 100% crap

Steve Riley — Tue, 03 Oct 2006 21:12:00 GMT

Imagine my surprise to read that Microsoft is removing NAP from Windows Vista! Does this guy actually get paid money to write this drivel? The particular folks quoted in the article all have their own agendas, of course.

News flash: we aren't dropping NAP. It's in the product now, we're actually running it on part of our own corporate network. And soon you'll get to enjoy the benefits of NAP in your own environments, too.

Ah, the joys of speaking about pre-release software!

Steve Riley — Wed, 06 Sep 2006 12:26:00 GMT

Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand (Auckland) and Australia (Sydney). It was largely the same as the presention at TechEds in America and India, but updated to reflect changes made in the product between the time I wrote the presentation and now.

Pre-release software is like that: it changes. And when you give presentations on beta software, you rely on the details you have to give the most accurate information possible. But there is, of course, no guarantee that functionality as explained in the presentation will exactly match what's delivered when the final product is released. And indeed, in my post on mandatory integrity control, I mentioned some changes.

Code integrity and signatures

The latest version of the presentation includes more details on code integrity and code signing. Previously I had described code integrity as applying to all binaries in the operating system; in fact, code integrity applies to the following:

All code loaded into a protected process
Modules implementing cryptographic functions
Modules loaded into the software licensing service

Kernel mode creates special cases that vary depending on the edition of Windows. For 64-bit:

All kernel mode code loaded anywhere at any time must be signed -- applies to drivers and non-drivers

For 32-bit, non-driver kernel mode code doesn't require a signature. For drivers, the allow/warn/block behavior of prior versions of Windows is gone. Windows Vista raises a warning if you attempt to install a driver without a signature (only if you're an administrator; standard users can't install unsigned drivers). Drivers with signatures install without prompts. Signatures can come in three forms:

Manufacturers can obtain WHQL signatures from Microsoft as part of the Windows logo program; this indicates a certain level of quality
Manufacturers can sign drivers themselves; this indicates authenticity but nothing about quality
IT departments can self-sign drivers; this allows organizations to silently deploy approved drivers, even if they otherwise lack signatures

For more information, read the whitepapers for 32-bit plug-and-play drivers and 64-bit kernel mode code.

Protected processes and high definition content

The Protected Media Path (PMP), part of the new Windows Media Foundation, contains two protected processes. PMP provides a more robust playback environment for high definition rights-protected content. Code integrity checks that all protected processes have valid certificates and that they haven't been revoked.

Based on some details provided to me, I stated that in only 32-bit Windows Vista, next generation high definition protected content will not play at all; 64-bit is the platform for playing back such content. Then I added some conjecture: the media companies wanted this because the risk of unsigned kernel mode code present in memory could thwart content protection.

Turns out that my information and my conjecture weren't correct. Windows will never decide not to play content. PMP itself isn't monitored by code integrity, but it does consume the output of a report generated by the operating system about unsigned code in memory. When you load next generation high definition protected content into a playback application, Windows reports the status of kernel mode drivers loaded into memory: the names of the drivers and whether each of those drivers is signed.

Based on that report, the playback application -- not Windows -- decides what to do: it will either play the content or raise an error and refuse to play. It's also possible for the content itself to indicate what to do, based on instructions contained within the content's embedded license.

Unfortuantely, my initial explanation sparked the interest of a journalist. Originally he was going to write that Microsoft has dropped support for BluRay and HD-DVD movies. I never said that, of course, although I can see how it's easy to leap to that conclusion. Even after I met with the journalist, to ensure he understood the details (as I knew them at the time), his article still generated some controversy: I got Slashdotted!

Keeping you informed

I guess that's the risk you take in a job like mine. It's a risk I'm willing to take, because I still believe I have the coolest job in the world: helping you learn everything you can about how to design and operate environments using Microsoft technology as safely and securely as possible.

Fortunately, mechanisms like this blog allow us to ensure that you, our customers, get the most up-to-date information we can give you. Now that I understand how PMP functions with respect to code integrity, I can let all of you know here, as well as ensure that future deliveries of the system integrity presentation will be as accurate as possible.

As always, I extend my sincere gratitute to everyone who takes time to attend my presentations. It means more to me than you'll ever know. I look forward to continuing to see familiar faces at events around the world, and also meeting new folks too. :)

Security in Windows Vista 64-bit

Steve Riley — Sat, 12 Aug 2006 02:17:00 GMT

By now, many of you have heard us speak about or have read our writings on the improved security capabilities of Windows Vista. As I've said at a number of events now, the research I've done into these capabilities has convinced me that enterprises should seriously consider Vista upgrades. This OS is really gonna make the bad guys rethink their tactics.

My friend Jeff Jones has recently dug into the differences in 64-bit Windows Vista. In his first article he describes hardware no execute protection. His second article explores Patchguard, explains its value, and deflates some recent research into bypassing Patchguard.

If you haven't been reading Jeff's blog, I recommend adding it to your list of feeds.

Mandatory integrity control in Windows Vista

Steve Riley — Sat, 22 Jul 2006 07:20:00 GMT

One of my favorite new security features in Windows Vista is Mandatory Integrity Control (MIC). It’s a classical computer science concept from the 1970s that’s finally getting its first commercial implementation—and of this I’m quite proud.

While discretionary access control lists (DACLs) are useful, they have some limitations. They do little to safeguard system stability and they can’t stop malicious software from tricking users into executing it. MIC adds the notion of trustworthiness evaluation into the operating system. Subjects with low degrees of trustworthiness can’t change data of higher degrees; subjects with high degrees of trustworthiness can’t be forced to rely on data of lower degrees. MIC implements an information flow policy and provides the enforcement mechanism.

When a user logs on, Windows Vista assigns an integrity SID to the user’s access token. The SID includes an integrity label that determines the level of access the token—and therefore the user—can achieve. (The SID’s format is S-1-16-<label>, where <label> is a number that represents the integrity level.) Securable objects (files, folders, pipes, processes, threads, window stations, registry keys, services, printers, shares, interprocess objects, jobs, and directory objects) also receive an integrity SID, which is stored in the system access control list (SACL) of the object’s security descriptor. The label in the SID specifies the integrity level of the object.

During an access check, before checking the user’s access through the DACL, Windows Vista checks the integrity level of the user and compares it to the integrity level of the requested object. If the user’s level dominates (that is, is equal to or greater than) the object’s level, the user will be allowed to write to or delete the object, subject of course to the DACL. If the user’s level doesn’t dominate the object’s, then the user can’t write to or delete the object regardless of what the DACL says. Integrity control, therefore, trumps access lists.

Windows Vista defines four integrity levels: low, medium, high, and system. Standard users receive medium, elevated users receive high. Processes you start and objects you create receive your integrity level (medium or high) or low if the executable file’s level is low; system services receive system integrity. Objects that lack an integrity label are treated as medium by the operating system—this prevents low integrity code from modifying unlabeled objects.

For those keeping track… Yes, there’ve been some changes since I spoke about MIC at TechEd. First, the label numbers have changed from 100/200/300/400 to 4096/8192/12288/16384, which in hex are 1000/2000/3000/4000. So don’t use the numbers when referring to labels, because they might change again! Second, processes no longer receive the lower of your integrity or the file’s integrity—instead, process integrity behaves as I described above. Third, we no longer use MIC to enforce Windows resource protection (WRP). All operating system files are now unlabeled, meaning they default to medium integrity. The files are ACLed such that only the trusted installer has write access; everyone else, including administrators, has only read and execute access.

Consider a scenario. Say you receive an attachment in email. When you save it, it’s written with low integrity because it came from the Internet—an untrusted source. When you execute the attachment, its process runs at low integrity because the file object is labeled low; therefore, your data (labeled medium or high) is protected from malicious writes by the attachment. It will, however be able to read your data. MIC implements a form of the Biba model, which ensures integrity by controlling writes and deletions. Contrast this with the more well-known Bell-LaPadula model, which describes levels of confidentiality by controlling reads.

Internet Explorer Protected Mode (IEPM) is built around mandatory integrity control. The IEPM process and extensions run at low integrity and therefore have write access only to the Temporary Internet Files\Low folder, History, Cookies, Favorites, and the HKEY_CURRENT_USER\Software\LowRegistry key. MIC prevents IEPM from writing anywhere else in the file system or registry—so no more silent installs of keystroke loggers into your Startup folder. And because the desktop runs at medium integrity, IEPM can’t send messages to it—thwarting shatter-style attacks. Because these new restrictions might break some applications, a compatibility mode virtualizes access to medium integrity resources (like the Documents folder and the HKEY_CURRENT_USER hive) by redirecting writes to low integrity locations (Documents and Settings\%userprofile%\LocalSettings\TemporaryInternet Files\Virtualized and HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry).

While it’s completely invisible, mandatory integrity control is an important advance in maintaining the security and stability of Windows Vista. I hope you’ll come to appreciate it as much as I do.