Cost-effective remote access proves elusive

Everyone says they want security. They don't. Deep down, end users don't care. They want MP3 downloads, and damn the viruses. They want a blank password, and if forced to have one, they want Windows to remember it for them.

This leaves me with a problem. If these carefree people design and implement insecure systems or use them in an insecure way, I may get fired. If they stumble across systems that are very secure (hopefully because I nudged them in the right direction), I'm seen as unnecessary and may get fired.

So I've decided that I can't worry only about security but instead must include cost savings. If my team keeps cutting costs, then whether or not we have incidents, we'll be invited to stay.

I've spent the past few days debating how we can save costs in our remote-access systems while maintaining adequate security. We have a high-cost/high-security approach at the moment. Finance wants a low-cost system. It would be easy to offer a low-cost/low-security answer, but the tricky bit is to discover a low-cost/high-security fix.

Remote Controls

We spend a great deal of money on remote access. We use Integrated Services Digital Network (ISDN) and analog dial-in for remote access and support. Not only do we have many staffers who globe-trot, phoning in from astoundingly expensive hotel phones, but we also place equipment permanently in the homes of IT support staffers so they can provide shift cover.

Some of our high-speed ISDN end users claim to use the system all the time, but our bills show that some use it for only five minutes per quarter. If we could get them off of dedicated lines while still providing the same service, we could save big on line rentals.

Other people configure their home systems to check for e-mail every five minutes. This automatically brings up the long-distance connections to the office, and the costs add up. To add insult to injury, many of these users have high-speed cable or Digital Subscriber Line Internet connections. These always-on, fixed-price services are much cheaper than the ISDN service we offer.

The IT support users aren't thrilled about the systems we want them to cart home. Some support technicians are annoyed at having to step away from their hot-rod UFO-style game machines with huge flat panels and use the steam-powered 17-in. CRT computers we give them. We could let them use their high-powered machines and their always-on connections to access their work data over the Internet, but the lack of security in doing that is so bad that I just can't accept it.

The industry-standard solution is to slap on a virtual private network (VPN), but this solves the wrong problem. VPNs do well at using cryptography to stop snooping or attempts to modify data in transit. However, such attacks aren't common. After all, why should hackers bother lifting credit card numbers from live connections when they can steal the entire database? The problems we have are with spoofed authentication and hijacked sessions.

Attackers will go to extreme lengths to steal or guess authentication credentials and our users pick bad ones, so using passwords is out. Many companies build public-key infrastructure architectures to get around this. But the private key ends up as a password-protected file on the local machine. Steal this and the user's password, and you can connect as that person.

We use SecurID tokens for authentication on our remote-access system. We could reuse SecurID not only at no extra cost for a VPN approach, as we already have the servers and tokens, but it would also stop hackers from stealing, spoofing or using brute-force methods to authenticate credentials. The passcodes it creates can only be used once, and the correct answer changes every minute.

Even if I know with absolute certainty that a valid user started a connection, I don't know what else might travel over that link. If attackers have broken into the user's home machine, they can piggyback on the connection right into the heart of our company.

To make this risk acceptable, we could protect each machine to the same standard as our Internet-facing systems. That would include patching, antivirus scans with regular updates, and intrusion detection with round-the-clock monitoring and expert trained response.

But we can barely manage this on the handful of Internet servers we have, never mind doing that for thousands of users' home machines, each with a different build and under their physical and systems administration control.

So we could give them machines locked down with our standard build and make them use those. But users will connect using their own insecure machines because they want it easy.

Perhaps I should make their machines full clients on our network. If I use Microsoft Terminal Services, then I can get away with a very limited network connection from them to internal terminal servers. I can use a firewall to protect this approach properly.

But even here, we face risks. Remote-control backdoor hacker utilities, such as Back Orifice, would still be able to get in. Can I trust that even my users would report cursors moving and files being opened as if by ghosts?

Setting Limits

My favorite alternative is to convince most users that they don't need remote access to all of our applications. Access to e-mail on our Microsoft Exchange server is the killer application for them, so we could set up an Outlook Web Access (OWA) server with a SecurID wrapper. OWA requires only a Web browser client, so it will work from a Web café or hotel business suite.

In that configuration, the worst a hacker could do is read and fake e-mail from our employees. It's cheap because staffers can use their own machines and network connections while keeping our systems safe. But will end users accept it?

I'm still looking for answers. If I find a truly secure, low-cost alternative for remote access, I'll either launch a start-up to sell it to others or tell you about it in a future column.