Depending on your level of confidence, simply go around the internet looking for trouble. ha. Unless McAfee is now opening up their md5/sha hash list to customers, I don't think you'd be able to know what is and what's not going to trigger if seen. Have you turned on all the GTI signatures on your sensors? There's low level informational sigs there that will fire if a submission was found and submitted.
From McAfee NSM server try to open https://tunnel.web.trustedsource.org. (GTI Server) And
https://gti-api.mcafee.com (GTI Server).
both the application working on https i.e 443..if the above sites are opened from your McAfee NSM then your GTI is working. If not then you have to configured rule for them.
Sorry - I didnt see this post in my initial searches, and have opened up a similar discussion here. I believe I am looking at the same thing (file reputation) as you are looking at, as you refer to the advanced malware policy?
Regarding the answers above:
- In current deployment, I am not permitted to go around looking for trouble :-)
- Browsing tests from NSM will not cover DNS from the NSP (this is for my question - just throwing it in there!) - and for advanced malware policy, the sensor needs to believe the file is suspicious in the first place (have set to high sensitivity temporarily, to have more chance of getting a 'hit', however it would be great there was a 'benign suspicious' test file that could be passed through the sensor, and even better if there was logic in place to fire an alert (perhaps in the File Rep DNS response, a certain value could indicate this was a test file, causing an alert to trigger?)
I suspect that the answer at present is simply a 'no - you cant actively test this (with the exception of taking for granted the whole thing is working if the CLI counters show requests and responses, which to be fair, is fairly fair :-) ).