Sorry für die Verwendung eines vulgären Wortes – es gehört tatsächlich u.a. zu einem Werk von Merle von Heyer.
Der Kontext passt zwar nicht, aber ich finde den Titel dennoch passend für mein heutiges Thema.
Als ich im November 2020 mit meinem Blog angefangen habe, wollte ich ein klein wenig dazu beitragen die IT-Welt sicherer zu machen.
- SolarWinds Orion (20.12.2020)
- Nach Sunburst kommt Supernova (22.12.2020)
- “ungewöhnliche Aktivitäten” bei Microsoft (02.01.2021)
- Ubiquiti warnt vor “security breach” (12.01.2021)
- Apple = Linux = Kritische sudo-Lücke (04.02.2021)
- Florida water system hack (09.02.2021)
- Solarwinds – Centreon – was kommt da noch? (18.02.2021)
- Wenn’s nicht mehr pumpt… (11.05.2021)
- …
Lassen wir es bei einem Auszug der Themen, über die ich schon berichtet habe.
Welche davon hast du noch im Blick?
Vermutlich nicht eines der oben aufgeführten Themen dürften uns aktuell noch beschäftigen.
Das zeigt sich auch, wenn man in einer Suchmaschine danach sucht.
In kaum einem der Fälle finde ich noch Hinweise auf das „was geschah danach?“ oder die Frage „was hat man daraus gelernt?“
Und das finde ich schade – darum soll es in diesem Beitrag gehen.
Das Informationssicherheits- Management nach ISO 27001 zeichnet sich durch eine essenzielle Funktion aus – das Demin Rad (https://de.wikipedia.org/wiki/Demingkreis).
Plan – Do – Check -Act und das in einer endlosen Wiederholung.
Zum Thema „kontinuierliche Verbesserung“ gibt es zwischenzeitlich viele Kommentare und Blickwinkel.
Als ich irgendwann gegen Ende der 1980’er Jahre „Kaizen“ (https://de.wikipedia.org/wiki/Kaizen) kennen lernte, faszinierte mich der Ansatz, immer wieder zu lernen, um sich zu verbessern.
Daniel Lock nennt die 4 Prinzipien der kontinuierlichen Verbesserungen auf seiner Webseite:
(https://daniellock.com/4-principles-of-continuous-improvement/)
- Grundsatz 1: Hör auf zu reparieren und fang an zu verbessern
- Grundsatz 2: Die besten Praktiken sind die, die man bereits hat
- Grundsatz 3: Verhaltensänderungen sind wichtiger als Prozessänderungen
- Grundsatz 4: Wenn du nicht versagst, hast du es nicht versucht
Wir leben in einer sehr schnellen Zeit die besonders mit Blick auf Angriffe gegen die Informationssicherheit durch eine permanente Informationsüberflutung aber auch einer extrem hohen „Flüchtigkeit“ geprägt ist.
Was heute noch als ein riesiges Thema in den Medien „gehyped“ wird, gerät sehr schnell in Vergessenheit und wird durch andere Themen überlagert.
Ein aktuelles Beispiel gefällig?
Wie hat sich dein Blick auf den Ukraine Krieg geändert, seitdem er begonnen hat?
Heute sprechen wir weniger über das Leid der Menschen und zählen dafür Panzer?
Unsere „Wahrnehmung“ wird sehr oft von den Informationen bestimmt, die wir erhalten.
Nun stellt sich die Frage, wie wir besser mit Informationssicherheitsvorfällen umgehen könnten.
Dafür sollten wir klären, worin sich ein „-Ereignis“ von einem „-Vorfall“ unterscheidet:
Informationssicherheitsereignis
Ein Ereignis – ein System, Dienste oder Netzwerk betreffend – welches ein mögliches Indiz für das Fehlschlagen einer Informationssicherheitsmaßnahme oder eine Bedrohung der Informationssicherheit darstellt.Informationssicherheitsvorfall
Ein Satz von einem oder mehreren Ereignissen, die mit erheblicher Wahrscheinlichkeit die Informationssicherheit unmittelbar bedrohen.
Log4J zum Beispiel war zunächst ein Ereignis, welches ich als CISO wahrnehme. Ein Vorfall war es für mein Unternehmen konkret nicht, weil wir kein Log4J einsetzen.
Jetzt könnte ich sagen – das war ein Ereignis ohne Auswirkung also schließe ich den Fall ab.
Richtig aber wäre zu prüfen, ob diese grundsätzliche Schwachstelle als Risiko vielleicht mit anderen Vorzeichen zu einer konkreten Bedrohung und damit zu einem Vorfall werden könnte.
Wir arbeiten sehr viel mit Microsoft Produkten und auch dort gibt es „Bibliotheken“, die man einsetzt.
PowerShell z.B. ist so eine Umgebung. Dort fallen mir spontan die „Module“ ein:
Ein Modul ist ein Paket, das PowerShell-Member wie Cmdlets, Anbieter, Funktionen, Workflows, Variablen und Aliase enthält. Die Member dieses Pakets können in einem PowerShell-Skript, einer kompilierten DLL oder einer Kombination aus beiden implementiert werden. Diese Dateien werden in der Regel in einem einzelnen Verzeichnis gruppiert.
(https://learn.microsoft.com/de-de/powershell/module/microsoft.powershell.core/about/about_modules?view=powershell-7.3)
Ich verstehe das so – nutze ich ein Powershell Modul dann beinhaltet dieses u.a. auch „Scripte“ die bestimmte Abläufe zusammenfassen.
Also habe ich ein sehr konkretes Risiko nur eben nicht durch Log4J sondern weil ich mir leicht eine Schwachstelle einfangen kann, nur weil ich mir ein Modul zur Verwaltung der Azure Umgebung installiere.
Das ist ein Vorgang, der jeden Tag sicher sehr oft durchgeführt wird.
Somit habe ich schon ein konkretes Risiko identifiziert, welches ich gleich auch im „Risk-Log“ aufnehmen und weiterbearbeiten kann.
Wir lernen daraus – allgemeine Sicherheitsereignisse müssen uns nicht direkt betreffen können aber ein Hinweis auf ein anderes, konkreteres Risiko sein.
Ein CISO muss so etwas im Auge behalten und beurteilen können.
Ein anderes Beispiel – gerade gestern noch habe ich ein Informationssicherheitsereignis im eigenen Unternehmen behandelt.
Ursache war eine Meldung aus der Microsoft Cloud zu „Microsoft 365 Defender has detected a security threat“.
Ein Klassiker: User schließt USB-Device an um Musik zu hören. Auf dem Device ist ein ‚Perlovga‘ Wurm gespeichert.
Wie würdest du das nun einstufen?
Ich denke es ist ein Ereignis, weil in diesem Fall der Virenschutz gegriffen hat.
Dennoch habe ich den Fall zu einem -Vorfall hochgestuft und weiter untersucht.
Warum? Weil wir hier einfach nur Glück gehabt haben, dass der Wurm erkannt wurde.
Was wäre bei einer noch unbekannten Malware geschehen?
Also muss ich mir jetzt überlegen, wie ich durch entsprechende technische oder organisatorische Richtlinien das Risiko weiter minimieren kann.
Bevor sich bei dir nun die Frage stellt, warum dieses Risiko (externe USB Devices) nicht schon längst blockiert wurde – auf der einen Seite benutzen wir die eigentlich gar nicht (Datenaustausch über Cloud) und wenn, dann brauchen das oft die Consultants für die Arbeit.
Wir lernen daraus – als CISO brauche ich auch regelmäßige Informationen zu jedem „-Ereignis“, selbst wenn es vielleicht für die IT nicht kritisch ausgesehen hat.
Viele Ereignisse sind Warnzeichen auf bestehende Risiken, die ich nur erkennen kann, wenn ich auch eine Information darüber bekomme.
Es hilft mir wenig, wenn die IT-Abteilung das Ereignis einfach abschließt ohne die Information auch zu dokumentieren und weiterzuleiten.
Bezogen auf das Thema dieses Beitrages sollten wir daran denken, dass es viele Informationssicherheitsereignisse geben wird, die uns direkt nicht betreffen. Schnell werden diese wieder in der medialen „Versenkung“ verschwinden.
Unsere Aufgabe ist es aber zu prüfen, ob wir ähnliche Konstellationen finden können, bei denen wir selbst zum Opfer werden könnten.
Glaube mir – es gibt sehr viel mehr als wir im ersten Moment so denken.
Wir werden nie alle Risiken in den Griff bekommen.
Wenn wir aber die Information bekommen, dass es einen anderen „erwischt“ hat, dann können wir das immer auch nutzen um uns selbst zu prüfen.
Ganz im Sinne der „kontinuierlichen Verbesserung“ und des „ewigen Lernens“.