It's no secret that security is a top concern among organizations seeking cloud-based services. While it's in the...
provider's best interest to allay that concern, no organization should settle for the potentially empty assurances offered in a provider's marketing materials.
So how can security professionals develop an honest assessment of cloud service provider security? What are the subtle clues that can help determine whether security is part of a cloud provider's corporate culture or just an item on a sell sheet?
Less than 20% [of providers] even know what the CSA is.
Assessing a provider's security begins with recognizing that security is a joint effort.
"It's very important for people to understand that security is not a one-way street. It's not just all the provider's responsibility. Security in a cloud provider environment is a shared responsibility. Some of the responsibility resides with the user, and they need to really understand that," said Bernard Golden, CEO of HyperStratus Inc., a cloud computing provider based in San Carolos, Calif.
"You need to recognize the shared responsibility and understand the trust boundary. In other words, where does the cloud service provider responsibility end, and where does the user's responsibility begin? That's a crucial thing to understand. Then the question is how do you evaluate the portions that are the cloud provider's responsibility?" said Golden.
An audit, while an important part of a cloud provider evaluation, will not reveal everything about the provider's security posture. "An audit, in our opinion, is complementary to a much more comprehensive security assessment of the provider," said Nikita Reva, lead security specialist for a food manufacturer. "An assessment needs to be part of the overall process of deciding whether you should use a cloud provider."
So how does one go about performing an assessment? "You can forge a path yourself and try to figure it out, or you can rely on tools and processes and work that's already been done by other people, which reduces your burden," said Golden. "I would always advocate for the latter."
Reva agreed. "Do not reinvent the wheel," he said. "The Cloud Security Alliance (CSA) has already figured out the majority of this. They have a really good, robust framework to use. Go ahead and leverage it."
Golden cited CSA's Cloud Controls Matrix (CCM) as a valuable tool to use in the assessment process. CCM cross-references different regulatory compliance and industry standards with the specific controls that are needed to meet the necessary requirements. Golden said an enterprise should determine the controls it needs from its cloud service provider in order to comply with applicable standards, take them to the provider and ask where they stand against them. If the provider is committed to security, Golden added, it will be able to offer a report that details how the controls are met.
Simply making this information available, however, isn't enough. The more important question is whether the provider already had it prepared. If so, that's an indication that security is part and parcel to the way a cloud service provider operates, said Golden. If the provider doesn't already have a report prepared or is not willing to explain it thoroughly, then that should be cause for concern.
Experts also suggest having a conversation with providers to discuss any industry-specific requirements that the CCM may not cover, and for the purpose of developing an impression of the provider's general attitude toward security.
"We ask some fairly poignant questions when we talk to people," said Reva. "We try to be cordial, but one of the areas that shed some light is their overall level of understanding of cloud security: 'What is it; how do you define it?'" Some of the other questions Reva's team asks: Is there a single individual in the company responsible for security? Is there a security program in place? What is the disaster recovery process? What is the incident response process?
"If a provider doesn't understand this, or has no conceptual understanding or processes in place, that may not be a provider you want to work with," said Reva, whose organization has assessed many providers in the last year. "Less than 20% even know what the CSA is," he said.
On the other hand, "If they are unable to have a subsequent discussion, it's probably a sign that this is not the provider for you, and you need to find another provider," said Golden.
Unfortunately, even if the provider is willing to have subsequent conversations, getting the information you need won't necessarily be easy. "It's the reality of what it is. It's always a struggle between providers not wanting to disclose anything and sharing enough detail to build some reasonable assurance," said Reva.
Reva said his organization asks providers if they perform penetration testing. This is important because the threat landscape increases for cloud-based applications, which are Internet facing. There's no guarantee that the provider has security controls in place to prevent potentially anyone from "knocking on your door," said Reva.
"More often than not, if we ask for any form of evidence of a pen test, it's met with, 'We can't provide that information to you because of sensitivity.' We don't just take no for an answer. We'll ask for a redacted version, so they remove the sensitive aspects of it, or some kind of an executive summary," said Reva.
There is a final potential roadblock worth noting, but it is not on the cloud provider's side. According to Golden, some organizations falsely believe that they can negotiate a strong SLA that will protect them from security and compliance risks.
"The implication is, 'I don't really have to check it out because I'll force them to give me a guarantee.'" But, Golden added, this is the wrong approach. "SLAs are more about compensation when something doesn't go right," he said. "It doesn't cause someone to do a better job."
About the author
Crystal Bedell is a freelance technology writer specializing in information security, networking and the cloud. She can be reached at email@example.com.