On the other hand no one believes me when I say the rule is ridiculous because if it was, then why would McAfee be suggesting it as a way to combat CryptoLocker? It MUST be a good rule if Intel is proposing it... UGH.
Sorry about that.
Tell those folks that Intel Security folk feel obligated to provide every plausible avenue or to leverage every mechanism available in combating the malware threat. They're not intended as a "This will work for you and everybody else". The particular example you cite contains AGGRESSIVE rules, which will be subject to false positives. But for an environment that doesn't run screensavers... or logon scripts... there are many environments out there that run with a LockDown type of configuration.
Instead of writing them off as crazy, you might assess if there's an implementation that provides similar or better protection; something more suited to your environment.
e.g. instead of blocking SCR at the client, block it at the gateway.
I agree with you, these should not be interpreted as "You must do this". We also avoid providing you rules that turn your system into a brick. And, because that has happened before (someone misreads a policy or Typo's a path entry), always exercise care when implementing Access Protection rules. Putting it in REPORT mode to start with is smart, until you're confident no adverse effects could come of it being set to Block.
Believe me, new access protection rules stay in report only mode for weeks before I ever would consider checking that "block" box. Some of these rules are real clunkers though. I can't even afford to leave a rule in report mode that dumps 300,000 hits to the event log each day.
What would make Access Protection useable in these circumstances would be if there were a way to specify exclusions in the target path.
Like don't let any *.scr files to be executed except for .... But the only exclusions are available for the calling process, and that is not enough in almost all cases.
I have very few executables that I need to let users run out of AppData, but I do have a few. Unfortunately, the Access Protection rules are all or nothing, so either I block all exes or none. I wish there were a way for me to exclude particular targets in the File target value.
like block access to all **\Users\**\*.exe except for this list [myprogram.exe,myotherprogram.exe,etc]. I have to trow out the good with the bad, and since I absolutely cannot block the "good" I also am unable to block the "bad". There is just no way to write exclusions that are effective.
Yes, you are describing a problem that we solved with Endpoint Security 10.1.
The expanded capability of the Access Protection feature in that release is a welcome relief.
I've started reading about that. I may not be fully understanding the product, but my initial though is that the idea of a single policy to cover the whole suite is a real stinker. But that is a whole different discussion.
I am testing the same thing!
300k hits! how many systems you have?
now I am testing the rules, the one I got many hits is rule number 3 from
Generic mildly aggressive Access Protection Rules
we should disable the report though if we have too many events from rule number 3.
now regarding HIPS protection
did you try this? on page 5 of the document
HIP signatures 6010 and 6011 block the injection immediately. Ensure they are enabled.
I tried them and it blocked browsers and acrobat and I have to exclude them