I asked, you answered. A few weeks ago, I wrote about Tom Whittington, CIO for California's Contra Costa County, where a glitch in an e-mail address book sent hundreds of messages with confidential information to a company in Sweden over a two-year period . I asked what he -- and the rest of us -- can do to keep something like that from happening again. Readers responded with far too many good ideas to print in this space. Here's a sampling:
- "We do not send sensitive data in e-mails. Instead, we save data in restricted-access folders on an internal server and send a link to the file in the e-mail. If the recipient of the e-mail is authorized to receive sensitive e-mails, he will already have the credentials required to access the folder."
- "Some companies block all outbound attachments except to whitelisted organizations. It allows e-mail traffic, just not attachments."
- "What Contra Costa County could have done was monitor all their outgoing mail with a program that scanned for keywords. They could have then embedded keywords in their Word and Excel documents that contained personal information."
- "The easiest solution may be to tag nonsensitive e-mail at the source and disallow e-mail directed outside the private network that does not carry the requisite tag."
- "1) Never send sensitive data via e-mail. 2) When you break Rule 1, encrypt the data. Any other system is broken by design, is it not?"
- "What if Mr. Whittington established a policy and infrastructure to support the encryption/decryption in electronic communications? If someone sends sensitive data that is not encrypted and it gets misdirected, you now have a policy to deal with the event."
- "Financial data and private employee information should never be sent through public e-mail without being encrypted. You can write procedures to automate the process in Perl on both Windows and Unix platforms, and you can probably do it in VBScript on Windows. The platform isn't the issue; it's a matter of thinking through a process instead of clicking through it."
- "The financial information and personal information should have been sent as an attachment that was created in an application that can password-protect the information."
- "The e-mail address architecture should have been set up differently. If the two-letter department abbreviations in e-mail addresses are eliminated, there is a smaller chance of e-mail being sent to an unintended recipient."
- "If there's a technological solution, I'd be surprised. If I were Whittington, I'd be investigating why all the Swedish e-mails warning about the problem were ignored. Looks to me like a cultural issue: lots of employees thinking it's someone else's problem."
- "All e-mails sent to addresses not on a whitelist could have a footer appended with an e-mail address and/or hyperlink for recipients to use if the e-mail was not intended for them. We should make it easy to report the problem to somebody who will actually attend to it."
- "An outsourced account that I work with had a similar problem. We were sending status reports and various other items 24/7, and we didn't know there was a problem until we got a truckload of tickets with missing reports, files not e-mailed, etc. It turns out that the solution was to use only the server address book and ignore the local copy."
- "I think the issue is the political environment. When the replies arrived, either the employees didn't know who to notify or they were afraid to say anything, or someone wanted power and control over IT. Unless you have witnessed it, you cannot even begin to comprehend the level of turf fighting that occurs in large governmental agencies, and it's not just with IT."
Thanks to you all for your ideas. They may not solve every e-mail-leak problem -- but they give us all a better chance of keeping them from happening.
Frank Hayes, Computerworld's senior news columnist, has covered IT for more than 20 years. Contact him at frank_hayes@computerworld.com.