Two default protection policies are designed to tightly restrict access to specific host functionality, the SCSP Strict (sym_win_protection_strict_sbp) and the SDCS:SA Whitelisting  (sym_win_whitelisting_sbp) policies.  The Strict Windows protection policies prior to the 6.5 release do not sufficiently restrict access to members of the Administrators group in some cases.  Previously, an authenticated user could take advantage of shortcomings in deployed protection policies, gaining unauthorized access to restricted functionality on a host.

Please note that adding these additional security settings cannot be applied to all servers, as functionality that is prevented may be required in some environments.  If you are running a Windows Protection policy from a release prior to 6.5, this article will explain some additional changes that can be made to existing 5.2.9 and 6.0 Protection Policies in order to lock down systems.  Take note that these controls can impact certain functionalities and as such should not be considered a general purpose enhancement. These changes should be tested thoroughly prior to deployment to ensure that they don’t break your specific environment.
 
1. The policy doesn’t block configuring an executable as a Windows Services. Using the Windows protection policies from releases prior to 6.5, the controls around Windows services are not sufficient to block access to authenticated Administrators in all cases. You must evaluate and test these changes thoroughly before deploying them to a production environment. The steps to tighten the controls around Windows services are as follows.

5.2.9 Windows Strict Protection Policy
>>>Advanced Policy Settings
   >>>Interactive Program Options
      >>>Alternate Privilege Lists
         >>>Specify interactive Programs that should not start
            Program path: %systemroot%\system32\sc.exe
 
   >>>Service Options
      >>>Additional Parameter Settings
         >>>Disable service execution of specific programs
            Program Path: %systemroot%\system32\sc.exe
 
6.0 Windows Whitelisting Protection Policy
>>>Advanced
   >>>Advanced Policy Settings
      >>>Sandboxes
         >>>Default Windows Program and Services [def_winsvcs_ps]
            >>>General Settings
               >>>Sandbox Execution Options
                  >>>Programs the Default Windows Applications may not run
                     Program path: %systemroot%\system32\sc.exe
            >>>Registry Rules
               >>>Read-only Resource Lists
               >>>Block modifications to these Registry keys
                  Resource Path: \REGISTRY\MACHINE\SYSTEM\*controlset*\Services
                  Resource Path: \REGISTRY\MACHINE\SYSTEM\*controlset*\Services\*
         >>>Basic Sandbox [basic_ps]
            >>>Registry Rules
               >>>Read-only Resource Lists
                  >>>Block Modifications to these Registry keys
                     Resource Path: \REGISTRY\MACHINE\SYSTEM\*controlset*\Services
                     Resource Path: \REGISTRY\MACHINE\SYSTEM\*controlset*\Services\*
      >>>Global Policy Options
         >>>Global Policy Lists
            >>>List of processes that services should not start [global_svc_child_norun_list]
               Program path: %systemroot%\system32\sc.exe
 
 
 
2. There is the possibility of remote persistent code execution via RPC. The existing network controls around RPC limit network access to hosts within the Local subnet. To mitigate this issue, the protection policies can be modified to block the RPC service from accepting inbound network requests from untrusted systems.  You must evaluate and test these changes thoroughly before deploying them to a production environment. It is critical that all Windows domain members are allowed to communicate with the domain controllers or user logins will be blocked. Note: This change will break domain logons on a domain controller. If this change is made to a domain controller, domain members will be unable to login on domain client-machines unless their machines are added to the inbound host list for the RPC sandbox. The steps to do this are as follows.

5.2.9 Windows Strict Protection Policy
>>>Advanced Policy Settings
   >>>Sandboxes
      >>>Remote Procedure Call (RPC) [rpcss_ps]
         >>>Network Controls
            >>>Inbound hosts list
               Remove all entries from the list except “Local IPs (v4 and v6)”
               Add entries to the list for trusted systems
 
6.0 Windows Whitelisting Protection Policy
>>>Advanced
   >>>Sandboxes
      >>>Remote Procedure Call (RPC) [rpcss_ps]
         >>>Network Controls
            >>>Inbound hosts list
               Remove all items from the list except “Local IPs (v4 and v6)”
               Add entries to the list for trusted systems
 
 
3. The Local Security Authority Subsystem Service (LSASS) stores credentials in memory for users with active Windows sessions. Microsoft has a write up for this located at http://technet.microsoft.com/en-us/library/hh994565.aspx .  It is possible for an authenticated local user to extract these passwords from memory. If you are using the Windows Protection policy from 6.0.0 MP1 or later, you are already protected.  To mitigate this issue with older policies, you can change the policy to prevent access to the running LSASS.exe process.  The steps to do this are as follows.

5.2.9 Windows Prevention Policy
>>>Advanced Policy Settings
   >>>Global Policy Options
      >>>Process Access Controls
         >>>No-Access Process Access Controls
            Block all access to these processes
            Target program path: %systemroot%\system32\lsass.exe
 
6.0 Windows Prevention Policy
>>>Advanced
   >>>Advanced Policy Settings
      >>>Sandboxes
         >>>Local Security Authority Subsystem Service
            >>>Local Security Authority Subsystem Application Data Protection
               >>>Local Security Authority Subsystem Application Process Data
                  >>>Block all access to the following Local Security Authority Subsystem processes
                     Program path: %systemroot%\system32\lsass.exe
 
 
4. The Windows installer can be used to add and remove software but also to execute arbitrary code. The existing controls around the Windows installer are implemented to provide maximum compatibility and to allow Windows updates to be run while the system is protected.  Because of this, there is the possibility of arbitrary code execution via the Windows Installer.  There are mitigations for this but it does impact the functionality of the system. You must evaluate and test these changes thoroughly before deploying them to a production environment. Once these changes are made, no updates to the system can be made in terms of adding/removing programs or windows updates. In order to be able to install software or updates you must disable prevention or otherwise undo the mitigation. The steps for this are as follows.

Remove the existing Safe privilege entries for msiexec
5.2.9 Windows Strict Prevention Policy
>>>Advanced Policy Controls
   >>>Interactive Program Options
      >>>Alternate Privilege Lists
         >>>Specify interactive Programs with Safe privileges
            >>>Remove the entry for Program path: %systemroot%\system32\msiexec.exe
   >>>Service Options
      >>>Alternate Privilege Lists
         >>>Specify Servers with Safe privileges
            Remove the entry for Program path: %systemroot%\system32\msiexec.exe
 
Do not allow msiexec to run
5.2.9 Windows Strict Prevention Policy
>>>Advanced Policy Settings
   >>>Interactive Program Options
      >>>Alternate Privilege Lists
         >>>Specify interactive Programs that should not start
            Program path: %systemroot%\system32\msiexec.exe
 
   >>>Service Options
      >>>Additional Parameter Settings
         >>>Disable service execution of specific programs
            >>>Program path: %systemroot%\system32\msiexec.exe
 
6.0 Windows Whitelisting Prevention Policy
>>>Advanced
   >>>Advanced Policy Settings
      >>>Sandboxes
         >>>Default Windows Program and Services
            >>>General Settings
               >>>Sandbox Execution Options
                  >>>Programs the Default Windows Applications may not run
                     Program path: %systemroot%\system32\msiexec.exe
 
      >>>Global Policy Options
         >>>Global Policy Lists
            List of processes that services should not start [global_svc_child_norun_list]
            Program path: %systemroot%\system32\msiexec.exe
 
 
5.  The existing controls around Windows Management Instrumentation provide compatibility with WMI functionality. Because of this, there is the possibility of arbitrary code execution via Windows Management Instrumentation. There are mitigations for this but it does prevent adding or removing WMI scripts to your configuration while prevention is enabled. If you want to modify your WMI configuration you would need to disable prevention or otherwise undo the mitigations. You must evaluate and test these changes thoroughly before deploying them to a production environment.  The steps to mitigate this issue are as follows.
 
5.2.9 Windows Strict Prevention Policy
>>>Advanced Policy Settings
   >>>Global Policy Options
      >>>File Rules
         >>>Block modifications to these files
            Resource Path: %%-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\MOF Self-Install Directory%%
            Resource Path: %%-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\MOF Self-Install Directory%%\*
   >>>Interactive Program Options
      >>>Alternate Privilege Lists
         >>>Specify interactive Programs that should not start
            Program path: %systemroot%\system32\wbem\mofcomp.exe
   >>>Service Options
      >>>Additional Parameter Settings
         >>>Disable service execution of specific programs
            Program Path: %systemroot%\system32\wbem\mofcomp.exe
 
6.0 Windows Whitelisting Prevention Policy
>>>Advanced
   >>>Advanced Policy Settings
      >>>Sandboxes
         >>>Default Windows Program and Services
            >>>General Settings
               >>>Sandbox Execution Options
                  >>>Programs the Default Windows Applications may not run
                     Program path: %systemroot%\system32\wbem\mofcomp.exe
      >>>Global Policy Options
         >>>Global Policy Lists
            >>>List of processes that services should not start [global_svc_child_norun_list]
               Program path: %systemroot%\system32\wbem\mofcomp.exe
         >>>File Rules
            >>>Read-only Resource Lists
            >>>Block modifications to these files
               Resource Path: %%-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\MOF Self-Install Directory%%
               Resource Path: %%-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\MOF Self-Install Directory%%\*