Data destruction is a part of good systems administration; you should design it in to your understanding of how you use your systems.
I did a piece back in August 2016 about data management, backups, and system administration. There are a few too many topics in that article to do them justice, so I’m going to talk just about data segregation and why you want to think about your data that way.
Back in 2005, I bought a refurbished laptop on Ebay (for a friend) and when I got it, I discovered that the former owner had not zeroized the hard drive and reinstalled Windows – they simply deleted their ‘My Files’ folder. Meanwhile, their ‘Favorites’ folder was untouched – and they had some pretty interesting ‘Favorites’ indeed: I could tell the seller was a stoner and liked very particular kinds of porn. So I zeroized the hard drive and reinstalled Windows. Back in around 2002, I was on a technology advisory board for a company called Trust Digital, which did endpoint encryption on cell phones, and I suggested that we do a little marketing piece by buying a dozen or so cell phones on ebay and using a forensics tool similar to Encase on them. We did, and there was some scary, scary stuff on them. There were also some pretty cool pictures of horny naked executives and their significant others, but none of Anthony Wiener – though you can bet a forensic examination of his storage would be interesting!
How do you keep this from happening?
Option 1: You never let your media leave your control.
Option 2: You destroy any media that’s about to leave your control.
Option 3: You encrypt your data and periodically de-key it, so if it goes out of your control, it reverts to a cloud of bits.
Option 4: You don’t care at all. Go Directly to Boardwalk, collect $200.
None of those options is very good unless you can segregate your data. Segregating your data means being able to tell the difference between your data and disposable data. For example, if I look over my shoulder here at my gaming computer, it has two SSDs in it: one is devoted to Windows 10, the other is partitioned into two segments, one of which is E:\Steam and contains downloadable game assets and the other F:\Whatever contains screenshots, settings, and DVD data I’m ripping and encoding. If I adopted a simple backup and data management strategy, of not segregating my data, i.e.: it was all C:\, then I’d have to backup and manage 600gb of data, instead of 35gb in the one partition I have defined as “mine.” Designing your system with data segregation means you’re saving yourself time and effort by defining what matters to you, and how it matters. Further, since the stuff on the F:\Whatever drive is not sensitive, I don’t bother to encrypt it. In this example, I’m using machine-level segregation! My important data is on my desktop server, a few feet over from the gaming system. I spent extra money to have two separate systems so I could let Steam and Microsoft control the software on the gaming machine, and otherwise ignore it. The desktop server contains more sensitive stuff, which is also segregated. Some partitions are backed up, some are encrypted and backed up, and others, like C:\Windows are disposable. If I had to send my computer for repair* or I’ve got a cool new piece of Equation Group malware on the system drive, I can pull out all the other hard drives that contain my data, and I can be fairly confident that the stuff in C:\Windows mostly doesn’t matter. (I’m sure Microsoft leaves data-turds all over the place, and there is probably data in the paging areas I don’t want to have leave my house, but, hypothetically, I might be willing to let C:\Windows leave my hands for a while.)
If you look at Disk 0 – my main drive – you’ll see it’s partitioned into C:\ (windows) and E:\ (home) They’re separate segments on the same drive (it’s a nice big SSD) so I get fast performance on both filesystems, but I only worry about the data on E:\ since Microsoft will cheerfully give me another 100gb of crap any time I ask them for it; there’s no need for me to lovingly preserve a copy of Windows.
If you’re a systems administrator with a lot of experience, you’ll know to think about your drive layout when you build your system. It’s you’re a more typical computer user, you go to Best Buy or whatever and come home with a system that already has an operating system installed. And, it’s usually been installed in a way that is most convenient for the operating system, not for the user. They don’t want to have to explain partitions to you, so you get one big partition “have a nice day.” In that case you have 3 options:
Option 1: Add another hard drive. Call it E:\Mystuff and put your stuff on it. If you ever need to send the system somewhere, take it out. Consider buying an Icy Dock removable drive bay so you can pop drives in and out if you need to. Or use an external USB drive (this has the added benefit of allowing you to turn it off if you want your files inaccessible)
Option 2: Reinstall the operating system more intelligently. Assume 200gb or so for operating system and programs (this will change over O/S releases and software load-out: measure what you currently use and add a large fudge factor of overhead) and partitition the root drive so that you’ve restricted the amount of space Microsoft feels it can crap all over. Put your stuff in the secondary partition, Microsoft and whatnot in the primary partition, and – if the hard drive fails, you lose the whole mess together.
Option 3: Create a container partition. A container partition is a virtual partition that exists within a single file in a filesystem. So, imagine you have a drive partition called C:\Windows and 200gb file called C:\Windows\Home.TC – you could make that Home.TC file look like another hard drive – the operating system simply treats the space in the file as it would space on a hard drive, and off it goes. You’ll experience some minor performance impact from doing this, but generally you’ll not notice it – operating systems have gotten pretty good at mapping virtual filesystems, because of the degree to which cloud systems are virtualized.
When I buy a laptop, I use Option 3, because it can be hard to add a whole new drive to a laptop, and Option 2 is unattractive because laptop device drivers are notoriously squirrelly and trying to get all the devices working after a bare metal install can make you pull your hair out. Also, since I travel a lot and my laptop might be examined crossing national borders, having a virtual encrypted volume seems like a decent idea for annoying the secret police. Just make sure you remember your passphrase for it, when they waterboard you, and dekey it when you leave your hotel (don’t dekey it while under video surveillance at an airport!)
Adding a new virtual partition is pretty simple is you use TrueCrypt: you just follow any of a number of walkthroughs for it. but: whenever someone mentions TrueCrypt in a blog, they get emails from marketing people saying “TrueCrypt has been discontinued for security reasons, you should tell people to use our product!” That’s true. Feel free to use something else. But we’re mostly using TrueCrypt, here, for segregation, not trying to keep the secret police away from our stash of nuclear secrets.
To create a volume you just click “Create Volume” and then walk through the prompts.
So I’m creating a large file that’s going to be called E:\temp\freethoughtblogs.secret, which will contain a file system that will appear to be a hard drive.
You tell it the size you want (I told it a measly 500mb, since my archive of freethoughtblogs secrets is remarkably small) Do not use a password like “freethoughtblogs” that anyone might guess. Also, do not use a password like: “you can waterboard me until I die, I will never tell you!” because you might find yourself yelling that at the secret police some day, and they don’t like surrealism.
Then, it formats the drive, and you now have a 500mb file (or whatever) of crypto-noise.
Yup, looks like noise. Don’t delete that file – it’s your virtual hard drive. You can mount it using TrueCrypt to attach it as a filesystem:
Above, you can see I selected the file as my container file freethoughtblogs.secret holding the encrypted filesystem. When I give the password and tell it to mount on drive F:, it appears on my system:
And windows sees it! (I had to rename it “Freethought” because, reasons)
Now, if I only had one drive in my system ( C:\ ) configured the way it came from Best Buy, I could use this trick to make a container file that’s encrypted well enough, so that if I sold the computer all I do is unmount the container file and forget the password (“freethought”) and it’s just a cloud of crypto-bits.
I want to emphasize this one more time:
I recommend this as a system adminstration technique, not a security technique.
It’s a great way of making sure your data dies with you. Which, if you’re getting on in years, is something else to think about.**
Destroying hard drives is also a good excuse for an upgrade, if you’re running out of space and have been eyeing those new 1tb SSDs:
video by Marcus Ranum, taken with Edgertronic slow-motion camera @2000fps shot with .44 magnum JHP
For all intents and purposes, when your container is dismounted, it’s just crypto-bits and you don’t need to worry about what happens to the drive. If you use some kind of backup system, you can back the contents of the encrypted volume (if it’s mounted, the contents are decrypted when you access them through the file system) up to another medium, or you can back up the encrypted container (which means you’ll back up the whole container each time) I used to keep a storage network server on my home network, which had several large container files, which I would mount with TrueCrypt – my accesses back and forth across the network were encrypted at the block level by TrueCrypt, and I didn’t have to worry if somehow someone stole my storage server (unlikely, but …) By the same token, when I finally decommissioned the storage server, I simply bagged it and dropped it in a dumpster; I knew the data was all in the containers and was all encrypted at the container level and there was nothing on the server that was recoverable without the passphrases for the container files)
Now, you can create a container file using Windows built in capabilities, except – since it’s Windows – it’s much more painful than it needs to be. Also, if you want to use Windows built in encryption (“bitlocker”) you need Windows Pro. Lastly, since the FBI never screamed bloody murder about Microsoft adding bitlocker to Windows, I assume that bitlocker’s backdoored. Remember, I am a professional paranoid. But also, the US Government has a deep and rich history of backdooring software; it seems absurd to imagine they’d refrain from pressuring Microsoft when they pressure AT&T to backdoor their own networks, Facebook to backdoor their messaging, Google to backdoor their email systems, Apple to backdoor their phones, etc. If you want to know how to do a container file in Windows, you go into the disk management subsystem and create what’s called a VHD (Virtual Hard Drive)
Another small fixed size virtual drive. Then you have to use Windows’ extremely awkward partition management to put a partition and format the virtual drive (Be SURE you are not formatting a real drive by accident) Then Windows will see the drive:
That’s New Volume (I:) that I just created. So now I have a TrueCrypt container and a Windows VHD.
I’m not going to illustrate the “turn on bitlocker” setup process because this machine is not running a version of Windows that’s professional enough to have bitlocker. The How to Geek article  has a very detailed walkthrough, if you care.
There is one really nice feature of using VHDs and bitlocker and that’s that Windows treats the container file as special and blocks all access to it while it’s mounted. So you can’t delete the container accidentally.
So, this has turned into a rather meandering voyage: the question was: “How do you handle data on devices, if you need to send them away for repair?” and my answer is necessarily “it depends.” Or “it’s complicated.” It depends on the device and whether the hardware is accessible or not. When I break an iPhone screen, which about once every couple years, the last thing I do with the device as it’s dying, is to go to the settings and reset it to factory default. Is that good? You’ve got to trust Apple, or put a bullet through the thing.*** If it’s a hard drive in a desktop, I’d pull it out before I sent it out of my hands (I already have backups of everything)
Really, you can’t ever answer a security question without taking into account your threat model: who’s your adversary and how strongly motivated are they to come after your data? Once you’ve established your threat model, then you can reason about what paths they are likely to pursue to come at you. I.e.: an angry internet troll is going to adopt very different attack strategies from NSA hackers, who are going to adopt very different attack strategies from the Russian mafia.****
(* That’s a hypothetical. I do my own repairs.)
(** My accountant is my executor, and has orders to physically destroy all of my hard drives by taking them to a machine shop and having someone take an oxyacetylene torch to them)
(*** And you’d better know where the memory is in the device so you hit it with the bullet. Or use an oxyacetylene torch.)
(**** When they ask for your password, you’re probably going to wind up in several dumpsters, in different parts of town, so it’s irrelevant: you’ll give it to them. Not that doing so will help you at all, or smooth your final moments.)
Bruce Schneier: Recovering Data From Cell Phones
Microsoft: How to Turn On Bitlocker Drive Encryption
Peter Guttmann: Secure Deletion of Data From Magnetic and Solid-State Memory (Peter makes an interesting discovery the NSA’s recommended data wiping technique was good enough to prevent anyone but the NSA from reading a wiped disk. Coincidence! This was from 1995, and of course drive densities and different track encoding techniques have probably changed the underlying assumptions completely. I remember when Peter did this talk in ’95, and it brought down the house.)