Kontinuierliche Sicherheit: Eine integrale Praxis für die Sicherheit der Software-Lieferkette

Dieses ist der zweite Teil einer Artikelreihe, in der die neuen NIST SP 800-218-Richtlinien untersucht werden. Der erste Artikel kann gefunden werden Download.

Kontinuierliche Sicherheit:
Eine ganzheitliche Praxis für die Sicherheit der Software-Lieferkette

Wie wir in unserem vorherigen Artikel besprochen haben, werden die vom US-amerikanischen National Institute of Standards and Technology (NIST) festgelegten Richtlinien die Art und Weise, wie Softwareprodukte und -dienstleistungen an die Regierung der Vereinigten Staaten geliefert werden, dramatisch verändern. 

Insbesondere NIST-SP 800-218 legt eine Reihe hochgradig sicherer Softwareentwicklungspraktiken fest, die in jeden Software Development Life Cycle (SDLC) integriert werden sollen. Die Einbeziehung dieser Praktiken in die gesamte Software-Lieferkette dürfte zu sichereren Produkten und Dienstleistungen führen, die nicht nur an die US-Regierung, sondern letztendlich branchenübergreifend und rund um den Globus geliefert werden. 

In diesem Artikel betrachten wir die entscheidende Rolle von Continuous Assurance (CA) bei der Erfüllung dieser neuen Anforderungen. 

Überblick: Was ist Continuous Assurance und wie funktioniert es? 

CA ist ein Konzept und eine Reihe von Lösungen, die sich in der Entwicklung befinden und die bereits bekannten Konzepte der DevOps-Disziplin für kontinuierliche Integration, Entwicklung und Tests ergänzen. CA sammelt detailliert Beweise über alle Ereignisse im Entwicklungslebenszyklus, einschließlich der Produkterstellung und -bereitstellung, die sich auf die Sicherheit des letztendlichen Softwareprodukts auswirken könnten. Es ist ein Mittel für Verbraucher von Software (z. B. Benutzer, Käufer und andere Risikobeteiligte), das Risiko der von ihnen verwendeten Produkte zu kontrollieren. 

Heutzutage nutzen Unternehmen eine Vielzahl von Sicherheitstools, um die Sicherheit der von ihnen entwickelten Softwareprodukte zu verbessern. Allerdings verwenden sie selten eine Gesamtrichtlinie, um den Standard für die konsistente Nutzung dieser Tools festzulegen. Wenn die Verbraucher von Softwareprodukten außerdem von einer anderen Organisation stammen, verfügen sie nicht über die Informationen oder Tools, die erforderlich sind, um die Messlatte für ihr Risiko festzulegen. Kurz gesagt: Dies ist der blinde Fleck der Software-Lieferkette, den CA beseitigen möchte. 

Das unmittelbare Ergebnis von CA ist ein Mittel, um sicherzustellen, dass Softwareprodukte nicht manipuliert wurden und dass während der Entwicklung kritische sicherheitsrelevante Tests durchgeführt wurden, aber es kann noch mehr daraus gewonnen werden.

Um Manipulationen durch Angreifer oder Vertuschungen versteckter Komponenten zweifelhafter Herkunft, beispielsweise aus verbotenen Ländern, durch Anbieter entgegenzuwirken, wandelt CA die gesammelten Beweise in eine manipulationssichere Bescheinigung um, indem die Informationen kryptografisch signiert und in einem unveränderlichen Speicher gespeichert werden eine isolierte sichere Umgebung. 

Indem die gesammelten Beweise maschinenlesbar gemacht werden, kann eine Richtlinien-Engine die vom Risikobeteiligten festgelegten Normen oder Regeln für jede Produktversion oder jedes Update kontinuierlich validieren. Auf diese Weise können Stakeholder sicher sein, dass ein Produkt seinen Sicherheitsstandards entspricht. 

Konzeptionell verbessert der Einsatz der CA-Methodik auch die Produktqualität. Durch die Steuerung des Basisstandards für Codeüberprüfung und Sicherheitstests mit einer zentralen Richtlinie für die Pipelines eines bestimmten Produkts würden Inkonsistenzen und Ad-hoc-Änderungen an ordnungsgemäßen Prozessen beseitigt.

Warum kontinuierlich?

Sicherheitskonfigurationen im Entwicklungsprozess sind nichts Neues. Beispielsweise haben Sie möglicherweise bereits festgestellt, dass keine Binärdatei ohne Schwachstellenscan in die Produktion geht. 

Heutzutage werden die Softwarebereitstellungszyklen immer kürzer. Dadurch kann es zu Abstrichen kommen. Möglicherweise wird die Codeüberprüfung übersprungen oder Sicherheitstests oder wichtige Verfahren werden möglicherweise nicht durchgeführt. Darüber hinaus werden ständig neue CVEs und Exploits gemeldet und ständig neue Komponentenversionen veröffentlicht. 

Alle diese Faktoren zusammen erfordern, dass wir Komponenten kontinuierlich anhand des festgelegten Sicherheitsstandards testen, um sicherzustellen, dass die verwendeten Prozesse weiterhin der Sicherheitsrichtlinie entsprechen. 

Die Sicherheitsrichtlinien werden vom Risikoinhaber festgelegt. Hier sind einige Beispiele für Richtlinienregeln, die verwendet werden könnten: 

• Erlauben Sie nur die Verwendung von Open-Source-Paketen aus einer genehmigten Liste
• Für jede Pull-Anfrage sind zwei Prüfer erforderlich.
• Stellen Sie sicher, dass alle proprietären Komponenten im endgültigen Artefakt auf die Quellcodeverwaltungs-Repositorys zurückgeführt werden können.

Die Messlatte für Softwaresicherheit höher legen

Angriffe auf die Softwarelieferkette verändern das erwartete Verhalten von Softwarekomponenten. Heutzutage beruhen diese Angriffe auf der mangelnden Fähigkeit sowohl der Softwarekonsumenten als auch der Softwarehersteller, die Integrität der Softwarekomponenten zu überprüfen. 

Durch das Signieren von Beweisen aus jedem Teil des Entwicklungslebenszyklus – von Open-Source-Abhängigkeiten bis zum Endprodukt – und den kontinuierlichen Vergleich dieser Beweise mit den Erwartungen werden Angreifer jedoch größere Schwierigkeiten haben, wenn sie versuchen, Dateien, Tools usw. zu manipulieren erwartetes Verhalten Ihrer CI/CD-Pipeline.     

Beweiserhebung: Beispiele und Empfehlungen

Hier sind einige Beispiele für Beweise, die entlang des SDLC gesammelt werden können:

Und hier sind die Arten von Richtlinien, die mithilfe dieser Beweise genutzt werden können:

Die Zukunft der kontinuierlichen Code-Sicherung

Im Secure Software Development Framework vom Februar 2022 (SSDF) schlägt das NIST vor, dass die Implementierung von Sicherheitstools im gesamten Entwicklungsprozess weitgehend auf Automatisierung basieren sollte. Unser Ansatz zur kontinuierlichen Sicherung steht im Einklang mit dieser Empfehlung. 

Auch wenn Sie sicher sind, dass alle Sicherheitsschritte und Schutzmaßnahmen korrekt konfiguriert wurden, müssen Sie dennoch die Mittel bereitstellen, um Kunden und Lieferanten zu versichern, dass Ihre Sicherheitsrichtlinien konsequent und kontinuierlich durchgesetzt werden. Alle Beteiligten, Softwarehersteller (Entwickler oder Anbieter) und Verbraucher (Benutzer oder Käufer) sollten in der Lage sein, die Beweise von jedem Glied in der Softwarelieferkette kontinuierlich und automatisch zu prüfen und zu verifizieren, um sicherzustellen, dass ihre eigenen Sicherheitskriterien erfüllt werden. 

Das Vertrauen in die Software-Lieferkette ist derzeit gering und dies gibt allen Beteiligten ständig Anlass zur Sorge. Um das Vertrauen in die Software-Lieferkette wiederherzustellen und nachweislich sicherere Produkte zu produzieren, ist es wichtig, die Sichtbarkeit der implementierten Sicherheitsmaßnahmen zu erhöhen und den Nachweis einer kontinuierlichen Code-Assurance zu erbringen.