Der IT-Security-Podcast reicht ein paar Themen außer der Reihe nach, für die in der vergangenen Jubiläumsfolge einfach kein Platz mehr war. Los geht es mit einer Liste, in der Google öffentlich notiert, welche Certificate-Transparency-Logs der Browser Chrome nutzt. Eine alte Version dieser Liste würde Google gerne abschalten – doch jedes Mal, wenn sie das versuchen, fallen erschreckend viele Apps von Drittanbietern aus. Die Hosts diskutieren, wie das kommt, was für fast schon kafkaeske Erfahrungen das Chrome-Team machen musste und welche neuen Ideen Google nun helfen sollen, die Liste abzuschalten – eines Tages, hoffentlich, jedenfalls nicht vor Juli 2027 …

Im weiteren Verlauf der Folge geht es um die Ransomware-Gang AlphV, die ein Comeback feiern will, und dafür auf die Blockchain setzt. Technisch keine dumme Idee, wenn auch keine Verwendung, die als werbewirksames Beispiel für den Wert von Blockchains taugt. Etwas beunruhigend finden die Hosts, dass AlphV unter anderem deshalb auf Blockchains setzt, weil sie dem Tor-Netzwerk nicht mehr trauen.

Ebenfalls beunruhigend sind die Erfahrungen des curl-Projekts mit Bug-Bounties: Getrieben von der Hoffnung auf diese Belohnung, überschwemmten angebliche Bug-Finder das Projekt mit KI-generiertem Nonsens. Der behauptete, höchst kritische Fehler zu melden, war in Wahrheit aber zusammenfantasierter Müll. All diese Meldungen zu entlarven, kostete so viel Zeit, dass curl sein Bug-Bounty-Programm eingestellt hat. Schlimmer wäre eigentlich nur, in KI-generierten Meldungen zu versinken, die tatsächlich kritische Lücken beschreiben – auch dieses Szenario sehen erste Entwickler am Horizont.

Zum Schluss müssen die Hosts noch vor einer höchst gefährlichen Lücke warnen, die viele telnet-Betreiber betrifft – also hoffentlich, hoffentlich, fast niemanden im Podcast-Publikum. Die neueste Folge von „Passwort – der heise security Podcast“ steht seit Mittwochmorgen auf allen Podcast-Plattformen zum Anhören bereit.

(syt)

Microsoft hat umfassende Änderungen an der Windows-Sicherheitsarchitektur angekündigt, die auf den ersten Blick nach einem Fortschritt klingen – bei genauerem Hinsehen aber erhebliche Schwachstellen offenbaren. Künftig sollen zwei neue Mechanismen für mehr Transparenz und Kontrolle sorgen: der „Windows Baseline Security Mode“ und erweiterte Nutzerberechtigungen unter dem Label „User Transparency and Consent“. Beide Ansätze werfen jedoch zentrale Fragen auf, die Microsoft bislang unbeantwortet lässt.

Der neue Baseline Security Mode soll standardmäßig nur noch signierte Anwendungen, Dienste und Treiber zur Ausführung zulassen. Aus Sicht vieler Security-Beauftragten mag das eine sinnvolle Maßnahme gegen Schadsoftware sein, sie nimmt den Anwendern aber in hohem Maß die Freiheit, ihren Windows-PC nach eigenem Belieben zu nutzen – wäre da nicht das Opt-out-Modell. Nutzer und IT-Administratoren können für einzelne Apps Ausnahmen definieren und damit die Schutzfunktion gezielt aushebeln.

Genau aufgrund dieser Möglichkeit verbleibt aus Security-Sicht jedoch ein potenzielles Einfallstor: Wird ein System einmal kompromittiert, können Angreifer diese Ausnahmen prinzipiell manipulieren oder selbst definieren. Am Ende kann Microsoft im Drahtseilakt zwischen Sicherheit und Nutzerfreundlichkeit also keine Seite richtig befriedigen. Der Blick über den Tellerrand zeigt, dass Apples vergleichbares Vorgehen bei macOS bei Anwendern nur bedingt gut ankommt.

Microsofts Ankündigung bleibt zudem vage, was die technische Umsetzung betrifft. Der Konzern spricht von „Runtime Integrity Safeguards“, ohne zu konkretisieren, wie sich diese von bestehenden Mechanismen wie Smart App Control unterscheiden. Letzteres nutzt Cloud-basierte Reputationsprüfungen und maschinelles Lernen, um verdächtige Software vor dem Start zu blockieren. Der Baseline Security Mode soll anscheinend primär breiter ansetzen und auch Dienste sowie Treiber zur Laufzeit überwachen – doch wie genau diese Prüfung ablaufen soll, gibt Microsoft bislang nicht bekannt.

Fragmentierung und Legacy-Probleme vorprogrammiert

Bereits sicher ist hingegen, dass die Situation für Unternehmens-IT und Organisationen mit älteren Anwendungen besonders problematisch wird. Unsignierte Legacy-Software wird unter dem neuen Regime blockiert, sofern Administratoren nicht manuell Ausnahmen konfigurieren. Das bedeutet erheblichen Verwaltungsaufwand für etliche IT-Abteilungen – und das Risiko einer fragmentierten Anwendungslandschaft. Hinzu kommt: Entwickler, die keine Ressourcen für die Code-Signierung aufbringen können oder wollen, werden faktisch von einem breiten Teil der Windows-Nutzerbasis ausgeschlossen. Besonders hart trifft das Open-Source-Projekte und Entwickler, die sich teure Code-Signing-Zertifikate von Microsoft nicht leisten können oder wollen.

Microsoft plant eine schrittweise Einführung, ohne konkrete Zeitpläne oder Meilensteine zu nennen. Sollen die neue Security-Maßnahmen schnell greifen, wäre ein Start bereits mit der Windows Insider Preview Mitte 2026 denkbar, zum Beispiel in Version 26H2 – oder einem künftigen Windows 12. Welche konkreten APIs und Tools der Konzern Entwicklern zur Verfügung stellen wird, um ihre Software anzupassen, bleibt ebenfalls unklar. Microsoft verweist lediglich auf kommende Blogbeiträge und Feedback-Kanäle – eine auffallend dünne Informationsbasis für eine derart weitreichende Änderung in Windows.

Berechtigungsabfragen nach Smartphone-Vorbild

Genauso zweischneidig ist das zweite neue zweite Security-Standbein: erweiterte Berechtigungsabfragen, wie sie von iOS und Android bekannt sind. Apps sollen künftig Nutzer um Erlaubnis fragen, bevor sie auf Dateien, Kamera oder Mikrofon zugreifen. Während macOS oder mobile Betriebssysteme seit Jahren granulare Berechtigungen durchsetzen, hinkt Windows in dieser Hinsicht tatsächlich deutlich hinterher.

Doch auch hier droht ein altbekanntes Problem: Prompt Fatigue, die Ermüdung durch zu viele Berechtigungsabfragen. Microsoft verspricht „klare und umsetzbare Prompts“, liefert aber keine Details, wie das Betriebssystem eine Überflutung der Nutzer mit Pop-ups vermeiden soll. Zudem bleibt offen, wie das System mit KI-Agenten umgeht, die zunehmend autonom agieren. Microsoft erwähnt „höhere Transparenzstandards“ für solche Anwendungen – freilich ohne deren Umsetzung zu erläutern.

Performance-Einbußen und Datenschutzbedenken

Obendrein dürften die geplanten Runtime-Checks die Systemleistung negativ beeinträchtigen, besonders auf Rechnern mit vielen installierten Anwendungen. Oder auf ohnehin altersschwachen PCs in etlichen Büros. Jede Prüfung kostet Rechen- und obendrein noch Arbeitszeit – ein Overhead, den Microsoft bislang nicht quantifiziert.

Auch datenschutzrechtlich wirft die erweiterte Überwachung von App-Aktivitäten Fragen auf. Um Transparenz herzustellen, muss das Betriebssystem kontinuierlich erfassen, welche Anwendung auf welche Ressourcen zugreift. Diese Telemetriedaten könnten bei einer Übertragung in die USA problematisch werden, insbesondere im Kontext der Datenschutz-Grundverordnung (DSGVO). Microsoft äußert sich nicht dazu, wie diese Daten gespeichert, verarbeitet oder möglicherweise übertragen werden.

Sollte also bei Windows alles so bleiben wie gehabt? Nein – aber gerade das offene System hat den PC vor langer Zeit zum Erfolg geführt. Nutzer durften installieren und ausführen, was sie wollten. Im Gegensatz zur vorigen Computer-Welt in Unternehmen. Dass Sicherheit heute eine größere Rolle spielen muss, ist unbestritten. Doch statt sie durch Abschottung und Nutzergängelung zu erreichen, wären ein besseres Design des Systems selbst und vor allem verlässliche Updates der richtige Weg.

(fo)

Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt, sich in Zukunft nicht mehr allein auf klassische asymmetrische Verschlüsselung zu verlassen und quantensichere Verfahren zu nutzen. Entsprechende Handlungsempfehlungen enthält die jährliche Aktualisierung der technischen Richtlinie TR-02102. Entwickler und Anwender von Kryptosystemen müssen allerdings nicht alles stehen- und liegenlassen: Das BSI setzt einen Zeitrahmen bis 2031.

Nicht ob und wann Quantencomputer traditionelle Verschlüsselungsverfahren bedrohten, stehe zur Sicherheitsbetrachtung im Vordergrund, schreibt das BSI. Es gebe Standardverfahren, deshalb solle die Migration zu Post-Quanten-Kryptografie vorangetrieben werden. In seiner 2026er-Ausgabe der Technischen Richtlinie 02102-1, „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“, spiegelt sich diese Einschätzung nun erstmals wider. In TR02102-1 heißt es nun:

Der alleinige Einsatz von klassischen Schlüsseleinigungsverfahren wird nur noch bis Ende 2031 empfohlen, siehe auch Abschnitt 2.3. Für Anwendungen mit sehr hohem Schutzbedarf sollte die Umstellung bereits bis Ende 2030 erfolgen. Dies geht aus einer gemeinsamen Empfehlung des BSI und europäischen (sic) Partnerbehörden hervor.

Wohlgemerkt: Zunächst geht es um die Schlüsseleinigung, also die Aushandlung einer sicheren Verbindung. Die Zeitpläne für andere Verschlüsselungsfunktionen sehen anders aus – digitale Signaturen etwa sollten erst ab 2036 auf hybride Verfahren umgestellt sein. Die Empfehlung bezieht sich nur auf die Kombination von PQC- mit einem klassischen Verfahren. Der alleinige Einsatz von PQC anstelle von RSA & Co wird nicht erwähnt.

Die Technische Richtlinie 02102 hat zunächst lediglich Empfehlungscharakter, wird jedoch häufig von anderen Richtlinien herangezogen und entfaltet in deren Geltungsbereich auch quasi-normativen Charakter. Das BSI nennt hier die Verarbeitung von Verschlusssachen, aber auch die TR-03161 verpflichtet Anwendungen im Gesundheitswesen zur Beachtung von TR-02102.

Plattner: Setzen neue Maßstäbe

BSI-Präsidentin Plattner sieht den Schritt als großen Wurf: „Mit der Abkündigung der klassischen Verschlüsselungsverfahren setzen wir neue Maßstäbe“. Die Migration auf PQC sei „alternativlos“, sagt die Amtsleiterin weiter. Doch prescht das Bundesamt nicht im Alleingang vor – die EU-Kommission hat einen unionsweiten Zeitplan für die Umstellung auf quantensichere Verschlüsselung.

Die TR-02102 besteht aus vier Teilen, die von grundlegenden Empfehlungen über Transport Layer Security (TLS), den Protokollen IPsec und IKEv2 bis hin zu einer Handreichung zum Einsatz von SSH reichen. Die Aktualisierung erstreckt sich auf alle Teilbereiche – so ergibt sich aus der Empfehlung hybrider Verfahren auch eine Abkündigung von TLS 1.2, das derlei nicht unterstützt.

Beim Übergang zu quantensicherer Verschlüsselung unterstützt das Unternehmen mit weiteren Leitfäden und Handlungsempfehlungen, die es auf einer Themenseite gesammelt bereitstellt.

(cku)