The trouble with S/MIME e-mail encryption
With careful planning, S/MIME can be nearly effortless after the initial install -- until you need to scan, inspect, or search the encrypted messages
Follow @rogeragrimesA few times a year, I recognize the need for a product where none exists because I hear multiple customers asking for it. This is one of those times. The products that an increasing number of my clients is looking for are e-mail scanning and archiving systems that can handle S/MIME-encrypted messages.
In a normal year, I visit 20 to 40 clients, ranging from small companies to Fortune 10, where I get to see what products they are using and how well these products work in a real-world scenario. Increasingly popular these days is the use of S/MIME and other e-mail encryption methods (such as PGP, proprietary Web mail portals, and so on) to protect e-mail both within the enterprise and externally. S/MIME isn't necessarily the best method to use, but it's a stable, open standard and probably the most common e-mail encryption method I've seen in use.
[ Die, unknown executable! Now that malicious programs outnumber legitimate ones, blocking the bad may give way to allowing the good. See "Test Center review: Whitelisting security offers salvation." ]
Every S/MIME customer I have goes through a few phases. First, they need to understand how it works. How do you turn it on? Who gets what keys? How are the keys distributed? What training will end-users need? How to automate its use? It's no small undertaking.
E-mailing in the dark
Often in the second phase, S/MIME ends up nearly crippling the company's normal e-mail functionality. S/MIME involves encryption, and when you encrypt e-mail, it is no longer searchable. At the very least, users can no longer retrieve past e-mails based upon message text keyword searches, although the e-mail subject line and some other information, such as file attachment name, may remain visible.
This may sound merely bothersome at first, but it becomes mission critical when you need that one single e-mail for proof in a disagreement. Some users respond by turning their e-mail subject lines into more descriptive headings that can be more easily found using keyword searches, but at some point, the sender begins to reveal information that should probably be protected within the S/MIME body.
Worse for today's computer security departments is the fact that S/MIME ends up defanging their anti-virus scanners, DLP (data loss prevention) tools, and e-mail archiving and retrieval systems. Outgoing S/MIME-encrypted e-mail can be anti-virus scanned before encrypting and sending, but it's more difficult to scan incoming S/MIME messages, where the scanning is done on a gateway or by an external service provider. Most of the risk from e-mail malware isn't from the stuff you send, anyway. It's from the stuff sent to you. If you use S/MIME and don't have client-side malware detection for e-mail, you now have a problem.
