Saturday, July 5, 2008

What's the opposite of "Icing on The Cake"??

From Cloudsecurity.org Interviews Guido van Rossum: Google App Engine, Python and Security:


cloudsecurity.org: What security principles did you follow for App Engine?

GvR [Guido van Rossum]: While I can’t share any specifics on what we’re doing to secure App Engine, I can say that the main principle we’ve followed could be called “defense in depth”. We’re not relying exclusively on a secure interpreter, or any other single security layer, to protect our users.


cloudsecurity.org: Please provide some examples of how those principles played out in terms of the current implementation?

GvR: Sorry, we don’t divulge such information.


cloudsecurity.org: How do you contain an attacker that exploits bugs in App Engine from exploiting the underlying OS and potentially interfering with other users processes or attacking backend systems?

GvR: You are correct that there are strong measures in place, but I’m not at liberty to discuss details.


Now, there's already been discussion about this article on the Daily Dave list, which I still haven't felt up to posting on. My thoughts, from the very second I read the article, were the same as everyone else; that Google's answers in this article is nothing but blatant security through obscurity. Now it's been suggested that this is not because of Guido, it's because of Google PR. That really doesn't make a bit of difference to me. I didn't assume that it was Guido's choice to not mention any details what so ever about the security model of Google App Engine (GAE), I assume that's Google's public stance and that he is, understandably, toeing the company line. What bother's me is that Google, a company known for it's openness and sharing, is attempting to use this tactic.

Now I have no doubt that there has been significant work to secure the GAE. It's a significant risk putting up a service like GAE, and I'm sure Google took that into account and took actions to limit their risks while expanding functionality. That fact makes me more frustrated by Google's actions regarding the security plan of GAE. Being Google I imagine there are plenty of interesting techniques being applied, and it could benefit many other projects to understand what techniques are being used by Google. Additionally it's a good check for Google, to be alerted by the multitudes of programmers and security experts to potential problems, hopefully before they become real problems. It's a model that's worked for open source software for a long time. Additionally it makes it more complicated for application programmers to write the most secure code possible, as they have no idea how their decisions may affect the overall security of the application.

Unfortunately Google took the other route. Close it down, don't share information, make people go look for it. Not being up front about it doesn't mean people won't find out intimate details of how GAE works and how it's security is being implimented. To the best vulnerability researchers it just makes the process take a little longer, but it won't stop them. Microsoft doesn't provide details to most of their software, yet vulnerabilities are found in it every month. What's most ironic is Google is beginning to clam up about security issues, while Microsoft, a company known for keeping security information under wraps, has spent the past few years reversing that image. This role reversal is disconcerting at best. Regardless, as someone debating creating and releasing an application on GAE or a standalone Django deployment, I'm concerned at the idea that under GAE my application's back end security is documented as a series of "I can't share any specifics" and things that "can't be divulged" instead of being clearly and openly documented.

0 comments: