Monthly Archives: December 2009

Cloud Security Alliance Guidance v2 Released

Last week, the Cloud Security Alliance (CSA) released its Security Guidance for Critical Areas of Focus in Cloud Computing V2.1. This is a follow-on to first guidance document released only last April, which, gives you a sense of the speed at which cloud technology and techniques are moving. I was one of the contributors to this project.

The guidance explores the issues in cloud security from the perspective of 13 different domains:

Cloud Architecture

  • Domain 1: Cloud Computing Architectural Framework

Governing in the Cloud

  • Domain 2: Governance and Enterprise Risk Management
  • Domain 3: Legal and Electronic Discovery
  • Domain 4: Compliance and Audit
  • Domain 5: Information Lifecycle Management
  • Domain 6: Portability and Interoperability

Operating in the Cloud

  • Domain 7: Traditional Security, Business Continuity, and Disaster Recovery
  • Domain 8: Data Center Operations
  • Domain 9: Incident Response, Notification, and Remediation
  • Domain 10: Application Security
  • Domain 11: Encryption and Key Management
  • Domain 12: Identity and Access Management
  • Domain 13: Virtualization

I thought the domain classification was quite good because it serves to remind people that technology is only a small part of a cloud security strategy. I know that’s become a terrible security cliche, but there’s a difference between saying this and understanding what it really means. The CSA domain structure–even without the benefits of the guidance–at least serves as a concrete reminder of what’s behind the slogan.

Have a close look at the guidance.  Read it; think about it; disagree with it; change it–but in the end, make it your own. Then share your experiences with the community. The guidance is an evolving document that is a product of a collective, volunteer effort. It’s less political than a conventional standards effort (look though the contributors and you will find individuals, not companies). The group can move fast, and it doesn’t need to be proscriptive like a standard–it’s more a distillation of considerations and best practices. This one is worth tracking.

Advertisement

eBizQ: SOA in This Year and the Next

It’s that time when we look back on one year and forward to the next. Over at the eBizQ forum Peter Schooff asked about SOA’s past and future:

What Developments in SOA Are You Most Thankful For This Year?

What Do You Think Will be the Biggest Trend or Development for SOA in 2010?

Identity Buzz Podcast with Now Available: End-to-End Web Services Security

I recently had a great, freewheeling discussion with Daniel Raskin, Sun’s Chief Identity Strategist. Daniel runs the Identity Buzz podcasts. We talked about issues in identity and entitlement enforcement in SOA, compliance, and the problems you run into as you move into new environments like the cloud.

Daniel’s post about our podcast is on his blog.

You can download the podcast directly right here.

Upcoming Webinar: Controlling Your SOA Across The Global Enterprise and Cloud

I’ll be delivering a Webinar next week about Layer 7’s Enterprise Service Manager (ESM) product. ESM offers the global view of clusters of SecureSpan Gateways and the services under their management. It’s functions fall into three main areas:

Enterprise-scale Management

  • Centrally manage and monitor all Gateways and associated services across the extended enterprise and into the cloud

Automated Policy Migration

  • Centrally approve and then push policy to any Gateway across the enterprise, automatically resolving environmental discrepancies

Disaster Recovery

  • Remotely manage, troubleshoot, backup and restore all Gateways, supporting full disaster recovery

ESM is an important tool for managing SOA in the Enterprise, but it also plays a critical role when SOA moves to the cloud. In addition to extending an organization’s visibility and control, ESM provides critical tools for automating the migration of policy to new environments:

I’ll go into this process in detail in the webinar. Hope to see you there. Here is the official abstract:

Organizations have begun extending their SOA initiatives beyond traditional enterprise boundaries to encompass third-party, geographically remote, and even cloud-based resources. As a result, the complexity associated with migrating applications across these environments (for example, from development in India to test in the cloud to production in a hosted data center) has increased exponentially. In this webinar from Layer 7, you will learn how topology and identity issues between environments, geographies and settings (i.e., enterprise vs. cloud) can be easily resolved and even automated, dramatically reducing migration risk.

You can sign up for this webinar at http://www.layer7tech.com/main/media/webinars.html.

Using URI Templates on XML Security Gateways

Earlier this fall, Anil John put out the following Twitter challenge:

“@Vordel, @layer7, @IBM_DataPower If you support REST, implement support for URI templates in XML Security Gateways”

Somebody brought Anil’s tweet to our attention this week, and Jay Thorne, who leads our tactical group, put together a nice example of just how to do this using SecureSpan Gateways.

URI templates are a simple idea to formalize variable expansion inside URI prototypes. A receiving system can then trivially parse out substituted components of the URI and use these as input. There’s an IETF submission here that describes the approach. It turns out that it was co-authored by my old friend and ex-IBM colleague Dave Orchard. Another co-author is Mark Nottingham, who I worked with at the WS-I. I guess I should have looked into this earlier. Sorry guys.

Here’s a real example of how URI templates work. Let’s begin with the template:

http://somesite/Template/{Noun}/{Verb}/{Object}

The braces represent variables for run time substitution. Suppose these variables equaled:

Noun=Dog
Verb=bites
Object=man

The result of the substitution would then be:

http://somesite/Template/Dog/bites/man

Which is pretty easy to parse up and process by a web application residing at http://somesite/Template

URI templates are also very easy to process on a SecureSpan Gateway. Here’s a policy that demonstrates how to access the variables in the URI. Basically, all this policy does is parse up the URI, audit the results, and echo the content back to the sender:

I’ll bind this policy to a particular URI range on my SecureSpan gateway virtual instance. This happens to be running with an HTTP listener on port 8080 on my Macbook Pro:

Now let’s walk through the policy in detail. The first assertion uses a regular expression to parse the URI.:

It places the content of the expansion variables Noun, Verb, Object into Vars[1] , Vars[2] and Vars[3] respectively. The next two assertions in the policy simply audit the resulting variables into the SSG audit subsystem; this can sink to cluster storage, or go off box. Finally, the policy populates a template XML document with the contents of the variables and echos this back to the original sender:

When I fire up my browser and hit the REST service http://scottssg:8080/Template/Dog/bites/man I get:

Obviously in a real policy, you would do something more interesting than just echoing parameters, such as route the message to a particular internal host based on template content. And you can certainly compose outgoing URIs using existing variable substitution capability in SecureSpan. The take away is this is very simple to implement, and I think that it highlights that here at Layer 7, we think that supporting RESTful services is just as important as supporting SOAP.

Visualizing the Boundaries of Control in the Cloud

Two weeks ago, I delivered a webinar about new security models in the cloud with Anne Thomas Manes from Burton Group. Anne had one slide in particular, borrowed from her colleague Dan Blum, which I liked so much I actually re-structured my own material around it. Let me share it with you:

This graphic does the finest job I have seen of clearly articulating where the boundaries of control lie under the different models of cloud computing. Cloud, after all, is really about surrendering control: we delegate management of infrastructure, applications, and data to realize the benefits of commoditization. But successful transfer of control implies trust–and trust isn’t something we bestow easily onto external providers. We will only build this trust if we change our approach to managing cloud security.

Cloud’s biggest problem isn’t security; it’s the continuous noise around security that distracts us from the real issues and the possible solutions. It’s not hard to create a jumbled list of things to worry about in the cloud. It is considerably harder to come up with a cohesive model that highlights a fundamental truth and offers a new perspective from which to consider solutions. This is the value of Dan’s stack.

The issues in the cloud that scare us the most all fall predicatably out of the change in control this environment demands. Enterprise IT has carefully constructed an edifice of trust based on its existing on-premise security models. Cloud challenges these models. Cloud rips pieces from the foundation of this trust, leaving a structure that feels unstable and untrustworthy.

We cannot simply maintain existing security models in the cloud; instead, we need to embrace a new approach to security that understands the give-and-take of control that is inherent to the cloud. This demands we recognize where we are willing to surrender control, acknowledge that this conflicts with our traditional model, and change our approach to assert control elsewhere. Over time we will gain confidence in the new boundaries, in our new scope of control, and in our providers–and out of this will emerge a new formal model of trust.

Let’s consider Infrastructure-as-a-Service (IaaS) as a concrete example. Physical security is gone; low-level network control is gone; firewall control is highly abstracted. If your security model–and the trust that derives from this–is dependent on controlling these elements, then you had better stay home or build a private cloud. The public cloud providers recognize this and will attempt to overlay solutions that resemble traditional security infrastructure; however, it is important to recognize that behind this façade, the control boundaries remain and the same stack elements fall under their jurisdiction. Trust can’t be invested in ornament.

If you are open to building a new basis for trust, then the public cloud may be a real option. “Secure services, not networks” must become your guiding philosophy. Build your services with the resiliency you would normally reserve for a DMZ-resident application. Harden your OS images with a similar mindset. Secure all transmissions in or out of your services by re-asserting control at the application protocol level. This approach to secure loosely coupled services was proven in SOA, and it is feasible and pragmatic in an IaaS virtualized environment. It is, however, a model for trust that departs from traditional network-oriented security thinking, and this is where the real challenge resides.