Cloud Computing Roundtable

This article first appeared in IEEE Security & Privacy magazine and is brought to you by InfoQ & IEEE Computer Society.

Guest editors Iván Arce and Anup Ghosh put together a roundtable discussion so readers can hear about cloud computing security from those who are on the front lines, providing services and looking at the real-world threats and requirements from the market.

Anup Ghosh: Thank you all for joining us. We’ve chosen you because your companies represent sub­stantial investments in cloud computing. To start, Eric, can you talk about the size target market and scope of Google’s cloud-computing initiatives?

Eric Grosse: That’s a good question, because scale is definitely a driving factor here. Gmail has hundreds of millions of users. If you printed just the first page of each new Google Doc created, you’d kill 120 trees a day, just to give you a sense. On the enterprise side, we have something like 30 million people using these services, so it’s a much larger task than I’ve been used to in the past. It’s very exciting to see the way this has been growing.

The big three challenges that I see as I’m trying to protect the average Google user are, number one, authentication. If the bad guys get your password and that’s all that protects your account, then [they] can do anything you can.

The second is malware. The world is just not win­ning the war against the malware authors, despite all the talented antivirus efforts. If anything, we’re see­ing a larger problem because attacks that used to be specific to a particular operating system now become cross-platform as we get the interoperability that we want with plug-ins and browsers and such, so that’s a big area, a big challenge.

Finally, Web-application vulnerabilities for the cloud space. The browser is a very complicated secu­rity environment, so I don’t blame engineers for hav­ing a hard time getting it right, but there are some things that are making that situation better.

Ghosh: I haven’t seen too much written about malware challenges with the cloud, and you bring up the interesting no­tion that now we’re talking about cross-platform at­tacks, because your cloud isn’t typically associated with a particular platform. Have you seen any evidence, or is this just sort of a projection of what may come?

Grosse: No, although the cloud certainly does de­pend on servers and datacenters, I’m not thinking about malware in the datacenter, thank goodness. [Laughter] I’m worrying about protecting the client end of this cloud ecosystem. That’s really where that problem is with malware.

Ghosh: John, can you describe the scope of Micro­soft’s efforts in cloud computing?

John Howie: Absolutely. I think a lot of the challenges [that] Eric brought up, are nearly identical for Micro­soft. The one thing I would throw into the mix is that, unfortunately with the cloud, your enterprise customers - your internal users - have potentially an unrealistic expectation of additional security in the cloud, so when they see anything in their cloud, whether it’s public or private, the majority assume it’s safe and trusted. It would never cross their minds that one of their colleagues, who also works for them and is sitting alongside them in the cloud consum­ing cloud services, may actually be sending malicious documents, malicious content, to them.

Ghosh: Jim Reavis from Cloud Security Alliance, do you want to speak for a moment on what you see as the top security challenges that Google, Microsoft, Ama­zon, and Cisco might face with their cloud services?

Jim Reavis: At the top of the list is just broker­ing transparency between providers and consumers. That’s always the real challenge when you’re in a new, disruptive phase of any type of technology.

Second is data - protecting the data - because we have so many different regulations out there, and a lot of them are jurisdictionally focused. And then, third, I would say, is the evolving threat model as you implement new types of computing systems. Looking at how the bad guys - and they are early adopters of cloud computing themselves - and how they’re going to evolve and look to attack new systems.

Ghosh: I want to give a chance to Steve Schmidt from Amazon Web Services to talk about the size and scope of their cloud operations and top security challenges as well.

Steve Schmidt: Amazon Web Services is really more of an infrastructure-as-a-service and platform-as-a-service offering right now than what you would get from Google typically.

Just to give you an example of the scope of one indi­vidual component of Amazon Web Services, and Ama­zon has three, which is our object store, which has about 152 billion objects in it and processes about 100,000 transactions per second. The single largest challenge that we face, actually, is making sure that we describe the shared-responsibility model of security appropriately to our customers. I heard one of our colleagues here talk about shared responsibility, and that’s an important dif­ferentiation between the cloud model and one where someone operates something in their own datacenter.

We’re responsible for the security from the con­crete of the data-center floor all the way up through the hypervisor. Customers, on the other hand, have responsibility for security of their operating system and their application layer, and making sure that that delineation is accurate, is complete, and that the cus­tomer knows what to do is critical to our success as an organization and the customer’s happiness with their services.

Jim Ransome: I’ll speak to WebEx, because that’s the business unit that I represent at Cisco. The big­gest challenges I see right now within my particular environment would be control alignment and opera­tionalization, basically doing the operations for the three security initiatives that we have: ISO 27001 and -2, which obviously are for our enterprise custom­ers, NIST 800-53 and NIST 800-37 for government/ public-sector customers, and PCI for the finance world with regards to the credit-card transactions that we use with our cloud transaction model.

The other part, I’d say, would be making our se­curity program transparent to our customers. In a fast environment for software as a service, which we are, this needs to be as transparent as possible to customers, because we’re providing most of their security.

Ghosh: A question that’s been burning on my mind is that we’ve got the major cloud service providers obviously investing significant amounts of dollars for putting this infrastructure out there and signing up customers. There are a lot of issues around security and trust in this environment, so what data do your companies not put in a public cloud and why?

What data would Microsoft, of its own corporate data, not put into your public cloud?

Howie: That’s such a great question. Tony Scott, who’s our CIO, and Steve Ballmer, who’s our CEO, have given us a mandate that everything must go into Azure [Microsoft’s platform as a service (PaaS) offer­ing; www.microsoft.com/azure] wherever possible, and so all of our internal line of business applications are being considered for migration to Azure. Now, there’re some things that will never go into Azure, for example, our SAP back end. That won’t go into Azure, but anything ranging from performance to payroll to our annual giving campaign, our corporate social-responsibility campaign, all of that is going into Azure, and a large part of it is already in today. So we are definitely hell-bent on getting stuff into Azure.

There are still some things that we’re holding back. One of the big ones right now is PCI DSS, because there’s a gray area around the use of virtualization for the payment-card industry, the security standard, so we’re holding back some of those things, but the majority of our in-house line of business applications are already candidates for moving into Azure, and, in fact, some of them are already in there. The rest are being ported over right now.

Grosse: Yes, I’d second that. There are very few kinds of data that we don’t put in our cloud, including our most sensitive material. For example, slide decks for top executives regarding our acquisitions, when my team is doing some of its most sensitive internal se­curity investigations, those notes are right in the cloud - performance-review materials, you name it. We really do trust our own cloud systems. We rely on them daily.

Ransome: If we do not trust our own clouds, how can we convince our customers to trust our clouds? There are some exceptions to that, obviously, where you have either regulatory or government requirements - where it absolutely has to be in a private cloud—and then you get into the conversation of whether or not it’s truly a hybrid cloud, private cloud, or public cloud, but as far as most of what we put from an enterprise standpoint, I would agree with the other two speakers.

Schmidt: Absolutely agree with the other speakers, and, in fact, when we do a lot of demonstrations to our customers, specifically enterprise customers, we actually use as one of the case studies our internal movement from in-house standalone systems into the cloud. It’s an example of how we think things can be done right, done safely, and increase efficiencies dra­matically. Just as an example, in-house SAP operations we move into the cloud, specifically, in fact, because SAP’s on-demand offering now runs on Amazon Web Services, so any kind of in-house data you can think of, we’ll move into the cloud.

Iván Arce: Regulation and compliance have been noted several times already, and the fact that there are regulatory pressures and compliance requirements has been discussed in detail about the cloud. But I wonder how much of that is real - and how much of that is theoretical?

Reavis: Technology, as it always does, sort of races ahead of these regulations, and so we run into real is­sues trying to explain to a regulator that’s maybe in­terested in information and protecting it for citizens inside of a certain country how we can assure that that information is protected and if, in fact, we can assure that it’s actually going to remain inside of that country.

Arce: Let me follow up quickly, because, Jim, did you say something about showing the compensating con­trol that follows the spirit of the regulatory framework or what’s required for a given industry or jurisdiction? From a practical standpoint, is that enough? Is it suf­ficient for cloud providers to demonstrate that they’re right with the spirit, or are regulators, auditors, much more strict with what they’re looking for?

Howie: At Microsoft, we often run into a situation whereby there are conflicting laws, and we have to navigate the statutory and regulatory landscape and do our best to show intent to comply with the spirit of the law.

Here’s a classic example: the EU Data Protection Directive and EU Data Retention Directive. The Data Retention Directive was passed in 2006 by the European Union. Basically member states are allowed to write a law - well, they have to write a law, but they’re allowed to put into that law a period of data re­tention for certain metadata regarding telecommuni­cations and data communications, and that data must be retained for between six months to a maximum of two years. Ireland, where we have a publicly disclosed datacenter, says two years; Germany says six months. And we’re often posed with the question, “Well, if a German citizen in Germany is accessing a ser­vice in Dublin out of our datacenter, do you keep the data two years or six months?” German law says categorically six months; Irish law says two years, so our answer is it’s two years, and Germany has said to us, “Well, you’re breaking German law.” What then happens if that German citizen travels to Spain? Spain has a retention period of one year. Spain claims that its law takes precedence. Germany says, “No, this is a German citizen; therefore, our law takes precedence,” and our data, which is housed in Ireland - the Irish law says two years.

So you can only ever really hope to meet with the spirit of the law, because when you’re a global organi­zation you cannot comply with a law in every single company you do business in. It’s just not possible. And to Jim’s point, a number of the regulations were written with some really good intentions in place but without understanding its underlying technology.

There’s a great saying that Microsoft Chief Privacy Officer Brendon Lynch likes to quote, and that is, “All data is global. All laws are local,” and as a result, you cannot comply with every single law in the world. It’s just not possible.

Grosse: I’d add that although it is frustrating to go through some of these regulatory frameworks, it’s still possible. We were able to get FISMA certification, for example, so one has to adapt these rules, but we find that the people running those frameworks do appre­ciate the cloud is different and they’re reasonable, so that part’s fine. What I do see, though, is so many people trying to define a new cloud security frame­work. Someone I heard counted dozens of different competing proposals. We already had too many dif­ferent frameworks to try to meet.

I would really love to see some consolidation in this security frameworks base so that when we go to a customer and say, “Okay, we understand that you need to certify the security before you’re willing to trust the data to the cloud,” if we had fewer of these distinct checkboxes to work up against, that would really be more efficient for everyone.

Ransome: I would concur with that as well that there needs to be a common control framework to unify commonly known and accepted industry standards and regulations. I really like Cloud Security Alliance’s effort - a controls matrix - but I think we do need an industry standard very similar to what is happening, I think, with the ISO 27001, where it becomes some­what of a de facto standard. You’re going to meet 80 to 90 percent of the security requirements that are out there by adhering to that, and then you do a business ROI analysis to figure out whether that extra 10 or 20 percent is worth the market you’re going into.

Arce: Do you think these different frameworks have, if you will, a too-narrow view of technologies ap­plied to security, things that do not really apply well to cloud service providers?

Howie: Yes, absolutely. Also, I think there’s always a challenge for any law or regulations within an appoint­ed time. You’re reliant on two things: one, the people writing that law or that rule and [two] that they write that regulation understanding the technology available today. But you’re also asking them to have an uncan­ny ability to predict what the future will look like as well, because by the time anything hits statute books or regulations published, the industry’s already moved on, and we’ve already got new technologies, and new technologies come to market all the time.

The other thing that I don’t think the legislatures, the legislators, and the regulators look at or consider is the sheer scale of cloud computing. For example, one of our commonly quoted figures, although it’s now out of date, is our ingress traffic, that incoming traffic rate of HTTP alone, not including SSL - is in excess of 145 gigabits per second. When you get someone who says, “You should always have intrusion detec­tion systems on your connection at the perimeter,” I’d have to put a datacenter for just IDS boxes and try and lift up that bandwidth just to do that. It just can’t be done.

Grosse: I agree that regulations that would talk about intrusion detection or malware detection or deep pack­et inspection on the network really are being passed by with current technology trends. Pervasive crypto, the use of SSL by default everywhere makes a lot of those measures inappropriate, but even beyond that, the whole notion that the main line of defense is the perimeter is also a less realistic view of modern security technology and practices, so we certainly depend a lot more on putting the protection close to the data rather than at the perimeter of the cloud or of a company.

Arce: Is there anything to say in that regard in terms of internal technologies and security controls that may or may not apply?

Schmidt: The cloud environment is very, very dif­ferent, as my colleagues have described. The scale is different. The implementation is different, and we firmly agree with the de-perimeterization is­sue. It’s one that really represents getting away from that fragile eggshell with a chewy center, which is a hacker’s delight. Once you get past that front door, you can run around pretty much unmolested inside a perimeter, and instead apply appropriate, reasonable security controls at every layer in the stack, apply them where it’s appropriate for your design, apply them where it’s reasonable for your operations, and apply them where it’s necessary to achieve the individual risk management goals that companies have.

Ghosh: I would like to get a feel as consumers and businesses move to the cloud—and their data is moved to the cloud for cost and efficiency reasons—what are the biggest privacy risks that users and companies need to be aware of? What do you do to provide as­surance against privacy risk?

Howie: Customer data is sacrosanct, and we’ve got very strict controls around where that data will have to go and who’s allowed to access it. It’s a very dif­ferent model from Facebook, and so a lot of privacy concerns you’re seeing about Facebook you do not see translated into the enterprise cloud arena. They’re very different business models, at least in the Micro­soft view of the world.

Internally at Microsoft, every developer has to un­dergo privacy training. Every operations person has to undergo privacy training. We have very strict rules in place around access to data.

Schmidt: If a customer decides to put it in the US, it’s going to stay in the US; we say so contractually. If the customer chooses to put the data in the Asia Pacific area, it’s going to stay in the Asia Pacific area. Interestingly, we have just as many customers who say, “I want to store my data in Europe, and I want you to guarantee to me - because I need to comply with EU privacy laws or I need to make sure that I’m not subject to surveillance by the US government, that it’s not going to be moved to the United States without my consent.” We say that as well.

We have very strict procedures in place for when our employees are allowed to access the machines the customer data resides on. We keep track of every ac­tion that they take on those machines, and we log all that information for later audits so that we can ensure that all employees are behaving consistently with our privacy policy.

Ghosh: Eric, Google’s been mentioned, and obvi­ously with Google Docs, people’s personal informa­tion certainly goes into the cloud. Can you speak some to the privacy risks and controls that Google puts in place?

Grosse: We have zero tolerance for insiders abusing that trust, but it’s so rare it’s not really the main con­cern I have. I feel like the privacy issue has a lot more to do with the user understanding the normal, ap­proved flows of information and being sure that the user has transparency and control.

Ghosh: If you look at a scenario today, in which your data is inside your company’s firewall on desktops, on servers, and you look at a scenario in the future, in which the data is moved to the cloud and seamlessly accessed from any number of different consumers of that data, you’ve now really concentrated that data— you’ve provided single access. From the hacker’s point of view, I don’t have to compromise lots of machines inside your network—I really need to get access to your cloud service. What do you guys see as the threat landscape against cloud computing services, how it’ll evolve given the opportunity here to gain access to sensitive data?

Howie: The threat landscape is always evolving, and we have a threat team that’s dedicated to looking at threat landscapes and evolving threats and then modifying or adjusting our controls in a continuous assessment pro­cess to ensure that we’re defending against those threats.

We do have other tools that we use as well, and we’re always looking at the next set of threats. I can’t tell you what the big ones are, because they’re always changing. Today’s threat might be different from tomorrow’s threat. The typical stuff we’re seeing, though, right now: the colored background noise, phishing attacks. Nigerian 419 scams are still ongo­ing. That’s always gonna happen; we’re always seeing that. It’s hard to get attacks against the cloud infra­structure. We’ve seen our fair share in the last year of denial-of-service attacks. We’ve seen a fair share of DNS hijacking.

I know that Google in the last 12 months has seen something very different from what we’ve seen, and I’ll let Eric talk about that. We’re working with our current partners in Amazon, Google, and others to share information, and Jim is completely plugged into that as well. But our response to the evolving threat landscape is continuous assessment of the threat land­scape itself and then adjusting our controls to address the risk from that.

Ghosh: For Eric, it would be great to point to spe­cific types of attacks or incidents you’re seeing against cloud computing, perhaps how they might be differ­entiated or to speculate how they might be unique and differentiated.

 Eric Grosse: I think the reference was to the Decem­ber event that we blogged about in January, in which we saw a very sophisticated level of attack that lots of people in the security media would’ve thought only happened to governments and defense contractors, and we pointed out that, actually, no, it’s going across all corners of the economy. We uncovered an attack, and in the course of our investigation, reached out to some 20 other companies, noting that their systems were also victims, and so I really don’t think that’s specific to cloud computing.

Very sophisticated threats [are] coming after you that may not be easy to see, but they’re there, and you certainly have to be ramping up your efforts on that. I think we should also look at some of the new opportu­nities that the cloud lets you use to recognize problems.

In a pure cloud model, let’s say you’ve got a hard­ened client that’s running nothing but a browser. There’s no local state except some encrypted cache. All of the data is actually in the cloud, so if a lap­top gets stolen, you’re really not at any risk - there are opportunities that look pretty appealing in terms of some defenses that weren’t as available before.

 Arce: Do you see trends that seek to use the cloud ser­vice as a way to amplify an attack to other consumers? Have you seen any of these trends in cloud services?

 Howie: Absolutely we have a concern - and Jim and the Cloud Security Alliance actually have this in their top threats - and that is a malicious individual or or­ganization contracted with us and is hosting malware or whatever on our service. This is true for infrastruc­ture-as-a-service offered by our colleagues at Amazon and also for platform-as-a-service offered by Micro­soft, perhaps also the app engine offered by Google, where they may have stolen credit cards, and they come to you and they’ll go online, because there’s no interaction at a physical level to buy the service.

You can spend a lot of time trying to create a bot­net, and you may or may not be successful and you’ve got to do the command and control on the infrastruc­ture or they aren’t going to stop.

The cloud could well be the biggest botnet. Con­versely, of course, you could argue that botnets are the most successful version of cloud computing today. But either way it demonstrates what the problem is.

Going back to something we talked about earlier about privacy, we don’t routinely inspect what our customers are doing in the cloud because, hey, they’re paying customers and it’s their data and it’s their ser­vice and they’re buying computing parts from us and a service from us. We often don’t immediately know when someone’s doing something nefarious in our cloud, and we have to rely on other mechanisms and notifications and abuse reports to actually know when some malicious individual or organization has bought service in Azure and is using it to serve mal­ware or to perform phishing attacks. We might not be the first to know, because we’re not allowed to look at what they’re doing with our service because of the privacy rules.

Reavis: I think in aggregate, security’s going to be bet­ter, because you’re essentially going to have profession­als running a lot of the security operations, and they’re going to be trained. It’s going to create a more even baseline, but it’s just the threat services, the attack ser­vices are going to change. And I’m calling on all cloud providers to be ready for those changes and circum­stances when there’s this tipping point that enterprises have more information in their clouds than they did before. Then they’re going to see some actors attacking them in a way that they didn’t before, so it’s a lot.

Ghosh: There’s been talk in the industry about con­nected clouds, so we don’t have cloud islands but instead sharing of cloud information. Anyone see both chal­lenges and opportunities, including security benefits and security risks, as you see federation of cloud services?

Grosse: At Google, we have something called the “data liberation front” that asks three key questions: Can I get my data out at all? How much is it going to cost to get my data out? How much of my time is it going to take to get my data out? And the ideal that we shoot for as answers to those questions are: Yes, you can get your data out. It costs nothing more than you’re already paying and as little time as possible to do that if you want.

So, none of us are perfect, but the interoperabil­ity is really going to come down to everyone agree­ing that that’s the model, that data belongs to users so they should be able to extract it. To really make that most effective requires the interoperability standards so when they do export that data, they can then easily import it somewhere else. That’s really what’s going to drive a great competition in the space.

Howie: Now, the question is: Can you get to the next level so that a customer who is working in multi­ple clouds could federate space they are already in, whether or not the cloud service providers realize it. Can they actually just simultaneously, transparently move data from, say, Salesforce.com to Google Docs or Microsoft’s online services? Because you may have a customer that’s using Salesforce for their CRM. They might be using Google Docs for something. They might even be using Azure for something else, and do the cloud service providers get together and provide some means to move data between them? I’d suspect that’s a while away, and so some standards come into play, but certainly getting data in and out is absolutely critical.

The other key thing, of course, is the identity meta system - allowing the consumer to have a sin­gle identity, which can be used across all cloud ser­vice providers. The simplest means to that, of course, is federation to an on-premise directory store. The challenge there is that standards only allow that to work successfully when you’re accessing your cloud services using the browser.

 Grosse: Since we’ve been working at this for a while, I’ll add a couple of other insights on this topic of data export. One is that we find customers are very keen to export, not just the data itself but metadata - say, configuration information about their account and so forth - and it’s not necessarily because they’re export­ing it in order to go somewhere else. If they can ex­port the data in a standard human-readable form or easily parsed form, they can choose to do some pro­cessing of their own on it to, say, look for changes that seem anomalous to them given some extra knowledge about their corporation.

There’s a security issue that arises. In a world where we haven’t solved the authentication problem and someone’s account may get hijacked, if we’ve now made it very easy for the bad guy on a moment’s no­tice to export absolutely everything, we’ve amplified the ability to cause harm and to leak information.

I think another challenge for us in the security in­dustry is to figure out not only, “How do we do the initial account authorization using something stron­ger than passwords?” like with the two-step verifica­tion we’ve done, but, “How do we also find a usable way for users to add an extra amount of authentication when they’re about to do an operation that has espe­cially high value, like export all my data or delete all my data?”

 Ghosh: On behalf of Iván and myself, and IEEE Secu­rity & Privacy, we’d like to thank the panelists for tak­ing the time to talk about cloud’s computing security risks; it was a very enlightening discussion.

About the Panelists

Eric Grosse, Engineering Director, Google Security Team, is responsible for protecting the security of users, customers, staff, and systems. He joined Google early in 2007 from Bell Labs where he had been a fellow and led research depart­ments in security, networking, and scientific computing. He has a PhD in computer science from Stanford University.

John Howie is the senior director of Technical Security Ser­vices for the Online Services Security and Compliance team within Global Foundation Services at Microsoft. He man­ages the teams responsible for identity and access manage­ment, strategy and architecture, threat management, and incident response for the company’s cloud computing in­frastructure.
Howie has a Bachelors of Science with Honors in computing from Edinburgh Napier University, Scotland.

James Ransome is the senior director and chief security of­ficer of Cisco’s Collaborative Software Group responsible for operational and strategic direction for the organization and its customer security.
He manages security and compli­ance efforts across multiple functions, including informa­tion technology, operations, product development, human resources, communications, legal, facilities management, and other groups with a particular focus on software as a service (SaaS) and WebEx service delivery.

Jim Reavis is cofounder and executive director of the Cloud Security Alliance. He previously was an international board member of the ISSA, a global not-for-profit association of information security professionals, and served as the asso­ciation’s executive director. Reavis was a co-founder of the Alliance for Enterprise Security Risk Management, a partner­ship between the ISSA, ISACA, and ASIS, formed to address the enterprise risk issues associated with the convergence of logical and traditional security. Reavis has a BA in business administration/computer science from Western Washington University.

Stephen Schmidt is chief information security officer for Amazon Web Services (AWS). In addition to being respon­sible for AWS’s standards-based security compliance, he currently leads security-centric product design, manage­ment, and engineering development. Prior to joining AWS, he had an extensive career as a senior executive at the US Federal Bureau of Investigation, including a term as chief technology officer and section chief of the FBI’s Cyber Divi­sion, overseeing areas of malicious code analysis, computer exploitation tool reverse-engineering and technical analysis of computer intrusions.

This article first appeared in IEEE Security & Privacy magazine issue Jan/Feb 2011. IEEE Security & Privacy magazine rovides articles with both a practical and research bent by the top thinkers in the field along with case studies, tutorials, columns, and in-depth interviews and podcasts for the information security industry.