In NetSec Letter #14 (www.avolio.com/columns/14.html), I stated, “The year 2001 will be remembered as the year of the VPN.” I then went on to point out that I said the same things about 1998 and 1999. VPN usage did rise, due to the rise in remote access requirements pulled along by the increase in high-speed Internet access available to teleworkers and work-extenders, and by the maturing of the base technologies that provide VPNs. Most of us are somewhat familiar with IPSEC (which I have decided to start spelling as those who named it do, in all CAPS). In the last year another class of VPN has grown into an interesting, and separate, market segment: the SSL VPN. This month, I want to make a case for SSL VPNs. [Disclosure: Aventail Corporation, a maker of SSL VPNs, recently hired me to write a white paper. This is NOT it. Also, in the past Whale Communications paid me to evaluate their E-Gap Server, which also provides SSL VPN functionality. This is also not it. But I did want you to know all this.]
I suspect that everyone reading this is familiar with SSL. You use it with your browser when making a secure transaction (sometimes). The web storefront — the http server — sends a digital certificate containing a public key, your browser verifies the certificate (and so, the key) as valid, and uses public key cryptography to make an encrypted connection back to the server to decide on secret keys to be used for confidentiality, authentication, and integrity checking. (See “Cryptography 101 at http://www.avolio.com/columns/Crypto101.html for more details.)
This is an SSL connection, but is it an SSL VPN? No. Neither is an IPSEC connection a VPN. Let me explain. A VPN should provide the basic communication security features of confidentiality, authentication and non-repudiation (as if anyone cares about this), and integrity assurance. Add access control and you have a VPN. An SSL VPN, as opposed to an IPSEC VPN, uses SSL for the secure communications piece, and must add access control.
Access control is important. Just because a connection is secure, doesn’t mean it is safe. All it means is that it is difficult to impossible to hijack or intercept. A legitimate user may have access rights to all sorts of things when sitting at his desk, on a known network address. Your security policy should stipulate how access rights change based on the connection point of the user. Is he at home or on the road on a company-owned PC? If he has a VPN client — software that allows access after some kind of strong and protected authentication to the PC — perhaps his access rights are similar to when he is at his desk at work. Is he at the local Starbuck’s on a wireless LAN? If it is his same PC, you still might want to trust the connection. Being wireless does not affect “the equation.” Maybe his connection is from an Internet Cafe, or a PC at a computer conference. What then?
Well, it depends. It depends on how much my VPN server can tell about the client PC. You might want to know if it is running a PC firewall or antivirus software. It will also depend on security attributes, such as key size, key algorithm, and authentication methods available (a user name and password over an encrypted connection is safe from eavesdroppers but not from guessing, whereas a challenge/response system or security token allows for a higher level of assurance).
An SSL VPN should provide the following:
There are three reasons I like SSL VPNs best. First, they are less expensive to deploy than IPSEC VPNs. They do not require an expensive PKI (an oxymoron) in order to operate securely. They do not *necessarily* require touching everyone’s notebook PC in order to install a client. They do not require everyone to have a corporate-owned PC.
Second, they allow access on the fly, from other people’s offices, kiosks, anywhere.
Third, they operate at the transport layer rather than the
network layer. This helps for ease of use. The SSL VPN server makes security
decisions at the transport or application layer. This has implications that are
significant, and have been personally significant to me. I have a satellite
connection to the Internet (Earthlink, via DirecPC), which is fabulous if it is
your last resort. I’ve tried unsuccessfully to use some standard and well-known
VPN clients in the past. Even after the IT department surrogate (I was half of
a demo, and also needed it to write a column) set up the client, pre-loaded it
with the security policy, postal-mailed it to me, and I installed it, it would
not work. All sorts of NAT and other anti-IPSEC stuff were going on. I even
thought, “Perhaps DirecPC denying packets, as do some other ISPs. But no,
that is not the case. Recently, I had to use an IPSEC client to access secured
information. The server-side of things still had to ship me client software on
a CD, but after installation, everything worked fine. Even, better, I was able
to easily access the Aventail demo lab using no client (just secured web access
for webified applications), the thin client (installed on demand, like any Java
applet), and an access client (securing all permitted network traffic, and
denying that which is not permitted). What more could I ask for?
#
My 2003 calendar is finally up on my web page. Please see
www.avolio.com/calendar.html.
Please note I will be speaking this Monday in
Scottsdale, AZ, at MIS Conference on Mobile and Wireless Security. The 1 day
class is VPN Introduction and Best Practices. I will be in New York City on
February 19 for a private 2-day class, “Investigative Response.” Even
though you cannot get in to it, I mention it because I think it is one of my
best classes and encourage you to see if it might not fit into your corporate
security training. It is a workshop to walk you through developing an incident
response plan and first responder team. If your company needs such a team (all
medium and large companies do) and do not have one (many do not), consider
kicking it off with this class.
See
Later in February I will be in Orlando to teach a new and improved “Tools and Techniques” for CSI.
My January Information Security Magazine “Just the Basics” column is entitled “Belts and Suspenders Redux,” a look at making your router take some of the load. You can find it at http://www.infosecuritymag.com/2003/jan/justthebasics.shtml
I also have a feature article in the February issue. In
“Gateway Guardians,” I evaluate and compare 5 E-mail firewalls. See
it at
http://www.infosecuritymag.com/2003/feb/gatewayguardians.shtml.