Any input/clarification woudl be appreciated. In our environment, we are only using the OnAccess Scanner and only the All Process Policy and have that set to only scan on Writes. According to Microsoft Guidance for Anti-Virus exclusions, they have a section titled Processes to Exclude from Virus Scanning and have the following listed.
We run multiple instances and versions on our server, and I'm being asked to provide the full path to the SQLServer.exe for all instances. Although I can get the list pretty easily, I'm questioning if doing this will have any impact as I think they are mis-interpreting the guidance.
My belief is that because we are usiing the all-processes policy, then the SQLServer.exe is included by default and does not need to be listed as an exclusion. Plus the policy is to only Scan on Writes, and we won't ever write the SQLServer.exe. They are reluctant to enable the Low-Risk and High-Risk profiles, but if then did, then SQLServer.exe should be added to the Low-Risk. Yet that is still different then adding it to the exclusion list.
I know providing them with the full path that they are asking for is the easy thing to do, yet I think it is just cluttering up the exclusion list and confusing people on what they think might or might not be happening.
Another reason for not adding it is that they already have the full path to the instance defined with exclude all subfolders...
Attempting to give a short answer i'll quote an Except from a post by rmetzger
Quoting William Warren's Blog:
Scan When Writing to Disk does not scan while files are being written to disk; it scans files after they have been written to disk. That is also the time files can be Read from disk, meaning, a file can be Opened before the Write Scan occurs or completes. If the Scan When Reading from Disk option is disabled, you can be infected by known malware because it can be launched before the scan occurs.
Scan When Writing to Disk does not block access to files until a scan is complete; that is what Scan When Reading from Disk is for.
Scan When Writing to Disk does not guarantee a scan will occur; that is what Scan WhenReading from Disk is for.
William Warren speaks at greater length on this in his blogs and I would highly recommend reading his info.
If performance is the issue you wish to address, there are many means available that can improve performance while leaving Scan on Read Enabled.
Enable use of High and Low Turn off read and write scanning for low Risk And add the Process name SQLServr.exe as a Low risk Process (look at turning back on Read scanning for Default and leave on for sure in High Risk.)
Add path\patern exclusions to High and default. Look at a migration plan to ENS where a trust model is used for scan avoidance.
dmcgeary thanks for the through reply. I have now watched that video 3 times. It is the reason I'm questioning the way we are implementing exclusions. I'm not in control of the way we implement the virus scan, but I have suggested the use of Low and High risk profiles. The group responsible has said this is a new feature that they are not familiar with and they will review the use in the future, but right now they are confident the exclusions they have are working as desired.
Can I ask a simpilier follow up question... The guidance from Microsoft where it says Processes to exclude from virus scanning... It lists the full path to the 3 SQL exe's. The team here is assuming that by putting the full path to the exe in the exclusion list that they are meeting the guidance from Microsoft and that it will be treated as a 'process' versus simply a file exclusion when the the .exe is read and written. Does putting in the full path to the .exe in the exclusions mean that VirusScan will treat the process as a Process and exclude any read or writes that exe does from scanning?