In-Depth

How Cloud Partners Can Identify (and Plug) Datacenter Security Holes

Most of the top cloud vendors provide basic datacenter security controls, but for partners looking to launch cloud-based services with third-party vendors, "basic" isn't enough. Where are the security holes in a cloud datacenter, and how can partners fill in those gaps for their customers?

• By Gladys Rama
• December 11, 2014

As solution delivery increasingly involves cloud-hosted services, solution providers regularly find themselves in the business of taking on new vendors who provide key services from datacenters over which the solution provider has no control. The vendors might be giants such as Amazon Web Services Inc. (AWS), Google Inc., Rackspace Inc. or Microsoft, with their own massive datacenters. They might be smaller vendors providing their services from their own purpose-built datacenter. They might be a co-location arrangement with a services provider of any size. Or they may simply be reselling the service of another vendor, abstracting the whole question.

Ultimately, it doesn't matter because the solution provider is the trusted advisor. Whether the customer's data was stolen out of a megavendor's datacenter, a small vendor's datacenter or a midsize co-lo provider, it was the partner's recommendation and, therefore, the partner's fault in the customer's eyes. How do you assess the risk you're getting into when going into business with a cloud-based service of any type?

'Trust But Verify'
Security has long been considered the bugbear of cloud computing; in survey after survey, fears over the perceived porousness of the cloud have emerged as the most-cited obstacle to cloud adoption. However, fears about cloud security have also been shown to decline the more common cloud use becomes. In its 2014 "State of the Cloud Report" (registration required), RightScale Inc. found that while security is still the top concern for organizations new to cloud computing (which RightScale calls "Cloud Beginners"), it's only the fifth-most important concern for heavy cloud users ("Cloud Focused" companies). The latter were most worried about compliance, instead.

Concerns about security also fell between 2013 and 2014 for both Cloud Beginners and Cloud Focused companies. RightScale attributed that decline in part to cloud providers themselves, which have continually fortified their internal security features. Mark Kraynak, chief product officer at datacenter security firm Imperva, echoes the notion that cloud vendors -- at least, the ones at the top of the market -- keep fairly tight ships.

"My personal opinion is they [the major cloud providers] are pretty buttoned-up on the security front," Kraynak says. "I wouldn't take it for granted, and there's a fair amount of work that partners and solution providers should do before they start doing business with those companies. But in general, the expectation is if it's a good brand like Google, Microsoft, Amazon, they've probably already put quite a bit of effort into the security controls on their production networks and it's likely that they've got better controls than [solution providers]. And it's likely that they've got better controls than any enterprise."

That doesn't mean partners and customers should let their guards down. Kraynak urges partners to take a "trust but verify" approach when it comes to doing business with cloud megavendors -- emphasis on "verify." To that end, he advises partners to request cloud vendors to provide past security audits, which are typically performed every year. A review of a cloud vendor's recent audits should give partners an objective assessment of the security of that vendor's datacenter operations. It's an approach that's also endorsed by Charles Radi, vice president and principal cloud architect at Cloud Technology Partners Inc. (CloudTP), a systems integrator based in Boston, Mass.

"[Audit reports] are pretty informative and they'll give you an indication of what the reality is according to a third-party assessor -- how compliant [the cloud vendors] are, how not compliant they are and where they're deficient. You can kind of map that out and say, 'That's an acceptable risk based on the type of business we run' or, 'That's not something that's acceptable to us.'" Radi says.

Another issue partners can confidently trust cloud vendors about (but, again, be ready to verify) is the physical security of their datacenter facilities. Concerns about outside individuals or rogue employees stealing data out of a cloud datacenter are becoming largely moot as more and more vendors use automation and remote technology to manage their datacenters. "I think long gone are the days where people actually have to go in there and reboot servers or pull out hard drives and do things like that. That's long gone, especially for the cloud providers," Radi says.

Kraynak adds that the physical security controls implemented by the top cloud vendors for their datacenters are very strong -- probably stronger than what most enterprises have on-premises. "Most enterprises would probably have door control to the front door to the office. You might have restricted access to your datacenter for your IT team. ... All those [top cloud vendors] are at least as restrictive as that, if not way more. The examples that I've been privileged to see -- you would be blown away. They're very secure," he says. "I would say, worry about it enough to verify it's there, but it's probably not your primary concern."

Where Solution Providers Can Step In
So what should the primary concerns of a partner be when it comes to datacenter security? The recent "Web Application Attack Report" (PDF) from Imperva gives one view: With cloud usage becoming more ubiquitous, Infrastructure-as-a-Service (IaaS) platforms are emerging as vectors for security attacks on Web applications. Published in October, the report found that Web application attacks originating from IaaS platforms are on the rise as more companies sign off on the "cloudification" of their IT assets. About 20 percent of all vulnerability exploitation attempts and 10 percent of all SQL injection attacks that Imperva observed between August 2013 and April 2014 originated from AWS IP addresses.

"This is an interesting beginning to what could become a trend in security, where hackers use cloud-provided public infrastructure, either by employing it themselves, or by hijacking some other organization's account, and elevating attacks from these platforms," the report concluded.

(One caveat: Imperva used AWS as the proxy IaaS platform for its report because, it said, the clear market dominance of AWS accounts for a "huge and growing portion of all online entities." However, Imperva Chief Technology Officer Amichai Shulman warned in a statement that other IaaS providers are by no means insulated against Web application attacks. "With this phenomenon on the rise, other IaaS providers have to worry about their servers being compromised. Attackers don't discriminate when it comes to where a datacenter lives," Shulman said.)

Imperva identified three possible ways an IaaS platform can be used by attackers to compromise the security of Web applications:

1. An attacker can simply host malicious server instances on the IaaS cloud.
2. An attacker can hack into a company's account and tamper with servers using administrator credentials.
3. An attacker can inject malicious code directly into a company's Web applications, thereby giving him remote control of the server.

The finding highlights a need for Web application security controls on which solution providers can capitalize. SQL injection, cross-site scripting and other attacks can prove costly to customers, and not just in terms of lost data: Bandwidth charges can ratchet up if a customer's infected servers become zombie or bot networks -- essentially, agents for attacks. The partner opportunity, according to Kraynak, is the provision of a Web application firewall for a customer's cloud-based applications. "Every application needs a Web application firewall in front of it," he says. "If anything, it's more important to have that in the cloud world than the on-premises world."

A second area where solution providers can provide security is in protecting customer applications against distributed denial-of-service attacks (DDoS), particularly because a cloud vendor's own DDoS security protections only extend so far. "For the most part, the cloud providers have a very good way of defending their infrastructure from denial of service, but they generally don't pass that on to the user of their infrastructure," Kraynak says. "They'll give you some level of help, but not what you would want for protecting your business."

That leaves a major security hole for a solution provider to fill if it wants to spare its customer from potentially getting their servers shut down by the cloud vendor. "If you're running in one of those IaaS provider environments and your site gets a DDoS attack, probably what that cloud provider is going to do is turn you off so that everybody else [in that cloud environment] can still run. They're protecting their infrastructure and their other customers," Kraynak explains.

A third possible security weak spot is the management interface of a customer's cloud application. Typically, that interface is a Web-based portal that can be potentially targeted by anyone. This past summer, code-hosting services provider Code Spaces was forced to close up shop because of such an attack. In the span of 12 hours, Code Spaces, which had been hosted on AWS, was hit first with a DDoS attack that later escalated into the unknown attacker accessing the Code Spaces Amazon EC2 control panel to demand a ransom. As the Code Spaces team tried to mitigate the attack by changing its passwords, the attacker -- who had already created backup passwords and logins of their own -- began deleting artifacts from the control panel, including, according to the official memo from Code Spaces, "EBS [Elastic Block Storage] snapshots, S3 buckets, all AMIs [Amazon Machine Images], some EBS instances and several machine instances." The attack effectively crippled Code Spaces enough that it was unable to continue operations.

Kraynak points to incidents like the Code Spaces debacle as another opportunity for solution providers, whose customers -- perhaps used to on-premises environments -- have likely never considered adapting their privileged-user security practices for the cloud. "The guidance I would give [to partners] would be to think about what you would do in an on-premises world and what the analog for that is in the cloud from a security perspective, and make sure you have a way to achieve that before you move workloads," he says.

Examine (and Reexamine) the Contract
In fact, a good deal of what partners must do to keep their customer applications and data safe happens during the contract negotiation process -- before they even make the move to the cloud. "It's not so much the security weaknesses [that solution providers should look at]. I think it's more of the contract clauses that providers enter into," says CloudTP's Radi.

Radi, who also runs the security and governance practice at CloudTP, stresses the importance of carefully reviewing the legal language in a contract before entering into an agreement with a third-party cloud provider, particularly if that cloud provider follows a "shared security model" -- and many of the big ones, including AWS and Microsoft, do. Under a shared security model (also called a "shared responsibility model"), a cloud provider assumes the responsibility of ensuring the security of its datacenters, but only up to a certain level in the stack, leaving the rest of the security burden to the users. As Microsoft puts it in its Azure Trust Center page:

Microsoft is responsible for the platform, and seeks to provide a cloud service that can meet the security, privacy, and compliance needs of our customers. Customers are responsible for their environment once the service has been provisioned, including their applications, data content, virtual machines, access credentials, and compliance with regulatory requirements applicable to their particular industry and locale.

Reviewing the contract language then turns into a way of making customers aware of exactly how these shared responsibilities are divvied up, and to what degree the cloud provider is legally obligated to protect them. The most important pieces of a cloud contract that a solution provider should eyeball are the parts about information security, according to Radi. "That's just making sure that...the cloud provider has implemented some sort of information security program, and that that program will protect the customer's information assets," he says.

In addition, Radi says partners should pay attention to the contract language around the following three areas:

• Data ownership and privacy
• Data location and jurisdiction
• Data retention and deletion

Partners should be particularly attentive to how the cloud provider's policies in those areas align with the customer's specific regulatory needs. If a partner has a customer that deals with data from U.S. federal agencies, the partner must make sure that the cloud provider's contract meets FedRAMP standards -- for example, by attesting that the customer's data will not leave the United States, and that all data stored in the United States will not be handled by someone outside of the country. Likewise, if the customer deals with private individuals' health data, the contract should meet HIPAA standards; if the customer deals with student information, the contract should meet FERPA standards.

A fourth key area to examine is how the contract defines the cloud provider's responsibilities with regard to breach notification. Information security controls aside, Radi believes cloud data hacks are not a matter of if but of when, so it's important to know in advance what a cloud provider's incident-response policies are. "That contract should also cover that cloud service provider's obligations in the event that...data is accessed inappropriately," Radi says. "What does the breach notification process look like? How long does it go for? How is it delivered, and what remediation actions do they take?"

Imperva's Kraynak notes that notification policies can be a sticking point particularly when working with smaller cloud providers, which may be more affordable than the bigger vendors, but often provide fewer customer protections in their service-level agreements (SLAs). "As you get further down-market...they [cloud providers] might not be so buttoned-up on security, and they might not be willing to give you a good SLA for notification and response to issues. Those would be huge flags," he says.

Ultimately, says Kraynak, the burden of closing the security gaps falls on the partner, not the cloud vendor. "If you were going to get breached...it's probably not going to be your provider's fault; it's probably going to be your fault for not having the right controls around the application because you forgot to do something, or it didn't work the right way, or the same way you expected it to work in on-premises. And the weakest link is very rarely the provider itself."