Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat seine technischen Analysen von Windows 10 im Projekt "SiSyPHuS Win10" aktualisiert, wie die Behörde am 24. Mai 2022 mitteilte. Das Projekt betrachtet die sicherheitskritischen Funktionen in Windows 10 und gibt Empfehlungen zur Härtung des Betriebssystems. Auch die Deaktivierung der Telemetrie wurde erneut betrachtet. Viele der Ergebnisse lassen sich, so das BSI, auf Windows 11 übertragen.
Anzeige
Das BSI unterzieht Windows 10 regelmäßig einer Sicherheitsanalyse und veröffentlicht die im Projekt SiSyPHuS Win10 ermittelten Ergebnisse. Bereits 2018 hatte ich im Blog-Beitrag BSI-Einstufung: Windows 10 ist ein 'Datenschutz-Unfall' über das BSI-Projekt SiSyPHuS Win10 berichtet. Hintergrund war damals, dass das Betriebssystem Windows 10 umfangreiche System- und Nutzungsinformationen an Microsoft sendet. Eine Unterbindung der Erfassung und Übertragung von Telemetriedaten durch Windows ist technisch zwar möglich, für Anwender aber nur schwer umzusetzen. Das war das Ergebnis einer Untersuchung der zentralen Telemetriekomponente von Windows 10, die das Bundesamt für Sicherheit in der Informationstechnik (BSI)durchgeführt hatte. Im Mai 2020 legte das BSI dann erste Teilergebnisse zum Projekt SiSyPHuS Win10 vor (siehe Windows 10: BSI veröffentlicht SiSyPHuS-Teilergebnisse).
Aktualisierung im Mai 2022
Die Woche hat das BSI nun über die Aktualisierung der technischen Analysen von Windows 10 im Rahmen des Projekts SiSyPHuS Win10 informiert. Ich bin über einen Tweet auf diesen Sachverhalt aufmerksam geworden – die entsprechende BSI-Information findet sich hier.
Mit dem Projekt SiSyPHuS Win10 (Studie zu Systemintegrität, Protokollierung, Härtung und Sicherheitsfunktionen in Windows 10) lässt das BSI Sicherheitsanalysen der sicherheitskritischen Funktionen in Windows 10 durchführen sowie darauf aufbauend passende Härtungsempfehlungen erstellen. In der ersten Fassung wurde Windows 10 in der Enterprise-Version 1607, die als LTSC-Ausgabe erhältlich ist (Support bis 13.10.2026), auf diese Sicherheitsfunktionen untersucht. In der Aktualisierung wurde nun Windows 10 Version 1809 (Windows 10 Enterprise 1909 LTSC, Support bis 09.01.2029) mit in die Analyse einbezogen.
Anzeige
Die Empfehlungen zur Härtung dieser Windows 10 LTSC-Versionen durch Gruppenrichtlinien haben also noch etwas länger Bestand. In obigem Tweet schreibt das BSI, dass man auch die Deaktivierung der Telemetrie erneut betrachtet habe und dass sich viele der Ergebnisse sich auf Windows 11 übertragen lassen. Das Problem im praktischen Umfeld ist aber, dass dort keine Windows 10 Enterprise LTSC-Versionen, sondern bestenfalls Windows 10 Enterprise oder Education, ggf. sogar Windows 10 Pro im Unternehmensumfeld im Einsatz sind. Und diese Versionen werden künftig im Jahres-Rhythmus aktualisiert und sind in der BSI-Analyse unberücksichtigt. Das gilt auch für den neuralgischen Punkt Telemetriedatenerfassung. Wer sich für das Thema erwärmt, findet im Dokument SiSyPHuS Win10: Studie zu Systemaufbau, Protokollierung, Härtung und Sicherheitsfunktionen in Windows 10 die komplette Beschreibung des Projekts samt Inhaltsübersicht über die einzelnen Kapitel. Dort taucht nun auch Windows 10 1809 auf.
heise kritisiert hier, dass die Version 1809 bereits 3 1/2 Jahre also sei, was zwar stimmt, aber im Hinblick auf die LTSC-Versionen nicht relevant ist. Das Problem ist vielmehr, dass das BSI etwas prüfen muss, welches in der Praxis nur selten in Unternehmen eingesetzt wird. So können die Empfehlungen des BSI zur Härtung und zur Telemetrie nur ein erster Ansatz sein, der durch das nächste Feature-Upgrade, bedingt durch die Änderungswut der Microsoft-Entwickler, bereits wieder Makulatur ist. Betrachtet es als Notnagel der Form "besser als nichts".
Ähnliche Artikel:
Windows 10: BSI veröffentlicht SiSyPHuS-Teilergebnisse
Windows 10 und die Sicherheitseinstellungen des BSI
BSI-Einstufung: Windows 10 ist ein 'Datenschutz-Unfall'
Behörden sollen unverzüglich auf Microsoft verzichten, fordern MVs Rechnungshof und Datenschutzbeauftragter
Anzeige
Betr. "Betrachtet es als Notnagel der Form "besser als nichts"":
Es gibt zunächst /1/. Würde fast wetten, dass das umfassender ist. Bis vermutlich auf 'Telemetrie abwürgen', womit sich Microsoft selbstredend in 's eigene Bein schiessen würde. Im weiteren gibt es – nur ganz kurz angetippt – noch das ganz grosse Rad namens OVAL /2/. /3/ listet Produkte, die mit OVAL Definitions in mehr oder weniger vielfältiger Weise umgehen können.
/1/
Microsoft Security Compliance Toolkit 1.0 – How to useArticle 05/12/2022
/2/
Open Vulnerability and Assessment Language
/3/
OVAL – By Capability List
Für Win 10/11 gibt es ein Tool von O&O, mit dem auch der Laie einiges an Telemetrie ausschalten kann (muss man aber nach jedem Windows Update erneut ausführen, um eventuelle Änderungen durch MS wieder zurückzusetzen).
Programm: https://www.oo-software.com/de/shutup10
Anleitung und Beispielkonfiguration der Uni Köln:
Problem ist, dass der Laie mit O&O Shutup an seinem W10 Home früher oder später dann in Probleme läuft, die er dann nicht dem Tool zuordnen kann.
Deswegen gibt es ja die Option nur empfohlene Einstellungen zu setzen. Wenn ein Laie nicht lesen kann, muss er halt aus seinen Fehlern lernen. Das sind die gleichen Menschen die bei "Frisch gestrichen" Schildern mit den Fingern reinpatschen :)
@Bernd:
Solche Tools leiden massiv an Transparenz was sie eigentlich tun.
Wenn ich Settings via GPO deaktivere, und die werden in den Tools als nicht deaktiviert angezeigt, habe ich meine Zweifel was da passiert. Da gehe ich lieber die GPO-Settings durch, und weis das dieser Weg supportet ist.
https://paste.debian.net/1240874/
Da deaktivere ich lieber die Dienste via Batchfile via Aufgabenplanuung beim booten, als mich auf iwelche Thirdparty Tools zu verlassen, wo ich garnicht weis welche Interessen hinter der wochenlangen Entwicklung gesteckt haben mögen.
Betr. "Wenn ich Settings via GPO deaktivere, und die werden in den Tools als nicht deaktiviert angezeigt, …":
Ich erinnere mich dunkel, dass das von Ihnen beobachtete Phänomen auch ohne 3rd party Tools auftreten kann. S. auf die Schnelle stellvertretend /1/.
/1/
Registry Based Local Policy Not Showing as Configured in gpedit.msc
Thread opened: Thursday, December 3, 2015 11:05 PM
https://social.technet.microsoft.com/Forums/en-US/8476c17b-5893-41ee-a185-79a886056a98/registry-based-local-policy-not-showing-as-configured-in-gpeditmsc?forum=win10itprogeneral
Um das nochmal an einem Beispiel zu konkretisieren:
>>Windows Fehler Berichterstattung deaktivieren <<
GPO setzt:
HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Error Reporting!Disabled
Die Microsoft Dokus bestätigen diesen Wert.
OOSU10 vom 30.05.2022 setzt laut ProcessMonitor folgenden Wert:
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Disabled
Weiteres Problem:
Diverse OO-Settings setzen User-Settings, anstatt Maschine-Settings.
Diese müssten in Multiuser-Sitzungen alle neu geladen werden.
@McAndrew
Mir erschliesst sich der Sinn dieser lebensfernen Diskussion nicht?
Gibt es vollständigere/bessere Methoden, als OO? Absolut!
Sind sie für den Laien(!) umsetzbar? Absolut _nicht_!
Also empfiehlt man dem Laien OO, falls man nicht selbst Dienstleister ist und eher Umsatz generieren will (also verkaufs- statt kundenorientiert berät).
P.S. Leseempfehlung: https://der-prozessmanager.de/aktuell/wissensdatenbank/pareto-prinzip
@Bernd:
>> Mir erschliesst sich der Sinn dieser lebensfernen Diskussion nicht
Das konkrete Beispiel zeigt auf, das möglicherweise/vermutlich einige Settings von OO nicht korrekt greifen. Ähnliche Feststellungen haben im übrigen auch schon andere, bereits vor Jahren gemacht (Quellen habe ich keine zur Hand).
Weitere Beispiele die gegen OO sprechen:
* Es werden in OO fundamentale Datenschutz-Settings wie vollständige URL-Übertragungen, und KI- Bildanalyse an Microsoft überhaupt nicht angeboten.
* Auch werden keinerlei Datenschutz-Settings für Office angeboten, so das jeder Office-Klick und bei Crashes die Vollständigen Office-Dokumente nach Microsoft fliessen.
Das alles hinterlässt für mich einen schlechten Beigeschmack, leider.
Also weil OO Lücken hat soll der User lieber gar nichts tun (Nein, "lern es halt!!" ist keine valide Option)?
Seltsame Logik. Welcher Teil des Pareto-Prinzips will Ihnen nicht eingehen?
Ob 1809 oder 21H2 es ist und bleibt eine Fummelei Windows einigermaßen so zurechtzustutzen, daß man halbwegs sicher damit arbeiten kann. Mit jedem Funktionsupdate wird das aufwendiger und schwieriger. Microsoft ist nicht daran gelegen ein sicheres Betriebssystem bereitzustellen. Wenn man das berücksichtigt, ist Windoes11 und alles was danach kommt eindeutig ein NO-GO.
Windows Server 2019 und Windows 10 1809 LTSC laufen bei uns abgesehen von den anfänglichen Schwierigkeiten beim Hyper-V Dienst (VM-Shutdownproblem) seit ca. 2 Jahren problemlos. Die großen, auch hier im Blog kommunizierten Kompatibilitäts-Probleme sind ausgeblieben. Selbst aktuelle Software läuft bei uns. Updates werden über WSUS eingespielt, Telemetriesammlungen sind minimiert, Datenschutz maximiert, Probleme durch Funktionsupdates kennen wir nicht. Loift.
Das Werte manuell gesetzte Registry-Settings nicht unter gpedit.msc erscheinen klingt mir plausibel: gpedit.msc pflegt meines Wissens seine eigene Datenbank und überträgt nur diese Werte in die Registry. Beim Neuöffnen läd gpedit.msc seine eine Datenbank ein.
Für Thirdparty-Tools welches als Portable-App laufen, dürfen dann aber nur die tatsächlichen Registry-Werte von Belang sein. O.g. Beispiel für die "Windows Fehlerberichterstattung", oder "Policys im UserContext anstatt im MashineContext" lassen eher die Vermutung zu das die Thirdparty-Tools in Details nicht 100% optimal/korrekt funktionieren. Zumal Microsoft die internen Reg-Pfade und intern GPO-Settings ändern kann, ohne das das Thirdparty-Applikationen registrieren.