Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Encryption at rest, what am I missing? - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Encryption at rest, what am I missing?
I've been going up, down, and around with the topic of encryption at rest for a while now and I feel like I'm missing something big - but don't have any idea of what. As far as I've been able to tell, the topic boils down to two sub-categories: 1) Encryption of endpoint devices (laptops, etc) which makes perfect sense to do, and 2) Encryption of central enterprise storage arrays (which is where I run into trouble).

I've been reviewing multiple compliance standards (ISO, CSA, PCI, etc); all of which require encryption at rest of enterprise storage arrays, yet I don't see any added benefit to doing so (I'm willing, but don't want to do it just to check off a box with no real gain). The problems I run into are basically these:
-If the point is to protect data on drives which have been decommissioned or stolen, then the attacker would first have to get hold of the discs (which would first require overcoming various physical security measures). Then, as the data is striped between multiple discs, they would need to get a set of discs from where the complete file could be extracted, and develop some method of reconstructing the data from that set of drives. I've not actually determined the probability of success with this, but am fairly certain that it is low and that adding encryption to those drives would not significantly lower the risk from this vector.
-If the point is to prevent someone who penetrates the network from getting at the data, then they first have to penetrate the network, but once done, they could always (in theory) exploit the servers which would be using the encryption keys and get at the data that way - again negating the value of adding the rest encryption.

In my searching of the web, I've found tons of resources that describe how to do this, but have yet to find any good sources that say why - and that's what I need to know. Why is this critical? What is the attack vector we're trying to defeat? What's the value?

Again, I'm fine with endpoint encryption (and have begun rolling that out), I just don't understand why we'd need to encrypt the production array. What am I missing?

Thank you very much for any information you can share.
CT

4 Posts
The motivations for disk encryption are probably more business driven than technical. With HIPAA if you encrypt data at rest and the database gets stolen you have “SAFE HARBOR” so you don’t have to notify the government, or the people whose data was stolen. Avoiding bad press like that can be worth a lot of money. With PCI if you don’t encrypt the right data and are non-compliant with the DSS, you can be assessed additional fees to recover the cost of card fraud in addition to the regular penalties of $50 to $90 a record. Some organizations, such as the IRS (IRS-1075), require it as a condition of doing business.

It is only an incremental increase in technical security, but when looked at from a risk management perspective it’s a good deal.
Anonymous

Thank you for the response. It seems that this is (unfortunately) as bad as I suspected, a method of making us seem secure without actually making us more secure - and that the only tangible benefit is being able to check off boxes on a form to further foster the illusion that we improved things. This drives me especially crazy since it will either cost us several hundred thousand dollars on self encrypting drives, or require a significant development effort to add the ability to encrypt data directly into our applications - all for very little gain - and when I think of what I could do with that money or effort put to use on efforts that would make things better, it just makes me cringe. CT

4 Posts
Quoting CT:Thank you for the response. It seems that this is (unfortunately) as bad as I suspected, a method of making us seem secure without actually making us more secure


We have a winner! "Safe Harbor" is only for the yachts that are parked in it. Those that have the rowboats need the pails.
ICI2I

63 Posts
Not everyone uses data centers with 24-hour staffing. Many small businesses run onsite servers and these shops will often be left empty after business hours, with no more physical security than the lock on the front door and maybe a burglar alarm. Something as simple as a server being misdirected in transit or being placed with discarded equipment before it's been properly processed can lead to the loss of data. There are also emergency evacuations--hurricanes, earthquakes, wildfires, riots, or any other event where everybody needs to run for their lives RIGHT NOW. After a major disaster, even a massive data center becomes an unguarded gold mine of computer equipment that looters can pick through for hours or days before anyone shows up to stop them. While the average thief may not know anything about RAIDs or infosec, you can bet their fencers know someone who does. Encrypting data at rest, even on a production server, is a bit like buying car insurance: 99% of the time, it's an absolute waste; but if one of these specific, unlikely event happens, you and your customers will be glad you did it. Halifax

4 Posts
Well, that certainly makes sense for the smaller companies - I've worked for a couple along the way, but had forgotten about the server "closets" (where it literally is a closet, probably with the door removed to provide ventilation). And the natural disaster scenario makes sense too, though I wonder if it makes sense to invest a lot of resources into mitigating a threat with a 0.000001% chance of occurring when those same resources could be used to deal with threats that have much higher probabilities. As always, we have to pick and choose our battles and I'm not fond of going after the tough, minimal risk when I can go after the big ones instead. Which leads me to wonder about compensating controls and such. As a rule, would it be acceptable (providing all other appropriate controls are in place) to not encrypt the array, accept the risk, and simply explain that the odds of that data being exploited in a manner that would not have been possible if the array were encrypted is so small that it is unneeded? CT

4 Posts
I've heard of significant performance hits with encryption of data RAID arrays and SAN's. Is everyone using hardware encryption to perform this? Or are you using Bitlocker with Server 2012? In either case, I feel this is one of those standards that is not widely practiced in small and medium businesses, and therefore a potentially (large) security risk. Anonymous

It sounds like you're assuming the use of whole disk encryption and you're right whole disk encryption really only protects the physical disk(s). However, you can encrypt data at the file or record level as well. If you keep your keys separate from your data (and you should) then this encryption will provide extra protection in that someone just trolling around on your system, even one with admin access, cannot directly see the unencrypted data. Sure, if they find the right key to decrypt they can do it (and you don't want to rely on security by obscurity), but it does make an attacker's job more difficult. David

3 Posts
Let's not forget that HIPAA was enacted in 1996, when the N64 was the gaming system of choice, the Motorola StarTAC flip phone was that latest cell phone and CDs were the primary medium for transferring of data from provider to provider. Ideas around protecting things like an iPad or a smartphone weren't even on the thought horizon. So, what was the target of "encryption of data at rest" in that period? That's one of the beautiful things (and drawbacks) of HIPAA: adaptability/flexibility. My belief is they were targeting removable media, had considerations around harddrives, but let it be generic enough to allow for new technology to be encompassed.

I'll agree that encryption today, under HITECH, can provide for "Safe Habor" if meeting FIPS 140-2. However, don't forget the changes implied by Omnibus around the risk evaluation related to an incident or breach regardless of encryption level. IMHO disk level encryption should be in-place or you'll likely find yourself in an uphill battle with an OCR auditor if you have a breach. Look at the 2011 breach associated with Health Net when IBM reportedly lost (couldn't account for) several unencrypted server harddrives from their datacenter. Also, how do you sanitize a drive if it fails and has to be sent back under warranty. You might not be able to spin up the drive, but after remanufacturing by the vendor who has your unencrypted data?

Also look at 164.310(d)(2)(iv) which is typically only seen as the backup requirement. However, the verbiage indicates the movement of devices should be included. That inclusion of movement of equipment does imply that they did have the foresight to try to protect data as servers and other equipment was being moved from location to location (potentially being lost in transit). IMHO that is a secondary or supporting argument around the need to encrypt at the disk level.

Hope that helps.
Not2Nite

2 Posts
Quoting Not2Nite:Also, how do you sanitize a drive if it fails and has to be sent back under warranty. You might not be able to spin up the drive, but after remanufacturing by the vendor who has your unencrypted data?


This sounds like a good reason to use encrypted at rest disks.. the only reason so far that makes any sense to me. (Though granted, in a big striped raid system, unless you have a bunch of other disks from the same raid set its going to be pretty difficult to get anything useful off the disk anyway)

The other reason I can make sense of is for quick disk wipe. ie. destroy the key and you are done.

I never quite understood where the key for the encryption on SED's comes from though. I assume it must be taken from a TPM chip within the computer or something similar?
Anonymous

Sounds like interesting Anonymous

See the paper by Securosis, Cracking the Confusion: Encryption, etc.

One reason for encryption is "separation of duties beyond what is possible with access controls. Usually this only means protecting against administrators, because access controls can stop everyone else." The most effective way to implement such separation of duties is to encrypt at the application layer, with the encryption happening within an HSM (so the keys are never available outside the HSM) and encrypted data sent to the DB.

The trouble is, HSMs are way too pricey for most organisations. So you encrypt on a dedicated server, which may also store the keys. Ensure that the encryption server is well protected and that the administrator is not also the admin for the DB.
VirafHathiram

1 Posts
Full Disk Encryption(FDE) or SAN-based encryption is wrong! Why? Look at
http://mobility-sp.com/images/gallery/FIREHOST-Whitepaper-Cloud-Encryption-2015.pdf
Anonymous

-
"I wonder if it makes sense to invest a lot of resources into mitigating a threat with a 0.000001% chance of occurring when those same resources could be used to deal with threats that have much higher probabilities."

Check out Dan Potter's talk from DefCon this year https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/Bruce%20Potter/. It talks EXACTLY about this issue and some of the motives driving the behavior.

That being said, if your app encrypts the data and the DB server is compromised your data is initially safe since the attacker would have to obtain the encryption key from the key server to decrypt the data. Defense in depth. The only other way would be to use a SQL injection to have the app decrypt the data as it spews it out.
Enke

5 Posts
Which again leads me back to my initial point. Sure I'd love to make everything perfectly secure, and do everything possible, but the reality of limited resources and the illusion of perfect security make it necessary to made choices. That said, my own belief is that it would be much easier to compromise an application and get data off the storage array (even if it was encrypted) than to get inside the datacenter, steal discs, recreate files, etc (even if the array was not encrypted). CT

4 Posts
"As a rule, would it be acceptable (providing all other appropriate controls are in place) to not encrypt the array, accept the risk, and simply explain that the odds of that data being exploited in a manner that would not have been possible if the array were encrypted is so small that it is unneeded?"

That is exactly what Risk Management is for. Together with the "Business" or "Front Office" the Business Impact of losing the data on the equipment should be assessed and quantified. After that it's a relatively simple sum to calculate if it's more expensive to mitigate the risk than the potential impact the loss will have or not.
AlfredP

5 Posts

Sign Up for Free or Log In to start participating in the conversation!