Windows 10 V1903: Security Baseline und (neue) Passwort Gruppenrichtlinien

Microsoft hat kürzlich den Draft seiner Security Baseline für Windows 10 V1903 und Server 1903 freigegeben. Zudem will Microsoft auf den Zwang zum Wechsel von Kennwörtern künftig verzichten.


Anzeige

Security Baseline (Draft) verfügbar

Microsoft hat vor einigen Tagen den Draft der Security Baseline für Windows 10 V1903 und Windows Server 1903 freigegeben. Die Security Baseline stellt die Sicherheitskonfigurationseinstellungen dar. Das Security Baseline-Paket besteht aus Dokumentation und Gruppenrichtlinien sowie PowerShell-Scripten, mit denen sich eine Basisabsicherung über bestimmte Einstellungen vornehmen lässt.

Die Ankündigung des Drafts erfolgte bereits am 24. April 2019 in diesem Microsoft-Blog-Beitrag. Dort lässt sich auch die benötigte ZIP-Datei herunterladen, wie die Kollegen von deskmodder.de hier anmerken. Hier die Liste der Änderungen gegenüber der Security Baseline von Windows 10 V1809.

  • Enabling the new "Enable svchost.exe mitigation options" policy, which enforces stricter security on Windows services hosted in svchost.exe, including that all binaries loaded by svchost.exe must be signed by Microsoft, and that dynamically-generated code is disallowed. Please pay special attention to this one as it might cause compatibility problems with third-party code that tries to use the svchost.exe hosting process, including third-party smart-card plugins.
  • Configuring the new App Privacy setting, "Let Windows apps activate with voice while the system is locked," so that users cannot interact with applications using speech while the system is locked.
  • Disabling multicast name resolution (LLMNR) to mitigate server spoofing threats.
  • Restricting the NetBT NodeType to P-node, disallowing the use of broadcast to register or resolve names, also to mitigate server spoofing threats. We have added a setting to the custom "MS Security Guide" ADMX to enable managing this configuration setting through Group Policy.
  • Correcting an oversight in the Domain Controller baseline by adding recommended auditing settings for Kerberos authentication service.
  • Dropping the password-expiration policies that require periodic password changes. This change is discussed in further detail below.
  • Dropping the specific BitLocker drive encryption method and cipher strength settings. The baseline has been requiring the strongest available BitLocker encryption. We are removing that item for a few reasons. The default is 128-bit encryption, and our crypto experts tell us that there is no known danger of its being broken in the foreseeable future. On some hardware there can be noticeable performance degradation going from 128- to 256-bit. And finally, many devices such as those in the Microsoft Surface line turn on BitLocker by default and use the default algorithms. Converting those to use 256-bit requires first decrypting the volumes and then re-encrypting, which creates temporary security exposure as well as user impact.
  • Dropping the File Explorer "Turn off Data Execution Prevention for Explorer" and "Turn off heap termination on corruption" settings, as it turns out they merely enforce default behavior, as Raymond Chen describes here.

So wirklich viel hat sich gegenüber der Version 1809 nicht verändert.

Microsoft verzichtet auf Zwang zum Passwortwechsel

Eine bemerkenswerte Änderung gibt es: Microsoft verzichtet in der Security Baseline darauf, die Kennwörter von Benutzerkonten zyklisch zurückzusetzen. Das war eine Option in Business-Umgebungen, wo Benutzerkennwörter nach meist 30 Tagen ungültig wurden und vom Benutzer zu ändern waren. Windows 10-Nutzer im Home-Segment waren davon nicht betroffen, da die Windows-Home-Versionen so etwas nicht direkt unterstützen. Ärger gab es höchstens, wenn diese Option durch irgend eine Software aktiviert wurde und dann den Nutzer nach einem neuen Passwort fragte.


Anzeige

Problem bei dieser Passwort-Verfallsrichtlinie war, dass die Leute entweder einfache Kennwörter festlegten oder diese auf einem Zettel notierten und unter der Tastatur hinterlegten. Jüngste wissenschaftliche Untersuchungen stellen daher den Wert vieler langjähriger Passwortsicherheitspraktiken wie Passwort-Verfallsrichtlinien in Frage Stattdessen gibt es bessere Alternativen wie die Durchsetzung von Sperrkennlisten und die Multi-Faktor-Authentifizierung. Microsoft empfiehlt zwar diese Alternativen, kann diese aber nicht mit den empfohlenen Baselines für die Sicherheitskonfiguration ausdrücken oder durchsetzen. Denn diese Sicherheitskonfiguration basiert auf den integrierten Gruppenrichtlinieneinstellungen von Windows und enthält keine kundenspezifischen Werte.

Daher verzichtet Microsoft mit den kommenden Windows 10 V1903 Security Baselines auf Passwort-Verfallsrichtlinien. Martin Geuß hat sich vor einigen Tagen hier zu diesem Thema geäußert und von Heise gibt es diesen Beitrag dazu. Zudem arbeitet sich Windows Pro hier an den neuen GPOs ab.

Ähnliche Artikel:
Security Baseline für Windows 10 Version 1809/Server 2019


Anzeige

Dieser Beitrag wurde unter Windows 10 abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Eine Antwort zu Windows 10 V1903: Security Baseline und (neue) Passwort Gruppenrichtlinien

  1. Martin Feuerstein sagt:

    Interessanter finde ich das Ding mit dem SVCHOST… da nicht mehr ausgeführt werden soll:
    – wenn eine Komponente nicht von MS signiert ist oder
    – nicht statisch gelinkt ist

    Mir ist kein Dienst bekannt, der SVCHOST nutzt und nicht von Microsoft stammt, aber dass ein externes Programm mit dynamisch gelinkten Bibliotheken oder nicht signiert von Microsoft sich an einen Prozess dranhängt (z. B. ein Virenscanner), könnte ich mir gut vorstellen.
    Klar, würde man sonst eher von Malware oder Viren erwarten, aber… AV-Bugs im letzten Monaten hatten wir ja auch, die über CSRSS gestolpert sind…

    Vielleicht kann Stephan Kanthak mehr dazu sagen? Mit so Zeugs dürfte der sich ja besser auskennen.

    Das mit der Namensauflösung in Windows 10 ist aber auch nicht so wirklich der Hit (oben: LLMNR) – insbesondere wenn eine VPN-Verbindung eben nicht Gateway und DNS komplett umleitet, sondern DNS-Abfragen von sowohl SSLVPN- und echtem Netzwerkadapter beantwortert werden (und der echte Netzwerkadapter schneller mit einer falschen Antwort antwortet als der VPN-Adapter)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.