Was haben wir gelernt?
Log4J
Von vielen wird Log4Shell als bisher kritischste Vulnerability überhaupt angesehen, denn anders als z.B. WannaCry / EternalBlue waren auch aktuell gepatchte und Linux-Systeme betroffen und die Lücke war kinderleicht auszunutzen. Entsprechend hat sich die Log4J-Schwachstellte auch den bisher einmaligen CVSS Score von 10 verdient.
Aber was haben wir daraus gelernt? Nun, die Software Entwickler sicher eine ganze Menge. Vom Library Management bis zur Unterstützung von Open Source Software gehen die Vorschläge. Aber die Software Entwicklung ist nicht unser primäres Thema, sondern das Operations. Man kann – nein: man MUSS davon ausgehen, dass Zero Day Exploits auch zukünftig auftauchen werden, und das nicht nur in hauseigenen Entwicklungen, sondern vor allem auch in zugekauften Lösungen, wo man über enthaltende Bibliotheken keine Infos hat. Was also können die Betriebs- und Sicherheitsverantwortlichen tun, um optimal vorbereitet zu sein?
Vom Schaden anderer profitieren
Man kann zum Beispiel ausnutzen, dass man vermutlich nicht der erste ist, den es trifft und man vor der Schwachstelle in einem CVE Feed gewarnt wird. Aber was folgt daraus? Woher soll man denn wissen, welche 3rd Party Software kompromittierbare Komponenten oder Module enthält? An der Spezifikation der SBOM (Software Bill of Materials) wird noch gearbeitet, mit dem dann in Verbindung mit dem Common Security Advisory Framework (CSAF) von den Softwareherstellern Gegenmaßnahmen ergriffen werden können. Aber als Anwender? Hier kann der Einsatz von SCA Tools helfen, SCA steht für Software Composition Analysis und Gartner hat hier eine Liste solcher Produkte zusammengestellt: https://www.gartner.com/reviews/market/software-composition-analysis-sca
Aber welche Software soll getestet werden, wo könnte der Exploit vorhanden sein? Bei Eigenentwicklungen: wie schnell wird eine betroffene Bibliothek erneuert und wie schnell erfolgt über die Deployment Pipelines ein Update? Ist dieser Prozess derart definiert, dass ein Emergency Change vom Operations angestoßen werden kann, auch wenn man noch nicht in der DevOps-Welt angekommen ist? Man tut gut daran, den Prozess einmal im Stile eines Feueralarms zu testen, wenn z. B. das Update einer Bibliothek ansteht. Bedienen sich wirklich alle Lösungen von der SELBEN Instanz im Repository („Deployment Hygiene“)? Nur dann kann man sicher stellen, dass ein zentrales Update plus ein Re-Deploy auch flächendeckend funktioniert.
Eine jederzeit vollständige Service Landkarte haben!
Ist das Asset-Management aussagekräftig und vollständig, so dass dann über ein zentrales Patching oder Deployment neuer Versionen oder Updates ausgebracht werden können? Existiert ein Emergency Prozess, der es dem Operations erlaubt, bei Gefahr in Verzug ohne Absprachen mit den Service Owner z. B. ein Patching mit Reboot durchzuführen? Vor allem interessant ist dieser Punkt für Managed Service Provider wie Skaylink, wo derartige Absprachen mit dem Kunden getroffen werden müssen, da sie im Konflikt mit SLAs stehen.
Angriffe entdecken
Wenn man jetzt aber doch der erste, oder zumindest nicht schnell genug war, die Schotten dicht zu machen, sofern das überhaupt möglich ist ohne den Geschäftsbetrieb einzustellen? Oder wenn man grundlegend mit erfolgreichen Angriffen rechnet, noch bevor man von einer Schwachstelle weiß? IDS, Intrusion Detection Systeme sind hier ein Ansatz, erfolgreiche Angriffe zu entdecken, und zwar an atypischen Verhaltensweisen und Netzwerk-Traffic. Hierbei darf man aber nicht versäumen, diese Systeme und vor allem die daran angebundenen Prozesse zu testen. Wer kennt noch das EICAR test file zum Testen von Anti-Virus-Software. Sowas in der Art muss man einem IDS vorlegen. Selbe Methode, nur komplexer. Es muss aber insbesondere klar sein, was im Folgenden dann passieren muss, wenn ein System als kompromittiert entdeckt wird oder auch nur als „möglicherweise kompromittiert“ gemeldet wird. Der entsprechende Ops-Mitarbeiter muss dann wissen, was zu tun ist und nicht nur den ACK-Button drücken, um auf die Frühschicht zu warten. Zeit ist hier ein ganz wesentlicher Faktor! Genau da kann Skaylink unterstützen:
Skaylink Cyber Security Center
Viele Angriffe wehrt Skaylink Cyber Security Center sofort durch automatisierte Reaktion basierend auf AI und Machine Learning ab. Darüber hinaus schlagen geeignete Maßnahmen vor und setzen diese auf Wunsch auch gleich um. Mehr Info gibt’s hier: https://stage.skaylink.com/skaylink-cyber-security-center/
Auswirkungen reduzieren
Es gibt so einige Möglichkeiten, die Wahrscheinlichkeit eines Schadens zu reduzieren. Einige davon sind unter dem Namen „Least Privilege“ zusammengefasst. Beispiel: Erfolgreiche Log4J-Angriffe laden über LDAP weiteren Schadcode nach. Warum aber sollte man einem Service, der kein LDAP braucht, den Weg ins Internet erlauben? Oder noch konsequenter: Viele DMZ-Services beantworten nur Anfragen, bauen aber von sich aus keine Outbound connections auf. Hier sollte die Firewall dann auch entsprechend zugesperrt sein, so dann nur auf inbound-Anfragen geantwortet werden kann. Sprich: Jeder Service darf nur genau das, was er können muss und kein Port mehr.
In Hyperscaler Umgebungen profitieren Applikationen, welche nicht monolytisch auf AWS EC2 oder Azure Compute laufen, sondern Cloud Native Services oder PaaS nutzen, wo ein großer Bereich an sicherheitsrelevanten Services vom Anbieter im Rahmen des Shared Resonsibility Modells übernommen wird. Cloud hilft auch hier, wenn es richtig gemacht ist. Skaylink bringt hier eine Menge an Erfahrung mit.
Starten wir gemeinsam in die Zukunft
Unsicher, wohin die digitale Reise bei Ihnen führen soll? Unsere Expert*innen stehen Ihnen gerne unverbindlich für Ihre Fragen zur Verfügung!
Einfach das nebenstehende Formular ausfüllen und wir melden uns umgehend bei Ihnen.
