S 4.247 Restrictive assignment of authorisations under Windows Vista and Windows 7

Initiation responsibility: IT Security Officer

Implementation responsibility: User

In Windows, authorisations can be granted for the following areas:

All authorisations must be granted restrictively in general, which means the rights need to be assigned according to the need-to-know or least-privileges strategies (see also S 4.149 File and share authorisation under Windows). This applies without exception to all areas in which authorisations can be granted. The authorisation concept specified prior to the installation of Windows must be implemented (see S 2.325 Planning the Windows XP, Vista and Windows 7 security policies).

For high to very high protection requirements of individual applications, the authorisations can be restricted beyond the safeguards mentioned above which may result in restricted functionality and stability. Under Windows Vista and Windows 7, the effort required for developing and testing a restricted, stable running system can become very high.

In the following, recommendations for the areas mentioned above are given:

File system and registry

The security group "Everyone" should not be used. The security group "Authenticated users" should not be added to any of the pre-installed file folders in the system drive, normally drive C:. In addition, this group should be removed from the security settings of the master folder.

In some folders of the system drive, the right "Write" is assigned to the security group "Everyone" by Windows and other software - particularly in the folder C:\ProgramData. This allows certain anonymous network accesses and script operations, which, in most cases, are not needed and pose a risk. Therefore, this write privilege should be subsequently removed from the individual subfolders. These folders can be found, for example, by using the AccessChk tool.

If high or very high protection requirements regarding the integrity or confidentiality exist, only software which is compatible with the integrity levels, the folder structure and the authorisations restricted by default of Windows Vista and Windows 7 should be installed. Information on this is available from the manufacturer or Microsoft. Furthermore, it is recommended to define dedicated groups for individual applications. In this case, corresponding access authorizations to the software and data in the file system and registry must be granted. When defining the restrictions, it is not only necessary to identify the system-specific directories and files, but also the application-specific directories and files subject to special protection requirements.

If very high protection requirements regarding the confidentiality or integrity exist, the inheritance of default authorisations in system folders, other folders of the system drive and in the registry keys should be disabled in order to assign explicit authorisations for program files and program data. Security groups such as Authorised Users or Administrators must then be removed and replaced by explicit user accounts. If the protection requirements are higher than normal, the owner entries of all folders, files and keys which are not System or TrustedInstaller should also be set to an explicit user account. This makes an attack through other compromised accounts impossible. However, irreparable damage will be caused to the system if the authorisations are set incorrectly. The extra development and testing requirements are therefore only appropriate in case of very high protection requirements.

Analysis tools by third-party providers such as AccessChk can help you to find deviating rights in folder structures and the registry.

Integrity levels

The compatibility mode of Windows Vista and Windows 7, the Microsoft Application Compatibility Toolkit and specific .NET-based software by third-party providers can transfer an application process to a higher integrity level (see S 4.341 Integrity protection in Windows Vista and higher versions). For high or very high protection requirements, such applications should be executed on isolated clients under exclusion of other applications to ensure that these are not threatened. If this is not possible for organisational reasons, it is recommended to secure the program files and data restrictively according to the section File system and registration.

If high or very high protection requirements exist, the execution of components that can skip integrity levels should be disabled. This includes, for example, the Windows Installer and the Windows compatibility mode as well as software for control and recording of the user interface (Snipping tool, remote assistance, VNC, macro recorder). Such components set the UIAccess=TRUE system property. Information on this is available from the software manufacturer. However, it is not possible to install updates and software while the Windows Installer is disabled.

Furthermore, if high or very high protection requirements exist, it may make sense to execute certain program parts on the integrity level low. The command icacls java.exe /setintegritylevel low, for example, executes a Java program from an unknown source on the mandatory level low. However, such restrictions involve a lot of time and effort for adapting and testing the application.

Software by third-party providers can make elaborate, program-specific changes to the authorisations and integrity levels much easier.

System authorisations and user rights

The settings described in the Microsoft documentation entitled Specialized Security - Limited Functionality (SSLF) for Windows Vista and Windows 7 should be used as a basis for high and very high protection requirements . They can be found in the product documentation on the internet or in the Microsoft Technet distribution. Contrary to the word "Specialized" in the title, they are suitable for global use, if no older Windows systems are used and all software used is compatible with Windows Vista and Windows 7. If even more restrictive settings are used, they should be tested on a few clients over several weeks and checked for compatibility with the network and system management and with specialist applications.

In production operations, all system authorisations should be enforced using domain controllers and group policies. System authorisations must never be set to Not configured. Otherwise, they could be manipulated from every account with local administrator rights.

Some important settings not covered by SSLF can be found in the resources for using the relevant module.

Authorisations for shares in client/server networks and home networks

Share authorisations should not be granted to integrated system groups such as Authorised users or Everyone. Furthermore, it is recommended to disable all local user accounts on clients and to only use domain accounts with Kerberos authentication.

The Homegroup function is not suitable for increased security requirements (see S S 4.423 Use of the homegroup function under Windows 7).

Starting programs, scripts and installations

If high or very high security requirements exist, the Windows Installer should be disabled in normal operation. This prevents updates and a majority of the software from being installed. The group policy under Computer Configuration | Administrative Templates | Windows Components | Windows Installer | Disable Windows Installer (Always) is used for disabling.

Review questions:

© Federal Office for Information Security. All rights reserved.