I can't see in your rule set criteria for scanning only "large" files.
The screenshot is created about my test WG where the file size dosn't matter.
1 of 1 people found this helpful
I saw the same question coming from an SE internally, I'm guessing you're the source.
I like how you did this. Based on your rules, if we dont see the hash within the defined limit (Default), that value should be removed.
Where/when are you adding the file hash to PDStorage? This is important because if you're adding the hash in the response cycle, MWG could find a virus in the embedded cycle. If this happened, we'd be whitelisting a hash which has a virus inside of the object.
Adding the hash in the Logging Cycle (Log Handler) is best because logging happens after the transaction occurs (rather than midway through it).
I built a version of this which maintains a list of hashes, and we're appending to that list in the logging cycle if no virus was found. The list of hashes is flushed after a GAM update is performed rather than every 24 hours. Flushing of the list is done in the error handler cuing on a certain incident ID.
Your guessing is correct. I was the source of the request.
The original idea of the rule was not mine. I found a similar rule on the community. (Thanks for it for fwmonitor.) https://community.mcafee.com/message/260210
Thanks for your advice!
The Logging Cycle is a better place to calculate a file hash. I redesigned the rule as you suggested and it is working perfectly.
You will not want to caclulate the hash in the logging cycle (it wont work). You will and to calculate it in the response cycle to a user defined property.
The order would be the following:
1. Calculate the hash of the response body in the response cycle -- User-Defined.ResponseBodyHash = Body.HashSHA1 (Example)
2. In the Logging cycle, if no virus was found (throughout the file -- response cycle or embedded), add the response body hash (User-Defined.ResponseBodyHash) to your PDStorage