Steve Riley on Security : encryption

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.

Do you need RMS/IRM in Office for Macintosh?

Steve Riley — Thu, 24 Apr 2008 01:34:16 GMT

Please let me know if this is a feature you'd be interested in. We're looking to build the business case to develop it, and the best way to do that is for you, our customers, to let us know.

Also, if any of you want to deploy RMS now but can't because there's currently no Mac support, I especially need to know. Thanks!

Microsoft IPsec diagnostic tool

Steve Riley — Fri, 01 Feb 2008 14:39:04 GMT

IPsec is a wonderful technology for identifying computers and securing the exchange of data between them. I've written and spoken extensively about in the past. It is, however, a bit of a challenge to configure, especially if you're newly learning about it. Microsoft recently released a diagnostic tool to help you create and test your policies. It checks for common network problems on host machines and suggests repair commands. It collects IPsec policy information on systems and parses IPsec logs to deduce why a failure might have happened. Beyond IPsec, it offers trace collection for VPN, NAP client, Windows Firewall, Group policy updates, Wireless, and System events. The tool's diagnostic report derives its conclusions from the system logs collected by the tool during its analysis phase, which are sufficient to diagnose any network related issue. For further assistance, you can share the logs with network administrators or Microsoft support.

Get the tool here: http://www.microsoft.com/downloads/details.aspx?FamilyID=1d4c292c-7998-42e4-8786-789c7b457881&displaylang=en

It works on these versions of Windows:

Windows Server 2003 Service Pack 1
Windows Server 2003 Service Pack 2
Windows Server 2003 Service Pack 2 x64 Edition
Windows Server 2008
Windows Vista Business
Windows Vista Business 64-bit edition
Windows Vista Enterprise
Windows Vista Enterprise 64-bit edition
Windows Vista Ultimate
Windows XP 64-bit; Windows XP Home Edition
Windows XP Professional Edition
Windows XP Service Pack 1
Windows XP Service Pack 2

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.

Myth vs. reality: Wireless SSIDs

Steve Riley — Tue, 16 Oct 2007 10:08:58 GMT

Do you ever wonder sometimes how it is that some ideas just won't die? Like the thought that not broadcasting your wireless network's SSID will somehow make you more secure? This is a myth that needs to be forcibly dragged out behind the woodshed, strangled until it wheezes its last labored breath, then shot several times for good measure.

Folks, there are fundamental differences between names, which are public claims of identities, and authenticators, which are secrets used to prove identities, and I've written extensively about this before. An SSID is a network name, not -- I repeat, not -- a password. A wireless network has an SSID to distinguish it from other wireless networks in the vicinity. The SSID was never designed to be hidden, and therefore won't provide your network with any kind of protection if you try to hide it. It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment (which defines WPA2, discussed later) even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID. And, even if you think your SSID is hidden, it really isn't. Let me explain.

All 802.11 wireless networks, regardless of the kind of operating system or encryption you might use, also emit unencrypted frames at times. One kind of unencrypted frame is an association frame. This is what a client computer, or "supplicant" in the 802.11 protocol vernacular, emits when it wants to join a wireless network. Contained within the frame, in clear text of course (since the frame is unencrypted), is the SSID of the network the supplicant wants to join.

Both Windows XP and Vista work best when your access points broadcast their SSIDs. XP really doesn't behave well at all with nonbroadcasting SSIDs. Vista has some added smarts to improve this a bit. Normally, Vista continually sends probe requests for nonbroadcasting networks. These probes are similar to unencrypted 802.11 association frames, and will generate clear-text responses from the access points if a nonbroadcasting network is present. You can reduce, but not entirely eliminate, these probes by configuring the wireless client to probe only for automatically-connected nonbroadcasting networks.

Both these behaviors make it very easy for an attacker to discover your SSID. The bad guy, perhaps a contractor or a guest in your facility, could run one of many wireless sniffer programs and simply capture the hundreds of association frames or probes that litter your air. No amount of "hiding" configured in your access points can prevent this kind of traffic interception.

So there you have it, simple SSID discovery. The old axiom remains true: security by obscurity is no security at all. Hiding an SSID will not hide a wireless network, so ignore any such advice -- and it's amazing how often I continue to see this. By the way, also ignore any advice that says to use MAC address filtering. It's amazingly trivial to spoof the MAC address of an allowed supplicant -- simply sniff the traffic, look at the MAC addresses, and use the neat little SMAC utility to change your MAC to one that's permitted.

Nonbroadcasting networks are not secure networks. The right way to secure a wireless network is to use protocols that are designed specifically to address wireless network threats. If you're still using WEP, either static or dynamic, I encourage you to move to WPA2 as soon as possible. For those of you at home running XP and have kept it updated, or if you're running Vista, then, you simply need to enable WPA2. We've got some additional guidance for home/small offices and for enterprise networks with certificate services or without. If you have hardware that's more than two years old and you can't upgrade it, check to see whether it supports WPA (an interim specification released before WPA2 was ratified). Both WPA and WPA2 are built on sound cryptographic principles, they're proven in the field, and they'll keep the bad guys out -- even when you're broadcasting your SSID to the world.

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.

Protect your data: everything else is just plumbing

Steve Riley — Mon, 02 Jul 2007 23:46:32 GMT

Take a few moments and indulge in a thought exercise with me. Consider your company’s complete collection of information processing assets—all the computers, the networks they’re connected to, the applications you use, and the data and information you manipulate. Which of those is the most valuable? Which—if it suddenly and tragically disappeared tomorrow—would jeopardize your company’s ability to remain in business?

That’s right, it’s your data. Any of the other elements could easily be replaced. But if your data vanishes, well then, you might as well close up shop and take residence on some forsaken island in the middle of the ocean. It’s your data that gives you your competitive edge, your data that constitutes a large part of your business, and your data that is most attractive to attackers.

Why, then, is there still so much emphasis on protecting all the plumbing that moves the data around, but little interest in protecting the data itself? My guess: old habits die hard. For most of the history of information security, emphasis on security has roughly followed this model:

Historical approaches to security have placed most emphasis on the network, with decreasing consideration of individual computers and the applications they run, and the least amount of consideration for the security of the data. (I’ve purposefully placed the physical layer outside the triangle, partly as a joke and partly for real—when I visit data centers I routinely discover physical security problems!) Once upon a time, this was the correct approach: computers and applications weren’t designed with much regard for security, and the only way to protect the data was to protect the network. And indeed, because it was generally the network that the bad guys were after, this approach worked.

The old model is no longer appropriate today. The bad guys really don’t care about your network anymore: they’re going after your data. Attackers were once motivated by pride: Mafiaboy was notorious for bragging about bringing down large parts of the Internet in February 2000 (and his bragging became his undoing). But these days, attackers are motivated by profit: they’re out to make money. The economics of the game have changed, and along with that so have the bad guys’ skills and the capabilities of their tools. Let me repeat: they want your data. They’ll steal it and sell it to your competitors, they’ll damage it and put you out of business. The network and your computers exist only as a means to get to your data. So we, as defenders of information assets, must change our tactics to react to—and possibly get in front of—the tactics of the bad guys. We’ve got to invert the traditional thinking and now emphasize security by following this new model:

Because protecting your data is now paramount, data protection deserves the bulk of your attention. Application security—developing applications with a mind toward security and how they might be purposefully abused by an attacker—is similarly critical. Good host security will remain important in this world as well, especially the security of mobile computers of all kinds. Because people use computers to run applications that process data, it’s these layers that are crucial. If you apply this model, the network can return to doing its only true job: moving bits around as fast as possible.

Traveling to the new world

So how do you get from there to here? One word: cool technology (OK, two words).

Full drive encryption

For some time, I’ve been advocating that using host-based firewalls isn’t an option: it’s required. Ordinarily, you have no control over the traffic that appears at your Ethernet port. A host firewall gives you control. I now have a second requirement: full drive encryption, especially on portable computers. According to the 2006 Australian Computer Crime and Security Survey, for four years in a row, laptop theft is the most expensive attack weathered by the organizations who responded. The exposure (and expense) isn’t the hardware—it’s the data stored on the computers. This tells me that good-quality full drive encryption is probably one of the best investments you can make to help save your company money! So go ahead and upgrade those laptops to Windows Vista (Enterprise or Ultimate editions) right now, to take advantage of BitLocker full volume encryption, because the cost of the upgrade is most certainly less than the cost of losing your data (and your reputation).

Learn more about BitLocker: http://technet2.microsoft.com/WindowsVista/en/library/ba1a3800-ce29-4f09-89ef-65bce923cdb51033.mspx

Document protection

When Alice creates a file and wants to give Bob read/write access, give Phil read access, and deny everyone else, the traditional approach involves a lot of work on the part of someone else. Alice has to beg, cajole, and bribe the network admin to create a file share, create two security groups, add Bob to one and Phil to the other, and create access control entries on the share’s access control list. That’s a lot of work for someone who really doesn’t care about Alice’s problems. And it’s incomplete: sure, Eve can’t touch the file on the share, but she can certainly convince Phil to give her a copy—read access also permits copying. If Phil were particularly malicious, he could modify his copy of the document first. You see, network-based access control works only so long as the protected object remains within the network. As soon as someone opens the file, the local copy in the computer’s memory obeys no restrictions.

Windows Rights Management Services (RMS) and Microsoft Office Information Rights Management (IRM) give you an alternate form of access control that persists on the documents themselves regardless of where they live. When Alice assigns read/write access to Bob and read-only access to Phil, she doesn’t need to involve the network admin at all. The access she assigns is stored right in the document and enforced by IRM. When Bob opens the document, Word first checks Bob’s permissions and then disables functionality so that Bob can’t do anything more than what he’s allowed. In Bob’s case, Word will refuse to do anything other than display the content in the window.

In addition to enforcing policy through IRM, RMS protects documents by encrypting them. RMS-protected documents remain encrypted in storage and in transit. They’re decrypted only after an authorized user has been authenticated and his or her permissions have been enforced. If someone outside the RMS’s domain attempts to open a file, it’ll just appear as nonsense. Unless your computer is enrolled in RMS and you’re on the list of authorized users, this document is useless to you. It’s also useless to the friends you’ve given copies to on those ubiquitous USB drives littering the basement of your desk.

Learn more about Rights Management Services: http://www.microsoft.com/rms

Data security

One definition of news is “something that happens rarely.” Data breaches must no longer be news, then, because they seem to happen with increasing regularity. The best way to avoid a breach is not to store data you don’t need—after you process that credit card number, delete it, don’t retain it. Other sensitive data you do need to retain in some database as part of your business. The best way to keep this data secure is to encrypt it in the database. Microsoft SQL Server 2005 includes some great features to help you here—field-level encryption of data in storage, encryption of data in transit, and enterprise-level key management. An important project that you should soon consider is to evaluate all instances where your company is storing private or confidential information (especially about your customers) and add data encryption where appropriate.

Learn more about SQL Server encryption: http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/SQLEncryption.doc

Of course, there’s more to data security than just the physical storage. Equally important are policies and processes for classifying data. There’s an entire body of knowledge—too much to absorb, really—on this topic. Rather than send you off on some endless forage through your favorite search engine, I’ll share with you a classification scheme I discovered recently. It’s simple and elegant—which means it’s something you can actually use.

First, think about confidentiality classifications. These are important because they help guide your response in case of a breach. Four classifications should be sufficient: public, internal, confidential, and private.

Next, consider retention classifications. If you should ever be hauled into court for some reason, the discovery process will uncover a whole lot of your data. You could face major penalties if new information is discovered after a trial starts. Therefore, it’s necessary to follow a policy that routinely purges e-mails and file shares after a period of time. These three retention classifications are good enough for most cases: regulated data for seven years, historical business data for three years, and temporary data (like e-mail) for one year.

Finally, consider recovery classifications. How quickly, in the event of a disaster, will you need to recover certain kinds of data? Are employees allowed to store mission-critical information on home computers or portable devices? Here’s a sample recovery classification: for mission-critical data, immediate recovery; for urgent data, recovery within 72 hours; for non-urgent data, recovery within 30 days.

Security for the modern age

Attackers constantly improve their tactics as their motives become more sinister. By adjusting your tactics as well, you can be certain that you’re doing your part to keep your information secure.

When you say goodbye to an employee

Steve Riley — Thu, 31 May 2007 21:29:45 GMT

...what do you do with his or her account? Recently this question came up -- someone was asking for guidance on how to handle this very situation. And, as often happens, the question was more about process and policy than anything to do with the technical issues of account management.

Those of you who've followed my writing and speaking will agree when I admit that I've become somewhat of a policy wonk over the past few years. Awhile back I spoke at an executive event in Taipei. I asked this question: "Who here can claim that their network is completely secure?"

Much to my surprise, a gentleman in the front row said "I can."

I honestly wasn't expecting that answer, so I decided to probe a bit. "Really? Wow. That's cool. How can you know that?" I asked.

His response: "Because I've installed every security product I can find."

...uh...hmm...it's unusual for me to be at a loss for words! But sensing a teaching moment, I talked for a while with the audience about risk assessment, about business drivers as the source of policy and process, and about technology as the implementation of some (but not all) process. It was a good conversation, one I've had many times since then.

You can twiddle all you want with various pieces of technology, but unless you have well-tuned processes that derive from policies reflecting the needs of the business, then your technological efforts are wasted. Very likely you'll end up focusing on threats that don't exist while ignoring those that can seriously bite you.

There are some elements, though, where you really don't need to worry so much about extensive process or looking to map from business drivers to policy to process. One of these is what to do with the accounts of ex-employees. While people become ex-employees for a variety of reasons, there's really only one threat that exists: all access by ex-employees is by definition unauthorized access. So as I see it, there's actually a very simple process for handling their accounts, and here it is:

Immediately disable accounts when users quit, get put on probation, or are fired
Delete these accounts when you no longer need them for recovering data

There's certainly no business requirement for keeping an ex-employee's account active. That's why you should disable it right away. If you instead immediately delete an account, you've made it nearly impossible to retrieve information that the employee has encrypted. The default recovery agent is a backup for EFS, but you need to have configured it correctly when you implemented EFS. However, for S/MIME there is no backup. Plus, in case you need to conduct any kind of investigation, you might need to log in to an ex-employee's account. So to be safe, disable it -- but keep it for a while.

Only after you're certain that you won't need it anymore can you then delete it. You don't want it to hang around forever, because for so long as it exists, it's something you have to manage. So when you're finished with it, after you've completed any investigations and have recovered whatever data you need, get rid of the thing. Now you can forget about it.

I see two remaining considerations. The first: it's up to you to determine the time interval between disabling and deleting. Here's probably the only point worth some thought in this process, and it's mostly about responsiveness. How much time can IT give the business units for completing an investigation and recovering data? Perhaps you'll have two time limits:

one for when no investigation is required (say 30 days for general collection and clean-up)
one for when there is an investigation (it's out of IT's hands, let the legal department decide -- but the duration should never be infinite!)

The other policy/process consideration is determining what data of the ex-employee to keep. I suppose "keep it all" would be one choice...but do you really need all the MP3s and porn that guy has collected? Unless you're investigating resource abuse, probably not! Here's an opportunity for you to work with the business units to decide -- most likely on a case-by-base basis -- which data to keep and which to discard.

Handling the accounts of ex-employees is pretty simple, really. So don't get too mired in arcane process work here. There's far more important work you need to be doing.

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!