1 Raindrop: The Thinking Person's Guide to the Cloud, Part 2

The Thinking Person's Guide to the Cloud, Part 2 (Part 1)

Remember my friend Hoff's question - why doesn't the OWASP Top Ten change? Why don't these problems get fixed? Let's look at some of the OWASP Top Ten [8] issues, an overview of some of the fixes, and see if the Cloud is likely to remedy any of them.

The first because its the most prevalent is Cross Site Scripting, which comes in several different flavors. The issue is that the XSS attacks are predicated precisely on the fact that the client is not aware of where its being directed to, the XSS payload hides itself in that expression of the virtualized endpoint whether through a malicious link, email or script. There are two problems here for Cloud - one is that this location transparency is a hallmark of the Cloud and the second is that the fixes we know about are not very good on the Service Requester, client side.

To effectively deal with XSS, we want Input Validation to root out malicious scripts and output encoding to neuter actively malicious content.

The second entry in the OWASP Top ten is Injection Flaws, the most famous being SQL Injection, but of course any resource is vulnerable to Injection such as the Injecting commands to LDAP.

The main protections against Injection Flaws is Input Validation and Safe Query Interfaces. Input Validation which requires either or both extensive knowledge of the known good commands and data the service supports, and/or extensive list of attacks and attack patterns.

Safe Query Interfaces requires control over say the database programming connectivity so that Parameterized Queries and Prepared Statement are used instead of raw SQL. But this requires some level of control on the resource access side.
OWASP issue number 4 is Insecure Direct Object Reference, where backend resources are ably to be directly called and in worst case manipulated to execute functions. It effectively an authorization failure, and it can manifest itself in a number of ways from components to directories to message queues to files that can be directly called.

There are three main fixes to Insecure Object reference - authorization, authorization and authorization. There is actually another one - assurance, because application's attack surface are so large and the ways objects are combined so unpredictable things like fuzzing are required to remediate this issue, but as we will see later conducting vulnerability assessment to find flaws such as Insecure Direct Object Reference in the Cloud are quite problematic.
OWASP issue number 5 Cross Site Request Forgery is a special type of authorization and session management flaw. Credentials are reused by the attacker to impersonate a legitimate logged on user and take actions using their credentials. Fixes for CSRF include using POST instead of GET methods, reauthentication, and applying state to the request through a random nonce token. And again we see that the fixes are required on the service provider side.
OWASP issue number 7 is Broken Authentication and Session Management, these involve authentication and sessions being poorly protected, such as sending tokens over unencrypted channels or poorly implemented, such as session fixation of replay. While there is some hope to partially mitigate some of these issues through federated identity and protocols like SAML, there is still in all cases a server side issue.
So if we take these five security issues - Cross Site Scripting, Injection Flaws, Insecure Direct Object Reference, Cross Site Request Forgery, and Broken Authentication and Session Management, we see that at any level above IaaS, the concerns of mitigating those vulnerabilities are outsourced to your Cloud provider(s), and the question to ask then is - are you outsourcing this deliberately or inadvertently?

Specifically, on a first pass, high level review our checklist now contains

* Input validation

* Output Encoding

* Safe Query Interfaces

* Authorization

* Nonce

* Authentication & session management

This is a summary of five items from one checklist.

Is your Cloud providers' security solution to these Reckless or Prudent? How would you verify if so?

So to complete our movement, we want to deliberately and prudently make a checklist of security architecture and design items and locate them in the Cloud. This is the first step, then next step will be governance: assigning roles and responsibilities.

Threat Modeling [9] takes the data flows, entry points, message exchanges, and other areas of interest to security; and gives us a way to find identify and categorize threats by type. Here is a secret though - Threat Modeling is not about Threats. Vulnerabilities are passive. Threats give security architects what they need - an active ingredient - a catalyst that exercises the vulnerabilities. Threat models are not about threats, they are ultimately about identifying and locating countermeasures. What countermeasures are required, where are they required, and what behaviors must they accomplish. The threats provide the context in which to do this.

This seemingly simple task has proven quite difficult in software and system development, and this makes Threat Modeling a very important discipline.
Each high level threat category maps to one or more Security services that act as countermeasures. So if you are concerned with Spoofing, then Authentication is a Countermeasure, if you are concerned with Dispute, then its Audit logging and so on.

Since, Threat Models are mainly about identifying and locating Countermeasures, the addition of the Attack Surface[10] construct has proven quite useful. This enables each Threat and each Countermeasure to be analyzed across combinations of Threat {Spoofing, Tampering, Dispute, Information Disclosure, Denial of Service, Elevation of Privilege} and Attack Surface {Data, Method, Channel}
This in turn gives you a way to baseline controls, so if you are planning on using SSL as a countermeasure, you can have a reasonably good chance at delivering an Encryption Countermeasure to deal with the Information Disclosure Threat at the Channel level.
The enemy of security architects is binary "we're secure or we're insecure" thinking. The beauty with the Threat Model + Attack Surface is to see what controls can work and where, and to use the framework to make security design tradeoffs.

How many times have we heard "we're using SSL, we're secure", using this matrix you can communicate clearly what's being delivered.

Now taking the output of the controls that we defined in analyzing some of the constituents of the OWASP Top Ten, we get a matrix that looks like this.
This process gives a rational way to make concrete progress on security requirements even when we're in early days of developing systems like the Cloud, we can use this approach to identify security requirements and put them in context.
So the overall security architecture process needs to start early. You cannot go and build Input validation, Output Encoding, Safe Query Interfaces, Authorization, Nonce, and Authentication & session management into you application 2 weeks before go live. You need those requirements early, and you need them to be in context. The Threat Model is a way to get them so you have time define detailed requirements, build them into the system, and verify that they work as expected.