DirectAccess versus VPN: They are Not the Same

Introduction

One of the most interesting parts of my work is the correspondence I get from readers detailing their own scenarios and questions. I often hear from people who want to replace their current VPN solutions with DirectAccess. While I’m always happy to hear that people are thinking about deploying DirectAccess (in part because my husband works with UAG DirectAccess and that news makes him happy), I have to remind them that while DirectAccess has many characteristics that might make you think of VPN, DirectAccess isn’t a VPN. In fact, it’s much more. One way to understand how the DirectAccess client differs from the VPN client is to put it in perspective with other types of clients on your network and look at the connectivity and security issues that are important with each of these client types.

Types of Clients

To begin this discussion, let’s assume that there are three general types of clients that are domain members and are under your administrative control. Each of the client types would be considered a “managed client” to a greater or lesser extent:

• The “bolted-in” corpnet client
• The roaming remote access VPN client
• The DirectAccess client

The “Bolted-In” Corpnet Client

The “bolted-in” corpnet client is a system that might or might not be literally bolted in, but either way, it never leaves the corporate intranet. This system is a domain member, is an always-managed system and is never exposed to any other networks. Its Internet access is always controlled by an application layer inspection firewall, such as a TMG firewall. USB and other removable media slots are either administratively or physically locked down and physical access to the building where it resides is allowed only to employees and escorted guests. These systems have anti-malware software installed, are configured through Group Policy or some other management system to maintain the desired security configuration, and Network Access Protection (NAP) is enabled on the network in order to prevent rogue systems from connecting to the network and accessing corporate resources. Windows Firewall with Advanced Security is enabled and configured to reduce the risk of threats introduced by network worms.
This concept of the “bolted-in” corpnet client gets as close as to the ideal of secure client as one can imagine:

• The system is never exposed to un-trusted networks.
  
  
• The system is always managed.
  
  
• The system is always under the control of corporate IT.
   
• Access to the system is limited to employees and escorted guests.
• “Out of band” access to the system is limited because ports for removable media are administratively or physically disabled.
  
• An application layer inspection Internet firewall such as TMG prevents users from downloading exploits from over the Internet.
  
• NAP reduces the risks of unmanaged clients connecting to the network and spreading malware obtained from other networks.
  
• It’s unlikely that the system will be stolen due to physical measures taken to “bolt in” the client to the physical infrastructure.

While you might imagine this to be the ideal system in terms of network security, how realistic is this characterization? How many client systems do you have now that never leave the corpnet? And even with these controls in place, how immune are these machines to attack? Consider the following:

• Social engineering is a common method that enables attackers to gain physical access to machines that are specifically targeted so that malware and Trojans can be installed on “bolted-in” corpnet clients.
  
• Even with physical ports disabled, it’s likely that users will be given access to at least an optical drive – in which case malware obtained from some outside venue can potentially find its way onto the “bolted-in” corpnet client.
  
• While an application layer inspection firewall can go a long way toward preventing malware and Trojans from entering the corpnet, if the firewall doesn’t perform outbound SSL (HTTPS) inspection, it is essentially worthless, because Trojans can use the secure (and uninspected) SSL channel to reach their controllers. In addition, users can take advantage of anonymous proxies through an unexpected SSL connection.
  
• If a Trojan were installed on the “bolted-in” corpnet client, a well written Trojan would use HTTP or SSL to connect to its controller and most likely connect to a site that has not yet been categorized as “dangerous”. Even if the organization used a “white list” approach to security, the attacker could hijack a low profile “safe site” (perhaps with DNS poisoning) and instruct the Trojan to connect to that site so that it can receive control commands.
  
• Users may try to circumvent your controls if they’re unable to visit sites or access Internet resources they desire. If users are using wireless connections, they can easily disconnect from the corporate wireless and connect to a tethered phone to access resources that are blocked by the corporate firewall and then reconnect to the corpnet after they get what they want. Users with either a wireless or wired connection may be able to easily plug in a wireless “air card” to connect to an unfiltered network and compromise the machine through the alternate gateway. In this scenario, the “bolted-in” corpnet client suddenly takes on some of the characteristics of the roaming remote access client.

The point isn’t that performing security due diligence is a lesson in futility. Instead, what should be clear is that even in the ideal situation of the “bolted in” corpnet client, there are many things that can go wrong and lead to a security incident. You still need to do everything you can to make sure that your machines are secure, up to date, and well managed – but you need to put into perspective how these “isolated” and immobile corpnet clients compare to other types of corporate client systems.
Finally and perhaps most important, it’s worth considering whether or not the concept of the “bolted-in” corpnet client might only be of academic interest. How many of these clients exist on corporate networks today - especially networks where the majority of employees are knowledge workers? In a task worker environment, you might think of VDI as a viable solution, because the tasks they perform don’t require the wide array of functionality provided by a full PC environment, but knowledge workers need the flexibility and power provided by a fully enabled PC platform. In addition, more and more companies are recognizing the advantages of telecommuting and more and more employees are working from home or connecting to the corpnet while one the road. Which brings us to:

more @ http://www.windowsecurity.com/articles/DirectAccess-versus-VPN-They-Not-Same.html