Erkenntnisse aus Log4j: Überstürzen Sie die Sanierung nicht

Die meisten von uns sind Menschen und haben schon einmal das erlebt, was man im Allgemeinen als „ Kampf oder Flucht “ bezeichnet – eine oft heftige autonome körperliche Reaktion, die sich in Herzrasen, angespannten Muskeln und schwitzigen Handflächen äußert. Die Reaktion kann von Panikgefühlen und einer Entscheidungslähmung begleitet sein, die unsere Fähigkeit zum logischen Denken praktisch aufhebt.

Die Wirtschaft verfügt über eine eigene Version dieser Reaktion, die sie im Laufe der Jahre ihrer Reaktion auf bedrohliche digitale Situationen entwickelt und verfeinert hat.

Das Risiko für Unternehmen ist dem Risiko für Menschen ähnlich. Eine zu häufige, zu intensive oder unangemessene Aktivierung der Kampf-oder-Flucht-Reaktion kann beim Menschen zu einer Reihe von klinischen Zuständen führen. Das ist eine Kurzform dafür, dass sie echten körperlichen Schaden anrichten können. Auf der Geschäftsseite kann die häufige, intensive oder möglicherweise unangemessene Aktivierung einer digitalen Kampf-oder-Flucht-Reaktion schädlich für die Geschäftsentwicklung sein – insbesondere im Bereich der Sicherheit.

Ähnlich den bekannten „Phasen der Trauer“ haben wir im Laufe unserer jahrzehntelangen Arbeit an der Eindämmung application und infrastrukturbezogener Bedrohungen die Entstehung von „Phasen der Sicherheitsreaktion“ beobachtet.  

Die Bedeutung der richtigen Antwort

Überstürzte Abhilfemaßnahmen können auf lange Sicht nicht die beste Lösung sein. Bedenken Sie, dass der erste veröffentlichte Patch für Log4j von Apache ebenfalls anfällig war, sodass Unternehmen, die sich überstürzt um die Behebung des Problems bemühten, im Grunde von vorne beginnen und alle ihre Systeme erneut patchen mussten.

An diesem Punkt möchte ich innehalten und nachdrücklich betonen, dass die Vermeidung überstürzter Sanierungsmaßnahmen nicht bedeutet, die Risiken zu ignorieren oder sich lieber zurückzuhalten.

Dies muss besonders beachtet werden, da ein verantwortungsvoller Umgang mit den Daten, die ein digitales Unternehmen antreiben, reale Konsequenzen haben kann. Im Zuge des Log4j-Vorfalls warnte die US-Handelskommission (FTC), sie werde „gegen Privatunternehmen vorgehen, die die durch Log4j offengelegten Verbraucherdaten nicht schützen.“ ( ZDNet )

Warum Schadensbegrenzung an erster Stelle steht

Aus einem bestimmten Grund hat die Schadensbegrenzung Vorrang vor der Sanierung. Nicht zuletzt, um dem menschlichen Instinkt gerecht zu werden, „etwas zu tun“ und schnell Abhilfe zu schaffen. Durch eine schnelle Schadensbegrenzung wird auch die Notwendigkeit berücksichtigt, verantwortungsvoll mit Kundendaten umzugehen, indem diese vor dem Abfluss geschützt werden und gleichzeitig der richtige Maßnahmenplan zur Behebung der Probleme formuliert wird.  

Die Schadensbegrenzung sollte die erste Maßnahme sein, insbesondere wenn es sich um eine so weit verbreitete Sicherheitslücke handelt, die eine eingehende Untersuchung der Software-Lieferkette erfordert. Die Allgegenwärtigkeit und die Schwierigkeit, herauszufinden, wo sich anfällige Pakete und Komponenten verstecken könnten, sind wahrscheinlich der Grund für die Feststellung, dass am 4. Januar „die Anzahl der Downloads mit Sicherheitslücken für #log4shell insgesamt immer noch 46 % betrug“. ( Sonatyp )

Die Realität einer standardmäßig digitalisierten Welt besteht darin, dass neue und traumatische Sicherheitslücken auch weiterhin zu Geschäftsunterbrechungen führen und bereits überlastete Ressourcen belasten werden. Aufgrund der Robustheit eines Application – das sich häufig über fünf Generationen von Application erstreckt, die auf Kern, Cloud und Edge verteilt sind – sollten wir davon ausgehen, dass die Behebung des Problems den größten Teil an Zeit und Energie in Anspruch nehmen wird. Deshalb ist eine schnelle Schadensbegrenzung so wichtig. Dies verringert den Druck und ermöglicht einen gezielteren und umfassenderen Ansatz zur Behebung der Probleme. Dabei wird unter anderem geprüft, ob veröffentlichte Patches sicher sind, und Entwickler können entsprechend den vorhandenen Veröffentlichungszyklen aktualisieren, patchen und testen.

Organisationen sollten sicherstellen, dass sie in allen Umgebungen über Kontrollpunkte verfügen, die die Risikominderung unterstützen. Web- und API-Schutz, Inhaltsprüfung und Blockierungsfunktionen an strategischen Kontrollpunkten bieten eine Art „Plattform“ zur Schadensbegrenzung bei derartigen weit verbreiteten Sicherheitslücken. Diese Kontrollpunkte können auch wertvolle Informationen liefern, indem sie Versuche aufdecken, solche Schwachstellen auszunutzen.  

Abschluss

Die meisten von uns erinnern sich noch an die Feuerübungen in ihrer Kindheit, bei denen wir trainierten, wie wir im Brandfall die Schule sicher verlassen. Ich habe auch Tornado-Übungen gemacht und ich vermute, dass es auf der ganzen Welt Kinder gibt, die Vorbereitungen für Erdbeben oder Tsunamis geübt haben. Einen Plan zu haben und zu wissen, wie man ihn umsetzt, kann entscheidend dazu beitragen, die Zeit, die man in Panik verbringt, wenn die Nachricht von einer schwerwiegenden Sicherheitslücke die Runde macht, zu verkürzen.

Also keine Panik. Nutzen Sie strategische Kontrollpunkte und konzentrieren Sie sich auf eine schnelle Schadensbegrenzung , damit Sie gezielte Abhilfemaßnahmen durchführen können.

Und denken Sie daran: Übung reduziert die Panik . Es ist überhaupt keine schlechte Idee, eine eigene „Sicherheits-Feuerwehrübung“ zu planen und durchzuführen.