I'm only beginning to grasp these processes myself, but for right now it's my job so I spend a lot of time trying. From what I've come to understand, AP Policies don't block at the file level, they block at the process level. I have loads of instances where svchost.exe (a process) is attempting to execute a particular .dll (file). These files include SQL, Citrix, Java and others; all legitimate functions. These programs run because I don't have the rule turned on but if the rule was enabled these programs would not run. I cannot turn this rule on for the sake of my well behaved programs but also to the detriment of a potential outbreak which I would not see until I observe my dashboard and see there's a problem. Since AP policy is run at the process level, I cannot say to svchost, "go ahead and do your thing but don't touch my Citrix dll's" etc. So for now, I just report and watch, and hope that svchost.exe doesn't actually launch anything harmful.
This is not just a real shame, I consider it pretty damn usless. I can't use the rule because my programs won't run and I can't work with it to exclude valid operations. I can't ignore it as I may end up regretting it, so it fills my log files every day, consumes my time examining and filtering the logs, takes up space on my limited resources and makes my life miserable because I gotta think about it.
Ok so that's a bit melodramatic, but I hope I've made my point; and that's just one rule. I hope McAfee gives us a way to be more flexible, otherwise this is a throw away function. Too many of those, and I wonder what the hell I'm paying for?
Turns out the CCMEXEC.EXE is problem with McAfee being more agressive with VSE 8.8 on self protection. One component of SMS handles licensing. As such when CCMEXEC.EXE starts up it needs to look at every running program, including the McAFee stuff. It asks for full permissions to the processes, which includes the right to terminate them. McAfee is no longer waiting for requests that actually terminate their processes to act. They now block requests for access rights that would allow the process to be terminated at some later time.
I could allow CCMEXEC.EXE to be an exception to the self protection rules. But SMS scripts install stuff, or could be scripted to disable McAfee. I could turn off reporting of violations of these rules, leaving protection in place. But then I would be blind as to other stuff going on.
McAfee needs to get with Microsoft and build some exceptions into their products. Until then I have logs full of false positive messages.
Did you get anywhere further with this ??? It is completely flooding my threat event log
Not really. McAfee Platinum support just pointed the finger at Microsoft and said it is their issue. So currently I have two very undesireable choices available. Turn off reporting on the self protection rules, which leaves me blind to any other process or user that is play around trying to turn things off.
Going in an making exceptions for CCMEXEC.EXE for all these self protection rules. Then if one of our SMS guru's writes a script to turn off McAfee services I will never see it. If they push out a package that some "helpful" vendor has provided that turns of VSE to "help" the install, I will never see it.
Making the exceptions for CCMEXEC.exe currently my choice of the lesser of two evils.
McAfee has shown no willingness to provide options around how agressive their self protection is going to be. They take the stance that the rest of the world will just have catch up to their programming. That it is our responsbility to have vendors update the programs and for us customers to go all the work of upgrading other stuff. They feel they can brake existing processes at will.