T 3.81 Inappropriate use of security templates for Windows Server 2003 and higher

Windows Server 2003 and higher allows you to copy the settings in templates directly into the system configuration. There are three template types for this purpose:

• Files with the .inf extension, called security templates in Windows Server 2003 and higher, are edited in the Security Configuration Editor (SCE).
• XML templates, referred to as security policies in Windows Server 2003 with Service Pack 1 and higher, are edited using the Security Configuration Wizard (SCW).
• Files with the .pol extension (Windows NT 4.0 templates) can also be used with Windows Server 2003.

All types mentioned are referred to in the following as security templates. They change the system configuration as soon as they are applied.

Besides the so-called security templates, there are also administrative templates (.adm extension).

In Windows Vista, the ADM files have been replaced by ADMX template files. These files use a new syntax based on XML for the registry-based policies. ADMX files offer the advantage that, in contrast to ADM files, they are language-independent and can be used with any language version in connection with language-specific ADML files.

In contrast to ADM files, ADMX files are no longer loaded individually into each group policy object and are instead administered in a central store. Since the Group Policy Management Console and Group Policy Object-Editor group policy snap-ins connect to the PDC Emulator by default, it is recommended in an Active Directory-based environment to place the central store for the ADMX/ADML files in the SYSVOL directory of this operations master. The operation master roll PDC Emulator emulates a primary or backup domain controller in Windows NT to ensure downward compatibility.

It is also possible to define your own administrative templates. This approach is particularly recommended when direct registry settings are commonly used in the institution. Since it is only necessary to define an administrative template once in this case, the corresponding registry settings can be comfortably distributed via the Group Policy mechanism. Among other things, this ensures that the registry settings are actually implemented on all target computers.

As security templates have profound effects on the system configuration, there is the risk that certain functions or the whole server will not be available if they are not tested. If the templates are rolled out automatically on multiple servers with the help of group policies or scripts, then operational disruptions or even the complete failure of the whole information system may be the result.

For these reasons, improper handling of security templates leads to a high potential for risk.

Possible threats can already be caused when creating the security templates due to incorrect handling. An analysis of the requirements is usually performed before the templates are created. Afterwards, a reference system is analysed manually by the administrator or automatically by the SCW. The analysis processes analyse numerous server components and settings that affect the operating system in a fundamental way. The analysis processes might not be complete or may fail for technical reasons without being noticed. The underlying security databases and security catalogues may be corrupt or not up to date. In addition, programmes from third-party manufacturers or special system configurations may have an unexpected influence on the analysis procedure.

The SCW is able to convert the security templates from the SCE and integrate them into its security policies files. This can lead to conflicts in certain parameters. In general, security templates can benefit from the distribution mechanisms of Active Directory and group policies, but to obtain full benefit, all template types must be converted to group policy objects or - in the case of .pol files from Windows NT 4.0 - be migrated. Conflicts and compatibly problems can also arise due to conversion or migration.

Installing security templates onto a server can fail when the server does not meet the requirements for the particular template. Older applications not developed for the current Windows versions often have unexpected side effects.

In addition, authorisation settings set to Refused in the template can cause unexpected responses that are difficult to eliminate.

In all cases described, there is a risk that a template will not have the intended effect and the system will be placed in an unknown state.

The risks are significantly higher when the security templates are not tested during development and roll out or the reference systems used for testing do not represent the actual systems.

Finally, inadequate technical and organisational implementation and testing of the distribution mechanisms for security templates can place the information system at risk. If roll out operations fail without being detected, then there will be inconsistencies in the servers. Thus, the configuration does not fully correspond to the specifications so that the security objectives are not achieved either. When developing and incrementally rolling out additional templates, some target systems might not meet the expected requirements any more in this case. This situation is referred to as a situation lacking policy conformity.

Security templates from Windows NT 4.0 (.pol files) are more at risk of having conformity problems and being incompatible with other template types. No tools are provided for .pol files in Windows Server 2003 and higher any more, and the manufacturer does not provide support any more for these files.