Are you considering cloud security in the abstract or cloud security in your software?

Looking at cloud security issues in the abstract, we see 4 areas of concern:

1. Mobility of Resources and multi-tenancy
2. Identity and access management
3. Data protection
4. Incident response and assessment

When choosing a cloud solution for your business application, it is easy to get dragged into a low level engineering discussion of these issues.

However, we don’t implement things in the abstract; we implement real-life applications in the cloud.

Our decisions on implementing security countermeasures in the cloud should actually not be a function of  4 abstract security concerns but of  business and security management decisions:

1. The cloud service model you choose. This is a business decision constrained by software engineering factors.
2. How you detect and mitigate your application vulnerabilities. This is a security management decision.

The cloud service model is supremely important and is closely tied to your business requirements.  If you are a business unit manager at healthcare provider looking to implement a private social network for healthcare, you will be looking at SaaS alternatives.  If you are a VP engineering at a company developing business analytics, you will be considering PaaS or IaaS service models where the language support is one of your key drivers. If you are a Java shop and the BigTable key-value data model used by Google App Engine appeals to you, then Google App Engine may be your best fit.  On the other hand, if you are a Ruby shop, you may want to consider Heroku.
Once you choose a cloud service model, you should spend as much time as possible doing threat modeling of your software and estimating your value at risk.
Since buggy software is insecure software, and since most bugs are baked into the design, and since it’s cheaper to fix bugs in software at the beginning of the software life cycle – it’s about getting the software architecture right and then doing the implementation well and not about bolting on some third-party application security firewall rented out to you by your cloud service provider.

Service models

Mobility of Resources and multi-tenancy is are a core requirement for a cloud service provider. If he’s doing a good job, it’s his first order of business,  not your first order of concern.
Regarding  Incident response and assessment, if your cloud provider is proactive, that is a very good sign that Incident response and assessment will be handled properly.  If he waits for you to tell him that there is a hacking issue on your server, then it’s time to start looking for a different cloud service provider.
Identity and access management are part of your application. The architecture and deployment of your application is influenced by your choice of service model but it’s still your code running in the cloud.
Data protection is either some, not or all your responsibility depending on the service model and your software applications. This is why we need to do threat analysis on the software and consider data protection as one of the areas of concern.

Choosing the right cloud service model

The market is shaking out right now and in any given segment there are only 2 or 3 players you should be considering.

SaaS

High integration, low flexibility, high vendor lock-in Meant for end-users. Think SF.com

PaaS

Less integration, mid flexibility, medium vendor lock-in Meant for application developers. Think Google App Engine, Appforce.com, heroku, Azure

IaaS

No integration, total flexibility, low vendor lock-in. Good for engineers. Think Amazon WS, Rackspace Cloud

2 management mistakes you will probably make on your next cloud project

1. Overengineering defense in depth and
2. Ignoring or mis-estimating your application software threat surface

This is a situation we often see with product development companies that develop a cloud service using IaaS (infrastructure as a Service) where they  implement too many controls in too many layers and ignore or minimize  the threat surface of the application software for security and compliance breaches.

Overengineering defense in depth

You can over-engineer your  defense in depth strategy and implement Firewall, load balancers, IPS in multiple layers in the cloud: in the WAN, on the LAN, in the virtual machines  and in hardware appliances.  The more layers you have, the more things that can go wrong. You will be more vulnerable instead  of being more secure and you will have to deal with half a dozen new issues that you created your self:

1. Patch management is hard
2. Different management systems, since each layer has it’s own management
3. Different administrators, since each management system has it’s own admin
4. Visibility for the end user customer is impossible
5. Almost impossible to audit

What things can go wrong when you ignore application threat surfaces?

Lots. DB exploits Connector vulnerabilities Shell script vulnerabilities SQL injection DDOS, information disclosure by malicious insiders.

Typical Web 2.0 attack scenarios

Here are a few you should be thinking about:

1. Any kind of code injection
2. Server or client returns invalid HTML
3. Pages that contain dead links
4. HTML forms that don’t match field types expected by controllers
5. Client side code that makes bad assumptions about AJAX services
6. Servers  that may attempt to execute invalid SQL queries
7. Improper marshaling/un-marshaling between DB server to Web server DB server to application tier Web server to browser

Typical Web 2.0 vulnerabilities

Here are a few you should be thinking about:

• Running a number of heterogeneous stacks guarantees too much chewing gum
• Mixing  languages and frameworks may be problematic causing typing and interface issues.
• PHP, Ruby, Python Flexibility, no static type guarantees
• C#, Java Static typed, but only at Web server
• Code complexity that increases application threat surfaces.
• Redundant code on servers and clients
• Redundant data on servers and clients

Summary

At the end of the day, the Cloud Security Control model looks great, but it doesn’t mitigate core vulnerabilities in your software or tendencies by system architects to over engineer. Once you choose the right service model and vendor, you should put aside the cloud security reference models and focus on hardening your own application software –

Remember – it’s your code that will be running in someone elses cloud.