1 of 1 people found this helpful
This is explained in the following KB article,
According to this, There is some risk associated with using the High / Low Risk Processes policies. Generally the risk is minimal and you should assess it on a case-by-case basis. Take care in determining the degree of acceptable risk to obtain the desired product performance.
Thank you for information, Any recommand to easy and fast way keep this risk lower! That will be helpful!
At the time you write some malware to disk, there might be no detection for it.
If you're not scanning on read, you can't guarantee to detect the infection.
If virusscan 8.8 scan file write only what risk we will met? We don't make system loding high, so can we seting virusscan only scan on file write to system. what risk we will met?
Let me quote William Warren: https://community.mcafee.com/message/114201#114201
This is of benefit to all forum readers -
A configuration where you only Scan on Write is vulnerable, not only because of the obvious security trade-off by not scanning on read, and notwithstanding the various counter-measures one can take to minimize the risk of a scan-on-write only configuration -
It is vulnerable because there is a situation where the file can be written to disk AND executed BEFORE it has been scanned.
When a file is written to disk and closed, this triggers VirusScan to scan the file when scan-on-write is enabled.
If for some reason we cannot get access to the file, since we are trying to scan the file object from a separate process and context to the original file-write+close, thus if we cannot access it at that time we implement what we call a Delayed Scan. The scanner will retry scanning after a short period of time.
If scan on read is not enabled, and the file were launched during this delayed scan window, you just potentially ran some malware.
There are other scenarios too that customers run into very often, not because of any neglect necessarily, it's just how life goes in the busy corporate world - Servers fall behind in their DAT-signature updates and nobody catches it until too late. All it takes is one user to access an infected file remotely to begin an outbreak.
Even with updated DATs the server does not scan it because scan-on-read is disabled. Relying on ODS assumes the ODS can scan the entire filesystem in its allotted time.
A user who accesss a remote infected file does not trigger a scan from their own local AV software because it would require having "On Network Drives" enabled AND "Scan on Read", the former is not enabled by default (nor recommended). Actually, this is often a temporary configuration implemented by folks who are dealing with an outbreak, until their servers have been cleaned and configurations set appropriately.
If we stick to ideal-world scenarios, we cannot ignore the risk inherent in Scan-on-Write only configurations due to imposed delayed scans. The only counter here is to enable Scan-on-Read. There are numerous configuration tweaks capable in the On-access scanner to maintain a scan-on-read configuration without performance impact. I admit there are scenarios too where the overhead is too much... but those are few and can be handled as special cases for risk mitigation.
Programs like Conficker take advantage of this slight opening and can cause infection before the write+close or delayed scan can catch the virus. However, the immediate read to load the program is caught on Scan when reading, catching the virus before the file may even be closed. There is a performance hit for this though, and should be considered. Your mileage may vary.
Hopefully this helps.