All suggestions are giving me a good array of options...unfortunately I am dealing with the much-maligned UK public sector here. They don't even seem inclined to answer my emails asking what sort of email system they are running. Their attitude usually is "our policy says we do things this way, either accept it, or tough". Even when the policy itself is completely self-defeating.
I'm keen to offer them some of these options, but if they don't want to talk to me, I'm kind of stumped. TLS (if possible) or some other form of archive protection seems the best idea to me, I think. On 12 May 2010 15:00, Phillip Partipilo <[email protected]> wrote: > 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]> > Date: 12 May 2010 10:49 > Subject: FW: Encrypted files. > To: "[email protected]" <[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" > > > > > > > > > > > > -- "On two occasions...I have been asked, 'Pray, Mr Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
