dark

Executive Order und der Solarwinds Hack – Was bedeutet das für uns?

Avatar
In den letzten zwei Jahren haben wir einiges im Bereich Cybersecurity lernen müssen. Die neuen Angriffsvektoren werden immer mehr ausgefeilter und richten sich immer mehr gegen die Wertschöpfungskette im allgemeinen. Aber was bedeutet das für uns? Was kann man dagegen unternehmen und welche Reaktionen sind von staatlicher Seite schon erfolgt?
Beginnen wir hier mit der Geschichte die all das hier ins rollen gebracht hat und dafür sorgte das die allgemeine Aufmerksamkeit auf die Verwundbarkeiten der generellen IT Infrastruktur gelenkt worden ist. Die Rede ist hier von dem SolarWinds Hack. Was passierte hier und was noch wichtiger ist; Was sind die lessons learned aus diesem Vorfall?
Wer den Artikel lieber als Youtube Video sehen möchte.. der kann hier einen Blick drauf werfen
Wichtig zu wissen ist es, dass die Firma SolarWinds eine Software herstellt, die für die Verwaltung von Netzinfrastruktur eingesetzt wird. Diese Software, mit dem Namen “Orion Platform” soll dabei helfen die Netzkomponenten effizient zu verwalten und zu administrieren. Wenn man sich auf der Webseite des Unternehmens SolarWinds die Produktbeschreibung ansieht, dann kann man dort lesen das die Software für das Monitoring, die Analyze und Verwaltung der Netzinfrastruktur eingesetzt werden kann. Und genau das haben die Kunden dann auch gemacht. Die Firma selbst hat ca 300000 Kunden weltweit und darunter sind nicht nur einzelne Firmen, sondern auch staatliche Organisationen und Konzerne aus den unterschiedlichsten Bereichen. Um immer auf dem aktuellen Stand zu bleiben beinhaltet die Softwareplattform einen automatischen Updatemechanismus. Und genau darauf hatten es die Angreifer abgesehen. Sie sahen in der Firma SolarWinds einen Multiplikator für ihre eigenen Aktivitäten. Aber wie kann man nun hierbei vorgehen? Die Angreifer besorgten sich die notwendigen Softwarewerkzeuge, durch einen Einbruch bei der Firme FireEye, und infiltrierten damit die Netze der Firma SolarWinds. Das Ziel war die Softwareentwicklungsabteilung in der die Binaries der Orion Plattform erstellt werden. Hier wurden die CI-Strecken derart manipuliert, das bei jedem Build der Software kompromittierte Binaries eingebunden werden. Das hatte nun zur Folge, das die Firma selbst diese Binaries produzierte und durch den automatischen Updateprozess in Umlauf brachte. Innerhalb kürzester Zeit konnten auf diese Weise ca 18000 Ziele infiltriert und und kompromittiert werden.
Was bedeutet das nun für uns?
Hier gibt es zwei Betrachtungswinkel. Der erste ist aus der Sicht des Konsumenten. Für die eigene Produktion ist sicherzustellen, dass keine kompromittierten Binaries eingesetzt werden. Das bedeutet das alle, und hier meine ich wirklich alle eingesetzten Binaries, überprüft werden müssen. Das sind die Abhängigkeiten der Anwendung genauso wie die Werkzeuge die eingesetzt werden in dem Produktionsprozess. Das zählen die Werkzeuge wie zum Beispiel der eingesetzte CI-Server, z.B. Jenkins, oder auch die Betriebssystemkomponenten der Infrastruktur und Docker Images.
Der zweite Betrachtungswinkel stellt die Sichtweise dar, die man als Distributor einer Software innehat. Damit ist jeder gemeint, der in irgendeiner Form Binaries verteilt. Dazu gehören nicht nur Kunden im klassischen Sinne, sondern auch andere Abteilungen die als Konsumenten der erstellten Binaries in Betracht kommen. Der damit einhergehende Vertrauensverlust kann ein Unternehmen sehr hohen finanziellen Schaden zufügen.
Was können wir unternehmen um uns zu schützen?
Wenn man sich nun die unterschiedlichen Ansätze ansieht um sich gegen diese Bedrohungen zu wappnen, kann man zwei prinzipielle Unterschiede erkennen.
DAST – Dynamic Application Security Testing
Eine Anwendung kann einem Blackbox Test unterzogen werden. Das nennen man dann DAST, Dynamic Application Security Testing. Hier geht man den Weg, wie es auch ein Hacker angehen würde. Es wird die Anwendung über die zu Verfügung stehenden Interaktionspunkte angegriffen. Hierbei werden meist Angriffsvektoren eingesetzt, die auf den Most Common Vulnerabilities basieren. Als Beispiel kann man eine SQL injection anführen. Diese Angriffsmuster sind erst einmal unabhängig von der eingesetzten Technologie und stellen typische Sicherheitslöcher in Webanwendungen dar.
Dieser Ansatz hat Vor-als auch Nachteile. Ein gravierender Nachteil ist, das mit den Tests erst begonnen werden kann, wenn die Anwendung entwickelt worden ist. Damit sind die Maßnahmen zur Beseitigung von gefundenen Schwachstellen kostenintensiver als es bei anderen Ansätzen der Fall ist. Ein bedeutender Vorteil dieses Ansatzes ist es, dass auch der dynamische Kontext überprüft werden kann, sofern man das Produktionssystem testet. Als Beispiel kann man schwache Konfigurationen, offene Ports und einiges mehr nennen.
SAST – Static Application Security Testing
Das Gegenstück zu den dynamischen Tests, sind die statischen Tests. Diese Tests analysieren die einzelnen Komponenten der involvierten Infrastruktur. Das umfasst nicht nur die erzeugten Anwendungen, sondern auch die beteiligten Komponenten für den Betrieb als auch der Erzeugung der Anwendung.
Ein Nachteil der SAST-Methode ist, dass nur nach bekannten Sicherheitslücken gesucht werden kann. Dieser Punkt relativiert sich aber dahingehend, das die Anzahl der bekannten Sicherheitslücken nicht nur stetig zunimmt, sondern das auch davon ausgegangen wird das die Menge der bekannten Sicherheitslücken die Menge der unbekannten Sicherheitslücken übertrifft. Ein weiterer Pluspunkt der SAST-Methode liegt in dem Bereich der Überprüfung der eingesetzten Lizenzen. Auch dieser Bereich trägt der Sicherheit des Unternehmens bei, wenn auch im juristischen Sinne.
Was hat nun die größte Wirkung wenn man mit dem Thema Sicherheit beginnt?
Bei der Betrachtung der unterschiedlichen Herangehensweisen, zeigt sich deutlich, das der Anteil der direkt oder indirekt eingesetzten Binaries den größten Umfang in einem Technologiestack ausmacht. Das bedeutet, das auch mit der Absicherung genau dieser Teile begonnen werden sollte. Hier gibt es nur den Weg mit SAST sicherzustellen das auch wirklich 100% direkt überprüft wird. Alle anderen Methoden erreichen diese Abdeckung nicht, oder wenn, dann nur in sehr seltenen Sonderfällen.
Hierbei ist allerdings zu beachten, das man die Abhängigkeiten untereinander versteht. Nur so kann man den möglichen Angriffsvektor erkennen und extrahieren. Hierbei ist es von essentieller Bedeutung, das nicht nur die Binaries selbst untersucht werden, sondern auch die dazugehörigen Meta-Informationen ausgewertet werden. Innerhalb der Softwareentwicklung gibt es für diese Analysen zwei Punkte an denen eine solche Analyse sehr gut hineinpasst. Der erste Punkt der den meisten einfallen wird, ist die CI-Strecke. Hier kann der CI-Server die Analyse bei der Durchführung einer Build-Pipeline alle Überprüfungen vornehmen und auch gleich das Reporting damit übernehmen. Sollten die Verstöße zu massiv sein, wird der Build abgebrochen. Die zweite Stelle die sich bestens für eine solche Analyse eignet, ist direkt in der IDE. Hier kann schon bei der Definition festgestellt werden ob die eingesetzte Lizenz erlaubt ist. Ebenfalls kann die Liste der bekannten Vulnerabilities extrahiert werden und liefert damit genug Informationen um die Entscheidung zu treffen ob diese Version dieser Abhängigkeit eingesetzt werden darf.
Lesson Learned – was wir durch den SolarWinds Hack gelernt haben
Durch den SolarWinds haben wir folgende Dinge lernen können. Die Angriffe gehen nicht mehr auf die finalen Ziele selbst, sondern gegen die Zulieferer. Hier versucht man Multiplikatoren zu erreichen, die den Wirkungsgrad dieses Angriffs massiv erhöhen. Ebenfalls muss man sich nun nicht mehr nur gegen den eigenen Einsatz kompromittierter Binaries schützen. Die neu dazu gekommene Komponente bedeutet, das auch die selbst erzeugten Binaries abgesichert werden müssen. Niemand möchte ein Distributor von infizierter Software werden. Daraus folgt, dass alle beteiligten Komponenten einer permanenten Überprüfung unterzogen werden müssen.
Reactions – Die Executive Order von Mr Biden
Der eine oder andere hat es sicherlich mitbekommen das es da diese Executive Order of Cybersecurity von dem US Präsidenten gegeben hat. Aber was genau bedeutet das nun und wer kann so etwas überhaupt unter welchen Bedingungen machen?
In den Vereinigten Staaten kann der Präsident – die „Executive Branch“ der US-Regierung – eine sogenannte Executive Order erlassen. Ähnlich wie ein CEO in einem Unternehmen hat die Exekutive die Macht, einige einseitige Entscheidungen zu treffen, die sich auf das Verhalten der US-Regierung auswirken. Wichtig ist, dass diese Anordnungen auf das Verhalten und die Politik der Regierung beschränkt sind und nicht auf allgemeine Gesetze oder Gesetze, die in die Rechte von Einzelpersonen oder Staaten eingreifen. Überschreitet die Exekutive in diesem Bereich, kann der Oberste Gerichtshof der USA oder andere rechtliche Mittel anfechten und alle Maßnahmen widerrufen. Nur der Präsident – aufgrund seines Status als Staatsoberhaupt – kann eine Durchführungsverordnung erlassen. Kein anderer Beamter darf dies tun.
Wichtig ist, dass Executive Orders meist darauf beschränkt sind, wie die US-Regierung intern vorgeht. Eine Exekutive Order könnte beispielsweise nicht einfach beschließen, die Steuern in einem Staat zu erhöhen oder weitreichende Handelsrichtlinien zu erlassen. Exekutive Anordnungen sind für das Verhalten der US-Regierung rechtlich bindend, wenn sie keine Grundrechte verletzen oder etwas Verfassungswidriges erlassen. Aus diesem Grund können man feststellen, dass diese Befehle die Richtlinien von Präsident zu Präsident ändern, da sie wie ein CEO einige der Tagesordnungen der Regierung festlegen. In diesem Fall bezieht sich die Exekutivverordnung darauf, wie die US-Regierung ihren eigenen Softwareverbrauch überwacht und reguliert, und legt Anforderungen fest, wie diese Software dokumentiert werden muss, um an die Regierung verkauft zu werden. Es diktiert nicht den Handel auf breiter Ebene.

Da die US-Regierung ihre eigene Arbeitsweise definieren kann, wurde beschlossen, dass die SBOM-Anforderungen (in Vorbereitung) die einzige Möglichkeit sein werden, Softwarekäufe zu genehmigen – Um eine Vorstellung von dem Volumen zu bekommen, muss man wissen das es sich um einen Betrag in zweistelliger Milliardenhöhe jährlich handelt. Dies bedeutet, dass jedes Unternehmen, das an US-Regierungsbehörden, wahrscheinlich staatliche und lokale Behörden, verkaufen möchte, und jeder, der mit Wiederverkäufern zusammenarbeitet, die an die Regierung verkaufen, und mehr, alle diese neuen Standards erfüllen müssen.

Als sich die Europäische Union mit der DSGVO auf umfassende Datenschutz- und Datensicherheitsgesetze geeinigt hat, war die Wirkung weltweit und schnell zu spüren. In einer global vernetzten Wirtschaft können Entscheidungen der weltgrößten BIP-Produzenten Maßstäbe für andere Bereiche setzen. Mit der DSGVO mussten Unternehmen in den USA und anderen Bereichen sofort Software und Prozesse überarbeiten und aktualisieren, um weiterhin in der EU Geschäfte machen zu können. Tatsächlich wurde es zu einer weltweiten Regelung, um EU-Verträge nicht zu verlieren. Ebenso wird davon ausgegangen, dass sich die US-Ordnung zur Cybersicherheit in umgekehrter Richtung entwickelt, wobei globale Unternehmen mit Sitz in den USA das globale Verhalten für Softwaresicherheit beeinflussen.

Wow – und nun?

Was bedeutet das nun für mich als Softwareentwickler? Nun, die Auswirkungen an dieser Stelle sind nicht so gravierend wie man sich das evtl vorstellen möchte. Im Endeffekt wird hier davon gesprochen das eine vollständige Liste aller enthaltenen Abhängigkeiten erstellt werden muss. Damit sind die direkten und indirekten Abhängigkeiten gemeint. Um nun solch einen Abhängigkeitsgraphen zu erhalten kann man sich zum Beispiel der Werkzeuge bedienen, die dieses schon machen. Gemeint sich die Werkzeuge die in der Lage sind, zum Beispiel einen vollen Abhängigkeitsgraphen zu erzeugen. Hierzu benötigt man einen logischen Punkt über den alle Abhängigkeiten geholt werden. Am besten eignet sich ein Tool wie zum Beispiel Artifactory, da hier das Wissen über alle eingesetzten Dependency-Manager zusammenlaufen. Werkzeuge wie der Vulnerability-Scanner JFrog Xray können dann auf diese Informationen zugreifen und nicht nur nach bekannten Schwachstellen und eingesetzten Lizenzen scannen, sondern auch den vollen Abhängigkeitsgraphen extrahieren. Diese Informationen können somit als Build-Information durch die CI-Strecke (z.B. JFrog Pipelines) erzeugt und in einem Build-Repository innerhalb von Artifactory abgelegt werden.

Fazit

Wir haben gesehen das die neuen Qualitäten der Angriffe auf Softwaresysteme im Allgemeinen zu erweiterten Abwehrmaßnahmen führen werden. Gemeint ist hier eine lückenlose Analyse aller beteiligten und produzierten Artefakte. Die dafür benötigten Werkzeuge müssen in der Lage sein über Technologiegrenzen hinweg die Informationen zu aggregierten Wirkungsgraphen zusammenzuführen. Ein Punkt innerhalb der Softwareentwicklung der sich hierfür geradezu anbietet, ist der logische Punkt über den alle Binaries dem System zugeführt werden. Die Komponenten alleine sind nicht ausreichend, da nur durch das Verständnis der dazugehörigen Meta-Informationen auch alle indirekten Elemente erreicht und überprüft werden können.

Die hierfür eingesetzten Werkzeuge können dann auch für die Erstellung der SBOM´s genutzt werden.

Meiner Meinung nach ist es nur ein Frage der Zeit bis wir auch dieser Anforderung nachkommen müssen, wenn wir keinen wirtschaftlichen Nachteil durch die Executive Order of Cybersecurity bekommen wollen.

Wer mehr zu dem Thema erfahren möchte, oder die hier kurz genannten Werkzeuge testen möchte; Kann sich gerne an mich wenden.

Wir bieten neben weiteren Informationen auch kostenlose Workshops an, um sich rein praktisch auf diese Herausforderungen vorzubereiten.

Und wer sofort mehr wissen möchte, der kann gerne auf meinem Youtube Kanal gehen. Dort habe ich weiterführende Videos zu diesem Thema.

Es wäre schön mir als kleines Dankeschön ein Abo auf meinem Youtube-Kanal zu hinterlassen.

https://www.youtube.com/user/svenruppert

Cheers Sven

Total
0
Shares
Previous Post

Cybersecurity – Was ist SAST, DAST, IAST und RASP? – ein kleines Intro

Next Post

Bewährte Praktiken für CI/CD Pipelines

Related Posts

PCI DSS-Sicherheitsauditverfahren – alles, was Sie wissen müssen

Die Einhaltung des Datensicherheitsstandards (DSS) der Zahlungskartenbranche (PCI, engl.: Payment Card Industry) erfordert eine jährliche Berichterstattung. Diese jährliche Berichterstattung umfasst umfangreiche PCI-DSS-Auditverfahren für Organisationen, die die höchsten Transaktionsvolumina abwickeln. Die Auditverfahren werden im Rahmen einer Vor-Ort-Bewertung durchgeführt, die als Konformitätsbericht (ROC, engl.: Report on Compliance) bezeichnet wird.
Avatar
Read More