Patrick Kamongi
University of North Texas, Denton, TX, USA
Cloud computing technologies support delivery and consumption of computing resources and products as on‐demand services. At the core of a cloud ecosystem, we observe five key actors (cloud consumer, cloud provider, cloud carrier, cloud auditor, and cloud broker), as defined in the National Institute of Standards and Technology (NIST) “Cloud Computing Reference Architecture” (http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909505) and shown in Figure 5.1.
From the view of cloud system actors, there is a one‐to‐many interaction between them, as illustrated in Figure 5.2. At the service layer (shown in Figure 5.1), we can think of various abstracted interactions between the cloud provider via the cloud carrier to the cloud consumer, and vice versa. These interactions may use different service models, notably Infrastructure‐as‐a‐Service (IaaS), Platform‐as‐a‐Service (PaaS), and Software‐as‐a‐Service (SaaS). When architecting and consuming on‐demand cloud services, it is important to keep in mind the potential for software failures that could compromise data confidentiality, integrity, or availability.
In this chapter, our focus is on security and privacy of the SaaS cloud model architecture, deployment, and usage from the cloud provider, carrier, and consumer point of view. SaaS is defined as capabilities given to the consumer to facilitate the use of the provider applications running on a cloud infrastructure (these are not limited to the IaaS but can also rely on some aspects of the previously mentioned key actors). In the next section, we highlight some of the top SaaS security and privacy challenges and how they affect both cloud providers and consumers.
The idea of a cloud SaaS consumer accessing a service (i.e. application) on demand without worrying about how it is hosted or maintained is appealing. This idea drives the adoption of cloud‐hosted SaaS. On the other hand, the SaaS provider has a large pool of available cloud infrastructure resources to meet all the needs of its consumers in terms of some key characteristics that a true SaaS service should exhibit. For instance:
In a perfect world, the functionalities of a SaaS application should meet consumer service‐level needs. However, in reality, there is a need to ensure the security and privacy of the service for both the consumer and provider to meet applicable compliance requirements.
For a given SaaS application, we should question the extent to which the following important security issues (Patel and B.S. 2014), among many others, are being addressed:
These issues must be addressed to meet the security and privacy requirements of the consumer subscribing to the SaaS application. NIST has published a draft document, “Cloud Computing Security Reference Architecture” (http://collaborate.nist.gov/twiki‐cloud‐computing/pub/CloudComputing/CloudSecurity/NIST_Security_Reference_Architecture_2013.05.15_v1.0.pdf), that provides technical guidance on how to model, securely architect, and deploy the Cloud from the ground up while addressing the needs of all key cloud actors (i.e. consumer, provider, broker, auditor, and carrier), service orchestration models (IaaS, PaaS, and SaaS) and deployment modes. We recommend this NIST draft and forthcoming cloud security publications as foundational reference documents for architecting and deploying any cloud service.
In the next sections, we present formal and practical solutions for performing and enforcing security and privacy analysis of cloud SaaS applications.
From the SaaS application‐provider's view, security is part of the process of designing, developing, deploying, and maintaining the application; whereas from the consumer's view, the security aspect of the application is leveraged after the application has been deployed.
At any point in time, the consumer or provider can determine the key components (inventory) that make up the offered SaaS application and then use them as a baseline set of configurations for analyzing the security of the application. Vulnerability assessment (Heck 1999) is one security aspect of interest. The process involves identification, quantification, and ranking of the vulnerabilities facing a system (or, in our case, a cloud application).
For instance, we can use an automated framework for assessing a cloud system's vulnerabilities, such as VULCAN (Kamongi et al. 2013) shown in Figure 5.3. A typical VULCAN assessment proceeds as follows:
An example use of the VULCAN framework is presented in Section 5.4. We illustrate how a prototype web application of the VULCAN framework (shown in Figure 5.4) can assess the vulnerability of a sample of applications in a Microsoft Office 365 (https://products.office.com/en‐us/home) subscription, shown in Table 5.1.
Table 5.1 A couple of applications within an Office 365 subscription.
Products (in CPE Format) |
|
|
An alternative way to assess vulnerability, beyond using an open source framework like VULCAN, is to use any suitable commercial vulnerability‐scanner solution, like those listed at https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools.
Upon identifying the SaaS application's vulnerabilities, it is important to develop and implement strategies to reduce their potential impact and mitigate risk exposure.
To estimate the real or perceived risk of any SaaS application, we can use a threat‐centered approach. After first performing rigorous threat modeling of a given application, we can estimate the risk of each of the modeled threats. Depending on the SaaS application domain, a proper threat classification can be defined. For example, the classification can be based on threat actors, assets, etc.
“Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level” (https://msdn.microsoft.com/en‐us/library/ee823878(v=cs.20).aspx).
For example, we can leverage an open source solution like Nemesis, which is an automated architecture for threat modeling and risk assessment of cloud computing assets (Kamongi et al. 2014). The Nemesis architecture is illustrated in Figure 5.5.
For a given cloud SaaS application, Nemesis requires the user to input details about the configuration of the application's components. The unified Nemesis framework then processes this information as follows:
These simplified and highly abstracted automated solutions provide a rigorous threat model and risk assessment of the analyzed SaaS application. Consumers can benefit from Nemesis' capabilities even though they have limited access to the backend application configurations – they can use client‐side configuration details facing the SaaS application being used. On the other hand, the SaaS application provider can use Nemesis' features in a similar fashion, with full assessment coverage, by providing a complete inventory of the IT products used to develop the offered SaaS application. In addition, the provider will be in a unique position to take into consideration the new recommended cloud configurations to reduce risk and improve their SaaS application security posture in their next release update.
A prototype web application that uses the Nemesis architecture is illustrated in Figure 5.6. It can be used to perform threat modeling and risk assessment for any cloud application (e.g. those in Table 5.1).
The SaaS application provider can incorporate risk management early in the application design and development processes to ensure delivery that is secure and that meets consumer security and privacy needs. During the architecture‐planning phase, we can refer to the NIST Cloud Computing Security Reference Architecture (http://collaborate.nist.gov/twiki‐cloud‐computing/pub/CloudComputing/CloudSecurity/NIST_Security_Reference_Architecture_2013.05.15_v1.0.pdf), which suggests these steps (abstracted here):
Note that these steps can be applied to a cloud SaaS application consumer as well, as in the case where a consumer is running an application locally and wants to migrate to a cloud‐based SaaS offering.
Moving toward a more checklist‐oriented approach to ensure that the needed security and privacy controls are in place for the delivered cloud SaaS application, we can use the Cloud Security Alliance (CSA) cloud controls matrix (CCM) framework (https://cloudsecurityalliance.org/download/cloud‐controls‐matrix‐v3‐0‐1). The framework is described as follows:
Within this framework, for every mentioned control domain, there is a control specification and a mapping to how it is applicable to the cloud service delivery model (i.e. IaaS, PaaS, and SaaS) via a checklist model approach.
The VULCAN framework, Nemesis architecture, and other supporting tools have been integrated into a holistic suite of tools called Cockatoo. These tools are integrated to form an automated solution for security risk assessment and mitigation for any cloud system that powers various cloud offerings (e.g. Office 365).
The Cockatoo toolchain (http://csrl.unt.edu/content/cockatoo‐toolchain) offers a helping hand to address the need for a cloud‐security and privacy‐management solution. An example workflow of the Cockatoo toolchain is illustrated in Figure 5.7. Cockatoo can be used via a managed web interface to assess a given cloud application's configuration. When applicable, an authenticated user (cloud consumer/provider) can perform:
A look at a cloud SaaS application's privacy assessment from the consumer and provider perspectives is presented in the next section.
A privacy assessment starts with the SaaS provider and consumer data privacy policy negotiation which is documented in a Security Service Level Agreement (SSLA). Once the desired privacy policy is finalized, the task remains to identify and mitigate any threat that could violate the agreement.
An approach to identifying and resolving privacy threats has been presented in the work by (Smolen 2010), which provides a context for when privacy threats occur (i.e. when data is leaked in a transaction that violates the desired privacy policy). The following set of questions should be used to determine the potential severity of any such transaction:
Once a privacy threat has been identified on either the consumer or provider side of the SaaS application, it should be logged. Then, a review process should address the threat accordingly using a relevant mitigation technique that considers how the data is processed.
(Deng et al. 2011) proposed a systematic approach for privacy threat modeling (called LINDDUN) to elicit the privacy requirements of software‐intensive systems (which may be applicable to cloud SaaS applications as well) and select privacy‐enhancing technologies accordingly. In this framework, the privacy threat types (Linkability, Identifiability, Non‐repudiation, Detectability, Disclosure of information, Content Unawareness, Policy, and consent Noncompliance) are obtained by negating privacy properties (Unlinkability, Anonymity, Pseudonymity, Plausible deniability, Undetectability, Unobservability, Confidentiality, Content awareness, Policy, and consent compliance).
The LINDDUN framework enables an analyst to identify privacy threats of a software‐based system or an SaaS application (which is our interest here), by modeling the application using a data flow diagram (DFD) and then mapping it to relevant privacy threats. Note that these privacy threats can be elaborated via threat‐tree patterns and reinforced by leveraging misuse cases as described in (Deng et al. 2011). Privacy‐enhancing solutions are added accordingly.
In this section, we cover some important aspects of securing any given cloud SaaS application while preserving privacy from the consumer and provider perspectives.
At any point in time, the cloud SaaS provider should be able to receive security and privacy requirements from a potential consumer and negotiate a favorable course of action. Likewise, the cloud SaaS application provider can impose new requirements on the host cloud infrastructure vendor (provider). This approach extends the initial contract (SSLA) negotiation between the vendor/provider and consumer. The SSLA helps to assess the security and privacy of any cloud provider offerings before the initial subscription or during a renegotiation process. Ontologies for SSLAs (Lee et al. 2015) have been proposed to aid understanding and comparison of SSLAs from different providers and facilitate their adoption.
Using a SSLA, a consumer can negotiate with their SaaS application provider regarding the security and privacy requirements imposed by their specific use cases and how the provider will demonstrate compliance with those requirements. Areas to explore for suggested best practices to incorporate into the SSLA, from the consumer point of view, can be found in the NIST Cloud Computing Synopsis and Recommendations, (http://csrc.nist.gov/publications/nistpubs/800‐146/sp800‐146.pdf):
Also, the SaaS provider should negotiate a SSLA with their cloud infrastructure provider to exhibit these attributes in a more concise way:
This list of recommended best practices can only serve as a starting point due to the variety of SaaS applications available. Best practices applicable to each application should be tailored uniquely to ensure that specific security and privacy needs are properly addressed.
The Microsoft Office 365 cloud subscription offers a variety of high‐end productivity solutions geared for personal and business use, including Microsoft Office (offline/online versions), cloud storage, Skype, e‐mail, social networking services, and so on.
An article by the Microsoft Office 365 team (https://docs.microsoft.com/en‐us/office365/securitycompliance/protect‐against‐threats) pinpoints some of the most prevalent threats (notably spoofing, malware, spam, phishing attempts, and unauthorized access to data) facing the adopters of Office 365. The article also provides best practices that an organization (that uses Office 365) can use to protect against a variety of threats.
Referring back to our earlier discussion on security and privacy analysis, a product like Office 365 should receive assessment considerations from both the consumer's and provider's point of view, on a real‐time basis, to ensure that:
An example workflow of a vulnerability assessment of Office 365 applications using the VULCAN framework (web application shown in Figure 5.4) would proceed as follows:
Using the Nemesis architecture, some example outputs of a security risk assessment for our selected Office 365 applications (shown in Table 5.1) are as follows:
A key takeaway from the security and privacy assessment of a SaaS product like Office 365 is that we must thoroughly analyze any security or privacy threat facing the consumer and provider. This requires thinking about the interactions between shared technologies (and their compositions) and possible user interactions over the provided cloud SaaS while leveraging automated solutions wherever possible. In addition, we should realize that security is a shared responsibility, where a given cloud service provider does its share of securing the product, and consumers apply recommended security solutions either from the provider or from a third party (e.g. cloud access security brokers, threat intelligence providers, specialized solutions for one or more part(s) of the cloud SaaS application, and so on).
Although many cloud SaaS application vulnerabilities can be identified and mitigated effectively from both the consumer and provider points of view, new threats continue to emerge. This reality is reaffirmed almost daily by revelations of major data breaches and cyber attacks; but several risk‐mitigation approaches are available, including the following:
A holistic solution to this SaaS challenge should be agile in terms of using a security and privacy framework during the design, development, deployment, and maintenance stages. A futurist approach should implement a holistic solution using automated systems capable of defending against cyber attacks and privacy violations in real time.
Recommended reading for more information on major security issues in cloud environments is available in (Sen 2013), which discusses the following:
A security white paper by Hightail (www.hightail.com) provides a useful guide for assessing a cloud SaaS provider from the consumer's point of view. The guide explores multiple security layers for cloud‐based sharing services with a focus on:
For each of these topics, the white paper presents details on some best practices for assessing cloud SaaS provider offerings.
(Rashmi et al. 2013) present a collection of current solutions available for securing SaaS based on the following areas:
A good recommended work on privacy in the cloud environment is an ITU‐T Technology Watch report (Guilloteau and Mauree 2012). This report provides a detailed discussion of various challenges posed by cloud computing and the standardization work being done by various standards development organizations (SDOs) to mitigate privacy risks in the Cloud, including the role of privacy‐enhancing technologies (PETs).
Any provider or consumer of a cloud SaaS application should maintain situational awareness of their security and privacy status by doing the following:
In this chapter, we have presented some key research contributions to the state of the art using a holistic approach to assessing and managing cloud SaaS application security and privacy threats. We have also recommended preferred security and privacy solutions that any cloud provider/consumer should adopt.