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.