Steve Riley on Security : physical security

I want a Model 22 HDD Hard Drive Disintegrator

Steve Riley — Wed, 21 Jan 2009 00:43:40 GMT

Here at Microsoft we have an active internal discussion group where most security-minded folk hang out. The topic of data destruction came up recently, it’s actually a lot more difficult than most people think. CIPHER /W and SDELETE do a reasonable job, but they aren’t perfect: the paper One big file is not enough: a critical evaluation of the dominant free-space sanitization technique dives into some interesting detail. Frequently people talk about DoD (U.S. Department of Defense) compliance, but seven wipes really aren’t necessary, according to Secure deletion: a single overwrite will do it. I’ve always thought the notion that bits will somehow “soak” down into the disk and could be recovered by “shaving off” the disk’s top layer is silly—probably invented by the folks who want to sell you secure wipe utilities. If that were really true, then it would be a fairly simple operation to “wash” away encryption, no?

For thorough data destruction, I’ve been a fan of shotgun washing. But for those without shotguns at the office, a company called Security Engineered Machinery has introduced the Model 22 HDD Hard Drive Disintegrator.

This system is built specifically to destroy hard disk drives. Load up to 10 drives on to the automatically indexing conveyor and in 30 minutes you'll have nothing but a pile of metal chips. The unit comes as a complete system, including sound-dampening enclosure and HEPA vacuum to remove airborne contaminants. The disintegrator's rotating knives transform the drives into unreconstructable fragments, leaving all data unrecoverable. the bin is made of aluminum, to prevent magnetic pieces from sticking to it

Watch the video, it’s pretty cool. I love the narrator’s dead-pan delivery, but the resemblance to the Illudium Q-36 Explosive Space Modulator really made me chuckle. They should do a marketing tie-in with Marvin the Martian.

“Oh, recoverable data makes me very angry. Very angry indeed!” (h/t Scott Culp for the quote.)

Speaking of washers and aluminum, my six-year-old Frigidaire front-load clothes washer started making a loud thumping sound during the spin cycle. So I did a little bit of searching and found out that this particular unit, a popular model made by Electrolux and sold under the Frigidaire, Kenmore, and General Electric brands, was apparently designed by someone who lacked a high school understanding of chemistry. An aluminum spider arm is connected to the stainless steel inner basket, which of course gets wet during use. What happens when you apply water to the interface of aluminum and steel? Galvanic action! The aluminum disintegrates. Some owners have posted videos of their washers here and here.

I’ll attempt the $300 three-hour repair, and I’ll paint the new spider arm with some primer and anti-rust paint. Or maybe I’ll convert it into my very own Illudium Q-22 HDD Explosive Hard Drive Disintegrator.

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.

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!

Why administrative passwords will never be like nuclear missile launchers

Steve Riley — Tue, 21 Nov 2006 13:16:22 GMT

During the past few months many people have lamented that Windows lacks a nuclear missile style control option for administrator passwords. Surely you've read about or seen photographs of missile silos where two operators, separated by a distance greater than the span of a single human's arms, must each simultaneously turn a key in a switch to launch a missile. Such a fail-safe is important when considering missile launches: presumably a nation can't thus be committed to global thermonuclear war on the deranged whims of a single raving lunatic.

At first glance, it seems reasonable to allow for similar control over domain and enterprise administrator accounts. A while back I wrote about the fundamental requirement of trust in administrators; missile control-style passwords (is there some official term for this?) might lessen the requirement for such trust, goes the thinking. Well, I'm not convinced that the logic that works for missile silos extends to administrator passwords. Let's examine the differences.

It works for missile silos because the fail-safe is tuned to the characteristics of its environment. It takes two keys, each of which must be rotated simultaneously, and they're separated by around ten feet or so: therefore, two humans absolutely are required. To accidentally or intentionally launch a missile when not under orders, both people must be either equally stupid or equally insane -- and in the second case, also equally trust that each is, in fact, a criminal, rather than one acting as a double agent attempting to entrap the other. Furthermore, both operators perform the function in full view of a whole lot of government staff and military officers. The environment and the fail-safe work together to keep the deadly missiles in the ground. Another important aspect is this: the silo and its control system are designed by and operated by the same entity, the government.

Now compare that to a domain controller. Let's say that it's possible to enable a feature that requires entering two passwords. Where would you do this? A logon screen with two password entry fields lacks both physical and human separation: one person could enter both passwords if he or she knew them. It's no better with smartcards -- again, one person could insert both cards into the readers. Replicating a silo-like environment using a pair of computers isn't the answer, because unlike the silos and their control systems, Microsoft designs Windows but you operate it. The fail-safe works for the silos because of the required physical separation. Microsoft can't dictate, and certainly can't enforce, that you have two domain controllers, separated by at least ten feet. Not everyone can afford all the necessary hardware; plus, think of the demands that would place on space and power in a data center. And besides, even with separated domain controllers, a malicious admin need only to enter the first password or insert the first smartcard in one computer then wheel over to the other one and enter the second password or smarcard there. I'm not sure there's a way to check for simultaneous credential entry.

Separation and delegation of administrative duties is, of course, a good and important concept, one that we'll continue to refine throughout the operating system. There's a lot of power granted to administrators right now, this power we will help you segregate among multiple roles (humans) in your organization. But because of the nature of computer systems, any human granted a particular bit of administrative power must be trusted with that power. Computer systems and the data they store, process, and protect aren't silos; applying silo-style security is the wrong approach to mitigating security risk.

Domain controller security: it starts at layer zero

Steve Riley — Sat, 11 Mar 2006 00:15:00 GMT

Recently I seem to have had the same conversation over and over again, in places as far apart as Jakarta, Winnipeg, and Berlin. The question is usually worded like this:

"What happens if someone steals one of my domain controllers?"

There is, essentially, only one correct answer, which is this:

"You flatten and rebuild the entire forest."

Not very comforting, I know. Consider this example.

A customer once liked to display all their shiny computer gear behind a large plate-glass window that faced the street (complete with labels indicating the telephone numbers of all the modems, but that's a different problem). One day, some dishonorable thugs decided to help themselves to a computer, so they smashed their pickup truck through the window, snarfed the first computer they saw, threw it into the back of the truck, and sped away. It just so happened that this computer was . . . a domain controller! They called the police and described the truck and the theft; the police found the thieves, recovered the computer, and returned it to the customer -- who proceeded to reconnect it to the network. Alas, a very unwise decision.

Think about it for a moment: a bad guy had physical access to that which is the source of authority for every security principal in the forest. Who knows what he's done? Some possibilities:

Extract password hashes from the AD database (no need to crack the passwords themselves now)
Install malicious self-replicating code
Add rogue user, service, and administrator accounts
Create or modify logon scripts

Honestly, this is a machine you can no longer trust. And if the bad guy still possesses the computer and manages to reconnect that Typhoid Mary of a DC back to your network, and forces a replication to the other DCs in the forest, well...it frightens me to think of the ramifications.

Back in the Windows 2000 days, Microsoft published some best practices for securing domain controllers. Part II (which I've linked below) contains a section called "Recovering from the physical breach of a domain controller." Ten thickly worded pages guide you numerous manual and time-consuming (read: potentially error-prone) steps for working the bad guy out of your forest. I suppose all that might succeed, but really you can't trust that forest anymore. Rebuilding it from the ground up is your only practical choice. Yes, FDISK is your friend.

Managing risk

Regular readers of my articles and attendees at my conferences know the point I'm making here. In the case of domain controller physical security, the question usually arises when customers begin placing domain controllers in locations outside the central headquarters. For we in the United States, where connectivity is amazingly cheap and highly reliable, no one thinks of placing domain controllers in far-flung offices with only three people, two cats, and a creaky vending machine disgorging year-old pretzels (when it's in the mood).

But in other areas of the world -- areas where bureaucracy-laden telcos, often remnants of tin-pot dictatorships, dispense bandwidth as if it were glittering emerald encased in pure platinum (with stratospheric monthly charges to match) -- organizations must make a security vs. usability tradeoff. Security prefers that all DCs remain safe in a central data center and all authentication traffic traverse the WAN; usability demands that DCs be placed where the people log on because WAN links die so frequently. In this scenario, I hope you agree with me that usability wins: if the people can't log on, they probably can't do their jobs; secure environments are useless if idle workers can't access them.

Therefore, you have to accept the risk, and situate domain controllers as close to the people and resources as possible. I have two suggestions for mitigating risk.

Cage that beast. Numerous manufacturers offer steel cages in which you can encase your remote domain controllers. Limit your selection to those that include some form of physical anchoring, such as a large heavy chain attaching the cage to a bolt or eye screwed deep into a concrete floor. Be sure the cage includes a decent lock -- an electronic lock is best, one that can audit all access. Remember, you're protecting not only the hard drive but the whole computer.
Consider multiple forests and selective authentication. Surely you've learned that Microsoft long ago stopped recommending single forest/single domain AD designs; yes, we were wrong about that. Because the forest is the true security boundary, implementing multiple forests helps contain the spread of any compromise. But to make multiple forests useful, you need to implement trusts. Typically, those are unidirectional: central corporate resource forests trust distributed user forests. There is the potential, at least, that the central forests might be trusting a compromised forest -- at least for a time -- and could themselves become compromised.

A feature known as selective authentication lessens the risk. It's an authentication permission set on the security descriptor of the resource computer object located in AD, not on the security descriptor physically located on the resource computer itself. Controlling authentication in this way provides an extra layer of protection to shared resources by preventing them from being randomly accessed by any authenticated user in the trusted distributed user forests. Now, if one of these user forests is attacked and requires a rebuild, you don't have to rebuild the entire trusting forest also -- only the machines in that forest enabled with selective authentication of principals in the attacked trusted forest. See the second article below for more information on selective authentication; scroll down about one-third.

So protect those domain controllers! No, they don't store your company secrets; yes, they're pretty much just plumbing in your network, but I'm sure many of you have experienced the painful inconvenience and overwhelming urgency associated with malfunctioning plumbing... Plus, consider Active Directory designs that contain threats and mitigate risk. Perhaps my 60-second AD design will work for you:

Forests and domains represent geography (geography is stable and doesn't move -- much)
Organizational units mirror your administrative model (types of machines and people)
Security groups follow your organizational chart
Selective authentication, not mere trusts, controls and limits access

It's simple, it's effective, it removes the politics from the design, and you don't need to pay an army of too-smart-for-school suits -- I mean consultants -- to pretend to labor over a customized design "just for you" that's really the same thing they did for the previous 1,000 customers but still costs you dearly.

Best practice guide for securing Active Directory installations and day-to-day operations: part II
http://www.microsoft.com/downloads/details.aspx?FamilyID=c0dbeb7e-d476-4498-9f6c-24974fb81f1e&DisplayLang=en

Security considerations for trusts
http://technet2.microsoft.com/WindowsServer/en/Library/1f33e9a1-c3c5-431c-a5cc-c3c2bd579ff11033.mspx

New column -- The case of the stolen laptop

Steve Riley — Thu, 10 Feb 2005 21:12:00 GMT

Seems like once a week I hear from someone worried about stolen laptops -- or, worse, just joined the ranks of laptop theft victimhood. The best way to stay out of that club is to keep the thing with you at all times, or leave it in your hotel room when you don’t want to carry it around. Yes, everyone has heard the warnings about hotel room theft, but I’ve never had something stolen from a hotel room and I spend well over 200 nights a year in hotels. You’re far more likely to leave your laptop or PDA or smart phone or USB drive lying on the seat in the taxi or on the counter at the bar as you and your new friend depart for the evening.

So how do you protect your data if the unfortunate should ever befall you? Three features of Windows 2000 and Windows XP can help you keep your information out of the hands of a thief who somehow manages to get hold of your laptop: passwords, encrypting file system, and SysKey. Do realize that if you use these features, you will most likely frustrate the thief so much that he or she will destroy your laptop in anger and disgust, but this is far preferable to seeing the development plans and source code of your next killer product posted on Slashdot.

http://www.microsoft.com/technet/community/columns/secmgmt/sm0205.mspx