Emerging Security Challenges in Cloud Computing, from Infrastructure-Based Security to Proposed Provisioned Cloud Infrastructure
Mohammad Reza Movahedisefat1, Seyyed Mohammad Reza Farshchi2 and Davud Mohammadpur3, 1Amirkabir University of Technology (Tehran Polytechinc), Tehran, Iran, 2Ferdowsi University of Mashhad, Mashhad, Iran, 3University of Zanjan, Zanjan, Iran
In this chapter, we discuss the threats, challenges, and guidance associated with securing an organization’s core IT infrastructure at the network, host, and application levels in the cloud. According to the best knowledge of the authors, up to now, there are no research with this perspective on cloud security in the literature. This chapter represents our first discussion of this infrastructure security in the context of SPI service delivery models (SaaS, PaaS, and IaaS). Non-information security professionals are cautioned not to simply equate infrastructure security to infrastructure-as-a-service (IaaS) security. Although infrastructure security is more highly relevant to customers of IaaS, similar consideration should be given to providers’ platform-as-a-service (PaaS) and software-as-a-service (SaaS) environments, since they have ramifications to customer threat, risk, and compliance management. Another dimension is the cloud business model (public, private, and hybrid clouds), which is orthogonal to the SPI service delivery model; what we highlight is the relevance of discussion points as they apply to public and private clouds. When discussing public clouds, the scope of infrastructure security is limited to the layers of infrastructure that move beyond the organization’s control and into the hands of service providers (i.e., when responsibility to a secure infrastructure is transferred to the cloud service provider [CSP], based on the SPI delivery model). Information in this chapter is critical for customers in gaining an understanding of what security a CSP provides and what security the customer is responsible for providing. This chapter discusses conceptual issues, basic requirements, and practical suggestions for designing dynamically configured security infrastructure provisioned on demand as part of the cloud-based infrastructure. We end this chapter by describing general-use cases for provisioning cloud infrastructure that provide bases for defining security infrastructure requirements.
Keywords
data security; infrastructure security; cloud computing; cloud services delivery model
Information in this chapter
Introduction
In cloud environments, one of the most pervasive and fundamental challenges for organizations in demonstrating policy compliance is proving that the physical and virtual infrastructure of the cloud can be trusted—particularly when those infrastructure components are owned and managed by external service providers.
For many business functions commonly run in the cloud—hosting websites and wikis, for example—it’s often sufficient to have a cloud provider vouch for the security of the underlying infrastructure. For business-critical processes and sensitive data, however, third-party attestations usually aren’t enough. In such cases, it’s absolutely essential for organizations to be able to verify for themselves that the underlying cloud infrastructure is secure.
The next frontier in cloud security and compliance will be to create transparency at the bottom-most layers of the cloud by developing the standards, tools, and linkages to monitor and prove that the cloud’s physical and virtual machines are actually performing as they should. Verifying what’s happening at the foundational levels of the cloud is important for the simple reason that, if organizations can’t trust the safety of their computing infrastructure, the security of all the data, software, and services running on top of that infrastructure falls into doubt. There’s currently no easy way for organizations to monitor actual conditions and operating states within the hardware, hypervisors, and virtual machines comprising their clouds. At those depths, we go dark.
Cloud providers and the IT community are already preparing to address this problem. Groups of technology companies have banded together to develop a new, interoperable, and highly secure computing infrastructure for the cloud based on a “hardware root of trust,” which provides tamperproof measurements of every physical and virtual component in the entire computing stack, including the hypervisor. Members of the IT community are exploring ways to use these measurements to improve visibility, control, and compliance in the cloud.
They’re collaborating on a conceptual IT framework to integrate the secure measurements provided by a hardware root of trust into adjoining hypervisors and virtualization management software. The resulting infrastructure stack would be tied into data analysis tools and a governance, risk, and compliance (GRC) console, which would contextualize conditions in the cloud’s hardware and virtualization layers to present a reliable assessment of an organization’s overall security and compliance posture. This type of integrated hardware-software framework would make the lowest levels of the cloud’s infrastructure as inspectable, analyzable, and reportable for compliance as the cloud’s top-most application services layer.
As we mentioned above, many communities have already adopted the “cloud,” a flexible computational platform allowing scalability and a service-based provision model.
Unfortunately, there are currently significant limitations when using a cloud infrastructure to perform security-critical computations and/or store sensitive data. Specifically, at the moment, there is no way to guarantee the trustworthiness of a Virtual Machine (VM) in terms of its origin and identity and the trustworthiness of the data uploaded and managed by the Elastic Block Storage or the Simple Storage Service (S3). These limitations made us to propose a macro-level solution for identified common infrastructure security requirements and design a hybrid model for on-demand infrastructure services provisioning.
Because of these limitations, public cloud computing uptake by business-critical communities is limited. A number of communities whose emerging information models appear otherwise well-suited to cloud computing are forced to either avoid the pay-per-use model of service provision or deploy a private cloud infrastructure. Deploying a private cloud is rarely a desirable solution. It requires an extended time frame and significant investment in hardware, management, and software resources. These limitations also apply to the deployment of a private cloud based on open source software because, while licensing costs are eliminated, the bulk of the investment in hardware and support resources is still required.
This chapter presents recent results of the ongoing research on developing an architecture and a framework for dynamically provisioned security services as part of the provisioned on-demand cloud-based infrastructure services. It shows that the proposed model, with a number of emerged patterns, can be applied to the infrastructure aspect of cloud computing as a proposed shared security approach in a system development life cycle focusing on the plan-build-run scope. Some of this information was adopted from Cloud Security and Privacy [1].
Background
The current cloud security model is based on the assumption that the user/customer can trust the cloud service provider (CSP). However, such an approach addresses only the first part of the problem and does not scale well with the potential need to combine cloud-based services from multiple providers when building complex infrastructures.
Cloud providers are investing significant efforts and costs into making their own infrastructures secure and achieving compliance with the existing industry security services management standards (e.g., Amazon Cloud recently achieved the Payment Card Industry Data Security Standard [PCI DSS] compliance certification and Microsoft Azure Cloud claims compliance with ISO27001 security standards). However, overall security of cloud-based applications and services will depend on two other factors: security services implementation in user applications and binding between virtualized services and cloud virtualization platforms. Advanced security services and fine-grained access control cannot be achieved without deeper integration with the cloud virtualization platform and incumbent security services, which, in its turn, can be achieved with open and well-defined cloud IaaS platform architectures.
Infrastructure security
The network level
When looking at the network level of infrastructure security, it is important to distinguish between public clouds and private clouds. With private clouds, there are no new attacks, vulnerabilities, or changes in risk specific to this topology that information security personnel need to consider. Although an organization’s IT architecture may change with the implementation of a private cloud, its current network topology will probably not change significantly. If there is a private extranet in place (e.g., for premium customers or strategic partners), for practical purposes, the organization probably has the network topology for a private cloud already in place. The security considerations in place today apply to a private cloud infrastructure, too. And the security tools in place (or should be in place) are also necessary for a private cloud and operate in the same way. Figure 23.1 shows the topological similarities between a secure extranet and a private cloud.
However, if an organization chooses to use public cloud services, changing security requirements will require changes to its network topology. The organization must address how its existing network topology interacts with its cloud provider’s network topology. There are four significant risk factors in this use case [2,3]:
• Ensuring the confidentiality and integrity of the organization’s data-in-transit to and from its public cloud provider
• Ensuring proper access control (authentication, authorization, and auditing) to whatever resources the organization is using as its public cloud provider
• Ensuring the availability of the Internet-facing resources in a public cloud that are being used by the organization or have been assigned to the organization by its public cloud providers
• Replacing the established model of network zones and tiers with domains
Ensuring data confidentiality and integrity
Some resources and data previously confined to a private network are now exposed to the Internet and to a shared public network belonging to a third-party cloud provider.
An example of problems associated with this first risk factor is an Amazon Web Services (AWS) security vulnerability reported in December 2008. In a blog post, the author detailed a flaw in the digital signature algorithm used when “… making Query (aka REST) requests to Amazon SimpleDB, to Amazon Elastic Compute Cloud (EC2), or to Amazon Simple Queue Service (SQS) over HTTP.” Although use of HTTPS (instead of HTTP) would have mitigated the integrity risk, users not using HTTPS (but using HTTP) did face an increased risk that their data could have been altered in transit without their knowledge.
Network-level mitigation
Given the factors discussed in the preceding sections, what can be done to mitigate these increased risk factors? First, note that network-level risks exist regardless of what aspects of “cloud computing” services are being used (e.g., software-as-a-service, platform-as-a-service, or infrastructure-as-a-service). The primary determination of risk level is therefore not which IaaS is being used, but rather whether an organization intends to use or is using a public, private, or hybrid cloud. Although some IaaS clouds offer virtual network zoning, they may not match an internal private cloud environment that performs stateful inspection and other network security measures.
If an organization is large enough to afford the resources of a private cloud, its risks will decrease—assuming the organization has a true private cloud that is internal to its network. In some cases, a private cloud located at a cloud provider’s facility can help meet security requirements but will depend on the provider capabilities and maturity.
An organization can reduce its confidentiality risks by using encryption; specifically by using validated implementations of cryptography for data-in-transit. Secure digital signatures make it much more difficult, if not impossible, for someone to tamper with the data, and this ensures data integrity.
Availability problems at the network level are far more difficult to mitigate with cloud computing—unless the organization is using a private cloud that is internal to its network topology. Even if the private cloud is a private (i.e., non-shared) external network at a cloud provider’s facility, an increased risk is faced at the network level. A public cloud faces even greater risk. But let’s keep some perspective here—greater than what?
Even large enterprises with significant resources face considerable challenges at the network level of infrastructure security. Are the risks associated with cloud computing actually higher than the risks enterprises are facing today? Consider existing private and public extranets, and take into account partner connections when making such a comparison. For large enterprises without significant resources, or for small to medium-size businesses (SMBs) [4,5,6], is the risk of using public clouds (assuming that such enterprises lack the resources necessary for private clouds) really higher than the risks inherent in their current infrastructures? In many cases, the answer is probably no—there is not a higher level of risk.
The host level
When reviewing host security and assessing risks, an organization should consider the context of cloud services delivery models (SaaS, PaaS, and IaaS) and deployment models (public, private, and hybrid). Although there are no known new threats to hosts that are specific to cloud computing, some virtualization security threats—such as VM escape, system configuration drift, and insider threats by way of weak access control to the hypervisor—carry into the public cloud computing environment. The dynamic nature (elasticity) of cloud computing can bring new operational challenges from a security management perspective. The operational model motivates rapid provisioning and fleeting instances of VMs. Managing vulnerabilities and patches is therefore much harder than just running a scan, as the rate of change is much higher than in a traditional data center.
In addition, the fact that the clouds harness the power of thousands of compute nodes, combined with the homogeneity of the operating system employed by hosts, means the threats can be amplified quickly and easily—call it the “velocity of attack” factor in the cloud. More importantly, one should understand the trust boundary and the responsibilities that falls on one’s shoulders to secure the host infrastructure that one manages. And one should compare the same with providers’ responsibilities in securing the part of the host infrastructure the CSP manages.
Cloud service models
Cloud computing enables hardware and software to be delivered as services, where the term “service” is used to reflect the fact that they are provided on demand and are paid on a usage basis—the more you use the more you pay. Draw an analogy with a restaurant. A restaurant provides a food and drinks service. If we would like to eat at a restaurant, we don’t buy it, we just use it as we require. The more we eat, the more we pay. Cloud computing provides computing facilities in the same way as restaurants provide food: when we need computing facilities, we use them from the cloud. The more we use, the more we pay. When we stop using them, we stop paying.
Although the above analogy is a great simplification, the core idea holds. Since computing is many things, cloud computing has a lot of things to deliver as a service. This is where the SPI model helps organize things. Let’s consider these in turn.
Software as a Service: These software products are typically end user applications delivered on demand over a network on a pay-per-use basis. The software requires no client installation, just a browser and network connectivity. An example of SaaS is Microsoft Office365. Until its launch, if a user required, say, Word, they would have to purchase it, install it, back up files, etc. With Office365, Word can be acquired for a small monthly fee, with no client installation. The files are automatically backed up, software upgrades are automatically received, and the software can be accessed from anywhere. If users decides they no longer want to use Word , they stop paying the monthly fee. It is that simple.
Platform as a Service: These types of platforms are used by software development companies to run their software products. Software products need physical servers to run on, along with database software and often Web servers, too. These comprise the platform that the application runs on. Building a platform is a time-consuming task, and it needs to be continually monitored and updated. PaaS provides all of the platform-out-of-the-box enabling software applications for the platform and will execute them with no requirement for administration of the lower level components.
Infrastructure as a Service: This covers a wide range of features, from individual servers to private networks, disk drives, and various long-term storage devices, as well as email servers, domain name servers, and messaging systems. All of these can be provisioned on demand and often include software license fees for operating systems and associated software installed on the servers. Organizations can build a complete computing infrastructure using IaaS on demand.
All of the services provided by cloud computing fit into one of the three delivery models above. End users typically use SaaS, software development teams use PaaS, and IT departments whose responsibility is the infrastructure use IaaS. There is much more to cloud computing, including aspects such as automatic scaling and security, for example. As a starting point, categorizing the delivery models helps to explain that all aspects of computing are covered; these cloud services are potentially useful for everybody involved in, or using, IT.
SaaS and PaaS host security
In general, CSPs do not publicly share information related to their host platforms, host operating systems, and the processes that are in place to secure the hosts, since hackers can exploit that information when they are trying to intrude into the cloud service. Hence, in the context of SaaS (e.g., Salesforce.com, Workday.com) or PaaS (e.g., Google App Engine, Salesforce.com’s Force.com) cloud services, host security is opaque to customers and the responsibility of securing the hosts is relegated to the CSP. To get assurance from the CSP on the security hygiene of its hosts, one should ask the vendor to share information under a Non-Disclosure Agreement (NDA) or simply demand that the CSP share the information via a controls assessment framework such as SysTrust or ISO 27002. From a controls assurance perspective, the CSP has to ensure that appropriate preventive and detective controls are in place and will have to ensure the same via a third-party assessment or ISO 27002-type assessment framework.
Since virtualization is a key enabling technology that improves host hardware utilization, among other benefits, it is common for CSPs to employ virtualization platforms, including Xen and VMware hypervisors, in their host computing platform architecture. One should understand how the provider is using virtualization technology and the provider’s process for securing the virtualization layer.
Both the PaaS and SaaS platforms abstract and hide the host operating system from end users with a host abstraction layer. One key difference between PaaS and SaaS is the accessibility of the abstraction layer that hides the operating system services the applications consume. In the case of SaaS, the abstraction layer is not visible to users and is available only to the developers and the CSP’s operations staff, whereas PaaS users are given indirect access to the host abstraction layer in the form of a PaaS application programming interface (API) that, in turn, interacts with the host abstraction layer. In short, if you are a SaaS or a PaaS customer, you are relying on the CSP to provide a secure host platform on which the SaaS or PaaS application is developed and deployed by the CSP and you, respectively.
In summary, host security responsibilities in SaaS and PaaS services are transferred to the CSP. The fact that a customer does not have to worry about protecting hosts from host-based security threats is a major benefit from a security management and cost standpoint. However, the customer still owns the risk of managing information hosted in the cloud services. It’s the user’s responsibility to get the appropriate level of assurance regarding how the CSP manages host security hygiene.
Virtual server security
Customers of IaaS have full access to the virtualized guest VMs that are hosted and isolated from each other by hypervisor technology. Hence, customers are responsible for securing, and on-going security management of, the guest VM. A public IaaS, such as Amazon’s Elastic Compute Cloud (EC2), offers a Web services API to perform management functions such as provisioning, decommissioning, and replication of virtual servers on the IaaS platform. These system management functions, when orchestrated appropriately, can provide elasticity for resources to grow or shrink in line with workload demand. The dynamic life cycle of virtual servers can result in complexity if the process to manage the virtual servers is not automated with proper procedures. From an attack surface perspective, the virtual server (Windows, Solaris, or Linux) may be accessible to anyone on the Internet, so sufficient network access mitigation steps should be taken to restrict access to virtual instances. Typically, the CSP blocks all port access to virtual servers and recommends that customers use port 22 (Secure Shell or SSH) to administer virtual server instances. The cloud management API adds another layer of attack surface and must be included in the scope of securing virtual servers in the public cloud. Some of the new host security threats in the public IaaS include:
• Stealing keys used to access and manage hosts (e.g., SSH private keys)
• Attacking unpatched, vulnerable services listening on standard ports (e.g., FTP, NetBIOS,
• Hijacking accounts that are not properly secured (i.e., weak or no passwords for standard
• Attacking systems that are not properly secured by host firewalls
• Deploying Trojans embedded in the software component in the VM or within the VM image (the OS) itself
Securing virtual servers
The simplicity of self-provisioning new virtual servers on an IaaS platform creates a risk that insecure virtual servers will be created. Secure-by-default configuration needs to be ensured by following or exceeding available industry baselines.
Securing the virtual server in the cloud requires strong operational security procedures coupled with automation of procedures. Here are some recommendations:
• Use a secure-by-default configuration. Harden the image and use a standard hardened image for instantiating VMs (the guest OS) in a public cloud. A best practice for cloud-based applications is to build custom VM images that have only the capabilities and services necessary to support the application stack. Limiting the capabilities of the underlying application stack not only limits the host’s overall attack surface, but also greatly reduces the number of patches needed to keep that application stack secure.
• Track the inventory of VM images and OS versions that are prepared for cloud hosting. The IaaS provider provides some of these VM images. When a virtual image from the IaaS provider is used, it should undergo the same level of security verification and hardening for hosts within the enterprise. The best alternative is to provide your own image that conforms to the same security standards as internal trusted hosts.
• Protect the integrity of the hardened image from unauthorized access.
• Safeguard the private keys required to access hosts in the public cloud.
• In general, isolate the decryption keys from the cloud where the data is hosted—unless they are necessary for decryption, and then only for the duration of an actual decryption activity. If an application requires a key to encrypt and decrypt for continuous data processing, it may not be possible to protect the key since it will be collocated with the application.
• Include no authentication credentials in your virtualized images except for a key to decrypt the file system key.
• Do not allow password-based authentication for shell access.
• Require passwords for sudo or role-based access (e.g., Solaris, SELinux).
• Run a host firewall and open only the minimum ports necessary to support the services on an instance.
• Run only the required services and turn off the unused services (e.g., turn off FTP, print services, network file services, and database services if they are not required).
• Install a host-based IDS such as OSSEC or Samhain.
• Enable system auditing and event logging, and log the security events to a dedicated log server. Isolate the log server with higher security protection, including access controls.
The application level
Application or software security should be a critical element of an organization’s security program. Most enterprises with information security programs have yet to institute an application security program to address this realm. Designing and implementing applications targeted for deployment on a cloud platform will require that existing application security programs re-evaluate current practices and standards. The application security spectrum ranges from stand-alone single-user applications to sophisticated multi-user e-commerce applications used by millions of users. Web applications such as content management systems (CMSs), wikis, portals, bulletin boards, and discussion forums are used by small and large organizations. A large number of organizations also develop and maintain custom-built Web applications for their businesses using various Web frameworks (PHP, .NET, J2EE, Ruby on Rails, Python, etc.). According to SANS, until 2007, few criminals attacked vulnerable websites because other attack vectors were more likely to lead to an advantage in unauthorized economic or information access. Increasingly, however, advances in cross-site scripting (XSS) and other attacks have demonstrated that criminals looking for financial gain can exploit vulnerabilities resulting from Web programming errors as new ways to penetrate important organizations. In this section, we limit our discussion to Web application security: Web applications in the cloud accessed by users with standard Internet browsers such as Firefox, Internet Explorer, or Safari, from any computer connected to the Internet.
Since the browser has emerged as the end user client for accessing in-cloud applications, it is important for application security programs to include browser security into the scope of application security. Together they determine the strength of end-to-end cloud security that helps protect the confidentiality, integrity, and availability of the information processed by cloud services.
Application-level security threats
According to SANS, Web application vulnerabilities in open source as well as custom-built applications accounted for almost half the total number of vulnerabilities discovered between November, 2006 and October, 2007. The existing threats exploit well-known application vulnerabilities (e.g., the OWASP Top 10), including cross-site scripting (XSS), SQL injection, malicious file execution, and other vulnerabilities resulting from programming errors and design flaws. Armed with knowledge and tools, hackers are constantly scanning Web applications (accessible from the Internet) for application vulnerabilities. They are then exploiting the vulnerabilities they discover for various illegal activities including financial fraud, intellectual property theft, converting trusted websites into malicious servers serving client-side exploits, and phishing scams. All Web frameworks and all types of Web applications are at risk of Web application security defects, ranging from insufficient validation to application logic errors.
It has been a common practice to use a combination of perimeter security controls and network- and host-based access controls to protect Web applications deployed in a tightly controlled environment, including corporate intranets and private clouds, from external hackers. Web applications built and deployed in a public cloud platform will be subjected to a high threat level, attacked, and potentially exploited by hackers to support fraudulent and illegal activities. In that threat model, Web applications deployed in a public cloud (the SPI model) must be designed for an Internet threat model, and security must be embedded into the Software Development Life Cycle (SDLC); see Figure 23.2.
SaaS Application security
The SaaS model dictates that the provider manages the entire suite of applications delivered to users. Therefore, SaaS providers are largely responsible for securing the applications and components they offer to customers. Customers are usually responsible for operational security functions, including user and access management as supported by the provider. It is a common practice for prospective customers, usually under an NDA, to request information related to the provider’s security practices. This information should encompass design, architecture, development, black- and white-box application security testing, and release management.
Some customers go to the extent of hiring independent security vendors to perform penetration testing (black-box security testing) of SaaS applications (with consent from the provider) to gain assurance independently. However, penetration testing can be costly and not all providers agree to this type of verification.
Extra attention needs to be paid to the authentication and access control features offered by SaaS CSPs. Usually that is the only security control available to manage risk to information. Most services, including those from Salesforce.com and Google, offer a Web-based administration user interface tool to manage authentication and access control of the application. Some SaaS applications, such as Google Apps, have built-in features that end users can invoke to assign read and write privileges to other users. However, the privilege management features may not be advanced, fine-grained access and could have weaknesses that may not conform to a organization’s access control standard. One example that captures this issue is the mechanism that Google Docs employs in handling images embedded in documents, as well as access privileges to older versions of a document. Evidently, embedded images stored in Google Docs are not protected in the same way that a document is protected with sharing controls. That means if a user has shared a document containing embedded images, the other person will always be able to view those images even after the first user has stopped sharing the document. A blogger discovered this access control quirk and brought it to Google’s attention. Although Google has acknowledged the issue, its response conveys that it believes those concerns do not pose a significant security risk to its users.
Another incident related to Google Docs was a privacy glitch that inappropriately shared access to a small fraction (Google claims 0.05 percent of the documents were affected) of word processing and presentation documents stored on its Google Apps cloud service. Though the documents were shared only with the people with whom the Google Docs users had already shared documents, rather than with the world at large, the problem illustrates the need to evaluate and understand cloud-specific access control mechanisms.
Cloud customers should try to understand cloud-specific access control mechanisms— including support for strong authentication and privilege management based on user roles and functions—and take the steps necessary to protect information hosted in the cloud. Additional controls should be implemented to manage privileged access to the SaaS administration tool and enforce segregation of duties to protect the application from insider threats. In line with security standard practices, customers should implement a strong password policy—one that forces users to choose strong passwords when authenticating to an application.
It is a common practice for SaaS providers to commingle their customer data (structured and unstructured) in a single virtual data store and rely on data tagging to enforce isolation between customer data. In that multi-tenant data store model, where encryption may not be feasible due to key management and other design barriers, data is tagged and stored with a unique customer identifier. This unique data tag makes it possible for the business logic embedded in the application layer to enforce isolation between customers when the data is processed. It is conceivable that the application layer enforcing this isolation could become vulnerable during software upgrades by the CSP. Hence, customers should understand the virtual data store architecture and the preventive mechanisms the SaaS providers use to guarantee the compartmentalization and isolation required in a virtual multi-tenant environment.
Established SaaS providers, such as Salesforce.com, Microsoft, and Google, are known to invest in software security and practice security assurance as part of their SDLC. However, given that there is no industry standard to assess software security, it is almost impossible to benchmark providers against a baseline.
PaaS Application security
PaaS vendors broadly fall into the following two major categories:
• Software vendors (e.g., Bungee, Etelos, GigaSpaces, Eucalyptus)
• CSPs (e.g., Google App Engine, Salesforce.com’s Force.com, Microsoft Azure, Intuit QuickBase)
Organizations evaluating a private cloud may utilize PaaS software to build a solution for internal consumption. Currently, no major public clouds are known to be using commercial off-the-shelf or open source PaaS software such as Eucalyptus (Eucalyptus does offer a limited experimental pilot cloud for developers at Eucalyptus.com, however). Therefore, given the nascent stage of PaaS deployment, we will not discuss software security of standalone PaaS software in this chapter. Nonetheless, it is recommended that organizations evaluating PaaS software perform a risk assessment and apply the software security standard similar to acquiring any enterprise software.
By definition, a PaaS cloud (public or private) offers an integrated environment to design, develop, test, deploy, and support custom applications developed in the language the platform supports. PaaS application security encompasses two software layers:
• Security of the PaaS platform itself (i.e., runtime engine)
• Security of customer applications deployed on a PaaS platform
Generally speaking, PaaS CSPs (e.g., Google, Microsoft, and Force.com) are responsible for securing the platform software stack that includes the runtime engine that runs the customer applications. Since PaaS applications may use third-party applications, components, or Web services, the third-party application provider may be responsible for securing their services.
Hence, customers should understand the dependency of their application on all services and assess risks pertaining to third-party service providers. Until now, CSPs have been reluctant to share information pertaining to platform security, using the argument that such security information could provide an advantage for hackers. However, enterprise customers should demand transparency from CSPs and seek information necessary to perform risk assessment and on-going security management.
IaaS Application security
IaaS cloud providers (e.g., Amazon EC2, GoGrid, and Joyent) treat the applications on customer virtual instances as a black box, and therefore are completely agnostic to the operations and management of the customer’s applications. The entire stack—customer applications, runtime application platform (Java, .NET, PHP, Ruby on Rails, etc.), and so on—runs on the customer’s virtual servers and is deployed and managed by customers. To that end, customers have full responsibility for securing their applications deployed in the IaaS cloud.
Hence, customers should not expect any application security assistance from CSPs other than basic guidance and features related to firewall policy that may affect the application’s communications with other applications, users, or services within or outside the cloud.
Web applications deployed in a public cloud must be designed for an Internet threat model and embedded with standard security countermeasures against common Web vulnerabilities (e.g., the OWASP Top 10). In adherence with common security development practices, they should also be periodically tested for vulnerabilities, and most importantly, security should be embedded into the SDLC. Customers are solely responsible for keeping their applications and runtime platform patched to protect the system from malware and hackers scanning for vulnerabilities to gain unauthorized access to their data in the cloud. It is highly recommended that applications be designed and implemented with a “least-privileged” runtime model (e.g., configure the application to run using a lower privileged account).
Developers writing applications for IaaS clouds must implement their own features to handle authentication and authorization. In line with enterprise identity management practices, cloud applications should be designed to leverage delegated authentication service features supported by an enterprise Identity Provider (e.g., OpenSSO, Oracle IAM, IBM, CA) or a third-party identity service provider (e.g., Ping Identity, Simplified, TriCipher). Any custom implementations of Authentication, Authorization, and Accounting (AAA) features can become a weak link if they are not properly implemented, and they should be avoided when possible.
In summary, the architecture for IaaS-hosted applications closely resembles enterprise Web applications with an n-tier distributed architecture. In an enterprise, distributed applications run with many controls in place to secure the host and the network connecting the distributed hosts.
Different cloud security approaches
Comparable controls do not exist by default in an IaaS platform and must be added through a network, user access, or as application-level controls. Customers of IaaS clouds are responsible for all aspects of their application security and should take the steps necessary to protect their application to address application-level threats in a multi-tenant and hostile Internet environment.
As mentioned in the previous section, the Cloud Security Alliance (CSA) was formed with the aim of promoting the use of best practices for providing security assurance within cloud computing. In this section, we learn from Robert Temple, director and chief architect of security platform for BT Innovate and Design, about security concerns as they relate to three different types of cloud services.
Are there any significant differences when approaching security between the three cloud service models, SaaS, PaaS and IaaS?
Different kinds of cloud computing services expose different entry points into the cloud provider and offer to the customer different types of service management operations. In turn, these create different attack surfaces, severity, and effects of exploits, as well as different probabilities of a security breach.
From resilience and availability, multi-tenancy and data co-mingling, cloud provider lock-in, control of data location, protection of data at rest in the cloud, and compliance to regulations and law about privacy, data protection, cross-border data movement, auditing, etc., there are too many to list in this chapter, but here’s a quick snapshot about what customers should make themselves aware:
SaaS customers should understand if their applications have been secured to establish best practice guidance, such as that from the Open Web Application Security Project (OWASP), and ensure that application level security controls have been implemented (for example, application-aware firewalling and intrusion prevention systems).
IaaS customers should understand how resource sharing occurs within their cloud provider—if they require significant scaling-up of provision at the same time as other users of the same cloud, it may risk breaching the capacity of the cloud provider, and therefore affect availability. Also, customers should be aware if their cloud provider’s technology architecture uses new and unproven methods for failover and verify what they use for disaster recovery, and customers should understand how their cloud provider deletes “old” data, particularly on the cessation of a contract.
For the PaaS in particular, a cloud provider’s patch management policies and procedures have significant security impact, so the customer should ensure that the patching policy is documented.
Provisioned access control infrastructure (DACI)
Developing a consistent framework for dynamically provisioned security services requires deep analysis of all underlying processes and interactions. Many processes typically used in traditional security services need to be abstracted, decomposed, and formalized. First of all, it is related to security services setup, configuration, and security context management that, in many present solutions/frameworks, is provided manually, during the service installation or configured out-of-band.
The general security framework for on-demand provisioned infrastructure services should address two general aspects: (1) supporting secure operation of the provisioning infrastructure, which is typically provided by the providers’ authentication and authorization infrastructure (AAI) supported also by federated identity management services (FIdM), and (2) provisioning a dynamic access control infrastructure as part of the provisioned on-demand virtual infrastructure. The first task is primarily focused on the security context exchanged between involved services, resources, and access control services. The virtualized DACI must be bootstrapped to the provisioned on-demand group-oriented virtual infrastructure (VI), the virtual infrastructure provider (VIP), and the virtual infrastructure operator (VIO). Such security bootstrapping can be done at the deployment stage.
Virtual access control infrastructure setup and operation is based on the above-mentioned DSA that will link the VI dynamic trust anchor(s) with the main actors and/or entities participating in the VI provisioning: VIP and the requestor or target user organization (if they are different). As discussed above, the creation of such a dynamic security association (DSA) for the given VI can be done during the reservation and deployment stage.
The reservation stage will allow the distribution of the initial provisioning session context and collection of the security context (e.g., public key certificates) from all participating infrastructure components. The deployment stage can securely distribute either shared cryptographic keys or another type of security credential that will allow validation of information exchange and application of access control to VI users, actors, and services.
Conclusion
The primary focus of this chapter is the security infrastructure for cloud-based infrastructure services provisioned on demand that in fact should be a part of the overall cloud infrastructure provisioned on demand. The proposed solutions should allow moving current enterprise security infrastructure—that currently requires large amounts of manual configuration and setup—to a fully functional virtualized infrastructure service.
In this chapter, we looked at network-, host-, and application-level security and the issues surrounding each level with specific regard to cloud computing. At the network level, although there are definitely security challenges with cloud computing, none of those challenges are caused specifically by cloud computing. All of the network-level security challenges associated with cloud computing are instead exacerbated by cloud computing—not specifically caused by it. Likewise, security issues at the host level, such as an increased need for host perimeter security (as opposed to organizational entity perimeter security) and secured virtualized environments, are exacerbated by cloud computing but not specifically caused by it. And the same holds true for the application level. Certainly, there is an increased need for secure software development life cycles due to the public-facing nature of (public) cloud applications, and the need to ensure that APIs have been thoroughly tested for security, but those application-level security requirements are again exacerbated by cloud computing and are not specifically caused by it. Therefore, the issues of infrastructure security and cloud computing are about understanding which party provides which aspects of security (i.e., does the customer provide them or does the CSP provide them?)—in other words, defining trust boundaries.
References
1. Mather T, Kumaraswamy S. Cloud security and privacy O’Reilly 2009.
2. NIST SP 800-145. The NIST definition of cloud computing. [Internet]. [Accessed on 2012 Jan 29]. http://csrc.nist.gov/publications/ nistpubs/800-145/SP800-145.pdf.
3. Demchenko Y, Mavrin A, de Laat C. Defining generic architecture for cloud infrastructure as a service provisioning model. In: Proceedings CLOSER2011 Conference; 2011 May 7–9; Nordwijk, Netherlands. SciTePress; 2011. ISBN 978-989-8425-52-2.
4. Demchenko Y, van der Ham J, Ghijsen M, Cristea M, Yakovenko V, de Laat. C. On-demand provisioning of cloud and grid based infrastructure services for collaborative projects and groups. CTS 2011: Proceedings of the 2011 International Conference on Collaboration Technologies and Systems; 2011 May 23–27; Philadelphia, PA, USA.
5. Demchenko Y, de Laat C, Lopez DR, Garcia-Espin JA. Security services lifecycle management in on-demand infrastructure services provisioning. In: Proceedings of the IEEE Second International Conference on Cloud Computing Technology and Science. Indianapolis, IN, USA; 2010. p. 644–650.
6. Demchenko Y, Ngo C, de Laat C, Wlodarczyk T, Rong C, Ziegler W. Security infrastructure for on-demand provisioned cloud infrastructure services. CloudCom2011: Proceedings of the 3rd IEEE Conference on Cloud Computing Technologies and Science; Nov 29-Dec 1; Athens, Greece. ISBN 978-0-7695-4622-3;2011.