Implementation of Cloud Computing Solutions in Federal Agencies : Part 3 – Cloud Transition Lessons Learned

(This is part 3 of the series entitled “Implementation of Cloud Computing Solutions in Federal Agencies”. First published on Forbes.com, this series provides the content of a whitepaper I recently authored. A copy of the complete whitepaper will be available at NJVC.com starting September 7, 2011.)

While the benefits and value of the federal cloud computing policy can be debated, the world’s transition to cloud computing as an integral component of any IT infrastructure cannot be denied. The prudent government executive should, therefore, heed the lessons learned from the many private industry corporations that already have miles behind them on this journey.

When identifying a potential cloud computing project, one should always count on a multi-year transition. Organizations should always use a consistent cloud opportunity identification process to reduce the risk of project failure by leveraging data from successful cloud implementations. Clients need to determine set metrics (economic, operational and service) with direct linkage to specific mission requirement(s). Use of a gate-driven cloud adoption process designed to terminate failed projects early in the project lifecycle and deliver measurable capabilities within a quick timeframe (weeks—not years) is highly recommended.

A risk mitigation plan also must be formalized that addresses each of the following concerns:²

• Loss of Governance. When moving to a cloud environment, clients relinquish control to the CP on a number of security-related issues. A gap in security defenses may also exist as service level agreements may not adequately address CP-related security requirements.
• Portability. Issues related to provider lock in are outlined in the Challenges section of this white paper on page 5.
• Isolation Failure. Multi-tenancy and collaboration are at the core of cloud computing. Resource isolation failure addresses mechanisms separating storage, memory, routing and reputation among different clients on the same cloud (e.g., guest-hopping attacks). However, it must be noted that attacks on these mechanisms are not as pervasive and much more difficult to attempt versus attacks on traditional operating systems.
• Compliance Risks. Investments in certifications (e.g., industry standard or regulatory requirements) may be compromised or lost when moving to the cloud.
• Management Interface Compromise. Security is an issue with client management interfaces with the public cloud provider. The reason? These services are provided via the internet and permit access to a larger set of resources than traditional operating systems. Security risk can dramatically increase when this is combined with remote access and web browser vulnerabilities.
• Data Protection. It may be difficult for clients to effectively check the data-handling practices of their CPs to ensure critical and sensitive data is handled lawfully and ethically. This problem can be aggravated in cases of multiple transfers of data (e.g., between federated clouds). However, it must be noted that some CPs share information on their data-handling practices with clients and others offer certification summaries on their data processing and data security activities and their various security controls (e.g., Statement on Auditing Standards 70 Certification.
• Insecure or Incomplete Data Deletion. As with most operating systems, when a request to remove a cloud resource is made, a true erase of data may not happen. Adequate or timely data deletion also may not be feasible (or undesirable from a client perspective) because extra copies of data are stored but not readily available or the disk to be destroyed also houses other data from other clients. When multi-tenancies and the reuse of hardware resources are added to the mix, this risk can increase.
• Malicious Insider. Cloud architectures necessitate the creation of certain staff positions (e.g., CP system administrators and managed security service providers) that can be extremely high risk in terms of internal security threats.

Creating a Cloud Computing Roadmap for Federal Agencies First Steps

According to, GovCloud: Cloud Computing for the Business of Government, when a government agency is ready to undertake the implementation of a cloud-based solution, it must determine which IT services, business functions and processes to deploy in the cloud environment. A five-year roadmap should be created that includes the desired order to move each of the services to the cloud for each year during that time period.³ Requirements for each service to be deployed in the cloud should be developed and a cost/benefits analysis performed to establish the rationale why each targeted service should move to the cloud.  

Implementation of a Low-Risk Test Case

A low-risk test case should be implemented prior to undertaking a wholesale transfer of services to the cloud.⁴ This is harder than it may sound as some IT services that may seem simple to deploy to the cloud are not so easy. Four questions should be asked (and answered) to decide which IT services are best suited to live in the cloud⁵:

1. Can compliance requirements be balanced with other IT prioirities?
2. Is this an IT function or service the agency has mastered?
3. Can the agency use a standardized service?
4. Is the test case easily implementable?

A misconception may exist that just because an application or service being deployed to the cloud isn’t mission critical, the process will be simple and straightforward. This is not always true. If the agency is new to the cloud and wishes to establish a private cloud it will take time to determine the appropriate split of responsibilities between the service provider and the agency’s IT team.⁶ Compliance and liability issues can also be tricky, as defining compliance conditions and establishing liability for intellectual property protection with cloud vendors reach well beyond the IT world—and, as such, with so many moving parts may take time to properly address and resolved.⁷ NIST has launched the U.S. Government Cloud Computing Business Case Working Group to assist agencies with the development of cloud-compatible user cases. Email, geospatial data exchange and services management are among the first user cases currently in development.  

Additional Recommendations

The authors of GovCloud: Cloud Computing for the Business of Government also offer seven recommendations that must be considered during the development and implementation of an agency’s cloud roadmap:

• Own the information, even if you own nothing else. An agency must claim its right to own the information even if it doesn’t own the infrastructure, application or service associated with that information. Any agency is liable for its information—regardless of where it lives—and some education will likely be needed about this fact among its IT team. While it may be unrealistic to prevent departments from provisioning their own cloud application, the agency must institute policies and procedures to ensure it can monitor how information deployed to the cloud is managed. As it is often hard to envision future uses of information, it also is recommended that agencies make sure cloud-dwelling data can be brought back into the enterprise if needed.
• Don’t take terminology for granted. It is vital to ensure that important terminology is defined in the same way by the agency and the cloud service provider—room for different interpretation always exists. A review of information governance policies must take place to identify the areas of highest risk so authoritative definitions for vocabulary in these areas can be developed and adopted.
• Hope for standards, but prepare to integrate. In short, the cloud is young and isn’t established enough to have developed standard specifications for platform interoperability and data exchange. Strategic groundwork for future data integration needs to be laid in the early stages of any movement to the cloud. Agencies must insist that their cloud service providers provide clear documentation on the data formats and schemas used for information storage in their systems.
• Control cloud platform proliferation. Agencies should minimize the number of different cloud platforms that require support to limit information fragmentation and decrease the chance of a future huge integration effort. To the greatest extent possible, an agency’s IT team should help departments look for shared requirements in standardized business functions. The team can identify cloud platforms that meet these needs and consolidate the agency’s services on them, when possible. Not only will the ability to share information increase, this will result in greater leverage when negotiating contract terms and pricing.
• Make the information “cloud ready.” Agencies that organize their data sets well enough for use across multiple platforms will be best positioned to take advantage of cloud services, and will be better able to deploy enterprise information to the cloud more easily.IT teams need to get into the habit of encrypting data into one common format (probably XML)—a process even more important if data moves through externally operated resources to the cloud.
• Master solution integration. The shift to the cloud requires IT professionals to change their focus from owning and operating enterprise systems to becoming master information service integrators. In addition to linking legacy databases to SaaS, IT teams need to connect their private and public clouds to create a seamless technology environment that works like a single cloud custom-made for their specific enterprises.

( Thank you. If you enjoyed this article, get free updates by email or RSS – KLJ )