9
Security‐as‐a‐Service (SECaaS) in the Cloud

Saman Taghavi Zargar1, Hassan Takabi2, and Jay Iyer1

1Office of CTO Security Business Group, Cisco Systems, San Jose, CA, USA

2Department of Computer Science and Engineering, University of North Texas, Denton, TX, USA

9.1 Introduction

Cloud computing has gained extensive interest within both academic and industry communities. It tries to consolidate the economic utility model with the evolutionary development of many existing approaches and computing technologies including distributed services, applications, and information infrastructures consisting of pools of computers, networks, and storage resources (Cloud Security Alliance 2009). Confusion exists in information technology (IT) communities about how the Cloud is different from existing models and how these differences might affect its adoption. Some see the Cloud as a novel technical revolution while others consider it a natural evolution of technology, economy, and culture (Cloud Security Alliance 2009). Nevertheless, cloud computing is a very important paradigm that provides tremendous potential for significant cost reduction through optimization and the increased operating and economic efficiencies in computing (Cloud Security Alliance 2009; Mell and Grance 2009). Furthermore, cloud computing has the potential to significantly enhance collaboration, agility, and scale, thus enabling a truly global computing model over the internet infrastructure.

While several researchers have tried to define cloud computing, there is no single agreed‐upon definition. Its definitions, issues, underlying technologies, risks, and values need to be refined. These definitions, attributes, and characteristics have been evolving and will change over time. The U.S. National Institute of Standards and Technology (NIST) defines cloud computing as follows: “Cloud computing is 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. This cloud model promotes availability and is composed of five essential characteristics, three delivery models, and four deployment models” (Mell and Grance 2009). In order to understand the importance of cloud computing and its adoption, we need to understand its principal characteristics, its delivery and deployment models, how customers use these services, and how these services need to be safeguarded. The five key characteristics of cloud computing are on‐demand self service, ubiquitous network access, location‐independent resource pooling, rapid elasticity, and measured service, which are geared toward allowing the seamless and transparent use of clouds. Rapid elasticity allows resources provisioned to be quickly scaled up (or down). Measured services are primarily derived from properties of the business model and indicate that the cloud service provider controls and optimizes the use of computing resources through automated resource allocation, load balancing, and metering tools (Takabi et al. 2010a).

The cloud computing paradigm ignited the rapid growth of novel virtualization methods (i.e. containers vs. hypervisors (Soltesz et al. 2007)), the emergence of the Internet of Everything (IoE), and the rapid adoption of smartphones that led to the evolution of business applications and systems worldwide. At the same time, there is an increasing trend of security threats against these assets by malicious entities. Applications running on or being developed for cloud computing platforms pose various security and privacy challenges depending on the underlying delivery and deployment models. Three key cloud delivery models are Software‐as‐a‐Service (SaaS), Platform‐as‐a‐Service (PaaS), and Infrastructure‐as‐a‐Service (IaaS). In IaaS, the cloud provider provides a set of virtualized infrastructural components such as virtual machines and storage on which the customers can build and run applications. The most basic components are a virtual machine (VM) and the virtual operating system (OS) where the application will eventually reside. Issues such as trusting the VM image, hardening hosts, and securing inter‐host communication are critical areas in IaaS. PaaS enables the programming environments to access and utilize the additional application building blocks. Such programming environments have a visible impact on the application architecture. One such impact would be that of the constraints on what services the application can request from an OS. For example, a PaaS environment may limit access to well‐defined parts of the file system, thus requiring a fine‐grained authorization service. In SaaS, cloud providers enable and provide application software enabled as on‐demand‐services. As clients acquire and use software components from different providers, securely composing them and ensuring that information handled by these composed services is well protected become crucial issues.

The cloud deployment models include public clouds, private clouds, community clouds, and hybrid clouds. A public cloud refers to an external or publicly available cloud environment that is accessible to multiple tenants, while a private cloud is typically a tailored environment with dedicated virtualized resources for a particular organization. Similarly, a community cloud is tailored for a particular group of customers.

Cloud computing's flexible and scalable economic solutions can be both a friend and an enemy from a security perspective, as the large resources and data gathered in datacenters makes them more attractive targets for attackers. Despite the enormous opportunities and values that the Cloud presents for organizations, without appropriate security and privacy solutions designed for clouds this potentially revolutionizing computing paradigm could become a huge failure. Several surveys of potential cloud adopters indicate that security and privacy are the primary concerns delaying its adoption (Catteddu and Hogben 2009). For example, on March 30, 2010, Yale University placed a migration to Google Apps for its email services on hold over privacy and security concerns (Tidmarsh 2010). However, cloud computing appears to be an unstoppable force because of its potential benefits. Hence, understanding the security and privacy risks in cloud computing and developing effective solutions are critical to the success of this new computing paradigm.

When we move our information into the Cloud, we may lose control of it. The Cloud gives us access to the data, but the challenge is to ensure that only authorized entities have. For instance, on June 19, 2011, Dropbox users reported that they were allowed into their Dropbox accounts after entering the wrong password (Peppetta 2011). It is crucial to understand how we can protect our data and resources from a security breach in a Cloud that provides shared platforms and services. It is critical to have appropriate mechanisms to prevent cloud providers from using customers' data in a way that has not been agreed upon in the past. In collaborative web applications that are built for groups, like Google Apps or any web‐based project management software, the security concerns spread across everyone involved. The security of the entire system is only as strong as the weakest user's setup. Once one person's weak password is brute‐forced or guessed, everyone's documents and information are at risk.

The architectural features of the Cloud allow users to achieve better operating costs and be very agile by facilitating fast acquisition of services and infrastructural resources as and when needed. However, these unique features also give rise to various security concerns. Table 9.1 summarizes these unique features with corresponding security implications (Takabi et al. 2010a).

Table 9.1 Security implications of cloud features.

Feature Security Implications
Outsourcing Users may lose control of their data. Appropriate mechanisms are needed to prevent cloud providers from using customers' data in a way that has not been agreed upon.
Extensibility and shared responsibility In general, there is a trade‐off between extensibility and security responsibility for customers within different delivery models; the sharing level differs for different delivery models, which in turn affects cloud extensibility for customers.
Virtualization There need to be mechanisms to ensure strong isolation, mediated sharing, and communication between VMs. This could be done using an access‐control system to enforce access policies that govern the control and sharing capabilities of VMs within a cloud host.
Multitenancy Issues like access policies, application deployment, and data access and protection should be taken into account to provide a secure multitenant environment.
Service‐level agreement The main goal is to build a new layer to create a negotiation mechanism for the contract between providers and consumers of services as well as the monitoring of its fulfillment at runtime.
Heterogeneity Different cloud providers may have different approaches to provide security and privacy mechanisms, thus creating integration challenges.

In order to address the critical security requirements of enterprises, in the past couple of years, there has been a tremendous effort toward proposing security services that could be delivered as cloud‐based services (a.k.a. Security‐as‐a‐Service [SECaaS]). Some of the services provided by SECaaS providers are intrusion detection systems and intrusion prevention systems (IDS/IPS), antivirus programs and antimalware, email and web applications security, identity and access management, traffic scrubbing, Secure Sockets Layer (SSL) certificates, encryption, integrity monitoring, security information and event management (SIEM), tokenization (payment card industry data security standard), etc. These security services have had and will continue to have an intense impact on securing enterprises of any size in the near future, a benefit that was not otherwise affordable especially for small enterprises. SECaaS enables security controls and functions to be delivered in new ways and by new types of service providers. It also enables enterprises to use security technologies and techniques that are not otherwise cost effective. Enterprises that use cloud‐based security services to reduce the cost of security controls and to address the new security challenges that cloud‐based computing brings are most likely to prosper. However, the main challenge for all enterprises that employ SECaaS is to implement robust, scalable, cost‐effective security services by performing a comprehensive risk analysis, because with rewards comes risk. More importantly, there are always trade‐offs and pros and cons for various SECaaS services that could be employed by enterprises. Therefore, a comprehensive risk‐analysis framework customized to a specific enterprise's goal for employing SECaaS, considering the enterprise's unique architecture, is necessary and tremendously helpful. Such a framework will lead to a smooth transition to the Cloud by any enterprise, and will let them benefit from SECaaS services provided by SECaaS providers. In this chapter, we propose SECaaS, a framework that aims to facilitate adoption of security services offered in the Cloud by assisting security managers to assess and choose from many security and privacy services provided by different cloud service providers and also for cloud providers to provide their security services more efficiently.

The remainder of this chapter is organized as follows: Section 9.2 discusses the related work. Section 9.3 presents the Security‐as‐a‐Service framework, describes its components, and provides its life cycle. Finally, Section 9.4 concludes the chapter.

9.2 Related Work

The Cloud Security Alliance (CSA) released its initial report in 2009, “Security Guidance for Critical Areas of Focus in Cloud Computing” (Cloud Security Alliance 2009). The CSA is an effort to facilitate the mission to create and apply best practices to secure cloud computing. Its initial report outlined areas of concern and guidance for organizations adopting cloud computing. The intention was to provide security practitioners with a comprehensive roadmap for being proactive in developing positive and secure relationships with cloud providers. NIST cloud efforts intend to promote the effective and secure use of the technology within government and industry by providing technical guidance and promoting standards. NIST released an early definition of cloud computing and also documented how to effectively and securely use the cloud computing paradigm (Mell and Grance 2009). (Trusted Computing Group 2010) discusses fundamental technologies on which the cloud security approaches are based. These technologies include Trusted Platform Module (TPM), Trusted Network Communications (TNC) architecture, and Trusted Storage. It selected six specific areas of the cloud computing environment from the CSA's security guide where equipment and software implementing Trusted Computing Group's (TCG) specifications can provide substantial security improvements, and explained how to apply these technologies in the Cloud.

(Takabi et al. 2010a) discuss security and privacy challenges in a cloud computing environment. They present unique issues of cloud computing that exacerbate security and privacy challenges in clouds, and discuss these challenges along with possible approaches and research directions to address them. They also proposed SecureCloud, a comprehensive security framework for cloud computing environments (Takabi et al. 2010b). The framework consists of different modules to handle security, and trust issues of key components of cloud computing environments. These modules deal with issues such as identity management, access control, policy integration among multiple clouds, trust management between different clouds and between a cloud and its users, secure service composition and integration, and semantic heterogeneity among policies from different clouds. (Jaeger and Schiffman 2010) discuss security challenges in the Cloud, the foundation of future systems' security, and key areas for cloud system improvement. (Jung and Chung 2010) propose an adaptive access algorithm that uses contextual information of the environments such as time, location, and security information to decide the access control to the resources. They also present an adaptive security management model using an improved role‐based access control (RBAC) model to solve more complex and difficult problems in cloud computing environments.

(Kandukuri et al. 2009) present security issues that must be included in a service‐level agreement (SLA) in a cloud computing environment. (Jensen et al. 2009) provide an overview of technical security issues of the Cloud. They start with real‐world examples of attacks performed on the Amazon EC2 service and then give an overview of existing and future threats to the Cloud. They also briefly discuss appropriate countermeasures to these threats, and further issues to be considered in future research. (Chen et al. 2010) try to frame the full space of cloud security issues by examining contemporary and historical perspectives from industry, academia, government, and the black‐hat community. They argue that most cloud computing security issues are not fundamentally new or fundamentally intractable. However, they suggest that two issues—the complexities of multiparty trust and mutual auditability—are to some degree new to the Cloud and propose future research directions for these issues.

The information security management system (ISMS) family of standards (the ISO/IEC 27000‐series) includes information security standards published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) (International Organization for Standardization 2009). The objectives of the ISO/IEC 27000‐series are to provide definitions and an introduction to the ISMS family of standards. It provides best‐practice recommendations on information security management, risks, and controls within the context of an overall ISMS. The plan, do, check, act (PDCA) model is an accepted life cycle for information security management that seeks to address changes in the threats, vulnerabilities, and impacts of information security incidents. The plan phase is responsible for setting policies, a strategy for implementing controls to achieve security objectives, and specific roadmaps to achieve control implementations within systems. In the do phase, controls are executed; and in the check phase, tests are performed to ensure that controls are operating as intended and meet objectives. In the act phase, gaps are remediated. Then the cycle repeats. This standard series is broad in scope and covers more than just privacy, confidentiality, and technical security issues; it is applicable to organizations of all shapes and sizes. The NIST Risk Management Framework defines a more detailed security life cycle that focuses on the implementation of controls in a specific IT system rather than at the overall ISMS level (Stoneburner et al. 2002). It provides “a foundation for the development of an effective risk management program, containing both the definitions and the practical guidance necessary for assessing and mitigating risks identified within IT systems” (Stoneburner et al. 2002). (Alberts and Dorofee 2005) have proposed the Mission Assurance Analysis Protocol (MAAP) to define an advanced, systematic approach for analyzing operational risk and gauging mission assurance in complex work processes.

9.3 Security‐as‐a‐Service Framework

In this section, we present a framework to assess and efficiently deliver cloud‐based security services to enterprises. First, we describe the framework by explaining its components in detail. Then, we explain how security administrators can use this framework to evaluate and adopt security services offered by various cloud service providers.

We propose the SECaaS framework as a new paradigm in cloud environment. We define SECaaS as the capabilities provided to the consumer to use providers' security products running on a cloud infrastructure and accessible through an interface. The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities. The goal is to develop a framework that facilitates provisioning of cloud‐based security applications and defines how to compose different security applications from different providers and come up with desirable solutions. It is critical to understand how architectures, technologies, processes, and human requirements change or remain the same when deploying cloud computing services (Cloud Security Alliance 2009). In order to understand how the cloud architecture impacts the security architecture, cloud services and architecture should be analyzed and mapped to a model of technical security, management and operational controls, risk assessment, and management frameworks. This is essentially an analysis to determine the general security posture of cloud services and how they relate to the protection requirements of an organization's assets. Once this analysis is complete, it becomes easier to decide what needs to be done in order to feed back into a risk‐assessment framework to determine how the risk should be addressed.

For SECaaS to be considered a practical cloud service, it must provide customers with the ability to establish their own security policies and risk‐management framework. Customers must be able to characterize, assess, measure, and prioritize their system risks. Cloud providers must offer security services independent of any platform and adaptable to constantly changing cloud environments and also ensure that their security measures are not too complex for efficient resource application. Prior to using a cloud service, customers must determine what security measures it provides and what extra security services are needed to deal with any potential vulnerability. Customers can identify from these analyses the common security services they can entrust to service providers. Figure 9.1, borrowed from (Cloud Security Alliance 2009), shows an example of various types of security controls needed when migrating to the Cloud. Depending on the cloud delivery model, the cloud service can be compared to a set of security controls to determine which controls already exist, provided by either the consumer or the cloud service provider, and which controls need to be solicited from other cloud providers.

Schematic with dashed boxes labeled Software-as-a-service, Platform-as-a-Service, and Infrastructure-as-a-service (outer–inner). Outside the boxes are arrows pointing to ovals labeled Application, Network, etc.

Figure 9.1 Security controls mapped to cloud delivery models.

As shown in Figure 9.2, the proposed framework includes four main components: the risk‐assessment module, the discovery module, the integration module, and the monitoring module. The security risk‐assessment module is responsible for identifying and evaluating risks and risk impacts, and recommending security controls to deal with these risks. Risk is defined as “a function of the likelihood of a given threat‐source's exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization” (Stoneburner et al. 2002). Customers use risk assessment to determine the extent of potential threats and the risk associated with an organization. Through a comprehensive risk analysis, the customer identifies what security controls and applications are needed to secure the organization. Then, the customer determines what security application will run on premises and what security applications should be adopted from cloud service providers. According to NIST's risk management guide, this module includes system characterization, threat identification, vulnerability identification, control analysis, likelihood determination, impact analysis, risk determination, and control recommendations (Stoneburner et al. 2002). The recommended security controls give security administrators basic building blocks to make their particular solution secure. We suggest that during the risk‐assessment process, mission assurance should also be taken into account. Mission assurance is defined as “establishing a reasonable degree of confidence in mission success” (Alberts and Dorofee 2005). It is a continuous attribute, and the degree of mission assurance in a process is inversely related to the amount of operational risk affecting that process (Alberts and Dorofee 2005). In order to do this, the MAAP can be used. The MAAP is a heuristic to determine the degree of mission assurance in complex processes; it provides a structured approach for analyzing operational risk (Alberts and Dorofee 2005). It uses the mission to frame a risk analysis and is designed to sort through complex distributed environments. Ultimately, it produces an accurate operational risk profile. The outcome of this module is a combination of technical, management, and operational security applications that aim to eliminate or reduce identified risks. Its technical security recommendations are input to the discovery module, during which the recommended procedural and technical security applications are chosen from existing cloud service providers.

Schematic with dashed boxes labeled Iaas, Paas, and Saas (inner–outer) linked to a box labeled SECaaS with downward arrows from risk-assessment module to discovery module, to integration module, to monitoring module.

Figure 9.2 Security‐as‐a‐Service framework.

The discovery module is designed to find service providers that provide required security services identified by the security risk‐assessment module. This can be done using a public repository that stores a list of services and their features, which can be accessed by customers. While looking for appropriate services, three factors should be taken into account: least cost, most appropriate, and minimal adverse impact. NIST's risk management guide suggests that customers “address the greatest risks and strive for sufficient risk mitigation at the lowest cost, with minimal impact on other mission capabilities” (Stoneburner et al. 2002). Customers use the public repository to find services that match best the identified requirements; service providers are ranked based on these factors, and finally the most appropriate ones are chosen. This module enables customers to compare services that different cloud providers offer and obtain assurance from selected cloud providers. The output of this module is a set of security services, possibly from different cloud service providers, that will be fed as input into the integration module.

Next, the integration module tailors the chosen security services from the discovery module to finalize the security building blocks the solution security administrators are developing for the organization. The output of this module is the system's security architecture, which includes an orchestrated security solution consisting of multiple security building blocks to address various security requirements. At this stage, the security architecture is embedded into the wider solution architecture that is being developed. During the integration process, confidentiality and privacy for services and data should be maintained.

The monitoring module is responsible for monitoring security services on a continuous basis. It is a real‐time security‐monitoring service that continuously tracks changes to system requirements that may affect security controls and reassesses control effectiveness. It monitors SLA commitments and context changes, among many other things that may affect the enterprise, and manages the migration, configuration, and contextualization of service components as a function of changes in context and/or SLA. It is also responsible for business‐continuity management and incident‐handling processes. In order to provide continuity, problems like recovery priorities (the customer's priorities regarding what is to be restored in case of an incident) and dependencies relevant to the restoration process should be considered. Incident management and response are part of business‐continuity management. This process aims to limit the impact of unexpected and potentially disruptive events to an acceptable level for an organization. It evaluates the capacity of an organization to minimize the probability of occurrence or reduce the negative impact of an information security incident.

The framework also offers a standardized, open interface for managing security services, to create a more open and readily available market for security services.

As shown in Figure 9.3, the life cycle of the SECaaS framework is as follows:

  • Assess security risks and define security requirements: Identify and evaluate risks and their impacts, and then recommend security controls.
  • Discover security services: Find providers that offer required services, and choose appropriate providers.
  • Integrate security services: Tailor the discovered security services, and finalize the security architecture.
  • Monitor security services: Track changes to the requirements that may affect security controls.
Security-as-a-Service flowchart with arrow from Assess (security risks) to Discover (security services), to Integrate (security services), to Monitor (security services).

Figure 9.3 Security‐as‐a‐Service flowchart.

The framework can be integrated into the enterprise's life cycle and effectively manages the different steps of the security service management life cycle.

An enterprise can employ our proposed framework to perform a risk analysis on various services it needs and weigh their pros and cons in order to wisely decide which assets can be secured through cloud‐based SECaaS and which are too risky and costly to be based on SECaaS. For instance, an enterprise could employ the SECaaS assessment framework and decide to only consider SECaaS for its information as an asset (e.g. database activity monitoring) and its network as an asset (e.g. IPS and firewall‐as‐a‐service [Zargar et al. 2011]), with the rest of its assets to be secured through existing or to‐be‐employed non‐cloud‐based services.

After deciding which categories of assets an enterprise would like to shop for that are available from SECaaS vendors, the next phase is to employ our risk‐analysis framework again for each of the categories to evaluate various SECaaS providers available in the market. For instance, various vendors provide IPS and firewall‐as‐a‐service, and each has pros and cons that the enterprise should evaluate before making a final decision. In order to employ our risk‐assessment framework, customized, specific enterprise metrics based on the need of the enterprise should be defined to evaluate which assets to secure through SECaaS. Then, for each chosen category of assets, different customized, specific enterprise metrics should be defined to evaluate the available SECaaS services in the market. The two phases that our framework employed in this example are shown in Figure 9.4.

Schematic displaying 2 dashed boxes labeled Phase 1 and Phase 2. Phase 1 has boxes labeled IaaS, Paas, and SaaS (inner–outer) linked to SECaaS and Phase 2 has 2 IDSs and IPSs (inner) and IaaS (outer) linked to SECaaS, etc.

Figure 9.4 Two phases of the proposed framework that an enterprise should employ to choose SECaaS suitable for its security goals.

9.4 Conclusions

In this chapter, we have discussed the critical security requirements of enterprises. While security and privacy services in the Cloud can be fine‐tuned and managed by experienced experts and hence have the potential to provide more efficient security‐management and threat‐assessment services, a framework is needed to assist security managers in choosing from many security and privacy services provided by different cloud service providers, and also to assist cloud providers in providing their security services more efficiently.

We have proposed an SECaaS framework that aims to facilitate adoption of security services offered in the Cloud. We introduced the framework, described its components, and explained how security managers can use it to efficiently solicit security applications required for enterprises from different cloud providers.

References

  1. Alberts, C.J., and Dorofee, A.J. (2005). Mission Assurance Analysis Protocol (MAAP): assessing risk in complex environments. Technical Note CMU/SEI‐2005‐TN‐032. https://resources.sei.cmu.edu/asset_files/TechnicalNote/2005_004_001_14537.pdf (accessed 6 January 2015).
  2. Catteddu, D. and Hogben, G. (2009). Cloud computing: benefits, risks and recommendations for information security. European Network and Information Security Agency (ENISA) Report. http://www.enisa.europa.eu/act/rm/files/deliverables/cloud‐computing‐risk‐assessment/at_download/fullReport (accessed 6 January 2015).
  3. Chen, Y., Paxson, V., and Katz, R.H. (2010). What's new about cloud computing security? Technical Report No. UCB/EECS‐2010‐5, EECS Department, University of California at Berkeley. http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS‐2010‐5.html (accessed 6 January 2015).
  4. Cloud Security Alliance (2009). Security Guidance for Critical Areas of Focus in Cloud Computing V2.1. http://cloudsecurityalliance.org/csaguide.pdf (accessed 6 January 2015).
  5. International Organization for Standardization. (2009). Information Security Management System (ISMS) family of standards: ISO/IEC 27000:2009. http://www.iso.org/iso/catalogue_detail?csnumber=41933 (accessed 6 January 2015).
  6. Jaeger, T. and Schiffman, J. (2010). Outlook: cloudy with a chance of security challenges and improvements. IEEE Security and Privacy 8 (1): 77–80.
  7. Jensen, M., Schwenk, J., Gruschka, N. et al. (2009). On technical security issues in cloud computing. In: Proceedings of the IEEE International Conference on Cloud Computing, 109–116. IEEE.
  8. Jung, Y. and Chung, M. (2010). Adaptive security management model in the cloud computing environment. In: Proceedings of the 12th International Conference on Advanced Communication Technology (ICACT), 1664–1669).
  9. Kandukuri, B.R., Paturi, R. and Rakshit, A. (2009). Cloud security issues. In: Proceedings of the 2009 IEEE International Conference on Services Computing, 517–520).
  10. Mell, P. and Grance, T. (2009). NIST definition of cloud computing v15. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800‐145.pdf (accessed 6 January 2015).
  11. Peppetta, M. (2011). Dropbox, leading cloud computing service, suffers security failure. http://memeburn.com/2011/06/dropbox‐leading‐cloud‐computing‐service‐suffers‐security‐failure.
  12. Soltesz, S., Pötzl, H., Fiuczynski, M.E. et al. (2007). Container‐based operating system virtualization: a scalable, high‐performance alternative to hypervisors. SIGOPS Operating Systems Review 41 (3): 275–287.
  13. Stoneburner, G., Goguen, A., and Feringa, A. (2002). Risk management guide for information technology systems. http://csrc.nist.gov/publications/nistpubs/800‐30/sp800‐30.pdf (accessed 6 January 2015).
  14. Takabi, H., Joshi, J.B.D., and Ahn, G.J. (2010a). Security and privacy challenges in cloud computing environments. IEEE Security and Privacy 8 (6): 24–31.
  15. Takabi, H., Joshi, J.B.D., and Ahn, G.J. (2010b). SecureCloud: Towards a comprehensive security framework for cloud computing environments. In: 34th Annual IEEE Computer Software and Applications Conference Workshops (COMPSACW 2010) (ed. S.I. Ahamed, D.H. Bae, S. Cha, et al.), 393–398. IEEE Press.
  16. Tidmarsh, D. (2010). ITS delays switch to Gmail. http://www.yaledailynews.com/news/university‐news/2010/03/30/its‐delays‐switch‐gmail‐community‐input (accessed August 2010).
  17. Trusted Computing Group. (2010). Cloud computing and security – a natural match. www.trustedcomputinggroup.org (accessed 6 January 2015).
  18. Zargar, S.T., Takabi, H., and Joshi, J.B.D. (2011). DCDIDP: A distributed, collaborative, and data‐driven intrusion detection and prevention framework for cloud computing environments. Proceedings of CollaborateCom’11, 332–341).
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset