Keeping PCs Safe on the Internet

PC Security Journal

Subscribe to PC Security Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get PC Security Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


PC Security Journal Authors: RealWire News Distribution, Denise Dubie, Lacey Thoms, Bob Gourley, Michael Bushong

Related Topics: Cloud Computing, PC Security Journal, Twitter on Ulitzer, SaaS Journal, IBM Journal, Security Journal, Platform as a Service, CIO/CTO Update, Java in the Cloud

Blog Feed Post

Application Security in the Cloud Is Still Cloudy

An interesting statistic raises an even more interestinger question

IBM shared a security related infographic via Twitter recently and in looking through the statistics (most of which are attributed to 2011 research, by the way) I happened to catch a statement claiming "The average company is attacked 60,000 times a day."

IBM notes that "average" is average for the study, which consisted of mostly large enterprises, and while I'm certain there are still experts who would dispute this claim (it's higher! it's lower! That's only an average of a subset of a selection of a ...) for me it raised an interesting question with respect to attacks and cloud-based applications: If your application is deployed in the cloud, how do you if/when it's being attacked? Perhaps more importantly, though, is whether or not you should know. After all, "the cloud" is taking care of all that infrastructure and networky stuff under the covers for you, right? And one of those "stuff" is addressing attacks.

NETWORK versus APPLICATION
Certainly there are many instances of organizations pointing out that their cloud provider is, in fact, dealing with network layer attacks.

We could spend an entire post detailing attacks (there've been many) but that's not the point. In general, the attacks that cloud providers are able to detect and thus address (even reactively, if not proactively) are network layer attacks, not application layer attacks.

You know, the kind of attacks that target vulnerabilities in either your application or its platform (web / application server) and sometimes in its network stack (think SYN floods and such). Cloud providers would (logically and correctly) point out that they have no control over the application or its platform (unless it's a PaaS or SaaS provider) and thus it is not their responsibility to monitor for attacks against those components.

And they'd be (mostly) right. Even in the cloud, the security of your application is still your responsibility because it's your application. Potential vulnerabilities in the application layer - whether data, logic, behavior or code based - are yours to address, not the provider. Where things get murky is at the protocol (HTTP & TCP) layers [pdf], where exploitation can be used with relatively few resources to successfully execute a DDoS attack against your application and yet there is virtually no way for the application instance to recognize such an attack.

l7stack

That's because detecting some types of application layer attacks requires visibility into both client characteristics as well as its behavior. A client connecting from a 100Mbps capable LAN that purposefully tries to use a tiny TCP window size or seems to be receiving data at a rate far below what it is capable of just might be part of an attempt to consume and keep busy application resources and in doing so with enough clients, successfully deny service to legitimate clients.

This kind of attack (which is often part of a holistic and much larger (not to mention coordinated) attack designed to distract organizations from true intent) is not detectable by an application instance unless it has end-to-end visibility. In the cloud, that's just not possible. Visibility into client characteristics is typically no deeper than a client IP address stuffed into a custom HTTP header. You can't infer an attack from an IP address, and transfer speed means little without other variables against which to measure the normality (or abnormality) of the behavior.

Even deploying traditional services to address (web application firewall, application delivery firewall) may not provide the visibility required because those services are being deployed atop the abstracted, service-based infrastructure and are treated more like application instances than infrastructure services in need of visibility into the network. Certainly these services will assist in mitigating many application layer attacks that focus on logic, platform, or data exploitation, but they may not be able to fully analyze the protocol layer because of the many layers of abstraction between them and the variables they need.

Thus, while aspects of application security in the cloud are certainly the responsibility of the developer (or organization), there are other aspects that require the assistance of the provider. Either in the form of services that have access to the information necessary or a means of sharing that same information with services deployed atop the infrastructure.

Which leaves us where we are today: application security in the cloud is still cloudy. It's definitely an area in which there is room for new services and solutions.

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.