Protecting Packages
Hello All,
We had an incident yesterday where the scheduled virus scan (using the latest antivirus definition) removed a custom dll associated with an application. Apart from affecting a few hundred users[:@], who had to re-install their application, we also created an exemption in the antivirus real time scan to exempt the dll until the next definition was released.
I was wondering if there is a recommended way to prevent this happening with future packages (it wasn't one of ours, but it could have been). The dll in question is dwspy36.dll; which has had some issues with it's name before. Can we protect certain dll's etc from being replaced with spyware, or as in this case removed by a 'false' positive[8D].
Any thoughts, recommendations, greatly appreciated.
Cheers
Wayne
We had an incident yesterday where the scheduled virus scan (using the latest antivirus definition) removed a custom dll associated with an application. Apart from affecting a few hundred users[:@], who had to re-install their application, we also created an exemption in the antivirus real time scan to exempt the dll until the next definition was released.
I was wondering if there is a recommended way to prevent this happening with future packages (it wasn't one of ours, but it could have been). The dll in question is dwspy36.dll; which has had some issues with it's name before. Can we protect certain dll's etc from being replaced with spyware, or as in this case removed by a 'false' positive[8D].
Any thoughts, recommendations, greatly appreciated.
Cheers
Wayne
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
kkaminsk
18 years ago
You can lock down files from the Virus scanner if you really want to but that might just create another bad situation if a bad dll gets placed on the machine in a secured location. I'd be more inclined to beat on the AV vendor for putting out a bad signature.
Posted by:
WayneB
18 years ago
Thanks kkaminsk,
Yeh, we got onto them pretty smart, but the damage was already done. As mentioned the dwspy36.dll (and dwspy5.dll) has had issues associated with it ,since spyware became a major headache in enterprise networks.
Is there a case for us, as network support, to request the application vendor to look at repackaging/redesigning their application to not include 'sus' named files that give false positives like this? The said file was also installed in the system32 directory, I believe this should be changed.
I appreciate your feedback, thanks.
Wayne
Yeh, we got onto them pretty smart, but the damage was already done. As mentioned the dwspy36.dll (and dwspy5.dll) has had issues associated with it ,since spyware became a major headache in enterprise networks.
Is there a case for us, as network support, to request the application vendor to look at repackaging/redesigning their application to not include 'sus' named files that give false positives like this? The said file was also installed in the system32 directory, I believe this should be changed.
I appreciate your feedback, thanks.
Wayne
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.