Das Secure Software Development Framework des NIST Warum SSDF auch außerhalb der USA relevant ist

Anbieter zum Thema

SYNOPSYS GmbH

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Windhoff Group

Im Secure Software Development Framework, kurz SSDF, empfiehlt das US National Institute of Standards and Technology einige Best-Practices für sichere Software-Lieferketten. Auch wenn das Framework den Fokus auf die Vereinigten Staaten legt, so ist es doch auch andernorts von Bedeutung.

Mit dem SSDF gibt das National Institute of Standards and Technology (NIST) Unternehmen ein Rahmenwerk an die Hand, um die Vorgaben der US-Regierung für die Sicherheit der Lieferketten besser erfüllen und umsetzen zu können. Dabei geht es insbesondere um die Executive Order 14028 und das Memorandum M-22-18 und die daraus resultierenden Nachweispflichten.

Zusätzlich soll das Framework die Bewertung, das Design und die Umsetzung von Programmen zur Softwareentwicklung unterstützen – und zwar derart, dass bei sämtlichen Prozessen, Verfahren, Werkzeugen und hinsichtlich der Lieferanten, die an der Software-Entwicklung beteiligt sind, Sicherheitsüberlegungen und -kontrollen integriert werden.

Dabei sollte man nicht außer Acht lassen, dass diese erwartete Nutzung gegebenenfalls in weitere Anbieterbeziehungen hineinreicht oder ausgelagerte Entwicklungsverfahren betroffen sind. Soll eine Software in einer stark regulierten Umgebung genutzt werden, muss also nicht nur das betreffende Unternehmen selbst die entsprechenden Normen erfüllen.

Nun wurde das SSDF von der NIST primär für die USA entwickelt. Es hat aber über den engeren geografischen Anwendungsbereich hinaus durchaus praktische Relevanz für andere Länder.

Weithin anwendbare Praktiken für sichere Softwareentwicklung

Das SSDF, wie es derzeit in Version 1.1 des „NIST SP 800-218“- Dokuments definiert ist, besteht aus 42 sogenannten Tasks, die sich auf 19 praktische Empfehlungen verteilen und wie folgt in vier Gruppen zusammengefasst sind:

1. Prepare the Organization (PO) (Vorbereitung des Unternehmens) – An dieser Stelle gilt es, die notwendigen programmunterstützenden Grundlagen zu schaffen, damit ein Unternehmen Mitarbeiter, Prozesse und Technologien für eine sichere Entwicklung in allen Bereichen bereitstellen kann.

2. Protect the Software (PS) (Schutz der Software) – Absicherung der produzierten Software und der zugehörigen Artefakte sowie nachweisliche Transparenz innerhalb der Lieferkette und weitere mehr.

3. Produce Well-Secured Software (PW) (Herstellung gut abgesicherter Software) – Sichere SDLC-Prozesse und -Werkzeuge, Durchführung von Maßnahmen und Tests hinsichtlich der Softwaresicherheit usw.

4. Respond to Vulnerabilities (RV) (Reaktion auf Schwachstellen) – Risiken senken, Probleme adressieren, Disclosure-Prozesse unterstützen usw.

Wer bereits mit dem SSDF vertraut ist, erkennt schnell, dass die in diesen Gruppen behandelten Themen für so gut wie jedes Unternehmen tauglich sind, das mit Software-Entwicklung befasst ist. Immer eingedenk dessen, dass diese bewährten Praktiken auch für Firmen gelten, die lediglich Software von anderen Parteien erwerben.

Letztendlich sollen die im SSDF ausgeführten Praktiken den Sicherheitslevel grundsätzlich erhöhen, aber auch das Bewusstsein für die Sicherheit von Softwareprodukten, Artefakten, der Entwicklungsinfrastruktur sowie der Produktions- und Beschaffungsprozesse schärfen – und zwar in allen Unternehmensbereichen. Dies dient einerseits der Softwaresicherheit als solcher und andererseits dem damit verbundenen Management von Governance, Risiken und Compliance.

Sichere Software-Entwicklung nicht nur in den USA

Software- und Cybersicherheits-Risikomanagement, Standardisierung und Governance sind auf der Prioritätenliste ganz nach oben gerutscht. Umfassende regulatorische Bestrebungen werden weltweit angestoßen. Das schließt auch neue Sicherheitspraktiken, Rahmenwerke und Vorschriften für die Softwareentwicklung und die Lieferketten mit ein.

Diese Vorgaben beschränken sich bei Weitem nicht auf Softwarehersteller, sondern haben Auswirkungen auf Käufer, Importeure und Dienstleister. Die derzeit definierten Verpflichtungen und Anforderungsprofile gehen über einzelne Softwareversionen hinaus und betreffen das breitere Ökosystem der Softwarelieferkette, digitale Produkte, vernetzte Systeme, Technologiedienstleistungen, Finanzunternehmen, kritische Infrastrukturen und weitere mehr.

Neue, auf Software- und Cybersicherheit ausgerichtete Gesetze und Vorschriften wurden gleichermaßen in Europa und im Vereinigten Königreich entwickelt und meist zügig verabschiedet. Zu den europäischen Beispielen zählen der Cyber Resilience Act und der Digital Operational Resilience Act.

Im Vereinigten Königreich sind der Product Security and Telecommunications Infrastructure Act 2022 und die vorgeschlagenen Änderungen an den Network and Information Systems Regulations zu nennen. Sie gelten zusätzlich zu den einzuhaltenden EU-Vorschriften für Unternehmen, die weiterhin den EU-Markt und einen EU-Kundenstamm bedienen oder anderweitig gemeinsame Dienste und Infrastrukturen betreiben wollen.

Was bedeutet das alles nun konkret?

Auch als nicht in den USA ansässiges Unternehmen oder nicht dort ansässiger Softwareanbieter sollten Sie darauf gefasst sein, in den Geltungsbereich des SSDF zu fallen. Etwa dann, wenn Ihre Software indirekt an die US-Regierung geliefert wird oder auf andere Weise in Produkte einfließt, die an die US-Regierung geliefert werden, oder wenn Sie in den USA geschäftlich tätig sind. In all diesen Fällen sollte man damit rechnen, aufgrund des SSDF neuen Compliance-, Gewährleistungs- und Anbietermanagementprozessen unterworfen zu werden.

Eine nachweislich solide Grundlage für die Softwaresicherheit und ein sicheres Produktentwicklungsprogramm stellen Mechanismen zur Verfügung, die ein umfassendes Risikomanagement im Unternehmen und innerhalb der Lieferkette erlauben. Aufgrund dieser Voraussetzungen lässt sich dann auch demonstrieren, dass der Sorgfaltspflicht hinsichtlich der Sicherheit entsprochen wurde. Das SSDF hat hier die Möglichkeit, sowohl das Programmdesign zu unterstützen als auch den Nachweis der Produktsicherheit zu erbringen und zu kommunizieren.

Unternehmen sollten stets zu gesetzgeberischen Initiativen und regionalen Regulierungen auf dem Laufenden sein. Zudem sollten sie, wo immer möglich, die Angleichung und Harmonisierung der regulatorischen Anforderungen an die Softwaresicherheit und Entwicklung berücksichtigen und vorantreiben. Schon allein, um die Komplexität nicht ausufern zu lassen.

Beispiele für Branchenvorschriften und Rahmenwerke für die Sicherheit, einschließlich des SSDF, unterstützen Unternehmen bei der Implementierung eines Softwaresicherheitsprogramms und helfen dabei, die Herausforderungen besser zu meistern – und beim Thema sichere Entwicklung nicht bei null anfangen zu müssen.

Was sollte man tun und wie kann das SSDF helfen?

Stellen Sie sich zunächst folgende Fragen:

• Gibt es im Unternehmen Richtlinien, Standards und Anforderungen für die Softwaresicherheit und die sichere Entwicklung?

• Kenne und verstehe ich den Kontext der Bedrohungslandschaft für meine Software vollumfänglich?

• Verfüge ich über Assessments für Softwaredesign und Risikomodellierung?

• Sind Mechanismen vorhanden, Sicherheitslücken und Schwachstellen zu erkennen, ebenso wie Fehler in Entwicklung und Produktion?

• Bin ich über den Sicherheitsstatus meiner Software und Produkte im Bilde?

• Ist das Unternehmen im Hinblick auf den Compliance-Status der Softwaresicherheit auf dem Laufenden?

• Habe ich die Konfiguration der Tools für den Software Build und die Pipelines überprüft?

• Ist die Entwicklungsinfrastruktur sicher?

• Wie überprüfe ich die Sicherheit von Drittanbieter- und Open-Source-Software?

• Wie trage ich selbst zu einer sicheren Softwarelieferkette bei?

• Wo brauche ich einen besseren Einblick in die Sicherheit meiner Software?

Wer nur eine dieser Fragen mit „Nein“ oder „Weiß ich nicht“ beantwortet, der sollte nicht zögern, sein Software-Development-Programm genauer unter die Lupe zu nehmen und zu überprüfen. Wer sich mit derlei Überlegungen beschäftigt, für den ist das SSDF ein nützliches Instrument.

* Ben Hutchinson ist Associate Principal Consultant bei Synopsys.

(ID:49570067)