Why an XML Gateway should be FIPS Certified - Especially in Federal Agencies

A FIPS certified appliance provides self-test and a finite state machine, providing network security assurance without risk of compromise. FIPS 140-2 validation of the entire appliance is the only independent validation that can provide assurance that the proper key storage, cryptographic operations, and operational integrity of the SOA Gateway have been met. A number of agencies and private organizations have now made FIPS a core requirement and recognize that just providing HSMs is insufficient and a fully FIPS validated SOA Gateway Appliance should be deployed to ensure the highest degree of robustness, scalability and security in a SOA deployment. For complete article click here.

Introduction to SOA/XML Gateways

There is an excellent article published by the folks at Forum Systems that highlights the best practises in deploying SOA/XML Gateways within your networks. The article covers the following significant areas:

1. Service Virtualization and Control
2. Data-level Privacy and Integrity
3. Information Flow Control and Audit

This article is a must read for serious SOA/XML architects, Application Integration specialists, Security professional and XML-based application developers.

To Read Article, goto: http://forumsys.com/resources/resources/whitepapers/Best_Practices_in_Deploying_SOA_Gateways.html

Why is an XML Gateway a requirement?

Much have been talked about this subject. The main two reasons to justify the capital expense on such a device are performance and security. When the enterprise deems those two reasons relevant it is a no brainer to make the XML gateway a requirement. Now let's take a simpler scenario where performance is not a problem and security is meant to be accomplished using SSL. I claim even in this scenario purchasing a dedicated server is a wise investment.

Let's assume you intent to invoke web services from multiple partners. The number of partners could potentially be on the thousands. As is the case, currently most of this partners do not have any web services as of yet. So they start as usual writing it from scratch using something like .NET. These projects tend to be low key and usually prototypes, so the use of a gateway is not even considered.

Most scenarios, in addition to using SSL mutual auth to secure the connection and authenticate the client will use some sort of XML security such as signature verification. This will require the developer coding the business case to write the required code for the signature verification. This is no trivial task to get done correctly. Even with all the help the .NET framework gives you, there are many caveats the developer will have to be aware and most likely will not have time to properly code for.

I see several problems with this approach. The security of the deployment solely relies on the time and expertise of the developer writing the security piece. In most cases, verifying the signature is just a small piece of the puzzle, quite irrelevant to the business case. It is a necessary evil that need to be done, but does nothing for the bottom line of the company. Debugging the signature verification code is time consuming. Why bother re inventing the wheel when they are companies that specialize in doing this sort of thing? The private keys are most likely sitting on the hard disk not properly secured. Whenever a new web services comes online the procedure will have to be repeated. This model is not scalable and at the end not cost effective.

The same use case can be done with an XML gateway fronting all the security aspects: SSL termination, signature verification or any other security requirement. The gateway centralizes all security aspects so that your developers can concentrate on the business case at hand. You can rely that your web service is properly secured without having to trust the individual ability of each developer. After all, the gateway is backed by a company so their reputation is always on the line. Private keys and certificates are on a central secured location not spread around in web servers around your organization. The Gateways are kept uptodate with the security standards, no need to go back to every one of your coded applications to update the security aspects of it. At the end, you will have save money and time for your company and ensured the Web Service deployment is secured.

Common problems with SOA deployments

Most large corporations face a common set of SOA deployment issues. Some of the issues are technical, some organizational. SOA is all about encouraging re-use at all levels, from simple operations to complex combinations of operations that form re-usable business operations.

Here are some common problems that we have seen across many deployments:

• Security is rarely a concern when enterprises build new SOA systems or port legacy systems into a SOA based environment. If at all, security is introduced as an after thought. Applications are built by development teams, and once they are ready to go into production, the operational folks bring up security concerns and the quick and dirty solution is to "turn on SSL."

Recommendations: Start looking at SOA security issues early on in the development process. Look at security within SOA comprehensively. Consider content-based security, protocol security, access control across operations. Look closely at the sensitive information and who should have access to it.

• Identity Management Systems are crucial in SOA deployments. However, Identity Management Systems are designed for Single Sign-On for web site resources, rather than protecting web services operations.

Recommendation: Ensure that your identity systems are extensible and can address SOA specific access control.

• Scaling: As new web services come online in your organization securing and monitoring them becomes increasingly difficult.

Recommendations: Make sure you have an XML firewall capable of scaling with your needs. In addition to the XML firewall, you are going to need a monitoring solution, to track capacity limitation and potential outages.

• Monitoring the health of your web services security infrastructure is no longer limited to your load balancer pinging your XML firewall. Even though your firewall might be responding to ICMP packets that's no guarantee that your web services are working correctly.

Recommendation: A combination of a monitoring solution and some health checks across the infrastructure. Make sure your health check exercise one or more of your web services operations to make sure that not only the XML firewall is up but also the back end servers that perform the web services operations. All parts of the infrastructure should also be monitored, including databases, syslog servers, identity servers and network connectivity.

• People: The single most problematic part of SOA deployment is the people involed in supporting and maintaining the deployments. In the past, firewall configuration and setting is something the IT department handle. SOA deployments present an unique challenge in this regard. XML firewall touch on so many internal system that in most cases not a single person is capable of maintaining the XML firewall by himself or herself. This is could be one of the most expensive aspect of a SOA deployment.

Recommendation: Make sure you assign a single person responsible for your XML firewall. This person does not necessarily need to know how to configure every aspect of the XML firewall, but it should be responsible for coordinating all aspect of deploying the configuration. Whatever you do, do not leave the XML firewall configuration on the hands of the IT department!!! In most cases the folks do not have the technical expertise for maintaining, and it requires help of the web services developers for properly manage the devices. In addition, avoid too many people having access to configure the device. It is best to have a small group of people that can make changes.

More to follow ....

Techniques in Attacking and Defending SOA Web Services

A good resource for those interested in the benefits of deploying a SOA Gateway. This is hands-on demonstration of attack vectors for SOA and Web Services and implementation of defense strategies using a SOA Gateway. Techniques include live examples of:

• SOAP based SQL Injection Attack
  
• Denial of Service Web Service Attack
• XSD Mutation
• Identity Discovery

Attack vectors are demonstrated using Crosscheck Networks SOAPSonar testing and diagnostics product and each attack is explained and mapped to the published CAPEC: Common Attack Pattern Enumeration and Classification system.

The Forum Systems Sentry SOA Gateway is shown as the central defense mechanism for back-end services with live data transaction examples and defensive actions.

View the demonstration here.

Virtues of WSDL Virtualization

WSDL virtualization is the ability to create a virtual WSDL from one or more predefined WSDLs files. Typically, WSDL virtualization takes place across multiple back-end systems that expose their operations through WSDL documents. An intermediary gateway sits between the producer and the consumer and aggregates the WSDLs. Based on policies enforced on the gateway, operations are exposed to the consumers. A sample deployment is shown below.


The virtues of WSDL virtualization include:

1. Security: The virtual WSDL can exposed or hide some of the operations from the original WSDLs. The WSDL endpoints are cloaked with only the intermediaries endpoints being exposed.
   
2. Consistency: Virtualization allows to select operations from multiple WSDLs and exposed them to clients as a coherent single WSDL.
   
3. Productivity: The main benefit of virtualization is to be able to mix and match operations without having to copy and paste parts of the desired WSDLs into new WSDL files. It allows a customer to be able generate a library of all the operations suported on its organization and only exposed the ones required for a particular customer.
   

Some of the challenges of WSDL Virtualization addressed by Sophisticated SOA Gateways, such as Forum Systems Sentry include:

1. Resolving different schemas that share the same namespace.
   
2. Multiple schemas might have different constraints for the same element, that might be incompatible.
   
3. Exposing the list of WSDLs that developers should be working on. Although external trading partners typically require a single WSDL, internal developers work with multiple WSDLs. A list of WSDL needs to be retrieved from the SOA Gateway to better manage developers working across multiple WSDLs

WSDL Virtualization is a crucial part of deploying SOA. The vices of free-for-all operations can quickly set chaos within a SOA deployment that can only be controlled through SOA Gateways that provide strong WSDL virtualization.

Qualifying Your SOA Gateway's Horse Power

Often in our tech industry there is a penchant to spout off performance numbers without qualifying the metrics and conditions under which these numbers are derived. The SOA Gateway community is not immune to this indulgence. I have to admit, even I am guilty of committing this sin sometimes.

In the SOA Gateway world, performance cannot simply be defined in terms of transactions per second (TPS) due to complexity of a message transaction and the task policy of the gateway. As a result, SOA Gateways today always specify a specific task (i.e XML transformation, WS-Encryption) and the associated TPS. However, this type of metric still falls short of fully expressing the true performance metric of a SOA Gateway. For example, a common task that is staple of every SOA Gateway is schema validation. This task validates the the structure of incoming and outgoing SOAP/XML messages. The performance of a SOA Gateway when performing validation is often expressed in terms of Schema Validation TPS.
This is simply not sufficient. Further qualifiers that should be applied to schema validation performance numbers are as follows:

• What is the size of the message?
• What transport protocol (HTTP 1.0, HTTP 1.1, MQ etc) was used to derive the numbers?
• Was the deployment in proxy mode or was it in service mode?
• How many clients were used in generation of load?
• Was the validation task performed on both inbound and out bond messages?
• How complex was the message structure and its associated schema (i.e n-dimensional arrays, abstract types).

The last bullet is a real challenge and it really affects the validation performance of a gateway.
Unless, these qualifiers are resolved, the numbers are subjective at best. Maybe one day we will learn some lessons from the automotive industry to really define a true metric in defining performance of each task in a SOA Gateway.