Educause Security Discussion mailing list archives
Re: Mobile Data - Protecting the University from unnecessary risk
From: "Buskill, Bruce M" <bbuskill () RADFORD EDU>
Date: Tue, 11 May 2010 08:03:48 -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">Consider Randy's caveats about OFTE as likely applying to just about all deployable "database encryption" solutions, as well.<br> <br> That's clearly true for "transparent" encryption, eg Oracle TDE, which decrypts the database at startup.<br> <br> I think there's a *lot* of "encryption" solutions which are only protecting against a limited set of media loss solutions. TDE, for example, does nothing against SQLi attacks, which point seems to be glossed over in a lot of discussion, particularly in the EHR/EHI (electronic health records) domain.<br> <br> -jml<br> <br> <br> -----Original Message-----<br> From: randy marchany<br> Sent: 2010-05-10 21:05:58<br> To: randy marchany;The EDUCAUSE Security Constituent Group Listserv<br> Cc: <br> Subject: Re: [SECURITY] Mobile Data - Protecting the University from unnecessary risk<br> <br> <br> 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 "sensitive data" 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 "sensitive data". 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 "Sensitve data". 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> a. single user/single folder - the user puts all of the sensitive<br> data files in a single folder/directory.<br> b. multiple user/one person with write access - multiple people<br> access the sensitive data folder in Read mode. Only one person<br> has write access to the file or folder.<br> c. multiple user/multiple people with write access to files in a<br> folder - most common environment for offices that handle sensitive<br> data (Controller's office, HR, Registrar, Grad School, Admissions, etc.).<br> d. Email attachments to internal users - using wide variety of email<br> systems (Exchange, Imap, Gmail, etc.). Some solutions are<br> effective in this case where you send an email to another<br> internal (to your EDU) user.<br> e. Email attachments to external users - we all have to send<br> sensitive data to external agencies. They may NOT support your<br> encryption schemes. For example, we probably have to send reports<br> to the Feds, state or NCAA regulatory agencies.<br> Institutional research groups, athletic associations within our<br> EDUs are prime users of this function, I suspect.<br> <br> 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 "cost-effective" in the EDU environment.<br> The key phrase is "cost effective". 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 "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. "On-the-fly" 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 "On-the-fly" upon file access (not at rest). So<br> once booted, ANYONE WITH READ ACCESS may read (decrypt) the files."<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 "decrypted" 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 & Lab<br> </div></font> </body> </html> Sent from my Android phone using TouchDown (www.nitrodesk.com)
Current thread:
- Mobile Data - Protecting the University from unnecessary risk Todd Britton (May 10)
- <Possible follow-ups>
- Re: Mobile Data - Protecting the University from unnecessary risk SCHALIP, MICHAEL (May 10)
- Re: Mobile Data - Protecting the University from unnecessary risk randy marchany (May 10)
- Re: Mobile Data - Protecting the University from unnecessary risk John Ladwig (May 10)
- Re: Mobile Data - Protecting the University from unnecessary risk Valdis Kletnieks (May 10)
- Re: Mobile Data - Protecting the University from unnecessary risk Joel Rosenblatt (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Stephen C. Gay (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Buskill, Bruce M (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Buskill, Bruce M (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Buskill, Bruce M (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Buskill, Bruce M (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Buskill, Bruce M (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Ken Connelly (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Matthew Gracie (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Bradley, Stephen W. Mr. (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk David Bowie (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Buskill, Bruce M (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Buskill, Bruce M (May 11)
- Re: Mobile Data - Protecting the University from unnecessary risk Morrow Long (May 11)