Securing Sensitive Data Issues

For all of us, the problem is well defined. We need to protect sensitive data that is stored on our IT devices. However, we need to be careful to avoid common security solution pitfalls. Typically, the sensitive data problem can be broken down into these phases.

Sensitive Data Protection Strategy

1. Define Sensitive Data. Protect "sensitive data" as defined by our
local policies. Things like SSN, CCN, Driver's license #'s, Bank
account #'s, Passport #'s, FERPA/HIPAA/GLB protected data items are
generally agreed to be "sensitive data". We can use NIST, PCI,
Educause and other guidelines to help us define sensitive data but for
the most part, the aforementioned items will be a good subset of these
sensitive data definitions.

2. Find the "Sensitive data". Where is sensitive data likely to be
stored? Do you know where all of your servers on your campus network
are? Database servers (Oracle, MySql, Postgres, MSSQL, Filemaker Pro),
www servers if not properly designed and configured, end user systems
(desktop/laptops), mobile devices (USB, CD, Backup media, smart
phones, lpads, etc.) are likely storage places. Use commercial tools
like IdentityFinder or freeware tools like Cornell's Spider, our
Find_SSN, UT-Austin's SENF. Realize that these tools may not find ALL
of the sensitive defined in step 1. But it is a good start. The
resistance to using these tools is the complaint that it a) generates
lots of false positives b) requires the user to examine all of these
files c) tells the user or sysadmins what they don't want to know.
Some of these tools will not run on all 3 of the common platforms
(Windows, Mac, Unix/linux). Most big DB servers are Unix/linux based.

3. Beware making a distinction about where the sensitive data is
stored. Who cares whether it's stored on a mobile device or DB server?
The problem is still there -- it must be protected at rest and in
transit. A flat out statement saying ANY sensitive data must be
protected regardless of WHERE it's stored simplifies the enforcement
mechanism of our sensitive data standards. Having said that, mobile
devices like smart phones introduce a whole new set of issues for
safeguarding email attachments sent to them.

4. How is sensitive data used? It's absolutely critical for security
officers and policy writers to understand the business processes that
use sensitive data. Protection solutions must be tailored to address
these processes. Some of the ways we've discovered sensitive data is
used include:
a. single user/single folder - the user puts all of the sensitive
data files in a single folder/directory.
b. multiple user/one person with write access - multiple people
access the sensitive data folder in Read mode. Only one person
has write access to the file or folder.
c. multiple user/multiple people with write access to files in a
folder - most common environment for offices that handle sensitive
data (Controller's office, HR, Registrar, Grad School, Admissions, etc.).
d. Email attachments to internal users - using wide variety of email
systems (Exchange, Imap, Gmail, etc.). Some solutions are
effective in this case where you send an email to another
internal (to your EDU) user.
e. Email attachments to external users - we all have to send
sensitive data to external agencies. They may NOT support your
encryption schemes. For example, we probably have to send reports
to the Feds, state or NCAA regulatory agencies.
Institutional research groups, athletic associations within our
EDUs are prime users of this function, I suspect.

Encrypting email attachments is a critical task.

5. Encryption is the catch-all method for protecting sensitive data.
In our research over the past 2 years, we've found NO enterprise wide
encryption solution that is "cost-effective" in the EDU environment.
The key phrase is "cost effective". There are commercial solutions
that address a segment but they are expensive the more licenses have
to be granted. There are solutions that work well in the Windows world
but not the Mac or Unix/linux world. Some people want to say you can
only use Windows systems to store sensitive data. What about the big
enterprise DB server? I've heard people talk about whole
disk encryption (on-the-fly encryption aka OTFE) as solutions.
However, we need to fully understand how OTFE works.

OTFE (Whole Disk Encryption) Issues

Tools like Bitlocker, GuardianEdge and Truecrypt's whole disk
encryption option were some of the items mentioned to us as a
control for securing data at rest. A number of you have told me
that Full Disk Encryption satisfies the at-rest part of your standard.
Beware the sense of false security full disk encryption may bring.

1. Full disk encryption (FDE) schemes such as Bitlocker and True Crypt
use on-the-fly encryption techniques to encrypt the disk. A friend of
mine describes OTFE as "On-the-fly encryption (OTFE), also known as
Real-time Encryption, is a method used by some encryption programs,
for example, disk encryption software. "On-the-fly" refers to the fact
that the files are accessible *immediately after the key is provided*
and in the case of FDE encryption, the key is provided at boot. While
the files on disk are still encrypted at rest, the keys are in memory
and decryption occurs "On-the-fly" upon file access (not at rest). So
once booted, ANYONE WITH READ ACCESS may read (decrypt) the files."
This is the critical piece.

2. This is significant in that as long as the system is booted up,
your files are encrypted UNTIL they are accessed by a userid or
process owned by a userid that has READ access to the files in
question. World read access allows any userid to decrypt the file. A
process running under your userid's privileges can decrypt any file
you have read access and any malware running under your userid has
that same access.

3. Even if you are running OTFE of some sort, you should use an
additional encryption scheme like Truecrypt, PGP, GPG, or some other
system like RMS. Decrypt the file and folder only when you need to
access it. Yes, all we're doing is reducing the "decrypted" window but
this window is MUCH smaller than the one for OTFE-only systems.

4. Regardless of which encryption scheme you use, you should still run
Find_SSN/CCN, IdentityFinder or any of the other sensitive data search
tools frequently on your systems. Whole disk encryption should never
be used as a reason for not running these tools on your system. You
need to know exactly where all sensitive data is located

5. Full disk encryption does nothing to stop malware, viruses or
trojan software from reading your files. After boot, if I have read
access to your files, I have the files.

Is protecting our sensitive data an intractable problem? Given the
cost of enterprise wide solutions, it may be. It might be time for the
EDU community to band together as a consumer group seeking an
enterprise wide solution.

-rcm, 5/11/2010