Application Whitelisting is probably the best protecton agains most crypto trojans (after backups or course).
The basic idea is that only software in specific directories (Windows and ProgramFiles) is is allowed to run, but everything else is blocked, and restricted users do not have write permission in the permitted directories.
Thus only admin can install writable programs, and admin is usually more careful than users.
Users cannot involuntarily trigger execution of email attachements, or web downloads, not even most driveby downloads that exploit a vulnerability in the web browser or an installed plugin.
AppLocker and SRP can be used to do blacklisting or whitelisting. Whitelisting is much more secure, but more likely to be unpleasant for the users.
Blacklisting can be used to block execution of programs in the directories through most infections today occur. Whitelisting allows only specific directories, and blocks everything else.
SRP existed already in Windows XP, and remained mostly(?) unchanged in 7, 8 and 10. It is included in the editions Pro, Ultimate, Enterprise, and Education.
AppLocker is available since Windows version 7, but only in Enterprise and Education editions. Applocker seems to exist Pro editions, because it can be configured, but it cannot be activated there (Microsoft is sometimes nasty).
The rest of this page is about SRP.
SRP can be configured in gpedit.msc, secpol.msc, and via GPO
THIS SECTION IS UNDER CONSTRUCTION
Beware of Microsofts automatic switching of defaults as soon as you activate SRP. The UI starts with having deny as default action for new rules which you add. But as soon as you turn SRP on, the default for new rules switches to allow.
As precaution you should first turn SRP on, before you add rules. This is possible, because Microsoft inserts two default rules. If you first add rules, and then activate it, you might involuntarily end up blocking important software, maybe even lock yourself out of Windows.
The UI behaves nicely when you add rules, but note that when you edit existing rules, the preselected button (which is activated when you just press the RET key to finish editing) is abort, i.e. discard your changes. I have never seen this anywhere else in Windows.
The default SRP of Windows does not directly specify paths, but names of registry values, which contain these paths.
In theory this is a good idea, because it catches special cases when the Windows directory is not on drive C:.
However some device drivers appear to load before interpretion of registry values is available,
and thus fail to load. You should thus manually add the paths
C:\Windows
C:\Program Files
When you activate SRP, Windows automatically inserts two default rules. This is great because otherwise you could easily make Windows fail completely, with no easy possibility for repair.
However the default includes only the Windows and the normal ProgramFiles directory.
Microsoft forgot that there is 64bit Windows, which has two ProgramFiles directories.
Thus with the defaults on a 64bit Windows only 64bit software works, but all 32bit software fails.
You must manually add the directory
C:\Program Files (x86)
There are two more missing items in the defaults, and these ones are outright dangerous.
You would probably not expect that some subdirectories of C:\Windows are writable
by everyone. It seems that the people who made the defaults for SRP did not know either.
You should add disallow rules for
C:\Windows\System32\Com\dmp
C:\Windows\System32\FxsTmp
C:\Windows\System32\spool\drivers\color
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\Tasks
C:\Windows\Registration\CRMlog
C:\Windows\Tasks
C:\Windows\Temp
C:\Windows\tracing
Some software puts executables and/or DDL library files in places where they should not be,
for example
C:\ProgramData
You should not allow executables to run from these directories. Sometimes you must
permit a single file or subdirectory, but do never ever allow the whole directory, because every user
can create a subdirectory there, and has write permission in that.
See also: Sophos with SRP breaks DNS.
THIS SECTION IS UNDER CONSTRUCTION
see also Make Dropbox compatible with SRP
It is generally a good idea to inspect Event Viewer after activating SRP. Because everytime SRP blocks something, it creates an entry there, that tells which file was blocked.
Alternatively you can set SRP to report only, not block, and let it run in this mode a few days before fully activating it. Then Event Viewer can tell you potential issues before they happen.