Educause Security Discussion mailing list archives
Re: Mobile Data - Protecting the University from unnecessary risk
From: John Ladwig <John.Ladwig () CSU MNSCU EDU>
Date: Mon, 10 May 2010 21:22:01 -0500
Consider Randy's caveats about OFTE as likely applying to just about all deployable "database encryption" solutions, as well. That's clearly true for "transparent" encryption, eg Oracle TDE, which decrypts the database at startup. 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. -jml -----Original Message----- From: randy marchany Sent: 2010-05-10 21:05:58 To: randy marchany;The EDUCAUSE Security Constituent Group Listserv Cc: Subject: Re: [SECURITY] Mobile Data - Protecting the University from unnecessary risk For all of us, the problem is well defined. However, we need to be careful to avoid common security solution pitfalls. Typically, the sensitive data problem can be broken down into these phases. 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 protect 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 "Sensitve 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, 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. 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. 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. I now put on my flame retardant suit. Randy Marchany University IT Security Officer VA Tech IT Security Officer & Lab
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)
(Thread continues...)