Speaking at the RSA 2010 Conference about XML - the soft underbelly of the Cloud

Next week at the RSA Conference in San Francisco I am speaking about XML security, a topic which has renewed importance because XML is used as the basis for so many Cloud interfaces.

In the talk, I talk about XML vulnerabilities related to the Xerces parser, and also explain how techniques such as CDATA smuggling can be used to smuggle malicious content through XML interfaces. I present an example of one such interface which allows CDATA-masked XML through, to a Cloud SaaS provider.

If you're at RSA, give me a shout!

Scriptable Command-Line Testing of Web Services

Did you know that with the free SOAPbox tool and with Vordel's XML Gateway you get a command-line tool which will send traffic to a Web Service and simulate load? Check it out yourself. The tool is called "SR" (Service Request)). With its parameter options it allows you to perform a load test, to send an attachment, and to perform SSL. After it runs its test, it presents you with statistics about the response times from the Web Service. It's a good part of any SOA or Cloud API practitioner's tool-belt.

Beansec Tonight at the Middlesex Lounge in Cambridge

Looking forward to the BeanSec meetup this evening at the Middlesex Lounge near MIT - hope to see other like-minded folks there...

After the Middlesex Lounge, possibly things will move over to the Asgard pub. The Asgard is named after the Irish gun-running boat which smuggled rifles from Germany to Irish rebels in 1914, sailed by Erskine Childers, an Englishman who later became Ireland's president. There is also a strong Boston connection to Childers, related to when he borrowed a spanner (or rather, "wrench") in Beacon Hill in 1903:

In autumn 1903 Childers travelled to the United States as part of a reciprocal visit between the Honourable Artillery Company of London and the Ancient and Honorable Artillery Company of Massachusetts of Boston. At the end of the official visit he elected to remain and explore New England on a hired motor cycle. One day by chance the machine broke down outside the Beacon Hill home of Dr Hamilton Osgood, a prominent physician in the city. Childers diffidently knocked to borrow a spanner but, as a visitor with the celebrated HAC, he was invited in for dinner and introduced to Dr Osgood's daughter, Mary Alden ("Molly") Osgood. The liberal English author and the well read republican heiress found each other congenial company. The hospitable Dr Osgood organised the rest of Childers's stay, with much time shared with Molly, and the pair were married at Boston's Trinity Church on 5 January 1904.

http://en.wikipedia.org/wiki/Robert_Erskine_Childers

History lesson over - hoping for some good Cloud and security conversation this evening.

How Cloud Service Brokers enable the Cloud Marketplace

Today, Mike Vizard from CTO Edge covers the Vordel Cloud Service Broker and mentions that:

"...customers are going to want to see an ecosystem of cloud computing services from multiple vendors that will allow them to dynamically allocate various jobs based on the capabilities and pricing offered by the cloud computing service. To accomplish that, IT organizations are going to have to deploy something that functions like a cloud computing broker at the edge of the enterprise."
http://www.ctoedge.com/content/enabling-ecosystems-cloud

This, of course, is exactly what the Vordel Cloud Service Broker provides. It mitigates against the differing proprietary interfaces provided by multiple Cloud providers. Once these proprietary interfaces are smoothed over by the Vordel Cloud Service Broker, this enables a number of exciting consequences. Mike Vizard mentions the usage of Amazon Spot Pricing as one of them.

Jonathan Kupferman has provided a good summary of the benefit of the Cloud Service Broker here:

With a plethora of cloud providers, each with a their own API/set of services/pricing model/etc it would be quite cumbersome for the end-user to programmatically access each service. Instead, the cloud broker creates the layer of abstraction between the user and providers so that the end users can see one cohesive view of all of the services. This way the customer doesn't have to worry about the nitty gritty like the different REST calls required to create a server, they just hit the launch button and a server appears on the desired cloud.
http://www.regexprn.com/2009/08/low-down-on-cloud-brokers.html

This allows the user of the Cloud Service Broker to deal with one interface, which represents a contract, and then the broker connect to the services on the client's behalf. As Chris Hoff puts it:

"In the case of the service broker, it’s their job to take these declarations of service definition (service contracts) and translate them across subscribing service providers who may each have their own proprietary interface."
http://www.rationalsurvivability.com/blog/?p=1189

As well as brokering the connection to multiple Cloud-based services which have differing interfaces, the Cloud Service Broker also manages the API Keys which are used to authenticate to the services. The Cloud Service Broker also meter the connections so that there are no billing surprises, and in order to provide an independent audit trail. Another key advantage of the Cloud Service Broker is that it allows for Service Level Agreement information to be collected for Cloud Services, from the point of view of the client. Cloud Service Providers, famously, are often loath to provide such SLAs.

Sign up for an invitation to download the Vordel Cloud Service Broker here.

Cloud and the Utility Meter Analogy

The "home utility" analogy is often used to explain Cloud Computing. For example, most people do not have an electricity generator in their house, and even if they do, they do not run it all the time. Instead, they rely on an external provider for electricity. In fact, I have often heard this analogy used by Cloud providers themselves: when asked "Why should I use your hosted services?", they ask back "Do you run an electricity generator in your house?".

But consider metering. For home utilities, meters are provided locally. Customers can view the meter reading and compare it to bills. This is not the case with Cloud Service Providers. What is needed is an on-premises broker in order to monitor the outbound connections and to lay down an audit trail.

For more on Cloud Metering, check out this EbizQ article.

Vordel is Hiring Technical Architects

Interest in working for Vordel? Check out the job description below, which you can also find at: http://www.vordel.com/about/careers/TA072.html. The position is based in Virginia and we're looking for candidates in that whole general area.

Position: Technical Architect

Location: Herndon, Virginia, USA
Reference Code: TA072


Description

Can you whiteboard in front of an Enterprise Architect and relate back to an Engineering team a customer's key technical requirements? Vordel's Technical Architects are responsible for driving sales, in partnership with field sales, by serving as a technical resource throughout the sales cycle.

Responsibilities

• Partner with sales executives to determine the client's technical needs; how Vordel's product(s) might fill those needs; the degree of customization required, and how best to approach.
• Present technical capabilities of Vordel products and be able to clearly articulate the functionality and manage the customer/prospect's expectations of what the product can do.
• Work directly with customer to fully understand their requirements and define and manage the technical evaluation or POC (directly or via a partner).
• Evaluate project feasibility and define use cases.
• Draw up technical architectures (Microsoft Visio)
• Define and manage process.
• Install and configure Vordel product(s) in client environment.
• Deliver onsite training on Vordel's products to partners and customers.
• Facilitate hand-off to a service partner.
• Assist Customer Support as needed by validating client issues on-site; typically where further sales opportunities exist.
• Assist in the timely production of quality proposals.

Qualifications:

• US Government Security Clearance - whilst not compulsory, would be an advantage.
• Experience of Enterprise Application Integration tools, technologies and applications (ESB, SOA, EDI).
• Web Services knowledge (XML, WSDL, SOAP).
• Knowledge of Cloud services such as Amazon Web Services and Force.com.
• Solid Understanding of security concepts such as digital signatures & cryptography and experience with enterprise authentication, authorization & messaging systems (e.g. LDAP, CA Siteminder, WebsphereMQ, TIBCO, JMS, etc.).
• Comfortable working in Linux, Solaris, and Windows environments.
• Prior consulting & project management experience.
• Degree level education, and 5+ years related experience.
• Effective presentation skills.
• Based in Herndon, Virginia but able to travel frequently throughout North America

If you are interested, please submit your CV/resume with a short cover note to openvacancies@vordel.com

The $6 Haircut

One of my colleagues alerted me to a Superbowl ad which ran last Sunday, concerning a barber shop which began offering $6 haircuts.



The problem was that the $6 haircuts were, of course, substandard. So how did competitors compete with this "too good to be true" offer? By putting up a sign saying "We fix $6 haircuts".



Jay Shepherd, a lawyer here in Boston, provides some good analysis: the barber who fixed the $6 haircuts "knew his customers would appreciate that value, and would pay for it".

It is easy to see parallels in the SOA space. Whole advertising campaigns have been built around "hey, we'll give you our product effectively for free - it may not work as well as the other guys, but we won't tell you that". Then customers must deal with the consequences, either using a substandard solution, or spending a great deal of money trying to get the "cheap" solution to work as well as the solution they should have used in the first place. The lesson is: "don't be the guy with the $6 haircut".

The RESTful STS

A Security Token Service (usually abbreviated to STS) is used to issue tokens. It is used for situations where a service requires a particular identity token, for example a SAML token. Check out a video of an STS in action here. A client requests the token from the STS, using a SOAP request according to the WS-Trust RequestSecurityToken (RST) specification:



However, Vikas Jain has suggested a more streamlined way for an STS to operate. Rather than using heavyweight SOAP messages to invoke the STS, why not use REST instead. This becomes a "RESTful STS". Vikas has suggested a token exchange for clients of a REST STS.

Let's explore how a RESTful STS would be configured in Vordel's XML Gateway. Here is a policy which will issue a SAML token or a more streamlined custom token when invoked with a RESTful query:



The policy is checking which type of token the REST caller is requesting: SAML or a custom token. The custom token is a lightweight non-XML token. Here we request a custom token from the STS using a request like this:
http://xmlgw:8080/RequestSecurityToken?TokenType=custom&RequestType=Issue
and we see the token returned:



Here we are requesting a SAML token using a request like this:
http://localhost:8080/RequestSecurityToken?TokenType=saml&RequestType=Issue

And we see the SAML token returned:



Calling a RESTful STS is, by design, must simpler than calling a full WS-Trust/SOAP based STS. Calling the RESTful STS from an XML Gateway is straightforward. In order to call the RESTful STS, we can make use of the fact that, within the Vordel XML Gateway, you can call out to another service "off the the side" within a policy. Here we call out to a RESTful STS in order to request a security token, and then we inject it into a HTTP Header:



Testing this in SOAPbox, we see the security token inserted by the Vordel XML Gateway into the Authorization header. This header can then be consumed by the downstream application server, or an agent inside the application server.



In summary, a RESTful STS is certainly a promising way to make STS functionality more generally used, since it doesn't require a heavyweight SOAP message to be created.

How to use SOAPbox to send attack vectors to a Web Service for vulnerability assessment / penetration testing

SOAPbox is a handy tool for testing a Web Service. It does stress testing, functional testing, authentication testing (e.g. handling mutual SSL), and vulnerability assessment. The vulnerability assessment piece is provided by the "attack vector" feature. You can access the attack vector functionality in the SOAPbox product by following these steps:

Firstly if you don’t have it already, download a free copy of SOAPbox from http://www.vordel.com/products/soapbox/

Next, in the “Classic” mode of SOAPbox (selected using the tabs in the top-right), load in the WSDL of the service you want to test (using the icon shown in the “WSDL_Import” screenshot attached). This will allow you to load in a particular operation of the WSDL.

Press the green triangular “play” button on the SOAPbox toolbar to send the request through once, to make sure it is hitting the Web Service. You should see a response in the right-hand side “Response” area. Now, you have tested it without the security vectors being inserted.

Now, Switch over to the “Design Mode” in the SOAPbox. Make a new test suite and a test case. It should now look like the attached “SOAPbox-configured” screen.

Press on the test case and choose “Add SOAP Message”. You can copy and paste the example SOAP message in here, under the “Body content” tab. This is the SOAP message you’ll be automatically inserting security vectors into.

Next, use the tab at the bottom of the screen to choose “Security Vectors”. On the left you’ll see a list of Security Vectors to add, such as SQL Injection and XPath Injection, and on the right you’ll see a tree-view of the message. Drill into this tree-view of the message on the right of the screen and choose where to place security vectors in the message. Now you can send the message by once more pressing on the green triangular arrow again. You will see the test input and response now on the right-hand-side of the screen.

Looking back to 2009, and brokering the Cloud for 2010

I'm pleased to report that Vordel today announced "a record increase in annual revenues and net income for 2009 with overall revenues up almost 80% on the previous year. Vordel added an additional 32 enterprise customers to its global user base validating Vordel's position as the premier provider of SOA and Cloud Governance products".

You can read more details at the news outlets below:



If you read down through the news details, you can see that a key offering for Vordel in 2010 is the Cloud Service Broker. We are now seeing the category of the Cloud Service Broker begin to emerge, and it is as exciting as the early days of the XML Gateway. It is exciting to work with early adopters who are gaining an edge on their competition, and exciting to see analysts and journalists covering the sector. Linda Leung over at Data Center Knowledge has written a piece which pull together a very useful list of Cloud Brokers, and provides the following commentary based on Gartner:

Gartner defines three opportunities for cloud brokers:

* Cloud Service Intermediation: Building services atop an existing cloud platform, such as additional security or management capabilities.

* Aggregation: Deploying customer services over multiple cloud platforms.

* Cloud Service Arbitrage: Brokers supply flexibility and “opportunistic choices” – and foster competition between clouds.

http://www.datacenterknowledge.com/archives/2010/01/22/cloud-computing-brokers-a-resource-guide/

This is a good overview of what Cloud brokers will be doing in 2010, as organizations continue to adopt Cloud-based services. Vordel is at the forefront of this. Watch this space...