Sorting Through the Hype of Ubiquitous Secure Remote Access and SSL VPNs

{LANG_NAVORIGIN} Encryption VPN
Ken Salchow 03/12/2005

Security

So what about your CEO who wants email access at the airport Internet kiosk? As intimated in the previous section, the CEO could probably already have that access—most enterprise mail systems provide some form of web-enabled access and support SSL. Most likely this hasn’t been deployed because of the heightened security risk associated with this scenario as the machine being used to access the resources cannot be verified in advance. The notion of ubiquitous access implies an increase in the number of un-verified access points and presents a serious security issue. The primary concerns are persistent information, and an increased risk of attack either via malicious code or malicious users.

Persistent information, the little artifacts left behind after using a computer to access information, is one of the bigger concerns. The standard browser cache, which can also cache user credentials, as well as temporary directories, are the most obvious concerns with the proxy-based access used in many SSL VPNs. That doesn’t mean that tunneled access doesn’t also have issues with file-downloads and email attachments that may be cached or saved to the local machine during access, they do. In addition, the now well known “Google Desktop Issue” can also present the opportunity for information to be duplicated and leaked to the rest of the world. All of these persistent items present a serious security threat particularly when the access is from an un-trusted or public terminal.

While persistent information is not a problem solely for SSL VPNs (IPSec can be susceptible to the same issues), the lack of a requirement for a pre-installed client makes it more of an issue. The providers of SSL VPN solutions have given us an arsenal of weapons to help ensure that these artifacts are not left behind. Most of them provide some form of “cache cleaner” which ensures that browser cache, history and cookies are removed from the system when the session is terminated normally and provide some mechanism for cleaning up the system on reboot if the session is terminated abnormally. In addition, many of them provide advanced features that enable you to empty the windows trash can, wipe the temp directory and even to remove its own software from the system. Unfortunately, because each client system and client OS handles these things differently, no cache cleaner is able to work on all client systems and ensure that all traces of persistent information is removed. Some vendors also provide a “protected workspace” or “virtual desktop” functionality which allows the entire session to exist only within this “virtual” arena; once the session is closed, all of that sessions data is eradicated. Here too there are OS limitations and while some of the vendors tout this functionality, they actually rely on 3rd party software that must be pre-installed—not very handy for that Internet kiosk at the airport.

Heightened risk of network attack and infiltration is another issue with wide-spread, ubiquitous remote network access. An unknown system may have viruses, Trojan software, key-logger programs or any other variety of malicious code running on it. You need to know that a) the user’s actions and data are not being intercepted and b) the system does not contain any code that could damage your network while it is attached. Since more than one out of every two computer-based attacks is initiated by an internal, authorized person, you also need to be wary of what even your authorized employees may be doing when accessing the system from an unknown location without the watchful eyes of co-workers and management looking over their shoulder.

Again, while these are not new issues only pertinent to SSL VPN, the vendors of these solutions have given us tools to help protect our networks. The “protected workspace” idea previously mentioned can subvert most malicious code by creating a new “instance” that is not running the malicious software; again, assuming that the vendor does not rely on a pre-installed client to make this work. The SSL VPN vendors have also given us a great deal of flexibility in defining characteristics of what we consider to be a “safe” system and only allowing access (globally or by resource) based on whether the client passes these tests. Most of them can test for things like the absence/presence of Anti-Virus (AV) and Personal Firewall (PF) software, the last time these were updated as well as whether it is a trusted vendor for that software. Most can also check things like OS type, OS version and patch level, browser version and patch level, SSL cipher-spec, and a host of other variables. This can go a long way to making sure that the systems used to connect to your network are up to standard. Alas, here too, there are often restrictions concerning the client OS and browsers supported. Many vendors only support one or two AV or PF vendors, as well as often requiring custom code or pre-installed software to get the most protection. Finally, many of the vendors suggest that their proxy-based access is the ultimate protection against virus and other malicious code from entering your network. While this may be true from a network level, recent studies have shown that most attacks today are carried out at the application layer, not the network layer; almost none of the vendors provide application layer protection or integrated virus scanning of files that are uploaded to the network.

SSL VPN inherently increases your security risks by virtue of its greater flexibility in deployment, ease of use, and breadth of coverage. While the vendors of such solutions—recognizing this fact—have provided sophisticated and unprecedented tools to increase the confidence of its use, the very use of these tools can serve to limit the landscape of acceptable client locations. That is to say, if you take advantage of the advanced security features—as you should—you will most likely exclude many un-trusted clients like airport kiosks. This is the correct thing to do, but in itself proves that truly ubiquitous access is not necessarily a good idea.

Business Requirements

I am constantly amazed at how often I am asked to help solve a business problem and handed a list of technical requirements. Business requirements describe who, what and sometimes where and when; technical requirements describe how. These are two distinctly different things where one is describing the “perfect” solution and the other describes the reality of implementing it. I would posit that “ubiquitous” access, especially that from the proverbial airport Internet kiosk is not a technical requirement, nor— in reality— is it a business one.

I have logged almost 300,000 actual flight miles in the past 3 years. In all that time at airports across the country, I have seen one, maybe two, people ever actually using an Internet kiosk. Furthermore, in all the seminars and presentations I’ve given I have found very few people who admit to ever using one; those that have mostly say that they did it out of curiosity more so than necessity. There are so many alternatives to this today that the usefulness of them— and consequently the requirement to support them— is, in my opinion mostly negligible or at least most certainly a fringe case.

Hanging out with the sales teams and executives who travel non-stop, I know that the real necessity is being able to consistently and reliable allow them to have a VPN connection from hotels, customer networks and wireless hot-spots like those at Starbuck’s and (incidentally) the airport concourse. It is the ability to provide secure access from these (increasingly ubiquitous) public networks that is in question, not secure access from public nodes. The issues encountered with IPSec in even these situations are what has called this technology into question and raised the awareness of SSL-based VPNs.

Not to say that there may not be legitimate business cases for access to secured resources via public terminals or that no one has ever used them for such, what I am saying is that part of the design and analysis process is to refine and define what the business wants and distill what the business really needs. “Ubiquitous access” is much too vague to be a technical requirement and should only be a conversation-started as a business one.

Reality Check

The reasons to investigate, and probably to deploy, an SSL-based VPN are numerous and compelling. They provide easier deployment and ongoing management, more reliable and consistent connections regardless of originating network and a host of new tools to help you provide more robust and appropriate security. All of this drives the numbers of lower TCO and quicker ROI—things the business, and you, should really be concerned with. Of all these reasons though, I hope I have given three pretty specific reasons to prove that a) ubiquitous access is not really possible, b) ubiquitous access is not really desirable and c) ubiquitous access is not really necessary. Holding back on adopting SSL VPN in hopes that it will satisfy this perceived need—or worse, believing the marketing hype and purchasing a solution that promises you ubiquitous access instead of the best set of real-world features you should be concerned with, could prove to be a costly mistake in the long run.

So, how about that car? Are you interested?

About the Author

Ken Salchow has been employed by F5 Networks, Inc. for the past five years where he has served in several capacities, currently as a security systems architect. In addition, he is the owner/operator of Binary Forensics, Inc., a boutique computer forensics lab serving the legal community in criminal and civil litigation and Digital Interlopers, Inc., a boutique penetration and testing organization serving small/medium business entities. He currently lives in Minnesota and can be reached at k.salchow@f5.com.

Reference

[1] http://www.webster.com/cgi-bin/dictionary?book=Dictionary&va=ubiquitous&x=0&y=0; Merriam-Webster Online.














Your IP address will be sent with this e-mail

From e-mail to e-mail