On Tue, 13 Feb 2001, Noonan, Wesley wrote:
> 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
I've got another saying you should add to your bag though: "An ounce of
prevention is worth a pound of cure."
> bad as the "malicious code" it serves to stop. They take different methods,
> but the end result is the same - lost time and money.
Given the stats we had on the losses from the previous VBS worms, I highly
doubt that the loss from blocking .vbs attachments from the world is going
to come anywhere near the same level.
> 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
That also allows mass mailers a window of oppertunity that is the part of
the problem that AV software does NOT protect from.
> 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.
Firewalls also prevent the exchange of information, so do receptionists,
front doors, tresspassing laws and wiretap laws. Security is about
restriction, and it's a necessary evil in this world.
> 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.
But for the general case, unsolicited e-mail attached VBS files that
aren't in .zip format cause more trouble than they're worth.
> 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.
Let me ask you this: When was the last time you did an analysis of the
.com and .exe files coming into your network for business purposes instead
of just for recreation and what does that do for your company's
productivity?
> 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.
With scripts from unknown, untrusted and unsecured external sources via
e-mail? Lots of houses fell down before we had building codes, and
limiting the freedom of expression of the lowest bidder seems to have
helped more than it hurt. Buildings still fall down, but nowhere near
with the same regularity. Encouraging poor building practices because
waiting for someone to build something well costs money and takes time
isn't a good enough argument for me to want to dwell in such a building.
> 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
So, you're asserting that the thousands to tens of thousands of infected
companies would lose more on blocking or quarentining .vbs files than
they've lost in the last 12 months on cleaning infected machines? I'd
like to see where your stats are coming from. That doesn't even take into
account the people you've infected and their newfound "appreciation" for
your company's practices.
> 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 a hell of a lot easier to block .vbs than it is to manage what
association every machine in a company is configured with.
> It's all about mitigating the risk while providing solutions that allow the
> users to work. No one said that it would be easy :)
Allowing the users to work is different than allowing them to do stupid
things. Just like you have to manage what activities young children
participate in because they either don't know or can't manage the risk, so
goes the life of the security admin. Given how many .vbs worms we've had
and the fact that the latest incantation is probably going to turn out
worse than Melissa and possibly Love Bug in volume, it's immediately
obvious that end-users aren't able to manage that risk.
You talk about the buisiness' need- but you don't seem to have taken into
account that there are very few businesses on this planet where there was
a business case for anyone clicking on that link- so the business has
already lost something, even before it becomes a mass mailer.
It's also a simple fact that if more places blocked .vbs, the worm would
not have gotten traction and probably wouldn't have used up any of our
time outside of a few people here and there. Overall the net gain (pun
intended) would be significantly higher than the proportion of people
managing their Win2k systems over open net-wide e-mail.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
