Feds' Edict To Encrypt Hard Drives Gets -- You Guessed It -- Ignored
from the surprise! dept
Back in May, the Transportation Security Administration did its best to gloss over the fact that it lost a hard drive containing personal information on some 100,000 of its employees by putting out a press release about it at 7 o'clock on a Friday evening. Now, a few months later, it's disclosed that the drive wasn't encrypted (via Threat Level), in contravention of a White House order from last summer saying that all devices containing personal data need to be encrypted if they're taken outside secure areas. As we've noted, these sorts of edicts and guidelines are meaningless unless they're actually followed, and non-compliance brings real repercussions.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: data breaches, identity theft
Companies: tsa
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
Repercussions?
[ link to this | view in chronology ]
Re: Repercussions?
its who ever is in charge of security in said department, since he didn't apply the edict plus the hard drive could be stolen
[ link to this | view in chronology ]
The problem is UNFUNDED edicts
[ link to this | view in chronology ]
no, the problem is thinking you need money
then you have problems on an employee level, not on a funding level.
[ link to this | view in chronology ]
Re: no, the problem is thinking you need money
[ link to this | view in chronology ]
Re: Re: no, the problem is thinking you need money
Military pay is about as close to "free" as you can get, without slavery. ;-)
[ link to this | view in chronology ]
Typical
And if the real reason it wasn't done was a lack of funding, then as Matt said, you have bigger issues. Software to encrypt data is relatively cheap. Otherwise, don't let anyone take the data out of a secure area. An organisation that is chiefly concerned with security ought to already have sufficient resources allocated to protect this kind of data.
[ link to this | view in chronology ]
Lost Drives
cattle on the way to the, oh well, you know the picture...
Good Day
[ link to this | view in chronology ]
Lost Drives
[ link to this | view in chronology ]
Re: Lost Drives
[ link to this | view in chronology ]
Re: Lost Drives
Even if the software comes for free, there are costs. The IT staff must construct a deployment plan that minimizes downtime while taking every precaution, imaginable and unimaginable, to ensure that there is no chance of lost data during deployment. There are tests that must be carried out looking for unintended consequences ("Whaddayamean, the backup solution won't work on an encrypted drive??!?") There is the downtime while the solution is being rolled out. There is user training. There is support after the fact. There are the ongoing costs of making sure that the solution stays patched against vulnerabilities going forward.
On any large-scale enterprise deployment, the cost of the software is NEVER the only cost, and quite frequently not even the major portion of the cost.
[ link to this | view in chronology ]
Mark O. and Microsoft
[ link to this | view in chronology ]
Lost Drives
[ link to this | view in chronology ]
not as easy as it sounds
I am a civilian contractor for the Navy, and we've been encrypting our laptops since last summer. They jumped right in with zero thought given to the consequences, and now security is WORSE.
First, we're talking volume encryption (it's pointless if you can mount the drive in linux and bypass the free crap suggested above), and I've never seen a free solution that easily lets you boot into XP with a fully encrypted HD. The options that do are actually pretty dangerous from my experience. The ATA standard makes allowances for bad sectors, etc, and the encryption breaks that - at least to the point where it would take 2 years for an emergency decryption. Oh yeah, warranties don't cover a HD that died due to a bad sector + encryption... Free?
Long story short, word has gotten around that if you have even a minor HD problem, your data is gone forever. So now we're fighting users who "back up" their data on unencrypted, personal USB devices. Turns out those things are FAR more easily/likely to be lost and/or stolen.
It's a joke - however I blame most of the problem on the lack of user education. Zero training is offered on any of this crap.
[ link to this | view in chronology ]
Re: not as easy as it sounds
Sing it loud brothers!! - I feel your pain
The problem with large scale IT support is there are always a million experts who have a friend that did it once on their home system for a few bucks or with open source software so it must be easy
Yeah right - the trick to large scale IT support isn't gadgets, hardware, flashy software etc. It's picking the right *solution* to support the business both during and after the rollout. The software usually has to be vendor supportable, open source has the distinct disadvantage that its source code is open to all (so not great for a security app you are relying on), and that in my experience if you end up with a problem that is almost unique to your build (not too uncommon) you are basically alone
You have to be able to plan a rollout which will not stop the business dead in its tracks, if you're 24x7 this can sometimes mean installing temporary clusters and almost always means shit loads of overtime. On the subject of clusters - you probably want to test in a model office environment what happens if one half of the cluster is encrypted but not the other....
For a major mid-high risk rollout like this (I don’t know of an encryption project that didn't screw up some drives) you need to invest time in communication - otherwise you end up with exactly what Brian states users panicking and backing up data to their MP3s. Hell if you are sensible you probably want to ensure you have some form of workstation backup solution before you go about this, or at least a few fast USB hard disks to do temporary backups at the users side before going ahead (which again requires more staffing, business disruption etc)
You'll want to make sure your support staff have adequate training in how to work the software, diagnose faults with it or are even basically aware of it - this includes your helpdesk – how are they going to support remote users?
On the subject of backups as already mentioned you need to make sure that you can backup encrypted disks so more testing - I reckon you'll probably also want to see what happens if you need to roll back due to a fault and your full backup is unencrypted but the incrementals aren't
On that note - roll back plans....
I'll stop, but you get the idea, there is a shit load more to consider in a large rollout of this level of software than most people initially think and almost every aspect involves increased cost and/or business disruption. The faster you want to go, the deeper pockets you need
[ link to this | view in chronology ]
Still Relevant After All These Years...
[ link to this | view in chronology ]
The bottom line is these solutions DO cost money (a great deal, actually) and none of them are as perfect as they need to be to truly integrate in a large business.
It's one thing to say "all hard drives with personal information will be encrypted", it's a completely different thing to actually do it.
[ link to this | view in chronology ]
Encrypted hard-drives - and then what?
Encryption is free? In what universe?
I reckon the best thing is to ban all personal computing devices and return to working off mainframes and dumb terminals.
[ link to this | view in chronology ]
TSA is dumb
Now, luckily there's nothing even vaguely sensitive on my laptop. But I find it hard to believe that it's safer in my bag riding the Metro than it is locked to my desk in a secure building with 24 hour security.
[ link to this | view in chronology ]
Bitching about the costs and the logistics
However, the order/edict is: "all devices containing personal data need to be encrypted if they're taken outside secure areas".
(to keep in with the TSA example:) Just how many TSA computers do you think have the personal information on some 100,000 of its employees and are taken outside of secure areas?
I don't know how many computers/drives we're talking about here, but objections to the cost and logistics to encrypt every computer/drive aren't relevant, (unless said personal information would be stored on every single TSA computer/drive).
I would assume that in effect it's only a small portion of all TSA drives/computers that have said personal information (so even if all those drives do leave secure areas, the actual required work is much smaller than assumed here).
And if the majority of TSA drives have large amounts of people's information on it, there are larger fish to fry (global TSA stupidity) than figuring out how to encrypt drives, because that would be treating a symptom, not the (stupidity) disease.
PS: Brian, why would you need a fully encrypted drive? If the confidential data is encrypted, that is sufficient, encrypting the rest of the drive at bests obscures the issue slightly, and as we know, security by obscurity is never good...
[ link to this | view in chronology ]
Re: Bitching about the costs and the logistics
You are right however - I think perhaps we are just applying the 'what would we like to see happen' logic rather than 'follow the edict' which would have been more appropriate for this post
Re encrypting just the data though - this is not usually a good, reliable method, for the reason that in these cases the key is either likely to end up stored on the same drive as the data, or be one the user can remember (i.e. easy). Bear in mind that you don't have as many timedetection constraints with data thats on a drive in your hand, so brute forcing becomes a viable option. Full hard drive encryption is the avenue I would go down for immediate strong & reliable protection and then work to build in other safe guards such as individual data encrption later
[ link to this | view in chronology ]
Re: Re: Bitching about the costs and the logistics
I do agree that for data (that is sensitive and should be encrypted) that would be used (on a daily basis) on the notebook/drive it is stored on, a full drive encryption would probably be best. (Although I'm not sure whether I would opt for a 1 drive solution and encrypt that, or have an unencrypted drive for the OS and a seperate, full encrypted drive for that sensitive data.)
[ link to this | view in chronology ]
Re: Re: Re: Bitching about the costs and the logis
Screenshotting certain bits to send as a query to Bob in accounts may not be uncommon, as may programs which take the data and then store it in temporary files
That's before you get to users who for no known good reason create a folder outside their 'normal' my documents work area to put things in
If you encrypt the lot then you know you got it all ;0)
[ link to this | view in chronology ]
SailorRipley
Why do you need a fully encrypted drive? Ask the NIST, not me. I believe "ease of use" is the primary factor (from my point of view at least, I'm sure those 4 levels above me would differ). It's much easier to explain to a user that they now need to log in one extra time when the PC boots than it is to train them to use encrypted stores. Not to mention what data needs to be encrypted and what doesn't. One note- none of our users have personnel data, I'm talking about sensitive/proprietary design data for ships and weapons systems (and not classified data - that has it's own policy universe)
One thing I think we all take for granted here is user savvy (or the lack of it). If all the users were computer experts, I'd be out of a job. For the majority of my users (3000+ at last count), all they really know is their next deadline and how they'll never meet it if they experience even a small glitch.
It's
[ link to this | view in chronology ]
Re: SailorRipley
Situation 1: (1000 computers with HW configuration A)
install OS and software on first computer, make image A, install image A on 999 other computers.
Situation 2: (1000 computers, x with HW configuration A, 1000-x with HW configuration B)
install OS and software on first computer with HW A, make image A, install image A on x-1 other computers.
install OS and software on first computer with HW B, make image B, install image A on 1000-x-1 other computers.
net difference: install OS and software on first computer with HW B...this really doesn't seem to justify doubling your cost or staff...
(I admit there will be a little more overhead than that)
[ link to this | view in chronology ]
small clarification
In any large org, licensing costs are barely negligible. In any project, labor costs account for 70-80% of the total. In the civilian contractor world, all the costs are factored into the service contract - which in most cases was tallied long before edicts such as this come down.
[ link to this | view in chronology ]
Your second post actually gets a little closer to reality, but still doesn't make much sense - wouldn't it be easier/cheaper/more reliable to just have one single image? At least in my org (not TSA), we only issue laptops to users that actually have a strong need - not just to anyone who asks. Perhaps if every user had a laptop multiple images would make more sense, but not if every laptop user handles sensitive data by definition.
Since I deal with drive encryption issues every day, a couple 'simple' real-world examples came to mind that I'd like to share:
1) email - laptop users are far more likely to use offline email storage in the form of local PST files (Exchange + Outlook). A big problem we see is the bad habit of CC:'ing unnecessary people - like a revised drawing or tech-spec PDF. How do you encrypt live PST files and still have Outlook recognize it? I haven't given it much thought, but my first guess is you can't - unless Outlook.exe and all it's req'd files are also contained on the same encrypted store. Fragmentation, bad sectors, etc, and you've got a nightmare.
2) the actual drive encryption process - takes a LONG time. The encryption solution we use (and shall remain nameless) can encrypt the volume in the background during normal use, but any hiccup during that week-long process (running in the background during normal use) and the data is toast. So before issuing a laptop to the user, we use the vendor's admin utility to fully encrypt the drive and at 100% utilization it still takes overnight. Decryption is the same but far more costly. Now on even routine service calls the first thing we have to do is manually decrypt the drive in case anything goes wrong during diagnosis or a component needs replacement (the software keys on an UID it generates based on the ID's gathered from the components, so the HD can't just be placed in another PC and brute-forced).
Again, "encrypting all gov't laptops" sounds peachy, but is a total PITA to implement. Unless of course you have a budget set aside for it and ample test/lab lead-time.
[ link to this | view in chronology ]
[ link to this | view in chronology ]