Schlimmer geht immer …

Der Solarwinds Hack war ein sehr großer Incident und bis heute habe ich das Gefühl, wesentliche Informationen wurden nicht offengelegt.

Klar – man kann immer den Joker ziehen, dass Details zu einem Sicherheitsvorfall für Angreifer von Interesse sein können, um weitere Angriffe durchzuführen. Also hält man sich als Unternehmen „bedeckt“.

Nun hat der amerikanische, demokratische Senator Ron Wyden einen Brief geschrieben.
(https://www.wyden.senate.gov/news/press-releases/wyden-requests-federal-agencies-investigate-lax-cybersecurity-practices-by-microsoft-that-reportedly-enabled-chinese-espionage)

Hintergrund ist der aktuelle Fall bei dem ein „Sicherheitsschlüssel“ von Microsoft eine wesentliche Rolle spielt.

This is not the first espionage operation in which a foreign government hacked the emails of United States government agencies by stealing encryption keys and forging Microsoft credentials. The Russian hackers behind the 2020 SolarWinds hacking campaign used a similar technique, with a noteworthy difference.

Also – beim Solarwinds Hack ging es auch um einen Sicherheitsschlüssel? Das hatte ich so nicht auf dem Schirm.

Nun ja – irgendwie fehlt dann doch die Zeit, um sich wirklich jedes noch so kleine Detail eines Angriffes anzuschauen.

Und vielleicht wurde diese Information bisher noch gar nicht veröffentlicht?

Wie gehe ich nun als CISO damit um?

Solarwinds ist Geschichte, aber jetzt hat der Angriff eine ganz andere Qualität.

Es sind nicht mehr die schlampigen Administratoren, die Ihre „OnPrem“ Systeme nicht im Griff haben.

Der Angriff geschieht in der Hochsicherheitszone von Microsoft – direkt in der Cloud.

In der „Zero Trust“ geschützten Umgebung, die ein wichtiges Argument für eine Cloudmigration ist.

Alle Kritiker werden sich freuen.

Tatsächlich ist das Grundprinzip selbst das Problem – die Arbeit mit kryptografischen Schlüsseln, um Sicherheit und Vertraulichkeit zu erzeugen.

Eigentlich eine digitale Schließanlage bei der es einen Zentralschlüssel gibt.
(https://de.wikipedia.org/wiki/Schlie%C3%9Fanlage)

Jeder Hausbewohner hat seinen individuellen Türschlüssel und damit komme ich nicht in eine fremde Wohnung rein.

Der Hausmeister aber hat den „Master-Key“ und öffnet damit jede Tür.

Es stellt sich die Frage, wie man so einen Schlüssel richtig schützt.

Am Ende wird man erkennen müssen – es gibt keinen 100% zuverlässigen Weg, das zu erreichen.

Somit habe ich ein Risko identifiziert: „Jemand bekommt Zugang zum Zentralschlüssel“.

Dieses Risko werde ich in vielen digitalen Sicherheitssystem wiederfinden.

Über die „Eintrittswahrscheinlichkeit„, dass jemand so einen Schlüssel bekommt, muss ich nicht lange nachdenken – die ist relativ hoch, wie die Beispiele aus der Vergangenheit zeigen.

Das „Schadensausmass“ – kann gigantisch sein. Oder „existentiell“!

Ein Risiko kann reduziert werden indem Maßnahmen getroffen werden, um das Schadensausmass und/oder die Eintrittswahrscheinlichkeit zu reduzieren. Im Kontext von Risiken wird auch von «mitigieren» gesprochen.

Andere Möglichkeiten in der Praxis wären:

• Verhindern: Sie versuchen durch geeignete Maßnahmen, die Ursachen für das Risiko in den Griff zu bekommen. Sie wollen im Vorfeld sicherstellen, dass es erst gar nicht zu Problemen kommt.
• Akzeptieren: Sie entscheiden sich, das Risiko zu akzeptieren. Sie verzichten auf mögliche Maßnahmen, um das Risiko zu vermeiden – und sind bereit, den Schaden zu akzeptieren, falls es doch passiert.
• Übertragen: Sie wälzen das Risiko auf einen Dritten ab. Zum Beispiel übertragen Sie das Risiko per Vertrag an einen Lieferanten, der für etwaige Folgen aufkommt.

Je länger ich darüber nachdenke – wahrscheinlich müsste ich das Risiko schlicht akzeptieren?
Was soll ich sonst tun, um den Schlüssel bei Microsoft besser zu schützen?

Verhindern kann man das offensichtlich auch nicht und kaum jemand wird mich gegen einen solchen Schaden versichern?

Formal könnte das aber schwierig werden, da ich Risiken nur unterhalb der Risikoakzeptanzschwelle akzeptieren kann.

Alle höheren Risiken müssen „behandelt“ also vermieden, verringert oder übertragen werden.

Ein Cloud-Gegner hat jetzt die richtige Lösung zur Hand – gar nicht in die Cloud gehen.

Wie ich aber schon zuvor geschrieben hatte – das Risiko ist nicht „Cloud only“. Es ist eher grundsätzlich.

Aaaaaaarghl – ich liebe das Risikomanagement.

Doch die Lösung liegt auf der Hand – es darf einfach keinen Zentralschlüssel geben!

Jede Kundenumgebung hat einen eigenen, individuellen Schlüssel. Dieser muss so sicher wie möglich untergebracht sein.

Eventuell geschützt durch andere, individuelle Schlüssel, die nur als Paar den Zugang erlauben.

Alle Informationen müssen konsequent und durchgängig damit verschlüsselt werden.

Damit sind lange nicht alle Probleme gelöst und es bleiben eine große Menge offener Fragen und Probleme.

Aber – kein Microsoft hat dann einen Zentralschlüssel, mit dem man auf andere Kunden zugreifen kann.

Tatsächlich sehe ich am Ende meines Beitrages noch viel zu viele Fragezeichen und ich bin nicht mit dem Ergebnis zufrieden.

Bezogen auf den aktuellen Fall habe ich zumindest seit gestern ein neues Risiko in meiner Liste und dazu gleich einen Incident.

Ich werde jetzt versuchen zu klären, ob mein Unternehmen angegriffen wurde oder nicht.

Vielleicht ein nicht erreichbares Ziel – aber ein Ticket dazu bei Microsoft kann man ja schon einmal aufmachen.

Und vielleicht – wenn ganz viele CISO’s ein Ticket zu dem Thema aufmachen und fragen, wie sie sicherstellen nicht angegriffen worden zu sein, vielleicht denkt Microsoft darüber nach etwas zu ändern?

Es sollte jedem klar sein, dass es durchaus möglich ist, dass dein Unternehmen mit dem Zentralschlüssel geöffnet wurde und jemand eine Hintertür eingebaut hat.

Wenn du einen Weg gefunden hast, das komplett auszuschließen – ich freue mich auf deine Mail an .