Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

To comply with Massachusetts's new personal information protection law, my company needs to (among other things) ensure that anytime personal information is sent via email, it's encrypted. What is the easiest way to do this? Basically, I'm looking for something that will require the least amount of effort on the part of the recipient. If at all possible, I really want to avoid them having to download a program or go through any steps to generate a key pair, etc. So command-line GPG-type stuff is not an option. We use Exchange Server and Outlook 2007 as our email system.

Is there a program that we can use to easily encrypt an email and then fax or call the recipient with a key? (Or maybe our email can include a link to our website containing our public key, that the recipient can download to decrypt the mail?) We won't have to send many of these encrypted emails, but the people who will be sending them will not be particularly technical, so I want it to be as easy as possible. Any recs for good programs would be great. Thanks.

share|improve this question
1  
Pig-latin. Don't need to install anything for that ;-) –  Bart Silverstrim May 17 '10 at 13:23
    
A public key belongs to the recipient and the sender uses it to encrypt a message. The recipient uses their private key to decrypt it. If it worked the other way as you describe, then anyone could download the key and decrypt any message. If you're going to call or fax, why not just "transmit" the data that way? –  Dennis Williamson May 17 '10 at 14:03
    
Yeah, I got my public/private switched up; typing too fast. I'm trying to figure out a solution that will work with the existing workflows in the company, in which HR routinely emails things back and forth to new employees, insurance companies, etc. The fax/call idea is probably not a good option either way. –  johnnyb10 May 17 '10 at 14:19

7 Answers 7

up vote 12 down vote accepted

We've had to go through something similar with our clients for PCI. The best way would be to use some version of PGP/GPG.

Now that being said, it really isn't as painful as you think. We have done this with hundreds of non technical users. What we did was choose two products - the free GPG (which Kronick states have GUI front-ends) as well as the pay for PGP software. We wrote up some really good documentation that could be sent to our clients instructing them how to use the software that they chose as well as trained our Account Managers on basic troubleshooting and how to use the software.

That has kept 95% of the issues that clients run into out of the IT queue. For the other 5% we made IT resources available to answer questions, as well as in the worst case get on a call to help the client out.


As an alternative we also bought some licenses of winzip so that we could use the built in AES encryption with a pass phrase. The commercial PGP software has the ability to create an encrypted file that is opened by passphrase only as well. Although honestly using PGP has worked out so well i think i only create these types of files 2 or 3 times a year.

share|improve this answer
    
Thanks, this is great info--products to check out as well as some info about your experience. I'm downloading GPG4win and am going to check that out first. –  johnnyb10 May 17 '10 at 14:27
    
Using any sort of end user option opens you up to liability, unlike PCI the law requires you to be on the hook for any reasonable issues (like joe user not using the technology) –  Jim B May 17 '10 at 15:00
    
@Jim B: using pgp if the user doesn't give you a key, you don't send to them. Basically they are forced to use it - in this use case - otherwise they either A) Don't get the data or B) can't read the data. –  Zypher May 17 '10 at 15:08
    
@zypher- how can you ensure that every user sending the data will encrypt every email? Just like an SMIME solution you must choose to encrypt your email it can't be forced - or am I missing something? –  Jim B May 17 '10 at 15:31
    
@Jim B: It's pretty simple, if you send an email containing information that needs to be encrypted without encrypting it, your fired for cause (in at will states this means no unemployment). Not everything needs to be a technical solution. From the question this won't be done too often so a more involved solution probably isn't worth the cost/benefit. If they needed to do this all day every day i would advocate not using email at all, and moving to online forms over SSL. –  Zypher May 17 '10 at 15:54

Wouldn't it be easier to have them check a website with the data encrypted via SSL, with a button to print the data on their end? That way you're not transmitting anything and you're in control of the dissemination of the data.

Anything with email will likely be too difficult for your users; they'll involve key generation or downloading a keyring or other things users will find to be a hassle or confusing. Your support costs will rocket up, unless the users just give up in frustration.

share|improve this answer
    
Thanks, that sounds like a good solution long-term; our company is slowly experimenting with and gradually rolling out SharePoint as a tool for communication with our clients and vendors; having people download stuff through a secure SharePoint site will probably be a big part of that, eventually. For now, I need to figure out a more immediate fix for HR people, who email forms back and forth containing personal info like SSNs. –  johnnyb10 May 17 '10 at 14:17
    
I don't know what your actual requirements under that law are, but if it's just forms, would using ZIP turning it into a self-extracting EXE file work (with the password set on the EXE)? I know some filters block them, but self-extractors are very simple to use and don't require installers. Even then, you could host them on an internal site and email links via email for users to download them (and give them the password/passphrase via trusted channels). –  Bart Silverstrim May 17 '10 at 14:29
    
Some of this depends on the channels you're using to transfer/host the data. If this is internal, using password-protected zips would probably be okay, but if you're doing this to public-access, that complicates things as there are zip password breakers out there. –  Bart Silverstrim May 17 '10 at 14:30
    
Now I'm thinking that encrypted zips might be the way to go. I just downloaded PGP4win and went through the PGP4win for Novices tutorial, and it requires far too much work for the recipient (in my opinion). I want the recipient to be able to type in a password and be done with it. –  johnnyb10 May 17 '10 at 14:45

Does it just need to be encrypted in transit (SMTP/TLS), or in storage/at the endpoints too (PGP, etc.)?

Working with similar legislations, I've generally setup PKI/SMTP/TLS between two or more organizations that frequently send/receive private/protected information; I just setup a smarthost at each organization matching the domains in question to route mail through either a site-to-site VPN tunnel when applicable or used SMTP/TLS to encrypt the mail in transit with Exchange.

share|improve this answer
    
According to the MA law, it's only the transmission that needs to be encrypted. It specifies "encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly." –  johnnyb10 May 17 '10 at 14:22
    
Then like I suggested, depending on the relationship(s) between organizations, I've either setup site-to-site VPN tunnels (with as restrictive tunneling rules as required; they also did some collaboration so the tunnel was the best option) or setup TLS in Exchange with certificates to encrypt the mail in transit. There's a good article on doing this in Exchange 2000/2003 from the MS Exchange Team Blog (msexchangeteam.com/archive/2006/10/04/429090.aspx) –  gravyface May 17 '10 at 14:45
    
+1 as enabling encryption at the server level is going to be far more reliable than relying on end users to remember to encrypt stuff when necessary. It might be your policy to fire end users who fail to encrypt necessary data but if they expose information they shouldn't have, firing them won't appease the regulation Gods - your company is still on the hook. –  icky3000 May 18 '10 at 6:15

You should take a look at Secure Messaging with S/MIME and OWA on Exchange Server 2007 SP1 If you want to encrypt the message. This solution also requires an extra step as the users must select the encrypt button (it's also probably not legal as you have to somehow assume that all of you users would never make a mistake and not encrypt an email that they should have.) Otherwise all you need to do is ensure that the destinations that you want to send Massachusetts PII are using TLS (you are required to have that information as you must vet everyone you might send Mass.PII to as per CMR 17.04). You should also probably write a transport rule that uses a regex to search for Mass PII. Massachusetts PII is defined as a combination of a resident's first and last name connected to one of the following: A driver's license number, a credit card number, or a Social Security number. You might want to BCC those messages for follow up in another mailbox or simply keep a count.

Off-topic but germaine...

Note for those reading this and thinking you are lucky not to live in MA, Suprise! If you store the personal information of a Massachusetts resident, regardless of whether or not you have a business presence in Massachusetts, you are subject to penalties set forth in 201 CMR 17.00. which could cost $100 record lost, with a maximum of $50K per "incident". MA General Law 93H states that there will be a $5,000 fine per "violation." What exactly does that mean? I don't think anyone knows and won't until someone gets hit with it.

It's important to note that this isn't an easy topic- here is the conent of a discussion between myself and Zypher about his answer:

me: Using any sort of end user option opens you up to liability, unlike PCI the law requires you to be on the hook for any reasonable issues (like joe user not using the technology)

Zypher: using pgp if the user doesn't give you a key, you don't send to them. Basically they are forced to use it - in this use case - otherwise they either A) Don't get the data or B) can't read the data.

me: how can you ensure that every user sending the data will encrypt every email? Just like an SMIME solution you must choose to encrypt your email it can't be forced - or am I missing something?

Zypher: It's pretty simple, if you send an email containing information that needs to be encrypted without encrypting it, your fired for cause (in at will states this means no unemployment). Not everything needs to be a technical solution. From the question this won't be done too often so a more involved solution probably isn't worth the cost/benefit. If they needed to do this all day every day i would advocate not using email at all, and moving to online forms over SSL.

me: IANAL - but I am stuck listening to them, the law is effectivly stating it has to be a techinical solution- "but I had a policy" is de facto evidence that one of those "reasonably foreseable" issues you are supposed to mitigate wasn't mitigated. Disciplining violators is also part of the law already. Take a look at this discussion informationweek.com/blog/main/archives/2009/02/…

Zypher: Actually if you read 17.03.2.b (here:mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf) I have a policy and trained my people on it, as well as having disciplinary measures is actually perfectly defensible. In fact the only mention of a technical solution is for preventing terminated employees from accessing records. IAANAL (I Am Also Not A Lawyer).

me:- 1,2,3 are simply things that are expected to be included not definitive solutions, 2b is the specific wording that applies (I cheated and asked a lawyer). If you have to say "I can defend that" the courts will probably crush you. With compliance issues you have to prove you are following the regs. The regs specifically say "foreseable". If you stand up in court and say "well if someone broke the policy they'd get fired" prosecution is simply going to say "So you admit that you foresaw a way for this policy to be violated, and took no reasonable measures to remove the issue?"

Zypher: Damn you for cheating. Well now we have to define reasonable as well, reasonable for my company (large multi-national w/ 100k+ employees) is not the same as for a mom and pop shop. But on that same token I think we are getting too far away from the Q&A mandate of the site... which is unfortunate because this discussion has provided some good insight.

me: it's "reasonably foreseable" not "reasonably secure" or even reasonable to implement. Remember that legally, using rot13 on the persons names and nothing else follows the standard becuase that is a form of encryption. This discussion is usefull so I'll edit my answer to include it so it's not lost.

share|improve this answer

GPG have utilities for windows and plugins for email client (mainly outlook and eudora) : http://openpgp.vie-privee.org/gnupg-win.htm It'll suite your needs I hope since you only have to right click and "encrypt", no CLI required :)

share|improve this answer
    
you can try also this one www3.gdata.de/gpg/download.html –  Razique May 17 '10 at 13:22
    
gpg4win.org - The official GNUPG windows front end. Has an outlook plugin as part of the package. –  Zypher May 17 '10 at 13:37
    
Thanks, very helpful! –  johnnyb10 May 17 '10 at 14:27

You could try the Djigzo email encryption gateway (disclaimer: I'm the author of Djigzo). Djigzo Email Encryption Gateway is an open source centrally managed email server (MTA) based on open source standards that encrypts and decrypts your incoming and outgoing email at the gateway level. Djigzo Email Encryption Gateway currently supports two encryption standards: S/MIME and PDF encrypted email. S/MIME provides authentication, message integrity and non-repudiation (using X.509 certificates) and protection against message interception. S/MIME uses public key encryption (PKI) for encryption and signing. PDF encryption can be used as a lightweight alternative to S/MIME encryption. PDF allows you to decrypt and read encrypted PDF documents. PDF documents can even contain attachments embedded within the encrypted PDF. The password for the PDF can be manually set per recipient or a password can be randomly generated and sent to the recipient via a SMS Text message.

Djigzo Email Encryption Gateway has a built-in CA which you can use to issue X.509 certificates for internal and external users. The external user can use the certificate with any S/MIME capable email client like Outlook, Outlook express, Lotus Notes, Thunderbird, Gmail etc.

Because Djigzo Email Encryption Gateway functions as a general SMTP email server, it is compatible with existing email infrastructures like Microsoft Exchange and Lotus Notes. Djigzo can be installed using one of the provided packages for Ubuntu Linux, Debian, Red Hat and CentOS. A ready to run "Virtual Appliance" for VMware ESX and Workstation is available.

Because it's open source it can be freely used. Sources and binary packages can be downloaded from our website (www.djigzo.com).

share|improve this answer
    
I just set up Djigzo yesterday. With Ubuntu 12.04, it was really easy (had issues with 12.10). It's intended for use as an encryption gateway, and it works very well. But it was pretty simple to integrate it with an existing Postfix server, so there's no need for a separate server to host the encryption gateway if you're already using Postfix. –  David Jan 24 '13 at 14:51

Actually, the law says to encrypt the senstive data, not necessarily the message. If the data is a file (and usaully it is), the easiest by far method is to just encrypt the file.

Assuming your goal is an extremely easy to use and deploy solution that'll work across your diverse customer base....

The US Air Force Research Lab's Encryption Wizard (http://spi.dod.mil/ewizard.htm) is free, DoD accredited, simple file encryptor. It handles passwords, smartcards, and certificates. Its Secure Delete can wipe the senstive file from a public computer.

Other than having Java, there is nothing to install or configure on either computer - just run the .jar file. Encryption Wizard runs on Mac, Windows, Linux, Sun, and other OS that run Oracle Java.

With EW, from zero you can encrypt and send a file w/in a minute and the recipent can decrypt in the same amount of time (assuming you use a certificate or call the person w/ the password.)

There are better big, intra-enterprise solutions but we've come across nothing better that can works for pretty much everyone everywhere at anytime.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.