Es ist auch wichtig zu berücksichtigen, ob es sich bei den Kunden um Anbieter oder Endanwender handelt. Die jüngsten Angriffe auf die Lieferkette deuten darauf hin, dass Anbieter nun auch ins Visier geraten können, wenn sie Dienstleistungen oder Software für Kunden bereitstellen, die selbst im Mittelpunkt eines Angriffs stehen.
Dies war bei den SolarWinds-Angriffen der Fall: Hier waren US-Regierungsorganisationen die Angriffsziele, und die Angreifer nutzten SolarWinds als Mittel, um sich Zugang zu diesen hochkarätigen Zielen zu verschaffen. Darüber hinaus könnten raffiniertere Ransomware-Angriffe häufiger auftreten, die auf Anbieter von Managed Services und deren Kunden abzielen.
So nutzte eine Angreifergruppe kürzlich Zero-Day-Schwachstellen in Kaseya VSA, während andere Akteure versuchen, den Erfolg von NotPetya zu wiederholen. Wenn Forschungsteams also Schwachstellen in Software entdecken, die in die Lieferketten vieler Anbieter integriert ist, dann ist es wichtig, alle nachgelagerten Softwareprojekte, Dienste und Kunden, die betroffen sein könnten, zu ermitteln und zu benachrichtigen.
Schlussfolgerungen: Was nun geschehen muss
Es liegt auf der Hand: Will die Branche als Ganzes widerstandsfähig gegen Angriffe auf die Lieferkette werden und ihre Kundschaft schützen, muss jeder Anbieter damit beginnen, Sicherheit als unabdingbar zu betrachten. Dies gilt nicht nur für seine eigenen Produkte, sondern auch für die Produkte, Komponenten und Dienstleistungen, die er von Dritten erwirbt.
Jeder Anbieter muss Maßnahmen ergreifen, um seine eigene Sicherheitslage zu verbessern, und seine Zulieferer dazu verpflichten, dasselbe zu tun. Dies senkt das Risiko in der Lieferkette und ermöglicht gleichzeitig eine schnelle und gründliche Reaktion bei Vorfällen. Noch wichtiger ist jedoch, dass die Anbieter durch diese Art gezielter Verbesserungen ihrer Sicherheitsprozesse die Verpflichtungen gegenüber ihren Kunden eher erfüllen können.
Immer komplexere Entwicklungsprojekte
Moderne Softwareprojekte sind zunehmend komplex, die Abhängigkeit von Frameworks Dritter, Open-Source-Software und gemeinsam genutzten Bibliotheken nimmt zu. Daher ist es wichtig, dass Unternehmen nach Möglichkeit ein umfassendes Inventar ihrer Softwarelieferketten führen, eine sogenannte „Software Bill of Materials“ (SBOM). Dies ist laut der US-Behörde NTIA (National Telecommunications and Information Administration) eine „formale Aufzeichnung, die die Details und Lieferkettenbeziehungen der verschiedenen Komponenten enthält, die bei der Erstellung von Software zum Einsatz kommen“.
Die NTIA unterhält dazu eine spezielle Seite, die darstellt, wie Unternehmen SBOMs erstellen und pflegen können und welche Herausforderungen dabei zu bewältigen sind. Dies könnte eine nützliche Ressource für jeden Anbieter sein, der seine eigene SBOM implementieren will.SBOMs sollten maschinenlesbar, daher leicht zugänglich und für das Schwachstellen-Management nutzbar sein.
Zudem wird die Einhaltung vorhersehbarer und gut strukturierter Datenformate den Anbietern die gemeinsame Nutzung ihrer SBOMs ermöglichen. Während die Standards, die zur Definition dieses Prozesses beitragen könnten, noch in Arbeit sind, stellt die NTIA in ihrem Dokument „Sharing and Exchanging SBOMs“ einige potenziell nützliche Bausteine vor. Wie die NTIA in der Einleitung zu dem Dokument feststellt, „ermöglicht die Transparenz in der Lieferkette sowohl den Anbietern als auch den Nutzern von Software eine bessere Risikoentscheidung“.
Blick in die Zukunft - Zusammenarbeit erforderlich
Einer der positiven Aspekte der zunehmenden Zahl von Cybersicherheitsvorfällen und -angriffen im Zusammenhang mit der Lieferkette ist die erhöhte Aufmerksamkeit von Anbietern, Experten und Gesetzgebern. Infolgedessen bringt die gesamte Branche neue Ideen ein, bildet Führungsgremien und schafft neue Richtlinien und Verfahren, die darauf abzielen, Sicherheitsprobleme zu entschärfen, die sich aus der Komplexität moderner Lieferketten ergeben. Um dieses branchenweite Problem zu lösen, ist die Zusammenarbeit aller Beteiligten – Hersteller, Anbieter und Sicherheitsforscher – erforderlich. Es gilt, die Schwierigkeiten bei der Meldung von Schwachstellen in gemeinsam genutzten Softwarebibliotheken zu überwinden und bei allen betroffenen Produkten zu beheben.
Evan Grant ist Staff Research Engineer bei Tenable.