Heartbleed OpenSSL Vulnerability

Here we go again, another huge vulnerability exploit detected in open source security software:

Massive Security Bug In OpenSSL Could Affect A Huge Chunk Of The Internet

The latest heartbleed OpenSSL vulnerability (CVE-2014-0160) is again a re-affirmation that using non-certified security modules for enterprise security is a really bad idea.  You can be certain that every IT security guy out there felt that they were doing all the right things to secure the enterprise.  The problem isn't the intent or implementation, the problem is the premise. You can't rely on integration platforms that have security add-ons for your enterprise risk mitigation. 

This is yet another day where Forum Sentry customers can revel in their decision to go with a industry-proven, independently certified, secure product.  Every system that is deployed behind Forum Sentry API gateway is secure, and none are susceptible to any OpenSSL vulnerabilities because Forum Sentry does not use OpenSSL for SSL or encryption.  Rather, Forum Sentry uses FIPS 140-2 and NDPP certified technology to provide the SSL and cryptographic features. 

There is a huge difference between "an integration device with security features" (hey CA, IBM, and Intel, are your ears ringing??) and "a security device with integration features" purpose built per Forum Sentry API Security Gateway.

It's not often that risk mitigation can be easily monetized as it takes a breach to truly represent the impact of lost passwords, lost keys, and lost trust.   Today that is on display in dramatic form, but Forum Sentry customers can simply relax and enjoy the security.

The Differences Between an XML Gateway and a Web Application Firewall

Jason Macy, CTO  

Forum Systems, Inc

Introduction

A common industry misconception is understanding the differences between an XML Gateway and a Web Application Firewall.   These technologies are sometimes confused as being competitive, but in fact they are complementary technologies that together provider the foundation of modern-day network perimeter security infrastructure.

Key Areas of Comparison

To better understand the distinctions between these product technologies, the primary areas of comparison are as follows:

Topology

• Deployment Modes

Protocols and Message Formats

• Standards
• Protocols

Security

• Threat Mitigation
• Transaction Privacy
• Transaction Integrity

Identity

• Access Control
• SSO

Transaction Processing and Mediation

• Workflow
• Transformation / Mapping

WAF Topology

WAF technology has several deployment modes, but it is an important distinction from a gateway product that over 50% of WAF deployments are in non-inline mode, also known as passive mode.   The modes of deployment are:

• Non-Inline Mode (50% of deployments)
• Transparent Proxy
• Layer 2 Bridge
• Reverse Proxy

XML Gateway Topology

XML Gateways are always deployed in a reverse-proxy configuration where the gateway component terminates the connection and provides the security, identity, governance, and mediation functions at TCP Layer 4-7.  The reverse-proxy deployment paradigm is necessary since XML Gateways serve as a protocol break intermediary for traffic flow and have the ability to restrict and block traffic flow as needed.  Thus, the mode of deployment for XML Gateway is always:

• Reverse Proxy
• Service Mode (Request/Response directly to Gateway, which performs the business function)

Protocols and Message Formats

A WAF product focuses on different set of protocols and message formats than an XML Gateway technology product.   This follows the logical expectation based on what types of systems and infrastructure these technology products focus on. 

A WAF focuses on the following technologies:

WAF Standards

• Web 2.0, HTML, XML, JSON, AJAX

WAF Protocols

• HTTP, HTTPS
• SSL / TLS

XML Gateway technology needs to have a much more comprehensive set of technology standards and formats it supports since it is an inline deployment which requires the need to bridge technology protocols and messaging standards in order to be the "gateway" conduit of message flow. 

XML Gateway Standards

• XHTML, XML, SOAP,  JSON, AS2, XML-Sec, WS-Sec, WSDL, XSD,
• ebXML, SAML, OAuth, WS-Federation, WS-Trust, XACML
• WS-Addressing, WS-RM, WS-Policy, Xpath, XSLT

XML Gateway Protocols

•     HTTP, HTTPS
•     SSL / TLS
•     JMS (IBM, Tibco, JBoss, Oracle, Active MQ)
•     AMQP
•     FTP/FTPS
•     SFTP
•     SMTP

Security
As WAF and XML Gateway products are both security products by trade, there are 3 primary areas of Security that these technology target.

1. Threat Mitigation
2. Transaction Privacy
3. Transaction Integrity

Security: Threat Mitigation
Threat mitigation is the ability to identify, detect, and re-mediate potential threat vectors in the traffic patterns.

A WAF product mostly focuses on HTML and HTTP based traffic paradigms whereby vendor specific static vulnerability patterns can be detected, as well as other aspects of request/response patterns pertaining to HTTP traffic flow.  The primary vectors for threat mitigation for WAF technology:

• HTML Content Aware
• Intrusion Detection and Prevention (URI patterns)
• URI rate-based heuristics
• Vendor Vulnerabilities
• URL cloaking / rewrite
• Parameter Inspection
• Learning mode (false positive / false negative behavior modeling)

  An XML Gateway performs deep-content inspection and parsing of the messages at the application layer of the message pattern.  Since an XML Gateway is a protocol-break intermediary, it consumes the message, inspects the contents, and then re-assembles for sending to the back-end service infrastructure.  This puts a much higher technology burden on XML Gateway technology to understand and be able to parse a much broader variety of protocols and message formats as well as ensure adherence to industry messaging standards and formats.

The primary vectors for threat mitigation for XML Gateway technology are:

• XML/SOAP/REST Content Aware
• Intrusion Detection and Prevention (parsing and deep-inspection)
• Rate-based, Size-Based heuristics
• Schema Validation
• Virus detection on XML/SOAP payloads
• URL cloaking / rewrite
• XML Parser Attacks

Security: Transaction Integrity
Threat integrity is the ability to ensure conformance can be verified and tampering has not occurred.

A WAF will target the transaction integrity as it pertains to cookies, jsp files, RFC conformance, and other aspects of HTTP and HTML request/response expectations.  The transaction integrity targets of a WAF are:

• Session Tracking
• Cookies, Source/Dest IPs
• HTTP RFC conformance
• HTML Form parameter checking
• Cross-Site Scripting
• Cookie Signing

An XML Gateway deals with more aspects of transaction integrity since it also has to be able to handle cryptography at the message level and be able to process and verify digital signatures and provide conformance checks across a broader spectrum of formats.

XML Gateway transaction integrity features include:

• XML-DSIG, OASIS WS-Security
• Signature Verification
• X509 Path Validation
• DTD Schema Validation
• XSD Schema Validation
• JSON Schema Validation
• HTTP RFC Conformance
• JMS Envelope and Message Conformance

Identity
Identity and Access Control are central requirements for any service-based architecture with consumers and services.  It is also essential for portals and other access to information that may be sensitive or controlled.  WAF technology generally does not deal with identity, but does have some lightweight features in this area. 

The core differences between a WAF and an XML Gateway in this area are broad.  A WAF does not have awareness of many of the identity token formats outside of traditional web and HTTP based formats.

WAF: Native Identity Integrations
    Active Directory, LDAP, RADIUS

WAF: Protocol Tokens
    Basic, Digest, Form Post, SSL X509, NTLM, Kerberos


XML Gateway technology conversely, is heavily dedicated to identity token consumption, generation, authentication, and authorization.  By necessity of the deployment and flow control paradigm of XML Gateway technology, the protocol break interception for security and mediation also becomes the logical point of centralizing the identity enforcement and single-sign on functionality.


XML Gateway: Identity Integrations
   Active Directory, LDAP, Siteminder, Tivoli AM, ClearTrust, Kerberos KDC, CoreID,
   JSAM, WS-Trust, XACML, OAuth

XML Gateway: Message-Based Tokens
     WS-Username, WS-Kerberos, WS-X509, SAML, DSIG

XML Gateway: Protocol Tokens
    Basic, Digest, Form Post,  Cookie, SSL     X509, REST URI, NTLM, Kerberos

XML Gateway: Credential Translation
    Message-to-Protocol, Protocol-to-Message

XML Gateway: SSO + Federation
    Sessions, SAML, STS


Processing, Mediation, and Workflow
An area of stark difference between an XML Gateway and a WAF is in the arena of mediation, transaction manipulation, and workflow routing.  This is again a primary difference due to the topology and deployment paradigms.  Deploying a WAF in passive mode (over 50% of deployments) does not have any ability to manipulate or alter the traffic data.   For the small percentage of WAF deployments that are in-line, the types of traffic that can be manipulated are effectively the HTML variants.

XML Gateway technology is designed specifically to consume the message, parse the message, apply mediation, enrichment, transformations, and finally determine the end-point target based on static or dynamic criteria.  Thus, the XML Gateway technology component is often used to perform a wide variety of business functions outside of pure security processing.

For WAF technology, when deployed in in-line mode, the processing and mediation that can be enforced focuses on the following areas:

WAF: Workflow Management

• Allow/Deny
• URL Rewrite
• Compression
• Content Replacement

For XML Gateway technology (always deployed in-line), the processing and mediation that can be enforced goes across a wide diversity of application payload formats and protocol variants across the following areas:

XML Gateway: Workflow Management

• Attribute Mapping
• Archiving
• Content-Based Routing                  
• Database Mapping
• Digital Signatures
• Header and Body Identification
• Identity Token Conversion
• Enrichment Data Aggregation
• Encryption
• Node Conversion and Encoding
• Transformation

Complimentary, not Competitive
A robust, resilient, secure architecture starts by ensuring the right technology components are in place.  WAF technology serves an essential role in the threat and access control side of web application traffic flows.  XML Gateway technology serves an essential role in the security, identity, governance, and mediation of business services, mobile devices, B2B flows, XML, SOAP, and REST messaging patterns with deep-content inspection and business-logic mediation.   A WAF and an XML Gateway are fundamental components of a secure, centralized architecture strategy.  These technology components focus on the TCP Layer 4-7 aspects of transaction, which comprise a much broader spectrum of the actual information flow across the corporate boundaries.

These components should be deployed where traditional Protocol Firewalls and IDS (Intrusion Detection Systems) are deployed, which provide the TCP Layer 2-3 protection.

Bottom line:
WAF + XML Gateway = Secure Architecture

Is REST remaking SOA? Gateways add features

Jack Vaughan interviewed Mamoon Yunus, CEO of Crosscheck Networks, at the Gartner AADI Event regarding prevalent deployment scenarios for SOA/XML Gateways (e.g., Forum Sentry), specifically on how Mobile Computing is being enabled using through gateway technologies.

Here is an excerpt from the interview:

It was all a bit of a whirl when we caught up with Mamoon Yunus, CEO of Crosscheck Networks, at a Gartner event in December. The topic on the docket then has more momentum today. So we decided to revisit our notes and share this take on strong-walled SOA gateways, lightweight SOA, REST and mobile applications. –J. Vaughan, site editor.

SearchSOA: How is SOA today relating to new interest in REST and mobile application building? 

Mamoon Yunus: Primarily what we're seeing is that companies have invested a lot in building a SOA infrastructure and now they're extending that through various channels to mobile computing, more lightweight applications—whether it's on an iPad or whether it's on a Smartphone. Because of that, they need to use lighter weight protocols such as REST while still leveraging the investment that they've made in the enterprise using SOA, more reliable, secure communication.

For full interview, please visit: Is REST remaking SOA? Gateways add features 

IBM DataPower vs. Forum Sentry

Mark Bakker from Xebia -- a specialized international IT consultancy focusing on Enterprise Java -- published an interesting overview of IBM DataPower Security Gateway and Forum Sentry.  Mark writes:

"The Forum sentry has some advantages when you compare it to the IBM Datapower XML Security Gateway XS40. The main difference is that you can do more whith only one appliance. You can replace an IBM Webseal, a virus scanner and an IBM Datapower XS40 with only one device.
My advice is to take this device in considerations where you have to choose for an XML firewall/ hardware ESB."

For full article, see: http://blog.xebia.com/2011/03/15/forum-sentry-xml-gateway/

XML Security Gateway plugging holes for Public Clouds

Recently, there has been a flurry of news emanating from the XML security world related to researchers demonstrating an attack on Amazon's AWS cloud management interface. The attack takes advantage of a well known exploit known as XML signature wrapping or XML signature manipulation.

Amazon since the publication of this paper has plugged the security hole in its interface. It is a labor intensive effort to plug these holes that requires constant monitoring especially when cloud service interfaces are public facing. Risk can be more easily mitigated by a deployment of an XML security gateway without requiring custom code changes.

An XML security gateway prevents exploit like these in several ways. The XML gateway primary defense against this type of signature manipulation is via signed element verification. In the Amazon scenario, an XML gateway would verify that the soap:Body and wsu:Timestamp elements were processed during signature verification. A secure XML gateway verifies by checking the actual elements, not the Id attributes. This type of secure verification is the default behavior for XML gateways such as Forum Sentry.

XML security gateway's WSDL validation would also prevent the duplicate soap:Body and wsu:Timestamp elements used in this exploit. Such schema validation is important, but it is not a substitute for signed element verification, because there are alternate places to hide arbitrary content in most schema.

Amazon mistakenly assumed that ID attributes mapped to only one element without enforcing the ID uniqueness constraint. When Amazon verified that the soap:Body and wsu:Timestamp were signed, they only checked whether a matching ID was referenced in a signature, not whether signature verification actually processed all the intended elements, a subtle but important distinction. Amazon's use of signed ID verification instead of signed element verification could also allow additional exploits not mentioned here. Amazon also neglected to check for multiple soap:Body and wsu:Timestamp elements, but that is a lesser security flaw. These flaws could be the result of a misguided attempt to optimize performance by inspecting only initial portions of the document during certain security processing phases.

This specific signature exploit and other critical flaws are well-known and common in do-it-yourself security implementations, so it's essential for companies like Amazon to leverage proven security solutions and partners. These exploits indicate an apparent lack of gateway protection that could make Amazon a popular target for new exploits. Perhaps Amazon has already been the target of other undisclosed exploits. And just imagine how many other companies are hosting sensitive services without adequate gateway protection. Amazon and other web service providers need a viable commercial security strategy, and customers should expect real protection for their sensitive data and infrastructure.

Managed File Transfer belongs under SOA Governance umbrella.

Jack Vaughan's recent article covers an important emerging trend: convergence between SOA and MFT technologies. Managed File Transfer (MFT) is a baseline mechanism for information movement within and across corporations using legacy protocols such as FTP. However, with the emergence of modern SOA-related protocols, companies are now migrating away from less secure and less reliable MFT transport protocols. This trend is also driven by regulatory requirements including PCI, HIPPA, and GLB

Link to Jack's article: Updated XML gateway brings FTP under SOA Governance umbrella.

Excerpt from the article:

Despite SOAP and SOA inroads, the vaunted File Transfer Protocol (FTP) continues to flourish in organizations that - not surprisingly – need to transfer files. Finance and banking both represent FTP bastions – although both sectors are also on their way to becoming SOA strongholds of sorts.

Bringing FTP - originated in the 1970s - under the general umbrella of governance is an eventual goal for many of these companies. Forum Systems, a Crosscheck Networks' subsidiary, seeks to support such efforts with a recent update to the Forum Sentry Gateway.

The latest version of the gateway offers content-level security for structured and unstructured data for documents of unlimited size using the OpenPGP standard, while also enabling message transfers over a variety of secured and unsecured transport protocols. Moreover, the software allows organizations to plan migrations from batch FTP processing to SOAP with Attachments (SwA)(MIME, DIME, MTOM), while using existing centralized governance policies across both legacy and modern message formats.

Evolving from Static HTML to Dynamic Portals: Security Implications

Companies that deploy websites with static HTML content typically use Web Application Firewalls (WAFs) to protect their static HTML content. With the proliferation of social media-type interaction via browsers and mobile devices, corporate portals are evolving from a "Refresh-mode" to "Widget-mode" portals that integrate disparate company systems into a unified customer portal. Each widget may be an independent unit with its own data feeds and update intervals. The rapid evolution of static HTML websites to dynamic web portals that function as composite applications could not be more evident in the banking applications that we are are now accustomed to. The security implication of dynamic portals is primarily driven by the following factors:

1. Content Complexity:  HTML, XML, SOAP, JSON, MTOM, SwA, PDFs, GIFS, JPEGS are a few of the content types that are generated and consumed by web portals.
2. Identity Diversity:  From simple cookies to signed SAML tokens, web portals have to handle a plethora of token types and provide Federated Identity capabilities for single sign on.
3. Malware Matrixing:  A matrixed set of channels via different content types are now available for malware to make its way into the enterprise.  For example, in the static HTML days, SQL Injection could come over HTML data, but now can readily move over XML.

Forum Systems, the only patented XML Gateway in the industry, has now extended its technology leadership by addressing security for dynamic web portals with the announcement of Forum Sentry WAF at Infosec UK, 2011.  For details, see Forum Sentry WAF.

For product announcement, see: Forum Systems delivers Industry's First Unified Content Firewall.

Cisco ACE gateway EOL: How to Pick a Replacement XML Gateway

It's official:  Cisco has published End-of-Life announcements for it's Cisco ACE XML Gateway.  Here are the top factors that end customers must consider in making replacement decisions:

1. Select a Patented Product:  Going with non-patented XML Gateway means that customers will have to replace their XML Gateways in the future yet again.  Customers tend to select innovative and leading technology providers with defensible Intellectual Property (IP).  They prefer to minimize their risk by avoiding trailing "me-too" technologies that continue to copy the leading patented XML Gateways.
• Conclusion:  Ask for vendors patents.  Forum Sentry is the only XML Gateway Appliance with a published patent (Patent #7,516,333).
2. Understand XML Gateway vs. ESB:  Would you add custom code to your network packet firewall?  Then why would you ever consider adding custom code to your XML Gateway?  A clear separation of roles should be enforced between an XML Gateway and an ESB/Application Server.  When replacing Cisco ACE XML Gateway, focus on security.  Let the ESBs and Application Servers run your custom code.  If you choose an XML Gateway that allows you to drop jar files, shared objects or any arbitrary code into its runtime environment, then you have selected and XML Gateway with a flawed security model.  Such XML Gateway architectures can make you feel safe while compromising your corporate infrastructure, especially your sensitive data.
• Conclusion: Review vendors' XML Gateway architecture before replacing the Cisco ACE Gateway.  Don't make the same mistake twice.  Cisco's architecture permitted dropping code on the Gateway that resulted in a poor security model.  Other XML Gateway vendors have followed Cisco's XML Gateway architecture that permits adding custom code.  IBM DataPower and Forum Sentry are the only products that do not permit arbitrary code to be dropped into their XML Gateways and stay true to the XML Gateway roles.
3. Demand Independent Security Assessment:  XML Gateways are typically deployed close to the corporate boundary and serve as a centralized conduit for information exchange between corporations and their trading partners.  The nature, volume, and value of transactions flowing through the XML Gateway requires a high degree of security and reliability.
• Conclusion: Review vendors independent security assessment.  FIPS 140-2 is the gold standard for independent security assessment.  Demand certification details from vendors.  Sticking an HSM crypto card into a hardware appliance and claiming FIPS certification is not sufficient.  The ENTIRE XML Gateway, not just the HSM crypto card should be FIPS 104-2 certified.  For any other certification, ask for the "boundary" of certification.  Most vendors have never subjected their entire XML Gateway Appliance to an independent security evaluation.  Forum Sentry is the only product in the industry to have achieved FIP 140-2 security certification across the entire hardware boundary.
4. Validate Comparable Features:  Migration of your policies from the Cisco ACE Gateway to the replacement XML Gateway should be seamless.  The selected XML Gateway should be architected with modular policy design for fundamental constructs such as Keys, Encryption/Signature Policies, Firewall rules can be readily moved from the ACE Gateway to the selected replacement platform.  The selected gateway should have the same or better functionality than Cisco ACE Gateway.
• Conclusion: Selecting patented, industry-leading XML Gateway is paramount.  This ensures that there are no functional gaps between existing and replacement products.  XML Gateway companies that continue to innovate and patent their IP are more sustainable and provide broader features than vendors that follow the leaders.
5. Replacement Costs:  For corporations that have made a bet on technology that has been EOLed, there are a number of costs including: i) Product Cost ii) Configuration Cost iii) Transition Costs. iv) On-going support and maintenance costs.  Replacement vendors should have flexible pricing models to accommodate your corporate EOL plan.
• Conclusion: Select vendors that can work within your budget and time-lines. Vendors should be flexible in reducing your CapEX expense while working with your planned multi-year support and maintenance budgets. Depending on the complexity of your policies, vendors should be open to helping you with your migration costs.  For a duration, you may be required to run both Cisco ACE and your new XML Gateway together while you migrate away from the ACE Gateway.  Your selected XML Gateway vendor should provide pricing options to accommodate this transition process.

XML Gateways are essential components of corporate infrastructure.  Choosing the right vendor initially or for replacement should be a rigorous and methodical process based on key factors as listed above.  Without this rigor, corporations may to choose inferior technology that, in the future, will have to be replaced yet again.

Next Generation of patented XML Gateway - Forum Sentry v8.0 - announced in Berlin, Germany

New Capabilities for Company's Flagship XML Gateway Ease Enterprise-to-Cloud Migration; Enable Seamless Extension of SOA to the Cloud

BOSTON and BERLIN, Oct. 5 /PRNewswire/ -- Crosscheck Networks, Inc. today introduced the next generation of its flagship product, Forum Sentry v8.0, helping organizations seamlessly migrate their enterprise SOA deployments to the cloud while capitalizing on the cloud computing model for business and competitive advantage. The company unveiled the latest version of Forum Sentry at the International SOA & Cloud Symposium, the world's largest international SOA and cloud computing conference.

Notably, at the show today, Crosscheck Networks (Booth # 13) CEO Mamoon Yunus will explore enterprise-to-cloud migration in the session, "Requirements for Extending Enterprise SOA to Public Clouds." Additionally, company CTO Jason Macy will share best practices in SOA threat defense in "SOA Threat Modelling: Attacking and Defending REST, XML and SOAP based Services."

With patented XML security acceleration technology and an architecture certified by NIST and the U.S. Department of Defense, the Forum Sentry XML Gateway is the industry standard for XML and SOAP security, access control and integration. Deployment highlights include processing:

• More than one billion transactions per day globally;
• 95% of the world's credit card information; and
• 80% of the traffic at one of the world's largest and most respected telecommunications services companies.

Underscoring its increasing adoption worldwide, Forum Sentry serves as the transactional foundation at more than 300 global organizations including:

• One of world's premier treasuries, which leverages Forum Sentry to accommodate the increased volume, and processing, of large data files -- up to 10 GB each in size;
• Europe's top counter-terrorism organization, which utilizes Forum Sentry to coordinate rapid information sharing among its neighbor countries; and
• One of the U.S.'s longest-standing and largest health benefits companies, which uses Forum Sentry to promote secure exchange of its Electronic Health Records (EHR).

According to Lydia Leong, Research VP, Gartner, "Although many organizations first look at cloud IaaS [Infrastructure as a Service] because they're interested in cost savings, agility and flexibility, rather than cost, tend to be the eventual primary drivers; the cost of the cloud IaaS, especially in comparison to efficient large-enterprise IT, can be higher than IT managers expect."(1)

"As organizations scale their infrastructures to accommodate rapid business growth and increased customer demand, they are frequently looking to the public cloud to help them offset capital expense and operational costs. But without the appropriate tools, businesses are unable to determine the true costs of cloud migration," said Crosscheck Networks CEO Mamoon Yunus. "With our simulation tool, CloudPort, we enable enterprises and government entities to perform the requisite cost analysis, and evaluate and select a provider for migrating all or parts of their infrastructure to the cloud."

Yunus continued: "Once organizations determine that moving to the public cloud makes business and fiscal sense, Forum Sentry's next-generation platform empowers them to take the next step -- migrating to the cloud cost effectively while securely extending their SOA deployments for the most seamless enterprise-to-cloud integration."

Helping organizations to successfully leverage the cloud computing model, key new capabilities in Forum Sentry v8.0 include:

• Integrated Cloud Adaptors for dynamic provisioning, auto scaling and load balancing across multiple cloud providers including Amazon EC2, OpSource Cloud, GoGrid and Rackspace.
• A Centralized WSDL Library and Extended Virtualization Support via Virtual WSDL and WSDL Versioning for increased collaboration and control of business services across diverse application development, security and testing roles.
• A Robust Management API for enhanced policy life cycle management, and secure, versatile cloud configuration, deployment and administration.
• Oracle WebLogic and JBoss Enterprise Middleware Adaptors to bolster federated SOA deployments. This support builds on Crosscheck Networks', a Red Hat Ready Partner, announcement earlier this year that the company has joined the Red Hat Independent Software Vendors (ISV) Partner Program.
• REST Identity Adaptor for flexible integration with custom enterprise identity systems.

About Crosscheck Networks

Crosscheck Networks and its wholly owned subsidiary Forum Systems deliver solutions for deploying robust, resilient, secure and reliable Service Oriented Architecture (SOA). More than 50,000 users in 42 countries across organizations such as the U.S. Treasury, British Telecommunications, Fidelity, Premera Blue Cross and the Dutch Health Care System rely on Crosscheck Networks and Forum Systems as the backbone of their secure transaction processing. Recognized as a technology innovator and security leader, Crosscheck Networks is the only company granted a patent for its Forum Sentry XML Gateway and has been certified by NIST and the U.S. Department of Defense. Forum Sentry is the de facto standard for XML and SOAP security, and Forum Systems has key OEM relationships with Barracuda Networks and Radware, among others. For more information, please visit www.crosschecknet.com.
(1) Gartner, "Cloud Infrastructure as a Service: An Essential Overview" by Lydia Leong, September 8, 2010

XML Gateway Myths

There are some common XML Gateway myths that this post would like to dispel. These myths are a manifestation of vendors overwhelming the customers with the latest bells and whistles of their product without explaining to the user fundamental basic capabilities of the product.

Myth #1: FTP protocol is only used to transfer unstructured bulk data to our back end systems.

FTP (File Transport Protocol) is the workhorse protocol that is still used today for majority bulk file transfers between enterprise corporations. FTP maybe a legacy protocol, but this legacy protocol is one of the most reliable and interoperable file transfer protocols available today to businesses. FTP can be used not only to transfer unstructured data but it can also be used to transfer SOAP or XML data between various different systems. An XML Gateway provides the capability to support XML data transfers over FTP for inbound or outbound traffic. Alternatively, an XML Gateway provides the means to protocol mix between FTP and HTTP protocol. For example, an incoming HTTP protocol carrying XML can be transformed into an FTP protocol carrying XML data or vice versa.

Myth #2: We don't need to virus scan SOAP with attachments since we have a virus scanner deployed at the edge.

This notion that a virus scanner can take any incoming raw file at the edge of the network before sending it to the back end is sufficient for processing SOAP with attachments provides a false sense of security. First, most SOAP/XML incoming traffic from the internet is SSL enabled. A virus scanner at the edge is not capable of peering into the encrypted data that is being sent to the back end application servers. Second, even if the SSL traffic is being decrypted at the edge, it is possible that SOAP with attachments might be encrypted or Base64 encoded thus rendering a edge virus scanner ineffective. An XML gateway provides the capabilities to terminate SSL connections, perform content-level decryption, and decode attachments for on board virus scanning.

Myth #3: XML Gateways cannot handle non-XML requests for authentication and authorization.

XML gateways always had strong integration capabilities with traditional identity management systems. Authentication and authorization of inbound SOAP or XML traffic is one of the strongest pillars of an XML Gateway. Given the tie in with traditional identity management systems, XML Gateways are no longer relegated to authenticating and authorizing XML traffic only. An XML Gateway today has the same capabilities to authenticate and authorize non-XML data that one would find in a software web agent installed in a Microsoft IIs or an Apache server. In fact, XML gateways make it easier for enterprise users to manage the authentication and authorization of XML and non-XML (HTML) requests on a single gateway.

Enterprise customers that are deploying Service-Oriented Architecture (SOA) using XML web services should be cognizant of these myths. An XML Gateway provides rich functionality that extends its capabilities beyond traditional web services XML integration use cases.

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.