A while back, a colleague asked me what is the best way to encrypt internal email.
My first question to him was – what is the threat, who is the attacker and what is the asset you are protecting? Are you trying to encrypt business communications between employees and vendors/customers to protect from eavesdroppers or do you want to encrypt the message repository and protect it from attackers? Before applying encryption as a security countermeasure do a little threat analysis first.
My experience with data loss prevention with systems that monitor millions of transactions and hundreds of violations a year has shown the following:
a. It’s better to use outgoing email in clear text because
1) you can monitor what people are doing and
2) having a business partner decrypt/encrypt is generally a pain in the ass that is greater than the value of the business transaction.
There is little reason to encrypt internal email in my experience. Let’s say that Mike in sales has an insider tip on company stock options and he wants to tell Candace in HR. Encryption doesn’t mitigate that threat. Let’s say that Joe has a secret algorithm he wants to sell to Gene who works the dark side. Encrypting internal email won’t mitigate that threat either. If there are confidential files being sent by email to external destinations – encrypt the files and give the key to the recipient.
If you’re concerned about data leakage then your cheapest and most effective countermeasure is monitoring email transmission for particular data types and destinations.
b. If you have high-value business communications between your company and vendors – you are better off just encrypting the file (for example a sensitive contract or product design doc) and sending the encrypted attachment. This will enable you to monitor who is sending and who is receiving and with the right monitoring system – you will be able to detect that an encrypted file was sent which is interesting information in it’s own right.
Read my blog entry on this topic http://www.software.co.il/blog/2007/06/secure_communications_without_1.html