Many organizations are reluctant to embrace cloud technologies, at least in part, because of concerns about the security of their data and applications.
The geolocation technique … revolves around generating a cryptographic hash that represents the trusted geolocation information for a particular cloud server.
Perhaps foremost among those concerns is the risk resulting from digital assets residing on cloud servers in locations they may consider undesirable, such as countries with differing security and privacy laws. An organization may not be willing, or ready, to have its data subject to multiple sets of laws and to allow the location of its data to change without warning as dictated by the whims of the cloud provider.
A common solution to this problem is for a cloud provider to state contractually that it will not allow workloads to reside in certain geographic locations. This is commonly achieved by relying on cloud geolocation techniques, which identify the approximate geographic location of a cloud server.
However, these techniques generally don't take security into account. They can easily be corrupted or otherwise circumvented to trick workloads into going onto undesirable, possibly unsecured, servers. It's unwise to trust them, especially when an organization is serious about cloud security.
The National Institute of Standards and Technology (NIST), in collaboration with representatives from Intel Corp. and EMC Corp.'s RSA Archer unit, have responded to this challenge by developing a method for trusted geolocation for cloud workloads. Documented in the new Draft NIST Interagency Report 7904, Trusted Geolocation in the Cloud: Proof of Concept Implementation, the proposed set of NIST cloud security techniques aims to establish a hardware root of trust that is constantly monitored and that ensures that the workload is not placed onto an unacceptable server (i.e., a server in a prohibited location). The solution takes a three-stage approach:
- Stage 0: Trustworthy Platform Attestation. This prerequisite stage is solely concerned with making sure the platform that a workload is going to be placed on is trustworthy. This primarily involves securing the cloud server, verifying the security configurations of the cloud server's BIOS and hypervisor before launching the hypervisor. It also ensures that while the hypervisor is running, the BIOS and hypervisor continue to be trustworthy.
- Stage 1: Secure Migration. This stage builds upon Stage 0 by permitting workload migrations between homogeneous trusted servers -- trusted servers in the same cloud with the same hardware and virtualization architectures. Note that at this stage, geolocation has not yet been included as a security factor; the focus is simply on ensuring that the platforms for the workloads can be trusted.
- Stage 2: Geolocation-Based Secure Migration. Stage 2 is similar to Stage 1, except that geolocation considerations are taken into account. Geolocation is confirmed not only before a workload is placed onto a server to prevent the workload from being placed in an inappropriate server location, but also periodically confirms the geolocation as that workload runs, in case there is any change in the geolocation policy during workload execution. If a policy conflict is detected, it is reported immediately and handled as the workload owner desires, such as halting the workload or transferring it to a different server.
The geolocation technique recommended in Draft NIST Interagency Report 7904 revolves around generating a cryptographic hash that represents the trusted geolocation information for a particular cloud server. This cryptographic hash is stored within the server BIOS, which safeguards it from alterations while also allowing security management processes to access it for continuous monitoring purposes. Using the server BIOS as a hardware root of trust provides significantly stronger security than relying on software-based trust information.
NIST's new publication does not provide specific recommendations for federal agencies or other organizations as to how they should perform trusted geolocation for cloud workloads. Rather, the publication is intended to provide a proof of concept of such an implementation, with sufficient technical details so that other organizations can duplicate what NIST, Intel and RSA Archer have done. The appendices of the publication contain detailed technical information, including step-by-step procedures and PowerShell scripts, to help other organizations reproduce the proof of concept in their own cloud environments.
The logical next step is for other organizations to try out the proof of concept in simulated or test cloud architectures and report their feedback to NIST during the public comment period for draft NIST Interagency Report 7904, which ends Jan. 31. All comments should be directed to email@example.com.
Meanwhile, organizations with concerns about geolocation should ask their cloud vendors how they ensure the trustworthiness of their platforms and how they geographically restrict workloads. NIST's method of ensuring trusted geolocation is certainly not the only way to do it; it's offered as an open set of specifications and techniques for the benefit of the cloud computing community.
About the author:
Karen Scarfone is principal consultant for Scarfone Cybersecurity in Clifton, Va., providing cybersecurity publication consulting services. Karen was formerly a senior computer scientist for the National Institute of Standards and Technology (NIST), and she has co-authored more than 50 NIST publications, including Draft NIST Interagency Report 7904, Trusted Geolocation in the Cloud: Proof of Concept Implementation.