Reducing the Complexity of Application Security

Integration is the Enemy of Security and so is Flexibility - an attribute that is essential for organizations to survive.  A corporation that cannot service its customers and suppliers, establish long sticky relationships with them and build an infrastruture that enables rapid addition of both suppliers, buyers and partners for information exchange will perish and get demolished by a nimble and flexible competitor whose infrastructure has integration capabilities for rapid information exchange.

Mike Vizard from CTOEdge talks about the business drivers that compel companies to integrate yet face security challenges that hamper integration efforts: Reducing the Complexity of Application Security

Here's a snippet from Mike's article:

"As business-to-business interactions over the Web become more pervasive, so too does the complexity associated with securing those transactions.

Unfortunately, all that complexity serves only to dissuade businesses from integrating business processes across the Web at a time when we want to encourage that behavior. So the challenge facing chief technologists is to find a way to make it simpler to integrate business processes without having to introduce complex layers of security."

Key components that help reduce (and improve) application security include:

1. Strong SOA Governance Enforecement, Monitoring and Security through XML Gateway such as Forum Sentry.
2. Portal and Web services Authentication and Authorization decisions through Secure Token Services such as Forum Sentry STS - Identity Broker.
3. Application Security Testing and Simulation through products such as SOAPSonar and SOAPSimulator for Identity, Privacy, Integrity and Penetration Testing.

Forum Systems latest XML Gateway targets SOA Federation

Looks like Forum Sentry, the pioneer and leader of XML Gateway and XML Firewall technology has announced its latest product that now addresses the growing need for handling not just XML/Web services traffic, but also HTML/Portal traffic. From a technology standpoint, this is not a revolutionary jump, but a gradual evolution of the XML Gateway that now handles HTTP/HTML-header information, which is by far easier than looking deeper into the XML packets. However, the business implication of this is significant since companies can now use a single platform for HTML and XML processing.

Continuing to set the benchmark for securing Web services, key new capabilities available via Forum Sentry include:

• HTML Portal Virtualization – Deployed in a “proxy” setting, Forum Sentry removes the identity and security burden from Web sites and portals. Leveraging Single Sign On (SSO) functionality across existing infrastructures, Forum Sentry’s non-intrusive, agentless design accelerates security and identity on a dedicated device – without requiring code changes to backend Web applications and services, or additional capital expenditure costs.
• Central Cookie and SAML Processing – Forum Sentry authenticates and authorizes both portal- and Web services-related identity tokens – the cornerstones of Federated SOA. Credentials are shared – regardless of where the services reside – throughout the entire transaction, producing an enhanced, seamless user experience without compromising security.
• Federated Two-Factor Authentication – Promoting greater security, Forum Sentry requires two pieces of information for identity verification of internal and external partners. It removes the complexities so often associated with token sharing across portals and Web services, while still enforcing the highest levels of authentication and authorization.
• Protocol/Document Attribute Mapping – Promoting greater ease of use, HTTP/HTML header information can be mapped into messages and documents. User information from HTTP can be transferred into a SOAP or XML message for usage elsewhere in the network – independent of protocol – enabling SOA Federation across both XML and HTML traffic.

For more details, see: Forum Systems Drives SOA Federation for Enterprises and Government Organizations

XML Flaws are Pervasive

Finally! What companies such as Forum Systems pioneered a defensive layer for through its XML Gateway product, Forum Sentry, and Crosscheck Networks invented for identifying XML Security vulnerabilities thorough its XML/SOAP pen testing product, SOAPSonar is now becoming mainstream.

Washington Post published an interesting article highlighting such XML-based vulnerabilities in a recent article titled XML Flaws are pervasive. This article highlights issues that Forum Systems introduced in early 2004. See white paper titled "Anatomy of a Web Services Attack." This paper cements Forum Systems as the pioneer in identifying a new class of security vulnerabilities exposed via XML/SOAP/WSDL-based technologies.

http://voices.washingtonpost.com/securityfix/2009/08/researchers_xml_security_flaw.html

Qualifying your XML Gateway Horsepower

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 XML Gateway community is not immune to this indulgence. I have to admit, even I am guilty of committing this sin sometimes.

In the XML 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, XML 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 XML Gateway is schema validation. This task validates the the structure of incoming and outgoing SOAP/XML messages. The performance of a XML 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 XML Gateway.

Frequent XML Gateway Uses

XML Gateways are becoming standard in enterprise SOA deployments with the following common themes:

1. Identity mediation is the first step for the majority of SOA Deployments. Identities come in may shapes and sizes represented at both the protocol level (e.g., HTTP Basic Auth, SSL Mutual Auth) and message level (WS-Security tokens X.509, SAML, etc.). Even if an enterprise successfully standardizes on a single identity representation, it cannot dictate how it's trading partners should represent its identities. Thus, inditites need to be accepted in many forms and changed to a single internal representation - that is if everyone within an organization can agree to a standardized representation. Most likely, even internally, more than one identity representation exists.
2. XML Firewalling is essential to ensure that information is checked before it makes it to the back end application server. The XML should be clean so that the backend server can safely process the message. Even more significant is the need to ensure that the SOA Gateway checks for information leaking from the corporation. This includes preventing sensitive information such as Credit Card Holder information from being compromised, as mandated by the PCI Security Standards Council.
3. Data Integrity and Privacy using content based signatures and encryption ensures that the message is not tampered with and that any part of the message can be encrypted granularly using standards such as WS-Security.

Other items such as Data Mediation, enrichment, transformation and archiving are also commonly enabled in a XML Gateway deployment.

Why is an XML Gateway a requirement?

The main two reasons to justify the capital expense of an XML Gateway 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 needs 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.

Such use cases can be readily handled with an XML Gateway fronting all the security aspects: SSL termination, signature verification or any other security requirement. The XML 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 up-to-date 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.

XML Gateway Patent

Forum Systems, the pioneer in 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.

XML Gateway: Best Practices, Requirements and deployment Strategies

XML Gateways are a great IT component for managing information flow between your enterprise and your trading partners.  They provide the required functionality, such as:

• Identity bridging (e.g., from HTTP Basic Auth to SAML)
• Transport mediation (e.g., between HTTP and MQ Series)
• Protocol and content based security (e.g., HTTPS, WS-Signatures, WS-Encryption)
• Message inspection (e.g., for SQL Injection, Viruses, and other malware)
  
• Interface Virtualization
• Transformation, Schema Validation

Such functions make is easy and cost effective for enterprises to integrate with their trading partners is a secure manner.  Here's a good article for best practices using XML-Gateways.

http://forumsys.com/resources/resources/whitepapers/Best_Practices_in_Deploying_SOA_Gateways.html

XML Gateways: Reducing the inherent Cost of Security

Dennis Sosnoski, Consultant and Trainer, Sosnoski Software Solutions, Inc. published an informative article titled: "Java Web Services: The high-cost of (WS-) Security." In the article Dennis compares performance profiles of different security configuration including SSL, username, signatures, encryption and sign-encryption. The tests are conducted using Axis2 version 1.5 with a Rampart code that provides content-level security.

The data clearly shows the overhead associated with security operations. Dennis later describes part of the reasons for the drop in performance is owed to the "Rampart handler implementation, which causes it to convert each request and response message to Document Object Model (DOM) form any time Rampart is engaged." This fact highlights one of the classic reasons for deploying XML Gateways (such as Forum Sentry): specialized commercial parsers designed for performance and security are better suited for security functions compared to java containers with general purpose parsers. Forum Sentry, as an example, has a ground-up parser designed for on-demand intelligent parsing of SOAP and XML messages without any redundant parsing. The security operations are deeply integrated with hardware cryptography. Based on almost a decade of customer installation, we have seen a 16-to-1 ratio between application servers and XML Gateway latency.

Dennis poignantly states:

"Another way of cutting the performance cost of WS-Security is to offload the security processing onto specialized hardware. Some XML gateway appliances provide accelerated processing of WS-Security encryption and signatures. You can use these appliances to handle the heavy-duty WS-Security processing while working with plain SOAP in your application. You obviously need to make sure you don't open any potential security holes in adding an appliance to your server. And you should test the performance gains from the appliance before you purchase. But at least in theory, this type of arrangement can offer some real performance gains."

XML Gateway - Load balancing Techniques

As an XML Gateway, Forum Sentry sits in front of your SOAP/XML/REST Web services protecting back-end services. For externally facing services (traffic comes in from outside your network), Sentry is responsible for handling all incoming XML traffic sent from your trading partner's client applications and destined for your services. Sentry processes these incoming requests and then sends them along to the back-end service (the remote server).

Often times the Forum Sentry gateway resides behind network load balancers which distribute the incoming requests among multiple Forum Sentry appliances. The load balancers ahead of Sentry allow for redundancy and increased throughput.  Forum Sentry,  also includes support for load balancing requests to multiple remote servers. The strategies are broken into two categories: Passive Load Balancing Strategies and Adaptive Load Balancing Strategies. Below is a quick summary of each.

Passive Load Balancing Strategies

Passive strategies choose a Remote policy without reference to the traffic passing through the system.

• Failover - Uses the order of the configured Remote policies in the group to signify priority. Always chooses the first Remote policy from the list of eligible Remote policies unless it is disabled or inaccessible, in which case it moves to the second, etc.
  
• Round Robin - Initially chooses an eligible Remote policy at random and then rotates through the list of eligible Remote policies in order, choosing the next eligible Remote policy for each new client request.
  
• Random - Chooses an eligible Remote policy at random for each new client request.
  
• Weighted Random - Chooses an eligible Remote policy at random for each new client
  request, using the relative weights configured for each Remote policy. The configured weights set the relative odds that each Remote policy will be selected if eligible.
  

Adaptive Load Balancing Strategies

Adaptive strategies gather statistics about current and past traffic passing through the system and choose a remote server based on the traffic patterns.

• Transfer Throughput - Chooses the highest performing eligible Remote policy. Performance is measured by the average transfer throughput of the last 100 requests, in bits per second.
  
• Active Requests - Chooses the eligible Remote policy which is the least busy, based on the number of concurrent requests the Remote policy is servicing.
  
• Response Time - Chooses the highest performing eligible Remote policy, measuring
  performance by the average response time of the last 100 requests. The Response Time strategy chooses the Remote policy with the lowest average response time.
  

XML Gateways, such as Forum Sentry are required to have sophisticated, flexible and dynamic load balancing capabilities within a corporate network.  Without such capabilities, scaling an XML/Web Services deployment becomes problematic.  A large number of non-XML, packet-based Load balancers are then used to work around the short comings of XML Gateways that lack sophisticated, content-based load balancing schemes.

Is Your XML Gateway Secure? Advantages of a Certified XML Gateway

An XML device or application that provides security functions does not mean that the solution itself is secure. A secure XML hardware device requires a properly designed architecture, precise algorithm implementation, secure key storage, encrypted policy data, and a secure API. While most anyone could claim these features, independent certification with security agencies such as NIST and DoD provide the unbiased analysis of these security requirements.

The Podcast below discusses in detail why FIPS and DoD Certification are essential for XML security hardware such as XML Gateways, and the distinct advantages over non certified devices, including the following areas:

• XML device PKI private key compromise protection
• SSL ciphers and XML security
• Secure policy data storage
• X509 authentication with CRL and parent chain signature verification
• Physical hardware integrity

To view the podcast, click here.