Overview of XML Security Trust and Threat models

Web Services allow machines to interact over a network via XML and SOAP messaging, and this has proven to be a valuable tool to both businesses and consumers. SOA Gateways, such as Forum Sentry, allows one to securely and efficiently process XML, SOAP and REST-based enabling a secure SOA deployment.

XML and Web Services Security can be categorized into Trust and Threat Models. The Threat Model helps identify both inbound and outbound threats and provide means of remediating such threats. Trust Models ensure that message privacy and integrity and retained while ensuring proper that appropriate authentication and authorization decision are made before letting messages traverse a corporate network.

Threats: Three major threats are Denial-of-service attacks (DoS), Viruses, and SQL injections:

• DoS attacks prevent a user, or an organization, from accessing services of a resource that they would normally be able to gain entry to. Although this type of attack can cost time and money, usually there is no information loss involved.

• A virus is a program, or a programming code, that replicates itself. Viruses are often found in email attachments, downloaded files, and on CDs. They may erase data or damage the hard drive. When a virus duplicates itself by resending itself as an attachment to an email or as a component of a network message, it is called a worm. There are three classes of viruses: file infectors, system or boot-record infectors, and macro viruses. File infectors attach themselves to program files and infect that program. System, or boot-record infectors, infect code on areas of a disk. Macro viruses are the most common, but they do the least amount of damage. Viruses can use Web services to enter corporate domains by going undetected through SOAP attachments (MIME or MTOM). Since such attachments are Base-64 encoded or maybe encrypted, traditions Anti-virus engines cannot match signatures to detect them

• SQL injections are used to gain access to a database or retrieve information from a database. This access is unauthorized and programs and applications are at risk of being attacked. It is easy to defend programs and applications from SQL injections by using simple coding practices or by looking for malicious string patterns used for SQL injections.

Trust: Three major categories of trust are privacy, integrity, and identity:

• When it comes to privacy, encryption protects personal information by encoding information. This has to be done so that only the person, or computer, with the private key can decode the information.

• Integrity insures that no one tampers with information. Signatures and verification are both part of integrity. Signatures are strings of letters and numbers that represent a signature. The message is scrambled with mathmatical formulas or algorithms. A key is needed to validate the signature. Verification simply validates a users indeed signed a message with his private key.

• Identity involves authentication, authorization, access control and tokens. Authentication verifies that information comes from a trusted source. One must know who created the information, as well as be sure that the information has not been modified since created. Authentication works closely with encryption to ensure that there is a secure environment. Authorization is simply controlling the access and rights to resources, including things such as services or files. Access control restricts what a user can do various resources. There are many types of tokens including SSL tokens, SAML tokens, and WS-Username tokens. Properly handing such Tokens both at the protocol and message level is crucial for establishing trust between business entities.

Both trust and threat must be addressed so ensure Web Service security. This is an essential component of information technology since a large amount of information is now located on the internet. Forum Systems has developed products that provide security in the Web Service environment.

For more information about trust and threat, see the whitepaper Solving The Trust & Threat Equation.

How-to establish XML Security using a Network Appliance

Providing appropriate XML Security is essential in ensuring secure integration across applications. XML makes machine-to-machine communication possible using standard internet communication protocols. The flexibility of using XML to integrate application directly competes with security. Forum Sentry, the leading patented appliance for XML Security enables enterprises to integrate with their trading partners without compromising security.

It is important to note that one of the main focuses of the Sentry XML appliance is, and has always been, XML security. Right out of the box there are many security features enabled by default, and the fact that your clients are accessing Sentry and not your back-end service directly is a major security benefit in itself. Forum Sentry is the industry's only patented XML Security Gateway that is both FIPS 140-2 certified and DoD PKI certified. For a good overview of Sentry's focus on security please click here.

You can also find many whitepapers regarding security around XML and Web Services here. We recommend starting with the "Best Practices in Deploying SOA Gateways" and the "Attacking and Defending Web Services" papers for a good introduction.

There are many features of Sentry related to securing XML that SHOULD always be utilized. These features include:

• SSL (with or without Mutual Auth)
• XML Encryption/Decryption
• XML Signature/Verification
• Intrusion Detection and Prevention (IDP Rules)
• Pattern Matching
• Anti Virus scanning
• Identity and Access Control (many different ways to accomplish this)

Below are some recommendations for utilizing common features in Sentry to further increase the security of your services:

• Use SSL with all externally facing services. All network listeners should use SSL (HTTPS). Start by enable SSL, and then consider enabling SSL with Mutual Authentication. SSL with client/server auth allows you to verify the client cert (and tie it to a specific user). At the very least, the network listeners should be HTTPS (SSL). For FTP traffic, Sentry supports FTPS (TLS or SSL) and OpenPGP encryption, decryption, signatures, verification.
• Use IP ACLs on your network listener policies to only allow incoming traffic from specific IP addresses or IP ranges. If a client tries to connect from an unknown IP range the connection will be rejected.
• Tighten existing IDP rule thresholds or add new IDP rules depending on your specific criteria.
• Enable Anti Virus Scanning.
• Consider creating custom Pattern Match policies to catch specific text strings. This helps to ensure no confidential data is leaked out with the response messages and prevents any harmful XML attacks coming into the service.
• Consider using XML encryption and XML decryption with your trading partners. The trading partners would encrypt the request data before sending to Sentry, the request data is then decrypted on Sentry. For response processing, Sentry would encrypt the response data before sending it back to the client.
• Consider using Schema Tightening and advanced validation options with your WSDL policies.
• Utilize Sentry's built in PKI infrastructure. Create, import, and store all keys related to the security of your services within Sentry. For added PKI security upgrade to the Sentry appliances that include the FIPS Level III HSM.

How to tell if your services are secure?

In addition to the recommendations above for tightening the security of your services with Sentry, we strongly recommend you perform some security/vulnerability/penetration testing of your services hosted on Sentry. You can use SOAPSonar from Crosscheck Networks to perform this testing. This is a great tool for functional and performance testing as well, but there is patented technology focused on security/vulnerability testing that you won't find with any other SOA test tools.

For instance, SOAPSonar includes a Vulnerability mode that enables the user to run scans against your services and report any potential issues - and explain how to fix them! In addition, if you configure SSL, encryption/decryption, or other WS Security features on Sentry, you can use this tool to test these features.

You can download a free evaluation of SOAPSonar here.

XML Gateway Patent

Forum Systems, the pioneer in SOA / XML Gateways became the first network appliance to be issued a Patent for XML security functionality.  This issued patent 7,515,333 has a significant impact on the XML Gateway market landscape and locks Forum Systems position as the pioneer in the XML Security appliance marketplace with defensible protection for XML Security hardware related Intellectual Property.  Vendors in this space include:

1. Forum Systems 
2. IBM Datapower
3. Cisco
4. Intel
5. Vordel
6. Layer7

For more details on this news click here.

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 ....