XML Security Gateway Evaluation Criteria Project

As Richard Bejtlich observed the TCP/IP stack is becoming intertwingled with lots of other things. Certainly, Cisco's purchase of Reactivity should lead us to expect more angle brackets in the stack not less, meaning XML Security is important in infrastructure as well as in distributed apps.

One of the primary, robust ways to deal with XML Secuirty in SOAP, Web services, SOA, and Rest apps is to use a XML Security Gateway. These are very powerful tools, the downside for the enterprise is that they are hard to assess and analyze. I launched the OWASP XML Security Gateway Evaluation Criteria project to:

* Create evaluation criteria supporting a transparent, level playing field for XML Security Gateway solutions to define their solution's key value proposition

* Where practical, attempt to standardize nomenclature and metrics

* Educate the community on the design considerations for XML security

I have found Ivan Ristic's work on the Web Application Firewall Evaluation Criteria to be very helpful, and would be happy if we can achieve similar utility in the XML security space.

Comments

[kartik]

good stuff...let me know if you need any help. I have extensive experience in XML and application security

[Bob McCormick]

If your WS-Security envelope is terminated on an XML appliance, and not in the application server, then
doesn't this create a security perimeter much like the firewalls and SSL gateways that you've previously critiqued on this blog?

[Gunnar]

Bob - no it does not require that. For a number of reasons

1) WS-Security supports multiple token types and namespaces in one message, so your security model is not an all or nothing proposition. I can define one token for the postman and one for the recipient, for example

2) A XSG need not be a standalone hardware device, they can be software based running on the same box as your app if you like. Obviously there are tradeoffs here

3) Frequently XSGs proxy communications. Read in security header/token, perform security checks, apply new or additional secuirty tokens/header, and forward request

Firewalls and SSL do nothing to address the basic security needs a web service has - end to end authentication, authorization, auditing, input validation, and so on.