Educause Security Discussion mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Mobile Data - Protecting the University from unnecessary risk

From: "Buskill, Bruce M" <bbuskill () RADFORD EDU>
Date: Tue, 11 May 2010 08:03:46 -0400
<html><head><meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style></head>
<body>
<font size="2"><div class="PlainText">For all of us, the problem is well defined. However, we need to be<br>
careful to avoid common security solution pitfalls. Typically, the<br>
sensitive data problem can be broken down into these phases.<br>
<br>
1. Define Sensitive Data. Protect &quot;sensitive data&quot; as defined by our<br>
local policies. Things like SSN, CCN, Driver's license #'s, Bank<br>
account #'s, Passport #'s, FERPA/HIPAA/GLB protect data items are<br>
generally agreed to be &quot;sensitive data&quot;. We can use NIST, PCI,<br>
Educause and other guidelines to help us define sensitive data but for<br>
the most part, the aforementioned items will be a good subset of these<br>
sensitive data definitions.<br>
<br>
2. Find the &quot;Sensitve data&quot;.&nbsp; Where is sensitive data likely to be<br>
stored? Do you know where all of your servers on your campus network<br>
are? Database servers (Oracle, MySql, Postgres, MSSQL, Filemaker Pro),<br>
www servers if not properly designed, end user systems<br>
(desktop/laptops), mobile devices (USB, CD, Backup media, smart<br>
phones, lpads, etc.) are likely storage places. Use commercial tools<br>
like IdentityFinder or freeware tools like Cornell's Spider, our<br>
Find_SSN, UT-Austin's SENF. Realize that these tools may not find ALL<br>
of the sensitive defined in step 1. But it is a good start. The<br>
resistance to using these tools is the complaint that it a) generates<br>
lots of false positives b) requires the user to examine all of these<br>
files c) tells the user or sysadmins what they don't want to know.<br>
Some of these tools will not run on all 3 of the common platforms<br>
(Windows, Mac, Unix/linux). Most big DB servers are Unix/linux based.<br>
<br>
3. Beware making a distinction about where the sensitive data is<br>
stored. Who cares whether it's stored on a mobile device or DB server?<br>
The problem is still there -- it must be protected at rest and in<br>
transit. A flat out statement saying ANY sensitive data must be<br>
protected regardless of WHERE it's stored simplifies the enforcement<br>
mechanism of our sensitive data standards.<br>
<br>
4. How is sensitive data used? It's absolutely critical for security<br>
officers and policy writers to understand the business processes that<br>
use sensitive data. Protection solutions must be tailored to address<br>
these processes. Some of the ways we've discovered sensitive data is<br>
used include:<br>
&nbsp;a. single user/single folder - the user puts all of the sensitive<br>
data files in a single folder/directory.<br>
&nbsp;b. multiple user/one person with write access - multiple people<br>
access the sensitive data folder in Read mode. Only one person<br>
&nbsp;&nbsp;&nbsp;&nbsp; has write access to the file or folder.<br>
&nbsp;c. multiple user/multiple people with write access to files in a<br>
folder - most common environment for offices that handle sensitive<br>
&nbsp;&nbsp;&nbsp;&nbsp; data (Controller's office, HR, Registrar, Grad School, Admissions, etc.).<br>
&nbsp;d. Email attachments to internal users - using wide variety of email<br>
systems (Exchange, Imap, Gmail, etc.). Some solutions are<br>
&nbsp;&nbsp;&nbsp;&nbsp; effective in this case where you send an email to another<br>
internal (to your EDU) user.<br>
&nbsp;e. Email attachments to external users - we all have to send<br>
sensitive data to external agencies. They may NOT support your<br>
&nbsp;&nbsp;&nbsp;&nbsp; encryption schemes. For example, we probably have to send reports<br>
to the Feds, state or NCAA regulatory agencies.<br>
&nbsp;&nbsp;&nbsp;&nbsp; Institutional research groups, athletic associations within our<br>
EDUs are prime users of this function, I suspect.<br>
<br>
&nbsp;Encrypting email attachments is a critical task.<br>
<br>
5. Encryption is the catch-all method for protecting sensitive data.<br>
In our research over the past 2 years, we've found NO enterprise wide<br>
encryption solution that is &quot;cost-effective&quot; in the EDU environment.<br>
The key phrase is &quot;cost effective&quot;. There are commercial solutions<br>
that address a segment but they are expensive the more licenses have<br>
to be granted. There are solutions that work well in the Windows world<br>
but not the Mac or Unix/linux world. Some people want to say you can<br>
only use Windows systems to store sensitive data. What about the big<br>
enterprise DB server? I've heard people talk about whole<br>
disk encryption (on-the-fly encryption aka OTFE) as solutions.<br>
However, we need to fully understand how OTFE works.<br>
<br>
Tools like Bitlocker, GuardianEdge and Truecrypt's whole disk<br>
encryption option were some of the items<br>
mentioned to us as a control for securing data at rest. A number of<br>
you have told me that Full Disk Encryption satisfies the at-rest part<br>
of your standard. Beware the sense of false security full disk<br>
encryption may bring.<br>
<br>
1. Full disk encryption (FDE) schemes such as Bitlocker and True Crypt<br>
use on-the-fly encryption techniques to encrypt the disk. A friend of<br>
mine describes OTFE as &quot;On-the-fly encryption (OTFE), also known as<br>
Real-time Encryption, is a method used by some encryption programs,<br>
for example, disk encryption software. &quot;On-the-fly&quot; refers to the fact<br>
that the files are accessible *immediately after the key is provided*<br>
and in the case of FDE encryption, the key is provided at boot. While<br>
the files on disk are still encrypted at rest, the keys are in memory<br>
and decryption occurs &quot;On-the-fly&quot; upon file access (not at rest). So<br>
once booted, ANYONE WITH READ ACCESS may read (decrypt) the files.&quot;<br>
This is the critical piece.<br>
<br>
2. This is significant in that as long as the system is booted up,<br>
your files are encrypted UNTIL they are accessed by a userid or<br>
process owned by a userid that has READ access to the files in<br>
question. World read access allows any userid to decrypt the file. A<br>
process running under your userid's privileges can decrypt any file<br>
you have read access and any malware running under your userid has<br>
that same access.<br>
<br>
3. Even if you are running OTFE of some sort, you should use an<br>
additional encryption scheme like Truecrypt, PGP, GPG, or some other<br>
system like RMS. Decrypt the file and folder only when you need to<br>
access it. Yes, all we're doing is reducing the &quot;decrypted&quot; window but<br>
this window is MUCH smaller than the one for OTFE-only systems.<br>
<br>
4. Regardless of which encryption scheme you use, you should still run<br>
Find_SSN/CCN, IdentityFinder or any of the other sensitive data search<br>
tools frequently on your systems. Whole disk encryption should never<br>
be used as a reason for not running these tools on your system. You<br>
need to know exactly where all sensitive data is located<br>
<br>
5. Full disk encryption does nothing to stop malware, viruses or<br>
trojan software from reading your files. After boot, if I have read<br>
access to your files, I have the files.<br>
<br>
Is protecting our sensitive data an intractable problem? Given the<br>
cost of enterprise wide solutions, it may be. It might be time for the<br>
EDU community to band together as a consumer group seeking an<br>
enterprise wide solution.<br>
<br>
I now put on my flame retardant suit.<br>
<br>
Randy Marchany<br>
University IT Security Officer<br>
VA Tech IT Security Officer &amp; Lab<br>
</div></font>
</body>
</html>


Sent from my Android phone using TouchDown (www.nitrodesk.com)
Previous By Date Next
Previous By Thread Next

Current thread: