Planned Vendor Link Leaves Security Hole

Jude denies a request for a live link after discovering security to be nonexistent on the vendor's end

Well, it's been half an hour since I said no to one of those "no is not an option" requests, and nobody has started yelling yet, so maybe I got away with it.

Our company has three main revenue-producing departments, one of which produces just more than half of the company's annual revenue - and trust me, that's an awful lot of money. Consequently, the people in that department get treated pretty well, and when they ask for something, they usually get it.



SMTP gateway: An SMTP gateway uses the Simple Mail Transfer Protocol, part of the TCP/IP suite of protocols, to allow the exchange of e-mail with other Internet hosts.

Firewall: A firewall consists of hardware and software that lies between two networks such as an internal network and an Internet service provider. The firewall protects your network by blocking unwanted users from gaining access and by disallowing messages to specific recipients outside the network, such as competitors.


Aladdin Knowledge Systems Inc. in Buffalo Grove, Ill., sells eSafe, a suite of antivirus security software for desktop computers, servers and gateways.

Content Technologies Inc. in Bellevue, Wash., is the maker of the MIMEsweeper family of antivirus software applications, including versions for Microsoft Exchange and Lotus Domino servers.

Cupertino, Calif.-based Trend Micro Inc.'s Web site contains information on InterScan VirusWall, which detects and removes viruses found in SMTP, HTTP and FTP gateway traffic. It also offers a wide variety of antivirus programs for e-mail, desktop software and other applications.


The latest thing they've asked for is a live network link into a vendor's systems. I won't go into what the network does, but there's definitely a valid business case for having the link, and the data traveling over the link is quite important.

The request for the link was raised as a project and assigned to a project manager. All the right hoops were jumped through, and it's almost live. The servers will be installed this coming weekend and the firewall altered to let the link through.

Guess when I first heard about the project: It was 10 a.m. Friday. Seeing as how I haven't been here long and the project manager didn't even know I existed before this morning, I guess it isn't that surprising. So I make this project priority No. 1.

The request is to add a firewall rule to allow server-initiated connections from an untrusted third-party server to a group of workstations on our internal network, with no form of network authentication.

For the nontechnically minded, a firewall's job is much like that of a bouncer in a nightclub. He has a set of rules saying who should come in, plus a guest list of specific people who go to the head of the queue no matter what. If you don't meet the rules and you aren't on the guest list, then you don't get in.

The request I have is the equivalent of putting someone down on the guest list as "my mate Dave" - anyone who turns up saying he's called Dave will be allowed in. And because a firewall has much less intelligence than your average nightclub bouncer, he'd be allowed in even if he had the computer equivalent of an insane glint in his eye and a blood-spattered chain saw - just as long as he promised that he's named Dave.

There are quite a few ways around this problem, but not many that can be implemented in the few hours we have before the group wants to start testing. We could trust in the security of these external servers to restrict access to only authorized users - the equivalent of asking for proof that you're called Dave (am I taking this analogy too far?). And we can restrict access through the firewall so all connections can reach only the one vendor-supplied application.

Both measures together are still not really good enough, but they're enough to stretch a point and support the business until we can get a better system in place.

When I talk to the vendor, even those options don't seem reasonable. We have no control whatsoever over the external servers, and the vendor's response when I ask if it has any security on its service is a bald "no."

If we install this service, we're not only putting the security of that service in jeopardy, but we are also opening a great big security hole in the side of the network, which puts everyone else at risk, too.

So I say no to the firewall request. I give some good reasons for my decision. I tell the department what it needs to change to be allowed to go through the firewall, and I start our networking team working on one of the possible alternatives. In fact, I manage to say no in a very positive way, a trick that any true consultant knows well.

But at the end of the day, I've just said no to the people who pay my wages. We'll soon see whether the project manager puts in a bit of extra work to put in a professional system or whether he just goes up the management chain to get me overruled.

Before I came to this company, I would have cynically expected to be immediately overruled. However, this company continues to astound me with the number of good staffers it employs - so maybe the project manager will go the extra mile. An hour goes by, and no response. I'm still waiting. . . .

Playing Offense on Viruses

A glutton for punishment, I've started a new installation process this week. At the moment, our antivirus defenses consist of workstation and server antivirus scanners, with another on our SMTP gateway at the head office that handles all incoming and outgoing Internet e-mail.

As I said in my first column, the scanners aren't working very well, mostly because we're finding it hard to manage the product across a multinational environment. In fact, at least half of our desktop antivirus scanners appear to be out of date at any given time.

We're trying to fix that problem at the moment, but until we do, I want to try to catch viruses before they reach the desktops.

From my experience, I've found that the vast majority of viruses come by e-mail - and by that I mean virus-infected attachments, as well as viruses like VBS.LoveLetter (the Love Bug virus) that spread themselves automatically by e-mail.

Our antivirus scanner on the SMTP gateway deals with all our corporate e-mail, but it doesn't deal with people who use Web-based e-mail services such as Microsoft's Hotmail. Although access to a lot of these e-mail services was blocked at our proxy server when VBS.LoveLetter hit, users seem to regard the block as a challenge rather than as a prohibition, and they delight in finding ways around it.

The answer to this problem is to implement a virus checker on the Web proxies so that all HTML and FTP traffic will be scanned for viruses. I started evaluating some of the main competitors, such as eSafe, MIMEsweeper and InterScan VirusWall, and then found that our head office had bought VirusWall off the shelf. I hope they did some evaluation work first. Never mind; at least they bought a global license, so now we have the software for free.

Luckily, we have one engineer on-site who worked with VirusWall at a previous company. The bad news: He says that for a while, VirusWall crashes were the main reason for engineers getting called out in the middle of the night, and when VirusWall crashes, it takes Internet connectivity with it. The good news: He knows the main warning signs of impending VirusWall crashes and can write some scripts to keep an eye out for them.

I'll keep you posted.

• This journal is written by a real security manager, "Jude Thaddeus," whose name and employer have been disguised for obvious reasons. It's posted weekly at and at to help you and your security manager better solve security problems. Contact him at or head to the forums. (Note: Registration required to post message; anyone may read messages. To register for our forums, click here).


Copyright © 2000 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon