This week I gave a talk at ITP’s SOA, BPM & Integration Forum in Zurich, a one-day conference with analyst presentations, customer case studies and one-to-one sessions.My talk, called “Accelerating Security & Governance with SOA”, had two main aims:

• To provide an overview of how and why many organizations are accelerating the design and deployment of SOA security and governance environments
• To discuss (and hopefully provide answers to) questions arising from this acceleration

To give you an idea of the ground I covered in my presentation, here’s a link to the slide deck I used. I’d also like to take a moment here to explain why I believe the acceleration of SOA security and governance programs is an important issue that demands our attention at this time.

First of all, SOA is continuing to expand throughout organizations, across organizational boundaries and into the Cloud. Organisations are reacting as dynamically as they can to the integration challenges this creates. At the same time, security and governance need to keep up, so the smart players are also accelerating these aspects of their SOA environments.

Second, the acceleration of SOA security and governance programs creates issues of its own. While, the rapid infrastructural changes created by growth in SOA and Cloud adoption certainly need to be managed and security must be enforced consistently, acceleration of security and governance raises a number of tricky questions, which I endeavoured to tackle in my talk:

• How do you manage the implementation of SOA security and governance without slowing down your organisation?
• How will your SOA remain operational as it evolves?
• How can you deliver APIs quickly while enforcing perimeter security and integration?

I got some very interesting feedback on my answers at the forum and I’m certainly looking forward to hearing more from the online community!

As a vendor of security products, I see a lot of Requests for Proposal (RFPs). More often than not these consist of an Excel spreadsheet with dozens—sometimes even hundreds—of questions ranging from how our products address business concerns to security minutia that only a high-geek can understand. RFPs are a lot of work for any vendor to respond to, but they are an important part of the selling process and we always take them seriously. RFPs are also a tremendous amount of work for the customer to prepare, so it’s not surprising that they vary greatly in sophistication. I’ve always thought it would be nice if the SOA gateway space had a standardized set of basic questions that focused vendors and customers on the things that matter most in Governance, Risk and Compliance (GRC). In the cloud space, such a framework now exists. The Cloud Security Alliance (CSA) has introduced the Security, Trust and Assurance Registry (STAR), which is a series of questions designed to document the security controls a cloud provider has in place. IaaS, PaaS and SaaS cloud providers will self-assess their status and publish the results in the CSA’s centralized registry. Providers report on their compliance with CSA best practices in two different ways. From the CSA STAR announcement:

1. The Consensus Assessments Initiative Questionnaire (CAIQ), which provides industry-accepted ways to document what security controls exist in IaaS, PaaS, and SaaS offerings. The questionnaire (CAIQ) provides a set of over 140 questions a cloud consumer and cloud auditor may wish to ask of a cloud provider. Providers may opt to submit a completed Consensus Assessments Initiative Questionnaire. 2. The Cloud Controls Matrix (CCM), which provides a controls framework that gives detailed understanding of security concepts and principles that are aligned to the Cloud Security Alliance guidance in 13 domains. As a framework, the CSA CCM provides organizations with the needed structure, detail and clarity relating to information security tailored to the cloud industry. Providers may choose to submit a report documenting compliance with Cloud Controls Matrix.

The spreadsheets cover eleven control areas, each subdivided into a number of distinct control specifications. The control areas are:

1. Compliance
2. Data Governance
3. Facility Security
4. Human Resources
5. Information Security
6. Legal
7. Operations Management
8. Risk Management
9. Release Management
10. Resiliency
11. Security Architecture

The CSA hopes that STAR will help to shorten purchasing cycles for cloud services because the assessment addresses many of the security concerns that users have today with the cloud. As with any benchmark, over time vendors will refine their product to do well against the test—and as with many benchmarks, this may be to the detriment of other important indicators. But this set of controls has been well thought through by the security professionals in the CSA community, so cramming for this test will be a positive step for security in the cloud.

“If your tools don’t work for you, get rid of them,” is a simple creed I learned from my father in the workshop. Over the years, I have found it is just as relevant when applied to software, where virtual tools abound, but with often-dubious value.

OAuth is an emerging technology that has lately been in need of useful tools, and to fill this gap we are introducing an OAuth toolkit into Layer 7’s SecureSpan and CloudSpan Gateways.  OAuth isn’t exactly new to Layer 7; we have actually done a number of OAuth implementations with our customers over the last two years. But what we’ve discovered is that there is a lot of incompatibility between different OAuth implementations, and this is discouraging many organizations from making better use of this technology. Our goal with the toolkit was to provide a collection of intelligently parameterized components that developers can mix-and-match to reduce the friction between different implementations. And thanks to the generalization that characterize the emerging OAuth 2.0 specification, this toolkit helps to extend OAuth into interesting new use cases beyond the basic three-legged scenario of version one.

I have to admit that I was suspicious of OAuth when it first appeared a few years ago. So much effort had gone into the formal specification of SAML, from core definition to interop profiles, that I didn’t see the need for OAuth’s one use case solution and had little faith in the rigor of such a grass roots approach. But in time, OAuth won me over; it fits well with the browser-centric, simple-is-better approach of the modern Internet. The mapping to more generalized, token server-style interactions in the new version of the spec appeals to the architect in me, and the opening up of the security token payload indicates a desire to play well with existing infrastructure, which is a basic enterprise requirement.

However, adding extensibility to OAuth will also bring about this technology’s greatest challenge. The 1.0a specification benefitted enormously from laser focus on a use case so narrow that it was a wonder it gained the mindshare that it did. OAuth in 2011 has no such advantage—generalization being great for architects but hell for standards committees and vendors. It will be interesting to see how well the OAuth community satisfies the oftentimes-conflicting agendas of simple, standard, and interoperable.

Here at Layer 7 we predict a bright future for OAuth. We also think it’s very useful today, which is why we introduced a toolkit instead of a one-size-fits-one approach. We see our customers using OAuth in concert with their existing investments in Identity and Access Management (IAM) products, such as IBM’s Tivoli Access Manager  (TAM) or Microsoft’s Active Directory (AD). We see it being used to transport SAML tokens that require sophisticated interpretation to render entitlement decisions. Taking a cue from OAuth itself, the point of our toolkit is to simplify both implementation and integration. And the toolkit’s parameterization helps to insulate the application from specification change.

I’ll be at the Gartner/Burton Catalyst show this week in San Diego where we’ll be demonstrating the toolkit. I hope you can drop by and talk about how it might help you.

“Live Fast, die young, and leave a good-looking corpse” was first uttered by actor John Derek in Knock on any Door,a 1949 film also staring Humphrey Bogart. This irresistible catchphrase has inspired generations of rebels from film to music to out-of-control teenagers. It also seems to have been taken to heart by the hacker collective LulzSec, which after a spectacular 50-day blitz across the Internet, is dissolving back into the shadowy back alleys from which it appeared. And just as James Dean—another famous adherent to the formula—did for film, so too have LulzSec changed the face of IT security and left an inspirational challenge for hacking’s next generation.

What is interesting about LulzSec isn’t necessarily their technique but their PR. The group appeared on the heels of high profile hacks by Anonymous and fed masterfully into a media-fueled hack-steria, feeding a public imagination over-stimulated with big audacious exploits that make great copy. LulzSec was the perfectly-timed counterpoint to Anonymous—gang fights equaling news that writes itself, whether the conflict is between thugs, dancers, graffiti writers, or hackers. And slipping away before being caught (sans one alleged member) ties this story up neatly into a narrative made to entertain. I’ve no doubt the movie rights will be bid sky-high.

If LulzSec can make claim to a legacy, then surely it is that effective marketing is just as important as the hack itself. LulzSec went from zero to global brand in a scant 50 days—a success that most marketing gurus can only dream of. In its wake, the collective leaves a somewhat heightened awareness of the terrible cost of security breaches among the general public. Their means to this end, of course, remain dubious; most hackers claim the same as a knee-jerk justification of their actions, though few are as wildly successful as LulzSec has been.

Nevertheless, no CEO wants to be subject to the negative publicity endured by Sony, which has suffered wave-after-wave of successful cyber attack. It is safe to say that LulzSec has dragged Internet security back into the executive suite, something which seemed almost unthinkable only a few months ago. The intelligent response to this new attention should be an increased emphasis on basic IT security foundations.

The Register today published an excellent summary of the latest issues with SSL. In the typically blunt and mordant style for which the publication is so famous, Dan Goodin illustrates how the gossamer-thin SSL web of trust is built on a superstructure of astonishingly dubious merit. It’s a wonder the whole thing works at all. Have a careful read of How is SSL hopelessly broken? Let us count the ways and then re-examine the cartel certs that anchor your own web browsing experience. As you roll out your API strategy, make sure you deploy your SSL endpoints with certificates that were subject to organizational or (much better) extended validation. Encourage—or if you can, demand—that your API clients limit their trust stores to a small subset containing only the most legitimate CAs. The opportunity is largely over in the browser world; affecting massive change there will only happen when individuals personally lose money on a grand scale. But APIs still have a chance to regain some level of trust through rigorous application of SSL best practices, and API providers and developers can take the initiative here.