Risk
9/26/2013
12:44 PM
George Crump
George Crump
Commentary
50%
50%

Flash Storage Has Special Security Needs

Over-provisioning and bad-block marking can leave flash storage devices vulnerable to data theft. Here are workarounds.

7 Ways To Create E-Portfolios
7 Ways To Create E-Portfolios
(click image for larger view)
At some point, almost every storage system will be used for a role different than what it was purchased for. This could mean assigning it to a new department within the organization, transporting it to another office, or decommissioning the unit all together. In any of these scenarios the first step is typically going to be erasing the data to make sure that nothing sensitive on that storage system remains. Interestingly, when it comes to solid state disk (SSD) or flash arrays, erase might not always mean erase.

When flash is erased the process is actually a write. A block of data is read from flash, the block on the flash is cleared by writing zeros to it, then new data, if there is any, is written to that block. The flash controller knows that any block regions with zeros are eligible for new data.

Formatting an SSD, even repeatedly, might not actually erase the drive like it will a hard disk drive. There are two functions of flash that can cause a problem. The first is the very common technique of over-provisioning. Over-provisioning allows the flash to extend its life expectancy by reserving a certain percentage of flash capacity and hiding it from the operating system. It allows the flash drive to leverage wear leveling to distribute the write workload over a higher number of flash NANDs. In some drives this over-provisioning can be as much as 25% of the capacity.

[ How did thumb drives betray the National Security Agency? Read Thumb Drive Security: Snowden 1, NSA 0. ]

The problem is that a straightforward format utility won't know about these extra cells and data could still exist on them after formatting. Some flash vendors have created special utilities that are able to address these hidden areas as well as perform a destructive series of writes that includes a mixture of ones and zeros. These utilities are perfect except for one other problem: bad-block marking.

The flash system technique of bad-block marking might also trip up your attempt to destroy data. Everyone knows by now that flash storage wears out eventually. The problem is that some memory areas wear out much sooner than others. When that happens, that block area can no longer accept writes. And if it can't accept writes, you can't write to it in order to perform an erase. You can, however, still read from it and the data is still there. That means that someone with the right motivation could get to your data.

The good news is that in both of these situations, systems can be taken into a lab and read. For most organizations most of the data isn't valuable enough to be considered worth the effort. But the chance of an organization having some data that is of value to outside interests is increasingly likely.

In either case, getting to the data requires some work and some lab equipment. The problem is technology is driving the price of the equipment required to do this forensic work just like it is driving everything else down. In short, you should do something to protect the organization and its data in case it falls into the wrong hands.

At a minimum, you should make sure your SSD or flash-array vendor has some sort of erase function that allows you to get to both visible and hidden areas of flash storage. Ideally, this will also perform some sort of "one then zero" erase on the data.

For many environments, though, the answer might be always-on -- not optional -- encryption, so that the moment the flash storage is removed from the system or the key is destroyed, the data is useless. The problem with always-on encryption is that it might hurt performance, so your vendor might need to increase the system's processing power so it can perform encryption at line rate.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

CVE-2014-8711
Published: 2014-11-22
Multiple integer overflows in epan/dissectors/packet-amqp.c in the AMQP dissector in Wireshark 1.10.x before 1.10.11 and 1.12.x before 1.12.2 allow remote attackers to cause a denial of service (application crash) via a crafted amqp_0_10 PDU in a packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?