Full Disclosure: Re: Anti virus installations on Windows servers

[Valdis.Kletnieks () vt edu]

On Wed, 29 Apr 2009 15:29:28 EDT, you said:
> What do you suggest to use on a server that must accept uploads of
> binaries from users?
Now that's a particular special-case instance.  The original poster only
differentiated as far as "Is it a different answer for your server and desktop".
So I answered the original question at that same level of detail.

> Should these binaries be scanned by an anti-virus? Can we trust that
> end users have competent Anti-Virus?
I don't know. *CAN* you trust that your end users have competent AV installed
and up-to-date?  If you can't, you probably need to be addressing *that* issue,
since those end users are probably visiting a lot of *other* servers besides
your upload server - and most of those are probably outside your control.

> Because of the relative infancy of non-windows-based anti-virus
> software would it be advisable to host a windows virtual machine that
> shares a 'virtual disk' that is monitored by a robust a/v software to
> use to host the binaries?
Properly done security is about tradeoffs.

How much will it cost to design/install/maintain/document the shared Windows
server that does the AV scanning, and how much will it save you in infections
that would not have been stopped *anyhow* by the end user's AV?

>                            Which antivirus software would you
> recommend?
Let's say we have 2 AV products, FooBar and Quux.  FooBar detects 20% more
stuff which you estimate will save you $60K/year in infections you don't
have to deal with, but the Quux site license will be $75K/year cheaper.

Your best bet at that point is buying Quux and coming out $15K/year ahead.

Now you discover that neither FooBar nor Quux will easily integrate into your
binary-upload server environment - each will require another $20K in R&D to
make that happen.  Frobnoxx sucks in detection capability, but will drop
right in for essentially free.

In the real world, you *often* end up choosing a product that's not the best
one rated solely on its main mission - things like licensing costs and
integration issues often end up dominating the decision.

> The easy out is to say "I don't need a/v and nobody does" perhaps you
> might want to put a little more thought into your answers before you
> hit send.
Note that's *not* what I said - what I *said* was that if you designed things
properly, you don't need "a/v" as a separate add-on because the things the
a/v will do for you are *already* done by other stuff.

> This, however, is not the point of the XKCD cartoon, the XKCD is
> saying that you shouldn't have a contingency plan for something that
> ISN'T A CONTINGENCY.
Close, but no cee-gar.  The XKCD is saying that if you designed it so that
you need that as a contingency, you blew the design.

> On a general purpose OS, especially a desktop, insane surface exists,
> no matter what protection you've put in.
Right.  The point you're missing is that if you apply the protection *properly*,
you shouldn't be needing a separate "a/v" add-on.

Attachment: _bin
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/