Tag Archives: security

Security in the Clouds: The IPT Swiss IT Challenge

Probably the best part of my job as CTO of Layer 7 Technologies is having the opportunity to spend time with our customers. They challenge my assumptions, push me for commitments, and take me to task for any issues; but they also flatter the whole Layer 7 team for the many things we do right as a company. And for every good idea I think I have, I probably get two or three great ones out of each and every meeting with the people who use SecureSpan to solve real problems on a daily basis.

All of that is good, but I’ve learned that if you add skiing into the mix, it becomes even better. Layer 7 is fortunate to have an excellent partnership with IPT, a very successful IT services company out of Zug, Switzerland. Each year they hold a customer meeting up in Gstaad, which I think surely gives them an unfair advantage over their competitors in countries less naturally blessed. I finally managed to draw the long straw in our company, was able to join my colleagues from IPT at their annual event earlier this January.

Growing up in Vancouver, with Whistler practically looming in my backyard, I learned to ski early and ski well. Or so I thought, until I had to try and keep up to a crew of Swiss who surely were born with skis on their feet. But being challenged is always good, and I can say the same for what I learned from my Swiss friends about technology and its impact on the local market.

The Swiss IT market is much more diverse than people from outside of it may think. Yes, there are the famous banks; but it is also an interesting microcosm of the greater European market—albeit run with a natural attention to detail and extraordinary efficiency. It’s the different local challenges which shape technology needs and lead to different emphasis.

SOA and Web services are very mature and indeed are pushed to their limits, but the API market is still in its very early stages. The informal, wild west character of RESTful services doesn’t seem to resonate in the corridors of power in Zurich. Cloud appears in patches, but it is hampered by very real privacy concerns, and this of course represents a great opportunity. Secure private clouds are made for this place.

I always find Switzerland very compelling and difficult to leave. Perhaps it’s the miniscule drop of Swiss ancestry I can claim. But more likely it’s just that I think that the Swiss have got this life thing all worked out.

Looking forward to going back.

Advertisements

The Future Is A Story About Mobile Computing

Earlier today CNET published an interview with Marc Andreessen, in which the Netscape founder and influential VC outlines his personal vision for where tech is heading in the near future. His new tagline, from a piece he wrote for the New York Times, is “software is eating the world”, a blunt reference to how software increasingly appears out of nowhere to utterly consume a traditional practice or business model—be this in commerce, the social realm, or just about everywhere.

Andreessen asserts that this affect will only accelerate in the future because of the explosion we are experiencing in mobile computing:

Most of the people in the world still don’t have a personal computer, whereas in three to five years, most people in the world will have a smartphone…. If you’ve got a smartphone, then I can build a business in any domain or category and serve you as a customer no matter where you are in the world in just gigantic numbers–in terms of billions of people.

This new scale of mobile is something we’re only beginning to see, but it is becoming clear that the change this brings about is going to be profound. Mobile computing is very interesting to Layer 7; watch our for some interesting new developments coming out of our labs early in the new year.

I discovered a similar indicator of mobile interest using Google’s Insights for search. Pete Soderling and Chris Comerford, from Stratus Security Technologies, gave an excellent talk back in 2010 at the RSA show about REST security. They illustrated how the zeitgeist around distributed computer communications was changing over time by comparing search volume for “SOAP Security” (blue line) and “REST Security” (red line):

Try this out for yourself here.

What struck me about this was not that REST came up so fast—you’d have to be living under a rock to have missed that one—but that the two approaches have been tracking roughly equivalent over the last year. This mirrors our own experience at Layer 7, where we support both SOAP and REST security equally. We see similar patterns of interest coming from our customers.

What is even more interesting is what happens when you add “Mobile Security” (yellow line) to the mix:

Try it here.

The future indeed, will be written from a hand held device.

Clouds Down Under

When I was young I was fascinated with the idea that the Coriolis effect—the concept in physics which explains why hurricanes rotate in opposing direction in the southern and northern hemispheres—could similarly be applied to common phenomenon like water disappearing down a bathtub drain. On my first trip to Cape Town many years ago I couldn’t wait to try this out, only to realize in my hotel bathroom that I had never actually got around to checking what direction water drains in the northern hemisphere before I left. So much for the considered rigor of science.

It turns out of course that the Coriolis effect, when applied on such a small scale, becomes negligible in the presence of more important factors such as the shape of your toilet bowl. And so, yet another one of popular culture’s most cherished myths is busted, and civilization advances ever so slightly.

Something that definitely does not run opposite south of the equator turns out to be cloud computing, though to my surprise conferences down under take a turn in the positive direction. I’ve just returned from a trip to Australia where I attended the 2nd Annual Future of Cloud Computing in the Financial Services, held last week, held in both Melbourne and Sydney. What impressed me is that most of the speakers were far beyond the blah-blah-blah-cloud rhetoric we still seem to hear so much, and focused instead on their real, day-to-day experiences with using cloud in the enterprise. It was as refreshing as a spring day in Sydney.

Greg Booker, CIO of ANZ Wealth, opened the conference with a provocative question. He simply asked who in the audience was in the finance or legal departments. Not a hand came up in the room. Now bear in mind this wasn’t Microsoft BUILD—most of the audience consisted of senior management types drawn from the banking and insurance community. But obviously cloud is still not front of mind for some very critical stakeholders that we need to engage.

Booker went on to illustrate why cross-department engagement is so vital to making the cloud a success in the enterprise. ANZ uses a commercial cloud provider to serve up most of its virtual desktops. Periodically, users would complain that their displays would appear rendered in foreign languages. Upon investigation they discovered that although the provider had deployed storage in-country, some desktop processing took place on a node in Japan, making this kind of a grey-area in terms of compliance with export restrictions on customer data. To complicate matters further, the provider would not be able to make any changes until the next maintenance window—an event which happened to be weeks away. IT cannot meet this kind of challenge alone. As Randy Fennel, General Manager, Engineering and Sustainability at Westpac put it succinctly, “(cloud) is a team sport.”

I was also struck by a number of insightful comments made by the participants concerning security. Rather than being shutdown by the challenges, they adopted a very pragmatic approach and got things done. Fennel remarked that Westpac’s two most popular APIs happen to be balance inquiry, followed by their ATM locator service. You would be hard pressed to think of a pair of services with more radically different security demands; this underscores the need for highly configurable API security and governance before these services go into production. He added that security must be a built-in attribute, one that must evolve with a constantly changing threat landscape or be left behind. This thought was echoed by Scott Watters, CIO of Zurich Financial Services, who added that we need to put more thought into moving security into applications. On all of these points I would agree, with the addition that security should be close to apps and loosely coupled in a configurable policy layer so that over time, you can easily address evolving risks and ever changing business requirements.

The entire day was probably best summed up by Fennel, who observed that “you can’t outsource responsibility and accountability.” Truer words have not been said in any conference, north or south.

The Cloud Security Alliance Introduces The Security, Trust and Assurance Registry

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.

Introducing Layer 7’s OAuth Toolkit

“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.

LulzSec Disbands

“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.

Blowing Holes in the Web of Trust

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.