For those concern large AV installation and protection of networks

[Support]

Here is what I should think that needed to be followed for a clean network.

1. Patch your systems according to the latest instructions from Microsoft.
2. Read on a daily basis on few AV vendors web sites for the current threads, virus, worms.
3. Notify your users when you see that an email worm is spreading out fast.
4. You do not need to do the number 3 if you use AV for Internet or AV for mail and Content and Spam filtering.Your gateway products should be informed before you even realize than a new thread already exist. Therefore as long as you got right tools properly installed on the gateway nothing malicious will pass through your network.
5. Get centralized application of an AV product.
6. Update your systems immediately, as soon as your vendor released new virus definition databases. Centralized applications of AV do that in few clicks..or without user intervention.
7. Get always informed from your AV Vendor for product patches, new releases.
8. Be patient you will be not the first neither the last that will got a network infectec by virus.
9. Be prepared to loose 10% of PC's if you put AV product for the first time, so a ghost of a prototype PC if you have the same brand of PC's on your company would be a good idea.
10. Test your systems if they are really work using the famous eicar file. This just to see that your engines are running properly. Go, first read then implement from the link: http://www.eicar.org/anti_virus_test_file.htm
11. Good Luck

[slarty]

1. Patch your systems according to the latest instructions from Microsoft.

I am strongly opposed to automated patching. As a developer, we found that our "friendly" sysadmin decide to patch boxes using some central tool whenever they feel like it. This causes two problems:

1. Some patches reboot the machine. Our friendly sysadmin decided it would be a really good idea to install this patch when everyone was busy, causing some people to lose their stuff as all the machines reboot
2. Sooner or later, M$ release a patch which breaks an application. Sysadmin have no way of testing this without consulting the developers, so they just patch it anyway. Then, through no fault of our own, our app inexplicably breaks.

Couple that with the fact that the majority of patches are unnecessary (they patch components not being used or not even installed), and you just have a source of headaches.

Instead, each patch should be evaluated on its merits. If it patches an unused component, or something that is irrelevant (Say, chinese version of IE), then don't install it.

After you've decided that a patch should be installed, try installing it on a test machine (preferably one server, one workstation), and test the applications.

If the patch requires a reboot, inform users when it will be installed, and ideally do it out of hours.

If the applications are known to work with the patch, then patch it.

[Support]

I would agree with your oppositions. Patching needs testing, backup, and planning before any implementation takes place. In addition there are a couple of tools that do patching in large scales which can analyze potential problems.
Good Point.

[waverebel]

A couple of additional points:
Make sure that you block the apropraite email attachment types, and update in the event of a new threat. your mail server software should be capable to do this.

Come up with a good user policy on the downloading of software and the execution of attachments (which should be blocked anyway).

Be careful about disk ascess between workstations to prevent viruses speading by shares.

[Support]

Originally posted here by waverebel
A couple of additional points:
Make sure that you block the apropraite email attachment types, and update in the event of a new threat. your mail server software should be capable to do this.

Come up with a good user policy on the downloading of software and the execution of attachments (which should be blocked anyway).

Be careful about disk ascess between workstations to prevent viruses speading by shares.

There all mentioned above..what is your point?

[shadow_dancer]

i ussualy love travelling and bring my laptop for any kind of job .. and put here and there on my NIC port for my network, so i rather use anyone network and then connect to my mainframe by remote. Yes ... Support correct about clean network , will make my job easier and faster, especially for number 10 (ten).
By the way i read links at
http://members.tripod.com/barhoush_2/topology.htm
http://www.iec.org/online/tutorials/in/ ...... and it is nice.

-Shad

[waverebel]

Support, you allude to AV mail filtering in point 3, but I cannot see where you reffer to disk access between workstations? or to an explicit user policy?

Support, I am not intending to dis your post, just to add a couple of things that did not appear to be clear to me from reading previous replies.

[Support]

Disk access between workstations is strictly prohibited unless reasons and when is required is done with read only access..in an internal network.
When we use centralized AV products we do determine what a user can access from internet and how the AV product should work internally. Thus for those using centralized AV and in general security products...the mean of the policy is pretty much understood.
Sorry if I would not made clear these facts.

[Und3ertak3r]

Support this is the first thread you have started that has been useful, with the balace from slarty and others will certainly help noobs..

cheers

[bballad]

Originally posted here by Support
Disk access between workstations is strictly prohibited unless reasons and when is required is done with read only access..in an internal network.
When we use centralized AV products we do determine what a user can access from internet and how the AV product should work internally. Thus for those using centralized AV and in general security products...the mean of the policy is pretty much understood.
Sorry if I would not made clear these facts.

you don't work with many MS networks where disk access is hiddne and active by default. If you don't know that the hidden shares are their.
I also have a hard time beleiveing that a mid to large company will not have file and print shareing on desktop systems, marketing and sales smucks who useualy out weight IT folks in busniess decsions useulay insist on it. Its nice to think that we can lock down any access point that we want to, but life works difrently in the real world