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"


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to