ein Artikel von Verena Eichinger, Amelie Kassner und Elisa Zeller

Schutz vor Supply Chain Attacks

Nun stellt sich also die Frage: was tun gegen diese vielfältige Gefahr, die von der Lieferkette oder besser, ihren Sicherheitslücken droht?

Zum Schutz vor SCAs geben verschiedene Unternehmen und Organisationen Vorschläge, welche Sicherheitsvorkehrungen man treffen kann. Unter ihnen sind Microsoft, Google und auch Anbieter von Security Software, wie UpGuard oder Ekran.

Die Maßnahmen sind vielfältig und teilweise überschneiden sie sich, daher wird hier ein Überblick über einige Beispiele gegeben.

Die komplexen Netzwerke von Lieferketten machen den Schutz vor SCAs nicht gerade einfach, einzelne Maßnahmen genügen nicht. Nur ein Zusammenspiel mehrerer Maßnahmen bietet wirksamen Schutz.

Im Allgemeinen gilt für Softwareanbieter und -entwickler, eine hochsichere Build- und Update-Infrastruktur bereitzustellen. Dazu zählt bei Veröffentlichung sofort Sicherheitspatches für Software und Betriebssystem zu installieren. Außerdem nötig sind fortlaufende Integritätskontrollen, sodass sichergestellt ist, dass nur vertrauenswürdige Software läuft, und Multifaktorauthentifizierung für Administratoren. Auch sichere Software-Updater und Entwicklungszyklen aufzubauen ist essenziell. Hierfür sollten SSL für die Update-Kanäle und Certificate Pinning genutzt, alles signiert – auch Konfigurationsfiles, Skripte, Pakete, etc. – und digitale Signaturen geprüft werden. Außerdem empfiehlt es sich, einen Incident-Response-Prozess für SCAs zu entwickeln, sowie regelmäßig Software zu testen und Codereviews durch andere Mitarbeiter durchführen zu lassen. [28] [53]

Zum Schutz der eigenen Infrastruktur muss man sich bezüglich SCAs erst einmal der Gefahr bewusst werden. Dabei hilft zum Beispiel das Assume Breach Mindset, bei dem davon ausgegangen wird, dass es auf jeden Fall früher oder später zu einem erfolgreichen Angriff kommt. Diese Annahme erfordert ein Umdenken hin zu einer aktiven Verteidigungsstrategie. Daraus kann die Implementierung einer Zero Trust Architecture (ZTA) folgen. Sie basiert auf der Sichtweise “die Welt ist böse, man kann niemandem trauen!” Jede Netzwerkaktivität könnte potentiell gefährlich sein. Daher werden Verbindungsanfragen nur angenommen, wenn sie strengen Richtlinien folgen. Google hat mit BeyondCorp 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üglich könnte man sich künftig ebenfalls an Google orientieren. Dort wird ein eigenes Set von Security Guidelines zum Schutz vor SCAs entwickelt, genannt Supply chain Levels for Software Artifacts, kurz SLSA. Es soll aus vier Stufen bestehen, SLSA 1 ist bereits entwickelt. Mehr dazu findet sich unter den weiterführenden Links.

Auch was Hardware betrifft, sollten strenge Sicherheitsregeln beachtet werden. Stichwort Shadow IT – Technische Geräte, die nicht von der IT-Abteilung geprüft oder freigegeben wurden. Ein wichtiger Punkt in Zeiten, in denen Arbeit im Homeoffice zunehmend häufiger wird. Alle Geräte, die ans System angeschlossen werden, müssen den strengen IT Richtlinien folgen und zudem überwacht werden. [21] [53] [11]

Besondere Aufmerksamkeit liegt auf dem Zugang zu sensiblen Daten und Ressourcen, also potentiellen Zielen von Angreifern. Dazu ist es nützlich, diese erst einmal als sensibel zu identifizieren. Hierfür können zum Beispiel Honeytokens implementiert werden. Sie sollen sich als wertvolle Information tarnen und damit interessant für Eindringlinge erscheinen. Wird dann von einem Angreifer auf die unechte Ressource zugegriffen, wird ein Signal aktiviert, welches das Unternehmen vor verdächtigen Vorgängen im Netz warnt. So wird deutlich, welche Ressourcen bevorzugt anvisiert werden. Dadurch ist es möglich, sie zu isolieren und eine effektive Antwort für die Angriffsstrategie zu erarbeiten. Ohnehin Zugang zu Daten und Ressourcen haben entsprechende Accounts im System. Daher müssen sie geprüft und überwacht werden. Vor allem privilegierte Accounts, von denen auf sensible Informationen zugegriffen werden kann. Um sie zu schützen, kann Privileged Access Management, kurz PAM, genutzt werden. Für ein zuverlässiges PAM Framework müssen alle privilegierten Accounts und diejenigen, die sie nutzen, identifiziert werden. Um sie zusätzlich zu sichern, kann das Principle of least privilege eingesetzt werden. Das heißt der privilegierte Zugang hat gerade so viele Rechte, wie für eine Aufgabe nötig ist, die mit ihm erfüllt werden soll. Zudem können die Accounts auch zeitlich limitiert werden, sodass sie nur so lange bestehen, wie sie nötig sind. Die bestehenden privilegierten Accounts sollten dann überwacht werden, um ungewöhnliche Vorkommnisse festzuhalten. Im Optimalfall werden diese Vorgänge automatisiert, sodass das Framework skalierbar ist und menschliches Versagen vermieden wird. Damit das funktioniert, muss das Framework zusätzlich von außen und innen geschützt werden. Umgesetzt wird das beispielsweise durch Aufklären von Personal, damit es nicht Opfer von Phishing oder ähnlichen Attacken wird. Außerdem durch Finden und Beheben von Datenlecks, wie zuvor genannt dem Verwenden von Multifaktorauthentifizierung mit Security Keys oder Ähnlichem und dem Verschlüsseln von Daten. Diese zusätzlichen Schutzmaßnahmen helfen auch sich direkt gegen SCAs zu verteidigen. [21]

PAM ist nicht primär dazu gedacht einer SCA vorzubeugen, sondern kann sie lediglich abschwächen. Dieses Framework ist sehr anfällig für Insiderbedrohungen, weshalb diese ebenfalls minimiert werden müssen. Man sollte dabei beachten, dass nicht alles, was ein Risiko darstellen könnte, aus böser Absicht unternommen wird. Daher ist es auch hierfür essentiell, Mitarbeiter aufzuklären. Außerdem lohnt es sich, regelmäßig Feedback von Angestellten einzuholen, sowie eine offene und unterstützende Arbeitskultur zu pflegen. Das beugt dem Risiko für feindlich gesinnte Insiderbedrohungen vor, die oftmals schwer auszumachen sind. [21][8]

Eine weitere Möglichkeit zum Schutz sensibler Systeme ist ein sogenanntes Walled Garden Ecosystem. Dabei werden nur eigene oder zuvor festgelegte Applikationen erlaubt. Auch generell ist es sinnvoll die Apps einzuschränken, die ein Nutzer verwenden darf.

Um bereits vorhandenen Schadcode zu entdecken gibt es verschiedene Tools. Zum Beispiel arbeiten auch GitHub und GitLab an Lösungen dafür. GitLab entwickelt den Package Hunter, 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 (EDR) Lösungen können ebenfalls verdächtige Aktivitäten automatisch gefunden und behoben werden. [30] [28]

Doch wie bereits zuvor dargestellt, ist bei einer SCA die eigene Systemsicherheit nicht das Einzige, das zählt. 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üfen, wie ernst die einzelnen Unternehmen Sicherheit nehmen, sollten regelmäßig Risikobewertungen der Unternehmen erstellt werden. Mit Fragebögen kann ermittelt werden, wie es bei ihnen um die Sicherheit bestellt ist. Diese können selbst erstellt werden oder man verwendet Vorlagen von einem vertrauenswürdigen Anbieter. Im besten Fall nutzt man auch noch ein Security Rating System für die einzelnen Zulieferer. Außerdem bietet es sich gegebenenfalls an, Drittanbieter zu überwachen. Hierfür gibt es beispielsweise Softwarelösungen von UpGuard oder Ekran. Oder die Orion Plattform von SolarWinds, wenn man diese denn nutzen möchte. Ob man nun externe Überwachungssoftware verwenden möchte oder nicht, sei mal dahin gestellt. Schließlich ist sie ebenso Software von Drittanbietern wie die, die sie überwacht. [21]

Accounts, die von externen Unternehmen ins eigene System führen, sollten ebenfalls gesondert gesichert und geprüft werden. Es muss klar sein, wofür sie genutzt werden, wie sie geschützt werden und ob sie überhaupt nötig sind. Auch Honeytokens können bei Zulieferern implementiert werden und es empfiehlt sich, Datenlecks bei diesen automatisiert zu identifizieren. [21]

Insgesamt helfen also mehrere Maßnahmen zusammen, darunter auch solche wie Multifaktorauthentifizierung, Zugangsbeschränkungen, das Personal zu unterweisen, Antivirensoftware… Kurz gesagt also viele Dinge, die sinnvoll für den Schutz vor jeglicher Art von Cyberangriff sind. Einige davon sollten eigentlich selbstverständlich für größere Software-Unternehmen sein. An solche richten sich die genannten Schutzmaßnahmen vornehmlich. Im Endeffekt helfen also gegen die vermeintlich neuen, schrecklichen SCAs dieselben altbekannten Maßnahmen, die Sicherheitsexperten mittlerweile seit Jahrzehnten predigen.

Und was können wir selbst, am Ende der Lieferkette tun? Nun, leider nicht sehr viel. Dem Privatnutzer bleibt nichts übrig als weiter den Updates und Services zu vertrauen und regelmäßig Daten offline zu sichern. Schließlich hat man keinen Einblick in die Sicherheitsmaßnahmen einzelner Firmen, geschweige denn einen Überblick über 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 über die Sicherheit anderer Produkte. Den Endnutzer entsprechend zu schützen wäre Aufgabe der Regierungen mit entsprechenden Vorschriften für Unternehmen. Und diese werden auch zunehmend dringender, wie uns der Angriff auf Kaseya zeigt. Denn dieser geht weg von wenigen großen Firmen hin zu vielen kleinen. Wie lange wird es dauern, bis normale Privatnutzer zum Ziel werden?

Und da sind wir bei einer weiteren Frage. Wer ist verantwortlich für eine SCA? Natürlich in erster Linie die Angreifer. Doch das ist nur die eine Hälfte der Wahrheit, wie Schneier in seinem Blog darstellt. In der modernen Marktwirtschaft ist Profit am wichtigsten und am besten möglichst 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ür Dinge, die vielleicht eventuell irgendwann mal passieren könnten. Oder vielleicht auch nicht, wer weiß das schon. Und dann sind ja die Angreifer schuld. Im Endeffekt führt also die Funktionsweise der Wirtschaft dazu, dass es sich für Unternehmen mehr lohnt, unsichere Produkte und Services zu verkaufen. Damit wird das Risiko von Cyberattacken zu einem hohen Maß auf den Endkunden abgeschoben. [37]

Es gibt also zwei Probleme mit der Sicherheit: Erstens können Käufer schlecht beurteilen, wie sicher ein Softwareprodukt oder die Prozesse des zugehörigen 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älzt wird. Der einzige Weg diese beiden Probleme aus der Welt zu schaffen: Minimale Security Standards für Software und ihre Entwicklung müssen gesetzlich festgeschrieben werden. So wie Vorschriften für Umweltverschmutzung oder Arbeitsrecht. Im besten Fall geschieht das auch noch international. Daran arbeitet beispielsweise das Consortium for Information and Software Quality, kurz CISQ. Dessen Ziel ist es, internationale Standards zu entwickeln, um Messung von Softwarequalität zu automatisieren und die Entwicklung und Erhaltung von sicherer, zuverlässiger und vertrauenswürdiger Software voranzubringen. Darunter ist beispielsweise der ISO 5055 Standard für automatische Source Code Qualitätsmessungen für Zuverlässigkeit, Sicherheit, Performance Effizienz und Wartbarkeit von Software. [4] [6]

Außerdem wird derzeit an einer Regelung für eine Software Bill of Materials (SBOM) gearbeitet. Also eine Materialliste, die eine Übersicht über die Rohmaterialien und die einzelnen Komponenten, aus denen die Software besteht, gibt. Hier würde 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ür Software, die der Kunde sich dann ansehen kann, um zu entscheiden, ob die Software qualitativ und sicherheitstechnisch seinen Ansprüchen genügt. Zudem sorgt die SBOM dafür, dass es keine Unbekannten mehr in der Risikobetrachtung gibt, sofern tatsächlich lückenlos dokumentiert wird was in ein Produkt einfließt. Dies ist Stand heute nicht immer der Fall. Und schließlich kann man nur Dinge patchen, von denen man auch weiß, dass sie eingebaut wurden. [5]

Pages: 1 2 3 4 5 6 7