Skip to the bottom for "morals" of the story. Some things to consider: Information leakage So once you've secured the areas that you know sensitive data resides or will travel through it is time to start looking at the areas where that data may end up unintentionally (or otherwise). When you edit a file on a computer for example that file not only exists on the harddrive in it's protected location, but is also loaded into memory so it can be manipulated. This often results in the data being written to a swap file or partition without the users knowledge or consent, an attacker will be able to retrieve data from these locations with little difficulty if access is gained. OpenBSD for example now supports an encrypted swap partition, in the file /etc/sysctl.conf simply enable vm.swapencrypt.enable: vm.swapencrypt.enable=1 In windows NT and 2000 you can force the swap file(s) to be held on certain partitions, creating a small (i.e. 200 megs for a 100 meg swap file) D: drive and placing the swap file there not only reduces the risk of it getting fragmented but makes it much easier to control access to it since controlling access to the C: drive on a windows machine tightly will often break many applications. In Linux you can encrypt partitions using a number of methods and could in theory mount a swap file (instead of a swap partition) on an encrypted partition to protect it however this is rather cumbersome. With the apparent death of the International Kernel crypto patch and several other software packages that allowed for the encryption of the entire system the future of encrypted swap files does not look good for Linux. As well there are any number of directories a user can copy a file to in most systems, for example on Unix the /tmp directory is often world readable and writeable, it is easy for an attacker to monitor this directory and "steal" files as they are copied in. One way to help prevent this is to set a strong umask for users, i.e. the default file permissions used when a file is created, "man <shellname>" will contain the necessary information, unfortunately many Unix systems still default to having world writeable umasks. Restricting access to removable devices is required if you do not want users to be able to take information home with them, in Unix simply assigning the appropriate permissions to the /dev/* entries will do the trick. For Windows a commercial software packages such as SecureNT can be used to limit access to removable media [2]. If users have access to the Internet then it is possible that they can upload files, restricting access for outgoing protocols such as SSH, FTP, RSYNC, TFTP as well as the users ability to install additional file transfer software on their workstation can prevent them from sending out information. Of course almost every user now has access to email, meaning they can simply attach the files and hit send, to prevent this you can often block outgoing attachments in most mail server packages or buy add on software to prevent this type of activity. - File encryption As mentioned before one method to help prevent information from being exposed is to encrypt it. Unfortunately encrypting data effectively is a lot harder then it should be, consequently it is often not done correctly, if at all due to the challenges. There are a large number of commercial products and other software packages that enable you to encrypt data on your harddrive, I will cover them by each major OS in a sort of practical guide format along with the pitfalls that may be present. No solution fits all, so it is very difficult for me to actually give any a strong recommendation over each other (they all work reasonably well). The beauty of encryption is that in theory if it is done correctly an attacker has absolutely no way to get at the data unless they somehow steal the encryption keys. If you use a strong passphrase to protect your keys or store your keys offline then even with physical possession of the device (i.e. a laptop) an attacker would still have to try a huge number of combination, and in theory should not be able to break it using brute force. - Software to wipe data There are four main ways of wiping data that you will probably be interested. The first and most simple is wiping individual file(s) and directories, this is your first line of defense, tossing something into the recycle bin or trash can and hitting empty is not enough. The next stage would be to regularly wipe the free space on your system, thus anything that was deleted (securely or not) is, well, wiped out (pun intended =). Of course wiping free space will probably not delete something on a swap partition or currently in a swap file (as well depending on exactly how the swap file is configured data may linger long times). The next step is to wipe partitions, of course wiping your drives means you will need to reload the OS and data from backups. This however provides a higher degree of assurance, especially for Windows systems, because the swap file will be completely cleaned. The last step is the most severe, you wipe the device itself, this should destroy all the data, all the data structures, partition tables, the master boot record and so forth. This guarantees that data in swap partitions or on other unused partitions is completely wiped. If you do not wipe the device completely there will always be an element of doubt (however slight) that some data may have remained. To wipe a drive you can either boot from a floppy disk, put the drive into another system or even purchase a hardware unit with that can wipe the drive (many hardware disk copying products have this option). The problem with software wiping solutions is that in theory if an attacker gets ahold of the drive (after it has been wiped) there may be some flaw in the software (how many people verify the data has been wiped using a different software package?) that allows an attacker to retrieve data. Alternatively some stunning new discovery might result in an attacker being able to somehow reconstruct the orientation of bits that were physically present at one point. As well there is much more room for error, if you wipe a file there is no easy way to tell if the file was wiped or not short of doing a full forensics work up on the drive. If you do a partition or complete disk wipe then you better make sure that the process is not interrupted (and heaven only know how long it will take for several wipes on an 80 gig device). If your data is truly sensitive then the next paragraph is for you. Hardware to wipe data Physical destruction of the device is generally speaking a lot more effective then a software wipe, however it is a lot more trouble. The Pentagon reversed an order they had in place for 6 months that required the physical destruction of harddrives for systems that had contained "unclassified" data, so like many the trade off of physical destruction is not worth it for all systems [7][8][9]. If you choose to go with a physical destruction device make sure it meets the various DOD (Department of Defense) standards that are applicable, if a device does not meet DOD standards but claims to destroy data effectively be wary of it (I would not purchase it). The most common method for physically destroying hard drives is through the use of strong magnetic fields that fluctuate, thus "resetting" all the bits so that no data can be retrieved. Another common method is to grind the surface of the disk off, this is more common with CD destruction machines, but is highly effective and also has the benefit of leaving visible proof that the unit in question has been dealt with. The last method tends not to be used because it is messy but consists of using heat or flame to oxidize the surface of the platter or melt it, again leaving visible proof that the unit in question has been dealt with. Some places will simply drill a hole in the drive with a power drill, in theory there is no realistic way to retrieve data from such a damaged unit however as new technology becomes available it is likely that retrieve the data will be possible. This also applies to physically warping the platters (i.e. bending them in half), as attractive as it seems you would be better off using a DOD approved method. --------------------- Moral's of the story: Wipe the device, not just the C: partition or the /home partition. Data can leak into swap, temp files, you name it. If you encrypt first then the primary data store technically doesn't need to be wiped (assuming you used a good passphrase to protect the keys) but you still need to remember about leakage, so wipe the device. Using software is prone to error, and the vast majority of users never bother to verify the data was actually wiped. Using hardware to wipe is often simpler (remove HD, place on eraser for one minute, and then optionally use a power drill to punch a hole through the media) and certain techniques can leave obvious marks so that you do not accidently forget to wipe stuff. If you are serious about wiping media then you should have a formal verification step at the end to make sure it was wiped. Do not trust an outside entity to do this (a security company recently sold computers off to a another firm that was supposed to wipe the drives and put them up for auction, but the drives were not wiped. ooops). The above excerpts are from: http://www.seifried.org/security/articles/20010910-protecting-information-fr om-exposure.html Kurt Seifried, kurtat_private A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/ ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Tue Oct 02 2001 - 09:05:59 PDT