I have a bunch of developers that use JBoss and Eclipse. They are complaining that when they are developing that On Access Scans are absolutley killing their production. My question is this, how much of a risk would I be exposing the network to by excluding both JBoss and Eclipse as processes or just excluding these two processes by group or user. Thank you in advance for any opinions or suggestions. I am currently running EPO 4.5. We are a mix of VirusScan 8.7 p/2 and VirusScan 8.5 p/8 Engine 5400.
You may want to look at low risk/high risk profile instead. This allows you to nominate processes you deem as 'low risk' and have that profile configured to not scan 'read' and/or 'write' whenever that processes touches other files. There is a good KB on this you may want to read - KB55139. So rather than excluding whole groups or whole directories which can lead to security holes, you are taking a calculated risk to 'trust' this process. Give it a try and see the results. Hope this helps.
For a development environment, be sure you are using 8.7i with Patch 2 (at least Patch 1 + HF464768).
This release alters what happens under-the-hood when you disable Buffer Overflow and Access Protection features. The hooks in place that allow their functionality get released when you disable the feature; prior releases still had the hooks in place so you had little performance gain in disabling the feature.
If you couldn't tell, the recommendation would be to disable BOP and AP features. The overhead of these features when you have tons of I/O occurring, both file and registry, is very noticeable (and unavoidable). This will give you nice performance gains. Build times will still be longer because OAS is enabled...
Regarding the scanning configuration for OAS, making use of Hi/Default/Low risk profiles is a good idea - adding the processes which are responsible for most of the file activity to low risk, with the low risk config set to either not scan their activity or to exclude what they're doing (the former offering better gains).
FMRs for smarter ways to handle the "build environment" scenario are welcome.