Monthly Archives: January 2010

The Dust of Haiti

Yesterday I was asking Jim Brasset, our IT Manager, a few questions about monitors when I noticed the laptop open on his desk.

“What did you do to that laptop? It’s a mess.”

“It was in Haiti. I’m doing data recovery on it,” he replied.

The laptop belonged to his cousin, a nurse working in Port-au-Prince. She was evacuated on a C-130 to Montreal, and the laptop came with her as she found her way back to Vancouver. Now, only a week after the earthquake, it connects Jim to a terrible human drama.

I ran my finger across the keyboard, picking up the powdery residue of concrete smashed to ruin.

“The dust of Haiti.”

Despite all of the advances we have made in communication, there is a poignancy to physical objects that technology will never capture. Find a charity you respect, and give to help the people of Haiti.

Up is the New Up

As some of you may have already heard, 2009 was a spectacular year for Layer 7. Despite the economic downturn—leading to the “flat is the new up” quip around the Valley—we actually grew more than in any year previous. In fact, we’ve grown steadily year-over-year for the last four years. 2009, however, turned out to be special for a number of reasons.

First, Gartner placed us in the leader’s quadrant in the MQ for Integrated SOA Governance. This is important because it recognizes that SecureSpan Gateways offer a comprehensive solution for SOA governance in-a-box. Now, you will never catch me equating governance with technology; but technology is a critical component of governance, and if the technology is well-designed it will give you the tools you need to support your overall SOA governance initiative.

2009 also saw the formal launch of our cloud product line. With the Amazon AMI image of SecureSpan, we released the industry’s first—and only—SOA Governance Gateway for the cloud. We were active contributors to important efforts like the Cloud Security Alliance’s critical guidance for securing the cloud. And we successfully promoted mantra that “in the cloud, you must protect services, not networks,” at watershed industry events like GigaOm Structure and through ongoing presentations with leading thinkers like David Linthicum and Anne Thomas Manes. These days, everybody seems to be jumping onto the cloud bandwagon; what is much more rare is a company offering something besides talk and vapor. Well, talk is easy.  I’m very happy that we made real accomplishments in the cloud space in 2009.

But it’s not all about the cloud. With the release of the Oracle OSB Appliance, which came out last fall, we’re showing the continued value of high performance, secure appliances in the enterprise. Layer 7’s OSB gives you a real solution for putting important infrastructure like OSB into the DMZ. The DMZ is in our DNA, and you should expect further innovation in this area in the near future.

In the end, the measure of all of this is sales success, and we’re very happy with our results. Layer 7 recorded a 35% growth in customers over 2008 and a blow-out year for revenue. This success energizes the team and fosters a great determination to continue to win—it is tangible as you walk the floor. I couldn’t ask for anything better going into 2010, because the products and innovation that are underway will far exceed what came out in ’09. Watch this space.

How to Secure REST and JSON

Here at Layer 7 we get asked a lot about our support for REST. We actually have a lot to offer to secure, monitor and manage REST-style transactions. The truth is, although we really like SOAP and XML here at Layer 7, we also really like REST and alternative data encapsulations like JSON. We use both REST and JSON all the time in our own development.

Suppose you have a REST-based service that you would like to publish to the world, but you are concerned about access control, confidentiality, integrity, and the risk from incoming threats. We have an answer for this: SecureSpan Gateway clusters, deployed in the DMZ, give you the ability to implement run time governance across all of your services:

Pictures are nice, but this scenario is best understood using a concrete example. For the services, Yahoo’s REST-based search API offers us everything we need–it even returns results in JSON format, instead of XML. Yahoo has a great tutorial describing how to use this. The tutorial is a little dated, but it’s simple, to the point, and the REST service is still available. Let’s imagine that I’m deploying a SecureSpan Gateway in front of the servers hosting this API, as I’ve illustrated above. The first thing I will do is create a very simple policy that just implements a reverse proxy. No security yet–just a level of indirection (click on the picture for detail):

This is just about as simple as a policy can get. Notice that the policy validator is warning me about a few potential issues. It’s pointing out that the transaction will pass arbitrary content, not just XML. Because I’m expecting JSON formatted data in the response, this is the behavior I expect. The validation is also warning me that this policy has no authentication at all, leaving the service open to general, anonymous access. We’ll address this in the next step.

I’ve explicitly attached this policy to the gateway URL:


If need be, I could easily add wild card characters here to cover a range of incoming URLs. For this demonstration, I’m just running a virtual SecureSpan Gateway here on my Macbook; it’s not actually residing in the Yahoo DMZ, as would be the case in a real deployment. But from the perspective of an administrator building policy, the process is exactly the same regardless of where the gateway lives.

I’ve also placed a restriction on the listener to only accept HTTP GET verbs:

Now I can point my web browser to the gateway URL shown above, and get back a JSON formatted response proxied from Yahoo. I’ll use the same example in the Yahoo tutorial, which lists pictures of Madonna indexed by Yahoo:


This returns a list looking something like this:

{"ResultSet":{"totalResultsAvailable":"1630990", "totalResultsReturned":10, "firstResultPosition":1, "Result":[{"Title":"madonna jpg", ...

which I’ve truncated a lot because the actual list spans thousands of characters. The Yahoo tutorial must be fairly old; when it was written, there were only 631,000 pictures of the Material Girl. Clearly, her popularity continues unabated.

Now let’s add some security. I’d prefer that nobody on the Internet learns that I’m searching for pictures of Madge, so we need to implement some privacy across the transaction. I can drag-and-drop an SSL/TLS assertion into the top of my policy to ensure that the gateway will only accept SSL connections for this RESTful service. Next, I’ll put in an assertion that checks for credentials using HTTP basic authentication. I’ll use the internal identity provider to validate the username/password combination. The internal identity provider is basically a directory hosted on the SecureSpan Gateway. I could just as easily connect to an external LDAP, or just about any commercial or open source IAM system. As for authentication, I will restrict use of the yahooImageSearch REST service to members of the development group:

HTTP basic authentication isn’t very sophisticated, so we could easily swap this out and implement pretty much anything else, including certificate authentication, Kerberos, SAML, or whatever satisfies our security requirements. My colleague here at Layer 7, Francois Lascelles, recently wrote an excellent blog post exploring some of the issues associated with REST authentication schemes.

Let’s review what we this simple policy has given us:

  1. Confidentiality, integrity, and server (gateway) authentication
  2. Authentication
  3. Authorization
  4. Virtualization of the internal service, and publication to authorized users

This is good, but I’d like to add some more REST-specific constraints, and to filter out potential REST attacks that may be launched against my service. I can do this with two simple assertions: one that validates form field in HTML, and another that scans the content for various code injection signatures:

The form data assertion allows me to impose a series of tight constraints on the content of query parameters. In effect, it let’s me put a structural schema on an HTTP query string (or POST parameters). I’m going to be very strict here, and explicitly name every parameter I will accept, to the exclusion of all others. For the Yahoo search API, this includes:

  • appid
  • query
  • output
  • callback

The latter does some wrapping of the return request to facilitate processing in JavaScript within a browser:

Depending on my security requirements, I could also be rigorous with parameter values using regular expressions as a filter. I’ll leave that as an exercise for the reader.

Naturally, I’m concerned about REST-born threats, so I will configure the code injection assertion to scan for all the usual suspects. This can be tuned so that it’s not doing unnecessary work that might affect performance in a very high volume situation:

That’s it–we’re done. A simple 6 assertion policy that handles confidentiality, integrity, authentication, authorization, schema validation, threat detection, and visualization of RESTful JSON services. To call this, I’ll again borrow directly from the Yahoo tutorial, using their HTML file and simply change to URL to point to my gateway instead of directly to Yahoo:

<title>How Many Pictures Of Madonna Do We Have?</title>
<script type="text/javascript">
function ws_results(obj) {
<script type="text/javascript" src="https://scottssg:8443/yahooImageSearch?appid=YahooDemo&query=Madonna&output=json&callback=ws_results"></script>

Still can’t get over how many pictures of Madonna there are.

I ran it a few times and here’s what it looks like in the dashboard. I threw in some policy failures to liven up the display:

So where can we go from here? Well, I would think about optimization of the policy. Depending on predicted loads and available hardware, we might want to check for code injection and validate the schema before performing authentication, which in the real world would likely call out to an LDAP directory. After all, if we are being fed garbage, there’s no sense in propagating this load to the directory. We can add SLA constraints across the service to insulate back end hosts from traffic bursts. We could also provide basic load distribution across a farm of multiple service hosts. We might aggregate data from several back-end services using lightweight orchestration, effectively creating new meta-services from existing components. SecureSpan Gateways provide over 100 assertions that can do just about anything want to an HTTP transaction, regardless of whether it contains XML or JSON data. You can also develop custom assertions which plug into the system and implement new functionality that might be unique to your situation. Remember: when you are an intermediate, standing in the middle between a client and a service–as is the case with any SecureSpan Gateway–you have complete control over the transaction, and ultimately the use of the service itself. This has implications that go far beyond simple security, access control, and monitoring.

On the Death of Design-Time Service Governance

Practically on the anniversary of Anne Thomas Manes now-famous SOA-is-Dead pronouncement, David Linthicum suggests we convene the vigil for design-time service governance. Dave maintains that cloud technology is going to kill this canonical aspect of governance because runtime service governance simply provides much more immediate value. Needless to say, rather than a somber occasion, Dave’s started more of a donnybrook. I guess it’s about time to get off of the bench and join in the fun.

The incendiary nature of is-dead statements often conceal  the subtle but important ideas behind them. Dave’s declaration is no different. What he’s really suggesting is that cloud will rapidly shift the traditional priorities with respect to services governance. In the big SOA era (before Jan 1, 2009), design-time governance was king. It fit nicely into the plan-manage-control discipline underpinning a large enterprise-scale SOA effort. And to support this, tool vendors rushed in and offered up applications to facilitate the process. Run time services governance, in contrast, was often perceived as something you could ignore until later–after all, on-premise IT has reasonably good security and monitoring in place. The technology might be old and the process a little byzantine, but it could tide you over. And if any internal staff were caught accessing services they shouldn’t be you could just fire them.

The cloud inverts this priority. If you deploy even one service into the public cloud, you must have runtime service governance in place. That one service needs to be hardened and protected as you would a DMZ-based application. You must have continuous visibility into its operation from the moment you turn it on. Run time governance simply cannot be put off.

The cloud is also about agility. We are attracted to the cloud because it offers rapid deployment, elastic computing, and that hard to refuse pay-for-what-you-need model. This same sense of agility is a leitmotiv throughout the entire development process. When you talk to teams that have been successful with the cloud, they are usually small, they rail against enterprise bureaucracy, and agile development process is in their DNA. They are comfortable and extremely efficient with the tools and process they have, and they don’t see a lot of reason to change this. Do they still need discipline, organization, process, communication, sharing? Absolutely–but they have this; it’s ingrained into their existing process. I see this in my teams developing products every day. It’s the mix of great management, excellent people, process where it’s been shown to be needed, and a basic set of tools we all rely on every day.

Will design-time services governance tools disappear completely? Of course not. But their value becomes apparent with scale, when you begin to approach “a lot of services” (and no,  nobody really knows what this means–probably more than a scoville, less than a parsec). The point is, in the cloud nobody starts there, but they do need to focus immediately on the threats.

In the end, governance priorities in the cloud come down to a pretty simple precept: Duplicating a piece of functionality probably won’t get you fired; leaving an open door that was used to compromise corporate data probably will.