You’ve handed over controls to a third-party, so how do you implement the right levels of security in a cloud environment, trust the provider to take care of the rest, and still meet compliance initiatives?
Unless you were off the grid, you most likely saw the Wired journalist Mat Honan’s gripping account of how he was hacked. A 19-year old hacker using the name “Phobia” gained access to Honan’s Amazon account, used that access to hack his Apple accounts, wiping his iPhone, iPad and MacBook, and eventually gaining entry to Honan’s Twitter account. Ironically, all that hacking activity was just a roundabout way for Phobia to get to Honan’s Twitter account.
We can derive a number of learnings from this attack; the reminder that regular backup of your data is essential, the importance of two-factor authentication, and even that your security policies need to be evaluated. But what this attack also demonstrates is the exploitation of “daisy-chains” of trust to escalate levels of privileges. This is what modern malware behavior exhibits – an initial entry point into an organization’s network is followed up by more sophisticated infection to gain greater access in the network.
This same exploitation of trust is also applicable in the virtualized and cloud computing world. Initial access to a virtual machine (VM) in a virtualized data center environment could escalate to additional privileges in the virtualized network if not properly secured. That’s been the fundamental security concern with hypervisors (which provides the trust level of a super user) and unfettered access to virtual applications.
If the ability to secure virtualized environments is about limiting the exploitation of trust, then what happens when you outsource your infrastructure to the cloud? You’ve essentially handed over controls to a third-party, so how do you implement the right levels of security in a cloud environment, trust the provider to take care of the rest, and still meet compliance initiatives?
These concerns bring us to the topic in question: can a public cloud computing environment truly be compliant with regulations or business covenants?
Trust and Responsibilities Depends on the Cloud Model
The first step is understanding the level of responsibilities on the part of the service provider and the cloud customer. First, let’s take a step back and review the cloud service models:
• Software as a Service (SaaS) – In SaaS deployments, cloud customers are provided access to an application running on a cloud infrastructure. The application is accessible to the end user from various client devices and interfaces, but the customer does not manage or control the underlying cloud infrastructure. Examples of SaaS include Salesforce.com and Google Apps.
• Platform as a Service (PaaS) – In PaaS deployments, cloud customers deploy and control supported applications on the provider’s cloud infrastructure using programming languages and tools supported by the provider. Examples of PaaS include Salesforce.com’s Force.com, Google’s App Engine and Microsoft’s Azure.
• Infrastructure as a Service (IaaS) – In IaaS deployments, cloud customers provision processing, storage, networks, and other computing resources and deploy and run operating systems and applications. The cloud customer does not manage or control the underlying cloud infrastructure, but controls the specific platform virtualization environment being used (servers, operating systems, storage, and deployed applications). Examples of IaaS include Rackspace and Amazon’s Elastic Compute Cloud (EC2).
The selection of the cloud service model determines the level of responsibilities on an organization versus the cloud provider. In a SaaS environment, the cloud provider owns the entire application and infrastructure stack. The customer will need to manage security policies for access to the SaaS applications. Therefore, the extent that you can influence security is to build it into your contract, ensure the rights levels of access by your users, and that the access to the SaaS application is secure.
In a PaaS model, because the cloud service providers are providing the platform and proprietary software suite to write applications, the cloud provider either provides the necessary security solution to secure the platform and application stack, or you have to design a solution using their platform.
In an IaaS deployment, the cloud provider owns the cloud computing infrastructure, but the organization owns the entire application stack. Therefore, while hypervisor and server security may be the domain of the cloud provider, you need to address application level security.
Clearly, the responsibilities reside with both organizations and cloud service providers, but may differ based on the cloud service choice. Ultimately, regardless of the choice of cloud services, and the service provider, the buck stops with cloud customers to prove and meet compliance in a cloud environment.
The Hurdles to Meeting Compliance
Now that we’ve established the responsibilities for security, what about the exact details of meeting compliance? At a high-level, organizations must assure auditors that confidential data is protected, isolated and restricted to the right sets of users. That’s easy to control in a private cloud setting.
The same sets of best practices we’ve been advocating are all still applicable in a cloud computing environment. This means having complete visibility into all traffic and users so you can safely enable applications, implementing a comprehensive threat framework that understands known and unknown threats, delivering a high-performance architecture, and being able to flexibly integrate into any design. A next-generation security solution can address these requirements.
For an outsourced cloud, the hurdles to meeting compliance now extend to the service provider network. The following considerations are important when evaluating the security of the cloud provider network:
Visibility and Control – Similar to an internal data center or private cloud, a fundamental security consideration for the cloud is safe enablement of applications in customer networks. Therefore, visibility into all service provider traffic is essential. Authentication of all users is required, and the service provider network needs to be strictly controlled for insider or third-party access. Privileged actions such as IT administrator functions, remote management functions or “daisy-chains” of access need to be restricted.
Data Privacy – The biggest concern with cloud providers is around data privacy. In a cloud environment, data is stored redundantly in multiple physical locations, and the compliance factor will involve validating whether safeguards are in place and legal/regulatory requirements are being met when data crosses boundaries. These jurisdictional and legal or regulatory requirements impact not just the data location but also the data flow, and the handing and processing of the data. Certain cloud providers will restrict where data is stored in order to meet compliance mandates.
The jurisdiction and legal/regulatory requirements around data have been a source of confusion for some time. For example, the Cloud Industry Forum recently made a claim in the U.S. House of Representatives that the Patriot Act was erroneously positioned as a reason not to use U.S. cloud providers because it would allow any U.S. government agency to access any data on a server in the United States without notice or warrant.
Data Ownership – The ownership of cloud data needs to be clearly established. This includes data that is collected by the cloud provider about customer-related activities in the cloud, as well as if the cloud provider service is terminated and the infrastructure shut down. Data ownership challenges may come into play when you consider electronic investigation of inappropriate or illegal activities for forensic or legal reasons, and trying to conduct them in a dynamic cloud environment.
Multi-tenancy – Cloud computing environments support large numbers of customers and platforms to achieve cost benefits and economies of scale from cloud services. Multi-tenancy from multiple customers sharing the use of a common infrastructure or platform can lead to higher security risks. Just as segmentation within a data center is a best practice to isolate vulnerable networks, multi-tenancy and isolation within the cloud environment is required so that security breaches with one customer’s network or application do not expose any other customer to the same threat.
New attack surface – In a cloud environment, in order to more efficiently deliver services, the infrastructure is typically built on a virtualized platform. Virtualization technology partitions a single physical server into multiple operating systems and applications for the multiple tenants that are being serviced. The virtualized infrastructure provides additional components that need to be secured for compliance reasons. Hypervisor vulnerabilities, and the ability to harden them is a key requirement.
Compliance is Possible
The specific topic of this article is on meeting compliance. Note that this may not necessarily mean the same thing as ensuring security. In an ideal world, implementing security and meeting compliance should be complementary. However, the reality is that meeting compliance is a more programmatic approach to managing the risks of critical systems. This means that if a specific compliance mandate excludes a “system” as non-critical, the system may still need to be protected even if not mandated under regulations.
In summary, if your head is in the cloud on compliance, then you’ve got a problem. It is possible to be regulatory compliant in cloud environments with the right set of next-generation security solutions. But, in a public cloud environment, regulatory compliance must be addressed hand in hand with a trusted provider. As with the Mat Honan hacking incident, all bets are off if one party misses the mark.
