Microsoft Security Baseline

The Microsoft Security Compliance Toolkit has been at version 1.0 since it was released – the version number has never been incremented. The toolkit provides configuration defaults for any current operating system. For each build, a baseline is released for both the server and the client. Moreover, Microsoft provides suggestions for configuring the Chromium-based Edge browser and the Office 365 package outside of a fixed cycle. This coverage comprises operating systems, browsers, and Office, the three most important areas for Microsoft in the enterprise.

The suggestions are delivered as a ZIP file and always with the same structure. The file contains Excel spreadsheets with the new settings and a PDF that explains the included Microsoft security baseline (MSB) blog post with the changes. The policies come as a Group Policy Management Console backup and can be imported in bulk by a script, but the single values can also be integrated into existing policies with the local GPO (LGPO) utility [10]).

Other administrative templates (ADMX files) have the guidelines as an HTML report, meaning you can take a look at the content before importing. The policies are broken down into user and computer objects and their use cases. BitLocker and Defender are separate policy objects, although they are part of the operating system, because these two tasks are often handled by third-party software. Microsoft saves you a lot of the work by removing unnecessary and unused settings from the policy.

This approach illustrates an important point. Microsoft wants MSB to be used and actively removes any stumbling blocks that might prevent its integration. They have deliberately left out some settings because they (probably) can never be realized in practice. For example, some configurations are set to monitor instead of deny or force. You may well be shocked to discover how easy it is to integrate the policy in practical terms. The name "Baseline" is a good description of the underlying concept. It is the minimum that must be defined, the lowest common denominator that can be introduced without spending a great deal of effort and time on long integration tests.

Microsoft does not prevent telemetry or cloud access in the baseline; some criticism may be justified from a European perspective. Because Microsoft sorts the baseline by topic, it often seems a bit smaller than other rulesets. Microsoft also tries to define MSB for the as-delivered state of the current build and only tries to specify values that are not already implemented. It does not try to reconfigure default values that are already correct. Unfortunately, this process is not implemented consistently. I found definitions for various values in the baseline that have not been necessary since Windows 8 (e.g., WDigest settings). However, because other templates check for the existence of this value, Microsoft has continued to include it to avoid errors in an audit report.

BSI SiSyPHuS

The German Federal Office for Information Security (BSI) expands the Microsoft baseline to include items such as the cloud. However, it has some potential for improvement in the area of telemetry. At the time of writing this article, a new version of SiSyPHuS was in the works; when it would be released was uncertain. Conceptually, in contrast to the MSB, the BSI rules and regulations were created to build on each other. Each object has a "normal" and an "increased" protection requirement (Figure 1). The BSI distinguishes between individual computers and domain members, except for the "logging" policy configuration, which is regulated identically for all systems. This feature reduces triple configurations with identical settings in each policy. If you want to realize a high level of protection for your computers or users, you need to apply at least three group policy objects: Normal Protection plus Increased Protection plus Logging . If you add up the rulesets, the result is then rated high.

Figure 1: Increased or normal protection requirements in GPOs? BSI SiSyPHuS knows the answer.

You find this type of evaluation in other templates, too. The problem is the evaluation itself, which has no rules and has its own value system. The bar for grading each setting is ultimately something you define yourself; there are no real-world arguments. This categorization dates back to the time when the major concern was reducing the administrator's workload. Normal protection has less potential for error than increased protection, so applying the normal level of protection across the board in AD should be the minimum. If you use other adjectives such as "poor" and "good" instead of "normal" and "increased," suddenly things don't sound so cozy. Why should an administrator settle for a normal (poor) configuration when they can implement an increased (good) protection requirement?

If an incident occurs, accusing fingers will point at the administrator, who should always try to configure the network to the best of their ability. Administrators will not want to implement a weak configuration with the knowledge that there is a better way. Merging the two templates into one would take a lot of political hassle out of the system, especially because you will always have debates about every setting as to whether the value is now normal or increased. Just consider the screensaver. To which of the two categories does the value belong? Is it normal because by now all users have gotten used to a screensaver coming on after a certain amount of time, or is it more of a special factor because a password is needed to unlock it again? Depending on the value at stake, discussing how to classify this could well be just a waste of time. The far easier approach here is to integrate without evaluating.

One minor point of criticism relates to the way SiSyPHuS sorts the folders in the ZIP file. Instead of using a single backup folder with a central manifest.xml file such as MSB, BSI stores each policy backup in its own folder. This arrangement might look neatly sorted and structured, but it makes importing the policies more complex, because several sources need to be read instead of just one.

If you slip SiSyPHuS over the Microsoft baseline, you will have no conflicts whatsoever with regard to the set values. The overlapping settings are defined identically. The thinking on the question of what is considered secure is unanimous. Unfortunately, SiSyPHuS is defined for 1809 LTSC, so no practical ruleset has emerged here. The Long-Term Servicing Channel (LTSC) version was never intended for normal operation, and most companies have long since switched to the semiannual channel versions. Moreover, build 1809 is already three and a half years old and lagging far behind the current requirements.

CIS Benchmarks

The Center for Internet Security (CIS) has been providing suggestions for hardening IT systems for many years, and Microsoft is just one of many operating systems covered. Microsoft's Aaron Margosis and Rick Munk are involved in the CIS benchmarks; they also happen to be the two leads on MSB. CIS offers security configurations from Apache to Zoom. These evaluations can be assessed retroactively and compared with specifications.

CIS is a complete system: In the case of Microsoft policies, it provides GPO backups and delivers a build kit that automatically integrates and redeploys version changes and updates; alternatively, it can make changes to existing policies. It also comes with comparison tools and can work out the score that a system achieves on the basis of the benchmark's internal rating system. Both GPO backups and the build kit are commercial products.

Available free of charge is a 1,300-page PDF that contains all settings. This tome can seem extremely daunting at first sight because of the sheer mass, but if you frequently use the GPO editor and feel at home there, you can convert the PDF into a GPO with just two hours of hard work. CIS understood years ago that the best way to document group policies is to follow the structure of the Group Policy Editor. In the editor, you start at the top in Policies and end up in the Administrative Templates | Windows Update area. This is exactly the order that CIS uses for the PDF.

The sheer volume of the PDF results from the excellent documentation of each value. Each setting has a short explanation describing the effect. Additionally, the document names each value with its policy and shows the registry entry behind it so that its existence can be checked on the target to enable compliance.

Also interesting is that the default value of the system is documented. The CIS benchmark often sets values that confirm the default in a GPO, which helps orient the actual state on the build if the system was not installed by the customer (e.g., by an OEM hardware partner). By the way, third-party installation is never a good idea, because manufacturers also earn money from advertising. You tend to end up with too much software garbage on the systems, and nobody knows what the software manipulates.

The benchmark is similar in structure to BSI SiSyPHuS, defining Level 1 and Level 2 , which are equivalent to normal and increased . More recently, CIS has attempted to provide further assistance in the form of the implementation groups construct (IG1 to IG3). The groups reference other CIS tools and attempt to create an assessment outside the terms of the Levels. Approximately 150 evaluation categories meet a varying number of criteria, from IG1, with some 50 criteria met, to IG3, with all criteria met. IG1 is defined as essential cyber hygiene.

Just as with BSI, what this variant is good for remains a mystery. Money might be the prime motivation. Again, administrators will want to avoid delivering a system with a poorer configuration than they could easily achieve. The requirement is that the system meet the best possible configuration. However, this can mean something different for a machine controller in production than for an office PC in administration. It is a good idea to aim for the best possible approach and not make concessions that mean less work for the time being but are likely never to be further hardened because no one is around to do the work.