Analytics
6/3/2011
02:59 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Who's Responsible For Security In Cloud Services?

If you think your service provider is going to take care of everything, then you have another thing coming

For companies worried about the security of their data in cloud services, a recent survey could be disheartening.

Almost two-thirds of cloud service providers placed responsibility for the customer data hosted on their infrastructure with the customer, according to a survey of providers (PDF) conducted by the Ponemon Institute and funded by CA Technologies. Cloud providers typically see the availability of their services, cost optimization, and ease-of-use as their top concerns, not security, says Larry Ponemon, chairman and founder of the Ponemon Institute.

Only a quarter of the providers surveyed said the security of their services was a competitive advantage.

"On average, our research shows that cloud providers are less secure than on-premises IT infrastructure," Ponemon says. "And the reason that they are less secure is because they don't see security as their mission."

IT executives need to pay more attention to the fine print in their cloud services contracts, especially because providers and customers are not on the same page when it comes to security, Ponemon says. While 69 percent of providers place security responsibility with their customers, only 35 percent of customers believe they need to worry about the security of their data in the cloud.

"What we find is that CIOs and CISOs are starting to see this as a potential enormous risk -- a data-protection risk and even a privacy risk in some instances -- because the environment is out of their control and they have to rely on the assurances of the cloud providers," Ponemon says.

But companies that make security a primary consideration in negotiations with a cloud provider can come to a solid agreement. Security firm Symantec, for example, has used a public cloud infrastructure for more than six years. During that time, CIO David Thompson has renegotiated security clauses and had security measures reviewed.

"We have taken those suppliers through a number of security reviews and [penetration] tests, over and over again," Thompson says. "And the providers we have partnered with have really done a good job in providing us confidence. I will tell you, my comfort level with them is much higher than it was five years ago."

In some cases, the CIO might not have a choice about jumping into cloud services because the initiatives are initiated by the business side of the house. In these cases, the security team might have to deal with a service-level agreement (SLA) that is inflexible, says Thompson.

"One of the trade-offs you have to factor in is [that] when you go to these service providers, they are optimizing around the most common denominator to optimize the cost," Thompson says. "In most cases, you are getting a pretty decent SLA at a really good price."

But having the conversation about security can make a difference, experts say. For one, such conversations can demonstrate to a provider that the customer takes security seriously -- and expects the service provider to take security seriously as well, says Lina Liberti, vice president of security for CA Technologies. In the end, security should not be the responsibility of the customer or the provider, but a shared responsibility between the two parties, she says.

"At the end of the day, you have to hold the provider accountable to make sure they are adhering to the SLA, and you have to make sure that you are doing the right due diligence to enable that security as well," Liberti says.

Companies also should ensure that software-as-a-service (SaaS) providers do not have the ability to access or use their data. In many cases, the provider will want to be able to use aggregate information, and companies should carefully check their contract language, said Matthew Karlyn, a partner in the technology practice a law firm Foley & Lardner, in a recent interview.

"You should be able to continue to use your data," Karlyn said. "You should be able to ensure that the vendors are backing up the data frequently. Obviously, we are looking for very, very thorough confidentiality protections."

If a cloud provider will not provide the necessary contract assurances, then the enterprise should consider doing an end run around the provider by encrypting its data, experts say. Many companies, such as CipherCloud, enable companies to encrypt data in the cloud and decrypt it within their premises.

Even for companies that have a good, security-conscious SLA in hand, the extra level of encryption makes sense, says Ponemon. "It takes a little bit longer, and you have to have the right tools in place, but it can be -- and should be -- done," he says.

Have a comment on this story? Please click "Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web