3

I'm looking for an email encryption solution for a client. They are currently using Exchange 2007 but are willing to go to a hosted solution if necessary. They are looking for a solution that will allow them to encrypt messages based on certain rules (ie., message contains certain sensitive information). They'd prefer an automatic solution to reduce the chance of sensitive data being sent unencrypted. They have no control over the client at the recipient end, so it could be outlook, yahoo, gmail, etc. I've seen some solutions that send the recipient a notification then allow the recipient to go to a site to view/download the message/attachment. Anyone have any experience with this type of solution? Appliances or hosted solutions?

Terry
  • 78
  • 4
  • Could you provide a whitelist of domains that require encryption? i.e. if sending to @sensitiveclient.com then encrypt, if @someotherclient.com, send unencrypted? – gravyface Apr 26 '11 at 22:44
  • Unfortunately, no. The customer base is dynamic and would be a logistical nightmare to keep up with. – Terry Apr 28 '11 at 00:20
  • Shopping recommendations are outside of the scope of the Stack Exchange websites (including this one). [Please ensure you are familiar with the FAQ](http://serverfault.com/faq#questions). – Mark Henderson Jan 14 '12 at 03:45

4 Answers4

4

Let me preface this with: e-mail encryption schemes suck, all of them.

S/MIME is the only widely supported method for encrypting/decrypting e-mail. It requires that both the recipient and sender have a certificates (key pairs, private and public). The sender must have the recipient's public key. It's somewhat common to simply e-mail the key over first, or have it available on a website; there is no standard way of doing it however. The sender encrypts the e-mail with the recipient's public key and authenticates it with their own private key. The recipient must have their own private key and the public key of the sender (which is typically attached to the e-mail for simplicity) to decrypt and authenticate the e-mail.

If you understand that without reading it at least 3 times, congratulations, you deserve a small award (and you're likely an IT person, not a poor user who has to try to do it every day).

Setting up rules to require encryption in Outlook isn't too hard. Actually having the above requirement satisfied so that Outlook can encrypt the e-mail, that's hard.

An alternative solution (one that we use) is to setup a portal website; protected by SSL or similar. Put the document or information on the website, then e-mail the URL to the recipient. Have them call you to get their password if you haven't established it before hand, or for extra credit use 3rd party authentication like OpenID.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • Agreed - email encryption schemes suck, as I am finding out. Given that the users on both the sending and receiving end are non-technical, I believe it's likely that they'll end up with a portal type solution. Any recommendations on commercial solutions, as opposed to home grown? – Terry Apr 28 '11 at 00:28
  • @Terry, we use SharePoint, but that's a pretty expensive solution for a simple portal. A quick Google for "Open Source Document Portal" brings up quite a few projects; home grown might not be a bad idea if you have developers with the relevant competencies already. – Chris S Apr 28 '11 at 01:37
  • Windows SharePoint Services 3.0 should do what you want and is free. – gravyface Apr 28 '11 at 02:17
  • I think the client is looking for something a little more turn key than implementing Sharepoint. Its a good thought though. – Terry May 04 '11 at 18:53
  • If they want a "simpler" solution (at least from the user's prospective) I know a few companies running Cisco's IronPort. It's basically an MTA that looks for email based on policies and automatically puts and "offending" e-mail in a sharepoint like secure web site, then sends the original recipient an e-mail notifying them of them web site. – Chris S May 04 '11 at 19:26
2

I worked on the client-side of a government-backed secure email joint venture that had similar requirements as what you've described, although implemented differently. As Chris S explains, putting the onus on encryption in the hands of the end-user rarely works.

Again as Chris S suggested, they had originally wanted to setup a secure Web-based messaging system, but the end-users and stakeholders didn't want to change processes or couldn't as they had 3rd-party applications that required SMTP/email as the transport.

What they ended up doing was setup a secure, central Mail Transfer Agent (MTA) that all participating parties used as a TLS-encrypted smarthost to route mail. This central MTA then parsed the headers of every mail message and if there was a match on destination address against a "to be encrypted" whitelist, this in turn was relayed via TLS to the destination MTA; if there was no match, mail was routed via the MX records as normal unencrypted. With proper firewall rules, there's no easy way to send plain-text messages by "mistake" so while not end-to-end encryption, the mail is encrypted in transit between trusted MTAs, and does not require the end-user to do anything to make that happen.

The system (still) works well, but obviously requires alot of coordination between the mail administrators of each participating organization.

If this kind of coordination is not possible for your situation, I'm with Chris S on this: I'd setup a secure messaging system using SSL certificates (SharePoint Services 3.0 could easily be used for this) and possibly two-factor authentication, depending on your requirements.

gravyface
  • 13,947
  • 16
  • 65
  • 100
  • I think this is more manual that the client is looking for plus, they won't be able to do TLS with Yahoo, gmail, etc. – Terry May 04 '11 at 18:54
1

I am actually currently in the middle of implementing a solution for a customer. We are using Ironport appliances. Emails are inspected by the Ironport DLP module and if they meet the criteria are encrypted. Ironport offers a variety of solutions. You can install and manage your own appliance, use a hosted appliance at their data center, or have Ironport manage appliances at your location.

The email recipient receives the message as an html attachment containing the encrypted email and some javascript which interacts with the Ironport to retrieve keys and decrypt the message. No special client or pre-shared certificates or keys are necessary.

There are a variety of similar products. We looked at solutions from ZixCorp, Axway (Secure Messenger), Google/Postini, Microsoft, and McAfee. Many of the hosted solutions require you to also use their spam/antivirus filtering services.

TimS
  • 2,136
  • 13
  • 8
  • I think this is the road that the client will end up going down. They don't want something too manual to maintain. What made you go with IronPort over ZixCorp, etc. Pricing? Features? – Terry May 04 '11 at 19:00
  • My customer is a government agency and ultimately they decided none of the hosted solutions currently met their security requirements. With Ironport they were able to have a solution in which they controlled all pieces of the solution. We are deploying C160 appliances along with Ironport Encryption Appliances to provide a local keystore rather than using the Cisco CRES service. Zix did provide an option of a local keystore. – TimS May 04 '11 at 22:30
0

You can try Djigzo open source email encryption gateway (www.djigzo.com). It's an SMTP gateway with support for S/MIME and PDF encryption and contains a DLP module which can quarantine or force encrypt your email based on the content of the email. You ready to run Virtual Appliance is available for VMware and Hyper-V and installation packages are available for Debian/Ubuntu and RedHat/CentOS.

user80226
  • 1