• Authentication allows you to be sure that your user is who you think she is. Simple passwords are insufficient because they base your organization’s security on your employees’ ability to come up with one that can’t be guessed. Authentication methods that better establish your user’s identity include two-factor and one-time use
  passwords, smart cards, and digital certificates.
• Authorization gives your users access to the specific services they need. Your sales staff needs access to the order-entry system, while engineers need access to the source-code control system. All of them need to access their email. Good authorization systems are role based, so employees, contractors, and partners can be classified into roles and granted access based on their role.
• Encryption makes communication private. Encryption alone doesn’t make it secure — it just makes sure that nobody else can see your network traffic, including passwords and confidential data.

Most people equate the term ‘VPN’ with security while, in fact, unrestricted VPNs are almost never the right choice for supporting individual remote users. The problem is not that the encryption technology itself is inadequate, but rather that the way most of them are implemented, makes them very insecure.

VPNs support native protocol-level access to services over an encrypted channel, extending full network connectivity to a remote site. Having direct access is convenient, but it also opens up a direct path for attacks. With open, protocol-level access, your employee’s laptop or PC can provide a vector for viruses and worms to enter your network. Just because the channel is encrypted doesn’t mean that it protects against malicious attacks or content — all it means is that nobody else can see the content as it traverses the Internet (Figure 1).

Most organizations configure all-or-nothing access, giving any authenticated user full access to internal services without any role-based authorization, and without assessing the condition of the user’s computer. This is particularly dangerous when combined with VPN authentication mechanisms. These typically require only a weak, user-defined password to protect an encryption key. This means that anyone with physical access to an employee laptop or PC has the keys to your internal network. Traditional VPNs are sometimes acceptable for situations where you have two trusted partners, as in a business-to-business relationship, where you constrain traffic to only the required protocols, and the two sides of the connection use a strong authentication mechanism.

If I shouldn’t use a traditional VPN, then what should I use?

A spectrum of choices
Getting remote access right can take a lot of work, especially if you want it to be quick, easy, and reliable as well as safe and secure. There is a spectrum of choices that differ in what they expect of the client and its security, and how much control you want to have over client access (Figure 2).

• Secure services wrap individual network protocols with Secure Socket Layer (SSL) encryption. For example, IMAPS is Internet Mail Access Protocol wrapped in SSL. Secure services can be useful when with there are clients to support them (such as email clients). But more complex protocols (such as network file sharing) don’t have ’secure’ versions and aren’t supported by clients. Secure services have many of the same problems as VPNs, including the lack of a global, role-based authorization mechanism, and a reliance on weak passwords. Secure services are also dependent on the client. For example, you probably don’t want to try to reconfigure a mail client on an airport kiosk to access your email remotely.
• “Clientless VPNs” or “Mobile VPNs” are modern-day adaptations of traditional VPNs, and they use the Web browser’s SSL connection as a tunnel for reaching internal services. One type of Mobile VPN, the “SSL VPN,” is common in commercial products that provide good administration tools for authentication and authorization and often include client assessment/screening capabilities. These are sometimes called “clientless VPNs,” as they require no preconfigured client software. SSL VPN products can integrate with enterprise authentication mechanisms, and can be configured to scan the client’s security before authorizing access. SSL VPNs are one step removed from the client and they are often combined with higher-level approaches. Be forewarned that implementing SSL VPNs without role-based authorization and client security profile assessment can be just as insecure as traditional VPNs.
• Remote desktops allow users to access their desktop systems and the applications that run on them. Rather than providing protocol-level access to services, remote desktops provide an image of the desktop, limiting the avenues through which an attack can be made. Remote desktop mechanisms can be combined with SSL VPNs to integrate a layer of authentication, authorization, and encryption.
• Portals include mechanisms for aggregating services under a global umbrella of authentication, authorization, and encryption. Accessed through a Web browser, a common use for portals is to provide access to (“publish”) applications that are not native to the web, using technologies from companies such as Citrix (www.citrix.com) or 2x (www.2x.com). Portals can be easy to administer, but they also can be expensive and complex. Of all the choices, portals and Web-based interfaces are the most client independent, offering the best in anytime, anywhere, remote access.
• Web-based interfaces provide remote access on a per-application basis. Rather than providing an image of a remote application, they make its GUI available through the Web. Many organizations are structuring their own internal applications as Web-based ones, making it relatively easy to extend them out to the Internet. For standard applications such as email, there are many open source and commercial product options. Web-based interfaces are usually completely independent of the client system, and they provide a similar defense against direct protocol attacks as remote desktops. The main drawback of Web-based interfaces is that it’s easy to end up with a hodgepodge of authentication and authorization mechanisms. One way to avoid this is to combine Web-based applications with SSL VPNs that provide central control over authentication, authorization, and encryption.