Cleaning Up After Classified Email
What do you do to keep sensitive information safe after it's been in an email message?
July 28, 2004
Los Alamos National Laboratory (LANL), the birthplace of the atomic bomb and one of the most secretive places in the United States, is currently shut down while its director, staff, and a variety of appointed officials try to figure out what to do about several security breaches, including the sending of classified messages over the lab's unclassified email system. US government agencies live by the "once classified, always classified" rule: If a system that's certified for unclassified information gets even one classified message on it, they must treat the disks as classified until those disks have been sanitized according to the requirements set out in a document called DoD 5220.22-M, "National Industrial Security Program Operating Manual." Those requirements call for all affected disks to be degaussed, destroyed, or overwritten with a specific pattern of bits.
Of course, that's a bit drastic for those of us who aren't designing nuclear weapons or doing other kinds of classified work. But LANL's problems have got me thinking about the technical challenges of "cleaning" an ordinary email system over which someone has sent confidential or legally sensitive information. It's no easy task.
The first thing to do is to figure out where the sensitive message might have been stored on disk. At some point, the Information Store (IS) will have handled the message, so it will certainly be in the .edb files on the systems that hold the sender's and recipient's mailboxes. Message information will also be in the transaction logs. And depending on the version of Exchange you're using and the clients that were used to send and receive the message, the data might be in the Message Transfer Agent (MTA) or SMTP queue directories or the sender, recipient, or gateway .stm files. You might even find copies in your spam filter, postmaster mailbox, or Badmail directory. It's difficult to find all the potential places that a sensitive message might have left traces, so take your time.
Once you find whatever remnants might be left on your systems, how do you get rid of this data without destroying your entire Exchange Server? If the scope of the message's distribution was limited, you can delete it by using Outlook, Outlook Web Access (OWA), or the Mdbvu32 utility. If you know the message's subject line, you can use the ExMerge utility to remove the message from the IS. The ExMerge log files also will tell you what mailboxes you need to clean. After you delete the message, you can purge the day's transaction logs. You can perform an offline defragmentation of the databases that contain the message, although doing so isn't guaranteed to immediately remove all traces. You can move the affected mailboxes to a fresh database (after removing the messages), then delete the old database.
None of these steps, however, are guaranteed to remove all traces of the sensitive information, and none of them are much help unless you already know exactly where the message has spread. Tools that can search your mail databases according to keywords (Ontrack Data Recovery's Ontrack PowerControls comes to mind) are handy for solving the latter problem. If your line of work involves highly sensitive data, I suggest you think now about how you'd handle the "spilt milk" if some of that data ended up floating around your email system.
About the Author
You May Also Like