Can you guarantee secure remote access from devices in the wild?

In the course of scores of conversations about security, I have regularly elicited a gobsmacked silence with a simple question: "How do you reliably secure access from an untrusted computer?"

We at Nemertes have interviewed hundreds of companies about a broad range of security topics and the security aspects of specific technologies. One topic that comes up again and again: secure remote access from "wild" computers, e.g., not assets owned by the organization but rather someone's personal computer, or a hotel or Kinko's somewhere.

Remote access attacks: Hackers turn back the clock with Telnet attacks

We have had many discussions with IT folks who were busily deploying (SSL or IPsec) VPN clients, or secured Web access to various applications, or even access to virtual desktops. They were doing their utmost to secure the connections robustly without killing performance or making the system too inconvenient to use. Many of them were aiming the solutions at both trusted and untrusted machines.

However, when I ask about the security of the endpoint itself - "if it is compromised, isn't your session security compromised automatically? How do you reliably secure access from an untrusted computer?" -- I get the loooong pause.

Usually the dead air is followed by an answer similar to "Yeah, I suppose so, but we have to assume it isn't compromised, dealing with the compromised scenario is low on our priority list, and right now we can't really extend our scope that far..." and so on. They have spent significant time considering the possibility of pwned workstations within their LANs, and spend time and effort working to prevent, detect, and eradicate such compromises. Unfortunately, they have not, as it turns out, worked the alarmingly high possibility that a home computer is compromised into their planning. All their network encryption can come to naught in the face of a keyboard sniffer or root kit hiding in Windows somewhere.

Very few people explain how they use network-access control systems to try to assess the health of VPN hosts connecting. This is great for VPN hosts but not so good for Web accessible systems or remote desktops delivered via a browser.

And of course, no such tool is perfect in detecting a deeply compromised system. Sometimes the long pause is followed by "That's why we disallow access for most people and most applications from most places." Alas, these folks are sacrificing a major benefit of the connected world — ubiquitous access — in order to mitigate the risk. They wind up either preventing people from working, or urging the organization to provide more laptops to enable more secure remote access. They are improving security, but not making security an enabler of broadened function.

Only very rarely do we hear "We have a plan for that." The plan is usually some variant on bootable media. The simple versions boot a minimal operating system off a CD-R or a read-only USB stick, that OS providing a secure remote-access client, perhaps Web-based, perhaps terminal-services based. The more complex versions provide a more full-featured virtual machine image. The newest and most baroque version has users installing a bare-metal hypervisor on their home machine, and their own copy of Windows into one virtual machine (VM) on it, with a separate VM for their work image or remote access client, and potentially others providing monitoring and security services.

In evaluating your security posture, make sure to address the elephant in the room for remote access: if users can get in from something other than a company asset, what are you doing to guarantee the security of that endpoint?

John E. Burke is a principal research analyst with Nemertes Research this week subbing for Andreas Antonopoulos who will return soon.

Read more about wide area network in Network World's Wide Area Network section.

This story, "Can you guarantee secure remote access from devices in the wild?" was originally published by Network World.

What’s wrong? The new clean desk test
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies