US-Präsident erlässt Verordnung zu Cybersicherheit: Welche Security-Anforderungen sieht sie im Kontext der Software-Lieferkette vor?

Mit seiner Verordnung zur Stärkung der Cybersicherheit ging US-Präsident Biden am 12. Mai 2021 einen wichtigen, angesichts der diversen ihr vorangehenden Meldungen aber wenig überraschenden Schritt. Denn letztlich kann sie als Reaktion auf eine Kette schwerwiegender Incidents gewertet werden, die mit dem SolarWinds-Hack begann und im Ransomware-Angriff auf Colonial Pipeline einen weiteren Höhepunkt erreichte, war dieser doch einer der bislang massivsten seiner Art auf einen Energieversorger des Landes.

Viele der jüngsten Angriffe standen zudem im Zusammenhang mit der Software-Lieferkette. Umso weniger überrascht es also, dass sich ihre Absicherung also quasi durchgängig durch die Verordnung zieht – zumal der SolarWinds-Hack nicht nur von geradezu historischem Ausmaß war, sondern auch eine ganze Reihe höchster Stellen der US-Regierung in seinem Wirkungsradius lagen. Betroffen waren etwa das Pentagon und Außenministerium, außerdem das Ministerium für Heimatschutz. Dazu kamen aber auch diverse Unternehmen aus dem privaten Sektor wie Microsoft, Intel oder Cisco. Kein Wunder also, dass Sicherheit in der Software-Lieferkette inzwischen stärker ins Blickfeld rückt.

Andererseits steht die Software-Lieferkette tatsächlich schon seit Langem im Visier von Angreifern. Snyk etwa stellt die diversen mit modernen Konzepten der Software-Entwicklung verbundenen Komponenten bereits seit 2018 als schwaches Glied in der Lieferkette heraus, durch das Entwickler selbst zum potenziellen Vehikel für die Ausbreitung von Malware werden. Die Software von heute ist zudem noch weitaus tiefgreifender von diesen Konzepten geprägt. Entsprechend attraktivere Angriffsziele sind damit auch die zugrunde liegenden Strukturen geworden. Diesen Entwicklungen und Risiken trägt Präsident Bidens Verordnung Rechnung, sieht dazu unter Federführung des US-Handelsministerium strikte Regulierungen für Software-Anbieter vor, die diese an Stellen der US-Regierung ausliefern.  

Wodurch sind Angriffe auf die Software-Lieferkette charakterisiert?

Entscheidend bei einem Angriff auf die Software-Lieferkette ist, dass die Drahtzieher darauf abzielen, Schadcode in ein nachgelagertes Ziel innerhalb des komplexen Gefüges der zugrunde liegenden Komponenten einzuschleusen. Die Lieferkette selbst ist jedoch nicht das eigentliche Ziel, sondern vielmehr das Sprungbrett, über das Malware weiter verbreitet oder ein Backdoor für weitere Aktionen eingerichtet wird. So etwa auch beim Angriff auf SolarWinds, bei dem es Hackern gelang, sich Zugang zur Plattform für Netzwerk und Anwendungs-Monitoring namens Orion des Software-Dienstleisters zu verschaffen. Über Updates mit schädlichen Versionen der Plattform waren sie dann der Lage, Tausende ihrer Nutzer zu infizieren.

Extrem effektiv also, und ein Paradebeispiel dafür, warum moderne Konzepte der Software-Entwicklung die zugehörige Lieferkette als Angriffsvektor so attraktiv machen. Denn Planung, Materialbeschaffung, Fertigung und Verkauf – die klassischen Elemente industrieller Lieferketten – sind im Software-Kontext genau die gleichen. Nur besteht das Material dabei eben aus Code. Dieser Code kann durchaus proprietär sein und von den Entwicklern der jeweiligen Software stammen. Ein immer größerer Teil wird jedoch aus kommerziellen oder Open-Source-Quellen bezogen – Abhängigkeiten, über die potenziell schädlicher Code in die Software gelangen kann. So liegt modernen Software-Lieferketten heute ein immer komplexeres Geflecht aus Prozessen zugrunde, die allesamt höchst effektive Verbreitungswege für Malware bilden können.

Vorgaben der US-Regierung zur Absicherung von Software-Lieferketten

Einige der wichtigsten Säulen der präsidialen Verordnung bildet die Modernisierung der Cybersecurity-Methodiken der US-Regierung insgesamt. Hierzu gehören auch der verstärkte Austausch und die engere Zusammenarbeit mit dem privaten Sektor in diesem Kontext sowie strengere Sicherheitsanforderungen an die Software-Bezugsquellen des öffentlichen Sektors. Ganz explizit adressiert wird zudem das Risiko im Zusammenhang mit Angriffen auf die Software-Lieferkette. Hierzu ist direkt zu Beginn von Abschnitt 4 Folgendes zu lesen:

Kommerzieller Software fehlt es häufig an Transparenz bezüglich ihren Entwicklungsstrukturen. Ihrer Widerstandsfähigkeit gegenüber Angriffen wird nicht hinreichend Aufmerksamkeit beigemessen, außerdem mangelt es an adäquaten Kontrollen zur Unterbindung von Manipulationen durch böswillige Akteure. Stringentere, stärker vorausschauende Mechanismen sind daher dringend vonnöten, um gewährleisten zu können, dass entsprechende Produkte sicher und ihrem Zweck entsprechend funktionieren. \[...] Daher sind dringend staatlich gesteuerte Maßnahmen auf den Weg zu bringen, die schnell zur Stärkung der Sicherheit und Integrität der Software-Lieferkette beitragen.

Zur Mitigierung dieser Risiken für Regierungsstellen nimmt die Verordnung das National Institute of Standards and Technology (NIST) in die Pflicht. Von ihm erwartet werden Best Practices, Leitlinien und Kriterien für künftige Standards mit Anwendbarkeit für Software-Anbieter, die ihre Produkte an US-Behörden verkaufen möchten.

Software-BOM

Wie bereits erwähnt, wird im Vergleich mit Komponenten von Drittanbietern oder der Open-Source-Community nur noch ein relativ geringer Anteil des Codes heutiger Software intern entwickelt. Diesen Status quo adressiert die Verordnung mit ihren Anforderungen an mehr Transparenz dazu, woraus sich Software genau zusammensetzt. Hierzu sieht sie die Erfassung sämtlicher Komponenten in einer Software Bill of Materials (SBOM) vor, um die mit ihnen verbundenen Risiken besser abmildern zu können.  

Sichere Dev-Umgebung

Software-Lieferanten müssen die Sicherheit der Umgebung nachweisen, die sie zur Entwicklung einsetzen. Gemäß Verordnung soll das NIST hierzu Kriterien erarbeiten, nach denen Sicherheit im Kontext von Dev-Umgebungen definiert ist. Zentrale Elemente hiervon bilden sichere Build-Prozesse und Datenverschlüsselung, Audit-Strukturen und Authentifizierung sowie Incident-Monitoring und -Management.

Sichere Dev-Prozesse

Ferner gelten Vorgaben zu Methodiken sicherer Entwicklung, deren Umsetzung Software-Anbieter ebenfalls nachweisen müssen. Speziell geht es dabei um automatisierte Security-Tests sowohl in den Frühphasen als auch im weiteren Verlauf der Entwicklung, um so die Integrität des Codes gewährleisten und Schwachstellen proaktiv aufdecken und beheben zu können. Zum Nachweis entsprechender Maßnahmen sind auf Anfrage sogenannte „Artefakte“ beizubringen, außerdem muss die Anwendung entsprechender Tools und Prozesse belegt werden.

Open-Source-Integrität

Zwischen 80 und 90 % des Codes einer Anwendung entfallen heute auf Open-Source-Komponenten. Dem trägt die Verordnung Rechnung, indem sie Software-Anbieter dazu verpflichtet, „Integrität und Ursprung jedweder in einem Produkt verwendeten Open-Source-Software nachweislich zu gewährleisten“.

Stärkung der Sicherheit in der Software-Lieferkette

Den ersten Ansatzpunkt für mehr Sicherheit in der Software-Lieferkette und entsprechend auch für die vom NIST vorgesehen Standards bildet grundsätzlich die Absicherung von Anwendungen. Snyk bietet hierzu eine cloudnative Plattform, die Anwendungssicherheit direkt auf Entwicklerseite umsetzbar macht – und damit auch die Erfüllung nahezu sämtlicher Vorgaben der Verordnung.

Developer Empowerment

Praktikabel sind die gemäß Verordnung umzusetzenden Methodiken zur sicheren Entwicklung nur, wenn sie sich auf unkomplizierte Weise in Dev-Workflows einpassen lassen. Denn schließlich sind es die Entwickler selbst, bei denen genau diese Prozesse beginnen: Sie entscheiden, nach welchen Grundsätzen sie Anwendungen entwickeln, sind also auch direkt für Integrität, Qualität und Sicherheit des zugrunde liegenden Codes verantwortlich. Nach konventionellen Methodiken greift Security jedoch erst in den Spätphasen des SDLC. Hierdurch aber entstehen Reibungsverluste aufgrund wenig intuitiver Workflows, die mit der Dynamik heutiger Dev-Umgebungen schlicht nicht mehr Schritt halten können.

Snyk dagegen gibt Entwicklern Tools an die Hand, mit denen sie Sicherheit unkompliziert in den Dev-Prozess einpassen und zugleich adäquate Anleitung durch das Security-Team erhalten können. Dabei ist die Snyk Plattform so konzipiert, dass sämtliche der ihr zugehörigen Tools die UX gängiger Dev-Toolkits in einer Weise abbilden, die Entwickler nicht in ihrer Arbeit ausbremsen.

SDLC-übergreifend automatisierte Sicherheit

Zur Gewährleistung der Software-Integrität sieht die Verordnung eine frühestmögliche Implementierung automatischer Security-Scans innerhalb des SDLC vor, dies „in regelmäßigem Turnus oder zumindest vor der Veröffentlichung des Produkts, einer neuen Version oder eines Updates desselben“. Snyk bietet hierfür neben einem breiten Spektrum an Integrationen auch die Möglichkeit, Security-Tests über die Snyk API automatisiert in die verschiedenen Phasen des SDLC einzubringen. Dies beginnt bereits in der lokalen Dev-Umgebung, setzt sich in Git-basierten Workflows fort und zieht sich vom Build-Vorgang bis in die Produktion durch. 

Code-Sicherheit für sämtliche Elemente moderner Software

Abgebildet werden in der Verordnung nicht zuletzt auch die Entwicklungen im Hinblick auf den Aufbau des Codes heutiger Anwendungen. Denn zum proprietären Code und Open-Source-Paketen gesellen sich in modernen Software-Lieferketten auch noch Container und der Code zur Definition der zugrunde liegenden Cloud-Infrastruktur (Infrastructure as Code).

Um die mit diesen Elementen jeweils verbundenen Risikoprofile handhaben zu können, braucht es einen ganzheitlichen Ansatz für die Sicherheit von Anwendungen. Wer also einzig auf Verfahren rund um Static Application Security Testing (SAST) setzt, die nur intern vom Dev-Team geschriebenen Code abzusichern vermögen, trägt den Risiken im Zusammenhang mit Open-Source-Tools und Containern keine Rechnung. Umgekehrt wiederum würde Software Composition Analysis (SCA) allein eine Lücke beim proprietären Code hinterlassen. Deshalb vereint Snyk sämtliche Testverfahren in einer umfassenden Plattform mit Developer-Fokus, die es Entwicklern wie Unternehmen einfach macht, alle Code-Elemente moderner Software stark abzusichern.

Reporting auf Ebene einzelner Komponenten

Wie bereits ausgeführt, steht Transparenz im Mittelpunkt der meisten Anforderungen der Verordnung, dies einerseits im Hinblick auf Security-Prozesse und -Maßnahmen, andererseits betreffend der einer Software zugrunde liegenden Komponenten, die in einer SBOM festzuhalten sind. Snyk deckt all dies durch umfassende Reporting-Features ab, mittels derer sich eine Software-BOM ebenso einsehen und exportieren lässt wie verschiedenste andere Berichte. So lassen sich via Snyk API etwa auch externe Tools für Reporting und Schwachstellen-Management integrieren und durchgängig automatisiertes Security- und Compliance-Monitoring umsetzen.

Nächste Schritte

Gemäß Verordnung ist vorgesehen, dass das NIST binnen sechs Monaten vorläufige Leitlinien vorlegt, die innerhalb eines Jahres zu finalisieren sind.  Per se richten sich die Vorgaben zwar nur an potenzielle Software-Bezugsquellen der US-Regierung. Allerdings ist davon auszugehen, dass sie sich sukzessive auch im privaten Sektor etablieren und im Software-Markt als Ganzes Einzug halten werden.

Daher empfiehlt sich bereits jetzt ein genauer Blick auf die Vorgaben, um festzustellen, ob diesen entsprechend potenzielle Schwachpunkte in Ihrer bestehenden Software-Lieferkette bestehen.

Über sämtliche Entwicklungen rund um die neuen Standards halten wir Sie in unserem Blog auf dem Laufenden. Denn tatsächlich arbeiten wir aktiv mit dem NIST zusammen, um sicherzustellen, dass unsere Lösungen die Vorgaben optimal erfüllen, dies insbesondere auch mit unserer SBOM SIG zur Erstellung einer Software-BOM.

Sie möchten mehr über unsere Zusammenarbeit mit Regierungsstellen und darüber erfahren, wie wir sie bei der Erfüllung der Anforderungen dieser Verordnung unterstützen? Senden Sie eine E-Mail an snyk_federal@snyk.io oder besuchen Sie unsere Seite zu Snyk for Government.