I'd like to suggest some additional management or policy options to allow extra control over Memory Exploit Mitigation policies, and their deployment.
Currently, the below article is all the options we have to effectively tune MEM policies.
https://support.symantec.com/us/en/article.howto127949.html
What I would like to suggest is some form of additional controls, either by adjusting the aggressiveness for example, or by some form of scheduling, for when MEM policies are initiated.
For context. When a MEM policy is initiated on an endpoint, especially for the first time, they will inject a dll file into memory during the operation of one of the applications listed within the policy or will force the app to load into memory. There is currently no control, apart from effectively switching these off and on at this moment in time.
What I've noticed (and maybe others have also), is that this process - at the very least initially - can negativity impact the performance on endpoints. In some instances this is an accepted risk/drawback. However, in many situations, this has seen noticeable user feedback, and performance related concerns around it's deployment to more critical infrastructure or endpoints.
We have noticed this impact has increased since the move to SEP 15. So as an example, some customers who previously had their SEPM enrolled into SEP Cloud, were switched to SEP 15. SEP 15 has then replaced many MEM policies (whether intended or not) with it's own default policy. This has led to several instances where estates have been impacted significantly while this new policy starts the vulnerability scan process.
Ideally, some form of scheduling, or even a "randomize start" type feature - as with administrator defined scans - to help mitigate the risk of this impacting large numbers of endpoints at once.
Regards,
Andrew.