Cloud Security

I’m in the middle of preparing for Black Hat Europe where I’ll be speaking about Cloud Security.  Here’s the blurb:

This presentation rips apart the hype and “newfangledness” of Cloud Services (IaaS, PaaS, SaaS etc) to expose the ghost in the machine. Just as the human brain has grown, built upon earlier, more primitive brain structures, so it is with the Cloud. With the advent of commercially available, pay-as-you-go public Cloud services, CFOs are casting a weary eye to the CIO in anticipation of joining the great infrastructure linedance in the sky. Meanwhile, vendors are jockeying for position to “enable” the Enterprise Cloud and Cloud brokers are trading excess compute capacity in data centers. What does all this mean from a security point of view? What are the security risks (and benefits)? Are you ready to face the ghosts in the Clouds?

I’m really looking forward to this.  If you’re going to be there, let me know!

Full details of the conference, along with paying 200 Euros less if you register by Wednesday 8th April are here

I’m proud to announce the results of a recent security collaboration with Amazon AWS.

As Jeff Barr announced on the AWS blog today:

Early this morning we launched a brand new cloud computing service. This revolutionary new technology will change the way you think about the cloud.

For a while the cloud was simply a metaphor meaning “a bunch of computers somewhere else.” Until now, somewhere else meant good old terra firma, the Earth itself. After extensive customer research we found that this rigid, antiquated way of thinking just won’t cut it in today’s post-capitalist world. They need locational flexibility, the ability to literally instantiate a cloud where they need it, when they need it.

To solve this problem, we have designed and are now introducing the Floating Amazon Cloud Environment, or FACE for short. Using the latest in airship technology, we’ve created a cloud that can come to you.”

If you’ve been watching Amazons SEC filings, you’ll know they invested heavily in nano. FACE is the first realisation of that investment.

Jeff continues on to implementation details:

The FACE uses durable, unmanned helium-filled blimps with a capacity of 65,536 small EC2 instances, or a proportionate number of larger instances. The top of each blimp is coated in polycrystalline solar cells which supply approximately 40% of the power needed by the servers and the on-board navigation, communication, and defense systems. The remainder of the power is produced by clean, efficient solid oxide fuel cells. There’s enough fuel onboard to last about a month under normal operating conditions. Waste heat from the fuel cells and from the servers is used to generate additional lift.

This is a big win energy wise but presents some interesting communication and security issues.

There are two options for ground communication, WiMAX and laser. The WiMAX option provides low latency and respectable bandwidth. If you have the ground facility and the line of sight access needed to support it, lasers are the way to go. The on-board laser doubles as a defense facility, keeping each FACE safe from harm. Using automated target detectors with human confirmation via the Mechanical Turk, competitors won’t have a chance.

I can now spill the beans on the security aspects of the solution (subject to NDA).

FACE Security

Since FACE is an untethered environment, ensuring cross airspace data transfer compliance was a non-negotiable. It was therefore essential to implement a data privacy ‘hints’ system, whereby the on-board GPS system could be programmed to correlate GPS co-ordinates with terrain specific data privacy laws and issue AMQP style ‘nudge’ messages to the navigation system to counteract potential jurisdictional data drift. The neat thing about this approach was that different FACEs could be deployed to satisfy customers in different regions (much like EC2). Furthermore, should two FACEs need to converage for cross-FACE data transmission, one FACE could draw energy from the other FACE’s solar cells. This turned out to be very useful for availability, particularly for the UK FACE where low cumulus made solar cell charging difficult (thanks to the Portugal team!)

Another security concern was the laser. Amazon legal was naturally concerned about potential liability issues should an attacker compromise a FACE and launch a reverse protocol attack to commandeer ground facilities. If an attacker were able to take over the lasers this would not only be a physical security risk but a PR disaster for Amazon. This led to the development of a novel security protection we nicknamed FACEMASK (original huh?). The idea behind FACEMASK is really simple: treat rapid changes in the solid oxide fuel cells as a potential breach indicator. How so? It turns out that both stack and heap buffer overflow attacks result in a fluctuation of the normally highly stable oxide full cells powering FACE. This isn’t special in itself, however the fingerprint of the energy draw *is*. We developed a catalogue of fingerprints and in testing were able to detect 91% of attacks reliability. No security is perfect and we’ll continue to refine the coverage, however compared to existing signature based defenses, this is orders of magnitude better.

Anyway, I promised I wouldn’t say more, but I hope this gives you a taste of the unique challenges and solutions and how “off our box” thinking can be applied to Cloud Security.

As Jeff hinted in his blog post, this is a limited offer - the doors are likely to close tomorrow. For more information, click here.

Peter Coffee from Salesforce.com was recently quoted in the Australian edition of Computer Weekly talking about the prospect of Compliance as a Service:

“There are composite solutions [to compliance issues]: build the application in the cloud using nothing but anonymous tokens to identify customers… but that is not trivially easy to do,” he said.

“Instead, compliance as a service maybe be offered where [the service provider] acts as an intermediate layer of your application that takes care of a variety of things. They could indemnify the customer against any issues around personally identifiable information crossing boundaries.”

Under such a compliance service, a service provider would accept the burden of knowing the rules, court precedents and regulations which are industry-specific, Coffee said. Responsibility to sanitise data wherever it left the country over a broadband link would move from the customer to the service provider.

“Layers upon layers of new services will emerge representing new layers of expertise and therefore new layers of profitability for those providing services with that kind of value. I think that’s happening now and more so all the time.”

If you consider the cost, complexity, misinterpretations and challenges that organisations face trying to be ‘compliant’ today with their in-house IT, “Compliance as a Service” (CaaS) has to be a Cloud marketeer’s dream!

More seriously, how else can you enforce continued compliance across multiple service providers? This comes back to the notion of packaging security policy along with data, such that in a multi-Cloud provider environment, there is a way to establish automagically who can meet the policy requirements on a dynamic basis.  But would you trust the digital word of the providers?  A provider could accidentally or intentionally affirm compliance with a digitally transmitted policy and go on to accept/process workloads in Clouds that are not suitable/compliant for the data.

Could a 3rd party CaaS inserted “man in the middle” style, act as a trusted arbitrator? If a CaaS provider offers to bear liability for compliance misses and was able to satisfactorily hide the complexity of compliance for the right price, you could foresee such a provider establishing a dominant position in the Cloud-o-sphere.

Right now though, this is all speculation on my part.  Does anyone know of such a service or are you developing one? I’d love to hear about it.

The Electronic Privacy Information Center (EPIC) has lodged a formal complaint about Google to the US Federal Trade Commission (FTC), insisting that they investigate the adequacy and sufficiency of Googles privacy and security safeguards.  EPIC is also seeking changes to Googles Term of Service and a suspension of Googles Cloud Computing services until ’safeguards’ are verifiably established.  Finally, they want the FTC to “compel Google to contribute 5,000,000USD to a public fund that will help support research concerning privacy enhancing technologies…”.

EPIC forwards this complaint on 3 primary fronts:

• the specific ways that Google represents their security controls to consumers (yet disclaims all responsibilities in the Terms of Service)
• the “harm” caused by the recent Google Docs privacy breach
• the claim that Google has “inadequate security”

Secondary arguments include citing a number of other, older vulnerabilities in Google online services and referencing some significant privacy breaches where the FTC acted before.  In my view, these are distractions and inconsistent with the primary argument.  The call for Google to pay 5 million dollars is poorly framed, seemingly an afterthought and potentially devisive.  I suspect EPIC will have lost the goodwill of privacy moderates by making such a demand.  Had they just dropped the number and left the call for a fund, it might have made it more palatable.

Given the complaint is 15 pages long, there is plenty to comment on.  For the sake of brevity, lets contain our analysis to the primary arguments, introduce a potential curveball and go “one step beyond” to examine the implications for Google users should the FTC rule in EPICs favour.

What Google Says About Security

EPIC highlights two specific security claims made by Google.

On the Google Docs homepage

Getting to know Google Docs> Saving your presentation

The complaint then goes on to suggest that Google “encourages users to add personal information to their documents and spreadsheets” and repeats the statement made by Google that “your data is private, unless you grant access to others and/or publish your information”.

Having built their primary argument based on public statements made on Google online properties, they bring out the Google Terms of Service which states in Section 14.1 that the services are provided “as is”, with no warranty and that Google does “not represent or warrant” that [14.2 B] “your use of the Services will be uninterrupted, timely, secure or free from error”.  Section 15 states that Google will not be liable for losses.

The Harm Caused By The Google Docs Privacy Breach

EPIC then attempts to link the Google Docs privacy breach with harm experienced by Google users:

Curious.  2 sentences in a 15 page report where EPIC could have firmly established the ‘harm’ case.  No examples, no quantification, no impact analysis. Perhaps EPIC is playing its hand carefully and is readying a parade of impacted users who can demonstrate they were “harmed” by the privacy snafu.  Failing that, it would mean they have built their case on the morality of a software privacy bug at a popular online service and ultimately, an industry wide disparity between the big print a company uses to market their services (and software!) as trustworthy and the small print where the lawyers spell out the case for the defense.

The Claim That Google has Inadequate Security

The third and final primary argument.  Skipping past the reminder from EPIC to the FTC that they acted in response to other privacy breaches, EPIC goes on to state that Google’s “inadequate security is an unfair business practice” and that Google’s “Inadequate Security” is a deceptive trade practice”.   They argue that the Google Docs privacy breach was a result of inadequate security practices and that Google:

• encourages people to share “sensitive” documentation in promoting their services
• “knew that Cloud Computing Services are susceptible to data breaches”
• “knew that disclosure of personal user data could cause substantial injury to customers”
• was “aware that commonsense security measures, including storing user data in encrypted form, rather than in clear text, could reduce the likelihood and extent of consumer injury”
• “created an unnecessary risk to users’ data by employing unreasonable security practices, including the storage and transmission of personal information on its computer network in clear text”

What I find fascinating about this is that EPIC is drawing a significant conclusion about Google’s security practices based on the fact that Google doesn’t take “commonsense” security measures. In other words, because Google hasn’t implemented a PKI and DRM for document sharing in a (for many) free service, Google is somehow employing unreasonable security practices (!).

This just strikes me as really unreasonable and wholly unrealistic.  If the FTC mandated those level of security protections to “qualify” for accepting data that consumers choose to put in the Cloud, you can say goodnight to *all* of the popular Web 2.0 services.

With Google thoroughly chastised, they draw the following “big picture” conclusion:

First Google, now the Cloud Computing as a whole - I’d better change my domain name fast! ;-).

A Potential Curveball

After I posted my thoughts on how Google Security responded to the Google Docs sharing problem I was contacted by a Google Docs user who stated that he reported a sharing problem to Google in January. He discovered a large number of documents shared with over a hundred people (he gave specific numbers that I’m intentionally not quoting to protect his privacy).  He states he called Google Tech support who initiated a support case.

Assuming this is true (and based on his note, I have no reason to doubt it) it means either:

• Google Docs has suffered another sharing problem that was quietly fixed (no notification?)
• If this is the same sharing problem, it means at least someone in Google knew about it from late January which completely changes how their responsiveness to dealing with this problem will be perceived.

What If EPIC Gets Their Way

If the FTC went as far as forcing Google to suspend its services, we will witness the largest Denial of Legitimate Service (DoLS) attack in history.

Can you imagine how that would play out?  I suspect it would also be the worst PR disaster of all time for EPIC as Google users turn on them in their droves…

In their concern for privacy, one part of security that EPIC seems to have forgotten is availability and the Cloud is all about that.

Troy Angrignon has put together a really useful Cloud Ecosystem Map.

Why is this useful?  As he states:

Following Terry Matthew’s Sir Terrence Matthews “checkerboard model”, it should be easy going forward to find logical areas that need to be built out. Think about it as “X for the cloud”. For example, identity management from the last era was mostly LAN/WAN-based single-sign on and directory service based. “Identity for the cloud” is a logical hole to fill and sure enough, that is what Symplified is aiming to do.

The map shows the companies along the X axis and the service offerings on the Y axis.

Click the screenshot for the full PDF

As you go through the map, do you spot any security opportunities?  I thought I’d see more security offerings listed but I don’t.  If that doesn’t scream ‘gap in the market‘ I don’t know what does!

Troy is looking for feedback - as he says, its version 1.0.

Let me know what you think in the comments.