Do Cloud-based Apps Destroy Web App Security?
My colleague, Ben Walther, pointed me at this post about Cloud applications and Web-app security by Rich Mogull. The title is “How the Cloud Destroys Everything I Love (About Web App Security)”. The post talks about running Web apps on a cloud platform like EC2. I’m not sure I buy into everything they say.
First, I’m not sure what Rich means by a “Web App”. To me, the term Web App describes an n-Tier application with a browser front end and some kind of backend SQL database. There are maybe some web service calls thrown into the mix. It’s the kind of applications that everybody’s been writing for the last 10 years. So, what’s going to change if I’m running this same application architecture on infrastructure that I’m buying as a service? Sure, I have to worry about all of the inter-machine communication channels because I don’t have the nice data center supplied network security. But what else?
Now when we move to cloud-based applications (environments like AppEngine or 10gen), ones that take advantage of the highly distributed nature of the code as well as the virtual environments, then we have changed the application architecture. I buy that security for these apps changes, but it’s no longer “web app” security. In these cloud-based applications, there are some different fundamental assumptions about the architecture, like no transaction serializability. But for these legacy web apps running in a virtualized infrastructure, I’m less convinced that there is a drastic change.
There are a couple of specific points made in the article that I don’t agree with:
Secure development (somewhat) breaks because the underlying platform can’t be locked down.
Just because you can’t lock it down yourself doesn’t mean that it can’t be locked down. This seems like an argument for secure deployment breaking and not secure development. Even then, the PAAS or IAAS may actually lock the platform down better than you can. It does shift the problem from looking at technical artifacts (configuration files, patch logs, etc) to looking at legal and audit artifacts (SLAs and certifications).
Static analysis tools (mostly) break.
The contention is that there’s less code you program yourself. I don’t see this as true for IAAS platforms like EC2, how much code is provided that you really need to worry about. Besides, static tools are language based and if it’s the same language, it doesn’t really matter whether it’s running on a virtual OS or a physical one. The change that breaks static analysis is the move to dynamically typed languages.
My take is that the infrastructural changes of a cloud computing have a more drastic effect on an organization’s ability to deploy securely. Being able to develop securely is based on the application architecture. I really see these as independent levers rather than a single “cloud” lever.
Technorati Tags: Cloud Computing, Security
February 13th, 2009 at 1:28 pm
Excellent post, thanks for the insights.
Just one comment for now as I put some more thought into the topic:
“The change that breaks static analysis is the move to dynamically typed languages”
I don’t necessarily agree with this. Just because commercial SAST do not currently cover any of these languages today doesn’t mean that they won’t in the future. I understand that inspecting dynamic languages is more difficult because you don’t have the characteristics of the type system to lean upon. However, certain tools such as Ruby Flog measures assignments, branches, and calls. Some dynamic languages like Groovy output Java bytecode. You may also see a move to other testing methods such as unit and module testing for security properties, particularly effective when combined with code generation and metaprogramming principles.