Re: Secure file transfers

[Alan Amesbury <amesbury () OITSEC UMN EDU>]

Theresa M Rowe wrote:

> We have a big push for using outsourced ASP/data hosting services
> here.  We have a strong policy for contract review, including a
> security review.
>
> We've been insisting on secure file transfer methods for data
> exchanges between the university and the vendor.  We've accepted VPN
> or SFTP as methods for data exchange, especially for those contracts
> where the data exchanges include confidential data (we have a state
> law in Michigan that protects certain data such as social security
> numbers and credit card numbers).  Data exposure (unauthorized
> access) of those data elements can result in a maximum $750,000 fine
> for the university.

While I, like most security practitioners, have a strong tendency to
lean towards maximum protections for data, I've also recently realized
that sometimes you just have to stick with what's good enough.  That's
where organizational policy comes in; you use it to drive your
technology decisions, not the other way around.  Your policies, drafted
in close cooperation with legal counsel, should address how different
classifications of data should be treated when in transit and when stored.

So, my question is:  For these outsourced services, what's the maximum
classification of data that's being handled, and how do your
institutional policies address its transport and storage needs?  If
you're talking about hosting pictures of squirrels that roam around your
campus, plain FTP is probably good enough.  Sure, plain text FTP
transmits EVERYTHING, including login credentials, in the clear, and
it's possible that those credentials might get intercepted in flight and
later used to deface Oakland's "Famous Squirrels from Rochester,
Michigan" web site, but admittedly the potential loss is low, and
squirrel pictures aren't legally or contractually protected (usually).

However, if you're talking about hosting data for which protection is
legally mandated (e.g., FERPA, HIPAA, or similar laws are involved),
your institutional requirements will (hopefully!) explicitly require
commensurate protection of that data.  In such a case, you're well
within the boundaries of sanity by insisting on full encryption for all
data in transit, and it might be reasonable to require encryption for
data at rest, too.

> We've been getting a push back from some vendors that "standard FTP"
> is secure enough.  We've been saying it isn't good enough.

Maybe the vendor is willing to put its money where its mouth is, and
accept legal liability in writing for any breach that might occur?  I
mean, if plain text is good enough, then they're not really assuming any
more potential liability by accepting such terms, are they?

> I am checking in on best practice.  I'd appreciate your thoughts on
> this.

Our policies are clear.  Quoting from

        http://www1.umn.edu/oit/security/privatedata.html


"private data" is defined as "legally and contractually protected
non-public University data and data which the University is obliged to
treat as confidential whether it is research, clinical, educational,
outreach, or administrative data....."  When in transit "across the
Internet (external to the University's network)  or other open networks
such as wireless connections, both the authentication data (e.g. a
userid and password) and the data itself must be encrypted with strong
encryption."


--
Alan Amesbury
OIT Security and Assurance
University of Minnesota