In der Informationssicherheit sollen die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit für die verarbeiteten Daten erhalten werden. (Digitale) Daten sollen also immer verfügbar, vollständig und unverändert nur den jeweils berechtigten Personen zugänglich sein.
Gleichzeitig nimmt für die Verarbeitung dieser Daten in der IT die Menge der beteiligten Systeme und deren Vernetzung stetig zu, so dass die Komplexität eines Gesamtsystems steigt, welches eine bestimmte Funktionalität erbringt. Diese Tendenz hat sich während des letzten Corona-Jahres weiter beschleunigt und läuft dem KISS-Prinzip in der IT und auch der Informationssicherheit zuwider: „Keep it simple [and] stupid“. In diesem Artikel wird kurz skizziert, an welchen Stellen Komplexität „lauert“, und das nicht nur in fernen Rechenzentren. Doch warum ist Komplexität problematisch? Kurz und vereinfacht gesagt ist Komplexität gefährlich für die Informationssicherheit in IT-Systemen, weil ein böswilliger Angreifer nur eine Schwachstelle im kombinierten Gesamtsystem finden muss, um Daten zumindest lesen, aber meist auch verändern zu können. In der Praxis werden für einen erfolgreichen Angriff allerdings oft mehrere Schwachstellen kombiniert ausgenutzt, weil in den IT-Systemen Schutzmechanismen eingebaut sind. Diese Schutzmechanismen erhöhen jedoch wiederum die Komplexität des Gesamtsystems – hierbei wird ein Wettrüsten bzw. ein Teufelskreis erkennbar.
Die Komplexität von IT-Systemen hat natürlich viele technische Aspekte, wie etwa eine Redundanz in Rechenleistung, Speicherung und Datentransfer (um Integrität und Verfügbarkeit zu gewährleisten). Die in der Interaktion für die Anwender*innen sichtbaren Apps bzw. Anwendungen sind zudem aus diversen Software-Komponenten aufgebaut (z. B. Bibliotheken, Micro-Services, Cloud-Umgebungen), die zum Beispiel je nach Betriebssystemumgebung anders kom- poniert werden oder andere Software-Komponenten als Basis benötigen. Jede dieser Software-Komponenten hat einen eigenen Lebenszyklus: Bestimmte Versionen können Sicherheitslücken enthalten oder werden nicht mehr weiterent- wickelt, was die Sicherheit der App beeinträchtigen kann. Entsprechend müssen Aktualisierungen von Software-Komponenten vorgenommen werden, die bei nicht selten hunderten solcher Abhängigkeiten in aktuellen Apps viel Zeit und Aufmerksamkeit erfordern. Der Betrieb einer App im weiter gefassten Sinn wird oftmals, wie auch am CMS, durch verschiedene Dienstleister*innen im Zusammenspiel ermöglicht: Dienstleister*in A mag sich aus verschiedenen Gründen nur um seine, von ihm entwickelte App a kümmern und nutzt daher einen Dienstleister*in B, der eine virtuelle Maschine b mit einem Linux-Betriebssystem anbietet, wobei er auf Dienstleister*in C zurückgreift, der ein Rechenzentrum bzw. Cloud-Dienst c betreibt, in dem Hardware diese virtuelle Maschine b betriebsbereit werden lässt. Über Dienstleisterbeziehungen zwischen A – C müssen entsprechend Aktualisierungen koordiniert werden, was diesen organisatorischen Aspekt der Komplexität zusätzlich erhöht. Mit einer solchen Komplexität sind selbst große Firmen zuweilen überfordert, wie der Ausfall der Dienste Facebook, Instagram u.a. des Unternehmens Meta Anfang Oktober 2021 gezeigt hat. Dabei kam es durch eine Fehlkonfiguration zu einer Kettenreaktion, die zum Ausfall führte. Erkennung und Behebung wiederum wurden ebenfalls durch Komplexität behindert – diesmal durch die bereits erwähnte Komplexität notwendiger Schutzmechanismen. Die Schutzmechanismen selbst sind nicht problematisch gewesen, jedoch ihr Zusammenwirken mit der Notfallsituation.
Während des Schreibens dieses Artikels ist Mitte Dezember quasi als Paradebeispiel der vorherigen Ausführungen die bedeutende Sicherheitslücke „log4shell“ (CVE-2021-44228 u. a.) bekannt geworden. Sie wurde vom BSI mit der höchsten Stufe Rot der IT-Bedrohungslage bewertet. Andere Einstufungssysteme vergaben ebenfalls die höchstmöglichen Bedrohungsbewertungen (CVSS 10.0), weil diese Lücke trivial über das Internet ausnutzbar ist, die Ausführung beliebiger Anweisungen (in Form von Programmcode) auf anfälligen IT-Systemen ermöglicht und insbesondere die von der Sicherheitslücke betroffene Softwarekomponente log4j in unzähligen Produkten genutzt wird. Das Identifizieren betroffener Softwareprodukte ist sehr schwierig, weil log4j oftmals tief verschachtelt und dadurch versteckt eingebaut ist. Es gelingt typischerweise nur mit bereitgestellten Informationen des jeweiligen Herstellers. Zur letztendlichen Abdichtung der Schwachstelle in den Produkten müssen die dort enthaltenen log4j-Pakete aktualisiert werden. Typischerweise müssen die Hersteller dazu Patches liefern oder alternativ behelfsweise Anleitungen für eine abgesicherte Konfiguration liefern.
Unzählige Administrator*innen und Entwickler*innen arbeiteten weltweit an der Beseitigung von log4shell. Doch auch Anwender*innen sind durch stetig bereitgestellte Updates ihrer genutzten Software in der Verantwortung, diese auch zeitnah auf selbst verantworteten IT-Geräten einzuspielen. Denn log4shell hat einmal mehr gezeigt, dass die Informationssicherheit eines Gesamtsystems durch das schwächste Teilsystem bestimmt ist.