Simple and  Effective

Static Windows as a Problem

Depending on the region of the world, different institutions claim to be able to configure a system more securely than when it was delivered. This claim poses the question of why the system was not already secure in the as-purchased state. The answer lies in the Microsoft ecosystem with its ancient roots. Software that is 20 to 30 years old is still being used in industry, as well as banks and insurance companies. It has to carry on working. Companies expect to be able to continue using their expensive, customized enterprise resource planning (ERP) systems.

You could also tell the sorry tale of Internet Explorer at this point. Techniques that were new when it was established are still in use. Unfortunately, these are not so easy to replace and adapt to today's conditions. Sometimes a solution presents intself – bug fixing, hardening, and more security courtesy of Microsoft – if you simply integrate a patch. However, security-related changes are often only possible after announcements made in advance, because of dependencies on the third-party ecosystem (e.g., if you disable SMBv1, LDAP signing, or the default setting for Excel macro execution). Microsoft itself defined in an RFC at some point the rules of the game and cannot change them dynamically. Other applications rely on the set of rules defined back then. Consider, if you will, the access token with its maximum size of 65,536 bytes. When the size was set, no administrator believed that a user would ever be in more than 1,000 security groups, exceeding the token's maximum size. Now that some large companies are experiencing their third or even fourth AD migration, including taking the security identifier (SID) history with them, space is suddenly at a premium.

SMBv1 can be considered an example of a change for which a long period of notice was given. Every Microsoft operating system from Vista onward speaks SMBv2, but SMBv1 was not removed from the system until Windows 10 v1903, and it can still be enabled in any build – even in Windows 11 – because various devices (e.g., multifunction printers with scan-to-UNC interfaces) still only speak SMBv1.

GPO Templates

Once a Microsoft technology was released or allowed, people started using it, and getting rid of it was very difficult or required individual testing and assessment on the part of an organization. In this dilemma, Microsoft unfortunately cannot act as they would like. Although the limit of functionality is defined by the ecosystem, that does not mean that it would not be better to configure things correctly, which is where templates and recommendations come in. Examples include:

• Microsoft security baselines from the Microsoft Security Compliance Toolkit [4]
• SiSyPHuS, a study of system design, logging, hardening, and security features in Windows 10 from the German Federal Office for Information Security [5]
• Center for Internet Security benchmarks [6]
• US Department of Defense Security Technical Implementation Guide [7]
• Australian Centers for Cyber Security Guidelines for system hardening [8]
• gp-pack Privacy and Telemetry from Mark Heitbrink [9]

Before I look at the individual templates with their advantages and disadvantages, I can issue a blanket statement for all of them: The newer templates go back to the Microsoft baselines and the older ones align with it. Microsoft itself has gone on a major offensive and has started making recommendations on how to make its own system better, in the sense of "harder."

The focus of the templates, with the exception of gp-pack Privacy and Telemetry, is on operating system hardening. In contrast, the reduction of transmitted data (silencing) is usually only rudimentary. It's about security – nothing more, nothing less. Data that Windows sends to a manufacturer can improve security; however, it can contradict the GDPR under certain circumstances, and guidelines as to what is permitted or prohibited are not clear. I recommend sending as little data as possible to ensure continued secure operation. Unfortunately, this plan is defined individually, and as long as there are no legally effective rulings on what is allowed and what is not, admins operate in an unsatisfactory gray area.

Security Template Integration

My recommendation in terms of GPO templates is: Import the values for settings without much to-do and then investigate in the test scenario what you can and cannot implement. The test shows the values that cause errors. If you try to resolve everything up front, you will never get done. Often admins even take out some values for fear that something bad might happen. Of course, you can do a rough review in advance but avoid addressing all the details, especially when many settings are not self-explanatory or refer to algorithm or encryption techniques that you cannot evaluate because the basic technical understanding is missing.

The approach first uses values without any attempt at evaluation, and the test shows whether the value should be kept in the recommended setting. In the end, you have a construct that is genuinely best defined for your company. All values are implemented, and only the requirements from your own infrastructure brought about changes. If an external audit occurs with such a set of rules, only a few results will show up as deficiencies because they were not implemented, and you had no knowledge of these facts. External auditors only apply one of the known yardsticks and check for the existence of rules.

It is important to note that implementation is an ongoing process. It does no good to enable the rules on a cut-off date and then just leave them be for the next few years without making any further adjustments. Rules and regulations are not static and need to be reviewed every six or 12 months. Where vendors provide updates, you will want to check and integrate the updates as soon as possible. The overhead of making small changes on a regular or permanent basis is far less than that of making massive adjustments every two years.

Another important point, quickly clarified, is the selection of the appropriate template, because – in fact – it is simply all those mentioned. There is no debate as to which of the templates is the better or more comprehensive. Each provider has their own ideas that are important in their own value systems, but it would be a mistake not to adopt all of these points, assuming they only generate work and do not cause any problems. Time and labor are unfortunately still the biggest arguments against template integration, which I look at in detail below.