Wenn das Wort Supply-Chain-Angriff zu hören ist, wird es Manchen gerade im Rückenmark zucken und die Cyber-Angriffe auf Solarwinds (Dezember 2020) sowie auf Kaseya (Juli 2021) ins Gedächtnis rufen. Diese beiden Angriffe stehen exemplarisch für sogenannte Lieferketten-Angriffe – auch Supply-Chain-Attacken (aus dem Englischen) genannt. In diesem Blogbeitrag erläutern wir die Herausforderungen im Umgang mit Lieferketten und zeigen Ihnen Wege auf, wie Sie sich schützen können. Wir machen dies, indem wir etablierte Standards zu Rate ziehen und daraus spezifische Empfehlungen ableiten.
Was sagen die etablierten Standards
Um den Herausforderungen auf den Grund zu gehen, werfen wir einen Blick in die etablierten Standards. Wie stehen diese zum Thema Supply Chain. Wir beginnen mit dem IKT-Grundschutz [1] der Schweiz. Er legt die minimalen, organisatorischen, personellen und technischen Sicherheitsvorgaben im Bereich Informatiksicherheit für die schweizerische Bundesverwaltung fest. Er kann also auch für KMUs als Mindeststandard verwendet werden. Hier muss das Wort fast mit der Lupe gesucht werden. Es wird verlangt, dass mindestens die ganze Lieferkette in der Dokumentation jedes «Informatikschutzobjektes» angegeben ist.
Einen Schritt weiter geht der Mindeststandard BSI IT-Grundschutz [2] unserer deutschen Nachbarn. Der BSI IT‐Grundschutz verfolgt einen ganzheitlichen Ansatz, der sowohl das Sicherheitsmanagement wie auch konkrete Sicherheitsanforderungen umfasst. Der IT-Grundschutz stellt eine spezifische Checklist «Outsourcing und Cloud» zur Verfügung und beinhaltet sechs Fragen. Die Checkliste ist für jede Form des Outsourcings (z.B. Fachanwendung, IT-Infrastruktur oder personelle Outsourcing) einmal anzuwenden.
Noch mehr Anforderungen an die Lieferkette stellt der ISO-27001/02 Standard. Es gibt zwei Annexe, welche die Lieferkette explizit ansprechen. Annex 5.21 («Managing information security in the information and communication technology (ICT) supply chain») listet 13 Punkte (Punkt a. bis m.) auf, welche bei Prozessen und Prozeduren im Zusammenhang mit der Supply Chain definiert und implementiert werden sollen. Annex 8.30 «Outsourced development» listet 11 Punkte auf (Punkt a. bis k.), um ausgelagerte Softwareentwicklung zu überwachen und zu Überprüfen. Daneben wird generell und immer mal wieder hinzugefügt, dass dies natürlich auch für ausgelagerte Dienstleistungen gilt.
Das NIST Cybersecurity Framework [3] nimmt ausserordentlich Bezug auf das Thema Supply Chain. Das NIST Cybersecurity Framework (NIST CSF) besteht aus Standards, Richtlinien und Best Practices, die Unternehmen dabei helfen, ihr Management von Cyber-Sicherheitsrisiken zu verbessern. Bereits in der Einleitung auf Seite IV steht «Building on previous versions, Cybersecurity Framework 2.0 contains new features that highlight the importance of governance and supply chains.». Das Framework unterteilt die Cybersecurity in sechs Domänen – sie nennen es “Functions”: Govern, Identify, Protect, Detect, Response und Recover. Dabei ist in der Function “Govern” eine Kategorien explizit für die Lieferkette bestimmt: «Cybersecurity Supply Chain Risk Management» (GV.SC). Zusätzlich gibt es eine weitere Unterkategorie in der Funktion «Identify» und «ID.RA-10: Critical suppliers are assessed prior to acquisition (ID.RA)». Somit adressieren ca. 10% der Anforderungen (11 von 106 Unterkategorien) direkt die Supply Chain.
Noch weiter geht DORA. DORA (Digital Operational Resilience Act) ist zwar kein Standard, sondern eine ca. 80-seitige Verordnung der EU (2022/2554). Mit ihr schafft die EU eine Regulierung über die digitale operationale Resilienz im Finanzsektor. Sie beinhaltet Themen wie Cyber-Sicherheit, IKT-Risiken und digitale operationale Resilienz. Generell muss man sich nicht mit der Finanzindustrie vergleichen. Als Indikation für die Zukunft macht es aber durchaus Sinn, auch kurz in DORA zu schnuppern. In den 106-punktigen Erwägungen der Gründe ist die fehlende Kontrolle von Zulieferern ein omnipräsentes Thema (siehe dazu Punkt 27 und Folgende). Unter Punkt 31 steht unter anderem «… Auch wenn mit der gruppeninternen Bereitstellung von IKT-Dienstleistungen spezifische Risiken und Vorteile einhergehen, sollte sie nicht automatisch als weniger riskant angesehen werden als die Bereitstellung von IKT-Dienstleistungen durch Dienstleister ausserhalb einer Finanzgruppe und sollte daher demselben Rechtsrahmen unterliegen…». Der Rechtsakt geht eigentlich so weit, dass von IKT-Dienstleister für kritische Services – was auch immer das heissen mag – ebenfalls sämtliche DORA-Anforderungen eingehalten werden müssen und diese quasi einer „Aufsicht light“ unterstellt werden.
Der Trend des zunehmenden Outsourcings und Cloud-Computings hat also Auswirkungen auf Cybersecurity-Standards sowie auf nationale und internationale Regulierungsbehörden. Bereits jetzt und in naher sowie ferner Zukunft wird vermehrt gefordert, dass die Risiken im Zusammenhang mit der Supply Chain besser identifiziert und konkrete Massnahmen zur Reduzierung dieser Risiken implementiert werden.
Hier liegt der Hase im Pfeffer
Bei der Analyse des NIST Cybersecurity Framework zeigt sich, dass Anforderungen eigentlich nur in der Funktion «Govern» und «Identify» spezifisch auf die Supply Chain eingehen. In den Funktionen «Protect», «Response» und «Recover» finden sich keine Unterkategorien, die explizit für Outsourcing oder Cloud-Computing vorgesehen sind. Es wird lediglich unter «Implementation Examples» erwähnt, dass dies auch auf «3rd Parties» angewendet werden soll. Wieso ist das aber so? Der Grund dafür ist, dass man im Bereich Supply Chain oft nur bedingt Kontrolle ausüben kann. Eine Ausnahme bilden Dienstleistungen, welche in der eigenen IKT-Umgebung stattfinden. Hier kann man die Sicherheit mittels der selbst implementierten Sicherheitsmassnahmen kontrollieren. Wenn man aber einen ganzen Service oder eine Software-Komponente extern bezieht, sind einem bezüglich der Funktion «Protect» die Hände gebunden. Theoretisch kann man vor Vertragsunterzeichnung die Bedingungen aushandeln. In der Praxis ist aber auch hier der Spielraum begrenzt. Und selbst wenn man die „richtigen“ Bedingungen ausgehandelt hat, ist das Erzwingen der Erfüllung der Bedingungen immer noch nicht möglich. Selbst nur schon das Kontrollieren (Umsetzen des Audit-Rechts) ist in der Praxis schwierig.
Wir erkennen, dass wir bei einem ausgelagerten Service eigentlich kaum einen Einfluss auf die «Protection» – und somit auch auf das Schutzniveau – nehmen können. Gibt es aber nicht doch Cybersecurity-Stellschrauben, an denen wir drehen können? Doch, das gibt es. Auch hier gibt uns das NIST CSF die Antwort. Über die Funktionen «Detect», «Response» und «Recovery» können wir indirekt das Schutzniveau erhöhen. Wir können Einsicht in das Monitoring und das Logging sowie relevante Alarme über mangelhafte Verfügbarkeit, Vertraulichkeit oder Integrität (CIA) verlangen. Wir können die Anwendung entsprechender Massnahmen bei CIA-Verletzung voraussetzen oder beispielsweise Tests für ein funktionierendes Recovery einfordern. Dann erhöht sich auch automatisch das Schutzniveau des Service.
Nun wissen wir also, weshalb neuere Standards die Supply Chain praktisch nur in der Domäne «Govern» und «Identify» direkt ansprechen. Wir müssen aber nicht besorgt sein. Sie decken trotzdem die gesamte Supply Chain ab, sofern wir auch für Services/Software-Komponenten die Funktion «Detect», «Respond» und «Recover» implementieren.
Gibt es Quick-Wins?
Das klingt jetzt sehr nüchtern und man stellt sich die Frage, ob es denn keine Quick-Wins gibt. Also Massnahmen, die die Sicherheit sofort erhöhen. Die gibt es natürlich auch für Supply-Chain-Angriffe. Zum einen hilft ein Privileged Access Management, um Services, Software-Komponenten und Betreiber nur mit den minimalen Rechten auszustatten. Auch ist ein Dark- und Deep-Web-Monitoring in vielen Fällen sinnvoll, insbesondere wenn man auf viele Zulieferer angewiesen ist. Dabei werden im Dark- und Deep-Web angebotene, kompromittiere Zugangsdaten und andere interne oder geheime Informationen nach Zulieferern durchsucht. Dies hilft, kompromittierte Zulieferer zu erkennen. Und als letzte Linie der Verteidigung schützt eine 24/7-Reaktionsfähigkeit bei der Bewältigung von Sicherheitsvorfällen vor Supply-Chain-Angriffen. Egal, wie ausgeklügelt der Angriff ausgeführt wird, Alarme treten in der Regel immer auf, wenn Endpoint-, Identity- und Network-Threat-Detection-Lösungen flächendeckend aktiv sind. Und dann gilt es, so schnell wie möglich zu reagieren.
Quo Vadis – Roadmap gegen Supply Chain Angriffe
Wie sehen nun aber mittel- bis langfristige Massnahmen aus? In einer ersten Stufe sollen die Abhängigkeiten zu Zulieferern dokumentiert werden. Dies wird ja auch in den Mindeststandards gefordert. In mittlerer und ferner Zukunft wird dies aber bei weitem nicht mehr genügen. Daher sollten wir uns bereits heute Gedanken machen, wie wir diese Risiken besser managen, aber auch besser kontrollieren und steuern können. Wir empfehlen einen Schritt weiter zu gehen und das Thema Supply Chain zentral in der Cybersecurity-Methodik zu verankern. Hierzu bietet sich das NIST CSF an (andere moderne Standards verwenden ja analoge Funktionen/Domänen). In der Funktion «Govern» kann direkt das NIST CSF – oder eine abgespeckte Version – verwendet werden, um Risiken zu identifizieren. Zudem empfehlen wir für die Funktion «Identify», die Dokumentation der IKT-Umgebung mit einer «Supplier View» zu ergänzen. Sie zeigt auf, welche externen Dienstleistungen von welchen externen Dienstleistern erbracht werden. Optimalerweise werden auch zusätzliche Eigenschaften wie die Kritikalität des Services, definierte RTOs (Recovery Time Objectives), Eskalationskontakte etc. beigefügt. Wer im Finanzsektor, als Zulieferer im Finanzsektor oder einer ähnlichen Branche tätig ist, sollte noch einen Schritt weitergehen. Für jeden Service und jede Software-Komponenten sollten Sicherheitsalarme implementiert und eine entsprechende Response definiert werden, je nach Schweregrad. Zudem sollten ausführliche Reports eingefordert werden. Parallel dazu sollten die oben beschriebenen Quick Wins (Privileged Access Management, Dark- und Deep-Web-Monitoring, 24/7-Verfügbarkeit) in Betracht gezogen werden. Dies hängt individuell davon ab, wie gross die Abhängigkeit von externen Dienstleistern ist.
Lackmustest der Empfehlungen
Diese Empfehlungen unterziehen wir nun einem Test. Hätten die Empfehlungen uns vor den Angriffen aus der Einleitung geschützt? Bei der Solarwinds-Attacke hätten die Empfehlungen wahrscheinlich nichts genützt. Die Attacke wurde von einem Nation-State-Angreifer durchgeführt. Dabei ging man extrem defensiv vor, sodass keine verdächtige Aktivitäten Alarme auslösten. Allerdings hatte ein Sicherheitsforscher bereits 2019 das FTP-Passwort für den Update-Server auf Github gefunden und die Unternehmung darüber informiert. Man hatte jedoch keine Massnahmen ergriffen. Ein Dark- und Deep-Web-Monitoring hätte dies höchstwahrscheinlich entdeckt. Auch bei der Kaseya-Attacke hätte es nicht gross anders ausgesehen. Die Ransomware-Gang REvil hat die VSA-SaaS-Applikation von Kaseya im Juli 2020, mittels Zero-Day-Exploits angegriffen und kompromittiert. Allerdings waren auch Kaseya die Schwachstellen seit März 2020 bekannt.
Bei beiden Angriffen handelt es sich jedoch um Spezialfälle. Bei beiden Attacken war eine Software-Komponente betroffen, welche für das Verwalten der Endpunkte verantwortlich ist. Die Software benötigte somit fast maximale Privilegien und praktisch sämtliche Aktivitäten waren erlaubt. Bei beiden Attacken waren Hunderte von Mandanten betroffen und nirgends wurden verdächtige oder maliziöses Aktivitäten detektiert. Dies zeigt einmal mehr, dass es 100% Sicherheit nicht gibt.
Summa Summarum
Der Blick in die bestehenden Standards zeigt uns auf, dass Risiken in Zusammenhang mit der Lieferkette zunehmen und besser adressiert werden müssen. Lasst uns das anpacken. Schritt für Schritt. Auch gemeinsam. Wir unterstützen sie gerne dabei. Kommen Sie gerne auf uns zu.
Referenzen
Links
https://www.avantec.ch/loesungen/beyondtrust/privilege-management/
https://www.avantec.ch/services/cyber-defense-center/#darkweb
https://www.avantec.ch/services/cyber-defense-center/#vulnerability-mgmt
