I'm starting to feel like too much of the focus in Cloud Computing continues to be on the security of the infrastructure (the environment), rather than the security of the actual applications and workloads.
It's not that I'm saying we should be ignoring or not paying any attention to the security posture of the cloud itself but rather that we're still spending too much time on the topic and potentially missing a fantastic opportunity.
As we discussed here at OWASP AppSec APAC in Sydney recently, there is still too much focus being given to the security of infrastructure, and we're spending a disproportionate amount of time on the security of infrastructure (the networks, the servers, etc) rather than actually looking at applications.
I had the pleasure of catching up with Jacob West, who is the Fortify CTO and Director of Software Security Research (if that's not a mouthful!) here at HP Enterprise Security, since we were both in the same venue and in a video we'll be publishing shortly we talked about this.
Spending is still leaning heavily towards infrastructure, so that 75% of budgets still go to securing the wrong thing. While attackers continue to focus heavily on applications (about 3 of 4 attacks continue to be executed at the application rather than the infrastructure) we're still spending only 25% of our IT Security budgets on that piece of the pie. It's madness.
As you start to build out your clouds and think about what security will be appropriate, and where you're going to spend your limited capital resources, think about this obvious misplacement of spending out there.
In order to avoid over-spending on attempting to solve the wrong problem think about how you're going to protect your applications. More importantly, think about how you're going to protect your applications from a model approach.
The model-driven approach to securing cloud-based applications or workloads has a number of advantages over the traditional detail-driven approaches:
- Abstracting implementation from policy is crucial to applying security across diverse deployment environments, which in spite of best intentions aren't always conveniently carbon-copies of each other
- Separating the what from the how enables security teams to govern without having to do implementation - this is the only way to get scalability of limited security talent
- Models don't change as often as the technical implementation details, enabling a longer duty-cycle of the security approach
- Automation can take care of the implementation details as long as the model is consistent and sane
Think about it this way, what if you could simply set a policy that models how you want to protect your application and then let some piece of automation take care of the 'how'? You could simply model "allow only ports 80 and 443 on ingress or egress" of your application.
Your 'model' then gets packaged and becomes portable (a topic for further discussion) with the application whether you deploy to a production or dev-test environment or across public, private or hybrid clouds from vendor X to the HP Cloud.
The beauty here is that the automation components behind the cloud take that model you've abstracted and implement it using the available controls and technical components inherent to that cloud provider or implementation.
Separating technical detail from the model makes a lot of sense... and now that cloud computing is making its adoption felt across all types of companies it seems as though the only way we can scale security to any reasonable level and make it real in these compute environments is by separating the model from the technical implementation - while leaving the implementation to high-grade automation.
Cross-posted from Following the White Rabbit