{"id":20446,"date":"2021-08-14T19:59:19","date_gmt":"2021-08-14T17:59:19","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=20446"},"modified":"2021-08-14T19:59:23","modified_gmt":"2021-08-14T17:59:23","slug":"supply-chain-attacks","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/08\/14\/supply-chain-attacks\/","title":{"rendered":"Supply Chain Attacks – Die Lieferkette schl\u00e4gt zur\u00fcck"},"content":{"rendered":"\n

ein Artikel von Verena Eichinger, Amelie Kassner und Elisa Zeller<\/em><\/p>\n\n\n\n

\"\"<\/a><\/figure><\/div>\n\n\n\n

Nach SolarWinds schafft es eine neue Schlagzeile aus der IT-Welt in den Massenmedien ihre Kreise zu ziehen. \u00dcber 500 Superm\u00e4rkte in Schweden mussten wegen eines Cyberangriffs schlie\u00dfen. Wie bereits bei SolarWinds handelt es sich auch hier um eine Supply Chain Attack (SCA). Mittlerweile f\u00e4llt dieser Begriff immer h\u00e4ufiger und er schafft es nicht nur allgemein f\u00fcr Aufmerksamkeit zu sorgen, sondern f\u00fchrt auch zu gro\u00dfer Besorgnis in IT-Kreisen. [12]<\/p>\n\n\n\n

Wir alle, die wir diesen Artikel lesen, sitzen gerade vor einem technischen Ger\u00e4t, das ein komplexes Zusammenspiel aus Hardware und Software darstellt. Diese Komplexit\u00e4t k\u00f6nnen wir in der heutigen Zeit nicht mehr vollst\u00e4ndig durchdringen, oder wissen Sie, woher die einzelnen Komponenten stammen und wer zu diesen Zugang hatte? Ist jegliche Software auf dem neuesten Stand und sind genutzte Bibliotheken auch wirklich vertrauensw\u00fcrdig? Kann man sich sicher sein, dass in das letzte Softwareupdate keine Malware eingeschleust wurde? Das alles sind Fragen, die sich stellen, wenn man sich mit SCAs befasst und beginnt, die Tiefe der dahinterstehenden Problematik zu begreifen. Zwar waren bisher stets Firmen das Ziel der Angriffe, doch wie es der k\u00fcrzliche Vorfall bei der Supermarktkette Coop in Schweden zeigt, sind deren Auswirkungen auch beim Endnutzer angekommen. An dieser Stelle lohnt es sich f\u00fcr jedermann, die Thematik genauer zu betrachten. Dazu wird im ersten Abschnitt dieses Artikels das zugrundeliegende Prinzip der SCAs erl\u00e4utert und gekl\u00e4rt, womit wir es genau zu tun haben. Anschlie\u00dfend werden die genannten Beispiele SolarWinds und der Angriff auf Kaseya, zu dessen Opfern auch die Supermarktkette Coop geh\u00f6rt, betrachtet. Diese beiden Angriffe sind Musterbeispiele f\u00fcr die Gefahr und den Wirkungsgrad der SCAs. Zuletzt soll es darum gehen, was gegen die Bedrohung durch SCAs unternommen werden kann.<\/p>\n\n\n\n\n\n\n\n

\n
\n

Nach diesem \u00dcberblick \u00fcber die Thematik k\u00f6nnen wir die vorigen Fragen erneut betrachten und entscheiden, ob wir uns sicher f\u00fchlen k\u00f6nnen oder von nun an in Paranoia leben m\u00fcssen. <\/p>\n\n\n\n

Im Anschluss finden sich au\u00dferdem weiterf\u00fchrende Links f\u00fcr alle, die sich noch tiefer in die Thematik einlesen m\u00f6chten. <\/p>\n<\/div>\n\n\n\n

\n

Inhalt:<\/strong><\/p>\n\n\n\n

  1. Einleitung<\/a><\/li>
  2. Das zugrundeliegende Prinzip<\/a><\/li>
  3. Kaseya<\/a><\/li>
  4. SolarWinds<\/a><\/li>
  5. Schutz vor Supply Chain Attacks<\/a><\/li>
  6. Fazit<\/a><\/li>
  7. Weiterf\u00fchrende Links<\/a><\/li>
  8. Quellen<\/a><\/li><\/ol>\n<\/div>\n<\/div>\n\n\n\n

    Das zugrundeliegende Prinzip<\/strong><\/h1>\n\n\n\n

    Zun\u00e4chst zu der grundlegenden Fragestellung, was man unter SCAs versteht. Die SCAs sind eine Art der Cyberattacken. Deren Grundgedanke ist es, nicht mehr ein Opfer direkt zu attackieren, sondern, wie der Name schon verr\u00e4t, \u00fcber eine Schwachstelle in dessen Lieferkette anzugreifen. Die Ziele sind dabei dieselben wie bei allen Cyberattacken: Vertraulichkeit, Integrit\u00e4t und Verf\u00fcgbarkeit von Daten und Diensten werden untergraben. Konkret genutzt werden die Attacken meist zum Diebstahl wertvoller Daten oder zur Erpressung der Opfer. Eine g\u00e4ngige Methode hierf\u00fcr ist die Nutzung eines Verschl\u00fcsselungstrojaners, sogenannter Ransomware. Die Angreifer profitieren bei der Durchf\u00fchrung von SCAs von mehreren Besonderheiten. Der nachfolgend erl\u00e4uterte Aufbau von Lieferketten erm\u00f6glicht es, einen Angriff ohne Mehraufwand zu verbreiten. So werden beispielsweise mit nur einer Attacke hunderte Firmen getroffen. Zudem wird eine bei einem Zulieferer eingeschleuste Malware unter dessen Namen bzw. \u00fcber dessen Software verbreitet. Damit versteckt sich eine SCA hinter g\u00fcltigen Signaturen und Zertifikaten und nutzt das Vertrauen aus, das dem Zulieferer entgegengebracht wird. Derartige Angriffe sind meist anspruchsvoll und technisch hoch entwickelt, da der Weg bis zum eigentlichen Opfer gut durchdacht sein muss und die Attacke an keiner Stelle auf diesem Weg entdeckt werden darf. [40] [42] [57]<\/p>\n\n\n\n

    Das Feld der SCAs ist dazu noch sehr vielf\u00e4ltig was genutzte Angriffsformen betrifft, da hier vom Einschleusen von Schadsoftware bis zum Austausch von Hardware alles m\u00f6glich ist. Entsprechend vielf\u00e4ltig sind die in diesem Kontext genutzten Begrifflichkeiten. Value Chain Attack oder Third Party Attack sind Bezeichnungen, die gleichbedeutend zu Supply Chain Attack genutzt werden. Durch die Vielzahl an m\u00f6glichen Angriffsformen tauchen allerdings auch spezifischere Begriffe f\u00fcr Attacken auf. So geh\u00f6ren die zunehmenden Dependency Confusion<\/em> oder auch Supply Chain Substitution<\/em> Attacks ebenfalls zu den SCAs. Ein Beispiel f\u00fcr die zahlreichen M\u00f6glichkeiten eines Angriffs w\u00e4ren neben dem Diebstahl von Daten oder Technologien auch das Einschleusen von Schadcode. Au\u00dferdem kann ein Angriff zu jedem Zeitpunkt im Lebenszyklus eines Produkts, also von der Entwicklung bis zum Betrieb oder der Wartung erfolgen. Man muss auch bedenken, dass nicht nur Angriffe auf spezielle Firmen, sondern auch auf die Verbindungen und den Datenfluss zwischen Elementen in der Lieferkette m\u00f6glich sind. [20] [33] [38]<\/p>\n\n\n\n

    Um hier den \u00dcberblick zu wahren gilt grunds\u00e4tzlich: Erfolgt ein Angriff \u00fcber die Lieferkette, so handelt es sich um eine Art von SCA. Daher lohnt sich ein Blick darauf, was genau die Lieferkette umfasst.<\/p>\n\n\n\n

    Der Begriff Lieferkette ist heutzutage beinahe schon irref\u00fchrend, da Herstellungsprozesse mittlerweile komplexe Netzwerke statt einfacher \u201eKetten\u201c sind. Die Vernetzung im Zuge der Globalisierung und die internationale Zusammenarbeit in der Herstellung von Produkten ist extrem stark ausgepr\u00e4gt. Das gilt entsprechend auch f\u00fcr die Vernetzung in Lieferketten von Hardware und Software. Zu dieser geh\u00f6ren alle Firmen oder Organisationen, die durch Produkte oder Dienstleistungen am Endprodukt mitwirken. Das umfasst unter anderem jegliche Vertriebsstellen, Spediteure, Lagerungsst\u00e4tten und s\u00e4mtliche Organisationen, die ein Produkt entwickeln, verbessern, ver\u00e4ndern oder warten. Verallgemeinert besteht die Lieferkette ausgehend von einer Firma also aus allen Zulieferern und wiederum deren Zulieferern, allen Kunden und wiederum deren Kunden, sowie der Firma an sich. [14] [42]\u00a0 [54]<\/p>\n\n\n\n

    Betrachtet man den Software-Bereich, so umfasst die Lieferkette folglich alles, was zum Endprodukt beitr\u00e4gt. Dazu geh\u00f6rt Open Source Code, Code von Partnern oder Zulieferern oder propriet\u00e4rer Code. S\u00e4mtliche Pakete und Abh\u00e4ngigkeiten und auch jegliche anderen Daten m\u00fcssen bedacht werden. Heutige Software ist entsprechend komplex und die vermehrte Nutzung von Integrations-L\u00f6sungen erh\u00f6ht diese Komplexit\u00e4t noch weiter. [16] [39]<\/p>\n\n\n\n

    In Bezug auf Angriffe bietet die Lieferkette viele M\u00f6glichkeiten. Anstelle eines direkten Angriffs auf ein gut gesch\u00fctztes Ziel nimmt man einen Umweg in Kauf und nutzt dabei leicht zug\u00e4ngliche Stellen in der Lieferkette aus. Hierbei k\u00f6nnen mangelnde Sicherheitsma\u00dfnahmen bei kleinen Zulieferern oder Sicherheitsl\u00fccken in deren Software ausgenutzt werden, um dadurch Zugang zum eigentlichen Opfer zu erlangen. Der Kern der Problematik liegt folglich darin, dass ein Sicherheitsrisiko an einem einzigen Punkt der Lieferkette an alle nachfolgenden Stellen weitergegeben wird. Diese Tatsache in Kombination mit der Komplexit\u00e4t des Netzes aktueller Lieferketten zeigt die Dimension der Problematik. In diesem komplexen Zusammenspiel reicht schon eine Schwachstelle in der Lieferkette aus, um einen Angriff zu erm\u00f6glichen. [42]<\/p>\n\n\n\n

    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Die Ursachen f\u00fcr derartige Schwachstellen sind nicht neu, es handelt sich um g\u00e4ngige Sicherheitsl\u00fccken. Diese beruhen auf mangelnden Anforderungen, die an die Sicherheit gestellt werden, oder ineffektiven Ma\u00dfnahmen. M\u00e4ngel und Fehler im Code oder Design einer Anwendung, sowie unzureichende Kontrolle und fehlende Tests k\u00f6nnen ebenfalls der Grund f\u00fcr L\u00fccken sein. Auch unsicheres Software Deployment oder allein schon unsichere Kommunikation k\u00f6nnen zu Problemen in der Sicherheit f\u00fchren. [42]<\/p>\n\n\n\n

    Wie man solche Probleme vorbeugen kann, wird im letzten Teil des Artikels Thema sein. Zun\u00e4chst betrachten wir zwei Attacken, die die zuvor beschriebenen Prinzipien in die Tat umgesetzt haben und beispielhaft daf\u00fcr stehen, zu was SCAs f\u00e4hig sind.<\/p>\n\n\n\n\n\n\n\n

    ein Artikel von Verena Eichinger, Amelie Kassner und Elisa Zeller<\/em><\/p>\n\n\n\n

    Die Attacke auf Kaseya<\/strong><\/h1>\n\n\n\n

    Betrachten wir die vergangenen Nachrichten zu Cyberangriffen beispielsweise zu Daten Leaks oder Breaches, stellen wir fest, dass diese mittlerweile fast schon regelm\u00e4\u00dfig und in erschreckender H\u00e4ufigkeit auftreten. F\u00fcr den Nutzer geh\u00f6ren derartige \u201eNews\u201c \u2013 die einzig wirkliche Neuigkeit dabei ist, wessen Daten diesmal betroffen sind \u2013 beinahe schon zum Alltag und werden von Vielen mit einem Achselzucken hingenommen. Die vergangenen Schlagzeilen zeigen allerdings auch, das SCAs das Potenzial haben, wesentlich mehr Schrecken zu verbreiten. Ein Beispiel hierf\u00fcr ist der Angriff auf die Firma Kaseya, der zur Schlie\u00dfung von \u00fcber 500 Filialen des Supermarktes Coop in Schweden gef\u00fchrt hat. In diesem Fall wird sichtbar und f\u00fcr betroffene Schweden im Alltag sp\u00fcrbar, wie weitreichend das Potenzial derartiger Attacken ist. Die Auswirkungen verlassen den Raum unserer digitalen Daten und finden sich pl\u00f6tzlich ganz real in unserer Nachbarschaft wieder, wo sie uns am Einkaufen hindern. [12]<\/p>\n\n\n\n

    Der Angriff erfolgte in drei Schritten: Zuerst wurde die Authentifizierung umgangen, anschlie\u00dfend erfolgte ein Upload von Daten und zuletzt die Ausf\u00fchrung von Code. Genutzt wurde dabei eine Zero-Day-L\u00fccke im Desktop-Management-Tool VSA der Firma Kaseya (CVE-2021-30116). Zwei weitere Sicherheitsl\u00fccken scheinen in Kombination mit dieser ausgenutzt worden zu sein, um ins System zu gelangen (CVE-2021-30119, CVE-2021-30120). Wie genau die Authentifizierung dabei umgangen wurde ist bisher nicht bekannt, allerdings gibt es verschiedene Ans\u00e4tze f\u00fcr eine Erkl\u00e4rung  (siehe weiterf\u00fchrende Links<\/em>). Da VSA unter anderem zum Remote-Management dient, ist die Software pr\u00e4destiniert zum Verteilen von Malware. Durch die L\u00fccken konnten Angreifer Zugang zu VSA Servern erlangen und eine Ransomware in Form eines Updates an Nutzer des Tools verteilen. <\/p>\n\n\n\n

    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Da zu Kaseyas Kunden viele Managed Service Provider geh\u00f6ren, die mit der Software wiederum eigene Kunden betreuen, konnte der Angriff sich global auf unz\u00e4hlige Firmen ausweiten.<\/p>\n\n\n\n

    Mit dem Update wurde eine veraltete Version des Windows Defenders und eine dll-Datei mit der eigentlichen Ransomware ausgeliefert. Der Windows Defender wird gestartet und eine Schw\u00e4che in der veralteten Version erm\u00f6glicht es, den Schadcode der dll-Datei unter vertrauensw\u00fcrdigen Prozessen auszuf\u00fchren. Versteckt durch den Windows Defender konnten die betroffenen Systeme damit vor\u00fcbergehend unentdeckt verschl\u00fcsselt werden. [12] [15] [18] [19] [35]\u00a0 <\/p>\n\n\n\n

    \"\"<\/a>
    Verbreitung des b\u00f6sartigen Updates \u00fcber MSPs an weitere Kunden [46]<\/em><\/figcaption><\/figure><\/div>\n\n\n\n

    Hinter dem Angriff steckt die Gruppe REvil. Der Vorfall wird in den Medien als eine der gr\u00f6\u00dften bisher dagewesenen Ransomware-Attacken bezeichnet, was bei ca. 1500 betroffenen Firmen und Organisationen wohl berechtigt ist. Neben den schwedischen Superm\u00e4rkten waren beispielsweise auch Kinderg\u00e4rten und Schulen in Neuseeland betroffen und auch in Deutschland blieben zwei IT-Dienstleister nicht verschont. Die Allgemeine Forderung der Ransomware-Gang betrug 70 Millionen Dollar. F\u00fcr die Coop-Superm\u00e4rkte \u00e4u\u00dferte sich die Attacke in der Stilllegung des Kassensystems. Knapp eine Woche nach dem Angriff konnten jedoch alle Superm\u00e4rkte wieder \u00f6ffnen, da das Kassensystem von Technikern zur\u00fcckgesetzt und neu eingerichtet werden konnte. Drei Wochen nach der Attacke hat die Firma Kaseya nun einen Schl\u00fcssel zur Entschl\u00fcsselung f\u00fcr ihre Kunden bereitgestellt, woher dieser stammt verr\u00e4t die Firma jedoch nicht. Zudem wird f\u00fcr Kunden ein Tool angeboten, um die eigenen Systeme zu \u00fcberpr\u00fcfen. Damit d\u00fcrften die Auswirkungen des Angriffs endg\u00fcltig abklingen. Dennoch setzt die Zahl der Opfer dieses einen Angriffs neue Ma\u00dfst\u00e4be f\u00fcr das Ausma\u00df, das man von k\u00fcnftigen Angriffen erwarten kann. Zu den T\u00e4tern bleiben lediglich Mutma\u00dfungen, denn REvil ist von der Bildfl\u00e4che verschwunden. Ob die T\u00e4ter zur Rechenschaft gezogen werden, ihre Infrastruktur durch Beh\u00f6rden lahmgelegt wurde oder sie mit dem erpressten Geld lediglich Urlaub machen ist jedoch nicht bekannt (Stand 14.08.21). [13] [17] [36] [45] [47]<\/p>\n\n\n\n

    \"\"<\/figure><\/div>\n\n\n\n

    Was von dem Angriff bleibt sind diverse seitdem ver\u00f6ffentlichte Updates zu VSA und ein \u00dcberblick zu IoCs f\u00fcr die Attacke. Damit m\u00f6chte man in Zukunft besser gewappnet sein. <\/p>\n\n\n\n

    F\u00fcr die Firma Kaseya bleibt die Situation jedoch angespannt, denn keine vier Wochen nach dem Vorfall sind schon wieder mehrere Sicherheitsl\u00fccken in einem Kaseya-Produkt aufgetaucht. Es gibt jedoch auch eine positive Auswirkung des Vorfalls, n\u00e4mlich die Sensibilisierung der Bev\u00f6lkerung f\u00fcr das Thema IT-Sicherheit. Fraglich bleibt jedoch, ob diese zusammen mit den Schlagzeilen aus den Nachrichten wieder verschwindet, oder tats\u00e4chlich Schritte zum Schutz gegen SCAs und andere Attacken eingeleitet werden. [1] [12] [17]<\/p>\n\n\n\n\n\n\n\n

    ein Artikel von Verena Eichinger, Amelie Kassner und Elisa Zeller<\/em><\/p>\n\n\n\n

    SolarWinds<\/h1>\n\n\n\n

    Einer der bekanntesten F\u00e4lle, wenn nicht sogar der bekannteste Fall, ist SolarWinds, der etwa im Dezember 2020 publik wurde und das Thema SCAs weltweit in den Fokus ger\u00fcckt hat. Bei SolarWinds handelt es sich um eine Firma, die IT-Management-Software und Remote-\u00dcberwachungstools anbietet, unter anderem f\u00fcr Netzwerkverwaltung, IT-Sicherheit und Anwendungsmanagement. Mit in ihrem Angebot ist die \u201cOrion Platform\u201d, die f\u00fcr die zentrale \u00dcberwachung, Analyse und Verwaltung des gesamten IT-Stacks verwendet werden kann. Auf einer inzwischen nicht mehr zug\u00e4nglichen Website listet SolarWinds mehrere hochkar\u00e4tige Kunden auf, ein Teil davon wird in der folgenden Abbildung dargestellt. [44] [27] [43]<\/p>\n\n\n\n

    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Eben diese Orion-Plattform wird der Firma zum Verh\u00e4ngnis, als \u00fcber eine Malware eine Backdoor in den Orion-Quellcode eingeschleust und an etwa 18.000 Nutzer per Update ausgeliefert wird. \u00dcber diese Backdoor k\u00f6nnen bei vermutlich ausgew\u00e4hlten Kunden weitere Angriffe ausgef\u00fchrt und zus\u00e4tzliche Backdoors installiert werden. Betroffen sind die Versionen 2019.4 HF 5 bis 2020.2.1, die \u00fcber den Zeitraum zwischen M\u00e4rz 2020 und Juni 2020 herausgegeben wurden. Es wird davon ausgegangen, dass Russland hinter den Angriffen steht. Im Speziellen wird ein Arm des russischen Staatsgeheimdienstes (SVR) verd\u00e4chtigt. [26]<\/p>\n\n\n\n

    Begriffe und Komponenten<\/h2>\n\n\n\n

    Betrachtet man den Angriff genauer, f\u00e4llt schnell auf, dass es sich nicht nur um eine einzelne Komponente handelt. Es kamen sowohl Malware, als auch Backdoors und Malware-Loader zum Einsatz, die in der Gesamtheit den komplexen Angriff erst m\u00f6glich gemacht haben. Auf die einzelnen Komponenten und deren Benennung wird in dem folgenden Abschnitt genauer eingegangen.<\/p>\n\n\n\n

    Mithilfe der SUNSPOT-Malware konnte die SUNBURST-Backdoor in die Orion Plattform, beziehungsweise deren Quellcode, eingeschleust werden. Der so modifizierte Code wurde anschlie\u00dfend von der Firma digital signiert und an Kunden per Update ausgeliefert. Die Backdoor erm\u00f6glicht es den Angreifern nun, auf betroffene Systeme und deren Daten zuzugreifen.<\/p>\n\n\n\n

    TEARDROP und RAINDROP sind weitere Elemente der SUNBURST-Angriffskette, hierbei handelt es sich um Malware-Loader. Diese konnten von den Angreifern als sekund\u00e4re Tools genutzt werden, um noch tiefer in die Netzwerke ausgew\u00e4hlter Opfer einzudringen und weitere Malware zu installieren. Sp\u00e4ter kamen zudem Berichte \u00fcber SUNSHUTTLE auf, eine weitere Backdoor, die bei kompromittierten Systemen gefunden wurde. [44]<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Etwas verwirrend ist die Benennung von Microsoft, da diese den Angriff urspr\u00fcnglich als SOLORIGATE bezeichneten und sp\u00e4ter dazu \u00fcbergegangen sind, den Angreifer hinter SUNBURST, TEARDROP und zugeh\u00f6rigen Komponenten als NOBELIUM zu betiteln. [32]<\/p>\n\n\n\n

    Im Zuge der Ermittlungen des SolarWinds-Angriffs und beim \u00dcberpr\u00fcfen des Codes der Orion-Anwendung wurde eine weitere Malware entdeckt, die im Nachhinein als SUPERNOVA betitelt wird.  Diese Malware wurde \u00fcber eine Sicherheitsl\u00fccke in der Orion-Plattform verbreitet. Es ist jedoch nicht klar, ob SUPERNOVA von denselben Angreifern wie SUNBURST stammt, da die betroffene dll-Datei nicht digital signiert wurde. Ebenfalls unklar ist, ob SUPERNOVA \u00fcberhaupt zum Einsatz gekommen ist. [3] [34] [50]<\/p>\n\n\n\n

    Zeitlicher Ablauf<\/h2>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Es ist wahrscheinlich, dass sich die Verursacher mehrere Monate in dem Netzwerk des SolarWind-Unternehmens befanden und den Angriff dort vorbereitet haben, bevor sie den Schadcode letztendlich in die Updates eingef\u00fcgt haben. <\/p>\n\n\n\n

    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Eine erste Kompromittierung der Entwicklungsumgebung fand wohl bereits am 04.09.2019 statt. In einem Artikel der Associated Press ist sogar bereits von Januar 2019 die Rede. Um herauszufinden, ob ihr Eingreifen unentdeckt bleibt, f\u00fchrten die Angreifer anschlie\u00dfend Code-Tests durch, bei denen sie Hintert\u00fcren in die Orion-Software eingeschleust haben. Etwa im Oktober 2019 m\u00fcssen Updates an Kunden ausgeliefert worden sein, die bereits derartigen Testcode enthielten. Dies blieb, wie erhofft, unentdeckt. [51] [25]<\/p>\n\n\n\n

    Von M\u00e4rz 2020 bis Juni 2020 standen die mit der Backdoor versehenen Updates zur Verf\u00fcgung. Erst im Zeitraum vom 08. – 11. Dezember entdeckte die Firma FireEye, dass sie Opfer eines Hackerangriffs wurde und fand im Zusammenhang damit die Orion-Kompromittierung. [44]<\/p>\n\n\n\n

    Im Laufe der Zeit wurden mehr und mehr Details zu dem Angriff bekannt, so beispielsweise, dass sich die Angreifer vermutlich seit September und wom\u00f6glich sogar einige Monate davor Zugang zum SolarWinds-System verschafft hatten. Auch die sp\u00e4ter entdeckte Backdoor SUNSHUTTLE, zu der FireEye und Microsoft am 04.03.2021 einen Bericht ver\u00f6ffentlichten, k\u00f6nnte bereits am 13.08.2020 aufgefallen sein, als eine suspekte betroffene Datei bei VirusTotal hochgeladen wurde. Welche Folgen das zu dem damaligen Zeitpunkt hatte, ist unklar.<\/p>\n\n\n\n

    Der Angriff im Detail<\/h2>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Ziel der Angreifer war es, die SUNBURST-Backdoor mithilfe der SUNSPOT-Malware m\u00f6glichst unentdeckt einzuschleusen. SUNSPOT ist dabei so konzipiert, dass es nur unter bestimmten Bedingungen aktiv ist, und w\u00e4hrend dem Build-Prozess Quellcode austauschen kann. Gleichzeitig wurde darauf geachtet, dass die neuen Codezeilen in keinen Build Logs auftauchen und dadurch keine Build-Fehler entstehen. F\u00fcr detaillierte Informationen zu den technischen Aspekten finden sich bei den weiterf\u00fchrenden Links mehrere Artikel: Ein Blogpost von Microsoft beschreibt das Vorgehen und die verwendeten MITRE ATT&CK-Techniken im Detail. Crowdstrike geht zudem genauer auf SUNSPOT ein.  [25] [29] [7]<\/p>\n\n\n\n

    Mit dieser Vorgehensweise konnte die Backdoor in der eigentlich legitimen Datei \u201cSolarWinds.Orion.Core.BusinessLayer.dll\u201d <\/em>eingebaut werden. Da die Datei von SolarWinds signiert war und so ausgef\u00fchrt wurde, dass alle normalen Funktionalit\u00e4ten erhalten blieben, wurde keine b\u00f6sartige Aktivit\u00e4t vermutet. F\u00fcr weitere Schritte wurde mittels der nun infiltrierten dll-Datei \u00fcber die Webadresse avsvmcloud[.]com<\/em> eine entfernte Netzwerkinfrastruktur aufgerufen. So konnte \u00fcber die Kommunikation zu der Webadresse eine Steuerung von Au\u00dfen aufgebaut werden. Diese erm\u00f6glichte es den Angreifern, ihre Arbeit fortzusetzen. Sie sind anschlie\u00dfend tiefer in das System eingedrungen (\u201clateral movement\u201d, s. weiterf\u00fchrende Links), um weitere Daten zu kompromittieren oder zu exfiltrieren. [9] [31]<\/p>\n\n\n\n

    Es liegt nahe, dass die Angreifer f\u00fcr ihre weiteren Ziele eine Abw\u00e4gung zwischen der Gefahr entdeckt zu werden und der m\u00f6glichen Beute vorgenommen haben. Die Ziele, die im Anschluss oben auf dieser Liste standen, konnten beispielsweise Opfer von TEARDROP werden. Da es sich dabei um einen Malware-Loader handelt, konnte damit weitere Schadsoftware auf dem System installiert werden. TEARDROP wurde \u00fcber die mit der Backdoor versehenen Orion-Plattformen an die entsprechenden Netzwerke ausgeliefert. Eine technische Analyse zu RAINDROP, dem zweiten gefundenen Malware-Loader, und ein Vergleich von RAINDROP und TEARDROP wird in einem Artikel von Symantec vorgestellt (s. weiterf\u00fchrende Links<\/em>).\u00a0 Au\u00dferdem wurden Schwachstellen in anderen weit verbreiteten Softwareprodukten, wie VMWare, von den Angreifern genutzt, um weiter vordringen zu k\u00f6nnen. [24] [26] [48]<\/p>\n\n\n\n

    Betroffene<\/h2>\n\n\n\n

    Nach einer Mitteilung der Cybersecurity and Infrastructure Security Agency (CISA) sollte davon ausgegangen werden, dass alle Systeme und Hosts, die von der Orion-Software \u00fcberwacht werden, kompromittiert wurden. Wird zudem festgestellt oder vermutet, dass Identit\u00e4ten auf einem System kompromittiert wurden, kann eine vollst\u00e4ndige Wiederherstellung von Identit\u00e4ts- und Vertrauensdiensten erforderlich sein. [44] [24]<\/p>\n\n\n\n

    Dass der Angriff ein Ausma\u00df von globaler Bedeutung hat wird klar, wenn man eine auf Telemetriedaten der Defender Anti-Virus-Software von Microsoft basierende Karte betrachtet. Sie zeigt, welche der Kunden, die Defender benutzen, eine kompromittierte Orion-Version genutzt haben. In einem Bericht von Microsoft vom 17.12.2020 ist die Rede von 40 Kunden, die dar\u00fcber in Kenntnis gesetzt wurden, dass sie Opfer der gezielten Angriffe wurden. Tendenz steigend. Hier stellt sich die Frage, ob man \u00fcberhaupt davon ausgehen kann, dass die Angreifer in jedem System gefunden und entfernt werden k\u00f6nnen, oder ob die ein oder andere Stelle \u00fcbersehen wird? Die zuvor aufgezeigte Komplexit\u00e4t des Angriffs und die lange Zeit, die die Angreifer in den Systemen verbringen konnten, gibt zu denken. Wer hinter einem so detailliert geplanten Angriff steckt und dabei viel Wert darauf gelegt hat, unentdeckt zu bleiben, k\u00f6nnte sicherlich noch immer leicht \u00fcbersehen werden. So w\u00e4re es denkbar, dass die SolarWinds Attacke auch in Zukunft noch Schaden anrichtet. [41]<\/p>\n\n\n\n

    \"\"<\/a>
    Verteilung der kompromittierten Orion-Versionen <\/em>[41]<\/figcaption><\/figure><\/div>\n\n\n\n

    Besorgniserregend ist zudem, welche Sektoren von dem Angriff betroffen sind: Der IT-Sektor (mitunter Sicherheitsfirmen), Abteilungen der Regierung wie Finanzen, Nationale Sicherheit, Gesundheit und Telekommunikation, sowie Organisationen, die Verteidigung und nationale Sicherheit unterst\u00fctzen. [41]<\/p>\n\n\n\n

    Beispiele hierf\u00fcr sind das U.S. Handels-, Energie- und Finanzministerium, das Justizministerium und die Verwaltungsstelle der U.S.-Gerichte, auf deren Systemen TEARDROP gefunden wurde. F\u00fcr Schlagzeilen sorgte auch, dass der interne Mailverkehr des U.S. Treasury and Commerce Departments als Folge des Angriffs von Hackern \u00fcberwacht werden konnte. In einem der j\u00fcngsten Berichte ist von 27 US-Staatsanwaltschaften die Rede, bei denen Microsoft Office 365-E-Mail-Konten von Mitarbeitenden geknackt wurden. Dies beinhaltet gesendete, erhaltene und gespeicherte Mails mitsamt Anh\u00e4ngen. Besonders betroffen scheinen B\u00fcros in den Distrikten New Yorks, bei denen sich zu mindestens 80% der Konten der Mitarbeitenden Zugang verschafft wurde. [25] [22] [10]<\/p>\n\n\n\n

    Gegenma\u00dfnahmen<\/h2>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Als Reaktion auf den Angriff haben sowohl SolarWinds als auch andere Firmen und Organisationen Ressourcen zur Verf\u00fcgung gestellt, zum einen Gegenma\u00dfnahmen, zum anderen Allgemeines wie Security Best Practices (siehe weiterf\u00fchrende Links<\/em>). <\/p>\n\n\n\n

    FireEye beispielsweise stellt auf einer \u00f6ffentlichen GitHub Seite ihnen bekannte Signaturen bereit und beschreibt, wie Kompromittierungen entdeckt werden k\u00f6nnen. Seitens Microsoft kam ebenfalls Unterst\u00fctzung, indem sie die Dom\u00e4ne avsvmcloud[.]com <\/em>\u00fcbernommen und zu einem \u201cKillswitch\u201d umgebaut haben. [9] [23]<\/p>\n\n\n\n

    SolarWinds hat zudem mit einem neuen digitalen Zertifikat betroffene Software-Versionen neu signiert und ihr altes Zertifikat widerrufen. Betroffene Software-Builds wurden inzwischen entfernt. Ein Upgrade auf die neuesten Versionen der Orion-Plattform wird stark empfohlen, sollte dies nicht m\u00f6glich sein, steht ein Skript zum tempor\u00e4ren Schutz der Umgebung bereit. Weiterhin wird darauf hingewiesen, die Orion-Plattform hinter einer Firewall zu platzieren, Internetzugriff daf\u00fcr zu verbieten und Ports und Verbindungen nur auf das N\u00f6tigste zu limitieren. Man sollte meinen letzteres m\u00fcsste ohnehin als Sicherheitsstandard in den Firmen gelten. Ein extra entwickeltes \u201cOrion Assistance Program\u201d soll Kunden unterst\u00fctzen, \u201cprovided at no charge\u201d, wie so sch\u00f6n darauf hingewiesen wird. Es w\u00e4re auch zu ironisch, wenn der Kunde hier noch zur Kasse gebeten w\u00fcrde. [44]<\/p>\n\n\n\n

    Was kaum angesprochen wird ist die Frage, was mit den gestohlenen Daten passiert und welche Auswirkungen dies haben k\u00f6nnte. Folgen daraus wom\u00f6glich weitere, noch ausgekl\u00fcgeltere Angriffe? Ebenso wird kaum angesprochen, wie lange es dauern k\u00f6nnte, bis sich Betroffene von so einem Angriff erholen. Sowohl SolarWinds, das zus\u00e4tzlich mit verlorenem Vertrauen zu k\u00e4mpfen hat, als auch Kunden, die wom\u00f6glich einiges an Zeit und Geld investieren m\u00fcssen, um ihre Systeme zu \u00fcberpr\u00fcfen, haben erheblichen Schaden erlitten. Ein Artikel der Associated Press spricht von Monaten, die es brauchen wird, um die Angreifer aus den US-Regierungsnetzwerken zu entfernen. Es m\u00fcsse davon ausgegangen werden, dass es in nicht klassifizierten Netzwerken von Spionen wimmelt. [2]<\/p>\n\n\n\n\n\n\n\n

    ein Artikel von Verena Eichinger, Amelie Kassner und Elisa Zeller<\/em><\/p>\n\n\n\n

    Schutz vor Supply Chain Attacks<\/strong><\/h1>\n\n\n\n

    Nun stellt sich also die Frage: was tun gegen diese vielf\u00e4ltige Gefahr, die von der Lieferkette oder besser, ihren Sicherheitsl\u00fccken droht?<\/p>\n\n\n\n

    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Zum Schutz vor SCAs geben verschiedene Unternehmen und Organisationen Vorschl\u00e4ge, welche Sicherheitsvorkehrungen man treffen kann. Unter ihnen sind Microsoft, Google und auch Anbieter von Security Software, wie UpGuard oder Ekran. <\/p>\n\n\n\n

    Die Ma\u00dfnahmen sind vielf\u00e4ltig und teilweise \u00fcberschneiden sie sich, daher wird hier ein \u00dcberblick \u00fcber einige Beispiele gegeben.<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Die komplexen Netzwerke von Lieferketten machen den Schutz vor SCAs nicht gerade einfach, einzelne Ma\u00dfnahmen gen\u00fcgen nicht. Nur ein Zusammenspiel mehrerer Ma\u00dfnahmen bietet wirksamen Schutz.<\/p>\n\n\n\n

    Im Allgemeinen gilt f\u00fcr Softwareanbieter und -entwickler, eine hochsichere Build- und Update-Infrastruktur bereitzustellen. Dazu z\u00e4hlt bei Ver\u00f6ffentlichung sofort Sicherheitspatches f\u00fcr Software und Betriebssystem zu installieren. Au\u00dferdem n\u00f6tig sind fortlaufende Integrit\u00e4tskontrollen, sodass sichergestellt ist, dass nur vertrauensw\u00fcrdige Software l\u00e4uft, und Multifaktorauthentifizierung f\u00fcr Administratoren. Auch sichere Software-Updater und Entwicklungszyklen aufzubauen ist essenziell. Hierf\u00fcr sollten SSL f\u00fcr die Update-Kan\u00e4le und Certificate Pinning<\/em> genutzt, alles signiert – auch Konfigurationsfiles, Skripte, Pakete, etc. – und digitale Signaturen gepr\u00fcft werden. Au\u00dferdem empfiehlt es sich, einen Incident-Response-Prozess<\/em> f\u00fcr SCAs zu entwickeln, sowie regelm\u00e4\u00dfig Software zu testen und Codereviews durch andere Mitarbeiter durchf\u00fchren zu lassen. [28] [53]<\/p>\n\n\n\n

    Zum Schutz der eigenen Infrastruktur muss man sich bez\u00fcglich SCAs erst einmal der Gefahr bewusst werden. Dabei hilft zum Beispiel das Assume Breach Mindset<\/em>, bei dem davon ausgegangen wird, dass es auf jeden Fall fr\u00fcher oder sp\u00e4ter zu einem erfolgreichen Angriff kommt. Diese Annahme erfordert ein Umdenken hin zu einer aktiven Verteidigungsstrategie. Daraus kann die Implementierung einer Zero Trust Architecture<\/em> (ZTA) folgen. Sie basiert auf der Sichtweise \u201cdie Welt ist b\u00f6se, man kann niemandem trauen!\u201d Jede Netzwerkaktivit\u00e4t k\u00f6nnte potentiell gef\u00e4hrlich sein. Daher werden Verbindungsanfragen nur angenommen, wenn sie strengen Richtlinien folgen. Google hat mit BeyondCorp<\/em> ein eigenes Zero-Trust-Modell entwickelt. Richtlinien sind ein weiteres wichtiges Stichwort: Sie sollten zur Sicherheit der Infrastruktur und der Produkte existieren und jeder muss sich daran halten. Diesbez\u00fcglich k\u00f6nnte man sich k\u00fcnftig ebenfalls an Google orientieren. Dort wird ein eigenes Set von Security Guidelines zum Schutz vor SCAs entwickelt, genannt Supply chain Levels for Software Artifacts<\/em>, kurz SLSA. Es soll aus vier Stufen bestehen, SLSA 1 ist bereits entwickelt. Mehr dazu findet sich unter den weiterf\u00fchrenden Links.<\/p>\n\n\n\n

    Auch was Hardware betrifft, sollten strenge Sicherheitsregeln beachtet werden. Stichwort Shadow IT<\/em> – Technische Ger\u00e4te, die nicht von der IT-Abteilung gepr\u00fcft oder freigegeben wurden. Ein wichtiger Punkt in Zeiten, in denen Arbeit im Homeoffice zunehmend h\u00e4ufiger wird. Alle Ger\u00e4te, die ans System angeschlossen werden, m\u00fcssen den strengen IT Richtlinien folgen und zudem \u00fcberwacht werden. [21] [53] [11]<\/p>\n\n\n\n

    Besondere Aufmerksamkeit liegt auf dem Zugang zu sensiblen Daten und Ressourcen, also potentiellen Zielen von Angreifern. Dazu ist es n\u00fctzlich, diese erst einmal als sensibel zu identifizieren. Hierf\u00fcr k\u00f6nnen zum Beispiel Honeytokens<\/em> implementiert werden. Sie sollen sich als wertvolle Information tarnen und damit interessant f\u00fcr Eindringlinge erscheinen. Wird dann von einem Angreifer auf die unechte Ressource zugegriffen, wird ein Signal aktiviert, welches das Unternehmen vor verd\u00e4chtigen Vorg\u00e4ngen im Netz warnt. So wird deutlich, welche Ressourcen bevorzugt anvisiert werden. Dadurch ist es m\u00f6glich, sie zu isolieren und eine effektive Antwort f\u00fcr die Angriffsstrategie zu erarbeiten. Ohnehin Zugang zu Daten und Ressourcen haben entsprechende Accounts im System. Daher m\u00fcssen sie gepr\u00fcft und \u00fcberwacht werden. Vor allem privilegierte Accounts, von denen auf sensible Informationen zugegriffen werden kann. Um sie zu sch\u00fctzen, kann Privileged Access Management<\/em>, kurz PAM, genutzt werden. F\u00fcr ein zuverl\u00e4ssiges PAM Framework m\u00fcssen alle privilegierten Accounts und diejenigen, die sie nutzen, identifiziert werden. Um sie zus\u00e4tzlich zu sichern, kann das Principle of least privilege<\/em> eingesetzt werden. Das hei\u00dft der privilegierte Zugang hat gerade so viele Rechte, wie f\u00fcr eine Aufgabe n\u00f6tig ist, die mit ihm erf\u00fcllt werden soll. Zudem k\u00f6nnen die Accounts auch zeitlich limitiert werden, sodass sie nur so lange bestehen, wie sie n\u00f6tig sind. Die bestehenden privilegierten Accounts sollten dann \u00fcberwacht werden, um ungew\u00f6hnliche Vorkommnisse festzuhalten. Im Optimalfall werden diese Vorg\u00e4nge automatisiert, sodass das Framework skalierbar ist und menschliches Versagen vermieden wird. Damit das funktioniert, muss das Framework zus\u00e4tzlich von au\u00dfen und innen gesch\u00fctzt werden. Umgesetzt wird das beispielsweise durch Aufkl\u00e4ren von Personal, damit es nicht Opfer von Phishing oder \u00e4hnlichen Attacken wird. Au\u00dferdem durch Finden und Beheben von Datenlecks, wie zuvor genannt dem Verwenden von Multifaktorauthentifizierung mit Security Keys oder \u00c4hnlichem und dem Verschl\u00fcsseln von Daten. Diese zus\u00e4tzlichen Schutzma\u00dfnahmen helfen auch sich direkt gegen SCAs zu verteidigen. [21]<\/p>\n\n\n\n

    PAM ist nicht prim\u00e4r dazu gedacht einer SCA vorzubeugen, sondern kann sie lediglich abschw\u00e4chen. Dieses Framework ist sehr anf\u00e4llig f\u00fcr Insiderbedrohungen, weshalb diese ebenfalls minimiert werden m\u00fcssen. Man sollte dabei beachten, dass nicht alles, was ein Risiko darstellen k\u00f6nnte, aus b\u00f6ser Absicht unternommen wird. Daher ist es auch hierf\u00fcr essentiell, Mitarbeiter aufzukl\u00e4ren. Au\u00dferdem lohnt es sich, regelm\u00e4\u00dfig Feedback von Angestellten einzuholen, sowie eine offene und unterst\u00fctzende Arbeitskultur zu pflegen. Das beugt dem Risiko f\u00fcr feindlich gesinnte Insiderbedrohungen vor, die oftmals schwer auszumachen sind. [21][8]<\/p>\n\n\n\n

    Eine weitere M\u00f6glichkeit zum Schutz sensibler Systeme ist ein sogenanntes Walled Garden Ecosystem<\/em>. Dabei werden nur eigene oder zuvor festgelegte Applikationen erlaubt. Auch generell ist es sinnvoll die Apps einzuschr\u00e4nken, die ein Nutzer verwenden darf.<\/p>\n\n\n\n

    Um bereits vorhandenen Schadcode zu entdecken gibt es verschiedene Tools. Zum Beispiel arbeiten auch GitHub und GitLab an L\u00f6sungen daf\u00fcr. GitLab entwickelt den Package Hunter<\/em>, der Schadcode oder unerwartetes Verhalten in Dependencies eines Programms entdecken soll. GitHub erweitert derweil einige Security Features auf Go Modulen, um die Supply Chain besser zu sichern. Mit Endpoint detection und response<\/em> (EDR) L\u00f6sungen k\u00f6nnen ebenfalls verd\u00e4chtige Aktivit\u00e4ten automatisch gefunden und behoben werden. [30] [28]<\/p>\n\n\n\n

    Doch wie bereits zuvor dargestellt, ist bei einer SCA die eigene Systemsicherheit nicht das Einzige, das z\u00e4hlt. Zulieferer sind die eigentliche Schwachstelle im Bezug auf SCAs. Es ist daher sinnvoll, nicht nur das eigene System zu betrachten, sondern auch das aller Zulieferer. Um zu pr\u00fcfen, wie ernst die einzelnen Unternehmen Sicherheit nehmen, sollten regelm\u00e4\u00dfig Risikobewertungen der Unternehmen erstellt werden. Mit Frageb\u00f6gen kann ermittelt werden, wie es bei ihnen um die Sicherheit bestellt ist. Diese k\u00f6nnen selbst erstellt werden oder man verwendet Vorlagen von einem vertrauensw\u00fcrdigen Anbieter. Im besten Fall nutzt man auch noch ein Security Rating System<\/em> f\u00fcr die einzelnen Zulieferer. Au\u00dferdem bietet es sich gegebenenfalls an, Drittanbieter zu \u00fcberwachen. Hierf\u00fcr gibt es beispielsweise Softwarel\u00f6sungen von UpGuard oder Ekran. Oder die Orion Plattform von SolarWinds, wenn man diese denn nutzen m\u00f6chte. Ob man nun externe \u00dcberwachungssoftware verwenden m\u00f6chte oder nicht, sei mal dahin gestellt. Schlie\u00dflich ist sie ebenso Software von Drittanbietern wie die, die sie \u00fcberwacht. [21]<\/p>\n\n\n\n

    Accounts, die von externen Unternehmen ins eigene System f\u00fchren, sollten ebenfalls gesondert gesichert und gepr\u00fcft werden. Es muss klar sein, wof\u00fcr sie genutzt werden, wie sie gesch\u00fctzt werden und ob sie \u00fcberhaupt n\u00f6tig sind. Auch Honeytokens k\u00f6nnen bei Zulieferern implementiert werden und es empfiehlt sich, Datenlecks bei diesen automatisiert zu identifizieren. [21]<\/p>\n\n\n\n

    Insgesamt helfen also mehrere Ma\u00dfnahmen zusammen, darunter auch solche wie Multifaktorauthentifizierung, Zugangsbeschr\u00e4nkungen, das Personal zu unterweisen, Antivirensoftware… Kurz gesagt also viele Dinge, die sinnvoll f\u00fcr den Schutz vor jeglicher Art von Cyberangriff sind. Einige davon sollten eigentlich selbstverst\u00e4ndlich f\u00fcr gr\u00f6\u00dfere Software-Unternehmen sein. An solche richten sich die genannten Schutzma\u00dfnahmen vornehmlich. Im Endeffekt helfen also gegen die vermeintlich neuen, schrecklichen SCAs dieselben altbekannten Ma\u00dfnahmen, die Sicherheitsexperten mittlerweile seit Jahrzehnten predigen.<\/p>\n\n\n\n

    Und was k\u00f6nnen wir selbst, am Ende der Lieferkette tun? Nun, leider nicht sehr viel. Dem Privatnutzer bleibt nichts \u00fcbrig als weiter den Updates und Services zu vertrauen und regelm\u00e4\u00dfig Daten offline zu sichern. Schlie\u00dflich hat man keinen Einblick in die Sicherheitsma\u00dfnahmen einzelner Firmen, geschweige denn einen \u00dcberblick \u00fcber alle Komponenten, die in einem Produkt oder Service stecken. Man kann sich lediglich daran orientieren, wer bereits gehackt wurde und diese Anbieter meiden, doch das gibt auch keinen Aufschluss \u00fcber die Sicherheit anderer Produkte. Den Endnutzer entsprechend zu sch\u00fctzen w\u00e4re Aufgabe der Regierungen mit entsprechenden Vorschriften f\u00fcr Unternehmen. Und diese werden auch zunehmend dringender, wie uns der Angriff auf Kaseya zeigt. Denn dieser geht weg von wenigen gro\u00dfen Firmen hin zu vielen kleinen. Wie lange wird es dauern, bis normale Privatnutzer zum Ziel werden?<\/p>\n\n\n\n

    Und da sind wir bei einer weiteren Frage. Wer ist verantwortlich f\u00fcr eine SCA? Nat\u00fcrlich in erster Linie die Angreifer. Doch das ist nur die eine H\u00e4lfte der Wahrheit, wie Schneier in seinem Blog darstellt. In der modernen Marktwirtschaft ist Profit am wichtigsten und am besten m\u00f6glichst viel davon. Das bedeutet, um erfolgreich zu sein, muss ein Unternehmen viel kurzzeitigen Profit machen und Kosten einsparen wo es nur geht. Und als erstes wird alles, was man im Moment nicht unbedingt braucht, wegrationalisiert. Wie Sicherheitspersonal. Oder Sicherheitsvorkehrungen f\u00fcr Dinge, die vielleicht eventuell irgendwann mal passieren k\u00f6nnten. Oder vielleicht auch nicht, wer wei\u00df das schon. Und dann sind ja die Angreifer schuld. Im Endeffekt f\u00fchrt also die Funktionsweise der Wirtschaft dazu, dass es sich f\u00fcr Unternehmen mehr lohnt, unsichere Produkte und Services zu verkaufen. Damit wird das Risiko von Cyberattacken zu einem hohen Ma\u00df auf den Endkunden abgeschoben. [37]<\/p>\n\n\n\n

    Es gibt also zwei Probleme mit der Sicherheit: Erstens k\u00f6nnen K\u00e4ufer schlecht beurteilen, wie sicher ein Softwareprodukt oder die Prozesse des zugeh\u00f6rigen Unternehmens sind. Und zweitens die Funktion des Marktes, die Firmen dazu bringt, Entscheidungen in eigenem Interesse zu treffen, auch wenn das Risiko damit auf ihre Kunden abgew\u00e4lzt wird. Der einzige Weg diese beiden Probleme aus der Welt zu schaffen: Minimale Security Standards f\u00fcr Software und ihre Entwicklung m\u00fcssen gesetzlich festgeschrieben werden. So wie Vorschriften f\u00fcr Umweltverschmutzung oder Arbeitsrecht. Im besten Fall geschieht das auch noch international. Daran arbeitet beispielsweise das Consortium for Information and Software Quality<\/em>, kurz CISQ. Dessen Ziel ist es, internationale Standards zu entwickeln, um Messung von Softwarequalit\u00e4t zu automatisieren und die Entwicklung und Erhaltung von sicherer, zuverl\u00e4ssiger und vertrauensw\u00fcrdiger Software voranzubringen. Darunter ist beispielsweise der ISO 5055 Standard f\u00fcr automatische Source Code Qualit\u00e4tsmessungen f\u00fcr Zuverl\u00e4ssigkeit, Sicherheit, Performance Effizienz und Wartbarkeit von Software. [4] [6]<\/p>\n\n\n\n

    Au\u00dferdem wird derzeit an einer Regelung f\u00fcr eine Software Bill of Materials<\/em> (SBOM) gearbeitet. Also eine Materialliste, die eine \u00dcbersicht \u00fcber die Rohmaterialien und die einzelnen Komponenten, aus denen die Software besteht, gibt. Hier w\u00fcrde beispielsweise auch verwendete Open Source Software aufgelistet. So kann der Ursprung der Software ermittelt werden, sowie Prozesse und Entscheidungen, die sie in ihrer Erstellung durchlaufen hat. Also eine Art Bauteilliste f\u00fcr Software, die der Kunde sich dann ansehen kann, um zu entscheiden, ob die Software qualitativ und sicherheitstechnisch seinen Anspr\u00fcchen gen\u00fcgt. Zudem sorgt die SBOM daf\u00fcr, dass es keine Unbekannten mehr in der Risikobetrachtung gibt, sofern tats\u00e4chlich l\u00fcckenlos dokumentiert wird was in ein Produkt einflie\u00dft. Dies ist Stand heute nicht immer der Fall. Und schlie\u00dflich kann man nur Dinge patchen, von denen man auch wei\u00df, dass sie eingebaut wurden. [5]<\/p>\n\n\n\n\n\n\n\n

    ein Artikel von Verena Eichinger, Amelie Kassner und Elisa Zeller<\/em><\/p>\n\n\n\n

    Fazit<\/strong><\/h1>\n\n\n\n

    Wenn wir die bisherigen Betrachtungen Revue passieren lassen, d\u00fcrfte wohl klar sein, welch immense Bedrohung die SCAs darstellen. SolarWinds und Kaseya haben es im Vergleich zu anderen Cyberangriffen geschafft, im gro\u00dfen Stil das Interesse der breiten Bev\u00f6lkerung zu wecken. Kaseya hat dabei deutlich gemacht, wie einfach die globale Verbreitung von Attacken \u00fcber die Lieferkette funktioniert und wie nah derartige Angriffe der Bev\u00f6lkerung kommen. SolarWinds dagegen wird wohl als Aush\u00e4ngeschild der SCAs in die Geschichte eingehen. Die Sch\u00e4den, die der Vorfall langanhaltend auch in Beh\u00f6rden angerichtet hat und die Komplexit\u00e4t, die die Aufarbeitung zutage gef\u00f6rdert hat, zeigen, wozu Angreifer f\u00e4hig sind. Das l\u00e4sst auch erahnen, wozu Angreifer in Zukunft f\u00e4hig sein werden und welches Ausma\u00df k\u00fcnftige Attacken erreichen k\u00f6nnten.<\/p>\n\n\n\n

    Im Blick auf die Gegenma\u00dfnahmen trifft man anschlie\u00dfend auf viele alte Bekannte. Da k\u00f6nnte man sich doch fragen, was all die sch\u00f6nen Ma\u00dfnahmen nutzen, wenn sie dann doch wieder eingespart und nicht gewissenhaft umgesetzt werden. Verfolgt man die Nachrichten zum Thema IT-Security, so hat man nicht gerade das Gef\u00fchl, dass etwas passiert. Man liest von Attacken, die \u00fcber Sicherheitsl\u00fccken erfolgten, die schon seit Jahren keine Neuigkeit mehr sind, und Multifaktorauthentifizierung scheint f\u00fcr viele immer noch ein Fremdwort zu sein. Ist ja schlie\u00dflich so umst\u00e4ndlich, wenn man da jetzt zwei Sachen braucht, um sich anzumelden. Und selbst wenn es derartige Ma\u00dfnahmen gibt, so finden sich, wie man bei Kaseya sieht, Wege, diese zu umgehen. Was machen also die Angreifer anders als die Firmen, dass sie solche L\u00fccken erkennen, die hoffentlich bei der Entwicklung stattfindenden Tests aber nicht? Vielleicht investieren sie einfach mehr Zeit. Vielleicht w\u00fcrde sich ja gerade das auch f\u00fcr die Firmen lohnen. Solange das Risiko die Kunden tragen und nicht man selbst, wird \u00fcber solch gewagte Thesen vermutlich nur gelacht. Schlie\u00dflich zeigt das k\u00fcrzlich diskutierte Lieferkettengesetz recht sch\u00f6n, wie bereit die Industrie dazu ist, mehr zu investieren zum Wohl Anderer, n\u00e4mlich gar nicht. In dem Fall ging es zwar um Menschenrechte – welch dreiste Forderung, mit Menschenrechten verdient man schlie\u00dflich kein Geld – allerdings sind die Aussichten, dann f\u00fcr die IT-Sicherheit etwas zu erreichen wohl doch eher d\u00fcster.<\/p>\n\n\n\n

    Die dahinterstehende Problematik versteckt sich also weiterhin irgendwo als Sicherheitsl\u00fccke in der Lieferkette und kann jederzeit zur Bedrohung werden. Und genau dieser Punkt ist es, an dem umgedacht werden muss. Ist es tats\u00e4chlich so, dass die Bedrohung erst noch entsteht, oder liegt sie nicht viel mehr schon ganz real vor, wenn es \u00fcberhaupt eine Sicherheitsl\u00fccke gibt? Interessant ist hierbei auch, dass ausgenutzte Sicherheitsl\u00fccken oft im Voraus schon bekannt waren. Woran scheitert es also, dass Angriffe \u00fcber solche L\u00fccken dennoch erfolgreich sind? Ohne Standards und gesetzliche Regelungen scheint man an dieser Stelle nicht weiter zu kommen.<\/p>\n\n\n\n

    Somit ist der Kunde oder Nutzer dem Ganzen hilflos ausgeliefert. Um auf die zu Beginn gestellten Fragen zur\u00fcckzukommen, wissen wir n\u00e4mlich nicht was alles in den Produkten steckt, die wir nutzen, und wer dazu Zugang hatte. Wir wissen nicht, ob f\u00fcr Software die wir nutzen mit vertrauensw\u00fcrdigen Bibliotheken gearbeitet wurde und diese stets aktuell gehalten und vor allem auch gepr\u00fcft wurden. Wir k\u00f6nnen uns auch nicht sicher sein, dass Softwareupdates sicher sind, woher sollten wir all diese Informationen auch nehmen?<\/p>\n\n\n\n

    Als Kunden wissen wir nicht einmal, welche Sicherheitsrisiken auf uns abgew\u00e4lzt werden und doch m\u00fcssen wir im Ernstfall die Konsequenzen tragen. Bisher hatten wir als Bev\u00f6lkerung das \u201cGl\u00fcck\u201d, dass sich derartige Angriffe gegen Firmen gerichtet haben. Es ist allerdings eher eine Frage von \u201cwann\u201d und nicht \u201cob\u201d Endverbraucher auch Ziel solcher Angriffe werden. Mit Kaseya ging der Schritt bereits weg von wenigen gro\u00dfen Zielen hin zu m\u00f6glichst vielen Kleinen. Viele geringe Erpressungs-Zahlungen ergeben schlie\u00dflich auch eine Menge Geld. Damit w\u00e4re der Schritt hin zur Erpressung von Privatpersonen nur logisch. Wer hier vorbeugen m\u00f6chte, sollte eine gute Backup Routine einrichten, um nicht erpressbar zu sein. Ironischerweise ist auch das eine Sicherheitsma\u00dfnahme, die ohnehin jeder in seinen Alltag integrieren sollte und wieder einmal nichts Neues. Also holen Sie sich einen Kaffee, starten Sie ihr n\u00e4chstes Backup und warten Sie gemeinsam mit uns auf die n\u00e4chste Schlagzeile zu Supply Chain Attacks, denn eines ist sicher: die wird es geben.<\/p>\n\n\n\n\n\n\n\n

    ein Artikel von Verena Eichinger, Amelie Kassner und Elisa Zeller<\/em><\/p>\n\n\n\n

    Weiterf\u00fchrende Links<\/strong><\/h1>\n\n\n\n