Sicherheit der Software-Lieferkette

Kapitel 4. Sicherer Entwicklungslebenszyklus

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Sichere Software ist eine Software, die so konzipiert und entwickelt wurde, dass sie auch bei böswilligen Angriffen weiterhin normal funktioniert. Ein sicherer Entwicklungszyklus (SDL, auch wenn deine Organisation vielleicht einen anderen Namen verwendet) besteht aus Aktivitäten, die die Sicherheit einer Anwendung oder eines Produkts während des Softwareentwicklungszyklus (SDLC) stärken. Er kann auch als sicherer Softwareentwicklungslebenszyklus (S-SDLC) oder als Secure Software Development Framework (SSDF) bezeichnet werden.

Es gibt drei Hauptgründe, ein SDL so früh und so oft wie möglich einzusetzen: um Schwachstellen zu reduzieren, die Auswirkungen von Schwachstellen zu verringern und die ursprünglichen Ursachen von Schwachstellen zu beseitigen. Wie bei allen Softwarefehlern ist es immer billiger und effektiver, diese Probleme frühzeitig zu erkennen, und "frühzeitig" geht den ganzen Weg zurück bis zur ursprünglichen Erstellung und Gestaltung der Software. Ein SDL kann den Kunden die Gewissheit geben, dass ein formaler Prozess eingehalten wurde, und kann außerdem verhindern, dass Unternehmen bei jeder neuen Version die gleichen Sicherheitsfehler wiederholen.

Wie wir in den vorangegangenen Kapiteln gesehen haben, erfordert die Sicherheit der Software-Lieferkette eine sichere Entwicklung als eines der grundlegenden Elemente und ist nun ein erforderliches Element in vielen rechtlichen Vereinbarungen und Zertifizierungen zur Cybersicherheit. Möglicherweise gibt es in deinem Unternehmen bereits SDL-Prozesse innerhalb der bestehenden SDLC- oder DevOps-Prozesse, auch wenn sie nicht als solche bezeichnet werden. In diesem Kapitel geht es um die Details von sicheren Entwicklungslebenszyklen, die Erweiterung von SDLCs und die gängigsten SDLs, die du in deinem Unternehmen einsetzen kannst. Für eine ausführlichere Diskussion über sichere Entwicklung empfehle ich das Buch Alice und Bob lernen Anwendungssicherheit von Tanya Janca.¹

Die Entscheidung, welche SDL verwendet werden soll, liegt in der Regel bei deinem Unternehmen und erfordert fast immer eine Anpassung des sicheren Entwicklungslebenszyklus an deine Prozesse. Sobald sich dein Unternehmen für eine SDL entschieden hat, solltest du die Entscheidung und die entsprechenden Details in einer unternehmensweiten SDL-Richtlinie dokumentieren.

Sichere Kontrolle des Entwicklungslebenszyklus 01

Kontrolle SDL-01: Beibehaltung eines Rahmens und einer Richtlinie für einen sicheren Entwicklungszyklus (SDL), die Mitarbeiter, Auftragnehmer und Dritte dazu verpflichtet, SDL-Praktiken für Anwendungen und Produkte einzuhalten.

Schlüsselelemente einer SDL

Ein SDL ist die Grundlage für eine sichere Software-Lieferkette. Es gibt fünf Schlüsselelemente einer SDL, die in den verschiedenen Frameworks vorkommen: Sicherheitsanforderungen, sicherer Entwurf, sichere Entwicklung , Sicherheitstests und Schwachstellenmanagement. Obwohl du das Risiko verringern kannst, indem du Schlüsselelemente - wie z. B. Sicherheitstests - ohne einenSDL umsetzt, kann es sein, dass du trotzdem im Nachteil bist, weil das Entwicklungsteam nicht sicher sein kann, dass es das getestet hat, was wirklich getestet werden muss. Die vorgeschriebenen Prozesse und Kontrollen eines SDL ermöglichen es dir, eine sichere Software-Lieferkette mit sicheren Anforderungen, sicherem Design und sicherer Entwicklung in einem reproduzierbaren Prozess umzusetzen .

Sicherheitsanforderungen

Die Sicherheitsanforderungen können durch Gesetze, Vorschriften, SDL-Frameworks und Standards definiert oder durch Kunden, Marketing, interne Richtlinien, bekannte Schwachstellen und Bedrohungsanalysen ermittelt werden. Es ist nicht ungewöhnlich, dass für ein Produkt, eine Anwendung oder ein System Hunderte von Sicherheitsanforderungen unterschiedlicher Komplexität bestehen. Zum Beispiel können die Marketinganforderungen für die Datensicherheit sehr allgemein gehalten sein, wie z. B. "Personenbezogene Daten dürfen nur vom Benutzer eingesehen werden", und dann in Dutzende von detaillierteren, niedrigeren Sicherheitsanforderungen zerlegt werden, wie z. B. "Daten müssen bei der Übertragung verschlüsselt werden" und "der Benutzerzugang muss authentifiziert werden".

Manchmal gibt es spezifische Vorschriften, die mit den Marketing- oder technischen Anforderungen verbunden sind. So kann es z. B. sein, dass es auf der Marketingebene Anforderungen an die Kryptografie gibt, die Vorschriften aber NIST FIPS 140 für kryptografische Module verlangen.² SDL Frameworks können auch Anforderungen einführen, wie z. B. die Anforderung der Dateiintegrität in ISA/IEC 62443, die sicherstellt, dass Benutzer eine Möglichkeit haben, zu überprüfen, dass die Software nicht verändert wurde. Bevor du eine Anwendung entwickelst, solltest du dich über die geltenden Standards und Zertifizierungen informieren, die du anstrebst, wie z. B. den CREST OVS (OWASP Verification Standard) für die Sicherheitsstandards von Web- und mobilen Anwendungen.³

Die Sicherheitsanforderungen für Produkte, Anwendungen, Systeme und Infrastrukturen, die sich aus internen technischen Richtlinien, bekannten Schwachstellen und Bedrohungsanalysen ergeben, müssen ständig aktualisiert werden, um neuen Bedrohungen und Angriffswegen zu begegnen. Der typische Ansatz für die Bedrohungsanalyse ist die Bedrohungsmodellierung - ein Verfahren, mit dem potenzielle Bedrohungen, wie strukturelle Schwachstellen oder das Fehlen geeigneter Schutzmaßnahmen, identifiziert und aufgezählt werden können und Gegenmaßnahmen priorisiert werden.

Ein weiterer Ansatz zur Analyse von Bedrohungen ist die Verwendung von Wissensdatenbanken mit kuratierten Angreifertechniken aus realen Beobachtungen, wie dem MITRE ATT&CK® Framework mit Angriffstechniken für Unternehmenssysteme, mobile Anwendungen und industrielle Kontrollsysteme (ICS).⁴ Die MITRE-Techniken können Verfahrensbeispiele, Abhilfemaßnahmen, Erkennungsinformationen und Untertechniken enthalten.

Das Cyber Kill Chain® Framework, das von Lockheed Martin entwickelt wurde, ist ein weiteres Framework zur Identifizierung und Verhinderung von Cyberangriffen. Der siebenstufige Angriffsrahmen zeigt die Aktionen des Gegners und die Maßnahmen des Verteidigers zur Verhinderung des Eindringens.⁵

Ähnlich wie die MITRE-Rahmenwerke befasst sich die Open Software Supply Chain Attack Reference (OSC&R) speziell mit den Techniken, die für Angriffe auf Software-Lieferketten verwendet werden. Ich empfehle dir, nicht nur die Informationen und Kontrollen in diesem Buch zu nutzen, sondern auch das OSC&R-Rahmenwerk sorgfältig zu prüfen, um die Anforderungen für dein Unternehmen, deine Produkte und Anwendungen zu ermitteln.⁶

Bei einigen Sicherheitsrisiken in der Software-Lieferkette kannst du die Sicherheitskontrolle in eine Sicherheitsanforderung umwandeln. Ein Beispiel dafür wäre die Infrastruktur-Sicherheitskontrolle IS-08 für Patches, wie in Kapitel 3 beschrieben. Eine Sicherheitsanforderung für eine Anwendung oder eine User Story, die speziell auf die "automatische Aktualisierung von Software" abzielt, würde einen Teil der IS-08 Sicherheitskontrolle lösen.

Irgendwann sollten alle diese Sicherheitsanforderungen in einer Anforderungs- oder User-Stories-Datenbank dokumentiert werden - einschließlich der Anforderungen, die sich auf die SDL Kontrollen und den Governance-Prozess beziehen. Die Rückverfolgbarkeit zwischen diesen Anforderungen, den Bedrohungsmodellen und den sicheren Testfällen ist wichtig, um die Anforderungen vor der Softwarefreigabe zu validieren und den Nachweis der Kontrollen für Prüfer zu erbringen. Mindestens einmal im Jahr solltest du die bestehenden Sicherheitsanforderungen auf Erweiterungen oder Ergänzungen überprüfen, wenn sich der SDL Prozess und die Kontrollen geändert oder verbessert haben und wenn neue Anforderungen und Bedrohungen aufgetaucht sind.

Sichere Kontrolle des Entwicklungslebenszyklus 02

Kontrolle SDL-02: Dokumentiere und pflege die Sicherheitsanforderungen für Anwendungen und Produkte. Dazu gehören auch Sicherheitsanforderungen, die durch Prozesse, Kontrollen, geltende Gesetze und Vorschriften vorgeschrieben sind.

Sicheres Design

Das Konzept des sicheren Designs (oder secure-by-design) ist nicht nur über Architektur und Infrastruktur, sondern auch über die Sicherheitsanforderungen, die in das System implementiert werden. Innerhalb eines Produkts oder einer Anwendung ist ein sicheres Design dann gegeben, wenn das Team die Anforderungen und potenziellen Bedrohungen bewertet hat, um das Risiko zu begrenzen. Das Risiko für die Sicherheit der Software-Lieferkette wird erheblich reduziert, wenn sichere Designaktivitäten wie die Modellierung von Bedrohungen durchgeführt werden. Selbst Produkte, die bereits entwickelt wurden, profitieren stark von einem vollständigen Bedrohungsmodell, das Einstiegspunkte, Code, Dienste, Protokolle, APIs und mehr analysiert.

Die Modellierung von Bedrohungen muss ein Teamsport sein, oder wie es im Threat Model Manifesto heißt: Es sollte nicht nur einen einzigen Helden geben, der Bedrohungsmodelle erstellt, sondern mehrere Personen, die Darstellungen und Ansichten liefern, um verschiedene Probleme zu beleuchten.⁷ Bedrohungsmodelle sollten als lebendige Artefakte betrachtet werden, die das Team erneut überprüfen muss, wenn sich die Architektur, die Technologie oder die Bedrohungen ändern. Dies zeigt, dass die Bedrohungsmodelle häufig aktualisiert werden sollten, da sich die Bedrohungslandschaft schnell verändert. Jedes Mal, wenn Risiken durch Bedrohungsmodelle identifiziert werden, müssen dem Produkt oder der Anwendung zusätzliche Sicherheitsanforderungen hinzugefügt werden.

Weitere Techniken zur Sicherung des Produkt-, Anwendungs- oder Systemdesigns sind:

• Analyse und Auswahl von Technologien, Komponenten, Programmiersprachen und Infrastrukturen mit geringerem Risiko im Vergleich zu anderen Optionen

• Die Verwendung von modularem Code für einfachere Code-Aktualisierungen oder Wiederverwendung

• Isolierung kritischer Komponenten und Sicherheitskomponenten von anderen Komponenten während der Ausführung

• Funktionen für sichere Bereitstellung, Betrieb und Wartung

Eine andere Art der sicheren Gestaltung ist "Privacy by Design" (manchmal auch PbD genannt). Dazu gehören Anforderungen an Datensicherheit, Datenschutz und Datenlokalisierung für persönliche oder geschäftliche Daten. Die Berücksichtigung von PbD in einem frühen Stadium des Entwurfsprozesses kann das Umgestalten von Datenbanken, Strukturen und gängigen Methoden wie Verschlüsselung erheblich reduzieren, um veränderte Datenschutzanforderungen zu erfüllen.

Sichere Kontrolle des Entwicklungslebenszyklus 03

Kontrolle SDL-03: Verwende bei der Entwicklung von Anwendungen und Produkten die Konzepte "Secure-by-Design" und "Privacy-by-Design". Führe eine Bedrohungsmodellierung für alle Codes, Dienste, Systeme, Infrastrukturen, APIs und Protokolle durch.

Sichere Entwicklung

Die sichere Entwicklung, ein weiteres Schlüsselelement eines SDL, umfasst die Methoden, Techniken und Praktiken, die Entwickler bei der Codeentwicklung befolgen und anwenden sollten. Dazu gehören wichtige Bereiche wie die richtige Fehlerbehandlung, die Fehlerbehandlung, die Speicherverwaltung und sichere Codierungsstandards. Sichere Kodierungsstandards sollten immer verhindern, dass Hintertüren, Debug-Schnittstellen, Fehlerinformationen oder geistiges Eigentum veröffentlicht werden. Die Regeln für sichere Codierung müssen auf die Technologie und die Sprachen abgestimmt sein, die dein Unternehmen verwendet. Wenn dein Unternehmen keine Standards für sichere Codierung hat, findest du unter "Codequalität" eine Liste verschiedener Standards.

Es gibt viele Tools, die den Code auf Sicherheitsrisiken überprüfen. Tools für die Codequalität und die Analyse der Softwarezusammensetzung (SCA) wurden entwickelt, um Fehler in freier und quelloffener Software (FOSS oder OSS) zu finden, indem den Code auf bekannte Schwachstellen untersucht. Diese Tools können auch Lizenzinformationen für potenzielle Compliance-Risiken ermitteln. Einige Tools suchen sogar nach fest kodierten Anmeldeinformationen oder nach der Einhaltung von Regeln für sichere Kodierung. Weitere Informationen zu Open Source oder zur Codeanalyse findest du in Kapitel 5.

Achte bei der Auswahl von Tools auf die Kompatibilität mit Anwendungen, Betriebssystemen oder Plattformen. Obwohl die Materialien des OWASP (Open Worldwide Application Security Project) ursprünglich für Webanwendungen entwickelt wurden, decken sie inzwischen mehr als nur Webtechnologien ab. In der Softwareentwicklung ist OWASP für sein "OWASP Top 10"-Projekt bekannt, in dem die 10 wichtigsten Sicherheitsprobleme für die Sicherheit von Webanwendungen aufgeführt sind und das etwa alle drei bis vier Jahre überarbeitet wird.⁸ Die OWASP-Liste von 2017 enthielt eine ganze Reihe von Frontend-Sicherheitsrisiken, aber die aktualisierte Liste von 2021 hebt auch Risiken hervor, die auf schlechte SDL-Praktiken zurückzuführen sind, z. B. Software-Integritätsfehler, unsicheres Design und anfällige und veraltete Komponenten.

Sichere Kontrolle des Entwicklungslebenszyklus 04

Kontrolle SDL-04: Befolge die Regeln für sichere Programmierung, nutze Tools und entschärfe bekannte Schwachstellen, um sichere Produkte und Anwendungen zu entwickeln.

Sicherheitsprüfung

Sicherheitstests sind das vierte Schlüsselelement einer SDL. Wie bei der Bedrohungsmodellierung ist es nie zu spät, mit Sicherheitstests zu beginnen. Wie in Abbildung 4-1 dargestellt, gibt es mehrere Möglichkeiten, Sicherheitstests durchzuführen, darunter statische Anwendungstests (SAST), dynamische Anwendungstests (DAST), interaktive Anwendungstests (IAST), Laufzeit Anwendung Sicherheit Schutz (RASP) und Penetrationstests.⁹ Fuzz-Testing, eine automatisierte Softwaretestmethode, bei der fehlerhafte, ungültige oder unerwartete Eingaben gemacht werden, um Softwarefehler und Schwachstellen aufzudecken, ist eine effektive Form des Sicherheitstests. Weitere Testarten sind Cloud-Container und Deployment-Tests, wie in Kapitel 6 beschrieben. Die verschiedenen Testmethoden sollten miteinander kombiniert werden und sind je nach Produkt, Anwendung, System oder Infrastruktur unterschiedlich.

Abbildung 4-1. Tools und Techniken zur Anwendungssicherheit

Diese Tools können das Sicherheitsrisiko nur dann wirksam verringern, wenn auf der Grundlage der Ergebnisse Abhilfemaßnahmen (Verringerung der Auswirkungen) oder Abhilfemaßnahmen (Beseitigung der Bedrohung) durchgeführt werden . Außerdem können diese Tools Hunderte oder Tausende von Schwachstellen aufspüren, und die meisten sind unwirksam, wenn es darum geht, festzustellen, ob die Schwachstelle ausgenutzt werden kann. Priorisierung, Verfolgung und V&V (Verifizierung und Validierung) von Sicherheitstests sollten in Verbindung mit Testtools eingesetzt werden.

Sichere Kontrolle des Entwicklungslebenszyklus 05

Kontrolle SDL-05: Führe Sicherheitstests mit verschiedenen Tools und Techniken für Anwendungen und Produkte durch.

Vulnerability Management

Obwohl die Aktivitäten des Schwachstellenmanagements unter in den primären SDL Praktiken enthalten sind, ist dieser Teilprozess entscheidend für die Identifizierung, Bewertung und Behebung von Sicherheitsschwachstellen. Während des gesamten Entwicklungszyklus gibt es viele Aktivitäten, die Schwachstellen aufdecken können, z. B. bei der Bedrohungsmodellierung, der Entwicklung, der Codeanalyse, dem Scannen und dem Testen. Dieser kontinuierliche Prozess ist wichtig, um Produkte und Anwendungen bis zum Ende ihres Lebenszyklus zu sichern. Um den Reifegrad deines Unternehmens zu demonstrieren, kannst du deinen Prozess zum Umgang mit Schwachstellen sogar nach der Norm ISO/IEC 30111:2019 zertifizieren lassen.¹⁰

In einer perfekten Welt würden alle Schwachstellen vor der Veröffentlichung des Produkts oder der Anwendung behoben werden. Leider leben wir nicht in einer perfekten Welt, und so enthält jede Version Schwachstellen, die ausnutzbar sein können oder auch nicht. Im Jahr 2021 gab eine ausnutzbare Schwachstelle im Fernüberwachungs-Tool von Kaseya böswilligen Akteuren die Möglichkeit, Malware an über 1.000 Kunden zu verteilen, bevor Kaseya die Software offline nehmen konnte.¹¹

Wenn eine Schwachstelle gefunden wird, wird sie in der Regel mit einem Bewertungssystem bewertet, wie z. B. dem Common Vulnerability Scoring System (CVSS), das vom Forum of Incident Response and Security Teams (FIRST) entwickelt wurde.¹² Da CVSS jedoch nicht perfekt ist, gibt es inzwischen mehrere andere Bewertungs- und Rangordnungssysteme, die bei der Priorisierung von Schwachstellen helfen.

Der CVSS-Standard weist den Schwachstellen auf einer Skala von 0 bis 10 Schweregrade zu, wobei 10 der schwerste ist. Die aktuelle Version von CVSS ist eine berechnete Punktzahl, auf die in der Regel in Schwachstellenkatalogen verwiesen wird und die sich aus vielen Metriken zusammensetzt, darunter die Komplexität des Angriffs und die erforderlichen Berechtigungen. Es gibt drei weitere Bewertungs- und Einstufungssysteme: das Stakeholder-Specific Vulnerability Categorization (SSVC)-Modell, das Exploit Prediction Scoring System (EPSS)-Modell und den Known Exploited Vulnerability (KEV)-Katalog.

Das SSVC-Modell, das vom Software Engineering Institute der Carnegie Mellon University und der US Cybersecurity & Infrastructure Agency (CISA) entwickelt wurde, ist ein Entscheidungsbaum, mit dem Schwachstellen anhand von fünf Werten priorisiert werden können, darunter der Ausnutzungsstatus und die technischen Auswirkungen.¹³ Im gleichen Zeitraum wurde EPSS von FIRST entwickelt, um die Wahrscheinlichkeit abzuschätzen, dass eine Schwachstelle in freier Wildbahn ausgenutzt wird.¹⁴ Um die Nutzung zu erleichtern, wird der durchsuchbare oder maschinenlesbare CISA KEV-Katalog jedoch ständig mit den Schwachstellen aktualisiert, die derzeit ausgenutzt werden.¹⁵

Bei der Priorisierung der Schwachstellen empfehle ich dir, zuerst die KEVs zu beheben und dann die kritischen und hohen CVSS-Schwachstellen. Die Behebung kann viele Formen annehmen, wie z.B. kompensierende Kontrollen, Patches, Aktualisierungen oder das Ersetzen des Quellcodes. Im Idealfall werden alle Bibliotheken von Drittanbietern mit den neuesten Sicherheitspatches im Quellcode auf dem neuesten Stand gehalten, aber es gibt Situationen, in denen die einzige Möglichkeit darin besteht, kompensierende Kontrollen zu implementieren, um eine Ausnutzung zu verhindern.

Wenn ein Dritter eine Schwachstelle gemeldet hat, solltest du den Prozess zur Behandlung von Schwachstellen in deinem Unternehmen befolgen und die getroffenen Abhilfemaßnahmen gemäß den Offenlegungsrichtlinien deines Unternehmens offenlegen, wie in "Offenlegung von Schwachstellen" beschrieben .

Sichere Kontrolle des Entwicklungslebenszyklus 06

Kontrolle SDL-06: Pflege eines Rahmens für das Schwachstellenmanagement, einer Richtlinie für den Umgang mit Schwachstellen und einer Richtlinie für die Offenlegung von Schwachstellen, um Schwachstellen zu identifizieren, zu bewerten, zu beheben und externen Parteien mitzuteilen.

Erweiterung eines SDLC mit SDL

Je nach Unternehmen hast du vielleicht bereits einen Softwareentwicklungszyklus (SDLC), in den ein SDL integriert ist. Diejenigen, die über einen SDLC ohne Sicherheitsaspekte verfügen, sollten ihre bestehenden SDLC-Prozesse, Gates, Reviews, Vorlagen, Checklisten und Schulungen anpassen, um die wichtigsten SDL-Elemente zu integrieren. Auf diese Weise wird der SDL weniger zu einer "Checkliste" und mehr zu einer natürlichen Aufgabe im gesamten Entwicklungsprozess. Letztendlich willst du, dass dein SDL vollständig integriert ist und Teil der täglichen Denkweise deiner Teams, einschließlich der Geschäftsführung, bei der Entwicklung deiner Anwendungen und Produkte ist.

In den folgenden Abschnitten werden die gängigsten SDL Standards und Frameworks beschrieben. Der Markt, in dem du deine Anwendung oder dein Produkt verkaufst, kann auch bestimmen, welche SDL bei deinen Kunden besser ankommen würde. Wenn du noch keine SDL eingeführt hast, empfehle ich dir, deinen SDLC mit ISA/IEC 62443-4-1 (dem umfassendsten) oder NIST SSDF (das sich schnell durchsetzt und kostenlos ist) zu erweitern.

ISA/IEC 62443-4-1 Sicherer Entwicklungslebenszyklus

Die International Society of Automation (ISA), die International Electrotechnical Commission (IEC) und die International Organization for Standardization (ISO) haben gemeinsam die "62443-4-1:2018 Secure product development lifecycle requirements" (im Folgenden als "4-1 SDL" bezeichnet) erstellt und veröffentlicht, die in den Webshops der ISA und der IEC erworben werden können.¹⁶ Der Standard 4-1 SDL legt die Anforderungen an einen sicheren Entwicklungsprozess für Produkte der industriellen Automatisierungs- und Steuerungssysteme fest. Diese Prozessanforderungen können auf neue oder bestehende Software- oder Firmware-Produkte angewendet werden.

Der 4-1 SDL-Standard ist der robusteste SDL-Standard, der für die Entwicklung von Software und Firmware verfügbar ist. Das technische Komitee, das den Standard entwickelt hat, hat viele Anregungen aus den verfügbaren SDLs, Sicherheits-Frameworks, Sicherheitsstandards und den Erfahrungen der Industrie bei der Sicherung kritischer Systeme aufgenommen. Der 4-1 SDL Standard ist ein Teil der ISA/IEC 62443 Serie, die Standards für Komponenten, Systeme, Integrationen, Einsätze und Abläufe bietet.¹⁷ Der 4-1 SDL-Standard ist eine Grundvoraussetzung für Produkte und Systeme, um weitere ISA/IEC 62443-Zertifizierungen zu erhalten, aber als SDL ist er allgemein für jedes Produkt und jede Anwendung anwendbar, nicht nur für industrielle Systeme.

In der folgenden Liste sind die acht Praktiken der ISA/IEC 62443-4-1 SDL aufgeführt, wie in Abbildung 4-2 dargestellt:

• Sicherheitsmanagement

• Spezifikation der Sicherheitsanforderungen

• Sicher durch Design

• Sichere Implementierung (Entwicklung)

• Sicherheitsüberprüfung und Validierungstests

• Management von sicherheitsrelevanten Problemen (Schwachstellen)

• Dokumentation zum Sicherheitsupdate

• Sicherheitsrichtlinien

Abbildung 4-2. Acht Praktiken der ISA/IEC 62443-4-1

Das MDCG 2019-16 (Medical Device Coordination Group Document-Guidance on Cybersecurity for medical devices) Dokument verwendet ebenfalls diese acht Praktiken.¹⁸ Unternehmen, die Produkte für industrielle Kontrollsysteme (ICS) entwickeln, die in der Fertigung, in Energiesystemen, bei der Wasseraufbereitung und vielen anderen Bereichen eingesetzt werden, verwenden häufig 4-1 SDL als Grundlage für ihre unternehmenseigenen SDLs und lassen ihre globalen SDL-Frameworks durch unabhängige Zertifizierungsstellen zertifizieren. 4-1 SDL ist ein starkes, solides Framework für Software und Firmware, braucht aber einige Aktualisierungen, um die Anforderungen für Cloud-gehostete Anwendungen und kleine agile Teams zu erfüllen.

NIST SSDF

Das National Institute of Standards and Technology (NIST) der Vereinigten Staaten gibt viele Dokumente und Standards zur Sicherheit der Lieferkette heraus, darunter auch die NIST Special Publication 800-218. Das Dokument NIST SP 800-218 ist besser bekannt als das "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities" oder kurz SSDF genannt.¹⁹ Das Dokument vom Februar 2022, das zum Zeitpunkt der Erstellung dieses Artikels aktuell war, enthält einen beeindruckenden Querverweis auf die verschiedenen Frameworks für sichere Softwareentwicklung. Du kannst dieses Dokument nutzen, um sichere SDLC-Praktiken für deine Softwarelieferanten zu ergänzen oder einzuführen .

Der SSDF ist in vier Hauptbereiche unterteilt:

• PO: Die Organisation vorbereiten

• PS: Software schützen

• PW: Gut gesicherte Software produzieren

• RV: Reagiere auf Schwachstellen

SSDF ist eine gute Grundlage für eine SDL, aber es ist nicht umfassend genug, um eine sichere Software-Lieferkette aufzubauen, selbst wenn man die NIST CSF (wie in Kapitel 2 beschrieben) mit einbezieht. Um die Risiken in der gesamten Software-Lieferkette zu bewerten und zu identifizieren, brauchst du mehrere Rahmenwerke oder den Kernsatz an Kontrollen, die in diesem Buch beschrieben werden.

Das SSDF enthält keine konkreten Anleitungen zur Umsetzung der einzelnen SDL-Verfahren oder -Kontrollen. Es gibt jedoch ein hervorragendes zusätzliches Tabellenblatt, das dem SSDF-Dokument beigefügt ist. Die ergänzende Tabelle enthält fiktive Umsetzungsbeispiele, die nützlich sein können, um Erklärungen und mögliche Anwendungsfälle zu liefern. Wenn du bereits andere Rahmenkontrollen wie ISA/IEC 62443 oder NIST SP 800-53 umgesetzt hast, werden dir die Querverweise in der ergänzenden Tabelle sehr helfen.

Microsoft SDL

Microsoft hat seinen SDL (den Microsoft als Security Development Lifecycle bezeichnet) erstmals 2008 unter vorgestellt und unterstützt die SDL-Praktiken in allen in diesem Kapitel erwähnten Standards und Frameworks nachdrücklich.²⁰ Microsoft stellt auf seiner Website ein kostenloses Dokument mit dem Titel "Simplified Implementation of the Microsoft SDL" (Vereinfachte Umsetzung des Microsoft SDL) sowie eine vereinfachte SDL-Kalkulationstabelle zum Download bereit.²¹ Vor der Veröffentlichung des NIST SSDF war die Microsoft SDL-Dokumentation mein empfohlener Leitfaden für nicht-industrielle Kontrollsystemunternehmen, insbesondere für kleine Organisationen oder Start-ups. Obwohl Abbildung 4-3 einen Wasserfallprozess impliziert, lässt sich Microsoft SDL auch an agile Prozesse anpassen.

Abbildung 4-3. Der Microsoft Security Development Lifecycle - vereinfacht

Microsoft hat sein SDL mit weiteren Themen auf seinem Security Engineering Portal ergänzt.²² Die wichtigste Erweiterung ist die in Kapitel 6 erwähnten Secure DevOps-Praktiken, die als Grundlage für einen Cloud SDL betrachtet werden können.²³

ISO/IEC 27034 Anwendungssicherheit

Die Internationale Organisation für Normung (ISO) und die Internationale Elektrotechnische Kommission (IEC) haben gemeinsam die ISO/IEC 27034 als Teil der ISO 27k-Reihe erstellt und veröffentlicht. Die Norm ISO/IEC 27034-1:2011 "Information Technology-Security Techniques-Application Security" (Informationstechnologie - Sicherheitstechniken - Anwendungssicherheit) ist eine Anleitung für Organisationen, die Anwendungen erwerben, entwickeln oder verwalten.²⁴ Die ISO 27034-Reihe bietet außerdem Anleitungen für die Umsetzung und den Nachweis von Application Security Governance und Application Security Management, indem sie dabei hilft, ein Vertrauensniveau für den Lebenszyklus jeder Anwendung zu definieren, zu implementieren und zu erhalten.

Der Standard 27034 eignet sich sowohl für Softwareanwendungen in Unternehmen, die die ISO 27k-Normen übernommen haben, als auch für Unternehmen, die gerade erst mit der Implementierung von Sicherheit für ihre Anwendungen beginnen. Er ist eng an die Norm ISO 27005 für das Risikomanagement der Informationssicherheit angelehnt. Der 27034-Standard besteht aus fünf Hauptelementen:

Sicherheitskontrollen für Anwendungen (ASCs)

Überprüfbare Kontrollen, die mit den Sicherheitsanforderungen der Organisation verknüpft und nach Vertrauensstufe klassifiziert sind, um Schwachstellen in und um Anwendungen zu verhindern, wie in Abbildung 4-4 dargestellt.

Organisation Normative Framework (ONF)

Ein Repository von ASCs und Prozessen, das dazu dient, bewährte Methoden für die Anwendungssicherheit im gesamten Unternehmen zu standardisieren.

ONF-Management-Prozess

Verwaltet die Prioritäten einer Organisation und definiert ASCs zusätzlich zu anderen Prozessen und Sicherheitsaktivitäten für die Anwendungen der Organisation.

Application Security Management Process (ASMP)

Bewertet Risiken, definiert Anforderungen und testet ASCs mit Hilfe von Verifizierungsmaßnahmen.

Anwendungsnormativer Rahmen (ANF)

Sammelt und speichert ASCs für eine bestimmte Anwendung als Teilmenge der ONF sowie Prozessergebnisse als Sicherheitsnachweis für diese Anwendung.

Abbildung 4-4. ISO/IEC 27034 Kontrolle der Anwendungssicherheit

Auf den ersten Blick halten viele Organisationen die ISO-Norm 27034 für komplex, abstrakt und für Softwarehersteller nur von begrenztem Nutzen. Doch auch wenn die Zuordnung zu bestimmten Situationen den meisten Unternehmen überwältigend erscheinen mag, bietet die Norm 27034 einen schrittweisen Ansatz, der es Unternehmen ermöglicht, die Anwendungssicherheit je nach Reifegrad, Prioritäten und verfügbaren Ressourcen in ihre bestehenden Prozesse zu integrieren. Dieser Ansatz ermöglicht es Einzelpersonen, kleinen Unternehmen und agilen Organisationen, die ASC für ihre Anwendungen in ihrem Kontext zu entwickeln und dann die vom 27034-Standard vorgeschlagenen Elemente zu integrieren, wenn ihr Sicherheitsbedarf entsteht. Für Organisationen, die bereits nach vielen ISO 27k-Normen zertifiziert sind, ist die Norm 27034 eine Überlegung wert.

SAFECode

Das Software Assurance Forum for Excellence in Code (SAFECode) ist ein gemeinnütziger Zusammenschluss von Unternehmen, der seit 2008 SDL-Praktiken dokumentiert. Die mittlerweile dritte Auflage von "Fundamental Practices for Secure Software Development" bietet eine gute Grundlage für sichere Entwicklung und Tests.²⁵ Das Dokument verweist auf verschiedene Publikationen, darunter "Practices for Secure Development of Cloud Applications", das 2013 veröffentlicht wurde, und eine Anleitung für Agile Praktiker in "Practical Security Stories and Security Tasks for Agile Development Environments" von 2012.^26,27

Alle SAFECode Dokumente sind gut geschrieben und enthalten Details zu den Kernaspekten einer SDL. Die Dokumente enthalten jedoch keine präskriptiven und aufgezählten Anforderungen (z. B. Secure Design requirement number n). Ohne eine Reihe von Kontrollen kann eine Entwicklungsorganisation gegenüber Dritten nicht nachweisen, dass die SDL bei jeder Veröffentlichung eingehalten wurde. Ich glaube, dass die SAFECode-Publikationen als Ergänzung zu den Kontrollen und als Material für ein solides Schulungsprogramm verwendet werden können. Obwohl das Cloud-Dokument etwas veraltet ist und Serverless Computing nicht erwähnt, enthält das Agile-Dokument viele User Stories, Backlog-Aufgaben und Schwachstellen, die eine sichere Entwicklung und Prüfung unterstützen.

SDL-Überlegungen für IoT, OT und eingebettete Systeme

Eine SDL ist für alle Produkte und Anwendungen anwendbar, aber es gibt zusätzliche Überlegungen für Geräte wie IoT, OT (Betriebstechnologie, die physikalische Prozesse erkennen oder verändern kann) und eingebettete Systeme (Kombination aus Computerhardware und Software). Wie im Abschnitt "Maßnahmen zum Schutz von Geräten" erwähnt , gibt es verschiedene Möglichkeiten, den Schutz von Geräten durch zusätzliche Anforderungen, Designüberlegungen, Entwicklung und Prüfung von Software, Firmware und Hardware zu verbessern.

Für IoT-Geräte werden jedes Jahr neue Standards, Mindestanforderungen und Kennzeichnungsprogramme veröffentlicht, und viele davon sind spezifisch für den Typ des IoT-Geräts. Kennzeichnungsprogramme verlangen von den Herstellern, dass sie einen bestimmten Cybersicherheitsstandard erfüllen, bevor sie ein bestimmtes Logo (Vertrauenszeichen) auf dem Produkt anbringen dürfen. Das IoT-Cybersecurity Labelling Scheme von Singapur wurde zum Beispiel 2021 eingeführt und umfasst nun viele Kategorien von IoT-Geräten für Verbraucher wie Router, Smart Home Hubs und Smart Home-Geräte.²⁸ Finnland und Deutschland haben ebenfalls Cybersecurity-Labels herausgegeben, und das US IoT Cybersecurity Labeling for Consumers Programm ist in Planung, wurde aber zum Zeitpunkt der Veröffentlichung dieses Buches noch nicht offiziell veröffentlicht.

Bei OT-Produkten und eingebetteten Systemen sind die Standards und Grundlagen sehr ähnlich wie beim IoT, aber OT-Produkte haben in der Regel einen Bezug zur Sicherheit, entweder direkt (z. B. bei der Steuerung von Abwassersystemen oder Produktionsmaschinen) oder indirekt (z. B. beim Auslesen von Sensoren in einem Rechenzentrum). Es gibt eine Reihe von Standards für IoT/OT, darunter einige länder- und branchenspezifische Anforderungen. Ich habe die folgende Liste zusammengestellt, aber du musst dich über neue Anforderungen informieren, da ständig neue hinzukommen:

• ISA/IEC 62443-4-2: Technische Sicherheitsanforderungen für Komponenten²⁹

• ETSI EN 303 645: Cybersicherheit für das IoT der Verbraucher³⁰

• ISO/IEC 27400:2022: IoT-Sicherheits- und Datenschutzrichtlinien³¹

• ISO/SAE 21434: Cybersicherheitsstandard für die Automobilindustrie³²

• UL 2900-1: Netzwerkverbindbare Produkte³³

• CTIA IoT Cybersecurity Certification: IoT-Grundlage zum Zweck der Zertifizierung³⁴

• UK Product Security and Telecommunications Infrastructure Act 2022: mit dem Internet vernetzbare Produkte³⁵

• EU Cybersecurity Resilience Act (CRA): Verordnungsentwurf umfasst IoT-Bereich³⁶

• US NIST IR 8259 Serie: IoT-Empfehlungen und -Baselines³⁷

• US-Kalifornien Gesetz SB-327: erstes Gesetz speziell zur IoT-Sicherheit³⁸

• US Oregon Gesetz HB 2395: Verbraucher IoT Gesetz³⁹

Metriken zur Produkt- und Anwendungssicherheit

Eine häufige Frage von Neueinsteigern in die Anwendungssicherheit lautet: "Welche Metriken (eine Zahl) oder Messungen (Verhältnis zwischen Zahlen) verwende ich, um eine Organisation oder ein Produkt zu bewerten?" Die Antwort ist leider nicht einfach, denn sie hängt davon ab, wo du dich auf deiner Sicherheitsreise befindest und was sinnvollerweise erfasst werden sollte.

Mein persönlicher Favorit für neuere Sicherheitsprogramme ist eine Messung der SDL-Einführung, bei der Kennzahlen aus bestimmten Prozessen wie Penetrationstests und Sicherheitsüberprüfungen verwendet werden. Beim Penetrationstest sollten zum Beispiel keine leichten Schwachstellen gefunden werden, und es gibt ein Bewertungssystem für die Komplexität von leicht, mittelschwer und schwer. Du kannst eine beliebige Anzahl von Kennzahlen kombinieren und bestimmte Gewichtungen vornehmen (z. B. die dreifache Gewichtung für ein Produkt, das eine leichte Schwachstelle aufwies), um ein Messsystem zu definieren, das einzigartig für dein Unternehmen ist.

Für eine Liste vieler Metriken und Messungen zur Anwendungssicherheit empfehle ich das Kapitel "Capability Maturity Model and Security Metrics" in The Purple Book of Software Security.⁴⁰ Die Purple Book Community von Softwaresicherheitsexperten, zu deren Gründungsmitgliedern ich gehöre, hat außerdem das Scalable Software Security Maturity Model (S3M2) entwickelt, mit dem Unternehmen ihre Sicherheitsreife bewerten können.⁴¹ Dieses Software-Sicherheitsmodell kann von Unternehmen jeder Größe verwendet werden, sogar von Start-ups, und es ist auf alle Branchen und Technologien anwendbar.

Es sind drei weitere Modelle verfügbar: ISACA/Carnegie Mellon University CMMI, Synopsys BSIMM und OWASP SAMM. Das Capability Maturity Model Integration (CMMI) verwendet bekannte Reifegradstufen, um die Fähigkeit des zu messenden Prozesses zu bewerten. CMMI ist eine gute Wahl für Organisationen, die bereits andere Reifegradmodelle eingeführt haben und keinen speziellen Fokus auf Softwaresicherheit benötigen.⁴²

Das Synopsys BSIMM (Building Security in Maturity Model) ist als Bewertungsdienst verfügbar und wird daher hauptsächlich von größeren Unternehmen genutzt. Obwohl es keine Reifegradbewertung ist, bietet es eine Bewertung und einen Vergleich mit anderen Unternehmen und der Branche. Auf der Grundlage der Ergebnisse der jährlich durchgeführten Bewertungen erstellt Synopsys einen Trends & Insights-Bericht mit den wichtigsten Erkenntnissen und Empfehlungen.⁴³

Das OWASP-Projekt SAMM (Software Assurance Maturity Model) wurde speziell für die Anwendungssicherheit entwickelt und ist für jede Organisation kostenlos erhältlich.⁴⁴ Es ist ein umfassendes Reifegradmodell für die Anwendungssicherheit, das jedoch andere wichtige Bereiche der Sicherheitslage einer Organisation wie die Netzwerksicherheit und die physische Sicherheit nicht berücksichtigt. Ich schlage vor, dass du dir sowohl das OWASP SAMM als auch das Purple Book S3M2 ansiehst, um ein Reifegradmodell zu finden, das für dein Unternehmen geeignet ist.

Zusammenfassung

Sichere Entwicklungslebenszyklen sind der Grundstein für eine sichere Software-Lieferkette. Angesichts der Aufmerksamkeit, die der sicheren Entwicklung und den sicheren Testverfahren gewidmet wird, wird es bald zur gängigen Praxis werden, eine unternehmensweite SDL-Richtlinie für die Entwicklung interner, unternehmensinterner oder kundeneigener Anwendungen und Produkte zu haben. Es gibt zwar verschiedene Rahmenwerke und Ansätze für SDLs, aber sie alle drehen sich um die Hauptprinzipien Sicherheitsanforderungen, sicherer Entwurf, sichere Entwicklung und Sicherheitstests.

Durch die Einbeziehung dieser Schlüsselprinzipien in den SDLC eines Unternehmens wird die Sicherheitslage von Anwendungen und Produkten verbessert und es kann reagiert werden, wenn Schwachstellen entdeckt werden. In Kapitel 5 gehe ich auf die verschiedenen Arten von Quellcode ein und erkläre, wie man den Build- und Bereitstellungsprozess absichert.

¹ Tanya Janca, Alice und Bob lernen Anwendungssicherheit (Wiley, 2020).

² "Security Requirements for Cryptographic Modules", NIST, 19. März 2019.

³ "CREST OVS Web Application Programme", CREST, Zugriff am 10. Dezember 2023.

⁴ MITRE ATT&CK®, Zugriff am 10. Dezember 2023.

⁵ Lockheed Martin Corporation, Gaining the Advantage: Applying Cyber Kill Chain Methodology to Network Defense, 2015.

⁶ "A New Open Framework for Releasing Secure Products", PBOM, Zugriff am 10. Dezember 2023.

⁷ "Threat Modeling Manifesto", abgerufen am 26. Oktober 2023.

⁸ "OWASP Top 10", OWASP, Zugriff am 11. November 2023.

⁹ Sherif Koussa, "Was bedeuten SAST, DAST, IAST und RASP für Entwickler/innen?" Software Secured, abgerufen am 10. Dezember 2023.

¹⁰ "ISO/IEC 30111:2019 Vulnerability Handling Processes", ISO, abgerufen am 10. Dezember 2023.

¹¹ Charlie Osborne, "Aktualisierte FAQ zum Kaseya Ransomware-Angriff: Was wir jetzt wissen", ZDNET, 23. Juli 2021.

¹² "Common Vulnerability Scoring System SIG", Forum of Incident Response and Security Teams, Zugriff am 10. Dezember 2023.

¹³ "Stakeholder-Specific Vulnerability Categorization (SSVC)", US Cybersecurity & Infrastructure Security Agency, Zugriff am 10. Dezember 2023.

¹⁴ "Exploit Prediction Scoring System (EPSS)", Forum of Incident Response and Security Teams, Zugriff am 10. Dezember 2023.

¹⁵ "Known Exploited Vulnerabilities Catalog", US Cybersecurity & Infrastructure Security Agency, Zugriff am 10. Dezember 2023.

¹⁶ Siehe "ANSI/ISA-62443-4-1-2018, Security for Industrial Automation and Control Systems - Teil 4-1: Secure Product Development Lifecycle Requirements (Formerly Part 4-1: Product Security Development Life-Cycle)", International Society of Automation, Zugriff am 10. Dezember 2023; und "IEC 62443-4-1:2018", International Electrotechnical Commission, January 15, 2018, IEC.

¹⁷ International Society of Automation-Global Cybersecurity Alliance, Quick Start Guide: An Overview of ISA/IEC 62443 Standards, Juni 2020.

¹⁸ Medical Device Coordination Group, MDCG 2019-16-Guidance on Cybersecurity for Medical Devices, Juli 2020.

¹⁹ Murugiah Souppaya, Karen Scarfone, und Donna Dodson, "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities", NIST, Februar 2022.

²⁰ "Microsoft Security Development Lifecycle (SDL)", Microsoft, Zugriff am 29. Dezember 2022.

²¹ Microsoft Download Center, abgerufen am 29. Dezember 2022.

²² "Security Engineering Portal", Microsoft, Zugriff am 29. Dezember 2022.

²³ "Security DevOps", Microsoft, abgerufen am 29. Dezember 2022.

²⁴ "ISO/IEC 27034-1:2011 Information Technology-Security Techniques-Application Security", ISO, Zugriff am 10. Dezember 2023.

²⁵ SAFECode, Fundamental Practices for Secure Software Development, dritte Ausgabe, März 2018.

²⁶ SAFECode und Cloud Security Alliance, Practices for Secure Development of Cloud Applications, 5. Dezember 2013.

²⁷ SAFECode, Practical Security Stories and Security Tasks for Agile Development Environments, 17. Juli 2012.

²⁸ "Cybersecurity Labelling Scheme (CLS)", Cyber Security Agency of Singapore, Zugriff am 10. Dezember 2023.

²⁹ "ANSI/ISA-62443-4-2-2018, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS Components, 2nd Printing", International Society of Automation, Zugriff am 10. Dezember 2023.

³⁰ ETSI, Cyber Security for Consumer Internet of Things: Baseline Requirements, März 31, 2021.

³¹ "ISO/IEC 27400:2022-Cybersecurity-IoT Security and Privacy-Guidelines", ISO, Zugriff am 10. Dezember 2023.

³² "ISO/SAE 21434:2021 Road Vehicles-Cybersecurity Engineering", ISO, Zugriff am 10. Dezember 2023.

³³ "UL 2900-1 Ed. 1-2017 - Standard for Software Cybersecurity for Network-Connectable Products, Part 1: Allgemeine Anforderungen", ANSI Webstore, Zugriff am 10. Dezember 2023.

³⁴ "Internet of Things (IoT) Cybersecurity Certification", CTIA Certification, abgerufen am 10. Dezember 2023.

³⁵ "Product Security and Telecommunications Infrastructure Act 2022", legislation.gov.uk, Zugriff am 10. Dezember 2023.

³⁶ "European Cyber Resilience Act (CRA)", abgerufen am 10. Dezember 2023.

³⁷ "NISTIR 8259 Series", NIST, Zugriff am 10. Dezember 2023.

³⁸ "California SB-327 Information Privacy: Vernetzte Geräte", kalifornische Legislative, 28. September 2018.

³⁹ A-Engrossed House Bill 2395, Oregon Legislature, abgerufen am 10. Dezember 2023.

⁴⁰ Purple Book Community, "Capability Maturity Model and Security Metrics", in The Purple Book of Software Security, abgerufen am 10. Dezember 2023.

⁴¹ "Scalable Software Security Maturity Model (S3M2)", Purple Book Community, Zugriff am 10. Dezember 2023.

⁴² "CMMI Development", CMMI Institute, Zugriff am 10. Dezember 2023.

⁴³ Synopsys, BSIMM 13: Trends & Insights Report 2022, 2022.

⁴⁴ "OWA Software Assurance Maturity Model", OWASP, Zugriff am 10. Dezember 2023.