FRAMINGHAM (11/10/2003) - The most important document a security professional can write isn't a policy document; it's his résumé.
I've been checking résumés lately because we need to replace a member of my staff who's moving to our New York office.
One went on at length about the applicant's ISO 7799 skills and experience, but ISO 7799 is the international standard for "Metallic materials -- sheet and strip 3mm thick or less -- Reverse-bend test." I imagine the candidate meant ISO 17799, "Code of practice for information security management." Reject.
Even candidates who managed to avoid résumé errors fell by the wayside. One decided to give up during the phone interview because he felt he'd blown it; he hadn't until he told me he wanted to give up. Another merrily told me his corporate LAN password during the interview.
Between filtering résumés and arranging interviews, I have to do my real job. This week, it involved getting approval for a lightweight secure remote-access system.
Last month, I wrote about the full virtual private network (VPN) that we're launching. But that requires a company machine at the remote end with layers of hardware and software, so many users are excluded from using it because of the cost. But many users who lack a company machine and connection would like to access e-mail and other applications. Increasing numbers of staffers have broadband connections. If we had a lightweight remote-access system, they would be able to work longer.
Our IT group has designed a Secure Sockets Layer (SSL) VPN from Fort Lauderdale, Florida-based Citrix Systems Inc. that lets users access our network over the Internet using only a Web browser.
However, there are security problems with any remote-access method. In this case, by opening our corporate network to the outside world, we might leak important data or allow attackers to get past our defenses. We use Bedford, Massachusetts-based RSA Security Inc.'s SecurID technology to authenticate each remote user. We also use SSL to encrypt data in transit.
This all sounds properly secure, but what if the remote end is infected with a worm or a virus? An infected remote machine could hijack the session or record keystrokes of internal passwords. This can happen in the period after the initial authentication and before the system encrypts the data to be sent.
We're very keen not to be caught in that way, and yet we can't rely on remote users to install, configure, update and maintain decent antivirus software. Home users, like corporate IT, get sloppy and miss updates, but with home users, we aren't there to monitor and catch the problems. Also, some staffers will be accessing the system from Web cafes around the world, so we can't even rely on our client software being in place.
To get around this issue, we are using Austin, Texas-based Whole Security Inc.'s Confidence Online virus-checking tools. These tools are downloaded and run every time the user connects over the Web. They look for common Trojan-horse and key-logging software and deny connections if the remote end is infected.
I was initially a bit suspicious of the product because I had heard that this kind of software often compromises on security due to the difficulty of getting code small enough to download and run quickly over a remote connection. Some competing products just look for the name of a Trojan horse, but few attackers are polite enough to run their software using a well-known backdoor name.
The Trojan-horse checker didn't fall short. I was impressed that it was clever enough to spot Trojans in which the executable file names had been altered. I was even more impressed when I ran the final stage of my tests.
I infected a machine with tens of Trojan horses and then cleaned it out using our company-standard antivirus software. You'd think that once I'd deleted everything that the antivirus software complained about, it would be safe to connect. But no, the Trojan-horse-checking software wouldn't let me in until I deleted five versions of Trojans that the antivirus software didn't spot.
I'm happy that the Trojan-horse checker worked so well, and I've given the green light to the VPN software. However, the test results have revealed a new set of problems. If our antivirus software doesn't detect the Trojan horses, how do we know we don't have them internally? Antivirus vendors have been sued by software writers who claim that their Trojan horses are legitimate remote-control tools. If antivirus programs don't pick up Windows Terminal Services, then they shouldn't detect their products, they claim. I don't buy that, and I hope Confidence Online keeps detecting as well as it does.
I'm looking into rolling out the Trojan-horse checker into our intranet Web servers so that desktops can be checked from a central location whenever they access the phone book. Perhaps we can run the tests as part of a log-in script when users authenticate. It feels odd to know that our external users may be better protected than insiders. Perhaps if I finally get an applicant who knows the difference between bending metal and security management, he can help solve these problems. What do you think?
This week's journal is written by a real security manager, "Vince Tuesday," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org, or join the discussion in our forum. To find a complete archive of our Security Manager's Journals, go online to computerworld.com/secjournal.
Mazu updates net traffic analyzer
A newly released version of Mazu Networks Inc.'s Profiler network traffic analysis product can spot unauthorized network activity and track applications that use so-called ephemeral ports, which pose a security risk to companies, says the Cambridge, Massachusetts-based network security vendor. Mazu Profiler Version 3 is designed to offer improved features for creating use and access policies for a network. It also has improved reporting capabilities for forensic analysis of compromised networks and contains features that enable administrators to track file transfer protocol (FTP) servers that don't rely on a predefined communications port. These ephemeral ports can make FTP applications difficult to track and monitor, Mazu says.
-- Vince Tuesday