Patrick, I applaud your rigor. I might not have made the same choices re definitions, but I could live with yours, as long as we are clear what we are talking about.
The DAR Tiger Team apparently considered the physical movement of media, including flash drives, as Data at Rest. Maybe that makes some sense, in that Data at Rest tends to imply a power-off scenario. Personally, I don't see a lot of difference between moving an encrypted file via a flash drive, and moving a previously encrypted file as an attachment to an e-mail message - both would seem to be Data in Transit, at least to me. But others might want to reserve the Data in Transit term to plaintext data that is being sent over an encrypted (and perhaps authenticated) session/channel, a la SSL/TLS or IPSEC, whether the session-level encryption is performed in software or in an external hardware box such as a HAIPE link encryptor. Data in Use, at least in the sense I was using the term, refers to explicitly selected data, i.e., those files that are currently OPEN and being displayed, edited, etc. Unfortunately, these definitions, or at least the way I was using them, do not adequately cover the "ALL THE REST" kinds of data that are the most troublesome - the temporary files, not-yet-scrubbed free space that previously contained sensitive data, the page file, hibernation file, and other typically "unseen" data. I don't have a good name for this kind of data - I wish someone would invent one. How about "Exploitable Ancillary Data" (EAD)? I would argue that Data at Rest problem is adequately solved by existing FDE solutions, at least if the disk encryption key is protected by a two-factor hardware cryptographic token, preferably using a strong ECC algorithm for the wrapping, and with a hardware-enforced limit on the number of incorrect PINs that can be entered. Assuming that the FDE solution is used to protect the boot volume, and/or any other volumes that EVER contained Exploitable Ancillary Data, the stolen laptop problem is effectively solved, modulo the devilish details. However, this solution DOESN'T protect the data from the some other user who has access to the computer, whether that user be the system administrator, someone with a Guest account, or perhaps your teenage game-playing son or daughter; nor does it protect against any malware that might be running. And to answer someone who questioned why it was necessary to scrub the data after it was deleted, assuming the use of a FDE solution, that FDE solution protects the system against unauthorized users, but it doesn't nothing to protect against other AUTHORIZED users, including malware. They can easily hit the Undelete button, or do a more thorough examination of all of the free space sectors, the page file, etc., looking for something that might be of interest. And BTW, I am not convinced that a virtual partition is sufficient to solve either of these problems, although a RAM drive would help a lot if temporary files could be confined to it reliably. And I disagree that it is unnecessary or undesirable to encrypt the OS files in an FDE solution. Unless you use something like Tripwire to hash all of the OS files against a digitally signed record, it is difficult or impossible to be certain that someone or something hasn't covertly buried some data in a file that is not likely to ever be used, e.g., one of the Windows update rollbacks. Likewise, as others have observed, many log files and other application data are stored in the same folders as the OS and application files, and certainly we shouldn't exempt a file from scrutiny just because it has an .exe or .dll extension. I certainly wouldn't claim that using a hardware file encryptor to encrypt files just as soon as possible, decrypt them only when necessary, and deleting and scrubbing the plaintext files immediately after successfully encrypting them will necessarily provide perfect security, but it will help to narrow the window of opportunity for malware or malicious user attacks to the bare minimum. More comments below, in line. Date: Thu, 26 Jul 2007 11:59:31 -0700 From: Patrick Cahalan <[EMAIL PROTECTED]> Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii; format=flowed I've been following this thread, and I think it's gone a little out of focus. I like the original idea, but if you're going to talk about classifying data in those three states (at rest, in use, in transit), you need to define exactly what you mean by those terms. Robert (who kicked off the thread) said: > However, Data at Rest is almost by definition completely useless. > Generally speaking, at least in most enterprise environments, data > is worthless unless it can be shared with someone else, and that > implies Data in Transit. And that includes data being physically > transported on a USB flash drive, as well as transmitted > electronically. Right at the beginning of the thread, we have ambiguity as to what "Data at Rest" means. If Robert is including physical transportation of media as part of the classification of "Data at Rest", then... well, the term itself can really be regarded as a useless category: you can always pick up a disk and carry it away... effectively (from a security analysis standpoint), the class of data which can be regarded as "at rest" is the null set. RRJ: The "that" in that sentence could be interpreted ambiguously. I meant to refer to physically transported data, i.e., form one computer to another, as Data in Transit. That doesn't include picking up your laptop and taking it home, however. Similarly, what is the difference between "Data in Transit" and "Data in Use"? We all seem to have some sort of assumed idea about what those states are, but there's no rigor attached to it... if data is being read off of media by some process, being transferred to the application layer in order to be presented to a user, is that "Data in Use" or "Data in Transit"? It's certainly changing states, which would imply that it's "in Transit"... I could go on, but you get my point. RRJ: Yes, I agree. I would propose to restrict Data in Use to a file that is currently open. But whether that should extend on a character-by-character basis to data that is being typed in and encrypted over SSL, I'm not quite sure. We're lacking the base context. So, being obsessed by classification, I'll propose one. "Data at Rest" is data recorded on storage media. This data can be regarded as "secure" if and only if data is protected by strong encryption (where "strong encryption" is defined as "encryption requiring a computationally infeasible amount of time to brute force attack") AND the key is (a) not present on the media itself (b) not present on the node associated with the media; and (c) the key is of sufficient length and randomness to be functionally immune to a dictionary attack. RRJ: That definition includes information being physically transported between two computers, but I could live with that as long as we are clear. "Data in Use" is all data *not* in an at rest state, that is on only one particular node in a network (for example, in resident memory, or swap, or processor cache or disk cache, etc. memory). This data can be regarded as "secure" if and only if (a) access to the memory is rigorously controlled (the process that accessed the data off of the storage media and read the data into memory is the only process that has access to the memory, and no other process can either access the data in memory, or man-in-the-middle the data while it passes through I/O), and (b) regardless of how the process terminates (either by successful completion, or killing of the process, or shutdown of the computer), the data cannot be retrieved from any location other than the original at rest state, requiring re-authorization. RRJ: That's close, but to my mind it doesn't quite deal with the case where there are multiple processes running simultaneously, e.g., in user space and system space, or two different users running simultaneously, and it implies a degree of memory protection that is clearly out of scope for most commercial operating systems. It also doesn't deal with various kinds of observable data, including Simple Branch Prediction Analysis attacks, where a spy process running on behalf of one user or process can determine the encryption key being used in a different process by means of a timing attack. "Data in Transit" is all data being transferred between two nodes in a network. This data can be regarded as secure if and only if (a) both hosts are capable of protecting the data in the previous two classifications and (b) the communication between the two hosts is identified, authenticated, authorized, and private, meaning no third host can eavesdrop on the communication between the two hosts. RRJ: This is accurate, but may be going too far, especially clause (a). I think most people would tend to separate the security of the information flowing over some kind of a transport medium (electronic or not) from the issue of the security of the information once it arrives; the assumption being that such data is more easily intercepted off the wire than by prying it out of the computer. Looking at these three classifications, here's your vulnerabilities: ----- Protecting Data at Rest: You must either (a) encrypt the entire contents of the storage media or (b) you must have complete knowledge of how any system or user organizes data when writing to the storage media so that you can encrypt the data that needs to be protected. (a) is FDE. (b) can accomplished by any one of a number of other solutions, but is very very difficult because even if you know how the system stores everything, you don't know (or have to enforce through restriction) how the user may store something (you must disable his/her ability to store anything "sensitive" on the media in a location that is not encrypted). Furthermore (c) you must enforce strong keys/passwords and (d) you must prevent the user from storing the password on the media. Finally, remember, (e) for detachable media, including laptop hard drives, the USER is considered the "node associated with the media", so really, your data can't be considered secure, because the user is the node, and the user has the key. (Unless, I suppose, you have the ability to revoke the key remotely, preventing Disgruntled Joe from taking a laptop out and then quitting with a copy of your code base already in his possession). RRJ: This is true if the user is allowed to take the entire laptop home, and can dump the contents once he gets there. But if the problem is limited to detachable/removable media, then various solutions can be used to bind or seal the encrypted data to the host computer so that it can't be decrypted on an unauthorized computer, even if he has possession of the data and the cryptographic token, and knows the PIN. By far, (c)/(d)/(e) are going to be the hardest. A suitably strong password that prevents a dictionary attack is going to be burdensome to the user to retain, so they're either going to forget it, or write it down and stickynote it to the monitor, etc. The only way to mitigate this risk effectively is to *limit access to the data in the first place* - people look at FDE as a "silver bullet" to allow them to say, "We can now allow our vice president to take a copy of the financial database home on his laptop, because it is encrypted, so we don't have to worry if the laptop is stolen", but that assumes that (c)/(d)/(e) aren't problems, which is screwy. Sensitive data shouldn't leave the house, people. If the VP wants access to the data because it makes his life easier, say "No, you need to be in the office to get access to that," or make sure ahead of time that everyone at the CEO/Board of Directors level knows that you have *no real data protection* - your data is only as secure as everyone is trustworthy. And while I may trust a particular worker to not read data to a corporate rival over the phone, I simply don't trust any number of workers > 2 to *not put their password on a sticky note on the screen of their laptop*. RRJ: Requirement (c) and (d) can be enforced through the use of a two-factor cryptographic token that destroys the keys if an excessive number of incorrect PINs are entered. With that mechanism, password complexity guidelines are quite so essential, and the tendency of the user to write the PIN on the back of their CAC card will be diminished. Certainly, storing the password or PIN in ANY form on the media where it can be subjected to an offline exhaustive search attack is a Very Bad Idea. ----- Protecting Data in Use: This is basically impossible in today's OS market... anyone who claims that they have "secure data is use" is full of baloney. The best you can do here is mitigate the attack vectors. [RRJ: Agreed. We can significantly mitigate the attacks, but not prevent them entirely.] If you use FDE, you solve some of the problems because the swap space is encrypted, which prevents one attack vector, or you can get rid of swap altogether (and make sure you're not using NVRAM). However, if you look at the various ways that Data in Use can be mishandled, virtually all of the major vulnerabilities are exploitable at the OS level, which is something that you've more or less outsourced to your OS vendor. Your only mitigation here is to lock down the OS as much as you possibly can (including using FDE to protect the OS files at rest!), and this is more often way more trouble than it is worth, given that even if you could cover all of your bases, it doesn't protect from Kevin Mitnick. From a cost/benefit analysis, aside from taking basic steps to secure an operating system, you're wasting money - locking down Windows to the point of near un-usability isn't going to protect you from a zero-day IE exploit. The number one way to prevent OS level exploits is to use a web proxy at your border and disallow all attachments via email. Anybody who can successfully sell #2, please let me know how you did it. If you can't do those two things, though, spending more than a minimal effort locking down the host OS is largely a waste of time. RRJ: It would also help to disallow all other users of that machine, including Guest accounts and the system administrator. And if someone figures out a way to sell that idea, I would also be very interested! ----- Protecting Data in Transit: Here's where S/MIME and SSL and IPSec and all that good stuff comes in. Actually, next to protecting Data at Rest, protecting Data in Transit is probably one of the easier tasks to accomplish at the present time, except for the fact that both hosts have to be able to protect the Data in Use, and we illustrated in the previous paragraph how hard that is. Yes, you can man-in-the-middle data in transit in many, many instances in today's networked world, but we already have many of the technologies to mitigate this; we just don't deploy them properly. RRJ: I agree, although most of the security mechanisms actually being used today are not strong enough cryptographically to protect the data for more than a few years. RSA-1024 is on the verge of being broken today, and will surely be possible within the next decade. And using AES-256 with an 80-bit equivalent public key algorithm, or a 32-bit equivalent password, worse yet, doesn't make any sense at all. ----- Looking at all of the above, it should be obvious to everybody that you can't claim your data is "secure". So, what you need to do is decide what constitutes "reasonably secure" and shoot for that; and that is an organizationally-dependent classification. There is no industry-wide Best Practice available here. > Assuming you are using a hardware token to provide two-factor > authentication, hopefully it has a big red light on it to let you > know when it is being used for encryption or decryption. And > hopefully you log off of the token as soon as you have finished > encrypting a file, and likewise whenever the screen-saver locks. Although I agree, this would be awesome if used properly, it's simply not ever going to be used properly. People won't notice if their hardware token flashes red. They don't notice when their browser doesn't have the SSL lock icon. Even if they do notice, taking a set of users bigger than a few, most of them aren't going to care. You can't solve this problem with education or training. RRJ: I'm not quite as pessimistic. In the case of our Hydra PC token, the red light isn't just a small LED that could easily be overlooked - it lights up the transparent end-cap with a very bright red light that is about 1/2" by 1" and is pretty obvious. It doesn't take much training to tell someone that it shouldn't be going off all by itself. > Unfortunately, really large files can become rather cumbersome to > deal with, and particularly the .pst files created by Outlook - > some of which can grow to 4 GB. So archive your e-mail religiously > to keep the working set small, and use s/mime for all your > important correspondence. Also great tips, which unfortunately are going to fail for any reasonable number of users. RRJ: One of the most serious and inexplicable omissions in Outlook and Exchange (all versions) is the ability to easily screen incoming e-mail based on whether it is encrypted and/or signed. Such a feature would immediately cut the amount of spam down to nearly zero. It isn't that hard to train users to encrypt all of their e-mail, at least all of their internal correspondence. You just have to send a nasty-gram to anyone who violates the policy, and copy his/her boss. > Finally, plan ahead. File formats change, disk crashes occur, > encryption hardware gets lost or broken, and your wife might need > to access your income tax returns if you run into a tree some > night. Absolutely. Also, remember, your data is only as secure as your backups. If you're busting your chops protecting your data, you should be busting your chops equally to protect your backups, whatever they are. RRJ: Absolutely. If the backup tapes fall of the back of the truck, they'd better be encrypted. Bob Robert R. Jueneman Chief Scientist SPYRUS, Inc. _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
