SOA Gateway - The Evolution of SOA and Cloud Computing

It has been a long time coming. For many years SOA Governance was the industry buzzword that virtually every company employed to indicate that they played in the SOA arena. The term "SOA Governance" was used to describe everything from design time management of test and design artifacts, monitoring, enforcement, UDDI registry storage, SLA expectations, etc. Many of the industry analysts latched onto UDDI as the central technology that would drive the governance initiatives.

The reality of successful SOA deployment turned out to be a different story. Successful SOA was measured on a project by project basis. Feedback from the CIO and CFO level as to the benefits of each project then reinforced the technology decision to invest further in SOA. It is the individual advantages first that lead to the higher level advantages later of investing in SOA. Due to the fractured nature of SOA deployments, it began to become a technology and architecture of multiple domains within an organization. Teams that each were able to show success of SOA did not do so in concert with each other.

That all changed once the adoption of SOA gateway technology began to take hold. SOA Gateways allow for the runtime governance of services and transactions. This in turn provides the means to aggregate the services of an enterprise in one consolidated location and centrally enforce reusable policies with regard to access control, security, and monitoring. This technology has led the way to the recognition of SOA as a true enterprise ROI optimization investment. As a result, the SOA Gateway has now also become what analysts had envisioned for UDDI in the early phases of SOA, which is the central place by which to manage, enforce, and monitor (a.k.a. govern) services and transactions.

Now we come to the age of cloud computing which is the new buzz phrase that has all but replaced "SOA Governance" in blogs, press releases, analysis coverage, and news cycles. This is the next frontier, the new promise of technology. Let's be clear, cloud computing has potential and real promise as a game-changing technology paradigm, but the actual adoption and recognition of this outcome will follow the same path as SOA did to get there.

Consider that SOA as a concept has been around for many years. Software as a service is not a new concept, but the open nature of services extended this concept to SOA. Cloud computing extends this concept further by providing dynamic SaS as lower cost, on-demand services. While the notion is easy to recognize in it's simplicity and elegance, it becomes a little more difficult to map to actual enterprise business use-cases.

Enter the SOA Gateway. This technology has become the central governance broker for transactions among clients and services. By that nature, the SOA gateway already abstracts the client from the service. This abstraction lends itself perfectly to the adoption of cloud based services that can extend the capacity and computing requirements on both sides of the transaction.

The success of Cloud Computing for enterprise transactions will depend on solving the core business concerns of reliability, security, access control, and accountability. It is not a coincidence that these topics happen also to be the core feature set of the SOA gateway industry.

Just as protocol firewalls and web application firewalls paved the way to the adoption of the internet for business communication, SOA Gateways will pave the way to the adoption of cloud computing for the next generation of business communication.

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.