Im April 2023 veröffentlichte CISA einen neuen gemeinsamen Leitfaden für Softwaresicherheit mit dem Titel Das Gleichgewicht des Cybersicherheitsrisikos verschieben: Security-by-Design- und Default-Prinzipien. Der Leitfaden wurde in Zusammenarbeit mit neun verschiedenen Behörden erstellt, darunter unter anderem der NSA, dem Australian Cyber Security Centre (ACSC) und dem deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI). Die Tatsache, dass mehrere Behörden aus der ganzen Welt bei der Erstellung eines Cybersicherheitsleitfadens zusammengearbeitet haben, sollte ein starker Beweis dafür sein, welche Bedeutung das Thema Cybersicherheit derzeit weltweit hat.
Jen Easterly, CISA-Direktorin, hat kürzlich in einer Rede vor Studenten und Lehrkräften der Carnegie Mellon University in Pittsburgh ihre Gedanken zum Thema Cybersicherheit geäußert. Nach Ansicht des CISA-Direktors sollten diese Leitprinzipien dazu beitragen, die globale Softwareindustrie in den kommenden Jahren zu leiten:
- Die Sicherheitslast sollte niemals allein beim Kunden liegen. Softwarehersteller sollten die Verantwortung für ihre Produkte und ihren Code übernehmen.
- Technologiehersteller sollten radikale Transparenz als Verpflichtung zur Verantwortung für ihre Produkte begreifen.
- Technologiehersteller sollten sich auf die Entwicklung sicherer Produkte konzentrieren und solche entwickeln, die sowohl konstruktionsbedingt als auch standardmäßig sicher sind.
Der CISA-Leitfaden greift diese Grundprinzipien auf und erweitert sie, einschließlich einer umfassenden Liste praktischer Vorschläge, die Softwarehersteller ergreifen können, um sicherere Produkte auf den Markt zu bringen.
Es ist interessant festzustellen, dass viele der expliziten Vorschläge darauf basieren Das SSDF-Framework des NIST aber praktischer und weniger freiwillig formuliert.
Einer der Vorschläge im Leitfaden, der sich direkt auf radikale Transparenz bezieht, besteht darin, dass Softwarehersteller die Produktion eines einbeziehen SBOM in ihrem SDLC, um Einblick in die Komponenten ihrer Software zu ermöglichen.
Aber reicht es wirklich aus, eine SBOM zu erstellen und diese überhaupt zu veröffentlichen? Was kann ein Softwarehersteller oder ein Softwarekonsument eigentlich mit einer SBOM-JSON- oder XML-Datei machen?
In diesem Artikel befassen wir uns mit den Verwendungsmöglichkeiten, die eine SBOM heute einem Softwarehersteller bieten kann, mit den Informationen, die einer SBOM hinzugefügt werden können, um sie anzureichern, und mit den Geschäftsinformationen, die durch die Untersuchung derart angereicherter Dokumente gewonnen werden können. Wir werfen einen kurzen Blick auf die Compliance-Seite der Verwendung eines SBOM und zeigen, wo Ihre Haftung als Softwarehersteller, Softwareaggregator oder Open-Source-Betreuer liegt. Abschließend sprechen wir über das Risikomanagement und darüber, wie die CISA-Prinzipien „Secure by Design“ und „Secure by Default“ mit der Einhaltung von Cybersicherheitsvorschriften und einem aufgeklärten Risikomanagement in Einklang stehen.
Nicht alle SBOMs wurden gleich erstellt
Heutzutage stehen viele Tools für die Erstellung von SBOMs zur Verfügung, von Open-Source- bis hin zu proprietären Lösungen. Eine Person oder ein Unternehmen, das die Erstellung von SBOMs in seine SOP einbeziehen möchte, könnte dies problemlos tun. Man konnte zwischen den verschiedenen wählen Normen diejenige, die ihren Bedürfnissen am besten entspricht, aber selbst dann stehen Ihnen möglicherweise viel zu viele Tools zur Verfügung, um eine fundierte Entscheidung zu treffen. Was könnte man also mehr suchen, wenn man sich für genau das Richtige entscheidet? SBOM-Generierung Werkzeug für dich?
Prüfen Sie zunächst, welche Informationen bei der Erstellung der SBOM enthalten oder weggelassen sind. Eine Stückliste, die Werkzeuge und Code enthält, die Teil des Entwicklungsprozesses, aber nicht Teil des eigentlichen Produkts waren, würde wahrscheinlich viele redundante Informationen enthalten, die nur sehr schwer aus der resultierenden Datei „bereinigt“ werden können, damit Sie sie behalten können die relevantesten Informationen. Ebenso würden Tools oder Code, die nicht enthalten sind oder absichtlich weggelassen wurden, auffällig fehlen, wenn Sie beispielsweise nach Schwachstellen suchen möchten.
Die Liste der Softwarebestandteile und -abhängigkeiten ist an und für sich größtenteils bedeutungslos. Es hat nur einen sehr geringen Zweck, der über das hinausgeht, was Sie damit machen können. Die häufigste Verwendung von SBOMs besteht heute darin, die Softwarekomponenten zu scannen, um eine Liste von Schwachstellen zu erhalten, die sich auf Ihr Produkt auswirken könnten.
Es ist wichtig zu bedenken, dass etwa 95 % der von Ihnen entdeckten Schwachstellen in Ihrem Produkt nicht ausnutzbar sind. Der Trick besteht darin, diese schwer fassbaren 5 % zu finden, einen Arbeitsplan zu erstellen und mit der Beseitigung dieser ausnutzbaren Schwachstellen zu beginnen. Wie erkennt man, was ausnutzbar ist und was nicht? Das ist die große Frage, die Sicherheits- und Technikleuten schlaflose Nächte bereitet. Ein aktueller Vorschlag ist die Verwendung einer Lösung namens ÄRGERN – ein Vulnerability Exploitability eXchange, eine Form einer Sicherheitsberatung, deren Ziel darin besteht, die Ausnutzbarkeit von Komponenten mit bekannten Schwachstellen im Kontext des Produkts, in dem sie verwendet werden, zu kommunizieren. Ein Großteil der Arbeit, den Heuhaufen an Schwachstelleninformationen zu durchforsten und die Nadel der ausnutzbaren Schwachstellen zu finden, bleibt größtenteils dem Ingenieurteam überlassen. Denn wer kennt sein Produkt besser als die Leute, die es programmiert haben?
Es gibt jedoch noch andere Dinge, die Sie tun können, insbesondere wenn es um vererbte Schwachstellen geht, die von übergeordneten Images Ihres Docker-Images oder von Abhängigkeiten weit hinten in Ihrer Abhängigkeitskette herrühren. Verwendung von Open-Source-Tools wie Elternbild Sie können herausfinden, welche Schwachstellen mit dem übergeordneten Image einhergingen und welche eine direkte Folge Ihres Codes waren. Dadurch sollte ein potenziell großer Pool an Schwachstellen beseitigt und die Sichtungsarbeit erleichtert werden. Es ist auch eine gute Idee, verschiedene Hinweise zu verschiedenen Schwachstellen zu verwenden, denn sobald Sie festgestellt haben, dass eine Schwachstelle nicht ausnutzbar ist, ist es sinnvoll, andere in Ihrem Team oder Ihre Benutzer darüber zu informieren, damit Sie nicht in jeder Version dieselbe Schwachstelle überprüfen Ihres Produkts, bei dem Sie nicht einmal das Modul geändert haben, in dem es gefunden wurde. Es ist außerdem ratsam, Ihre Open-Source- und Drittanbieter-Abhängigkeiten zu verfolgen, damit Sie den Code in Ihrem Produkt aktualisieren können, sobald sie ausnutzbare Schwachstellen gefunden und behoben haben sicher, dass Sie auch vor diesem besonderen potenziellen Problem geschützt sind.
Was können Sie einer SBOM noch hinzufügen?
Wie oben erwähnt, werden SBOMs heutzutage am häufigsten als Checkliste für das Scannen von Schwachstellen verwendet. Mithilfe verschiedener frei verfügbarer Datenbanken wie der NVD (National Vulnerability Database) können Sie eine Liste von Komponenten scannen, ähnlich der, die von einem SBOM bereitgestellt wird, und sehen, welche Schwachstellen darin enthalten sind. Sobald Sie eine Liste der Schwachstellen haben, können Sie diese nach Schweregrad sortieren, prüfen, ob Korrekturen vorhanden sind usw.
Eine weitere nützliche Informationsebene über Ihre Komponenten ist deren Lizenz. Viele Open-Source-Komponenten verfügen über eine Lizenz, die nicht mit der kommerziellen Nutzung kompatibel ist. Es ist wichtig, sicherzustellen, dass alle Ihre Open-Source-Komponenten, auch solche, die Sie nicht selbst eingebunden haben, sondern von einer anderen Komponente eingebunden wurden, mit dem, was Sie machen möchten, im Hinblick auf ihre Lizenz kompatibel sind.
Ein letzter Vorschlag besteht darin, Open-Source-Sicherheitsindikatoren für Ihre Abhängigkeiten zu befolgen, z OpenSSF-Scorecard. Ein objektives, relativ einfaches Maß für den Zustand der Cybersicherheit von Open-Source-Bibliotheken könnte eine große Hilfe bei der Entscheidung sein, welche Bibliotheken in Ihr Produkt einbezogen oder weggelassen werden sollen. Diese Bewertungen in Kombination mit dem Schweregrad der Schwachstellen sind eine gute Möglichkeit, die Schwachstellen einzuordnen, an denen Sie zuerst arbeiten möchten.
Risikomanagement als Business-Intelligence-Übung
Es gibt mehrere Sicherheitsrisiken Heutzutage muss sich jeder Softwarehersteller damit auseinandersetzen. Zwischen Malware, Krypto-Minern, Passwort-Stealern und Ransomware ist es ein Wunder, dass Hersteller sich sicher fühlen, irgendetwas auf den Markt zu bringen. Niemand kann alles auf einmal bewältigen, daher erstellen Unternehmen Bedrohungsmodelle und versuchen, ihr Risiko entsprechend ihrer Einschätzung ihrer schwächsten Glieder zu steuern. Der einfachste erste Schritt besteht darin, sicherzustellen, dass Ihr Code und Entwicklungsprozess allen relevanten Vorschriften und Best Practices entspricht. Nists SSDF und OpenSSFs SLSA sind ein guter Ausgangspunkt, ebenso wie die US-Anforderungen für Dinge wie eine SBOM. Die Einhaltung der Vorschriften und Best Practices könnte zumindest eine relative Sicherheit vor Rechtsstreitigkeiten im Rahmen des Gesetzes versprechen Sicherer Hafen Programm. Aber das ist nur der Anfang.
Der CISA-Leitfaden ermutigt Hersteller, bei der Entwicklung ihrer Produkte zunächst die Sicherheit im Auge zu behalten. Einige „zusätzliche“ Sicherheitsmaßnahmen nach Fertigstellung des Produkts können einige grundlegende Schwachstellen, die Teil der Produktarchitektur sind, nicht beheben. Dem Leitfaden zufolge handelt es sich bei Secure-by-Design-Produkten um Produkte, bei denen die Sicherheit der Kunden ein zentrales Geschäftsziel und nicht nur ein technisches Merkmal ist. Auch die Hersteller werden ermutigt, sich zu engagieren radikale Transparenz und Rechenschaftspflicht. Das bedeutet unter anderem, sicherzustellen, dass Schwachstellenwarnungen und damit verbundene allgemeine Schwachstellen und Gefährdungen (CVE) Die Aufzeichnungen sind vollständig und korrekt. Dies bedeutet auch, dass die Weitergabe der Komponenten des Codes, seiner Abhängigkeiten und Schwachstellen gefördert wird, um Benutzern und Kunden zu zeigen, dass der Hersteller sich zumindest potenzieller Probleme im Produkt bewusst ist.
Laut Wikipedia, Business Intelligence (BI) umfasst die Strategien und Technologien, die Unternehmen für die Datenanalyse und Verwaltung von Geschäftsinformationen. Wie Sie sich vorstellen können, sind das Sammeln einer SBOM für jeden Build sowie des Schwachstellenberichts, der Lizenzinformationen und der Hinweise, die aufschlüsseln, welche Schwachstellen ausnutzbar sind und welche nicht, eine Menge Informationen. Die Anzahl der Informationspunkte erhöht sich, wenn Sie die Lebensdauer eines typischen Softwareprodukts berücksichtigen und die Tatsache, dass Sie diese Informationen für jeden Code oder jedes Tool von Drittanbietern haben möchten, das Sie verwenden, sowie für Open-Source-Pakete, die Sie einbinden. direkt oder vorübergehend. Um das Ganze auf eine Weise zu verstehen, die von den Sicherheitsverantwortlichen der Organisation (wahrscheinlich dem CISO und den ihm unterstellten Personen) genutzt werden kann, benötigen Sie ein System, eine einzige „Pane-of-Glass“-Plattform Damit können Sie all diese Informationen organisieren, effektiv durchsuchen und bei Bedarf in nützlichen Berichten präsentieren. Um nur ein Beispiel dafür zu nennen, wie wichtig eine BI-Plattform für eine Cybersicherheitsplattform sein könnte: Stellen Sie sich Folgendes vor: Log4J Drama des letzten Jahres. Wäre es nicht toll, alle Ihre Produkte, einschließlich Abhängigkeiten und Tools von Drittanbietern, mit ein paar Tastendrücken nach dieser „neuen“ Bedrohung zu durchsuchen? Wie wäre es mit der Überprüfung auf das Vorhandensein eines anderen neuen bedrohlichen CVE, der gerade herausgekommen ist? Oder erstellen Sie einen Bericht darüber, wie die Gesamtzahl der Schwachstellen in Ihrem Unternehmen im Laufe der Zeit zunehmend abnimmt (oder zumindest nicht zunimmt). Das ist die Art von nützlichen „Big Picture“-Informationen, die nur ein BI-System auf einer mit Cybersecurity SBOM angereicherten Erfassungsplattform bieten kann.
Erst wenn Sie über alle relevanten Informationen verfügen, können Sie Ihr Risiko wirklich einschätzen, sowohl in Ihrem aktuellen Code, in Ihren Abhängigkeiten als auch in der Entscheidung, Tools oder Codes von Drittanbietern in Ihr Produkt aufzunehmen oder wegzulassen. Bei kontinuierlicher Ausführung können Sie diese Risikobewertung auch dazu verwenden, Builds zu überwachen und sie von der Produktion oder Auslieferung abzuhalten, wenn verdächtige Aktivitäten entdeckt werden.
In die Zukunft schauen
Die Technologie schreitet ständig voran. Waren einst monolithische Codeprojekte, die auf Servern im Büro des Unternehmens lagen, die Norm, sind es heute die Multi-Cloud-Microservices-Architektur und LLMs, die den Weg weisen. SBOMs müssen sich weiterentwickeln, um alle von der Software verwendeten komplexen Architekturen oder Infrastrukturen unterstützen zu können, damit sie relevant und nützlich bleiben. CycloneDX von OWASP arbeitet beispielsweise bereits an der Einbeziehung ML-Transparenz in ihrem SBOM-Format. Das gleiche Format stellt auch sicher, dass bei der Planung für die Zukunft VEX-Funktionen und eine SBOM-Sharing-API einbezogen werden. Ich gehe davon aus, dass immer mehr Plattformen wie die von erstellte Schreiber werden für die Sammlung und Weitergabe sicherheitsrelevanter Informationen, einschließlich SBOMs, erstellt, sowohl aus regulatorischen Gründen als auch wegen des Nutzens und Werts, den solche angereicherten Informationen für die Organisationen haben, die sie ordnungsgemäß nutzen.
Die Plattform von Scribe steht kurz vor der Veröffentlichung eines neuen BI-Tools als Teil der bestehenden Sicherheitsplattform mit allen von mir vorgeschlagenen Funktionen und mehr. Ich ermutige Sie dazu Versuche esSehen Sie sich den Nutzen dieser im Laufe der Zeit gesammelten Informationen an und finden Sie heraus, wofür Sie die Informationen verwenden können. Unabhängig davon, ob Sie sich für die Integration der Scribe-Plattform in Ihr SDLC entschieden haben oder nicht, ist der Wettlauf um ein sichereres Ökosystem und ein umfassenderes, nützlicheres SBOM noch lange nicht vorbei. Es ist besser, jetzt auf den Transparenzwagen zu steigen, als sich radikale Transparenz durch Regulierung oder Marktdruck aufzwingen zu lassen.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
