That's quite true Wes. I have always taken it that Security is about
lowering risks to the most minimal, whilst having as little impact as
possible on communications and business. Total security would require most
servers (for example) to be so watertight that nothing could get in - even
legitimate business!
Anti-Virus products as well as AV email agents do have means to block VBS
(but not by default). In the case of CA's AV Exchange Agent it requires an
enhancement which disallows all VBS, and only allows registered acceptable
VBS. For external threat (ie. Mass volume VBS virus like Anna K.vbs) this
would be OK, virus writers can't account for your own in-house VBS if you
have them - unless the threat from inside is quite possible. So the chance
of malicious code coming through in disquise of your not-well-known
legitimate VBS is low.
As far as .COMs and .EXEs... I'm not so sure. I wasn't very keen on Office
2000's Service Pack 2... has anyone else installed it? It was way too
restrictive in how many attachments it stripped. And the security patches
can't be reversed unless you uninstall and reinstall Outlook (well that's
what MS officially say. I copied some DLLs from a non SP2 install, and it
worked again).
Nigel Hedges
Computer Associates
Network Administrator, GIS
tel: +61 98213195
fax: +61 98213010
mobile: +61 413 483 436
[EMAIL PROTECTED]
-----Original Message-----
From: Noonan, Wesley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 14 February 2001 5:50 AM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: FW: Anna Kournikova virus information - Please Read
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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
