The amount of control customers have over public cloud computing services increases as you move down the computing stack, with Software as a Service (SaaS) offering little or no control and Infrastructure as a Service (IaaS) offering the most control. The same goes for security responsibilities in the cloud: With SaaS, the responsibility to secure the platform and infrastructure clearly falls on the provider.
But things get murky the further down the stack you go. When it comes to IaaS, there is no clear-cut line between provider and user security responsibilities. The onus to define that line falls on the customer.
"It's really important that cloud tenants or customers understand this is definitely a shared responsibility from a governance perspective, from a control perspective, from a management perspective," said Jim Reavis, executive director of the Cloud Security Alliance, an organization that promotes best practices and training to improve cloud security.
Identify security gaps; understand security provisions
The shared security responsibility is underscored by the fact that different organizations have suffered varying consequences as the result of high-profile IaaS problems such as Amazon's outage in June 2012, Reavis said. "Some literally went out of business and others didn't experience any downtime when their data went offline. That indicates there was something the customers had under their control to control their destiny."
To implement the appropriate controls, cloud tenants must understand where security gaps exist. "You have to know what you're buying. Some focus more on security than others," said Antonio Piraino, CTO, ScienceLogic, a Reston, Va.-based provider of IT operations management software.
It’s really important that cloud tenants or customers understand that this is definitely a shared responsibility from a governance perspective, from a control perspective, from a management perspective.
Cloud Security Alliance
"As with most things in the cloud, [security] does tend to vary vendor by vendor," said Thomas Trappler, a Los Angeles, Calif.-based advisor for and instructor in cloud computing risk mitigation. Amazon Web Services (AWS), for instance, offers "an alphabet soup of different options," he said. "There's not just any one AWS service. So even within that, there could be variations of what a customer may be responsible for and what you might pay Amazon for to take another level of responsibility."
Ultimately, customers get what they pay for, Piraino said: "If you're paying for cloud services, you pay extra for additional security and additional uptime and disaster recovery."
The division of security responsibilities can be further confused by the various portions of the computing stack the customer procures from the IaaS provider. "We're seeing more bleed between IaaS and PaaS," Piraino said. "In its purest form, [IaaS is] a raw computing infrastructure" -- anything below the operating system (OS), he explained. "At the rawest level, the customer is responsible for configuring the [virtual machines], the OS, installing a firewall, those sorts of things. But you can buy into IaaS beyond just the raw virtual machines. Various flavors may come with an OS or database that may have some apps on it. The more you buy, the more accountability is on the IaaS provider," he said.
Consider, for example, AWS. "When it comes to specific concerns around malicious intent to one's AWS deployment, the general rule of thumb is that the higher up the stack one goes, the lower the ability for AWS to be responsible for the security of that workload or data," he explained. "At the facilities and physical infrastructure layers, it's easy, and in AWS's competence and interest to provide physical security that is best of breed, since it comes at a low cost for such a large operation."
"At the network layer and virtualization layers, the answer is not quite as clear-cut," Piraino continued. For data transfers within AWS data centers -- between zones and technologies such as Amazon's Elastic Cloud Compute (EC2) or Elastic Block Store (EBS) -- the responsibility belongs to AWS.
"Similarly, AWS has baked in its toolsets to the Xen Hypervisor underlying its IaaS offering – making it part and parcel of its cloud offering over which the customer has no say, thereby making it the de facto responsibility of AWS," Piraino said.
Develop the right mindset for public-cloud security
A paradigm shift occurs when organizations move applications to a public cloud, Trappler said. "The mindset is different. The way you have to think about it is different. It seems obvious, but it's important. People tell me, 'We moved from what we're used to -- a technically managed solution -- to a contractually managed solution in the cloud where someone is doing something for us. How do we know they are doing it right?'"
The answer: "Always confirm and contractually obligate [the provider] to the point that you understand what they should be taking care of," Trappler said. To this end, understand which portions of the provider's infrastructure are certified and/or audited. "It may not be the entire infrastructure. There are often multiple data centers and points in between," he said.
"This contract is now this shared understanding of where the lines are drawn of what the provider is supposed to do and what the customer is supposed to do," he said. "You need to have a contract to establish the terms of that relationship, a common understanding of who does what. Then there should be vendor management on the customer side to maintain that relationship."
Dig Deeper on Cloud access management and application security
Crystal Bedell asks:
Does your IaaS agreement clearly define both customer and provider responsibilities?
0 ResponsesJoin the Discussion