Recently I have deployed Software Restriction Policies to block certain paths from being able to run *.EXEs .
I have found this to be extremely successful and easy to manage with one exception:Java.
Here is what I have implemented as of now.
Please disregard Spotify being allowed. It is a client network, so I lost that battle.
The current rule for Java works like a champ. The only problem with this is that Java changes its updater name with every version pushed out. So here is the question...How to I allow java in such a way that I don't have to add an exemption for each version? (I know I can do this ahead of time, but with a great number of clients this isn't a practical solution. Neither do I want more than a couple rules for one program)
I have tried using wildcards to no avail. It seems the wildcards don't work as I would think they would. The following is a small sample of what I have tried.
%userprofile%\appdata\local\Temp\jre-*.exe
%userprofile%\appdata\local\Temp\jre*.exe
%userprofile%\appdata\local\Temp\jre*-windows-i586-iftw.exe
%userprofile%\appdata\local\Temp\jre-?u??-windows-i586-iftw.exe
%userprofile%\appdata\local\Temp\jre???????????????????????.exe
At this point I understand it may not be possible, but I figured I would bring it the forum to get some over-sized brains together.
Obviously this is a response to CryptoLocker, Zeus and the others. If I cant find a way to dynamically allow certain programs like this I may just use the zipped folder paths, and scrap the rest. It seems that the main point of infection for my clients are the fraudulent emails (not the compromised sites) which generally encapsulate their EXEs in zipped folders.
Thanks in advance!