Security Column: Managing Outgoing Viruses

Every once in a while, I see some new security development that really sets
me on edge. The latest one is courtesy of DERA (Defense Evaluation and Research
Agency), an agency of the MoD (Ministry of Defense) in Britain. Like many agencies
that deal with computer security, they periodically come out with some new idea or product that solves a popular problem.

In this case, DERA has come up with a way to combat email borne viruses. Realizing
that you will not always be able to intercept and stop a virus as it makes itss
way into the network, you can try to prevent it from “germinating” and spreading
to other systems. This is a good idea, having defense in depth. If you don’t
catch incoming viruses at least you will be less likely to propagate them to
other systems. Unfortunately, the method suggested by DERA is extremely simplistic
and will no doubt annoy users to no end.

DERA’s idea is that when you send out an email you will receive a message asking
you if you really want to send it. Thus, viruses that generate emails to spread
themselves will be stopped because the user will realize they have not intended to
send a message, and they will not click “OK.”

This appeals to many people because of its apparent simplicity and potential
effectiveness. Unfortunately, there are several severe problems with it. The
first will be the annoyance that will slowly become unbearable, like Chinese
water torture, of having to wait for a message and then click on “OK” whenever you send an email. Instead of quickly typing out an email and hitting send you
will need to wait until the server sends a response so you can click the approval button. Depending on how heavily loaded the server is, this may take a while.

The second problem is that writing a virus with the ability to respond to this
message will not be terribly difficult. As this software becomes more popular,
virus writers will compensate for it by automatically replying to the messages.
Of these two problems, I suspect the user interface will be the major downfall.
Security measures almost never work if they are intrusive, because users will
first try to circumvent them, and then they will loudly complain if they cannot.
Also, these systems only work if the client uses the company mail servers. If
someone has Outlook set up to use Hotmail as well, for example, the virus may
successfully spread through that account.

There are also much better ways to deal with this solution that will not be
as “in your face.” For example, you could have the mail server either hold all
email for several seconds or minutes before sending it and apply either rate
limits on the amount of mail a user can send out, or if the user sends too many
messages that are identical or nearly identical, have it flag them and raise
an alarm. This is made easier by the fact that most viruses send
themselves out as attachments, making them easier to spot. Hooking into your
authentication system is another option. If a user is not logged in, but their
machine is trying to send out email, this is an obviously suspicious activity.
More intelligent approaches such as these, while harder to implement, are probably
going to be more effective as they will not annoy users to the same degree.

Of course, this all ignores many of the simple steps you can take to block
the spread of these viruses. Simply blocking .vbs extensions at the mail server
(both incoming and outgoing) will very quickly reduce your risk exposure by
a significant degree. Firewalling outgoing connections to port 25 (SMTP, the
mail transfer protocol) and forcing users to use the company’s mail servers
will at least ensure that their outgoing messages must pass through your filters,
and you will have a log of them. For most UNIX systems, there are a number of
free log monitoring utilities you can use to alert you if a user suddenly starts
to send out a lot of email.

Remember, security doesn’t have to reduce usability.


Links

http://www.zdnet.co.uk/news/2001/16/ns-22417.html

http://www.theregister.co.uk/content/8/18478.html