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

The Thinking Person's Guide to the Cloud

HOWTO: Keep your head in the clouds and your feet on the ground

By Gunnar Peterson

October 27, 2009

mnemonic RISK Conference, Oslo, Norway

“Everything we think of as a computer today is really just a device that connects to the big computer that we are all collectively building"-Tim O'Reilly

My friend Chris Hoff asked this question in a recent podcast - "why is the OWASP Top Ten the same year after year? why don't these things gets fixed?"[1]. The reason is that software security and security architecture and design is nowhere near as a high priority as it needs to be.

If you look at the evolution of software over the years, you will see a history of more and more systems and data being connected together. Beginning with the Web through to component based application and then to Web services, at each step the common theme is more connectivity, more integration. Software is a rapidly changing universe.

Unfortunately, Information Security has not kept up. Our field started out promisingly in the mid-90s with network firewalls and SSL for security mechanisms to defend websites, but that is about as far it got. In 1999 when SOAP emerged as a firewall-friendly protocol designed for the explicit reason to go through the firewall, that should have been a wake up call to Information Security that the "firewall + SSL" security architecture was past its prime, but here 10 years later we are still hitting the snooze button.

My view is that as technology is deployed we need security mechanisms that form fit to those new technologies, instead what we have is security technologies that form fit to auditor's excel spreadsheets.

One of the things that's most promising about the Cloud is that it forces the security design questions to the forefront that have been swept under the rug for the past decade. In other words how do you primarily rely on network security as we have done for the Web's life, when the Cloud abstracts the network away?

That is what each one of these technologies does

Are we really going to try this same security architecture again?

This talk has three parts, in the first part we'll explore a working definition of the Cloud. In part two, we'll look at some examples of threats. Lastly, we'll examine some security patterns for the Cloud and what it means to design, deploy and operate these new Countermeasures.

NIST's work on Cloud Computing[2] describes Clouds as being Private, Community-based, and Public. There are hybrids of all of these as well. These in turn are delivered as SaaS, PaaS or IaaS.

Some of the key characteristics show the limitations of the Web security model of network firewall + SSL.

Broad Network Access means the old security based on network firewall predicated on isolating our "good stuff" from the Web's "bad stuff" is irrelevant. Like a horse and buggy on a 8 lane freeway, hazardous at any speed.

Virtualization means that we'll need to authenticate users in one place and authorize them in another. Given that SSL is a point to point connection oriented security protocol it will not help us much in this endeavor.

Over at the Open Group, the Jericho Forum sums up the Cloud patterns[3] based on a permutations of Proprietary vs Open (using standards or not), Perimeterised or Deperimeterised, Outsourced or Insourced, and External or Internal. Of course, there are many variations of all of these, how you decide on each of these will have an impact on your end design. And the way that you choose to deliver security will vary depending on the model. In the Proprietary model you'll likely determine for example security policy and identity based on the Cloud vendors' representation, in an Open approach, it will be predicated on open standards for security policy and identity.

Giving the Cloud Rubik's Cube one more turn, the Burton Group [4] summarizes that depending on which model you choose IaaS, PaaS, Saas, you level of control decreases. This is not necessarily a problem in and of itself, but its a very important factor in security architecture and design.

So what do business get out of the Cloud? They get to leverage the massive scale of the Web, its extensive distribution, cost advantages, and to a degree some increased agility, but mostly what they get is new ways to interact with their customers. Businesses are becoming platforms that pulled by their customers, rather than programs where business push resources to their customers.

The evolution that the Cloud is driving began as a technical evolution because of distribution, virtualization technologies is now causing evolution in the business side, which is causing new technical imperatives, meaning technology will evolve (because this business needs it to) and security hopefully will evolve (because its time).

The main thing that got me interested web programming in the early 90s was a paper by John Perry Barlow called "The Economy of Ideas: Selling Wine without Bottles"[5] and the basic idea is that if you looked around at industry, there is a tremendous amount of cruft to manufacture wine bottles, put wine in bottles, store wine bottles in warehouses, and so on. The logistics of wine bottling and distribution are immense. The reason you and I can't make a great beer and sell it to every body and become a global beer barons is not because we can't make better beer than Budweiser, its because we can't replicate their distribution systems.

But here's the thing, the consumer never really cared about the logistics of distribution, they care about the wine.

Fast forward from Wine without bottles essays in the early 90s and you can find the logical result of all this technological ferment everywhere there are clueful people, you can go to a place like McKinsey and find an interesting paper that connects many of the dots that Barlow discussed and they are happening right now.

The paper "From Push to Pull-Emerging Models for Mobilizing Resources"[6] by John Hagel and John Seely Brown extends their idea that what formerly thought of the edge of the enterprise is in fact forming a core. Their paper contrasts the historical Push Programs with current Pull Platforms

"Push programs represent a top down approach to dictating activities. These programs tend to specify activities or procedures in detail. The core assumption of push programs is that demand can be anticipated and that it is more efficient and reliable to mobilize resources in pre-specified ways to serve this demand. These activities or procedures may be organized into modules (for example, semesters in a curriculum), but that is only for the convenience of the provider. The modules are usually tightly coupled – deployed in a pre-specified sequence."

Now let's contrast that with the Pull Platforms

"Pull platforms tend to be much more modular in design but now the modules are for the convenience of the participants of the platform. Modules are created to help to make resources and activities more accessible in flexible ways since the core assumption of pull platforms is that the needs of participants cannot be well anticipated in advance. Pull platforms are designed from the outset to handle exceptions, while push programs treat exceptions as indications of failure."

Technology is what is driving these changes, its giving companies ways to find and connect with the best skills and cost mix they need to deliver value to their customers. But here is the challenge to Information Security - delivering security services to our customers in a Top Down Push Program world could not be more different than delivering security to a Pull Platform. Just think of the difference between treating an exception as a failure (optimized push), versus expecting exceptions (decentralized pull)

Think about the Mainframe as the quintessential Push Program: top down design, centralized control, procedural programming, and resource centric. Delivering security services to a Mainframe is fairly straightforward, the terminals are dumb, the communication links are "internal", and then its a matter of loading users into RACF and assigning privileges.

The first difference here is the amount of a priori knowledge required to pull this off

Then there is the resource-centricity- RACF is RESOURCE Access Control Facility, but what about the user? What if there are multiple namespaces for resources? Where does the Resource domain begin and end in a Cloud, a Pull Platform which is demand driven not provider-driven?

Now, lets look at the constituents of the Pull platform, its dominated by uncertainty. Demand is uncertain, its people centric, there is constant innovation, new code rolling out all the time. There is no "design" there is emergent set of behaviors and structures.

We hear a lot about Role based Access Control as a model to deliver security in companies, but the problem with RBAC in distributed systems like Access Control Lists before it, is that its practically impossible to know at design time what all the subjects, all the objects, all the roles and all the sessions need to be and how they should be mapped together. RBAC can play an important role as a local authorization policy enforcement tool, but its very limited as a platform security construct, because we are building the platform at the same time we are using it.

And this is the way things are going, now that technology has enabled it - do you expect your business to be more customer centric or less? Do you expect it to be more distributed or less? These changes will ripple out and I would say that our security models are ill prepared, because they are resource centric. Put a firewall on the network, use SSL on the perimeter,a dn assign access privileges to the resources. But what happens to this model when resources ae dynamic and sourced from a variety of players and networks? What happens when the access decisions relies on the user privileges and preferences not just the resource and service provider?

What happens to the SSL protection on the edge when the edge is the core? what happens to network firewall security when the network is abstracted away.

All of these historical facades that security has hidden behind for web security are long past their sell by date. we simply cannot afford a status quo mindset where the Cloud is a big mainframe and we just need to apply RACF for the Cloud.

The generic access control model is comprised of Subjects like user accounts, Objects like web URIs, and Web services that are mediated by Security Services.

The objects are no longer far on the back end, they are accessible directly or indirectly by the users, from anywhere.

There are two more drivers to discuss the first is mobility and the second is networked participants.

The first thing to know about Mobility is that these devices are becoming Platforms in and of themselves. If you add up all the "there's an app for that" you'll quickly realize that the mobile device run more applications than that Unix server you used to administer. They are platforms just as much as the big service providers are. They are more dynamic and they are pulled from many sources. They have the one thing that the Service providers lack - local, user context. This is changing on a daily basis through a variety location and user context aware applications, summed up beautifully by Timo Arnall's work on "Web in the World" [7]

The second thing is networked participants - the subjects and objects are likely to exist in multiple disparate namespaces. Meaning point to point protocols will not be able to help make the kinds of access decisions required in a Cloud of multiple parties, authorities and realms.

The security services can make decisions like authentication decisions, this requires them to know a lot about users, directories, how the user was authenticated and so on.

Security services can make authorization decisions, this requires some mapping to the that which is being authorized such as the application methods to make local authorization decisions.

Security services can actively or passively write to an audit log, and this requires them to be in line in the application and know something about the events they are reporting on.

Here we look network firewall based security. Ask yourself for the Subject's Data, App, Services, VM, Server, Storage, Network, and Organization - what visibility does the network firewall have to make an authentication or authorization decision? What kind of information would it even begin to make such a decision?

I am not saying anything bad about network firewalls and SSL, they are necessary conditions, just not remotely sufficient.

Now the entry point to most Cloud services is not surprisingly Web services. Web services separate into Service requesters and Service Providers. They exchange messages through service interfaces that are then mapped into the service's application implementation.

One of their main design goals was back in 1999 to go through the firewall

So far, we've seen two main camps in Web services: Service Oriented Architecture (SOA) and REST. These two approaches are both focused on loosely coupled integration, they have some subtle differences, where SOA separates the Service from the entity (e.g. data), the address in REST is in fact the reference to the data and in REST that's accessible via standard HTTP Get style methods.

Technical Debt occurs when "During the planning or execution of a software project, decisions are made to defer necessary work...The list can grow quite long, with some items surviving across multiple development cycles."

Martin Fowler on making technical debt actionable:

"To my mind, the question of whether a design flaw is or isn't debt is the wrong question. Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking. A particular benefit of the debt metaphor is that it's very handy for communicating to non-technical people.

I think that the debt metaphor works well in both cases - the difference is in nature of the debt. A mess is a reckless debt which results in crippling interest payments or a long period of paying down the principal. We have a few projects where we've taken over a code base with a high debt and found the metaphor very useful in discussing with client management how to deal with it.

The debt metaphor reminds us about the choices we can make with design flaws. The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small - such as if it were in a rarely touched part of the code-base.

So the useful distinction isn't between debt or non-debt, but between prudent and reckless debt."

I put together a simple Technical Debt Clock for Information Security to track how long we have been running the same basic Network firewall + SSL security architecture, its been 14 years or 5078 days. How much technical debt have incurred since then? You can write a lot of code in 5078 days!

If we look at an Information Security version of this we see in InfoSec we're used to not winning all the battles, but its very useful to understand what decisions are being made for time to market expediency and if in the design its at all feasible to revisit them. A PEP is a good concrete example here, building an interceptor pattern in front of your web service a la Axis2/Rampart could allow you to get to market with say Basic Username/Password token and later on change to a SAML token. If the interceptor was there your revision is causing not only behavioral changes but also structural changes and will likely be much more difficult to get through dev/QA later on. Sometimes the most important thing is getting the boundary right on release 1 even if that means the boundary is not optimally protected til later.