Cloud Security

A lightning post to highlight a recent change to the Google App Engine Terms of Service.

Clause 2.2 just had some text added to it:

“You agree not to use the Service in the design, development, production, or use of missiles or the design, development, production, stockpiling, or use of chemical or biological weapons.”

I’m glad they cleared that up - now all the bad guys know to use Amazon AWS or Microsoft Azure.

P.S I can’t help feeling the irony, given the App Engine logo…

Google just announced some major new features to App Engine.

In addition to offering Java (with an Eclipse plugin to follow) and a cron facility for scheduled jobs, they now offer a way to integrate your existing enterprise applications into App Engine.

From the announcement of Google Secure Data Connector (SDC) :

SDC provides the following functionality:

1. Secure link.Encrypts connectivity between Google Apps and your network. Google Apps is the only external service that can make requests over this connection.
2. Filters.Limits the scope of the types of requests that can be routed over SDC. You can configure filters to limit which gadgets, spreadsheets, and App Engine applications may access which internal systems. Filters may also be used to control which users can access and share data from your internal systems within Google Apps. You can use the user level filter control to augment the security provided by your internal system for verifying users and originating applications. Filters should not be used as a standalone authentication system.
3. OAuth Signed Fetch.Protects requests that are made through SDC. You can use Signed Fetch to authenticate requests from Google if your applications are OAuth aware. Note that SDC provides connectivity between Google Apps and your internal systems. If you do not use OAuth Signed Fetch, then SDC does not provide authentication.

In case pictures help, this is how it looks:

And these are steps:

1. Google Apps forwards authorized data requests from users who are within the Google Apps domain to the Google tunnel protocol servers.
2. The tunnel servers validate that a user is authorized to make the request to the specified resource. Google tunnel servers are connected by an encrypted tunnel to SDC, which runs within a company’s internal network.
3. The tunnel protocol allows SDC to connect to a Google tunnel server, authenticate, and encrypt the data that flows across the Internet.
4. SDC uses resource rules to validate if a user is authorized to make a request to a specified resource.
5. An optional intranet firewall can be used to provide extra network security.
6. SDC performs a network request to the specified resource or services.
7. The service verifies the signed requests and if the user is authorized, returns the data.

This will enable a whole host of data mashups using an enterprise friendly language (Java).

What I found most interesting (beyond the network security issues of Google having a large tentacle into your network), is the API trust model relies on OAuth.  All the cool kids do OAuth these days, even Twitter recently joined the OAuth party.

Google are offering OAuth as the only mechanism to authenticate Google to your enterprise applications.

Which begs the question: how many of your legacy apps are OAuth enabled?  You don’t know?  Let me help you out here: None.

This is a case of Web 2.0 meeting Enterprise -1989.

How many of your legacy apps could even be OAuth enabled?  OK, take away the word legacy (there is an implicit insult when vendors call all your apps legacy), how many of your newfangled apps could support OAuth?  This question is worth asking as without OAuth support, there is no way to authenticate Google to your applications.   Hmmm, IP level controls OK?

If Google can drive OAuth into the enterprise then frankly, they would have done us a favour.  But how many organisations are going to be willing to re-engineer apps?  Of those that are, how many are just going to say ‘its OK, its no different from our partners accessing our database (hello?)…open the firewall’.

It will be really interesting to observe how enterprise application architects react with CloudVision(tm) react to this.  It will be even more interesting to measure the enterprise uptake of OAuth (I’m not holding my breath).

Forget concerns about PCI and DR in the Clouds - Microsoft Azure just recovered from being offline for 22 hours.

The Azure Cloud is currently in Technology Preview mode which means unscheduled developer holidays are pre-baked in.

I haven’t written about Azure before (tut tut), however I have been following along.

In case you somehow missed the announcement from Ray Ozzie, this is the Azure Stack.

And this is what it looked like to the Azure development community for the past 22 hours:

As seems to be the case for Cloud outages, updates are posted to a support forum.  Here is all anyone knows thus far (via Oakleaf Systems):

This was obviously a significant outage and it will be interesting to understand the root cause.  These massively distributed systems are truly an enormous engineering challenge - we’ll wait to see what Microsoft (and others) can learn from this particular incident.

I look forward to exploring the security aspects of Azure with you in the upcoming weeks.

Mosso/Rackspace recently announced they have “PCI enabled” a Cloud Sites customer that needed to accept online credit card payments in return for goods (i.e. a merchant).

However, the website hosted on Mosso’s Cloud, doesn’t actually receive, store, process, transmit any data that falls under the requirements of PCI.

Or to put it another way, its ‘compliance’ through not actually needing to be…

This didn’t deter them from putting a “PCI How To” document together which starts as follows (emphasis mine):

Building a PCI Compliant e-Commerce Solution Using Cloud Sites

Cloud Sites is designed to provide an elastic web hosting environment.  This capability can allow an e-commerce merchant to properly handle the high volume shopping season without carrying extra infrastructure throughout the remainder of the year.  Cloud Sites is not currently designed for the storage or archival of credit card information.  In order to build a PCI compliant e-commerce solution, Cloud Sites needs to be paired up with a payment gateway partner.

They then include the following helpful graphic which I modified to emphasis where the PCI data is NOT received, stored, processed or transmitted.  Everything to the left of the red line is the Mosso Cloud and everything to the right is the Payment Gateway provider.  The middle bit marked ‘API’ is that of the Payment Gateway as called by the merchant.

As they go on to state:

The communication from the Card Processing System to the Web Front End can never contain cardholder data.  Cardholder data includes: primary account number, expiration date, name as it appears on the card, CVV, CVV2 and magnetic stripe.

Yes Cloud Ladies and Gentlemen, this is an implementation of an age-old Internet architecture that involves redirecting customers wishing to pay for the contents of their online basket to an approved and compliant online payment gateway.

This approach follows the advice that RackSpace gives with regard to their dedicated hosting business (non-Cloud):

If you deal with credit cards and are required to meet the PCI DSS, my advice is to find a way to limit the scope of your compliance as much as possible. Rackspace recently concluded a two-year effort to receive our PCI Service Provider Report on Compliance (ROC) as a Compliant Level 1 Service Provider from Visa USA.

Just to be really clear, the PCI certification referred to above is of their dedicated hosting business – not their Cloud (aka Mosso business).  Different technologies and different architectures.

So, is there any PCI angle to this in reality?

The document talks to the PCI requirement as follows (emphasis mine):

By designing your e-commerce site in this manner, PCI compliance is reduced to a Type A SAQ (Self Assessment Questionnaire) for merchants processing less than 6,000,000 annual transactions.  The current version of the Type A SAQ can be obtained at: https://www.pcisecuritystandards.org/saq/instructions_dss.shtml. To achieve compliance when all cardholder information is handled by a partner, you only need to address two of the twelve sections of the complete PCI-DSS (Payment Card Industry – Data Security Standard) and only a subset of the controls in each of those sections.  The two sections are (9) Restrict physical access to cardholder data and (12) Maintain a policy that addresses information security.

The section 9 requirements are designed to protect any cardholder information stored at your office locations. If possible configure the relationship with your payment partner so that it is impossible for you or your employees to obtain complete cardholder information.  When logging into the partner portal you should see at most the last 4 digits of a card number.

The section 12 requirements are designed to ensure you’re working with PCI compliant partners to handle the cardholder information for you and that you have a process in place to ensure those partners remain compliant.  VISA publishes a list of compliant service providers on a monthly basis at: http://usa.visa.com/merchants/risk_management/cisp_service_providers.html

If you’ve followed along this far, you’ll realise that Mosso Cloud Sites is still ‘out of scope’ from PCI requirements as they pertain to the payment process itself, as that is handed off to a 3rd party gateway (the 3rd party must be PCI compliant though).  Section 9 is relevant to the office of the merchant – not the web front end hosting provider (Cloud or not) and section 12 is about your choice of payment gateway, again, nothing to do with Mosso.

Mosso is only relevant when it comes to the PCI requirement that the merchant perimeter is subject to vulnerability scans. In other words, because the merchant has outsourced hosting of an Internet accessible web front-end to Mosso, the merchant website must pass an initial, then four quarterly vulnerability scans to meet the PCI scanning requirement.  But Mosso isn’t responsible for running those scans.  Their contribution was to ‘partner’ with two Approved Scanning Vendors who do the work.

And that brings up two PCI scanning related issues regardless of whether you host on the Cloud or at a traditional hosting provider:

• vulnerability scans must take place after major network changes
• some vulnerability checks rely on banner grabbing to determine software version numbers and some providers (like Mosso) backport security fixes resulting in failed checks as version numbers are not incremented.  This is an age-old problem and a limitation of the scanning technology, not the provider.  The Approved Scanning Vendor will need to liaise with the provider/merchant to create manual exceptions.

So what role does Mosso really play when it comes to PCI compliance today?  They permit the Authorized Scanning Vendor to perform scans and confirm software fixes are in place when vulnerability checks generate false positives.

The Takeaway

The fact that Mosso is seeking ways to help their customers off-load as much PCI compliance requirements to other 3rd parties is fine – it makes business sense for them and their merchant customers.  It’s their positioning of the effort as a “landmark breakthrough” and that they are somehow pioneers which leads to generalisations rooted in misunderstandings that is the problem.

Next time you hear someone say ‘Cloud Provider X is PCI compliant’, ask the golden PCI question: is their Cloud receiving, processing, storing or transmitting Credit Card data (as defined by the PCI DSS)?  If they say ‘No’, you’ll know what that really means…marketecture.