The Value of Application Logic in SSL VPN Gateways
Q1 – Defining Application Awareness Dana: Noam, Whale uses the phrase “Application Awareness™” when referring to some of the capabilities of its SSL VPN Gateway.Can you provide our readers a clear definition of what Whale means by this phrase in the context of SSL VPN gateways? Noam: Application aware technology enables an SSL VPN to understand how applications work in order to connect and secure them. At a technical level, Whale is simply referring to the addition of application-specific logic either to the remote access gateway or, in the case of non-web applications, to the client. When a gateway can examine the traffic of individual applications, it can perform a wide range of functions that depend on both the inspection and control logic. For example, the inspection logic might identify specific application commands and the control logic could limit their use in particular situations. A security policy could then define what action is or is not permitted. Since applications vary in terms of how they operate and what functions they provide, different application logic would be suitable for each one. Q2 – Potential Benefits Dana: At a business level, the potential benefits from adding such capabilities to an SSL VPN gateway are not obvious. Nor am I aware of other vendors highlighting their importance. Can you provide examples that clearly illustrate these benefits? Noam: Sure. There are many ways application aware SSL VPN gateways can deliver substantial economic value. Let me briefly describe just two of them. First, they enable organizations to extend access to more web applications from remote devices beyond their knowledge and control – to business partners and customers, and to employees that use public and shared devices. It is important to understand that SSL VPN gateways do NOT provide true clientless access to all web applications. Lotus iNotes with embedded Sametime and Microsoft SharePoint are just a couple of the web applications that do not work clientlessly unless the gateway has application-specific logic. If, for example, each of the 50 lawyers in a law firm can increase their billable hours by even 1 hour a month, at $200 an hour this translates into a revenue boost of $10,000 a month. Enabling their access from any remote device improves their productivity. And this is a very modest example. The Microsoft SharePoint Portal Server illustrates another benefit – the ability to extend full web application functionality to users on unmanaged devices. Without application-specific logic important services are not always available. For example, with SharePoint the Office 2003 Integration, Web Parts and Explorer View features cannot be supported with a standard clientless device. So the application can be accessed universally but its capabilities are severely constrained; that limits user productivity. Q3 – All Access Methods Not Equal Dana: Noam, at a first glance you appear to be saying that application awareness is essential to fulfilling the promise of universal application connectivity over SSL. But I thought all SSL VPN gateways provided this functionality. What am I failing to understand? Noam: Today most gateway vendors offer a number of access methods for handling various types of applications. Web applications are generally handled by HTTP proxies, which include logic that rewrites web pages and hides internal URLs. Terminal and “well-behaved” client-server applications are usually handled by port or socket forwarding technologies. Everything else is typically run through a network-level connector – something akin to an IPSec tunnel. So you are right in believing that one could access almost any TCP or UDP application with almost any SSL VPN gateway but only if all access methods are permitted at the remote device. That’s a big assumption. Let me briefly describe some potential problems: Some web applications cannot be supported by the typical gateway HTTP proxy/rewriter. For example, if an application (1) doesn't return cookies to the server, (2) uses hard coded paths which are not rewritable, or (3) relies on periodic polling of the server by the client for updates, these create problems that gateway vendors deal with in different ways. The simple solution is to require the web application traffic to pass through either a port forwarder or a network-level connector tunnel. But these access methods can create new problems. The web traffic is no longer rewritten, the fall-back connection methods are fundamentally less secure, and they require the download of ActiveX or Java agents. On many shared devices ActiveX downloads are not permitted and Java Virtual Machines are often unavailable, outdated or incompatible. In contrast, one could handle the “rewriter” problem with application logic in the SSL VPN gateway. Then organizations would not need to accept the limitations of the other access methods. Q4 thru 6 – Digging Deeper to Understand Assumptions Dana: Before you move on, I would like you to briefly explain each of your specific assertions. I want to ensure that our readers not only understand but also appreciate what you are saying. To start, why do the web objects you listed cause problems for an HTTP proxy/rewriter? Noam: When the client side of a web application does not send cookies to the server, the HTTP proxy cannot tell which session this request belongs to or if it is authenticated at all. When the paths are hard-coded in a way that prevents them from being rewritten, the SSL VPN gateway will not be able to tell which backend server it needs to send the request to. And when an application's client side periodically polls the server for updates, the server side inactivity timeout mechanism will keep on being reset, and the session will never time out. There are other ways of identifying user inactivity but these are client-based and again require downloading an applet or ActiveX component. Dana: Why do you claim that port forwarders and network connectors are less secure access methods? Noam: Port forwarders and network connectors both use tunnels to connect the end-point with the backend server. As a rule, the traffic passing through the tunnel is not inspected, and even when it is, it is not inspected at the application layer. This means that although the client and server "converse" in HTTP which can be parsed for the purpose of filtering and setting granular access control, in reality the traffic is treated as if it were opaque and tunneled to the web server. With network connectors, not only is the data or payload tunneled, but the packet headers are sent as well. What this means is that you've drilled a hole through your perimeter firewall for the SSL VPN traffic, and then tunneled potentially dangerous packets directly to the backend server. Dana: Now that we understand what we might want to avoid, how can gateway application logic solve the problem? Noam: By knowing the application, the gateway can make changes to the traffic to get around the specific problems it presents. In addition, knowledge of the application can assist in determining where to send requests that have not been rewritten. Last, application awareness helps to identify polling requests for each specific application and ignore them when calculating inactivity. Q7 – Additional Benefits Dana: So basically, application awareness is all about expanding access to applications and application functionality from unmanaged devices. Am I right? Noam: This is actually only one aspect of application awareness. In fact application awareness affects almost all aspects of SSL VPN remote access. I clearly can't go into great detail here but I would like to at least mention such issues as Single Sign On and integration with multiple user directories; integration with enterprise portals; session cleanup of application specific caches; setting levels of functionality access policies based on end-point security compliance; positive logic application firewalling; client-side troubleshooting, and allowing access from non-web client application based on the executable's hash… And the list goes on. Q8 – Security PolicyDana: Let's focus then on just one of these. In your opening comments you referred to what appeared to be application-specific user privileges. Can you be a little more specific as to how SSL VPN gateways could be used in this manner? Noam: Sure. Corporate security policies governing access devices normally dictate conditions that must be met on the access device for users to perform specific business functions. But until now, SSL VPNs limited access to entire applications – and not specific functions – based on end-point conditions, severely limiting user productivity. For example, when users worked from non-trusted machines without anti-virus software, they were either denied file access or were given full file-system access but put the organization at risk of becoming infected with a virus in the process. An application aware SSL VPN can recognize upload/download requests, and can block these requests if necessary. This means that users on non-compliant end-points can still be productive by reading and viewing their email and attachments, but are prevented from uploading attachments or files. ("No updated anti-virus, no upload" policy). Another brief example: If the wiping of temporary files isn't assured then the user will not be permitted to open attachments or download files ("Can't wipe, can't download" policy"). Q9 – Impact on Ownership Costs Dana: Anyone blessed with a healthy amount of skepticism will wonder how much effort it will take to implement, configure and maintain the new capabilities provided by an application aware gateway. How does Whale address these concerns? Noam: That's an easy one to answer – it takes no effort whatsoever from the side of the customer. Whale has set up an Application Group, an independent unit within our R&D, to make sure customers don't have to deal with any of these issues. The Application Group is dedicated to developing new modules for the popular enterprise applications, and we are committed to updating all modules to cover new product versions. These modules in fact simplify configuration of access to applications, since the administrator only has to select the application from an already existing list. Without application awareness, the administrator would need to configure the application, port, polling requests, rule set, upload and download URLs, SSO, etc. One more thing I'd like to add about costs; not only does the application awareness not add to the management overhead of the solution, but it reduces the overall total cost of ownership by significantly increasing remote worker productivity and can often directly impact revenue generation by making secure and fully functional access possible from anywhere. Q10 – Whale’s Application Awareness Strategy Dana: Whale apparently believes “application awareness” represents a strategic opportunity to create customer value and differentiate its products. What does it already offer today? And what should we expect from the company in the future? Noam: Whale today offers about 40 application aware modules optimized for the most common applications. This constantly growing number includes web, browser embedded and client-server applications. These include Outlook and Outlook Web Access, Lotus Notes, iNotes and DOLS, Lotus Sametime, Microsoft SharePoint Portal, Citrix and many others. We also provide an application aware toolkit for companies who want to develop their own modules for in-house applications or for less common applications that Whale doesn't yet support out-of-the box. In an effort to be more proactive with regard to new application versions in particular, Whale is involved in standardizing its proposed application definition language, which allows the application vendor to define their application networking environment. This will be easily embedded into application gateways such as Whale's SSL VPN. Q11 – Wrap-up Dana: Let me summarize what I believe I learned today for our readers. Then please tell me where I went astray.
Noam: I think you have a good grasp of this subject and what Whale is doing to take advantage of the opportunity. Thank you for the opportunity to discuss how Whale views it. Q12 – Additional Whale Info Dana: If our readers want to learn more about the application awareness capabilities available today on Whale’s Intelligent Application Gateway appliance, where can they go? Noam: Anyone interested in finding out more can visit
Whale's website
where they can view a recently presented webcast
on this subject which includes META Group analyst Mark Bouchard and
two organization who describe how Whale's application awareness serves
their remote access needs. And they can listen to a short 8 minute audio
that discusses how application awareness impacts security
designs of the SSL VPN. Finally, a list
of all the applications Whale has verified to work "out-of the
box" with our gateway is available.
More About Whale on SSL VPN Central Our Thumbnail Appraisal of the Whale e-Gap® Remote Access gateway(view) Executive Interview: Desktop Search Engines Need Not Undermine Enterprise Security (view) |
