News from NIST. Comments are requested for a “plain terms” document for “decision makers”; my first comment is that more technical guidance would be more appropriate. A “how to” is what everyone is asking for, not a “should do”:
The cloud computing research team at the National Institute of Standards and Technology (NIST) is requesting public comments on a draft of its most complete guide to cloud computing to date.
Draft Special Publication 800-146, NIST Cloud Computing Synopsis and Recommendations explains cloud computing technology in plain terms and provides practical information for information technology decision makers interested in moving into the cloud. Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources-for example networks, servers, storage, applications and services-that can be rapidly provisioned and released with minimal management effort or service provider interaction.
Comments for this draft should be sent to email@example.com by June 13, 2011.
To view the press release from NIST’s Public Business and Affairs office regarding this draft, please go to this NIST page:
Here’s a sample directly relevant to my post on the Dropbox encryption and key management controversy now documented in a complaint to the FTC.
8.5.7 Key Management
Proper protection of subscriber cryptographic keys would appear to require some cooperation from cloud providers. The issue is that unlike dedicated hardware, zeroing a memory buffer may not delete a key if: (1) the memory is backed by a hypervisor that makes it persistent, (2) the VM is having a snapshot taken for recovery purposes, or (3) the VM is being serialized for migration to different hardware. It is an open issue on how to use cryptography safely from inside a cloud.
It seems to me that final statement is out of place and too concessionary and, if accepted, pretty much kills the FTC complaint.
And here’s a sample of the “should do” theme in the “General Recommendations:
…protective mechanisms should be required by subscribers for separating sensitive and nonsensitive data at the providerâ€™s site.
If I wanted that high-level of a guide I could use an existing standard.