Cryptolocker

The context in which I mention "trivial" is relating to a competent malware author, not an end-user or IT professional.  LoadLibraryEx has a feature (LOAD_IGNORE_CODE_AUTHZ_LEVEL) to circumvent SRP and AppLocker.  Used in conjunction with dll hijacking or macro loading-- for example-- it's very possible to create a malicious dll (loaded by a white-listed application, such as Microsoft Office) which bypasses both.

Without the hotfix I referenced above:

...malware in the %TEMP% or %system drive%:\Users directory can be executed by using the SANDBOX_INERT and LOAD_IGNORE_CODE_AUTHZ_LEVEL flags, even if access to these directories is limited by AppLocker rules.

http://support.microsoft.com/kb/2532445

Privilege escalation techniques could also be deployed as needed (KiTrap0D (In Memory/User), etc.)

Don't get me wrong, I'm a defense in depth advocate-- hardening systems, data backup/recovery, business continuity, etc., etc. should all be part of the design.

I'm merely posing the question, which is much more effective and efficient?  

Having an vulnerable applications run in virtual containers which automatically revert to clean states upon infection or deploying human resources for diagnosing, recovering, reimaging, and restoring?

Encrypting documents aside-- Call me eccentric, but I'd rather have malware with remote access/reverse shell firewall extrusion capability (effectively giving the author access to the victims private network) occur in an (isolated network) virtual container, as opposed to my actual network.

My recommendation is a paradigm shift, which by its very nature is destined to be resisted by the archaic paradigms of the day.

Hi.
> ...to circumvent SRP and AppLocker.
Yes, I read so, but will the authors use it? It would require to trick people into using certain white listed applications and open an attached document that uses that dll trick, that might not even work with any (to-the-author-unknown-) version of (for example) word (if even present) or whatever program.
So applocker poses quite a problem to the authors.

There are many other examples available.  Consider compromising the white listed applications themselves; a recent example is CVE-2013-3918 (MS13-090).  In this case the end user would need only visit a specially crafted web page to become exploited.  Exploitation could inject its payload directly into the memory space of the white listed application (IE).  The malware authors could also negate the need for initial C&C "phone home" requests (for the public key) by dynamically providing a (pre-generated) key upon introduction of the payload.  This could have the side effect of creating unique code for every payload instance-- which would easily bypass signature based solutions.

Again, I'd personally prefer exploitation to take place in an isolated protected space as opposed to my primary OS and private network.

Such attack vectors may be mitigated against by deploying EMET on all Windows systems.

So I pose the question, what is the wisdom in opposing "DMZ for your endpoint" architectures?  My recommendations are not made lightly.  They are thoroughly researched and proved.  I recommend you research FireEye, Invincea, EMET, and OpenDNS.

but will the authors use it?

Is your organization willing to accept the risk that they (and all other malware authors) won't?

Thanks for all the feedback
Some practical solutions and some information that made me realise just how little I know about these threats

Been surfing the net for hours following your links :-)

[If] known, no threat.
Unknown, menace.

:-)

Your welcome.  Take a look at the following course syllabus on Securing Windows and Resisting Malware.  Much of the techniques described above are discussed.