Clouds, WAFs, Messaging Buses and API Security…

In my Commode Computing talk, I highlighted the need for security automation through the enablement of APIs. APIs are centric in architectural requirements for the provisioning, orchestration and (ultimately) security of cloud environments.

So there’s a “dark side” with the emergence of APIs as the prominent method by which one now interacts with stacks — and it’s highlighted in VMware’s vCloud Director Hardening Guide wherein beyond the normal de rigueur deployment of stateful packet filtering firewalls, the deployment of a Web Application Firewall is recommended.

Why? According to VMware’s hardening guide:

In summary, a WAF is an extremely valuable security solution because Web applications are too sophisticated for an IDS or IPS to protect. The simple fact that each Web application is unique makes it too complex for a static pattern-matching solution. A WAF is a unique security component because it has the capability to understand what characters are allowed within the context of the many pieces and parts of a Web page.

I don’t disagree that web applications/web services are complex. I further don’t disagree that protecting the web services and messaging buses that make up the majority of the exposed interfaces in vCloud Director don’t require sophisticated protection.

This, however, brings up an interesting skill-set challenge.

How many infrastructure security folks do you know that are experts in protecting, monitoring and managing MBeans, JMS/JMX messaging and APIs? More specifically, how many shops do you know that have WAFs deployed (in-line, actively protecting applications not passively monitoring) that did not in some way blow up every app they sit in front of as well as add potentially significant performance degradation due to SSL/TLS termination?

Whether you’re deploying vCloud or some other cloud stack (I just happen to be reading these docs at the moment,) the scope of exposed API interfaces ought to have you re-evaluating your teams’ skillsets when it comes to how you’re going to deal with the spotlight that’s now shining directly on the infrastructure stacks (hardware and software) their private and public clouds.

Many of us have had to get schooled on web services security with the emergence of SOA/Web Services application deployments. But that was at the application layer. Now it’s exposed at the “code as infrastructure” layer.

Think about it.

/Hoff

[Update 6/7/11 – Here are two really timely and interesting blog posts on the topic of RESTful APIs:

Most organizations will drop in DAM and WAF, but only in critical pain points — usually after an incident where they failed to ask the questions about what-if scenarios involving further compromise into these sorts of systems.

However, many of these DAM/WAF drop-ins are monitoring-mode only, with no customization, and are too often appliances that are themselves unmonitored and misunderstood.

Questions about JMS, MQ, Enterprise Bus, and other infostructure issues are usually at a DevOps maturity level 7 out of 10 scenario, when most Ops orgs are permanently stuck at a 1 with infostructure today. By trying to raise their metastructure capabilities and maturity levels, they are adding severe risks — whether they be risks to availability metrics, application security, and/or just regular business decision-making.

Great post and I strongly agree with you since most of the IaaS/PaaS is all about reaching to infrastructure layer via web services and/or APIs. I think it's high time to get many of us schooled on web services