Generell gesagt finden sich keine technischen Neuerungen im Bereich der Gruppenrichtlinien für lokale Installationen von Windows Server 2022. Die GPO-Infrastruktur und die zur Verfügung stehenden Funktionen sind statisch und es gibt keine Entwicklung mehr in diesem Bereich. Innovation und Änderungen entstehen in der Cloud. Dort stellt Microsoft diverse Funktionen zur Verfügung, allerdings nur dann, wenn IT-Verantwortliche den passenden Plan beziehungsweise Vertrag abschließen. Doch noch immer gibt es out of the box in einem reinen Azure AD nichts, was den Client so umfänglich steuert, wie Gruppenrichtlinien es lokal können. Vor diesem Hintergrund werden wir uns um neue beziehungsweise veränderte Ansätze kümmern, die sich in über 20 Jahren Gruppenrichtlinien-Design und -Struktur ergeben haben. Wir besprechen Regeln, die heutzutage – nach vielen Jahren mit GPOs – umgesetzt sein sollten, auch wenn sich daran technisch nichts geändert hat und die Best Practices seit Jahren Gültigkeit haben.

Haben Admins zu Beginn des Active Directory (AD) in den 2000er-Jahren mit der Konfigurationen des Desktops gehadert, so gilt heute der größte Aufwand der Abwehr von Ransomware und dem Damoklesschwert der DSGVO bei einem möglichen Datenverlust. Verwundert stellen wir fest, dass die wenigsten ADs in ihrer Delegation und den Gruppenrichtlinien diesen aktuellen Anforderungen gewachsen sind.

Den von Ransomware-Attacken betroffenen Unternehmen ist oft vieles gemeinsam – hauptsächlich eine IT-Struktur, wie sie vor 20 Jahren aufgebaut wurde. Sie vernachlässigen seitdem, Grundlagen zu ändern und Strukturen aktuell zu halten, stattdessen standen andere Themen als das AD als zentrale Anmelderessource im Fokus. Benutzer anmelden funktioniert doch einwandfrei, warum sollte es hier eine Baustelle geben? Dieses Denken fällt den Unternehmen jetzt auf die Füße. Nachdem eine Ransomware es in das Unternehmen geschafft hat, verbreitet sie sich gerne per "psexec" und einer Batch-Datei, verteilt über den Admin-Share.

Das ist NT4-Technik, die heutzutage immer noch gang und gäbe ist und viele Administratoren nutzen sie in der täglichen Arbeit. Die Türen und Tore sind intern offen, es gibt kein Firewallkonzept zwischen den Clients, kein Software-Allow-Listing, keine Abgrenzungen der administrativen Konten in ihrem Wirkungsbereich und die Kennworte verdienen ihren Namen als "Geheimnis" nicht. Vielmehr findet Password-Recycling statt, identische Kennworte kommen für diverse Accounts zum Einsatz und das Passwort des Administrators der Domäne ist gerne mal 15 Jahre alt. Beim letzten Versuch, das Kennwort zu ändern, sind so viele Dienste ausgefallen, dass es leichter ist, das alte zu behalten, als alle Stellen zu finden, wo es hinterlegt ist. So und ähnlich jedenfalls klingen oft die gesuchten Entschuldigungen, wenn die Dinge bei einem Audit, Health-Check oder einfach nur im Gespräch mit einem Dienstleister zu Tage treten. Und im schlimmsten Fall ist es eine Ransomware, die diese Fehler ausnutzt.

Mit Gruppenrichtlinien haben sich Admins lange und viel um das Thema Konfiguration und Customizing gekümmert. Mittlerweile liegt der Schwerpunkt mehr bei den Sicherheitsanforderungen, aber auch der Reduktion von Telemetriedaten. Das Rad muss der IT-Verantwortliche aber nicht neu erfinden, denn die Technik ist vorhanden und die Richtlinien existieren.

Die Herausforderung, der sich heute ein Administrator in Sachen Gruppenrichtlinien stellen muss, ist die Frage "Was muss ich konfigurieren?" Die Antwort hängt wie immer an den eigenen Möglichkeiten: Einige Konfigurationen sind als Richtlinie nur ein einziger Schalter und damit aus Richtliniensicht extrem trivial. Es passiert nicht viel mehr, als einen Registry-Wert anzuknipsen. Die Funktion dahinter erfordert aber oft die richtige Hardware, wie beispielsweise im Fall des virtualisierungsbasierten Schutzes der Codeintegrität. Oder es sind eine Zertifikatsinfrastruktur und Prozesse erforderlich, um Code Signing umsetzen zu können. Oder wir sind mit Organisationsfragen konfrontiert, wenn der Administrator ab jetzt drei, vier oder gar noch mehr Konten zur Administration (je nach Sicherheitskreis oder Ebene) zu bedienen hat.

Bei der Suche nach dem "Was" können vordefinierte Schablonen helfen, denn es gibt Hersteller, die fertige Richtliniensets anbieten und zum Download bereitstellen. Andere verlangen Geld dafür oder sie liefern ein komplett dokumentiertes PDF, das der Admin selbst in eine GPO umsetzen muss.

Bevor wir über die generellen Methoden und Regeln reden, die unabhängig von Windows Server 2022 sind, einige Ressourcen zu den Neuerungen:

- Die Windows-Server-2022-ADMX und GPO-Settings als Excel-Sheet [1]

- Administrative Templates (ADMX) für Windows Server 2022 [2]

- Gruppenrichtlinieneinstellungen für Windows Server 2022 [3]

Windows Server 2022 bringt 47 neue Richtlinien-Settings, bei einer Gesamtzahl von 4442 Policies. Ein paar weitere Eckdaten:

- Es sind 39 neue Richtlinien für das Computer-Objekt, acht für den Benutzer.

- 13 Richtlinien gehören in den Bereich Privatsphäre und Telemetrie.

- Sechs Richtlinien kommen für den Windows Defender.

- Weitere sechs GPOs steuern die Windows-Sandbox.

Allein an der Anzahl und der Verteilung lässt sich erkennen, dass es für das Thema Kontrolle eines Betriebssystems keine großen Veränderungen gibt. Microsoft hat einige Komponenten in ihrer Funktionalität erweitert, aber es ist kein so großer Sprung wie von Windows Server 2003 auf 2008 R2 oder 2008 R2 auf 2016. Die Zwischenversionen waren, wie auch Server 2019, bei wenigen Unternehmen im Einsatz. Die Masse bewegte sich von Server 2003 über 2008 R2 zu 2016. Damit steht jetzt bei vielen IT-Organisationen Server 2022 als nächste Stufe im AD an.

Je nachdem, in welcher Region der Welt Sie sich befinden, gibt es unterschiedliche Institutionen, die für sich in Anspruch nehmen, ein System sicherer als im Auslieferungszustand konfigurieren zu können. Dabei muss die Frage erlaubt sein, warum das System nicht schon im gekauften Zustand sicher ist. Die Antwort darauf liefert das Microsoft-Ökosystem mit seinen uralten Wurzeln: In der Industrie, aber auch bei Banken und Versicherungen wird immer noch auf 20 bis 30 Jahre alte Software gesetzt. Diese muss weiterhin funktionieren. Unternehmen erwarten, dass sie ihre teuer gekaufte Warenwirtschaft, das individuell angepasste ERP weiterhin verwenden können.

Das traurige Lied vom Internet Explorer darf in diesem Moment ebenfalls angestimmt werden. Derlei Techniken haben sich irgendwann etabliert, sie wurden genutzt als sie neu waren und sind immer noch im Einsatz. Und sie lassen sich leider nicht so leicht ersetzen und auf heutige Bedingungen anpassen. Manchmal ist eine Lösung, Fehlerbeseitigung, Härtung und damit Absicherung seitens Microsofts einfach durch einen Patch zu integrieren. Oftmals aber sind sicherheitstechnisch notwendige Änderungen aufgrund von Abhängigkeiten zum Drittanbieterökosystem nur mit langfristigen Ankündigungen möglich, wie etwa das Deaktivieren von SMBv1, LDAP Signing oder die Default-Einstellung zur Excel-Makroausführung zeigen. Microsoft selbst hat irgendwann in einem RFC festgelegt, wie die Spielregeln sind und kann diese nicht dynamisch ändern. Andere Anwendungen vertrauen auf das (damals) definierte Regelwerk. Denken wir beispielsweise an den Access Token mit seiner maximalen Größe von 65.536 Byte. Als die Größe festgelegt wurde, hat kein Administrator geglaubt, dass ein Benutzer jemals in mehr als 1000 Sicherheitsgruppen steckt und so die maximale Größe des Tokens überschreitet. Jetzt, nachdem einige große Firmen ihre dritte oder sogar vierte AD-Migration inklusive Mitnahme der SID-History erleben, ist der Platz auf einmal sehr knapp.

SMBv1 kann als Beispiel für eine langfristig angekündigte Änderung gelten: Jedes Microsoft-OS ab Vista versteht SMBv2, aber aus dem System wurde v1 erst mit Win-dows 10 1903 entfernt. Trotzdem lässt es sich in jedem Build – selbst in Windows 11 – weiterhin aktivieren. Denn es gibt noch diverse Geräte wie zum Beispiel Multifunktionsdrucker mit Scan-to-UNC Schnittstellen, die nur SMBv1 sprechen.

So und ähnlich zieht es sich durch die Historie von Microsoft. Sobald Microsoft eine Technik veröffentlicht oder erlaubt hat, wurde sie auch von irgendwem verwendet. Eine Abschaffung ist dann kaum noch möglich oder bedarf eines individuellen Tests und Abschätzens seitens des Anwenderunternehmens. In diesem Dilemma kann Microsoft leider nicht so agieren, wie sie es gerne würden. Die Grenze der Funktionalität wird durch das Ökosystem definiert. Das bedeutet aber im Umkehrschluss nicht, dass es nicht besser zu kon- figurieren wäre. An dieser Stelle setzen die Schablonen und Empfehlungen an. Empfohlene Beispiele dafür sind:

1. Microsoft Security Baseline aus dem Microsoft Security Compliance Toolkit [4].

2. BSI SiSyPHuS, eine Studie zu Systemaufbau, Protokollierung, Härtung und Sicherheitsfunktionen in Windows 10 [5].

3. Die Benchmarks des CIS, des Centers for Internet Security [6].

4. Der "Security Technical Implementation Guide" des Department of Defense [7].

5. Die "Guideline for System Hardening" des ACSC (Australian Centers for Cyber Security) [8].

6. Das "gp-pack PaT" von gruppenrichtlinien.de [9].

Bevor wir die einzelnen Templates mit ihren Vor- und Nachteilen ansehen, können wir pauschal eine Aussage für alle treffen: Die neueren Schablonen gehen alle auf die Microsoft-Baseline zurück und die älteren sind mit ihr abgeglichen. Microsoft selbst ist hier in einer großen Offensive vorangegangen und hat angefangen, Empfehlungen auszusprechen, wie sein eigenes System besser im Sinne von "härter" gemacht werden kann.

Der Fokus der Vorlagen, mit Ausnahme des "gp-pack PaT", liegt auf der Betriebssystemhärtung. Dementgegen ist die Reduktion der gesendeten Daten ("Silencing") meist nur rudimentär hinterlegt. Es geht um Sicherheit – nicht mehr und nicht weniger. Daten, die Windows an einen Hersteller sendet, können die Sicherheit erhöhen. Das kann aber unter Umständen der DSGVO widersprechen und hier gibt es keinerlei klare Vorgaben, was erlaubt oder verboten ist. Wir empfehlen, so wenig Daten wie möglich zu senden, damit weiterhin ein sicherer Betrieb gewährleistet ist. Leider ist das individuell definiert und solange es keine rechtswirksamen Urteile gibt, was erlaubt ist und was nicht, agieren Admins in der unbefriedigenden Grauzone.

Grundsätzlich lautet unsere Empfehlung in Sachen GPO-Vorlagen: Importieren Sie die Werte ohne große Diskussion und untersuchen Sie anschließend im Testszenario, was umsetzbar ist und was nicht. Der Test zeigt Ihnen, welche Werte Fehler verursachen. Führen Sie diese Unterhaltung im Vorfeld, damit bloß nichts passieren kann, werden Sie niemals fertig! Oft nehmen Admins sogar einige Werte aus Angst heraus, weil Sie denken, es könne etwas Schlimmes passieren. Natürlich können Sie im Vorfeld eine grobe Durchsicht machen, aber eine Besprechung aller Details sollten Sie vermeiden. Zumal viele Einstellungen nicht selbsterklärend sind oder sich auf eine Technik mit Algorithmen oder Verschlüsselungstechniken beziehen, die Sie nicht bewerten können, weil die technischen Grundlagen fehlen.

Unser Ansatz behält diese Werte ohne Bewertung und der Test zeigt, ob der Wert in der empfohlenen Einstellung bleibt. Am Ende haben Sie damit ein Konstrukt, das wirklich bestmöglich für das eigene Unternehmen definiert ist. Es sind alle Werte umgesetzt und nur Anforderungen aus der eigenen Infrastruktur haben Änderungen herbeigeführt. Kommt es mit so einem Regelwerk zu einem externen Audit, tauchen nur wenige Ergebnisse als Mangel auf, weil sie nicht umgesetzt wurden, von denen Sie keine Kenntnisse hatten. Der externe Auditor legt auch nur eine der bekannten Messlatten an und prüft die Existenz.

Wichtig ist, dass die Implementation ein fortlaufender Prozess ist. Es hilft nichts, die Regelwerke zu einem Stichtag zu aktivieren und sich dann für die nächsten Jahre auszuruhen, ohne weitere Anpassungen vorzunehmen. Das Regelwerk ist nicht statisch und ist halbjährlich oder jährlich zu prüfen. Liefern die genannten Hersteller Updates, sollten Sie diese schnellstmöglich checken und einarbeiten. Der Aufwand, regelmäßig oder permanent kleine Änderungen vorzunehmen, ist wesentlich geringer, als alle zwei Jahre in einer Hauruckaktion viele Anpassungen einzuspielen.

Ein weiterer wichtiger Punkt, der sehr schnell geklärt ist, ist die Auswahl der geeigneten Vorlage, denn tatsächlich sind es schlicht und ergreifend alle sechs. Es gibt keine Diskussion, welche der Schablonen die bessere oder umfassendere ist. Zwar hat jeder Anbieter eigene Vorstellungen, die in seinem Wertesystem wichtig sind, es wäre jedoch ein Fehler, diese Punkte nicht alle mitzunehmen, wenn sie keine Probleme, sondern nur Arbeit verursachen. Zeit und Arbeit sind leider immer noch die größten Argumente gegen die Integration der Vorlagen, die wir im Folgenden detailliert betrachten.

Das Microsoft Security Compliance Toolkit steht seit seiner ersten Veröffentlichung auf der Version 1.0 – diese wurde nie weitergezählt. Es bietet Konfigurationsvorgaben für jedes aktuelle Betriebssystem. Zu jedem Build erscheint eine Baseline sowohl Server als auch Client. Zudem liefert Microsoft außerhalb eines fixen Zyklus auch Vorschläge zur Konfiguration des Edge-Browsers auf Chromium-Basis und für das Office-365-Paket. Mit Betriebssystemen, Browser und Office sind die drei wichtigsten Bereiche abgedeckt, die Microsoft im Unternehmen abbildet.

Die Auslieferung erfolgt als ZIP-Datei mit immer gleicher Struktur: Wir finden Excel-Tabellen mit den neuen Einstellungen und mittlerweile ein PDF, das den Blog-Eintrag zur Microsoft Security Baseline (MSB) mit den Änderungen erklärt und bereitstellt. Die Richtlinien kommen als GPMC-Backup und sind per Skript in Masse importierbar, aber auch die Einzelwerte lassen sich mit vorhandenen Richtlinien mit dem LGPO-Tool (Local Group Policy Object Utility [10]) integrieren.

Ebenfalls finden wir weitere ADMX-Vorlagen mit den Richtlinien als HTML-Report, sodass Sie vor dem Import einen Blick auf den Inhalt werfen können. Die Richtlinien sind thematisch aufgeteilt in Benutzer und Computerobjekte und ihren Anwendungszweck. BitLocker und Defender stellen eigene Richtlinienobjekte dar, obwohl sie Bestandteil des OS sind. Die Erklärung dafür ist, dass diese beiden Techniken oft durch Drittanbietersoftware übernommen werden. Microsoft erspart uns hier einen großen Teil der Arbeit, die unnötigen, nicht verwendeten Einstellungen aus der Richtlinie herauszunehmen.

Dieses Vorgehen verdeutlicht einen wichtigen Punkt: Microsoft will, dass MSB zum Einsatz kommt und setzt so wenig Stolpersteine bei dessen Integration wie möglich. Einige Einstellungen hat Redmond dabei bewusst ausgelassen, da sie in der Praxis (wahrscheinlich) niemals umsetzbar sind. So sind einige Konfigurationen auf "Überwachen" eingestellt anstelle von "Verweigern" oder "Erzwingen". Tatsächlich werden Sie mit etwas Erschrecken feststellen, wie leicht die Integration der Richtlinie in der Praxis ist. Der Name "Baseline" beschreibt sehr gut das dahinterliegende Konzept: Es ist die Basis, das Minimum, das definiert werden sollte. Es bildet den kleinsten gemeinsamen Nenner, der sich ohne Kraftakt und großen Zeitaufwand mit langen Integrationstests einführen lässt.

Logischerweise verhindert Microsoft in der Baseline keinerlei Telemetrie oder Cloudzugriffe, das mag in einem europäisch beziehungsweise deutschen Ansatz als berechtigte Kritik gelten. Da Microsoft die Baseline nach Themen sortiert, wirkt sie oft etwas kleiner als andere Regelwerke. Ebenfalls versucht Microsoft MSB auf dem Auslieferungszustand des aktuellen Build zu definieren und versucht, nur Werte vorzugeben, die nicht umgesetzt sind. Es soll nicht zum Konfigurieren eines Default-Werts kommen, der schon korrekt ist. Allerdings ist dieser Prozess nicht konsequent umgesetzt und bei diversen Werten finden wir eine Definition in der Baseline, die schon seit Windows 8 nicht mehr notwendig ist – wie im Falle der "WDigest Settings". Da andere Vorlagen aber die Existenz dieses Wertes prüfen, hat Microsoft ihn weiterhin integriert, damit es zu keinem Fehler im Audit kommt.

Das BSI erweitert die Microsoft-Baseline um Punkte wie die Cloud. Allerdings spart es sich Verbesserungspotential im Bereich der Telemetrie. Zum Zeitpunkt der Veröffentlichung dieses Artikels ist eine neue Version des SiSyPHuS in Arbeit; ob sie noch im Jahr 2022 erscheint, ist nicht gewiss. Konzeptionell wurde das BSI-Regelwerk im Gegensatz zur MSB aufeinander aufbauend erstellt. Es gibt pro Objekt einen "Normalen" und einen "Hohen" Schutzbedarf. Des Weiteren unterscheidet das BSI in Einzelrechner und Domänenmitglied und die Konfiguration der Überwachungsrichtlinie wurde separiert, da sie für alle Systeme identisch geregelt wurde. Dadurch reduzieren sich die dreifachen Konfigurationen identischer Einstellungen in jeder Richtlinie. Wer einen hohen Schutzbedarf für seinen Rechner beziehungsweise Anwender realisieren möchte, muss also mindestens drei Gruppenrichtlinienobjekte anwenden: "Normaler Schutzbedarf " plus "Hoher Schutzbedarf" plus Überwachung. In der Addition des Regelwerks ist das Ergebnis dann als "Hoch" bewertet.

Diese Art der Bewertung finden wir auch in anderen Vorlagen. Das Problem stellt die Bewertung selbst dar: Diese ist frei erfunden und unterliegt einem eigenen Wertesystem. Die Messlatte für die Einstufung der einzelnen Einstellung ist letztlich komplett selbst definiert und hat keinerlei reale Argumente. Diese Kategorisierung stammt aus der Zeit, als dem Administrator die Arbeit erleichtert werden sollte: "Normal" birgt weniger Fehlerpozential als "Hoch" und die Anwendung des normalen Schutzbedarfs flächendeckend im AD sollte das Minimum darstellen. Wenn wir anstelle von "Hoch" und "Normal" andere Adjektive verwenden wie "Schlecht" und "Gut", dann klingt das auf einmal nicht mehr so freundlich. Warum sollte sich ein Administrator mit einer normalen (schlechten) Konfiguration zufriedengeben, wenn er einen hohen Schutzbedarf (gut) realisieren kann?

Spätestens wenn es zu einem Vorfall kommt, sind die beschuldigenden Finger immer auf den Administrator gerichtet, der nach bestem Wissen und Gewissen sein Netzwerk definieren muss. Administratoren möchten nicht wissentlich mit einer verweichlichten Konfiguration dastehen, wenn sie wissen, dass es wirklich besser geht. Eine Zusammenführung der beiden Templates in ein einziges würde hier sehr viel politischen Ärger aus dem System nehmen. Zumal es bei jeder Einstellung immer wieder zu Diskussionen führt, ob der Wert nun "Normal" ist oder "Hoch". Denken wir an den Bildschirmschoner: In welcher der beiden Kategorien gehört der Wert? Ist er normal, weil sich alle Anwender mittlerweile dran gewöhnt haben, dass ein Bildschirmschoner nach einer bestimmten Zeit anspringt, oder ist es eher ein besonders hoher Faktor, weil ein Kennwort notwendig ist, um ihn wieder freizuschalten? Je nach Wert, um den es geht, wird nur unnötig Zeit verbrannt für die Diskussion, wie er einzuordnen ist. Der viel einfachere Weg ist hier die Integration ohne Bewertung.

Ein kleiner technischer Kritikpunkt ist die Form, in der SiSyPHuS die Ordner im ZIP-File sortiert: Anstelle nur einen einzigen Backup-Ordners mit einer zentralen manifest.xml-Datei zu verwenden wie das MSB, liegt beim BSI jedes Richtlinien-Backup in einem eigenen Ordner. Das sieht ordentlich sortiert und strukturiert aus, gestaltet aber den Import der Richtlinien etwas aufwendiger, da mehrere Quellen einzulesen sind anstelle nur einer.

Legen wir SiSyPHuS über die Microsoft-Baseline, gibt es tatsächlich keinerlei Konflikte in Bezug auf die eingestellten Werte. Die sich überschneidenden Einstellungen sind identisch definiert. Über die Frage, was als sicher gilt, herrscht Einigkeit. Leider ist SiSyPHuS für "1809 LTSC" definiert, sodass hier kein praxisnahes Regelwerk herausgekommen ist. Die LTSC-Version war nie für den Normalbetrieb vorgesehen und die meisten Firmen haben mittlerweile schon längst auf die Semi-Anual-Channel-Versionen umgestellt. Zudem ist Built 1809 mittlerweile schon dreieinhalb Jahre alt und hinkt damit weit den aktuellen Anforderungen hinterher.

Das CIS liefert seit vielen Jahren Vorschläge zur Härtung von IT-Systemen, Microsoft ist da nur eines von vielen. An den Benchmarks des CIS sind Aaron Margosis und Rick Munk von Microsoft beteiligt, die auch die beiden federführenden Personen der Microsoft Security Baseline sind. Das beantwortet direkt die Frage, ob das CIS eventuell widersprüchlich zur Baseline ist – nein, der Benchmark ist nur umfangreicher. Das CIS bietet Sicherheitskonfigurationen von A wie Apache bis Z wie Zoom. Wie der Name Benchmark vorgibt, handelt es sich um Auswertungen, die sich hinterher bewerten und mit Vorgaben vergleichen lassen.

Das CIS bietet ein komplettes System: Im Fall von Microsoft-Richtlinien stellt es GPO-Backups bereit und liefert ein "Build Kit", das automatisch die Änderungen und Updates der Versionen integriert und wieder bereitstellt beziehungsweise Änderungen auch in vorhandene Richtlinien integrieren kann. Ebenfalls stellt es Vergleichswerkzeuge bereit und kann den Score ermitteln, den ein System nach dem internen Bewertungssystem des Benchmarks erzielt. Sowohl GPO-Backups als auch das Build Kit sind kostenpflichtig. Für einen IT-Dienstleister werden hier rund 3500 Euro pro Jahr aufgerufen.

Kostenfrei ist hingegen ein PDF, das alle Einstellungen beinhaltet, allerdings sieht sich der Administrator hier rund 1300 Seiten gegenüber, die im ersten Moment aufgrund der schieren Masse extrem abschreckend wirken. Wer sich oft im GPO-Editor bewegt und dort zuhause fühlt, kann das PDF allerdings in nur zwei Stunden Fleißarbeit in eine GPO überführen. Das CIS hat schon vor Jahren verstanden, dass die beste Reihenfolge, Gruppenrichtlinien zu dokumentieren, darin besteht, sich an der Struktur des Gruppenrichtlinien-Editors zu orientieren. Wer englische Systeme administriert, der beginnt im Editor oben bei "Account Policies", um im Bereich der "Administrativen Vorlagen / Windows Update" zu enden. Genau in dieser Reihenfolge agiert auch das CIS mit seinem PDF.

Das Volumen des PDFs ergibt sich aus der hervorragenden Dokumentation jedes einzelnen Werts. Zu jeder Einstellung steht eine kurze Erklärung bereit, die die Auswirkung beschreibt. Zudem nennt das Dokument jeden Wert mit seiner Richtlinie und zeigt den dahinterliegenden Registry-Eintrag, damit dieser am Ziel auf Existenz geprüft werden kann und damit Compliance ermöglicht.

Nicht uninteressant ist, dass der Default-Wert des Systems dokumentiert ist. Der CIS-Benchmark setzt oftmals Werte, die den Standard per GPO bestätigen. Damit soll sich der IST-Zustand am Build orientieren, falls das System nicht selbst installiert wurde, sondern zum Beispiel von einem OEM-Hardwarepartner. Letzteres ist übrigens niemals eine gute Idee, denn die Hersteller leben auch von Werbung und am Ende ist zu viel unerwünschter Softwaremüll auf den Systemen, von dem keiner weiß, was es im System manipuliert.

Der Benchmark ähnelt in seinem Aufbau dem des BSI SiSyPHuS und arbeitet mit "Level 1" und "Level 2", was "Normal" und "Hoch" entspricht. Seit Neuestem versucht das CIS mit dem Konstrukt der "Implementation Groups" (IG1 bis IG3), weitere Hilfe zu bieten. Die Gruppen referenzieren auf weitere Werkzeuge des CIS und versuchen eine Bewertung in anderer Form als die Level. Es gibt circa 150 Bewertungskategorien und die Anzahl dieser variiert von IG1, in dem rund 50 Kriterien erfüllt sind, bis hin zu allen in IG3. IG1 wird auch als "Essential Cyber Hygiene" bezeichnet.

Genau wie beim BSI bleibt auch hier wieder der Sinn dieser Variation etwas verborgen. Der Gedanke, das Geld im Vordergrund steht, drängt sich auf. Es ist weiterhin so, dass der Administrator sich nicht auf das Spiel einlassen sollte, ein schlechter konfiguriertes System auszuliefern, als er bekommen kann. "Bestmöglich" muss der einzige Anspruch sein, den das System zu erfüllen hat. Dies kann jedoch für die Produktion mit einer Maschinensteuerung etwas anderes bedeuten als in der Verwaltung an einem Office-PC. Trotzdem sollten Sie immer vom optimalen Ansatz aus agieren und nicht von einem Zugeständnis, das weniger Arbeit bedeutet, aber sehr wahrscheinlich niemals weiter gehärtet wird, da sich niemand die Arbeit machen wird.

Auch wenn Windows Server 2022 wenig neue Featuress in Sachen GPO liefert, gilt es denoch bei den Clients für maximale Sicherheit zu sorgen. Dabei helfen zahlreiche GPO-Vorlagen, deren Vorstellung der zweite Teil des Workshops anschließt. Darüber hinaus widmen wir uns der kommenden Ausgabe detailliert administrativen GPO-Aufgaben.