• E-mail
• Print
• Comment
• Font Size
• Digg
• del.icio.us
• Discuss article

Completing The Secure Application Access Puzzle

Posted on: Sunday, 24 July 2005, 03:00 CDT

SSL VPNs offer the greatest promise, but their capabilities still need some enhancement

Workforce mobility is a relatively recent phenomenon, but the phrase itself has already become a tired one. Equally tired are the IT staffs of large organizations that are still struggling to deliver mobility in a secure way, using virtual private networks based on IPSecurity (IPSec VPNs). With nearly a decade of deployment experience as a benchmark, it's safe to say that IPSec remote access has proven overly cumbersome, more difficult and less reliable than promised.

And the struggle has only begun.

Just as organizations are finally managing to deploy IPSec remote access to large user populations in tightly controlled environments, workforces are redefining secure access needs. The original remote access paradigm-a worker connecting to the corporate network from a companyowned laptop, using company-installed software, over a modem connection-no longer satisfies business needs. Today's workforce requires access to whatever applications they need to conduct business, transparently, from any location, when convenient and necessary, using any device, over any network. This paradigm shift- from "tightly controlled" to no barriers-presents several problems for organizations:

* Workers must be able to access diverse business applications from the most convenient device available, anywhere, using any network. Workers today use a variety of devices and communications networks, from laptops and PCs to Internet-enabled handheld devices, communicators and cell phones built on lightweight operating systems. With such platform diversity, it is simply impractical to deploy secure access solutions that rely on intrusive, permanently installed client software. In addition, workers want to connect over the most convenient communications link available at the moment, from dialup and cellular services to public wireless LANs (WLANs) and residential broadband.

* Organizations must provide granular, resource-based access. Every organization must protect business applications and information from unauthorized disclosure and abuse, not only for the obvious business reasons but especially to comply in a confusing, evolving and unforgiving regulatory environment (e.g., Sarbanes- Oxley, Gramm-Leach-Bliley). To satisfy such complex security needs, organizations need to establish a level of trust for a given user, which may vary depending on access location and device. For example, a health care provider may be allowed access to patients' complete personal medical information from a PC connected to a hospital LAN; but if that same medical professional dials in from her personal handheld device via a cellular service, she might only be granted access to patients' contact information.

* Organizations must protect information assets from malicious code and attacks. Viruses, worms, blended threats, spam and spyware are more prevalent today than ever before. Such attacks drain IT and network resources, threaten privacy and company reputation and hamstring user productivity. Organizations must have solutions to block these attacks from every possible point of entry, including remotely connected devices.

Today's secure remote access solutions in general, and IPSec VPNs in particular, cannot meet these business objectives. We need a new paradigm that not only provides high degrees of end user transparency and granular policy controls, but also can be used on any device and operating system, over any available network.

Today's Remote Access Alternatives

The top contenders for secure remote access today are secure Sockets Layer (SSL) and IPSec VPNs. Both have meaningful roles, and, for the moment, both fall short of customer expectations in meaningful ways.

IPSec is a proven solution for site-to-site virtual private networking, where organizations can exercise considerable administrative control over equipment, policy, and topology. The same degree of administrative control must be assured by organizations that choose to adopt IPSec for secure remote access. But outside the comfort zone of one's own network, IPSec adds rather than removes barriers. The following areas are the most troublesome.

* Addressing complexities. Private addressing and network address translation (NAT) are used everywhere. Private IP addresses are commonly used within remote access environments-branch offices, home offices, hotspots and other guest networks.

NAT changes those private IP addresses to public addresses, but modification-such as this-happens to be one of the attacks IPSec was designed to detect. While workarounds exist in tightly controlled environments, VPN administrators cannot in general predict whether IPSec users will succeed in connecting to corporate networks, because they simply cannot be certain where NAT is applied and what addresses are used in the remote network.

* Limited authentication. Standard IPSec provides mutual authentication of tunnel endpoint devices using digital certificates or shared secrets (passwords). Neither is very practical for authenticating remote access users. Passwords provide weak authentication at best, and are difficult to manage in large scale. Client certificates have failed largely due to complexity of the Public Key "Infrustration" needed to support them. Many organizations prefer two-factor authentication methods, but IPSec solutions for token- or challenge-response based authentication are proprietary, complicated and actually increase IPSec's vulnerabilities when the popular "aggressivemode IKE with group shared secrets" is used.

* Limited authorization policy model. IPSec security associations only have IP and port-level information on which to base authorization policies. Specifically, IPSec policies cannot examine application-level protocol headers and data payloads. While IP addresses and port numbers are often satisfactory for site-to-site VPNs, this severely limits the types of authorization policies that organizations can implement. For example, organizations cannot easily construct security policies in IPSec to control user access based on specific application operations (e.g., an FTP GET/PUT) or a specific data object accessed (e.g., a hyperlink or specific MIME attachment type).

* IPSec requires permanently installed client software and policy configuration at the endpoint device. Permanent software is intrusive, and installation is potentially disruptive. Moreover, resident software means that every endpoint device must be configured and managed. This is challenging enough for a single enterprise, and even more so in multi-enterprise environments. Users cannot adopt new mobile devices until IPSec client software is available for those platforms. Finally, users are stripped of the convenience of accessing business applications from any non-managed device. A permanent software requirement effectively eliminates IPSec from satisfying the "anywhere, any device" objectives of the new secure access paradigm.

* IPSeC security associations create a potential attack vector to every service on every host. IPSec creates an IP- or network-level tunnel (connection) between a client computer and VPN security gateway. This has the same logical effect as connecting a device directly into a network. Direct tunnels are more easily compromised, especially by malicious code, such as a keystroke logger that is inadvertently installed on the remote client.

Many organizations simply can't do business in the tightly- controlled environment IPSec demands. Their constituencies are simply too dynamic, business relationships too fluid and security needs too stringent. Organizations of this kind are turning to SSL- based secure remote access solutions.

The SSL Alternative

SSL VPNs are already proving themselves superior to IPSec remote access in several respects:

* Simpler than IPSec. By leveraging the Web browser, and operating above the network layer, SSL VPNs can eliminate IP address management issues, avoid the need to permanently install client software and eliminate policy configuration at client devices. Most business applications can be accessed via any endpoint device using a standard Web browser interface.

* SSL VPNs support user authentication. By basing access on application proxy technology, an SSL VPN inherently offers a convenient and expedient gateway for extending the user challenge- response authentication methods most widely in use today, from Windows Logon and one-time password systems to token-based authentication methods and certificates. Organizations can be more confident in authorizing access to sensitive or regulated information because the user, rather than the device, is authenticated.

* SSL VPNs support more granular authorization policies than IPSec. Application proxies by definition examine application data payload: access policies can be applied to individual data objects, as a way of narrowing authenticated user access down to a specific set of servers, applications and data objects. Policies can also be refined to permit the creation of different access levels, depending on authentication method, endpoint device and location.

* SSL VPNs do not allow direct network connections. No network tr\affic passes through the VPN proxy/gateway, provided that the gateway itself is hardened against network and transport level attacks.

More Complete, But Pieces Are Missing

Today's SSL VPNs remove several barriers that prevent organizations from offering an "everywhere access" solution via IPSec. However, it's dangerously easy to paint too rosy a picture of SSL VPNs. SSL VPN gateways are attractive, but the current set of offerings is incomplete. Several key areas in particular must be addressed before SSL VPN dominates the secure remote access field.

* Proxy solutions are not appropriate for all applications. Consider IP-telephony. The SIP (Session Initiation Protocol) signaling traffic can be proxied, but latency- and jitter- sensitive voice (i.e., "bearer") traffic that is transferred using RTP may not flow through a proxy without added delay, which may render the phone call less than toll quality.

Other applications may not work at all. A remote help desk application, for example, may need to "tunnel out" from behind the proxy to a remote client. Such dynamic routing is not widely available in SSL VPNs today.

* Web is not the only desirable user interface. For some applications, users prefer native application support to a "webified" user interface; Outlook Web Access is a case in point. secure access solutions must accommodate all business applications. For such applications, complete and controlled network access is still necessary.

* Secure access from any device increases the need for location- sensitive endpoint security. Organizations that permit access from any endpoint device should take note of the adage: Be careful what you ask for, you just may get it. "Any device" includes a spyware- and virus-infected PC connected to a broadband connection in a poorly operated Internet caf.

Today, SSL VPNs offer browser data protection, which attempts, after the user logs off, to eliminate sensitive information that may have been used during the course of a secure access session. Common browser data protection features include removal of any cached user credentials and removal of temporary spooled or cached files. Some SSL VPNs can be configured to prevent a user from creating local copies of company-sensitive information on a non-work computer.

These are valuable and necessary features, but alone are not sufficient. secure access with no barriers implies that the VPN gateway will require measures to ensure that the endpoint doesn't pose a threat to the organization before a remote user attempts to authenticate (as described below).

* Secure access must be entirely transparent. Mobility, extranet, and complex business relationships completely unravel the traditional notion of insiders versus outsiders: and accordingly, internal versus external connections. Increasingly, users are constituents of diverse communities. Trusted users rather than connections must be the basis for access. Today, every user connection should be viewed as external; every user as initially untrusted; until the users-not devices-have been authenticated and their (location-sensitive) privileges have been identified.

If the industry were to satisfy these additional four criteria, then SSL VPNs could in fact claim to provide everywhere access, securely, with no barriers.

Completing The Puzzle

First, let's revitalize our thinking about secure remote access. Ultimately, the goal of a remote access VPN is not to build secure tunnels between remote devices and trusted networks, but to provide authenticated users with authorized and confidential access to applications. Generally speaking, users rarely need access to every application distributed over an organization's network, so a full network connection does more harm by exposing an organization to attack than it does good by solving the secure application access requirement.

The problem is that we've boxed our thinking into "SSL is for protected Web access" and "IPSec is for protected network access." It's time to encourage organizations to use SSL to tunnel IPlevel traffic. Nearly all new access devices offer SSL-enabled browser access. As an alternative for a proxied, secure conduit for native IP traffic, SSL is as viable as TPSec, L2TP, and even SSL alternatives that tunnel PPP. The bottom line: SSL is closer to ubiquity than IPSec will ever be, so we may as well leverage that ubiquity for all it's worth.

In the real world, secure access is less about "which secure tunneling protocol bits are best" and more about "providing secure application access that is appropriate for the task, user, and location." Users and CFOs don't care about bits and bytes, or protocol elegance and architectural purity. So let's stop championing protocols, and implement a solution that gives the customer what he or she wants.

Where an SSL-enabled browser satisfies application access needs, use the browser. Where a native protocol over IP is required, have the SSL VPN gateway upload a lightweight application or a temporary agent (e.g., a Java applet) to the client. You can then use this application or agent to tunnel the IP packets that carry authorized native protocols as payload over SSL to an intelligent proxy, and have the proxy manage endpoint device addressing, routing and configuration transparently to the end user.

By automating the installation process and employing an application client rather than permanently-installed software, we can both minimize the intrusiveness of the client and provide automatic selection of whatever endpoint access method is best suited to support the specific application the user wishes to access.

Next, let's extend endpoint security to encompass more than browser scrubbing (data protection) actions: these are invaluable, but even more can and must be done to protect organizations that want to accommodate the "any device" user. Complement existing data protection measures with endpoint device interrogation and integrity checking. Have the SSL VPN gateway inspect endpoint devices before a user enters authentication credentials, to assure that no malicious code is present on the system, and that all security measures and applications, as well as local policy configuration settings, comply with security policy.

Finally, provide administrators with the means to either grant limited access to a user whose endpoint device does not satisfy this admission policy, or to redirect the user to a quarantined area, where the user can update his or her device to comply with policy (e.g., by installing required security software or updating a malware signature database).

Conclusion

These final steps are not small, but they are pragmatic and achievable. All that's left to complete the secure application puzzle is to have someone implement memo

Endpoint device interrogation and integrity checking are the next steps

IPSec is useful mostly for site-to-site links within an enterprise

The VPN's goal is to connect users with applications, not devices with networks

Dave Piscitello is president and principal consultant at Core Competence, Inc. A 30-year network, Internet and security veteran, Dave provides advisory and consulting services for security and broadband access companies, service providers and Fortune 100 companies. He maintains an active security blog at http:// hhi.corecom.com/weblogindex.htm

Copyright Business Communications Review Jul 2005

Source: Business Communications Review

More News in this Category