Re: Secure File and Email Transfer

[Jesse Thompson <jesse.thompson () DOIT WISC EDU>]

Clark, Sean wrote:
> TLS (Transport Layer Security) may also be a good option for
> gateway-to-gateway email encryption, depending on the receiving
> institutions ability to implement TLS on their end.  We originally setup
> TLS to ensure a secure connection between researchers at our university
> and a drug company.  After we setup TLS and configured our mail gateways
> to preferentially use TLS for mail transfer (ie when the other mail
> server was TLS-enabled), we found that quite a bit of our email traffic
> to other institutions was being encrypted.  TLS is supported by
> Sendmail, Postfix, Exchange -- and Ironport.
> ;)

Hmm, we see only 7% of external mail servers will do STARTTLS with our
servers.  It would be cool if they all did it so that we could require
it for all traffic.  But we're still in the position of making it
optional by default and manually requiring it for a few domains of our
choosing.

To answer the original question... I guess it depends on how you want to
secure the files and who you want to be able to access them.  Do you
intend to just secure files in transit, or on the desktop?  Do you want
to prevent users from sending files over email insecurely?

For securing files in transit *and* on the desktop, you will need a PKI.
 It is expensive and won't work with another domain that does not have a
PKI.

Using TLS might work for securing files in transit over email on campus
since you might be able to mandate TLS be supported on all campus mail
servers.  But you can't mandate remote domains support TLS unless you're
willing to cut off communication with 93% (?) of the world.

We offer a Xythos service that works well for uploading and sharing
files securely (https) on and off campus.  There are many other services
(in-house or 3rd party) that you can choose from to meet your needs.  Of
course, you can't mandate usage of these services.

I presume that there's software out there that will strip attachments at
the email gateway and upload to a web-based service.  If they exist I
don't know how well they work, and I can think of some drawbacks to that
approach.

Jesse
UW-Madison


> Sean Clark
> Manager, IT Security/Email/UNIX Systems
> UCDenver IT Services
> Sean.Clark () UCDenver edu
> 303-724-0486
> **Please note my new email address!**
>
>
> ------------------------------------------------------------------------
> *From:* The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Daniel Bennett
> *Sent:* Wednesday, November 12, 2008 6:56 AM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* [SECURITY] Secure File and Email Transfer
>
> Hello All,
>
>
>
> I am conducting some research to determine the route that other
> universities are taking in securing files/emails when needed.  I have
> found three solutions and I am wondering which of them other
> universities are implementing or if they are using other methods.
>
>
>
> The three are:
>
> 1.       Public Key Infrastructure, issuing public/private keys to all
> employees.  This is time consuming and requires key exchanges.  I find
> this to require lots of time which translates into money to maintain and
> support.
>
> 2.       Third party mediator.  This is where an institution sends a
> file/email to a third party over a secure channel.  Then the receiver is
> told by the third party that a file/email is waiting and they log into a
> site to download/view through a secure https connection.
>
> 3.       Use secure ftp.  Setup a secure ftp server and give vendors a
> username and password and they are notified when something is waiting
> for them.
>
>
>
> Any insight would be appreciated.
>
>
>
> Thank You,
>
>
>
> *Daniel R. Bennett*
>
> *Pennsylvania College of Technology*
>
> *IT Security Analyst*
>
> CompTIA Security+
>
> 570.329.4989

--
  Jesse Thompson
  Division of Information Technology, University of Wisconsin-Madison
  Email/IM: jesse.thompson () doit wisc edu

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature