> What's the policy/setting for disabling dll injection?
in the SRP/Enforcement you can enable SRP for DLLs too. In this case all disallowed (which are not explicitly allowed) DLLs will not be executed.
> How about chasing version and controlling apps with SRP?
agree, this is huge question. There is no way to chase app version (unlike Applocker), but there are workarounds, when you can use hash rules for these purposes.
On the other hand, Applocker cannot protect systems from recent Adobe compromise: http://blogs.adobe.com/asset/2012/09/inappropriate-use-of-adobe-code-signing-certificate.html
Applocker cannot differentiate 2 certificates with the same subject (even if they are issued by different CAs). In this case, new Adobe certificate (most likely) will have the same Subject field, as the result all files signed by Adobe (and malware too) will be considered as trusted. To prevent this, you should not use publisher rules, as the result, you can't use app version control.
What's the policy/setting for disabling dll injection?
How about chasing version and controlling apps with SRP? Isn't that an impossible pain too?
I would disagree. DLL injection can be prevented by SRP (though, it is not enabled by default). In addition, this process is not too easy for users.
That's one of the major reasons not to use srp.
Are you sure? I haven't access to these editions and cannot check it.
© 2008 - 2019 - Sysadmins LV. All rights reserved