Cloud Security Risk Agreements for Small Businesses

Isaac Potoczny-Jones <ijones@galois.com>

PDF version.

ABSTRACT
Cloud computing can be particularly beneficial to small businesses since it can decrease the total cost of ownership for IT systems. Unfortunately, one of the major barriers to adoption of cloud services is the perception that they are inherently less secure, exposing the organization to unacceptable risk. There are standard processes for managing security risk that can help businesses make trade-off decisions, but these processes currently cannot be applied to cloud computing since the security details of cloud services are not typically available to small businesses. This lack of information leads to a lack of trust: small businesses cannot evaluate the security of cloud services. This paper proposes an approach for cooperation between cloud vendors and small businesses based on the NIST Risk Management Framework. Security Risk Agreements would address the lack of trust so that small businesses can confidently adopt cloud services, benefiting both small businesses and cloud vendors.

1.    INTRODUCTION
Cloud computing is the concept of offering remote network access to a set of IT resources [20], and it has the potential to be very valuable to small businesses since it can decrease the total cost of ownership of IT systems. However, one of the major barriers to adoption of cloud services is the perception that they are inherently less secure, exposing the organization to unacceptable risk [11]. This perception is based on the existence of vulnerabilities that are unique-to or amplified-by typical cloud-based architectural approaches and since cloud services are hosted remotely [16] [19] [20].

Risk-based security analyses such as NIST’s Risk Management Framework [23] are a widely-adopted method for making security decisions. Such a risk-based analysis of cloud services would allow a small business to make cost-benefit decisions about whether to deploy cloud services since they could analyze the vulnerabilities and implement security controls. However, the security details of cloud services are not typically available to a small business. This lack of information leads to a lack of trust: small businesses cannot evaluate the security of cloud services.

This paper proposes that cloud service providers should offer a Security Risk Agreement (SRA), which is a kind of Service Level Agreement (SLA) tailored to providing small businesses the information they need to evaluate whether a certain cloud service will meet their security requirements.

Increased trust will increase adoption, benefiting both the business and the cloud vendors. This type of agreement would address the widespread lack of trust in cloud security through an explicit and mutual understanding, based on a widely-adopted risk framework.

2.    BENEFITS TO SMALL BUSINESSES
Cloud computing is gaining attention since it is believed that it increases flexibility and decreases the cost of IT services. NIST defines cloud computing as, “a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction [20].”

The US federal Chief Information Officer Vivek Kundra has argued that cloud computing is economical, flexible, can be rapidly implemented, can improve consistency in service, can be more energy efficient, and can increase an organization’s ability to focus on its mission since it can spend less time and fewer resources on information technology [18].

For example, small Internet-based businesses which cannot predict their bandwidth, storage, and CPU utilization might appreciate the flexibility that services like Amazon’s EC2 system provide since they can automatically scale based on the required usage. Furthermore, services like Google Docs can provide capabilities, like word processing, that are enhanced with collaborative aspects since multiple users can modify a document simultaneously. For small user bases such cloud-based services are often free.

Cloud vendors and NIST both argue that cloud computing has some security advantages, and indeed can be more secure in some cases since, for instance cloud vendors have dedicated security teams [20]. For instance, Google has deployed multi-factor authentication [9] which increases the security of the login process.

All of these elements should make cloud computing attractive to small businesses, since they can save on investment in IT and security specialists.

3.    CLOUD RISK MANAGEMENT
As with any technology, such benefits are partly offset by the existence of risks, and in particular for cloud computing, security tops the list of concerns for most organizations [11].  Risk-based security analyses are a widely-adopted method for making security decisions and are required for federal systems covered by FISMA [23] and health-care related systems covered by HIPAA [29]. A risk-based analysis of cloud services would allow a small business to make cost-benefit decisions about whether to deploy cloud services since they explicitly weigh the impact of potential security problems against the cost of mitigating those problems. Processes for managing security risk have been developed by a number of organizations, but these processes are of limited applicability in cloud computing, since cloud vendors do not supply risk information about their services.

One risk analysis process is the Risk Management Framework (RMF) which is outlined in detail in NIST’s documentation [23] and involves understanding the impact of a loss of Confidentiality, Integrity, or Availability (CIA) to an organization’s data or systems. The impact of such a loss is categorized as low, moderate, or high, depending on the reputation, financial, and human costs of an event. For instance, a high impact security event might involve the loss of human life [21]. Based on this impact assessment, the process goes on to define steps for identifying vulnerabilities, selecting and deploying security controls to manage those vulnerabilities, and ongoing assessment and monitoring of their effectiveness.

When an organization stores its data in a cloud-based system, that system becomes a part of its IT infrastructure since a CIA failure in a cloud system would impact that organization’s data. Furthermore, the cost savings of cloud computing can be offset by the level of risk it imposes. Therefore, a small business’s cost/benefit analysis should include a risk analysis of those systems before moving the organization’s data to them.

4.    VULNERABILITIES AND SHARING
Cloud computing involves a number of vulnerabilities that are not present in traditional environments where an organization physically controls its own computing resources and does not share hardware or software resources with other organizations or the general public. The level of sharing between customers can vary greatly depending on the service. For the sake of argument, let’s say that for a given level of sharing, there is some possibility that a malicious individual is sharing resources with an organization that wishes to protect its data. A greater level of sharing implies a higher degree of risk (all other things being equal) since the pool of users is more likely to include malicious users. Small businesses, whose resources are subject to a high degree of sharing, are therefore subject to high risk.  This section outlines different sharing models (which are not mutually exclusive) and related vulnerabilities:

4.1.    Cloud Deployment Types
NIST defines three categories of cloud deployments: private, community, and public, and these each imply different types of sharing [20]. Private clouds are those that are owned or leased by an enterprise, and so involve the least amount of sharing. These are likely outside the scope of what a small business can afford, so will not be discussed further.

Community clouds are those that are shared by a set of organizations with some mutual trust. For example, Google’s “Apps for Government” system has a separate cloud for organizations that are required to be FISMA compliant [12].  This addresses a vulnerability that Mell & Grance point out: that data stored in the cloud could be subject to foreign governments’ legal actions [20]. Google addresses this by storing government data only within the US [17], but it doesn’t make that guarantee for public cloud customers like small businesses.

Public clouds are available to the general public and so involve the most sharing. These are the types of systems that most small businesses would use. The following sections outline other sharing models and related vulnerabilities that can apply to private, community, or public clouds. These vulnerabilities are probably more likely to have an impact in public clouds since they have a larger user pool, some of which might include malicious users.

4.2.    Multi-Tenant vs. Dedicated Tenant
Multi-tenant architectures allow multiple customers to use the same database and application instances [5]. Although there are mitigations, such architectures can lead to SQL injection vulnerabilities where malicious users issue queries against the database holding sensitive information. Furthermore, errors in access control enforcement can lead to inadvertent disclosure of data [26]. Dedicated tenant services host only a single customer, and so some such vulnerabilities might be more difficult, but this can come at the cost of performance.

4.3.    Virtualization Vulnerabilities
Virtualized systems run multiple virtual machines on a single physical host, and Gartner argues that such virtualized servers will be more vulnerable than physical servers for the next few years as organizations learn more about securing their systems [10]. One vulnerability is that confidential information can be leaked when a malicious user is able to execute a virtual machine on the same Local Area Network. For instance, researchers have demonstrated the ability to estimate traffic rates, perform side-channel attacks in order to extract key material, and use timing channels to send covert data between machines [27]. Another vulnerability is that if a malicious user is running a virtual machine on the same physical machine, there’s some potential that they can execute some code that will give them control over the operating system that is executing all of the virtual machines. This has been demonstrated in practice [28].

4.4.    General Vulnerability Classes
Other vulnerabilities are not necessarily specific to the method of deployment. Mell and Grance outline several general classes of security challenges [20] which include:

Customers must trust the cloud vendor’s security model. For instance, errors in the cryptographic implementation of cloud services could result in a loss of confidentiality of customer data as in [25]. In order to trust the cloud vendor’s security model, customers first need to understand the security claims made by the cloud vendor. For instance, the Dropbox cloud storage service has come under criticism for how it expressed security claims about its use of encryption, leading some customers to believe their data was cryptographically protected from Dropbox insiders [30] and resulting in an FTC complaint [31].

Customers cannot necessarily respond to audit findings, for instance, when a Linux vulnerability affecting EC2 was discovered [3] administrators could not address the issue until Amazon released corrected kernels [24].

Customers can have trouble obtaining support for investigations, for instance, if a security expert wishes to test their own EC2 service for vulnerabilities, they must request permission from Amazon, and certain types of testing are not permitted since it would affect other customers’ shared resources [4].

Proprietary implementations cannot be examined by the customer, for instance, one of the above vulnerabilities was visible to the public, and so was discovered by a customer, demonstrating the strength of transparency [25].

Customers lose physical control of the IT systems, for instance, data hosted in a foreign country is subject to their laws. Even laws in the US are unfavorable since, as is pointed out in [6], cloud vendors can be subpoenaed for a customer’s data, whereas if they stored the data themselves, a warrant would be required, which has a higher burden of proof.

5.    BARRIERS TO RISK-BASED ANALYSIS
Thus far this paper has outlined cloud computing’s potential benefits to small businesses, the necessity for small businesses to perform risk-based security analyses for cloud services, and the vulnerabilities that cloud computing is subject to. In order for small businesses and cloud vendors to reap the benefits of a shift to cloud services without small businesses having to sacrifice their ability to perform such analysis, cloud vendors should provide service-level agreements that include risk-based guarantees about the level of security of their infrastructure.

Cloud vendors understand the necessity of risk analysis, at least in their engagements with the US federal government. Google and Microsoft both already provide FISMA compliant cloud services for government clients [8] [12], which involves risk-based analysis, but no such commitment is made to the general public. Cloud vendors also provide SLAs relating to performance and availability, and these agreements have reimbursement clauses which offer financial guarantees [2] [14], but no such guarantee is provided with regard to confidentiality and integrity.

Cloud vendors also recognize the importance of conveying the security of their infrastructure [1] [7] [15], likely because they understand that security is a major barrier to adoption. However, while these assurances are some comfort, they do not come with a guarantee, and are insufficient for risk management.

6.    SECURITY RISK AGREEMENTS (SRAs)
When a small business adopts cloud computing, they are outsourcing part of their IT infrastructure, and they therefore also must outsource some aspects of their risk management. A Security Risk Agreement should include principles of transparency and communication between the cloud vendor and the small business, the definition of security incidents and their severity, what level of guarantee the vendor is offering against incidents, and the consequences of a loss of confidentiality or integrity (availability being well defined in current SLAs). With that in mind, this section briefly outlines the steps of the Risk Management Framework [23] and what roles the small business and the cloud vendor play in each step.

Step 1: Categorize the information system. In this step, the small business acts as the Information Owner/Steward and identifies the impact of a loss of confidentiality, integrity, or availability for its data: low, moderate, or high. The cloud vendor acts as the Information System Owner and will declare what level of impact their system can be authorized to handle. Some cloud vendors might only be trusted to handle low-impact data, but can potentially provide this service at a lower cost than a vendor who can handle moderate- or high-impact data.

Steps 2-3: Select and implement security controls. In these steps the set of security controls (mitigations) from NIST 800-53 [22] are selected and implemented by a combination of the cloud vendor and the small business. NIST divides security controls into a number of families, and within each family, some controls will be more naturally the accountability of the business and some of the cloud vendor. Since each business has unique security needs, each will likely want to identify a baseline set of must-have security controls and select vendors which are known to implement those security controls. Furthermore, the business might be required to implement some security controls in order to make up for a lack of controls from the cloud service (e.g. implementing encryption in the transport layer to make up for the lack of a virtual private network). For each family of security controls, one party bears the primary accountability for selecting and implementing the controls from that category, and that accountability is summarized in Table 1.

Table 1. Proposed Primary Accountability for NIST 800-53 Security Control Families

Step 4: Assess the effectiveness of the security controls. NIST emphasizes the importance of the independence of a security assessor. Since this assessment can largely be shared among all the customers of a cloud service, and since the details of some identified weaknesses (arguably) should not be made known to the general public, a neutral third party should be available to assess the controls and to communicate the high-level results, including the level of residual risk, to the small businesses. Furthermore, businesses must be permitted to perform their own assessments since they might have unique security concerns.

Step 5: Authorize the information system. The cloud vendor should provide a plan to its customers to correct any weaknesses. The small business must be accountable for determining the level of risk to the organization and determining if that level of risk is acceptable.

Step 6: Monitor security controls. Ongoing monitoring is the shared responsibility of the cloud vendor, the small business, and the security assessor. A security impact analysis of proposed changes must be performed by the cloud vendor and reported to the small business so that the business can assess the impact of that change on its corporate risk. Furthermore, businesses should be notified in advance of any change in security and either have the option to opt-out of a change or be given time to transition to a different vendor.

7.    CONCLUSION
At the same time that cloud computing is becoming ubiquitous, computer security is increasingly a concern for all businesses large and small. However, current service-level agreements between small businesses and cloud vendors do not allow for risk-based analysis of security by those businesses. This paper discusses both the value and the vulnerabilities of the shift to cloud computing and argues for a new practice in cloud business arrangements: the Security Risk Agreement. Such agreements will provide both parties with a clear understanding of their roles and accountabilities to one-another. This will help to avoid the kinds of mismatched expectations about security controls that can hurt both cloud service providers and their customers, as was the case regarding technical details of Dropbox’s encryption. This paper provides an initial overview of the roles of each party in the context of NIST’s Risk Management Framework. Security Risk Agreements address the major barrier to adoption of cloud computing: business’s trust that their data will be handled with an appropriate level of security.

8.    REFERENCES
[1]     Adams, S. 2010. Microsoft’s Cloud Infrastructure – FISMA Certified. FutureFed. http://blogs.msdn.com/b/uspublicsector/archive/2010/12/03/microsoft-s-cloud-infrastructure-fisma-certified.aspx.

[2]    Amazon. 2007. Amazon S3 SLA. Amazon Web Service http://aws.amazon.com/s3-sla/.

[3]    Amazon. 2009. Linux kernel vulnerability in certain EC2 AMIs.  Amazon Web Services. http://aws.amazon.com/security/security-bulletins/linux-kernal-vulnerability-in-certain-ec2-amis/.

[4]    Amazon. Penetration testing [policy]. Amazon Web Services. http://aws.amazon.com/security/penetration-testing/.

[5]    Bezemer, C. P. and Zaidman, A. 2010. Multi-tenant SaaS applications: maintenance dream or nightmare?. Proceedings of the Joint ERCIM Workshop on Software Evolution (EVOL) and International Workshop on Principles of Software Evolution (IWPSE), New York, NY, USA, pp. 88–92.

[6]    Brenner, S. W. 2006. Cybercrime and the U.S. criminal justice system. in Handbook of information security, vol. 2, H. Bidogli, Ed. NY, NY: John Wiley & Sons, Inc.

[7]    Dropbox. 2011 How secure is Dropbox? https://www.dropbox.com/help/27.

[8]    Estberg, M. 2010. Microsoft’s cloud infrastructure receives FISMA approval. Global foundation services blog. http://blogs.technet.com/b/gfs/archive/2010/12/02/microsoft-s-cloud-infrastructure-receives-fisma-approval.aspx.

[9]     Feigenbaum, E. 2010. A more secure cloud for millions of Google Apps users.  Official Google Enterprise Blog. http://googleenterprise.blogspot.com/2010/09/more-secure-cloud-for-millions-of.html.

[10]    Gartner. 2010. Gartner says 60 percent of virtualized servers will be less secure than the physical servers they replace through 2012. http://www.gartner.com/it/page.jsp?id=1322414.

[11]    Gens, F. 2008. Cloud Services User Survey, pt.2: Top Benefits & Challenges.  http://blogs.idc.com/ie/?p=210.

[12]    Google. FISMA-certified cloud applications for government. Google Apps for business. http://www.google.com/apps/intl/en/government/trust.html.

[13]    Google. Google Apps for business online agreement http://www.google.com/apps/intl/en/terms/premier_terms.html.

[14]    Google. Google Apps service level agreement. http://www.google.com/apps/intl/en/terms/sla.html.

[15]    Google. Software-as-a-service has built-in security advantages.  Google Apps for business. http://www.google.com/apps/intl/en/business/infrastructure_security.html.

[16]    Gruschka, N and Jensen, M. 2010. Attack Surfaces: A Taxonomy for Attacks on Cloud Services. Proceedings of the 2010 IEEE 3rd International Conference on Cloud Computing, Washington, DC, USA, pp. 276–279.

[17]    Krishnan, K. 2010. Introducing Google Apps for Government. Official Google Blog. http://googleblog.blogspot.com/2010/07/introducing-google-apps-for-government.html.

[18]    Kundra, V. 2010. State of Public Sector Cloud Computing. Chief Information Officers Council.

[19]    Li, H. C., Liang, P. H, Yang, J. M, and Chen, S. J. 2010. Analysis on Cloud-Based Security Vulnerability Assessment. E-Business Engineering, IEEE International Conference on, Los Alamitos, CA, USA, 2010, vol. 0, pp. 490-494.

[20]    Mell, P and Grance, T. 2009. Effectively and securely using the cloud computing paradigm.

[21]    National Institute of Standards and Technology. 2004. Federal Information Processing Standards Publication, Standards for Security Categorization of Federal Information and Information Systems (FIPS PUB 199).

[22]    National Institute of Standards and Technology. 2009. Recommended Security Controls for Federal Information Systems and Organizations (SP 800-53 Revision 3).

[23]    National Institute of Standards and Technology. 2010. Guide for applying the risk management framework to federal information systems (SP 800-37).

[24]    ObReiman. 2009. Kernel vulnerability affects EC2: NULL pointer dereference. AWS Developer Forums https://forums.aws.amazon.com/message.jspa?messageID=142144.

[25]    Percival C. 2008. AWS signature version 1 is insecure. Daemonic Dispatches. http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html.

[26]    Rane, P. Securing SaaS Applications. Information Systems Security.http://www.infosectoday.com/Articles/Securing_SaaS_Applications.htm.

[27]    Ristenpart, T., Tromer, E., Shacham, H., and Savage, S. 2009. Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds. Proceedings of the 16th ACM conference on Computer and communications security. New York, NY, USA, pp. 199–212.

[28]    Secunia. 2007. Xen multiple vulnerabilities – advisories. Secunia security. http://secunia.com/advisories/26986/

[29]    Scholl, M. et al. 2008. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. National Institute of Standards and Technology.

[30]    Soghoian, C. 2011. How Dropbox sacrifices user privacy for cost savings. Slight paranoia: http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-user-privacy-for.html

[31]    Soghoian, C. 2011. In the matter of Dropbox, Inc. Request for investigation and complaint for injunctive relief. FTC Complaint.

[32]     Wojtczuk, R. 2008. Subverting the Xen hypervisor. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167.5640&rep=rep1&type=pdf