Consumer cloud storage needs to be enterprise class too: Ask Jennifer Lawrence

We treat consumer cloud services as if they are expected to be less robust and less secure than the clouds we use for mission-critical data. But that should not be the case.
Written by Jason Perlow, Senior Contributing Writer
Image: Jennifer Lawrence/Facebook

Wow, what a holiday weekend. Labor Days are supposed to be relatively quiet, with hot dogs and sizzling burgers adding the requisite entertainment. At least, for most men celebrating our final summer hiatus, standing watch over our Webers lined with charcoal-grilled meat along with a few six packs of beer is about as exciting as it is supposed to get. 

Nobody was expecting a massive photo dump of extremely private moments from Hollywood's most famous actresses, as a result of what appears to be a targeted iCloud hack using "brute force" methods. Over a hundred nude photos, some extremely explicit, were posted in total on the infamous discussion board 4chan during the weekend.

Many of these were from "Girl on Fire" Jennifer Lawrence, among others including Kirsten Dunst, Kate Upton and Mary Elizabeth Winstead.

The hack that befell J-Law and the other actresses is regrettable. We all need to be extremely careful what we capture on our smart devices, and that we need better methods for controlling what should and should not be uploaded to cloud storage accounts and how they should be secured.

But I also want to add that we definitely should not be "blaming the victim" with this event. Rather, we all have the right to explore our sexuality, using whatever technology we have at our disposal providing that we use it between consenting adults and it is legal.

We could treat cloud storage accounts for consumers the same way we do for enterprises, such as those used by cloud-integrated storage appliances on Microsoft's Azure, Google's Compute Engine and Amazon's S3. 

Nobody should "slut shame" Jennifer Lawrence or any of those actresses for taking those photos. It was their right to do so.

However, I think all of us are now going to think twice about what happens after we hit the shutter button on a smartphone.

Let's start with the devices themselves and work our ways down the stack. All the mobile platforms -- iOS, Android and Windows Phone have default settings which allow them to back up your photo "feed" to your cloud storage account associated with that ecosystem.

Google's Android even takes this a step further by having "Auto Backup" which puts your photos on their Google+ social network. And if you have Google+ for iOS installed, it can do the same thing, but you have to turn it on.

It's probably safe to say that should not be the default setting for any of these devices anymore.

This is not to say that I don't think we should leverage cloud storage as photo backups. In fact, quite the contrary. But we need better management tools so that photos can be sent into a "queue" and we can bulk approve for what gets backed up, and set exceptions for what should not.

For the exceptions, one way to handle this might be the ability to store more private material (such as those containing photos of your children) into an encrypted folder. This methodology is already used in all the mobile operating systems when they are enrolled for Mobile Device Management (MDM) for enterprise-use in BYOD scenarios.

The time has come for MDM to be a service that all consumers can use to better control their technology. I've previously made the case that we need MDM for parents so they can protect their children. My ZDNet Security blogging colleague Larry Seltzer agrees.

After this recent fiasco, I'm now convinced we need this for every device we own, be it a smartphone, tablet or a laptop computer. As consumers, we should be able to enroll all of our stuff, encrypt the local filesystems (using technologies such as BitLocker or the Android/iOS equivalents) and set pin codes for unlock.

If this is good enough for the enterprise, then it's good enough for you and me.

As a secondary precaution, should the device get lost, we should be able to send a remote kill signal that erases the local storage the moment it is turned on and locks onto a mobile network. 

Now let's get into the security of the cloud storage itself. The actual communication between endpoint device and storage account using the various services is encrypted using TCP port 443, or SSL. This is true for Microsoft's OneDrive, Google Drive and also for Dropbox.

But while the end-to-end traffic between device and storage account is encrypted, we still rely on user accounts and passwords for the access control method to that storage.

Steven J. Vaughn-Nichols notes that we should strongly consider 2-factor authentication for securing cloud storage accounts. I think that for celebrities like Jennifer Lawrence as well as the others targeted by this hack and other high-profile people who may end up being potential targets for this kind of cloud-based data theft in the future it's a good option.

But I'm not going to sugar coat it, 2-factor auth is a hassle. I use a variant of this every day for work and it's an extra pain in the neck. But I fully understand why my employer makes me use it, as I have access to some very sensitive stuff that could result in major intellectual property loss and have severe business impact to the company if someone were to steal my laptop and get access to our internal network or even my own OneDrive for Business storage on Office 365.

For the rest of us, there are other ways to deal with this besides 2-factor auth. We could treat cloud storage accounts for consumers the same way we do for enterprises, such as those used by cloud-integrated storage appliances on Microsoft's Azure, Google's Compute Engine and Amazon's S3. 

Microsoft's StorSimple backup appliance, for example, uses an access key -- essentially, a very long randomly-generated password -- to connect to each Storage Account that holds the Azure Blob containers storing the backup data for the connected appliance. This is in addition to the ID of the storage account itself that the containers live in.

Now, one would think that a very long randomly-generated password would be enough. For my own personal Azure blob storage, which I use from my PCs at home, I'm pretty confident that nobody is going to get in.

But the StorSimple appliance goes even further. It actually encrypts the data within those storage accounts into machine-unreadable chunks using an encryption key locally stored on the appliance itself.

Should anyone manage to get past the access key and into the Storage Account on Azure, the information they'd find would be completely unusable.

Now, StorSimple isn't the only cloud storage product that can encrypt using local keys on storage accounts. CloudBerry Backup, a $29.00 product I use on my home PC to vault my most private data on Azure (and I'd trust it to back up my naked pictures as well) uses a similar encryption methodology.

While it would add an additional layer of end-user administrative burden, I think we should be using at a bare minimum local access keys for every cloud storage connected device that we own, so that only the devices we permit should be able to have access to those storage accounts, and each device's access key should be unique, because unlike typical cloud-integrated storage which never leaves the datacenter, mobile devices by definition are carried around.

Consumer cloud storage providers should provide portals and apps for managing these access keys, and ultimately, we should be encrypting the blobs themselves at the device level, even if it is at a cost to battery life and CPU performance.

Given the shift towards 64-bit processors in mobile devices, such as those already in the iPhone 5S and the iPad Air and on certain Samsung smartphones, that CPU hit shouldn't be as serious going forward anyway. 

Should we be treating consumer cloud security the same way we do it in the enterprise? Talk Back and Let Me Know.  

Editorial standards