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.