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:

The Roaming Remote Access VPN Client

In the 1990s, the “bolted-in” corpnet client was the norm. In the second decade of the 21st century, workers are far more mobile and the bolted-in client has given way to the roaming remote access VPN client. Knowledge workers have powerful laptop computers they take to work, to their homes, to customer sites, to hotels, to conferences, to airports, and anywhere else in the world where there is an Internet connection. And in many cases, after being at one or more ofthese locations, they bring these laptops back to the corpnet.

The roaming remote access VPN client poses a very different threat profile when compared to the mythical “bolted-in” corpnet client. Like the “bolted-in” corpnet client, these machines are domain members, have anti-malware software installed, have the Windows Firewall with Advanced Security enabled, and are initially configured to be fully compliant with corporate security policy. The roaming VPN client computer, when first delivered to the user, is as secure as “bolted-in” corpnet client.

However, that configuration and security state doesn’t last for long. The user might not connect to the corpnet over the VPN connection for days or weeks. Or the user might connect daily for a week or two, and then not connect for a few months. During the interim, the roaming VPN client computer slowly but surely falls out of compliance. Group policy is not updated, anti-virus updates might complete on an irregular basis, other anti-malware software may fall out of date. Security and compliance controls that are imposed on clients located on the corpnet may never find their way to the roaming remote access VPN clients because they fail to connect over the VPN in a timely manner.

The roaming VPN client falls further and further out of your defined security compliance configuration and the problem becomes magnified because the machine is connected to a number of networks of low and unknown trust. These unmanaged or poorly managed networks might be full of network worms and the computer might be exposed to users who have physical or logical access to the computer and who would otherwise not have access to the computer if it were to never leave the corpnet.

What happens when the user brings this computer that has fallen out of compliance back to the corporate network? What if the computer became compromised by worms, viruses, Trojans and other forms of malware? The damage might be limited if you have Network Access Protection enabled on the network, but how many networks have actually turned on NAP, even though it’s been available for years as part of the Windows Server 2008 and above platform?

Of course, the user wouldn’t even need to bring the compromised computer back to the network. Suppose the user had connected the computer to a number of different networks, exposed the computer to a number of users of unknown trust, and ended up with a compromised computer. Then the user needs to change his password after three months so he connects via VPN to perform the password change. The potentially disastrous security results would be the same as if the computer were actually returned to the physical corporate network.

As you can see, the roaming VPN client suffers from a number of security issues compared to the historical “bolted in” client:

The roaming VPN client is connected to the corpnet on an intermittent basis – or sometimes never – and therefore falls out of the reach of Group Policy and other management systems.

The roaming VPN client is exposed to unmanaged and poorly managed networks, increasing the potential “attacker surface” to which the roaming remote access VPN client is exposed, compared to the machine that never leaves the corpnet.

The roaming VPN clients can access the Internet and the users can do whatever they want while connected to Internet sites because there is typically no filtering of Internet connections when the VPN client is not connected to the corpnet.

If the VPN client is configured to disable split tunneling, it might be forced to use corporate Internet access gateways during the time the client is connected. However, once the VPN connection is dropped, the user can do what he wants again – and can share any malware or Trojans the computer acquired while disconnected from the VPN when it connects again.

Users might avoid connecting to the VPN because logon times are slow, connectivity is inconsistent, and the entire VPN experience is less than optimal, further increasing the risk of falling out of security compliance and increasing the risk of compromise.

The roaming VPN client is therefore significantly different from a security perspective, compared to the “bolted-in” corpnet client:

Group policy may or may not be updated on a timely basis.

Anti-virus software may or may not be updated on a timely basis.

Anti-malware software may or may not be updated on a timely basis.

Other management and control methods may or may not be able to reconfigure the client on a timely basis.

The number of people who have access to the physical VPN client computer is potentially greater than those who have access to a “bolted-in” corpnet client, including not only the user’s family members and friends but also people who might actually steal the computer.

The key difference between the roaming VPN client and the “bolted-in” corpnet client is that the VPN client is not always managed, and that it is exposed to a greater number of programmatic and physical threats. However, there are ways to mitigate some of these threats and many companies have already introduced methods to do so, such as the following:

Deploying disk encryption (such as BitLocker) so that if a machine is stolen, the disk can’t be read using an “offline attack”. Disk encryption can also employ a “key” based access method to the disk, so that if the machine is turned off, the machine will not boot without the key.

Requiring two-factor authentication to log onto the machine, with the second factor also required to unlock the machine or wake it from sleep.

Deploying NAP or similar technologies to test endpoint security before the machine is allowed corpnet access. If the machine cannot remediate, it is not allowed corpnet access.

Ensuring that user accounts used to log into the network are not the same as administrative accounts used to manage network servers and services, to prevent elevation attacks.

Pushing back the datacenter away from all clients, both VPN and corpnet situated clients, so that the datacenter is physically and logically separated from the entire client population.

Using one of more of these mitigations will go a long way toward reducing the potential threat exposed by remote access VPN clients. While perhaps not leveling the field with the “bolted-in” corpnet client, there may be scenarios where the roaming remote access VPN client may actually present a lower risk. We will examine one of those later in this article.

The DirectAccess Client

Now we come to the subject of the DirectAccess client. Like the VPN client, this computer can move from the corpnet, to a hotel room, to a conference center, to an airport, and to anywhere else that a roaming remote access VPN client might be located. The DirectAccess client, in its lifetime, will be connected to both trusted and untrusted networks, just like the roaming remote access VPN client, and the risk of physical compromise of the computer is also similar to that seen with the roaming remote access VPN client. Thus, it would appear that the result of a comparison between the DirectAccess client and the VPN client is that they are essentially the same from a threat perspective.

However, there are some significant differences between the roaming remote access VPN client and the DirectAccess client:

The DirectAccess client is always managed. As long as the DirectAccess client computer is turned on and connected to the Internet, the DirectAccess client will have connectivity with management servers that keep the DirectAccess client within security configuration compliance.

The DirectAccess client is always serviceable. If IT needs to connect to the DirectAccess client to perform custom software configuration or troubleshoot an issue on the DirectAccess client, there is no problem getting access because the connection between the DirectAccess client and IT management stations is bidirectional.

The DirectAccess client uses two separate tunnels to connect. The DirectAccess client has access only to the management and configuration infrastructure through the first tunnel. General network access isn’t available until the user logs on and creates the infrastructure tunnel.

When you compare the DirectAccess client to the remote access VPN client, the DirectAccess client can present a much lower threat profile than the VPN client, because the DirectAccess client is always within the command and control of corporate IT. This is in stark contrast to the roaming remote access VPN clients that may or may not connect to the corporate network for long periods of time, which leads to configuration entropy that can significantly increase the risk of system compromise. In addition, the mitigations mentioned above that apply to the remote access VPN client can also be used with the DirectAccess client.

Here is where we reach the point of making a critical distinction: when comparing the roaming remote access VPN client to the DirectAccess client, all the evidence points to the fact that the DirectAccess client poses a lower threat profile. Comparisons between the DirectAccess client and the “bolted-in” corpnet client are probably of academic interest only – since few organizations have these “bolted-in” clients anymore and most firms are enabling users with VPN access to reach corpnet resources,and both VPN clients and DirectAccess clients will move in and out of the corporate network, making the division between the “corpnet client” and the “remote client” virtually meaningless from a security perspective.

Conclusion

I’ve heard a number of people express concern over the possible threats that a DirectAccess client can present to the corporate network due to its “always-on” capability. However, this concern is expressed without considering the context of the DirectAccess client and how it compares to the traditional remote access VPN client. From the analyses provided in this article, it should be clear at this point that because the DirectAccess client is always managed, always updated, and always within the command and control of corporate IT, its threat profile is indeed much lower than that presented by the remote access VPN client.

Featured Links

How to Prevent Security Breaches

Join Brien Posey, Microsoft MVP, for a discussion of the increasing trend of data breaches and real-life lessons learned, including recent examples such as the Anthem breach. Brien will also discuss future trends based on recent data breach investigations and address a range of topics including:

How and why do data breaches happen and which firms are more exposed?

What is the cost that data breaches hold for organizations?

What can companies do to stay protected?

The webinar includes a live Q&A session with our expert presenters to answer your top questions.