S/MIME is one method. It's kind of a PITA, having to do a certificate exchange, and then sometimes Outlook just doesn't want to cooperate. How about a password protected 7-zip archive with AES-256 encryption? The price is right.
Phillip Partipilo Parametric Solutions Inc. Jupiter, Florida (561) 747-6107 From: Alan Davies [mailto:[email protected]] Sent: Wednesday, May 12, 2010 6:09 AM To: NT System Admin Issues Subject: RE: FW: Encrypted files. Via email .. S/MIME is the easiest for users to understand and certificates are cheap. No admin needed at all. Weakness is that it's only encrypted as far as the mailbox, so the user would be prone to saving it unencrypted to a file share (may not be an issue at all). Weaker than that, and a good complimentary measure, is TLS between mail servers to ensure confidentiality of transmission, even when they "forget" to encrypt the file. Aside from that, HTTPS portals are good. We'd do a basic security evaluation of the portal in question and potentially allow access to that. Or host it the other way around from our own portal. With PGP and self-decrypting archives (the SDA .exe bother ..!) we don't find it an easy solution. PGP confuses basic users at the best of times and having to unzip (as .exe is blocked by most gateways and also by nearly all email clients), then unencrypt a file really does their heads in! With keys, it's much better, but you still have an initial learning curve. alan ________________________________ From: James Rankin [mailto:[email protected]] Sent: 12 May 2010 10:57 To: NT System Admin Issues Subject: Fwd: FW: Encrypted files. I received the email below from a public sector entity we work with, who are maintaining that for "security reasons" they now send out certain documents as encrypted .exe files, which they expect our users to unpack themselves. Notwithstanding that a) the IronPort isn't particularly keen on letting executable attachments through, b) our Application Management solution won't execute anything that isn't owned by Administrators, and c) our whitelist GPO won't execute anything that doesn't match one of its hash rules, this sort of approach seems a little, well, archaic to me. The best bit is, they are sending the password for the encrypted executable to our users via a plain-text, unencrypted email, so the security is more or less worthless anyway. My question is, how do other people handle transmission of encrypted data to users who work in a locked-down environment? We use the IronPort's built-in encryption features to handle our user's requirements to send sensitive data, but I'm looking for something to work the other way. I can only assume there are far better ways than sending out executable files via email, so I am looking for some real-world solutions. I *could* ratchet down our end-user security to allow these through, but I'd sooner propose something else that allows me to keep it in place. TIA, JRR ---------- Forwarded message ---------- From: James Rankin <[email protected]<mailto:[email protected]>> Date: 12 May 2010 10:49 Subject: FW: Encrypted files. To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> I understand from xxx that there has been a request from xxxxxxxxxxx that the landlord schedules are not sent as .exe files, unfortunately we are unable to send any information out externally relating to xxxxxxxxxxxxxxxxxxxx unless it has been encrypted. This is xxxxxxxxxxx policy I'm afraid, we did used to zip the files and password protect them but this has been deemed not secure enough. Apologies for any inconvenience this may cause to yourselves when you receive the file but as stated previously the current way we send the files is now standard xxxxxx practice. Thanks. ************************************************************************************ WARNING: The information in this email and any attachments is confidential and may be legally privileged. If you are not the named addressee, you must not use, copy or disclose this email (including any attachments) or the information in it save to the named addressee nor take any action in reliance on it. If you receive this email or any attachments in error, please notify the sender immediately and then delete the same and any copies. "CLS Services Ltd × Registered in England No 4132704 × Registered Office: Exchange Tower × One Harbour Exchange Square × London E14 9GE" ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
