I don't disagree that we will continue to see the problem.
Here is where I think it is overkill. Security isn't everything, and it sure
isn't the only thing. Someone once told me "security that hampers work is
not security". That is such a true statement. Security like that is just as
bad as the "malicious code" it serves to stop. They take different methods,
but the end result is the same - lost time and money.
Rather than blocking all .vbs extensions, one could block only those that
their DAT files recognize. That allows the .vbs extensions a company may
need to receive to work just fine. I'll give you an example. This very email
I am writing will be blocked by no less than 10 people on this list. Why?
Not because it contains a virus (it doesn't) but because it contains a key
word. And as a result, no less than 10 people will gain no worthwhile
information from our exchange (not that they would anyway, but you get my
point ;-)). This is little better than blocking "all .vbs files". It
prevents the exchange of information.
Does the above protect against everything? No, you have the possibility that
a "new" virus slips in before your DAT's are updated, but one must ask
themselves "is the risk worth it, now that I have mitigated it in this
manner". The answer varies from case to case.
Let me ask you this. Does anyone know of an email scanning product that
blocks "all .exe and .com extensions" by default and design? Of course not
(or at least I don't know of one - not by default at least), since people
need to be able to pass executables as part of their day to day business.
The same holds true for .vbs. The shops that have lot's of W2K and are
managing the hell out of it are doing so with scripting.
An even better solution to the .vbs issue that I have seen is the newest
outlook patches which only allow you to save files with that extension (no
running of the code from the email client). Now that's a good balance of
protection and function IMHO. Another solution (though with secure email it
is tough, if not impossible, to do) is to change the extension to something
like .txt when it passes through the gateway. Yet another one is to change
the default execution method for .vbs to be "notepad.exe". Then one can
either uses cscript to manually run any .vbs that they need to, or pick an
extension (i.e. .wes) and associate .wes with wscript. Now anything that
comes in as .vbs is harmless, and you can still push and run scripts
internally by using the .wes extension.
It's all about mitigating the risk while providing solutions that allow the
users to work. No one said that it would be easy :)
Wes Noonan, MCSE/MCT/CCNA/NNCSS
Senior QA Rep.
BMC Software, Inc.
(713) 918-2412
[EMAIL PROTECTED]
http://www.bmc.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 13, 2001 09:33
To: [EMAIL PROTECTED]
Subject: Re: FW: Anna Kournikova virus information - Please Read
> "Noonan, Wesley" <[EMAIL PROTECTED]> said:
> Blocking all .vbs seems like a little overkill to me...
Why is it overkill? From a security standpoint running an unknown executable
is an open invitation to disaster.I know there is great utility in
automatically running executables, but it is fraught with danger.
This is not just an MS problem, although their software has some really bad
security design features. To cite an example, in the early days on the
Internet, the lowly vi editor added a feature to allow execution of macros
imbedded in text files. This allowed setting editor controls automatically
for specific document types. It was deemed a bad feature and removed, since
you could run any arbitary program when a user opened a file with the
editor. With this particular feature it was easy to set a trap for a user
running with superuser privileges and create a root backdoor.
The VBS problem continues to plague email systems. The worms are easy to
write and easy to distribute and there are enough non-security aware email
users to redistribute them. Until software designers write code with
security in mind coupled with a concerted effort at user training, we will
continue to see these kind of problems.
--
Smoot Carl-Mitchell
Strategic Technologist - Managed Services
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
