Software Restriction Policy is deprecated by Microsoft (technet effectively claiming SRP is not supported), depuis Windows 7 Enterprise/Ultimate introduced AppLocker.
In practice SRP has certain pitfalls, for les deux false negatives et false positives. AppLocker has le advantage that c'est encore being actively maintained et supported. If AppLocker is an option alors it could be le cheaper one - après accounting for votre time et risks taken. C'est aussi possible il y a a suitable third-party alternative (but this question didn't include that option 🙂.
Hopefully you'd gain perfect understanding of SRP's pitfalls avant you fall into tout of them </sarcasm>. Some of them are described in a nice security article from Vadims Podāns.
Known pitfalls
"To enumerate tous folders avec users write access you can use, par exemple, AccessEnum utility depuis Sysinternals pack." (or AccessChk).
An NSA document gives 16 examples of folders to blacklist with SRP (although le registry path rules use backslashes incorrectly so must be corrected - see point on registry paths below) et warns about a common over-broad blacklist entry.
The obvious question is why ne sont pas we carefully whitelisting individual paths under \Windows instead. (Including le \Windows\*.exe legacy, System32\*.exe, etc). Je n'ai pas notice tout answers to this anywhere 🙁.
Using environment variables like %systemroot%, SRP can be bypassed by users by clearing le environment variable. These are pas used in le suggested defaults. However they may be tempting to use. This footgun is fixed in AppLocker, parce que it jamais looks at environment variables.
The suggested defaults neglect to allow for le two différent \Program Files used on modern 64-bit installs. When resolving this using le more secure "registry paths", there are reports of false denials in random situations, qui could easily be missed in testing. e.g. see comments on SpiceWorks SRP howto. Ceci est to do avec 32-bit applications reading relevant paths depuis le WOW6432Node of le registry: resolution is to add both these paths to SRP to allow tous programs to work on 32-bit et 64-bit machines as Unrestricted si started depuis an x64 ou x86 host process: %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
The par défaut extensions neglect to forbid PowerShell scripts (*.PS1) supported by Windows. (See video). And APPX too. Also according to Microsoft's comparison table, SRP ne peut pas manage "Packaged apps" in Windows 8; J'ai no idea what this means.
Registry path rules must pas have slashes immediately après le dernier percent sign (despite being included in Microsoft's own built-in rules for XP/Server 2003) et tout backslashes must be replaced avec forwardslashes in order for le rule to work (1/2/3).
Of le sources J'ai trouvé for SRP, none put le full list ci-dessus together for you. And I seulement discovered Vadims Podāns' article by accident. What else is lurking out there?
Many sources recommend simply removing LNK files depuis le list. (And Web Shortcuts to avoid breaking Favourites?!). Disturbingly, no sources seem to discuss LNK vulnerabilities... or getting script interpreters to run files with an unexpected extension e.g. P9... ou maybe stuffing enough shellcode in an inline script parameter... etc.
If you essayez de compromise by allowing LNK files on le desktop, et you leave users avec write access to le desktop, they can now bypass votre policy entirely. Lovely tip depuis Vadims Podāns again. Note that le explanation applies to using tout extension in a path rule. Microsoft present multiple examples of this including *.Extension, avec no warning. So you ne peut pas trust le official documentation, et it seems unlikely to get fixed now.
[Potential AppLocker disadvantage]. Vadims Podāns reports that SRP entries using mapped drives do pas work. The UNC path must be used instead. Maybe they would alors apply to access through a mapped drive? c'est pas 100% clear. Apparently AppLocker was different: it didn't work avec soit 🙁. "Due to unknown reason, UNC paths doesn’t work in Applocker! This means that si votre application is installed in network, you have to create soit hash ou publisher rules."
Pragmatic approach
Software whitelisting is potentially a very powerful defense. If we get cynical: this is exactly why Microsoft deprecates le lower-priced versions et invents more complex ones.
Maybe no autre option is disponible (include 3rd-party solutions). Then a pragmatic approach would be to try configuring SRP as simply as possible. Treat it as an extra layer of defense, avec known holes. Matching le pitfalls above:
Start depuis le par défaut rules (from le pre-Win7 era 🙂.
Prefer to pas use environment variables, e.g. %systemroot%.
Add rules to make sure les deux \Program Files\ directories are permitted on modern 64-bit machines. The extra "registry paths" vous devrez add for \Program Files\ on 64-bit computers are %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% et %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
When adding to registry path rules, leave out tout backslash immediately après le percent sign, et replace tout further backslashes \ avec forwardslashes / (e.g. %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
Add PS1 to le list of controlled extensions.
Understand that a manageable SRP configuration is pas secure against a user determined to defeat it. The aim is to help/encourage users to work within le policy, to protect them against attacks like "drive-by downloads".
Allow LNK files. (Preferably by removing it depuis le extensions list, pas through certains path rule).
See point 7 🙂.
Make sure votre logon script folder is permitted. The NSA document suggests adding \\%USERDNSDOMAIN%\Sysvol\. (See point #2, sigh, alors see point #6).
