5.1 Introduction and Background

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:

• The ability to tailor the application to meet consumer requirements and needs
• Quick and timely pushing of software updates with negligible impact to application availability
• The delivery of a service that can be leveraged by other systems via cloud carrier‐supported protocols
• Support for collaboration and sharing of data among consumers

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:

• Authentication and authorization
• Availability
• Information security
• Data access
• Network security
• Data breaches
• Identity management and sign‐on process

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.

5.2 Security and Privacy Analysis

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.

5.2.1 Vulnerability Assessment

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:

• A user provides two primary inputs to the system with the first being, for example, “SaaS application configurations” (this data is provided to the System Classifications module of the VULCAN framework). The second input is a natural‐language query such as, “Assess for weaknesses that could allow an unauthorized access to my application.” This query is processed within the VULCAN Semantic Natural Language Processor (SNLP).
• The System Classifications module generates possible SaaS application‐based solutions and feeds them to the Indexer module. The Indexer then creates relevant vulnerability indexes, which are used to produce vulnerability groups from the Vulnerability Class Index module.
• The SNLP component performs reasoning tasks on the user query using the created vulnerabilities group data. Relevant results are returned to the user (SaaS application consumer or provider) via a dialogue agent interface. The results may include IT products that have vulnerabilities and other information relevant to the user's query.
• Using VULCAN's middleware application, we can also perform live penetration testing (assuming the user has the required permissions).
• VULCAN then reports the vulnerability status of the given SaaS application.

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.

Products (in CPE Format)
cpe:/a:microsoft:office:2016
cpe:/a:microsoft:skype_for_business:2016

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.

5.2.2 Risk Exposure Assessment and Management

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:

• Measurements are collected about what type of known vulnerabilities exist for the given cloud's assets.
• For each applicable vulnerability found, Nemesis explores how the vulnerability can be exploited and looks for ways it can be mitigated.
• The previous details are used to generate a set of customized outputs such as these:
  • An estimated value of aggregated risk.
  • Metrics for exploitable vulnerabilities.
  • Ranking of threat types by severity.
  • New recommended cloud configurations with a lower risk, along with a detailed summary of relevant Nemesis evaluation data.

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):

1. Categorize the information system.
2. Identify security requirements, and perform a risk assessment to identify security components (confidentiality, integrity, availability [CIA] analysis), and select security controls.
3. Select the best‐fitting architecture (from the cloud infrastructure provider).
4. Assess service provider(s).
5. Approve use of service.
6. Monitor the service provider (to ensure a reliable platform has been configured on which to build their SaaS offerings).

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:

• Provides fundamental security principles to guide cloud vendors and to assist cloud customers in assessing the overall security risk of a cloud provider.
• Strengthens information security control environments by delineating control guidance by service provider and consumer, and by differentiating according to cloud model type and environment.
• Provides a controls framework in 16 domains that are cross‐referenced to other industry‐accepted security standards, regulations, and control frameworks to reduce audit complexity.
• Seeks to normalize security expectations, cloud taxonomy and terminology, and security measures implemented in the Cloud.

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 manual or automated guided/unguided collection of telemetry data for any given IT system/application.
• An on‐demand vulnerability assessment task for the IT system/application.
• An on‐demand threat modeling and risk assessment of the IT system/application.
• An automated large‐dataset generation for machine learning experiments to predict the number of unknown vulnerabilities in a given software product.
• An on‐the‐fly prediction of the number of unknown vulnerabilities in a specific software product release/version.

A look at a cloud SaaS application's privacy assessment from the consumer and provider perspectives is presented in the next section.

5.3 Best Security Practices and Recommendation

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):

• Consumer‐side vulnerabilities
• Encryption
• Authentication
• Identity and access management
• Visibility
• Data protection and privacy
• Client device/application protection
• Secure data deletion

Also, the SaaS provider should negotiate a SSLA with their cloud infrastructure provider to exhibit these attributes in a more concise way:

• Provider assessment
• Supplementary backup
• Physical isolation (if it is critical to the offered SaaS application)
• Logical isolation (highly recommended)
• Encryption (of the data at rest and secured channel of communication)
• Infrastructure automation (ensure that it is done in a secure way)
• Virtualization implications (specific to the security of the virtual environment)
• Guest hardening (tailored to the offered SaaS application)

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.

5.4 Use Case Example: Microsoft Office 365, SaaS Version

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:

• A proper vulnerability assessment on all Office 365 products (along with their hosting infrastructure and delivery platforms) is done to ensure that any known or discovered vulnerability is quickly patched and mitigated.
• A security risk assessment is performed (taking into account the offered and consumed products, services, and users' interactions) to stay ahead of any threats and drive informed decisions to mitigate them.
• The privacy policy is not violated and is maintained to reflect user needs.
• The SSLA should offer some guarantees to the adopters of Office 365 and ensure that data security and privacy requirements for subscribed products are being met (i.e. comply with the SSLA).

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:

• Via the Assess window, a cloud provider/consumer can use the LEGOS tool to add the Office 365 application's configuration (e.g. shown in Table 5.1) information to assess vulnerabilities. A vulnerability index ontology knowledge base (OKB) is then generated for the supplied configurations (illustrated in Figures 5.8–5.10). Figure 5.8 illustrates over 2000 semantic facts captured by the information found about known vulnerabilities, exploits, and patches that impact the indexed Office 365 products. Figure 5.9 provides insight into the generated vulnerability index; we can see how the found vulnerabilities affect not only the original tasked products (shown in Table 5.1), but also other related products.
• Via the Report window, the user can then initiate the generation of a Vulnerability Assessment Report by selecting the generated vulnerability index OKB. The vulnerability report is rendered on‐the‐fly as shown in Figure 5.11. For example, the generated report informs the user about the overall vulnerability status of the assessed Office 365 products via the Executive Summary section, and the Vulnerability View section provides a thorough account of all found vulnerabilities that affect the assessed Office 365 products, etc.
• Via the Query window, the user can invoke the VULCAN/Chatbot service to get answers to any questions they may have about the generated Vulnerability Assessment Report or any publicly known vulnerability.

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:

• Figure 5.10 visualizes the found vulnerabilities that have publicly known exploits. Each of these assertions can also be rendered via the Nemesis web application Threat Modeling window, Exploitable Vulnerabilities Tab (shown in Figure 5.6). A Nemesis rendered exploitable vulnerabilities example is shown in Figure 5.12.
• Figure 5.13 shows the percentage of classified STRIDE (https://msdn.microsoft.com/en‐us/library/ee823878(v=cs.20).aspx) based threat‐type instances that could be exploited due to the presence of any of the found vulnerabilities.
• Figure 5.14 shows the severity rank of classified STRIDE‐based threat type instances inferred from the severity of the found vulnerabilities.
• A risk score can be computed (using Nemesis' implementation of an ontology and Bayesian‐based threat‐probability model (Fenz 2011; Kamongi et al. 2014) and rendered via the “Risk score” shown in Figure 5.6 (Risk Assessment window).

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).

5.5 Current Trends and Future Direction

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 continued push for exploring and adopting various vulnerability‐management solutions.
• Using a secure hosting solution or privately developing a security team to actively monitor events at the host and network levels, then evaluating and mitigating any detected incident.
• Adoption of third‐party or private solutions that seek to provide additional layers of security (i.e. defense in depth). Leveraging threat intelligence provides early warnings of impending threats and also exposes contextual and actionable details for any indicator of compromise (IOC).
• Using various security and privacy compliance standards tailored to specific industries (i.e. health, financial, etc.).

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.

5.6 Related Works

Recommended reading for more information on major security issues in cloud environments is available in (Sen 2013), which discusses the following:

• Threats against information assets residing in cloud computing environments.
• Types of attackers and their capability of attacking the Cloud.
• Security risks associated with the Cloud, including common attacks and countermeasures.
• Emerging cloud security risks.
• Some example cloud security incidents.

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:

• What to look for in an information security program.
• The importance of application architecture for a secure environment.
• How to think about data security.
• Correctly assessing systems and network security.
• Key areas to focus on when determining data‐center security.

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:

• Authentication and authorization
• Availability, data confidentiality, and VM security
• Information and network security
• Cloud standards and data access
• Web application security, data breaches, and backups
• Identity management and sign‐on process

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).

5.7 Conclusion

Any provider or consumer of a cloud SaaS application should maintain situational awareness of their security and privacy status by doing the following:

• Identify and document security and privacy requirements.
• Perform a real‐time vulnerability assessment of cloud assets.
• Proactively assess and track any relevant security and privacy threats.
• Perform risk assessment based on the identified threats.
• Proactively leverage proven processes, methods, and tools to mitigate perceived risks.

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.

Acknowledgments

• Takabi, Hassan, University of North Texas, USA
• Kavi, Krishna, University of North Texas, USA
• Gomathisankaran, Mahadevan, University of North Texas, USA
• Struble, David G., University of North Texas, USA

References

1. Deng, M., Wuyts, K., Scandariato, R. et al. (2011). A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements. Requirements Engineering 16 (1): 3–32.
2. Fenz, S. (2011). An ontology‐and Bayesian‐based approach for determining threat probabilities. In: Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security. ACM.
3. Guilloteau, S. and Mauree, V. (2012). Privacy in cloud computing. ITU‐T Technology Watch Report.
4. Nathan Heck. (1999). Best practices for vulnerability assessments. Presentation. https://slideplayer.com/slide/5683363.
5. Patrick Kamongi, Mahadevan Gomathisankaran, and Krishna Kavi. (2014). Nemesis: automated architecture for threat modeling and risk assessment for cloud computing. Paper presented at the Sixth ASE International Conference on Privacy, Security, Risk and Trust (PASSAT) in Cambridge, MA (December 13–16, 2014).
6. Patrick Kamongi, Srujan Kotikela, Krishna Kavi et al. (2013). VULCAN: vulnerability assessment framework for cloud computing. In: Proceedings of The Seventh International Conference on Software Security and Reliability. SERE (SSIRI) 2013. IEEE, 218–226).
7. Lee, Chen‐Yu, Kavi, Krishna M., Paul, Raymond et al. (2015). Ontology of secure service level agreement. In: Proceedings of the 2015 IEEE 16th International Symposium on High Assurance Systems Engineering (HASE). IEEE, 166–172.
8. Patel, N.S. and Rekha, B.S. (2014). Software as a Service (SaaS): security issues and solutions. International Journal of Computational Engineering Research 2250–3005.
9. Rashmi , G. Sahoo, and S. Mehfuz. (2013). Securing software as a service model of cloud computing: issues and solutions. arXiv preprint arXiv:1309.2426.
10. Sen, J. (2013). Security and privacy issues in cloud computing. In: Architectures and Protocols for Secure Information Technology Infrastructures, 1–45. IGI Global.
11. Alex Smolen. (2010). Privacy design analysis: a framework for identifying and resolving privacy threats. Paper presented at CHI 2010, Atlanta, Georgia (April 10–15, 2010).