Das Supportende von Windows 10 am 14. Oktober 2025 hat (hoffentlich) viele Unternehmen dazu bewegt, auf Windows 11 zu migrieren. In diesem Zug bietet es sich zudem an, die Geräteverwaltung auf Microsoft Intune umzustellen und dort dementsprechend auch die Windows 11 Hardening Policies zu verwalten. Mit einer sauber konfigurierten Hardening Baseline lässt sich die Angriffsfläche von Windows-Systemen deutlich reduzieren.
Mit Intune können Richtlinien ganz einfach zentral erstellt und verteilt werden. Trotzdem gibt es einiges zu beachten. In diesem Artikel erfahren Sie, wie Sie Windows 11 sicher härten – mit konkreten Empfehlungen zu verschiedenen Themen rund um das Windows 11 Hardening:
- Microsoft Security Baseline
- CIS-Benchmark
- BitLocker über Intune
- Recovery Keys
- LAPS (Local Admin Password Solution)
- ASR-Regeln (Attack Surface Reduction)
- Die Windows-Firewall
Am Ende werden Sie sich selbst ein Bild gemacht haben und wissen, wie Sie vorgehen können, um Windows-11-Geräte entsprechend abzusichern.
Inhaltsverzeichnis
- Einfach und schnell: Microsoft Security Baselines
- CIS-Benchmark auf Windows 11 anwenden
- BitLocker über Intune verwalten
- LAPS (Local Admin Password Solution) zur sicheren Verwaltung von lokalen Administratorenkonten
- Attack Surface Reduction (ASR)
- Windows-Firewall effektiv einsetzen
- Fazit: Mit Windows 11 Hardening zu mehr IT-Sicherheit
Einfach und schnell: Microsoft Security Baselines
Microsoft stellt schon seit Jahren Security Baselines für seine Produkte bereit. So konnten im Rahmen des Microsoft Security Compliance Toolkit für Windows 10 entsprechende Policies heruntergeladen und als Gruppenrichtlinienobjekte (GPOs; Group Policy Objects) im Active Directory (AD) importiert werden. Auch für Windows Server, Windows Defender, den Edge-Browser sowie für Office-Anwendungen stehen entsprechende Baselines zur Verfügung. Mit Intune gestaltet sich der Prozess jedoch deutlich einfacher.
Microsoft Security Baselines in Intune erstellen
In Intune müssen die Security Baselines nicht mehr separat heruntergeladen oder importiert werden. Microsoft stellt die Richtlinien direkt unter «Endpoint security > Security baselines» bereit, sodass sie unkompliziert erstellt, angepasst und auf Geräte verteilt werden können.
Durch Auswählen des im zuvor gezeigten Bild markierten Menüpunkts «Security Baseline for Windows 10 and later», kann über die Schaltfläche «Create Policy» eine neue Microsoft Security Baseline für Windows 11 erstellt werden. Zunächst muss ein aussagekräftiger Name vergeben und anschließend können die von der Policy bereits vorgegebenen Einstellungen überprüft werden. Zuletzt wird ein Assignment zugewiesen – im ersten Schritt an wenige Testgeräte und am Ende, wenn alles in Ordnung ist, an alle Geräte. Assignments sollten nur an Computergruppen erteilt werden, um Störungen zu vermeiden, wenn sich beispielsweise verschiedene Benutzer an einem Gerät anmelden.
Da die soeben erstellte Security Baseline eine grosse Anzahl an Einstellungen enthält, sollte sie zunächst gründlich getestet werden, bevor sie in einer produktiven Umgebung zum Einsatz kommt. Beim Hardening ist es völlig normal, dass einzelne Funktionen nicht mehr wie erwartet arbeiten. In solchen Fällen müssen die Ursachen analysiert und entsprechende Anpassungen vorgenommen werden. Zudem kann es vorkommen, dass Konflikte mit bereits bestehenden Configuration Policies auftreten. Üblicherweise werden dann die betreffenden Einstellungen innerhalb der Security Baseline angepasst – entweder durch Ändern des jeweiligen Wertes oder durch das vollständige Entfernen der betreffenden Richtlinie aus der Baseline.
Die Fehleranalyse und Identifikation der problematischen Einstellungen kann dabei je nach Situation anspruchsvoll sein, insbesondere wenn Fehlermeldungen oder Logeinträge nicht eindeutig auf die eigentliche Ursache hinweisen. Erfahrene Mitarbeitende, die mit den im Unternehmen eingesetzten Technologien, Protokollen und Prozessen vertraut sind, leisten hier wertvolle Unterstützung und können die Fehlerbehebung deutlich beschleunigen.
Windows Security Baselines erfolgreich implementieren und verwalten
Für ein wirkungsvolles Windows 11 Hardening müssen Windows Security Baselines korrekt integriert und verwaltet werden. Dabei sind zwei Aspekte besonders wichtig:
Die Baselines werden intern als Configuration Policies gehandelt, die zwar in einem eigenen Menü in Intune erstellt und verwaltet, in der Liste unter «Devices -> Windows -> Configuration» aber trotzdem bei allen anderen Configuration Policies mit aufgeführt werden. Wie der geneigte Intune-Admin weiss, sind Configuration Policies in einer flachen Hierarchie untergebracht und Einstellungen können weder vererbt werden noch doppelt mit unterschiedlichen Werten bestehen. Es kann daher gut sein, dass die erstellte Security Baseline Policy Einstellungen beinhaltet, die bereits in anderen Configuration Policies gesetzt wurden.
Kurz gesagt: Es kann zu Konflikten kommen, die gelöst werden müssen. Wird ein Konflikt erkannt, wird dieser in Intune auf dem Gerät, das die Policy anwenden soll, oder aber für die Policy selbst im Report angezeigt – einschliesslich der entsprechenden Einstellungen und des Namens der Policy, welche dieselbe Einstellung konfiguriert. Dabei empfiehlt es sich, die entsprechenden Einstellungen zu identifizieren und in der Security Baseline zu entfernen. Alle Änderungen an der Baseline sollten zusammen mit einer Begründung gut dokumentiert werden, damit in Zukunft nachvollziehbar ist, was geändert wurde und warum, da Microsoft hin und wieder eine neue Version der Security Baselines veröffentlicht und Updates zur Verfügung stellt.
Intune selbst trackt keine Änderungen an Policies und es gibt durch die flache Hierarchie keine Möglichkeit von «Exception Policies» oder dergleichen. Die entsprechenden Policies werden im Web-GUI mit einem Pfeil markiert und die Version jeder Policy ist in der Übersicht erkenntlich.
Wird eine Policy aktualisiert, müssen alle Änderungen, die vorgenommen wurden, erneut eingepflegt werden. Hilfreich dabei ist eine gut geführte Dokumentation, mit der das Update der Security Baseline schnell umgesetzt werden kann. Microsoft informiert über neue Policy-Versionen im Message Center (zu finden im Admin-Portal) oder als Blogbeitrag im Microsoft Community Hub (in englischer Sprache), wo sich die Beiträge auch als RSS abonnieren lassen. Für Windows erschient meist einmal im Jahr nach dem Release der neuen Version (z. B. 25H2) auch eine neue Baseline.
Damit sollte nun eine grundlegende Sicherheitsbasis geschaffen sein, mit der das Sicherheitsniveau der Windows-11-Umgebung erhöht werden kann, wenn sie auf die Client-Systeme angewendet wird.
CIS-Benchmark auf Windows 11 anwenden
Einen Schritt weiter geht das Umsetzen der CIS-Empfehlungen (Center for Internet Security) für Windows 11. Für Geräte, die mit Intune verwaltet werden, gibt das CIS einen separaten Benchmark für Windows 11 heraus: CIS_Microsoft_Intune_for_Windows_11_Benchmark (in englischer Sprache).
Darin werden hunderte von Einstellungen empfohlen – einschliesslich kurzer Erklärungen, was sie bewirken und warum sie wichtig sind. Zur Einordnung der Auswirkungen der empfohlenen Einstellungen auf den produktiven Betrieb gibt es zwei Level:
- Level 1 = geringes Risiko für negative Auswirkungen
- Level 2 = mögliche negative Auswirkungen sind zu erwarten
Die Windows Security Baselines überschneiden sich an vielen Stellen mit den CIS-Benchmarks, sind jedoch schlanker und decken weniger Einstellungen ab als die CIS-Empfehlungen.
Bei der Umsetzung sind erfahrungsgemäss folgende Punkte wichtig:
- Alle Level-1-Empfehlungen in einer Policy zusammenzufassen und sie zu testen
- Level-2-Empfehlungen mit den entsprechenden Teams/Mitarbeitenden durchzugehen und pro Einstellung zu entscheiden, ob sie relevant ist, ob mit negativen Auswirkungen gerechnet werden muss und ob die Empfehlung umgesetzt werden soll
- Dokumentation der Einstellungen, die nicht umgesetzt wurden (mit Begründung)
- Dokumentation der Einstellungen, die abweichend von der CIS-Empfehlung umgesetzt oder bereits in anderen Configuration Policies eingestellt wurden (Stichwort: Konflikte)
Einige Einstellungen können nicht mittels Settings Catalog gesetzt werden, sondern müssen etwa über PowerShell oder einen anderen Weg konfiguriert werden. Ich empfehle, sich an ähnlichen Herausforderungen zu orientieren und diese nach dem gleichen Prinzip zu lösen. Eine Möglichkeit wären beispielsweise die Remediation- und Plattform-Skripte in Intune, die jedoch nicht in jeder Lizenz (z. B. Business Premium) enthalten sind.
Sollte die Windows Security Baseline bereits umgesetzt worden sein, spielen natürlich auch hier wieder Konflikte eine Rolle. Diese müssen im Rahmen von ersten Tests der neuen Policy in Intune festgestellt und behoben werden. Mein Vorgehen ist hier jeweils, die entsprechenden Einstellungen in der Windows Security Baseline zu entfernen (und zu dokumentieren) und die Einstellungen aus dem CIS-Benchmark beizubehalten. So kann, zumindest gedanklich, von folgendem Aufbau ausgegangen werden: die Microsoft Security Baseline bildet die Basis und die CIS-Empfehlungen bauen darauf auf. Natürlich ist es auch möglich, die Vorschläge des CIS-Benchmarks ohne die Microsoft Security Baseline umzusetzen. Ich für meinen Teil finde jedoch, dass sie sich gut ergänzen.
Nach der Umsetzung und den Tests sollte nun eine Security Baseline für Windows-11-Clients existieren, die per Intune verteilt werden kann. Die verschiedenen sicherheitsrelevanten Einstellungen sind jedoch nur Teil einer soliden Grundlage. Es fehlen weitere Bausteine wie etwa BitLocker zur Laufwerksverschlüsselung oder eine geeignete Firewall Policy. Beide werden im CIS-Benchmark zwar grundlegend beschrieben, aber nicht abschliessend behandelt. Um diese Lücke zu schliessen, schauen wir uns im nächsten Kapitel BitLocker und seine Verwaltung über Intune genauer an.
BitLocker über Intune verwalten
BitLocker ist das Tool der Wahl, wenn es darum geht, Daten (genauer gesagt die Partitionen lokaler Festplatten und Wechseldatenträger) lokal zu verschlüsseln. Intune macht es Unternehmen einfach, BitLocker auf ihren Geräten zu aktivieren.
Dennoch gibt es auch Kritik, da das native Setzen einer PIN bei der automatischen Verschlüsselung während des Geräte-Setups mit Autopilot oder Device Preparation (zwei Wege für das automatisierte Geräte-Enrollment durch Intune) nicht möglich ist – doch dazu später mehr.
BitLocker Policy erstellen und konfigurieren
Eine entsprechende Policy kann in Intune unter «Endpoint security -> Disk encryption» erstellt werden. Zunächst muss ein aussagekräftiger Name vergeben werden und anschliessend zeigt das Portal alle relevanten Einstellungen zu BitLocker an.
Empfohlen werden folgende Werte für die automatische Verschlüsselung während der Inbetriebnahme eines Geräts mit Autopilot oder Device Preparation:
| Name | Wert |
| BitLocker | – |
| Require Device Encryption | Enabled |
| Allow Warning For Other Disk Encryption | Disabled |
| Allow Standard User Encryption | Enabled |
| BitLocker Drive Encryption | – |
| Choose drive encryption method and cipher strength (Windows 10 [Version 1511] and later) | Enabled |
| Select the encryption method for fixed data drives: | XTS-AES 256-bit |
| Select the encryption method for operating system drives: | XTS-AES 256-bit |
| Select the encryption method for removable data drives: | XTS-AES 256-bit |
| Operating System Drives | – |
| Enforce drive encryption type on operating system drives | Enabled |
| Select the encryption type: (Device) | Full Encryption |
| Require additional authentication at startup | Enabled |
| Allow BitLocker without a compatible TPM (requires a password or a startup key on a USB flash drive) | False |
| Configure TPM startup key and PIN: | Do not allow startup key and PIN with TPM |
| Configure TPM startup key: | Do not allow startup key with TPM |
| Configure TPM startup PIN: | Allow startup PIN with TPM |
| Configure TPM startup: | Allow TPM |
| Configure minimum PIN length for startup | Enabled |
| Minimum characters: | 6 |
| Allow enhanced PINs for startup | Enabled |
| Disallow standard users from changing the PIN or password | Disabled (Default) |
| Allow devices compliant with InstantGo or HSTI to opt out of pre-boot PIN. | Disabled (Default) |
| Choose how BitLocker-protected operating system drives can be recovered | Enabled |
| Configure user storage of BitLocker recovery information: | Allow 256-bit recovery key Require 48-digit recovery password |
| Allow data recovery agent | False |
| Configure storage of BitLocker recovery information to AD DS: | Store recovery passwords and key packages |
| Do not enable BitLocker until recovery information is stored to AD DS for operating system drives | False |
| Omit recovery options from the BitLocker setup wizard | False |
| Save BitLocker recovery information to AD DS for operating system drives | False |
| Fixed Data Drives | – |
| Enforce drive encryption type on fixed data drives | Enabled |
| Select the encryption type: (Device) | Full encryption |
| Choose how BitLocker-protected fixed drives can be recovered | Enabled |
| Configure user storage of BitLocker recovery information: | Require 48-digit recovery password |
| Allow data recovery agent | False |
| Configure storage of BitLocker recovery information to AD DS: | Store recovery passwords and key packages |
| Do not enable BitLocker until recovery information is stored to AD DS for operating system drives | False |
| Omit recovery options from the BitLocker setup wizard | False |
| Save BitLocker recovery information to AD DS for operating system drives | False |
| Deny write access to fixed drives not protected by BitLocker | Enabled |
Anschließend wird die Policy einer Gerätegruppe zugewiesen und somit aktiviert. Auch hier hat es sich bewährt, vor dem Roll-out einen Test durchzuführen.
Automatische Verschlüsselung mit Benutzer-PIN
Wie bereits angedeutet, fehlt bei der automatischen BitLocker-Aktivierung mit Autopilot oder Device Preparation eine entscheidende Funktion: das geführte Setzen einer PIN.
Standardmässig startet BitLocker die Verschlüsselung automatisch, sobald das Gerät eingerichtet wird – eine Benutzerinteraktion zur Eingabe einer PIN ist dabei nicht vorgesehen.
In der Praxis bleiben damit zwei Optionen:
- Auf die automatische Verschlüsselung zu verzichten und dem Benutzer nach dem Enrollment den Windows-Standardassistenten zur BitLocker-Einrichtung zu präsentieren.
- Die Verschlüsselung automatisiert und ohne PIN während der Gerätebereitstellung durchzuführen.
Ideal wäre jedoch ein dritter Weg: Das Gerät wird automatisch verschlüsselt und der Benutzer erhält eine Oberfläche zum geführten Setzen einer PIN.
Eine Lösung für genau dieses Szenario hat der Microsoft MVP (Most Valuable Professional) Oliver Kieselbach entwickelt. Er stellt ein PowerShell-Skript bereit, das als Intune-App verteilt werden kann. Dieses Skript zeigt Benutzern nach dem Einrichten und Verschlüsseln eines Geräts auf dem Desktop ein ansprechendes GUI zur Eingabe der PIN und setzt diese im Hintergrund automatisch für BitLocker. Eine detaillierte Beschreibung des Ansatzes findet sich in seinem Blogpost (in englischer Sprache).
BitLocker Recovery Key auslesen
Um an den Recovery Key zu gelangen, wird eine mit den entsprechenden Berechtigungen ausgestattete Rolle vorausgesetzt. Das sind (nicht abschliessend) neben dem Global Admin die Rollen Cloud Device Admin, Helpdesk Admin, Intune Admin, Security Admin und Security Reader. Das entsprechende Passwort kann in Entra ID und Intune auf dem Gerät abgerufen werden.
Zudem können Benutzer für ihre Geräte standardmässig die Recovery Keys unter «My Account» (https://myaccount.microsoft.com/device-list) abrufen. Dies kann in Entra unterbunden werden, sollte dieses Verhalten nicht gewünscht sein:
Abbildung 6: Benutzer können BitLocker Recovery Keys abrufen
LAPS (Local Admin Password Solution) zur sicheren Verwaltung von lokalen Administratorenkonten
Sollten Sie aktuell noch keine automatisierte Lösung für das Setzen und Wechseln der Passwörter lokaler Administratorenkonten einsetzen, empfehle ich Ihnen unbedingt, LAPS zu deren Verwaltung zu verwenden.
Für jedes Windows-Gerät (mit Ausnahme des Domänen-Controllers) ist üblicherweise ein lokaler Admin konfiguriert, für den oft im ganzen Betrieb dasselbe Passwort gesetzt und möglicherweise seit Jahren nicht geändert wurde. Empfohlen wird jedoch ein starkes Kennwort, das für jedes Gerät unterschiedlich ist und nach Benutzung oder Ablauf einer Frist geändert wird. Das sollte optimalerweise automatisiert ablaufen, um den Aufwand gering zu halten – und genau hier kommt LAPS ins Spiel.
LAPS in Microsoft Entra ID für Intune aktivieren
LAPS ist in Windows 11 bereits integriert und bedarf keiner Installation, wie das früher der Fall war. Damit LAPS zusammen mit Microsoft Entra ID und Intune funktioniert, muss es zunächst in Entra ID für den Tenant eingeschalten werden. Das ist im Entra Admin Portal unter «Entra ID -> Devices -> Device settings» über die Schaltfläche «Enable Microsoft Entra Local Administrator Password Solution (LAPS)» möglich.
Abbildung 7: LAPS in Entra für den Tenant einschalten
LAPS-Richtlinie in Intune erstellen und zuweisen
In Intune kann eine LAPS-Richtlinie zur Konfiguration von LAPS auf den Geräten unter «Endpoint security -> Account protection» über die Schaltfläche «Create Policy» erstellt werden. Wie bereits bei der BitLocker Policy wird zunächst ein aussagekräftiger Name vergeben und danach werden die LAPS-Einstellungen zum Konfigurieren angezeigt. Nachfolgend finden sich einige Informationen zu den Einstellungen:
| Name | Empfohlener Wert | Beschreibung |
| Backup Directory | Backup the password to Azure AD only | Legt fest, wohin das LAPS-Kennwort gesichert werden soll (in das lokale AD oder nach Entra ID). Das verwaltete Gerät muss dabei der Auswahl entsprechen. Beispiel: Ein Gerät, dessen LAPS-Passwort in das AD gesichert werden soll, jedoch nicht Mitglied der Domäne ist, wird die Policy zwar fehlerfrei umsetzen, das Passwort würde jedoch nicht gesichert werden. |
| Password Age Days | 30 | Setzt das maximale Alter eines LAPS-Kennworts. Nach dieser Frist wird es automatisch rotiert. |
| Administrator Account Name | <Name Ihrer Wahl> | Setzt den Namen des Benutzerkontos, das durch LAPS verwaltet werden soll. Wird keines angegeben, wird das Standardkonto «Administrator» verwendet. Das angegebene Konto muss auf dem verwalteten Gerät vorhanden sein. Es wird nicht automatisch angelegt. Achtung: Nach Abschluss der Out of Box Experience (OOBE) wird das Konto «Administrator» automatisch deaktiviert. |
| Password Complexity | Large letters + small letters + numbers + special characters (Default) | Legt fest, welche Komplexitätsvorschriften beim Generieren von LAPS-Passwörtern eingesetzt werden. |
| Password Length | 14 | Setzt die Länge für LAPS-Kennwörter. |
| Post Authentication Actions | Reset the password, logoff the managed account, and terminate any remaining processes: upon expiration of the grace period, the managed account password is reset, any interactive logon sessions using the managed account are logged off, and any remaining processes are terminated. | Definiert Aktionen, die nach Verwendung des LAPS-Benutzers ausgeführt werden. |
| Post Authentication Reset Delay | 4 | Definiert die Zeit in Stunden, bevor die «Post Authentication Actions» ausgeführt werden. |
Für Windows 11 ab Version 24H2 können weitere, neue LAPS-Einstellungen definiert werden:
| Einstellung | Empfohlener Wert | Beschreibung |
| Automatic Account Management Enabled | The target account will be automatically managed | Aktiviert die neuen Funktionen, die ab Windows 11 Version 24H2 funktionieren. |
| Automatic Account Management Enable Account | The target account will be enabled | Legt fest, ob das per LAPS verwaltete Konto aktiviert oder deaktiviert sein soll. |
| Automatic Account Management Randomize Name | The name of the target account will not use a random numeric suffix. (Default) | Legt fest, ob der Name des durch LAPS zu erstellenden Kontos aus zufälligen Zahlenfolgen bestehen soll oder nicht. |
| Automatic Account Management Target | Manage a new custom administrator account (Default) | Definiert das zu verwaltende Benutzerkonto. Hier kann entweder ein neues Konto, das auf dem verwalteten Gerät noch nicht vorhanden ist und dessen Namen später noch angegeben werden muss, ausgewählt werden oder es wird das Standardkonto «Administrator» verwendet. |
| Automatic Account Management Name Or Prefix | <Name Ihrer Wahl> | Setzt entweder den Namen (wenn «Automatic Account Management Randomize Name» ausgeschaltet ist) oder einen Präfix (wenn «Automatic Account Management Randomize Name» eingeschaltet ist). |
Die Richtlinie sollte einer Gerätegruppe zugewiesen werden. Benutzergruppen werden zwar ebenfalls unterstützt, können jedoch zu unerwartetem Verhalten führen, wenn Benutzer sich an verschiedenen Geräten anmelden und so ein Gerät je nach angemeldetem Benutzer unterschiedliche LAPS-Richtlinien erhält. Allgemein sollte bei der Verwendung von mehreren LAPS Policies auf Konflikte geachtet werden, die ein Umsetzen der Einstellungen auf verwalteten Geräten verhindern können. Konflikte verhindern im schlimmsten Fall das Speichern des Passworts in Entra ID.
Zugriff auf LAPS-Passwörter in Intune und Entra ID
Das LAPS-Kennwort kann anschließend in Intune oder Entra ID auf dem Gerät abgerufen werden. Dabei wird eine entsprechend berechtigte Rolle vorausgesetzt. Neben Global Admin sind das die Rollen Intune Admin oder Cloud Device Admin, wobei letztere das LAPS-Kennwort nur über das Entra-Portal und nicht über Intune aufrufen kann.
LAPS als Teil eines umfassenden Windows Hardening
LAPS ist eine unverzichtbare Komponente, wenn es darum geht, eine umfassende Hardening Baseline zu erstellen. In der Vergangenheit zeigte sich das Produkt robust und konnte mit minimalstem Aufwand betrieben werden. Mit den oben beschriebenen Einstellungen sind die lokalen Adminkonten geschützt und stellen kein unnötiges Risiko mehr für das Gesamtsystem dar.
Attack Surface Reduction (ASR)
ASR-Regeln identifizieren bekannte Angriffspfade und typische Verhaltensweisen, um die Ausführung oder Verbreitung von Schadsoftware im System zu unterbinden. So kann beispielsweise angegeben werden, dass Office-Apps keine Child-Prozesse starten dürfen oder ausführbarer Inhalt aus E-Mails blockiert wird.
ASR Policy in Intune erstellen und konfigurieren
Die Policy wird in Intune unter «Endpoint security -> Attack surface reduction» zuerst erstellt, dann mit einem passenden Namen versehen und zuletzt konfiguriert.
Die einzelnen Einstellungen sollten eingeschätzt und möglichst restriktiv konfiguriert werden. Der bereits erwähnte CIS-Benchmark (in englischer Sprache) beinhaltet zudem einige Empfehlungen zu ASR, die im Kontext des Betriebs interpretiert und umgesetzt werden können.
Um ein böses Erwachen zu verhindern, sollte die Policy zunächst getestet werden. Der Roll-out wird dazu oft in zwei oder drei Phasen aufgeteilt. Zudem können die einzelnen ASR-Regeln erst in den Audit-Modus gesetzt werden. Im Defender-Portal sind die durch ASR generierten Meldungen ersichtlich – jedoch nur mit entsprechender Lizenz und aktivierter Defender-for-Endpoint-P2-Integration (z. B. über Microsoft 365 E5 oder dedizierter Defender for Endpoint P2).
Mit einer Microsoft-365-E3- oder Microsoft-365-Business-Premium-Lizenz können ASR-Regeln zwar über Intune konfiguriert und ausgerollt werden, zentrale Telemetrie, Berichte oder Warnmeldungen stehen im Security-Portal jedoch nicht zur Verfügung.
Ereignisse lassen sich in diesem Fall nur lokal (z. B. über die Windows-Ereignisanzeige, siehe dazu Microsofts‘ Dokumentation) oder über ein angebundenes SIEM auswerten. Bei aktivierter Defender-for-Endpoint-Integration können ASR-Events über Advanced Hunting im Defender-Portal gefunden und ausgewertet werden. Eine Abfrage könnte beispielsweise wie folgt starten:
DeviceEvents
| where ActionType startswith "Asr"
Bei manchen Problemen sollte die Policy nicht direkt aufgeweicht, sondern zunächst hinterfragt werden, wieso es beispielsweise notwendig sein soll, nicht vertrauenswürdige und unsignierte Prozesse von einem USB-Stick aus zu starten.
ASR Policies und EDR-Lösungen von Drittanbietern
Vorsicht ist geboten beim Einsatz von EDR-Lösungen von Drittanbietern. Microsoft beschreibt in seiner Dokumentation zu ASR die Voraussetzungen zur Umsetzung der Regeln auf dem Client. Microsoft schreibt:
Microsoft Defender Antivirus muss als primäre Antivirenlösung aktiviert und konfiguriert sein und sich im folgenden Modus befinden:
- Primäre Antiviren-/Antischadsoftwarelösung
- Status: Aktiver Modus
Microsoft Defender Antivirus darf sich in keinem der folgenden Modi befinden:
- Passiv
- Passiver Modus mit Endpunkterkennung und -antwort (EDR) im Blockmodus
- Eingeschränktes regelmäßiges Scannen (LPS)
- Aus
Das bedeutet: Wenn Sie eine EDR-Lösung eines anderen Herstellers einsetzen, befindet sich Defender in der Regel im passiven Modus oder ist sogar ausgeschaltet. Die Attack-Surface-Reduction-Regeln können in Intune zwar erstellt werden und die Policy kommt auf den Geräten auch an, die Regeln werden jedoch nicht durchgesetzt. Ob Defender läuft und in welchem Modus er sich befindet, kann mit PowerShell herausgefunden werden:
PS> Get-MpComputerStatus | Select-Object AMServiceEnabled,AntispywareEnabled,AntivirusEnabled,RealTimeProtectionEnabled,AMRunningMode
AMServiceEnabled : True
AntispywareEnabled : True
AntivirusEnabled : True
RealTimeProtectionEnabled : False
AMRunningMode : Passive Mode
Windows-Firewall effektiv einsetzen
Die Windows-Firewall ist ein weiteres Feature, das für eine Hardening Baseline für Windows-Clients essenziell ist. Es blockiert, insbesondere auf mobilen Geräten, ungewollte eingehende Verbindungen und reduziert so die Angriffsfläche, da auf Client-Systemen von aussen grundsätzlich nichts erreichbar sein sollte.
In meinem Artikel Schützende Windows-Firewall konfigurieren beschreibe ich, wie die Windows-Firewall schnell, einfach und sicher per GPO in Domänen konfiguriert und verteilt werden kann. Darauf aufbauend habe ich auf meinem privaten Blog beschrieben, wie dieselbe Baseline mittels Intune erstellt und ausgerollt werden kann – inklusive Exporte in JSON für noch schnellere Ergebnisse.
In einem weiteren Artikel habe ich beschrieben, welche Tipps es beim Erstellen zu beachten gibt und was die konfigurierbaren Werte genau bedeuten:
Fazit: Mit Windows 11 Hardening zu mehr IT-Sicherheit
Mit den beschriebenen Methoden und Empfehlungen lassen sich solide Security Baselines für über Intune verwaltete Windows-11-Geräte erstellen. Wie bei allen Massnahmen zur Systemhärtung sind ein gründliches Testen vor dem Roll-out und eine sorgfältige Dokumentation entscheidend für den Erfolg und die Akzeptanz von «Security» im Unternehmen.
Einige Elemente wie die Microsoft Security Baselines oder LAPS lassen sich mit vergleichsweise wenig Aufwand einführen und steigern dennoch die Sicherheit merklich. Die bereitgestellten Empfehlungen und Werte für die BitLocker- und LAPS-Einstellungen erleichtern den Einstieg zusätzlich. Dabei ist jedoch wichtig, stets die jeweilige Windows-Version und das konkrete Szenario, für das die Einstellungen gelten, zu berücksichtigen.
Mit diesen Schritten legen Sie den Grundstein für ein robustes Windows 11 Hardening, welches das Risiko von Angriffen deutlich reduziert und gleichzeitig einen spürbaren Mehrwert für die IT-Sicherheit Ihres Unternehmens bietet.
Viel Erfolg beim Härten!
