Is There Safety in the Cloud?

Key Takeaways

• Increased demand and decreased resources for IT in higher education make the cloud an attractive solution for technology needs.
• The risks inherent in moving to the cloud mandate asking appropriate questions to determine the potential problems and advisable contractual solutions.
• The RFP and eventual contract should contain language that varies with the sensitivity or criticality of the information, which might be stored or processed in the cloud.
• Asking the right questions helps in assessing the potential for harm and determining whether an event is an incident or a security breach.

On April 30, 2010, more than 30 higher education IT professionals gathered at Portland State University to pilot the EDUCAUSE "Best for the West" programs. The title of the event was "Is There Safety in the Cloud?" The ideas in this article arose from that meeting.

On many campuses, increased demand for IT and decreased resources to meet that demand make cloud computing an attractive solution. The potential risks, however, make it advisable to consider the special contractual issues involved in moving to the cloud.

Asking the Right Questions

Asking appropriate questions helps you define and clarify the risks for your own campus. Once you understand your institution's concerns and tolerance for risk, you should incorporate these thoughts into your RFP or contract negotiations.

Question 1: Concerns

According to the EDUCAUSE "7 Things You Should Know About Cloud Computing":

"Cloud computing introduces significant concerns about privacy, security, data integrity, intellectual property management, audit trails, and other issues. Because higher education is subject not only to institutional policies but also to a broad range of state and federal regulations, these issues are complex and become even more difficult in the context of inter-institutional cloud initiatives. Because of the control that consumers of cloud services cede to providers, successful initiatives rely on a high degree of trust between a college or university and a supplier, including confidence in the provider's long-term viability."

What are your specific concerns, and how can they be mitigated?

Question 2: Skills

Also in "7 Things You Should Know About Cloud Computing":

"Operating in a cloud environment requires IT leaders and staff to develop different skills, such as managing contracts, overseeing integration between in-house and outsourced services, and mastering a different model of IT budgets. Lack of these skills could pose a risk to your institution."

Assess these skill levels in your institutions. What strategies can be used to improve these skills? Is your institution ready to take on this new business model?

Question 3: Security

Further:

"What are the specific security and privacy concerns in cloud computing? Why are they different in the cloud? Despite the potential security risks posed by cloud services, some would argue that cloud services offer more security than on-campus solutions, given the complexity of mounting an effective IT security effort at the institutional level."

Others would argue that cloud service offerings vary as much as institutional security capabilities and that financial considerations might drive institutions to use an insecure cloud offering even when secure cloud options are available.

Can you make the argument that cloud services are more secure than what you offer on your campus?

Question 4: Regulations

What regulations apply to the systems you wish to migrate to cloud computing? How? Why? Can you mitigate the concerns of the regulators?

Question 5: Trust

Are other higher education partners more or less trusted than commercial cloud vendors? Why?

Question 6: Private Clouds

Most central IT operations provide virtualized services to their campus customers today. This could be viewed as a private cloud computing service. How have you sold this service to your internal customers? Have they been leery of accepting this kind of arrangement? What is the difference between your customers procuring this service from an on-campus cloud versus an off-campus cloud?

Rethinking the RFP and Contract Process for the Cloud

Those of us in IT have many years of experience writing requests for proposals (RFPs) and contracts for durable goods, software licenses, and professional services, but software as a service (SaaS) and cloud computing have introduced the need for new types of language. The RFP and eventual contract should contain language that varies with the sensitivity or criticality of the information, which might be stored or processed in the cloud. The university retains ultimate responsibility for the safety of that information.

The RFP describes the service you are requesting and, just as important, the metrics used to evaluate the proposals. It should ensure that cloud systems have accountability and ask about options for authentication. Will the accounts be unrelated to existing university accounts, creating an administrative burden to synch cloud accounts and information with university accounts and related information? Can existing university accounts be used in a manner that doesn't endanger them or authentication data? Check the Cloud Security Alliance's "Guidance for Identity & Access Management" for other ideas.

If your university developed the desired system in-house, you could ensure the hosts were physically secure, the operating systems and databases were configured securely, and the applications had integrity, were appropriately available, and provided sufficient confidentiality. In the process you could create and collect evidence of those activities (through data center security plans, third-party audits, vulnerability assessments, software specifications, design documents, test plans and results, etc.)

When you contract for services in the cloud, you do not have visibility into each of these areas of concern during their development. To make up for that deficiency you can add requirements to the RFP for copies of specifications documents and third-party reviews (such as SAS 70s, Systrust certifications, Webtrust certifications, PCI compliance certifications, or external audit reports) that attest that the specs were met and that your security concerns have been adequately addressed. Where they have not been addressed, you can either make mitigation a condition of contract award or you can decide to accept all or some of the risk.

In your own hiring you perform background checks, reference checks, qualification reviews, etc. Ask for the following information to assure that the vendor takes the same or better care in their hiring process:

• Provide the name and contact information for your chief information security officer or equivalent. List any certification and special qualifications they possess.
• Describe the nature of your background checks before hiring staff or contractors.
• What training (in-house and third party) is provided for your employees?
• What relevant certifications do your employees hold?
• How are system administrator actions accountable, tracked, and auditable?
• Do previous position rights and privileges get promptly removed when employees, contractors, or vendors change their responsibilities?
• Are accounts disabled promptly when employees, contractors, or vendors leave?

Citing the company's security claims in marketing material does not qualify as due care. In one instance, a service provider told a university that their SaaS application was secure because their cloud platform provider (Amazon) was secure up to and including the operating system. The Amazon Elastic Compute Cloud (EC2) security overview white paper contained the following statement: "Guest Operating System: Virtual instances are completely controlled by the customer." This example underscores the importance of seeking assurances for each layer of the cloud offering and not just for the application you want to use.

A clean SAS 70, Systrust, or Webtrust certification will not protect you. Vulnerabilities have been announced for each virtualization vendor. See "Subverting the Xen Hypervisor,"¹ for example. Amazon uses a modified version of Xen for their EC2 Cloud offering. Hacking the hypervisor could allow access to each of the virtual systems it managed. It isn't necessary to hack the hypervisor to cause damage, however. ComputerWorldUK reported in December 2009 that a website hosted on Amazon EC2 had been hacked to run the Zeus botnet's command-and-control infrastructure.² Amazon was quick to announce that it wasn't their responsibility to protect against this attack. However, without assistance from the infrastructure owner, many of the tools used to protect physical web servers are unavailable to the website owner.

According to Ed Skoudis, founder of security consultancy InGuardians, cloud services are being used by the Russian Business Network to crack passwords and develop malware.³ It's not a stretch to say this would give the RBN the perfect opportunity to develop code for hacking the hypervisor. Neil MacDonald wrote for the Gartner Blog Network, "This doesn't mean that hypervisors are inherently insecure. The lesson? If the target is attractive enough, the bad guys will find a way to break in."⁴

Lacking a capability for monitoring traffic in the network leaves you blind to most current malware. To offset this concern, include questions in the RFP to determine the monitoring capabilities provided and the options available. In addition, if you plan to use the cloud for storing sensitive or critical information, then you could require that the data be encrypted. As long as the encryption and decryption do not take place in the cloud, your data is protected even if the hypervisor is compromised.

During processing of data in the cloud, the data must be decrypted, processed, then encrypted again. This means that some sensitive data may be accessible in the host's memory, in the virtual memory, and in the virtual equivalent of swap space on the virtual hard drive. You could mitigate some of the security threat by choosing a private cloud or using your own virtual resources instead of a public cloud offering. Private clouds are more expensive, but they are more open to customized security options than a public cloud offering. You might be able to add an indemnification clause to the contract of either public or private clouds.

Corporate executives attending a cloud law summit in London in February said that many customers try to negotiate terms that would shift some of the risk to cloud providers. Reporter Tom Espiner quoted Dervish Tayyip, head of Legal for Microsoft, as saying, "We're not an insurance company." Tayyip told ZDNet UK, "What is important is that customers understand the [cloud] offerings are standardised -- they are what they are. If the offering does not meet customer needs, maybe the cloud is not a realistic offering."⁵

If the provider won't negotiate an indemnification clause, consider approaching your insurance company about providing coverage to assist with the cost associated with a data breach. For both indemnification and insurance, though, you need to determine if it is acceptable to suffer the loss and be paid a sum rather than finding a solution that mitigates the loss. If the service providers consider indemnification too risky, maybe their solution isn't for you. You could specify by policy that certain types of applications (such as those that handle and store credit card or social security numbers) are too risky for cloud offerings. As the technology evolves, you can revisit this policy.

The security response to cloud services is not yet mature. The Cloud Security Alliance is developing guidance in 13 different domains to collect and aggregate a consensus of security professional responses to the challenges of cloud technology. You can find their latest version here. The European Network and Information Security Agency (ENISA) has produced a guide to cloud security issues.

The legal community is still in its infancy regarding cloud computing. Consider the issue of jurisdiction. In a cloud architecture, the data can be stored anywhere in the world without user knowledge or action. This presents legal challenges, since each country has different laws related to privacy, export control, and e-discovery. Criminal and civil law cases determine which laws and community standards to apply based on the location of key elements of the case. Cloud technology could complicate those cases where the storage location of the data is the factor that most influences jurisdiction.

If you choose to place remedies in your contract to limit your risk, you should also consider whether your organization will litigate if contract provisions are violated. Your remedies are only as good as your willingness to follow through.

Protecting Data in the Cloud

You cannot assume that you have the right and the authorization to investigate breaches in the cloud -- your contract with the cloud determines this capability. Your contract should bind the cloud provider to meet any regulatory and legal requirements that you are required to meet. If regulation requires you to protect your data, then you must encrypt it and ensure that the contract does not contain any provision that would permit the cloud provider to investigate your content. If the data that you store in the cloud includes FERPA protected data, then the cloud provider must agree to act as a FERPA agent for the university and to protect it as such. Be aware that law enforcement may approach your cloud provider and demand access to your data.

For any cloud user interface, users should be informed when they log in that they should have no expectation of privacy except that required by explicit law or regulation. The cloud provider and application should have the user agree that use of the cloud constitutes consent to monitoring. This would need to be spelled out contractually with your cloud provider. Your contract should explicitly grant your security staff and administrators the rights that you require regarding monitoring and investigations.

On a physical server, you have the option of purging the hard drive of data before reassigning it for other use or disposing of it. Have the prospective contractors describe the steps taken by the cloud service to ensure that none of your data remains when memory is reallocated to other customers or within your own virtual space.

What is a security breach and what is an incident? Portland State uses the term "breach" to describe all incidents that legally require notification to damaged parties. If there is no damaged party, then it is an incident instead of a breach. Both require mitigation.

Breach Response

You should require the companies that provide each component of your cloud infrastructure to notify you whenever their component has experienced a suspected incident. Review the details with the provider to determine if the incident could result in an exposure. If you determine it could not result in an exposure, then file a copy of your conclusions along with the notification to guard against liability. The details should be used to develop a plan to investigate the allegations. In the course of investigating the suspected incident, note there is no guarantee that any specific forensic tool you normally use will work in your cloud. Review the potentially exposed material and determine the scope (how many people, systems, or database tables could be involved) and nature of the incident (what type of sensitive or critical information might be exposed). Once you know which systems are involved, contact the managers responsible for that information.

Next, determine if any of the information requires reporting or notification (personally identifiable information, credit card numbers, bank account numbers with authentication data, personal health information). Then determine the number of unique disclosures or opportunities for disclosure. To the best of your ability, determine if there is any evidence that the exposed information was accessed. Clear evidence of an exposure of this data would qualify the event as a breach, requiring mitigation and notification. For an example, see "Congressional Websites Hacked."

Without clear evidence of disclosure, you have to prove a negative. The HITECH Act describes a concept called "potential risk of harm." Risk of harm is a concept borrowed from the UK's Data Protection Act 1998. Talking about Private Health Information, the law firm Pepper Hamilton noted, "A compromise of the security and privacy of PHI must pose a significant risk of financial, reputational, or other harm to the individual."⁶ Thus if someone changes the permissions on a directory that contains some of this protected class of data, and the dates associated with the sensitive data do not include any access during the time of exposure, then no potential for harm exists and no breach occurred.

While assessing the potential risk of harm, ask:

• Were the recipients obligated (by policy or regulation) to protect privacy and security of the information?
• Can the impact of the disclosure be mitigated?
• Do preexisting nondisclosure agreements or other measures assure no further disclosure?
• Was the sensitive or critical information returned before improper use could occur?
• Did forensics investigation find any evidence of improper use, discovery, or distribution?
• What was disclosed, and how much?
• Was the data encrypted or encoded?

Once you have the answers, arrange a meeting with the university's General Counsel, CIO, HR department, and the information asset owner. Describe the incident, disclosures, and data found during the review. Determine whether the disclosure (or potential disclosure) meets the criteria in federal or state law or regulations. If it does, and the potential for harm exists, then the group should draft and send a response to the individual who identified the disclosure. Next they will need to draft a response to the individuals whose personally identifying information was exposed. Once the notifications have been completed, determine the root cause of the exposure and implement a long-term solution.

Conclusion

So, "Is there safety in the cloud?" The answer seems to be a resounding "maybe." In the end, cloud computing is not the answer to all of our problems, but it could be the answer to some very specific ones. As IT professionals, we need to be wary of any solution that sounds too good to be true. We must be diligent about protecting institutional data, and we must sharpen our contract writing skills. The good news is that we can all be part of the discussion and learn from each other. Our answers to the questions will be different; the important thing is to have the conversation.

1. Rafal Wojtczuk, "Subverting the Xen Hypervisor," August 7, 2008.
2. Robert McMillan, "Amazon EC2 Cloud Harbours Botnet," ComputerWorldUK, December 10, 2009.
3. Reported in the March 10, 2010, SpamNews article "Legally Designed Cloud Computing Used for Malicious Purposes."
4. Neil McDonald, "Another Hypervisor Hack," March 14, 2010, blog entry for the Gartner Blog Network.
5. Tom Espiner, "Cloud Providers Shrug Off Liability for Security," ZDNet UK, February 12, 2010.
6. M. Peter Adler and Sharon R. Klein, Pepper Hamilton LLP, "Final Breach Notification Rule: The Countdown to Compliance," presented in a webinar August 25, 2009.

© 2010 Sharon Blanton and Craig Schiller. The text of this article is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license.