Zoidberg-
I understand what you're saying about the need for testing your product. If you can detect something bad but can't act on that item further (when you're -trying- to act on it) then that would understandably be a bad thing.
I hope you have read my later post that mentions logic.
I currently have in place some exceptions that prevent certain IT tools from being deleted when they are detected. I mention this to show that I am familiar enough with the exception tool to know that you -can- configure it to 'detect but not delete.'
Eicar is a data object that is designed to be detected as a threat. It is well known in the industry. In my opinion it should be in the list of known threats.
It is benign. It is impossible for eicar to cause any kind of harm. But the current SEP interface allows for items that are known to be harmful to be ignored.
Can you agree with me that this would confuse Mr. Spock?
UIltimately here's what I'm trying to do:
My company makes software that forensicly scans data. The input data can be nearly any kind of data that can be found on a PC. In fact, it is not uncommon for a whole hard drive to be hooked up to the system for scanning. We do not provide antivirus or any other kind of threat detection in our software, that is left to the end user. Our products only run on Windows, so it is necessary for antivirus software to be used. We are trying to test how our software works when data is displaced in the middle of processing, such as when an antivirus product would detect and remove a file containing a virus.
It would of course be foolish to use actual virii in testing so we are trying to use eicar.
I would place eicar in a zip as you have suggested, but of course that would have to be a password-protected zip file or SEP would simply detect it and delete it. However, just as using a password-protected zip file prevents SEP from scanning the contents of the file, so would it prevent our software from scanning the contents of the file.