Beobachtung aus der Praxis

Ich erlebe bei Windows-11-Projekten oft dasselbe Muster: Das Betriebssystem ist aktuell, ein Endpoint-Produkt wie Sophos ist im Einsatz, die Geräte sind modern – und trotzdem bleibt die Umgebung unnötig offen. Nicht, weil jemand „schlecht“ arbeitet. Sondern weil Härtung häufig mit Einzelmaßnahmen verwechselt wird.

Dann werden drei, vier Funktionen aktiviert, irgendwo gibt es noch lokale Administratorrechte, Office darf zu viel, Skripte laufen fast ungebremst, Altlasten bleiben aus Kompatibilitätsgründen erhalten – und am Ende entsteht Sicherheit eher auf dem Papier als im Alltag.

Genau deshalb trenne ich sauber zwischen Schutzsoftware und Systemhärtung. Ein guter Endpoint-Schutz ist wichtig. Aber er ersetzt nicht die Entscheidung, Windows 11 selbst so zu konfigurieren, dass unnötige Risiken gar nicht erst breit wirksam werden.

Mythos vs. Realität

Wie es funktioniert

Wenn ich Windows 11 härte, denke ich nicht in einzelnen Häkchen, sondern in vier klaren Hebeln:

1. Weniger Angriffsfläche
2. Weniger nutzbare Rechte
3. Weniger unerwartete Ausführung
4. Mehr Nachvollziehbarkeit im Betrieb

Für mich beginnt Härtung deshalb nicht bei Spezialfunktionen, sondern bei Fragen wie:

• Was darf auf dem Gerät überhaupt laufen?
• Wer darf lokal mehr als nötig?
• Welche Altprotokolle und Komfortfunktionen brauche ich in Wahrheit nicht?
• Wie stelle ich sicher, dass Richtlinien nicht nur existieren, sondern flächig wirken?

Diese Logik ist wichtig, weil sie auch Management-Entscheidungen sauber macht. Ich muss nicht jede technische Feinheit diskutieren. Ich muss zuerst entscheiden, welches Betriebsmodell ich will: kontrolliert oder bequem. Beides gleichzeitig klappt selten.

Die Maßnahmen, die ich bei Windows 11 priorisieren würde

1. Lokale Administratorrechte konsequent zurückdrängen

Wenn ich nur eine Maßnahme priorisieren dürfte, dann wäre es fast immer diese. Lokale Administratorrechte machen aus kleinen Vorfällen schnell größere Probleme. Was mit einem einzelnen Benutzerkonto beginnt, kann sich dadurch deutlich leichter auf dem Gerät ausweiten.

Was ich praktisch umsetze:

• Standardnutzer ohne lokale Adminrechte
• Administrativer Zugriff nur für definierte Rollen
• Trennung zwischen Alltagskonto und Administrationskonto
• Lokale Passwörter nicht statisch, sondern verwaltet und regelmäßig rotiert

Relevante GPOs / Einstellungen:

oder moderner über lokale Gruppenverwaltung / Gerätekonfiguration zentral gesteuert.

Windows LAPS priorisieren:

Wichtige Punkte:

• Passwortverwaltung für lokale Admin-Konten zentral aktivieren
• Kennwortrotation erzwingen
• Nur berechtigte Gruppen dürfen Kennwörter auslesen

Registry-Beispiel (LAPS, abhängig von eingesetzter Variante):

Meine Haltung dazu:
Ich diskutiere bei diesem Punkt ungern lange. Lokale Adminrechte aus Bequemlichkeit sind im Alltag fast immer teurer als die saubere Umstellung.

2. BitLocker verpflichtend und sauber ausrollen

Ich halte es für einen Fehler, Laufwerksverschlüsselung noch als „Option“ zu behandeln. Geräte gehen verloren, werden ausgetauscht, landen bei Dienstleistern oder sind schlicht außerhalb kontrollierter Räume unterwegs.

Was ich praktisch umsetze:

• BitLocker für Betriebssystemlaufwerke verpflichtend
• TPM nutzen, bei höherem Schutzbedarf TPM + PIN prüfen
• Recovery-Information zentral sichern
• Nachweisbare Compliance: verschlüsselt heißt nicht „sollte aktiv sein“, sondern „ist überprüfbar aktiv“

GPOs:

Sinnvolle Richtlinien:

Registry-Beispiele:

Warum das für Entscheider relevant ist:
Weil dieser Punkt nicht nur Sicherheit betrifft, sondern auch Haftung, Datenschutz und Betriebsdisziplin.

3. Application Control statt „mal sehen, was die Nutzer starten“

Ich sehe viele Umgebungen, in denen praktisch jede ausführbare Datei eine Chance bekommt. Für mich ist das zu offen. Wer ernsthaft härten will, muss die Frage beantworten: Was darf laufen – und was nicht?

Hier geht es nicht darum, sofort alles zu blockieren. Aber ich halte es für sinnvoll, den Weg in Richtung Positivmodell einzuschlagen.

Optionen:

• AppLocker: gut verständlich, für viele Umgebungen praktikabel
• Windows Defender Application Control (WDAC): strenger und nachhaltiger, aber mehr Einführungsdisziplin nötig

AppLocker-GPO:

Typische Regelbereiche:

• Executable Rules
• Windows Installer Rules
• Script Rules
• Packaged app Rules

Mein pragmatischer Weg:

1. Audit-Modus starten
2. Zulässige Anwendungen identifizieren
3. Ausnahmen zurückdrängen
4. Schrittweise verbindlich machen

Wichtige Registry-Pfade (je nach Regeltyp):

Warum ich das priorisiere:
Weil viele Vorfälle davon leben, dass irgendetwas Unerwartetes gestartet werden kann – Tools, Loader, Skripte, Hilfsprogramme, Installer. Wenn ich diese Freiheit reduziere, sinkt das Risiko spürbar.

4. Office, Makros und Skriptausführung enger führen

Viele Angriffe brauchen keinen technischen Glanz. Sie brauchen nur einen Dateityp, einen neugierigen Klick und zu viel Freiraum bei der Ausführung.

Deshalb betrachte ich Office-Härtung und Skriptkontrolle als Pflichtprogramm.

Was ich konkret umsetze:

• Makros aus dem Internet blockieren
• Nur signierte Makros dort zulassen, wo sie fachlich wirklich nötig sind
• PowerShell bewusster nutzen, nicht als unbegrenzte Allzweckfläche
• Skriptausführung dokumentieren und zentral bewerten

Office-Richtlinien:

Wichtige Einstellungen:

PowerShell-Beispiele:

• Ausführungsrichtlinie nicht als alleiniges Sicherheitsmittel betrachten
• Logging aktivieren
• Wo möglich nur signierte oder definierte Skripte zulassen

GPOs für PowerShell Logging:

Registry-Beispiele:

Meine Sicht:
Ich halte es für fahrlässig, Office und Skriptumgebungen offen zu lassen und dann auf den Rest der Schutzkette zu vertrauen.

5. Credential-Schutz und Virtualization-Based Security nutzen

Ein modernes Windows-11-Gerät sollte Zugangsdaten und sicherheitskritische Prozesse nicht so behandeln wie ein älteres Desktop-System. Gerade wenn Anmeldeinformationen im Spiel sind, zählt Trennung.

Was ich sinnvoll finde:

• Virtualization-Based Security (VBS) nutzen
• Credential Guard prüfen und wo passend aktivieren
• Schutz des LSASS-Prozesses stärken
• Secure Boot und TPM nicht nur „haben“, sondern in das Härtungskonzept einbinden

GPOs:

Wichtige Richtlinien:

Registry-Beispiele:

Pragmatik statt Dogmatik:
Ich rolle solche Funktionen nicht blind aus. Ich prüfe Kompatibilität, Leistung und Sonderfälle. Aber ich lasse sie auch nicht aus alter Vorsicht pauschal weg.

6. Netzwerk und eingehende Kommunikation restriktiv behandeln

Auch bei Clients gilt: Was nicht gebraucht wird, sollte nicht offen sein. Ich sehe häufig Firewalls, die zwar aktiv sind, aber über Ausnahmen oder Mischzustände unnötig durchlässig werden.

Was ich umsetze:

• Eingehende Verbindungen standardmäßig blocken
• Nur definierte Ausnahmen zulassen
• Remote-Verwaltung nur, wenn sie wirklich nötig ist
• RDP restriktiv behandeln oder ganz vermeiden, wenn es fachlich nicht gebraucht wird

GPOs:

Sinnvoller Grundsatz:

• Inbound: restriktiv
• Ausnahmen: dokumentiert und begründet
• Profiltrennung: Domain / Private / Public bewusst nutzen

Registry-Beispiel:

Warum das wichtig ist:
Weil viele Umgebungen historisch gewachsen sind. Ausnahmen bleiben jahrelang bestehen, obwohl sie längst niemand mehr braucht.

7. Altlasten und unnötige Protokolle konsequent entfernen

Hier wird Härtung oft unromantisch – und genau deshalb wirksam. Ich halte es für einen großen Fehler, aus Bequemlichkeit veraltete Funktionen weiter mitzuschleppen.

Was ich gezielt prüfe und möglichst reduziere:

• SMBv1 deaktivieren
• NTLM-Nutzung zurückdrängen, wo realistisch
• Unnötige Legacy-Komponenten entfernen
• Autorun / Autoplay restriktiv behandeln
• Nicht benötigte optionale Windows-Features abschalten

SMBv1 PowerShell / Windows-Feature-Bezug:

• SMBv1 gehört in modernen Umgebungen in der Regel nicht mehr zum Standardbetrieb

Autorun GPO:

Registry-Beispiel:

Meine Linie:
Kompatibilität ist kein Freifahrtschein für Dauer-Ausnahmen. Wenn etwas alt und riskant ist, braucht es einen klaren Migrationspfad oder eine bewusste Rest-Risiko-Entscheidung.

8. Patchen standardisieren – aber nicht als einzige Sicherheitsstrategie

Ich halte Patchmanagement für selbstverständlich, aber nicht für ausreichend. Viele Organisationen sprechen über Patches so, als wäre damit Härtung erledigt. Das sehe ich anders.

Was ich will:

• Verlässliche Update-Ringe
• Klare Zeitfenster für Qualitätsupdates
• Treiber- und Firmware-Frage bewusst behandeln
• Ausnahmen klein halten und sichtbar machen

GPOs:

Entscheider-Perspektive:
Patchen ist Betriebsdisziplin. Härtung ist Designentscheidung. Beides gehört zusammen, ist aber nicht dasselbe.

Typische Fehler, die ich bewusst lasse

1. „Wir härten erst einmal alles“

Das klingt entschlossen, endet aber oft in Rückbau, Frust und Sonderregeln. Ich gehe lieber priorisiert vor.

2. „Ein paar Power-User behalten lokale Adminrechte“

Ausnahmen wachsen fast immer. Was zuerst pragmatisch wirkt, wird schnell zum versteckten Standard.

3. „Audit-Modus reicht erst einmal“

Audit ist ein guter Einstieg, aber kein Zielzustand. Wer nie in verbindliche Regeln überführt, bleibt in der Beobachtung stecken.

4. „Legacy lassen wir, bis irgendwann später“

Später ist in vielen Umgebungen ein anderer Ausdruck für dauerhaft.

5. „Unser Endpoint-Produkt fängt das schon ab“

Das ist aus meiner Sicht die falsche Arbeitsteilung. Endpoint-Schutz ist wichtig. Die Grundhärtung des Betriebssystems bleibt trotzdem meine Verantwortung.

Soft-Zone: Mitwirkung & Organisation

Ich sehe Windows-Härtung nicht als reine Technikübung. Sie funktioniert nur dann sauber, wenn Fachbereiche und IT dieselbe Erwartung an den Arbeitsplatz haben.

Ein gehärteter Client ist nicht in jeder Situation maximal bequem. Dafür ist er berechenbarer. Genau das muss intern kommuniziert werden. Wenn Fachbereiche wissen, wie Softwarefreigaben laufen, warum lokale Adminrechte entfallen und welche Standards gelten, sinkt der Widerstand deutlich.

Ich formuliere das intern möglichst einfach:

Das ist keine Misstrauenserklärung gegenüber Mitarbeitenden. Es ist ein Betriebsmodell.

Soft-Zone: Kontrolle, Monitoring, Transparenz

Ich halte Transparenz für einen wesentlichen Teil der Akzeptanz. Wenn ich Härtung einführe, dann erkläre ich auch, was protokolliert wird, warum das nötig ist und wofür die Daten nicht genutzt werden.

Wichtig ist für mich:

• zweckgebundene Protokollierung
• keine Sammelwut
• klare Zuständigkeiten
• nachvollziehbare Eskalationswege

Hier gilt ein ruhiger Grundsatz:

Wenn diese Grenze sauber kommuniziert wird, entstehen weniger unnötige Konflikte.

Praxisbeispiele

Handlungsteil

Beispielhafte Baseline, die ich als Minimum sehen würde

Wenn mich jemand nach einem realistischen Mindestniveau fragt, dann ist das ungefähr die Richtung, die ich vertreten würde:

• kein lokaler Admin im Alltag
• BitLocker verpflichtend
• LAPS aktiv
• Makros restriktiv
• PowerShell-Logging aktiv
• Firewall inbound restriktiv
• Legacy-Komponenten abbauen
• Application Control mindestens vorbereitet, idealerweise schrittweise verbindlich
• VBS / Credential-Schutz dort aktiv, wo technisch tragfähig
• Patch- und Ausnahmemanagement sauber geregelt

Das ist noch keine „maximale Härtung“. Aber es ist aus meiner Sicht eine vernünftige, belastbare Linie.

Grenzen & Wirkung

Diese Maßnahmen machen Windows 11 nicht unangreifbar. Das ist auch nicht mein Anspruch. Mein Anspruch ist ein anderer: Ich möchte Standardangriffe unattraktiver machen, seitliche Bewegungen erschweren, Zufallserfolge reduzieren und Vorfälle schneller einordnen können.

Genau darin liegt der praktische Nutzen. Gute Härtung ist nicht spektakulär. Sie reduziert Freiräume, schafft Standards und verkürzt im Ernstfall die Reaktionszeit.

Abschluss

Offene Frage: Welche Freiheiten in Ihrer Windows-11-Umgebung existieren heute noch nur deshalb, weil sie historisch bequem waren – nicht weil sie fachlich wirklich nötig sind?