Wann ist Information "zu viel Information"?

Joao Correia

April 14, 2023 - Technischer Evangelist

Ansichten posten: 7

Sie haben den Trend sicherlich bemerkt - er ist kaum zu übersehen, wenn Sie aufmerksam sind. Die Changelogs werden immer spärlicher, vor allem im letzten Jahr oder so. Manchmal ist ein einfaches "Bugs behoben" oder "Leistungsverbesserungen" alles, was angeboten wird, um zu beschreiben, was genau zwischen den Versionen getan wurde. Es gibt einige ziemlich überzeugende Gründe für diese Veränderung, aber auch einige ebenso interessante Gegenargumente.

Vorbei sind die Zeiten, in denen man mehr Textabsätze zur Beschreibung einer Codeänderung hatte als Codezeilen für diese Änderung. Changelogs waren fesselnde Textstücke, die mit einer Schreibkunst verfasst waren, die einige literarische Autoren ihre Berufswahl überdenken ließ. Glückliche Tage.

Aber diese Zeiten sind nun vorbei. In einem beliebigen Änderungsprotokoll für Windows-Updates muss man schon sehr tief graben, um herauszufinden, was genau der Fehler war, der eine Korrektur erforderte, und was getan wurde, um das Problem zu lösen. Als dies vor einigen Jahren in Kraft trat, gab es eine beträchtliche (sehr lautstarke) Gegenreaktion, aber Microsoft ließ sich nicht beirren, und die Richtlinie ist bis heute in Kraft - sowohl für Verbraucher als auch für professionelle Produkte.

Man könnte meinen, dass dies einfach Microsoft ist, wie Microsoft eben ist, und dass dies zum Standardrepertoire der "großen Unternehmen" gehört. Aber ein Blick über den Tellerrand, zum Beispiel auf den Linux-Kernel, zeigt, dass dort das Gleiche passiert. Sicher, man kann all die Diskussionen, Kommentare und Threads in verschiedenen Foren über Fehler, Schwachstellen und neue Funktionen für den Kernel verfolgen, aber wenn man sich das Änderungsprotokoll selbst ansieht, wird es schwierig sein, spezifische Sicherheitskorrekturen in einer bestimmten Version zu identifizieren.

Sicherheit durch Unklarheit hält in der Regel nicht sehr lange an, aber es ist ein schmaler Grat, den die Entwickler hier beschreiten.

Die Sicherheitsprobleme

Befürworter einer Reduzierung der Informationsmenge in Änderungsprotokollen argumentieren oft, dass sie (in keiner bestimmten Reihenfolge):

Verringerung der Informationen, die böswilligen Akteuren zur Verfügung stehen, um neue Schwachstellen in älteren, bereits installierten (und damit anfälligen) Versionen zu erkennen;
Den "Guten" bleibt nur wenig Zeit, ihre Systeme zu patchen, bevor Hacker versuchen, in sie einzudringen, denn die Zeit zwischen der Veröffentlichung einer Sicherheitslücke und dem Auftauchen von Exploits "in the wild" verkürzt sich auf wenige Minuten;
Er behauptet, dass die Benutzer nicht über all die winzigen Details Bescheid wissen müssen, da sie so schnell wie möglich die neueste Version verwenden sollten; es gehört zum Einmaleins der Cybersicherheit, immer zu patchen.

Allerdings gibt es ebenso überzeugende Argumente auf der anderen Seite:

Bösewichte verfügen über die Ressourcen, das Know-how und den Anreiz, die tatsächlichen Codeunterschiede zwischen den Versionen zu vergleichen, und brauchen die Änderungsprotokolle nicht wirklich. Erschwerend kommt hinzu, dass KI-Bots jetzt bei dieser Aufgabe helfen können, was den erforderlichen Wissensstand trivialisiert.
Das Verschweigen dieser Details erschwert oder macht es sogar unmöglich, Prioritäten für die Flickarbeiten zu setzen, da keine vergleichbare Risikomessung zur Verfügung steht.
Jedes Mal die neueste Version zu nehmen, ist nicht immer völlig sicher, denn kein Patch hat jemals unbeabsichtigte Folgen verursacht, richtig?

Diskussionen darüber können sehr schnell hitzig werden, und es ist leicht, das Thema zu verfehlen und in "Ich weiß es am besten"-Argumente zu verfallen, die letztendlich unproduktiv sind. Diese Debatten machen jedoch ein Problem deutlich, das spürbare Auswirkungen auf die Sicherheit hat. Es ist unbestreitbar richtig, dass Sie Ihre Systeme immer mit der aktuellsten Version der darauf befindlichen Software betreiben sollten. Aber häufige Ereignisse wie der Verlust der Hardwareunterstützung oder Änderungen des Umfangs, der Anforderungen oder der Verfügbarkeit können dies unmöglich machen. In diesem Fall ist der Mangel an Informationen eher hinderlich als hilfreich, da Sie keine Möglichkeit haben, eine neue Schwachstelle zu erkennen, der Sie nun ausgesetzt sind - bis etwas Schlimmes passiert.

Sicherheitsprobleme nicht explizit als solche zu kennzeichnen, bedeutet auch, dass Sie kein CVE für das Problem beantragen (oder die Beantragung verzögern) werden. In einem Bereich wie der Cybersicherheit, der sich fast ausschließlich auf das Verfolgen, Verwalten, Scannen und Patchen von CVEs konzentriert, ist es gelinde gesagt fragwürdig, Sicherheitsprobleme zu haben, die alle Werkzeuge und Überwachungen umgehen.

Wo wir hinwollen

Es könnte eine Zeit kommen, in der Changelogs tatsächlich wertlos werden.

Bei den Windows Server Insider-Builds gibt es noch nicht einmal eine - und die Ironie dabei ist, dass Sie eine Betaversion ausführen, die kostenlos getestet wird, und dennoch keine Möglichkeit haben zu erfahren, was Sie eigentlich testen sollen. Dies könnte eher die Regel als die Ausnahme werden. Die Versionen der Verbraucher-Betriebssysteme bieten keinen einfachen Zugang mehr zu den Patch-Beschreibungen, die jetzt nur noch einen allgemeinen Hinweis auf behobene Fehler enthalten. Man muss schon tiefer graben, um mehr Details zu finden, und selbst das wird allmählich für ein kleineres Publikum zugänglich.

Auch hier ist es wichtig zu betonen, dass dies nicht nur etwas ist, das mit Closed-Source-Software zu tun hat. Auch in der Open-Source-Welt wird dieser Ansatz als gültig erachtet. In der Tat schafft dies eine besondere Situation für Open-Source-Projekte. Auf der einen Seite gibt es frei verfügbaren Quellcode, Fehlerberichte und den Wunsch, den Entwicklern einen Anreiz zu geben, an der Behebung von Fehlern und der Erweiterung von Funktionen zu arbeiten. Aber auf der anderen Seite verbergen Sie absichtlich Informationen, die bei diesen Aufgaben helfen würden. Irgendetwas passt hier nicht zusammen.

Es gibt eine sehr lange Liste von Argumenten zu dieser Debatte, die Sie in diesem Thread finden können Threadzu finden ist, in dem einige Kernel-Führer die Vorzüge des von ihnen gewählten Ansatzes zu diesem Thema erörtern - ebenso wie die umfangreiche Kritik, die damit einhergeht.

Die Auswirkungen von AI

KI entwickelt sich rasant weiter, und es ist schwer, mit all den neuen Funktionen Schritt zu halten. Ein bewährtes Merkmal der aktuellen KI-Bots ist jedoch ihre Fähigkeit, Ihnen beim Verstehen und Finden von Problemen im Code zu helfen. Es ist trivial, einen Vorher-Nachher-Codeblock in die Chat-Schnittstelle eines KI-Bots einzufügen und ihn aufzufordern, "die Fehler zu finden, die mit diesen Codeänderungen behoben wurden" und "wie diese Fehler ausgenutzt werden könnten".

Open-Source-Software wird diese Auswirkung viel schneller zu spüren bekommen als Closed-Source-Software, da die Zugänglichkeit in dieser Hinsicht gegen sie arbeiten wird. Die Prüfung von Unterschieden zwischen verschiedenen Softwareversionen zur Ermittlung von Sicherheitslücken war bereits etwas, mit dem sich Bedrohungsakteure befasst haben, und die Messlatte wurde nun erheblich niedriger gelegt. Aber es reicht immer noch nicht aus, dass die guten Jungs die Verfügbarkeit und die Ressourcen haben, um dies selbst zu tun - sie haben auch noch andere Sorgen, als sich nur auf das Finden und Ausnutzen von Fehlern zu konzentrieren.

Die "Unklarheit" in der "Sicherheit durch Unklarheit" wird bald ziemlich gut ausgeleuchtet werden.

Magische Kugeln oder das Fehlen solcher Kugeln

Es gibt kein Patentrezept für dieses Problem. Bislang hat es sich als unlösbar erwiesen, und es ist unglaublich, dass jeder glaubt, sein eigener Ansatz sei der beste - und deshalb macht er es auch auf diese Weise. Das kann so extrem sein wie drei verschiedene Softwareanwendungen auf einem System, die alle unterschiedliche Ansätze haben - das Betriebssystem, der Webserver und die Datenbank. Letzten Endes zahlt jemand den Preis für diesen uneinheitlichen Ansatz der Informationsweitergabe (oder des Verbergens), und es stellt eine weitere Hürde dar, die IT-Fachleute überwinden müssen, um ihre Arbeit effektiv zu erledigen.

Letztendlich ist die Debatte über Changelogs und die Menge der darin geteilten Informationen komplex und vielschichtig. Da sich Technologie und KI weiter entwickeln, muss die Branche möglicherweise ihren Ansatz für Sicherheit und Informationsaustausch neu bewerten, um ein Gleichgewicht zwischen Transparenz und Schutz zu finden.