Wednesday, February 24, 2010
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!
Monday, February 22, 2010
Wednesday, February 17, 2010
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.History lesson over - hoping for some good Cloud and security conversation this evening.
Tuesday, February 16, 2010
"...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."
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.
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."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.
Monday, February 15, 2010
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.
Friday, February 12, 2010
Position: Technical ArchitectLocation: Herndon, Virginia, USA
Reference Code: TA072
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.
- 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
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".
Thursday, February 11, 2010
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:
and we see the token returned:
Here we are requesting a SAML token using a request like this:
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.
Tuesday, February 2, 2010
How to use SOAPbox to send attack vectors to a Web Service for vulnerability assessment / penetration testing
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.
Monday, February 1, 2010
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:
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...
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/