Security in the Cloud
Security risks are a concrete expression of the lack of control a business faces when considering moving critical business systems to the cloud. From the perspective of the enterprise, there are seven major risks to be considered. Of these seven, four can be easily controlled or mitigated by the Enterprise. The remaining three remain the responsibility of the cloud provider of which the Enterprise has little real control, other than voting with their wallet. It may be argued that the Enterprise should make “demands” of the cloud provider through the use of contracts or third party audits, but in reality the market will determine the amount of security provided to Enterprises by cloud service providers and the level of acceptable risk. It may turn out that the cheaper price of cloud computing comes with necessarily increased risk, which may be a self-limiting factor in itself to the pervasive use of cloud computing by Enterprises.
We outline the top security risks as follows:
1. Insecure, Porous APIs: Most cloud services offer two categories of web-accessible APIs: Those based on web services (called SOAP) and those based on pure HTTP (called REST). Increasingly, some cloud providers are offering only REST style APIs which lack robust “Enterprise class” message level security and authentication mechanisms. Some APIs, such as the Twitter API are purposely designed for rapid development and allow and even encourage the use of unprotected user credentials which are more susceptible to man in the middle or replay attacks. While some providers, such as Amazon.com offer strong authentication mechanisms, it’s not clear yet how well these APIs stand up to content-based threats such as code injection, denial of service attacks, script injection, or malicious XML content. Moreover, it’s also not clear how much trust should be placed in data received by the Enterprise from a cloud API for potential threats. A compromised cloud service API session may be a direct avenue for an attack. Internal information systems exposed to the cloud at the API layer offer a universal tunnel for a savvy attacker. Without explicit protection, cloud APIs essentially expose previously guarded Enterprise data across the Internet into the hands of a third party. Moreover, for IaaS systems that expose XML based APIs for image management, these management APIs also require strong authentication and access control as an attacker may conveniently replace a trusted machine image with a rouge one.
2. Logical Multi-Tenancy: With shared cloud computing infrastructure, the division of Enterprise data is now logical rather than physical. This logical separation is typically achieved through the use of virtualized infrastructure which is a cheap and easy way to support a multi-tenant architecture at the cloud service provider. The perceived risk in this scenario is for an attacker to subvert the logical division provided by the guest virtual machine and gain access to the data of another tenant. A number of attacks on virtual machines, from detecting the presence of a hypervisor to running arbitrary code on the host have been documented3. These attacks highlight the uncertain security of multitenant, shared environments for critical Enterprise data. An Enterprise horror story would be an attacker signing up for a “free” account at the cloud service provider, detect the presence of a virtual machine and “escape out” of the VM instance to access the physical server operating system and potentially gain access to the Enterprise data. Technology such as Intel® Trusted Execution Technology (TXT) are available that can mitigate this type of attack, but responsibility for implementation ultimately still lies with the cloud service provider.
3. Data Protection and Confidentiality: Data stored, processed or indexed in a remote cloud service defines the extent of the new perimeter for the Enterprise. This new “fuzzy” boundary changes and moves with the data itself, not the traditional firewall. A necessary complication here is that for data to be used effectively by cloud services it must remain unencrypted or else SaaS providers will have a hard time indexing it for any function that relies on search. Common examples include spell-checking in a Google document or looking up sales leads in a CRM application. The Enterprise may have to give up encryption and data privacy requirements for some of its data but should also recognize the option of applying selective field or message level protection mechanisms for data before it reaches the cloud. A practical example of this is protecting employee or critical customer information on messages before the data is released to the cloud. This is one aspect of data protection that an Enterprise can control on data before it reaches the cloud service provider.
4. Data Loss and Reliability: When critical business data is moved to a cloud service, there is some inherent risk of data loss. Even if cloud service vendors offer multiple back-ups and data redundancy, there is no perfect way to protect against the failure of physical media and disasters are apt to strike at just the wrong time. To take an example, services such as Amazon’s storage service offer “credits” in the face of data unavailability4 within a given month. This SLA may be too weak a proposition for business critical data and Enterprises may need more protection to manage this risk. Data loss and unavailability at precisely the wrong time may completely cripple an Enterprise. It may be argued that this is a false risk because the Enterprise has a similar risk of catastrophic data loss inside its own datacenter and simply moving the data to the cloud doesn’t change the equation. This claim ignores the fact that the cloud service provider is offering the same product at a much cheaper price and the reliability that the Enterprise has built around its data may simply not be present with the cloud service provider. It should be noted that this risk may turn out to be a red herring. The convenience and cost savings of the cloud service and record of actual failures may reduce this potential risk to near-zero, but it is too early to tell.
5. Audit and Monitoring: The first step in managing the security of any system to know when specific risky events occur. If an Enterprise decides that cloud services provide value to the Enterprise but wants to audit when these services are accessed to evaluate risk, it needs a way to know when data flows to and from the cloud. Enterprises need to know who is making the service request, when the request is happening, how much data is sent or received and how the data is used. Given the convenience and ease with which cloud service providers can be accessed the biggest risk to an Enterprise concerns the use of unmanaged “rogue” cloud services or projects that go unnoticed or unmanaged by the Enterprise CSO.
6. Cloud Provider Insider Threats: A potential problem or weak spot with cloud services is the mismatch between the security requirements inside the Enterprise as compared to those employed by the cloud service provider. To take an example, many large Enterprises make special efforts to secure “endpoint” data on IT-issues laptops with two-factor authentication technology, forced password rotation and fully encrypted hard-disk drives. Moreover, data is often segmented with access controls that distinguish between full employees and contractors, especially in large companies with diverse geographies. In most cases these controls increase the security of the Enterprise data. It should be noted that has taken Enterprises many years to reach this level of increased protection. Once the data is moved from protected assets to the cloud, however, an instant “weak spot” is created. Security breaches are often breaches of the weakest link, and a determined attacker motivated either by financial gain or industrial espionage will likely find it easier to execute an insider threat from the cloud service provider to gain access to the Enterprise data rather than try to execute a brute force attack on an encrypted hard disk. It should be noted that this is not the same as “hacking into Amazon’s API” or “hacking Google documents.” Sophisticated attackers use social engineering techniques and insider connections to find the weakest link. A motivated attacker may even take a low level job at the cloud provider itself if it provides an easier path to the Enterprise data.
7. Account Hacking, Tiered Access Control and Authorization: While hacking an account through a stolen password or compromised credential is nothing new, Enterprises to date have done a decent job of segmenting credentials and access control throughout their infrastructure. This is actually a property or benefit of the somewhat localized security inherent in individual operating systems and the uses of role based (RBAC) and attribute based access control (ABAC) within the Enterprise. In other words, if an attacker gains root access to a networked system or database they may have access to other assets, but the breach of a single system is more often than not directly localized to the breached system. Further, breaches of a single account are self-limiting by the role or attributes associated with that account in the Enterprise LDAP system. It is true that sophisticated attackers can use information from any compromised system as a stepping stone for more sophisticated attacks, but more work is required by the attacker unless they are extremely lucky in breaching the exact system they need. If we contrast this to cloud service providers, a few such as Salesforce.com have rudimentary segmented access control and privileges5, but for the majority of these a breach of one account may grant the keys to the entire castle. In fact, the pay-off for an attacker who knows that he must hack just one account to gain access to all of the Enterprises resources may seek to employ cheap, readily available cloud computing resources for brute force attacks on passwords and cryptographic keys. Moreover, fine-grained authorization of Enterprise resources is a problem just now being solved inside the Enterprise and it will be some time before cloud providers reach the same sophistication of locking down the use of individual data elements, fields, URIs, resources or API calls to individuals with a specific role or specific attributes. Account hacking from an Enterprise insider also needs to be considered. Once the Enterprise moves to cloud computing traditional insider attacks can be more costly because the Enterprise must rely on the cloud provider to help prevent the insider breach. In short, not only are the keys to the castle held in the cloud, but the Enterprise has to protect its traditional assets and now cloud assets from insider attacks.
The previous seven risks are summarized in Table 1. Here we list the risks, a description of the threat and which party (Enterprise or Cloud Provider) is on the hook for reducing the threat. Ultimately, shoring up security risks is the job of both the Enterprise and the cloud providers. Short of a boycott, however, Enterprises have little real control over how security is implemented on the provider side. Cloud providers have yet to segment their offerings to provide increased levels of security targeted for Enterprise requirements such as higher levels of risk protection, integration with Enterprise identity systems, guarantees around multi-tenancy platform sharing (or isolation) and integration with monitoring, alerting and security event management systems. Instead, providers appear to be implementing minimum levels of security for their perceived target market. Whether this minimum security will rise as the industry matures is an open question, but for Enterprises that need to reduce risk while cautiously adopting cloud services we advocate the use of a high performance edge-oriented service gateway for those categories of risk that the Enterprise can control. This provides the necessary balance between the cost savings promised by cloud computing and the management of tangible risks that are under the Enterprise control. The next section outlines the concept of a service gateway and how it can reduce risk in four areas: (a) API protection and strong authentication, (b) Data protection and leakage, (c) Auditing and Monitoring, (d) Access Control and Authorization.
