Im September 2022 veröffentlichte das United States Office of Management and Budget (OMB) eine wegweisendes Memo bezüglich der Schritte, die erforderlich sind, um Ihre Software-Lieferkette auf ein für die US-Bundesregierung akzeptables Maß zu sichern. Jedes Unternehmen, das mit der Regierung und einer Bundesbehörde, die Software herstellt, Geschäfte machen möchte, muss die darin festgelegten Anforderungen und Fristen einhalten M-22-18-Memo.
M-22-18 konzentrierte sich auf die Sicherheit und Integrität der Software-Lieferkette und legte dabei besonderes Augenmerk auf die Rolle von SBOMs. Es enthielt eine Liste von Anforderungen und einen Zeitplan für die Umsetzung der erforderlichen Schritte zur Einhaltung der Vorschriften.
In dem Memo wurden zwei Hauptdokumente des NIST festgelegt: das Secure Software Development Framework (SSDF), SP800-218 und Sicherheitsleitfaden für die Software-Lieferkette als NIST-Leitfaden zur sicheren Softwareentwicklung. In dem Memo wird auch die Verantwortung der Softwarehersteller dargelegt, selbst zu bestätigen, dass sie die NIST-Richtlinien einhalten, bevor Bundesbehörden ihre Produkte verwenden dürfen. Diese Selbstbescheinigung hat in Form einer unterschriebenen Selbstbescheinigung „gemeinsames Formular“ zu erfolgen. Für drei Kategorien von Software ist dieses Selbstbescheinigungsformular erforderlich: der Kauf neuer Software, Upgrades größerer Versionen und Softwareverlängerungen.
Gemäß M-22-18 musste CISA innerhalb von 120 Tagen ab dem Datum dieses Memorandums (14. September 2022) dieses standardmäßige „gemeinsame Formular“ für die Selbstbescheinigung erstellen. Diese 120 Tage sind im Januar 2023 vergangen, aber die Form ist immer noch vorhanden Entwurfsformular obwohl die Kommentierungsfrist dafür am 26. Juni 2023 endete. Ungefähr zu diesem Zeitpunkt wies das OMB-Memo die Behörden ursprünglich an, mit der Sammlung von Attesten für kritische Software zu beginnen.
Basierend auf einigen Kommentaren, die zu diesem gemeinsamen Bescheinigungsformular eingegangen sind, hielt OMB es für angebracht, am 22. Juni 18 eine Änderung zu M-9-2023 zu veröffentlichen. Diese Änderung trägt den Titel M-23-16. Das neue Memorandum verlängert den am M-22-18 veröffentlichten Zeitplan für Agenturen, Bescheinigungen von Softwareherstellern einzuholen. Nun sind die Agenturen verpflichtet, diese einzusammeln Selbstbescheinigung „allgemeine Form“ von Softwareherstellern für „kritische“ Software spätestens drei Monate nach Genehmigung des gemeinsamen CISA-Selbstbescheinigungsformulars durch OMB. Alle anderen Softwarehersteller haben nach Genehmigung des Selbstbescheinigungsformulars durch OMB sechs Monate Zeit.
Seit dem Da das Standard-Selbstbescheinigungsformular im Mittelpunkt zu stehen scheint, wollen wir uns etwas genauer ansehen, was darin enthalten ist. Wir schauen uns auch an, wer genau unterschreiben soll und was eine solche Unterschrift bedeuten würde.
Gemeinsames Formular zur sicheren Software-Selbstbescheinigung
Folgt man der Regulierungskette von EO 14028 über die Leitlinienpapiere des NIST bis hin zu den OMB-Memos, ist klar, dass die Regierung darauf abzielt, alle, sowohl Bundesbehörden als auch Unternehmen des Privatsektors, davor zu schützen Schwachstellen in der Software-Lieferkette und Einbrüche. Da der Privatsektor (nach Ansicht der Regierung) nicht genug dagegen unternommen hat, hat die Regierung sich vorgenommen, neue Vorschriften zu schaffen, die jeder (der an die Bundesregierung verkauft) befolgen muss.
Selbst wenn Sie (noch) nicht an die Bundesregierung verkaufen, ist es natürlich in Ihrem Interesse, diese Regeln zu befolgen und sich selbst zu bestätigen, dass Sie „sicher“ sind, da solche Unternehmen ein attraktiverer Geschäftspartner sein werden. Wer möchte schon mit einem Unternehmen Geschäfte machen, das nicht bestätigen kann, dass es sein Möglichstes tut, um sein Produkt und seine Benutzer zu schützen?
Da wir bereits festgestellt haben, dass die NIST-Leitlinien die Grundlage für die neue Verordnung und die Best Practices bilden, ist es nicht verwunderlich, dass dieselben Vorschläge, die beispielsweise in der enthalten sind, aufgegriffen werden SSDF erscheinen auch im Selbstbescheinigungsformular.
Hier ist ein kurzes Beispiel aus dem Entwurfsdokument:
Entnommen aus dem Entwurf des Secure Software Self-Attestation Common Form
Links sehen wir die Anforderung, gefolgt vom zugehörigen EO-Abschnitt und dann den SSDF-Praktiken und -Aufgaben. Dies ist eine ziemlich umfassende Liste von Anforderungen (eineinhalb Seiten), die nicht unbedingt vollständig klar wäre, wenn der Leser nicht im Bereich Cybersicherheit und/oder DevOps oder DevSecOps tätig ist.
Das Dokument erfordert, dass der Unterzeichner des Unternehmens PERSÖNLICH bescheinigt, dass alle im Formular dargelegten Anforderungen konsequent eingehalten werden und dass das Unternehmen die betroffenen Behörden benachrichtigt, wenn ein Element auf der Liste nicht mehr gültig ist.
In dem Dokument wird nicht angegeben, wer im Unternehmen das Dokument unterzeichnen soll. Da dieses Formular jedoch die Voraussetzung dafür ist, dass das Unternehmen mit der Bundesregierung und ihren Behörden Geschäfte tätigen kann, liegt es nahe, dass der CEO die Person ist, die die Verantwortung übernehmen sollte Hier. Der CEO wird es wahrscheinlich nicht blind unterschreiben und seinen CTO und CISO bitten, (möglicherweise schriftlich) zu überprüfen, ob das Unternehmen alle diese Richtlinien und Anforderungen befolgt.
Da es kein etabliertes Produkt oder Betriebsverfahren gibt, das alle diese Anforderungen erfasst und bescheinigt, muss in gewisser Weise jedes Unternehmen, das den Vertrag unterzeichnet, für sich selbst „das Rad neu erfinden“ und hoffen, dass nichts Schlimmes passiert.
Wenn etwas Schlimmes passiert, würde die Bundesregierung den Unterzeichner auffordern, zu zeigen und zu beweisen, dass er alle Anforderungen der Formulare belegen kann.
Was passiert, wenn ich nicht unterschreibe?
Erstens ist diese ganze Bescheinigungssache derzeit nur relevant, wenn Ihre Software von einer Bundesbehörde verwendet wird, wenn Sie beabsichtigen, Ihre Software an die Bundesregierung zu verkaufen, oder wenn Ihre Software von einem Anbieter verwendet wird, dessen Software entweder im Einsatz ist oder an den Bund verkauft werden soll.
Beachten Sie, dass ich „aktuell“ gesagt habe, da alles darauf hindeutet, dass die SSDF-Konformität, entweder als Selbstbescheinigung oder in einer anderen überprüfbaren Form, zu einer neuen „Best Practice“ im Bereich der Softwareproduktion werden wird.
Wenn Sie also davon ausgehen, dass Ihr Unternehmen in die oben genannte Gruppe fällt und Sie es nicht schaffen, dieses Dokument mit gutem Gewissen zu unterzeichnen, ist noch nicht alles verloren. Solange Sie erklären können, wo der Mangel in der Bescheinigung liegt, und ein zufriedenstellendes Angebot abgeben können Aktionsplan und Meilensteine (POA&M) Die betreffende Bundesbehörde kann Ihr Produkt weiterhin kaufen/nutzen und in Ihrem Namen eine Verlängerung Ihrer Software bei OMB beantragen.
Die schlechte Nachricht ist, dass Sie mit oder ohne POA&M-Plan irgendwann ein vollständiges Bescheinigungsformular vorlegen müssen, was bedeutet, dass Sie vor einem Bundesgericht nachweisen müssen, dass alle im Formular erforderlichen Schritte von Ihrem Unternehmen befolgt wurden und dass Ihre Der Softwareentwicklungsprozess ist mindestens so sicher wie die Anforderungen des Formulars.
Die einzige Software, die derzeit von dieser Form der Bescheinigung ausgenommen ist, ist von Bundesbehörden entwickelte Software und frei verfügbare Software, auch Open-Source-Software genannt. Natürlich die meisten Sicherheit der Software-Lieferkette Lücken können in irgendeiner Weise auf ein Open-Source-Paket in Ihrem Code zurückgeführt werden, aber es ist ein echtes Problem, Open-Source-Entwickler und -Betreuer, die kostenlos arbeiten, dazu zu zwingen, eine rechtsverbindliche Garantie für ihre Software zu geben. Es sollte jedem überlassen bleiben, der Open-Source-Software verwendet, deren Sicherheit sowohl im Allgemeinen als auch im Hinblick auf die Software, in die sie eingebettet ist, im Besonderen zu überprüfen.
Worst-Case-Szenario
Diese ganze Sicherheitsgewissenhaftigkeit in der Software-Lieferkette begann nach dem berühmten SolarWinds hacken. Ohne auf allzu viele Details einzugehen: Zum Zeitpunkt des Hacks waren mehr als 18,000 Kunden des Unternehmens betroffen, darunter neun Bundesbehörden.
Erst jetzt, Jahre später, sehen wir einige rechtliche Konsequenzen aus diesem Vorfall. Die S, US-Börsenaufsichtsbehörde, ist hinter der Firma her als Ganzes sowie nach mehreren C-Level-Führungskräften. Dies kann als Beispiel für die Absichten der Regierung angesehen werden, sollte ein solcher oder ein ähnlicher Vorfall einem Softwarehersteller widerfahren, der sichere Entwicklungspraktiken bescheinigte und dennoch Opfer eines Hackerangriffs wurde.
Im Fall von SolarWinds unterstützt das Unternehmen jeden Mitarbeiter voll und ganz, der von solchen rechtlichen Schritten betroffen ist. Wenn man das US-amerikanische Rechtssystem kennt, dürften solche Fälle Jahre dauern und viel Geld kosten. Bußgelder sind nicht ausgeschlossen und könnten nach Schätzungen Millionensummen erreichen erlittene Schäden.
Sie können sich vorstellen, dass nicht alle Unternehmen, insbesondere kleine und mittlere, ihre Mitarbeiter so streng schützen wie SolarWinds. Das Problem besteht darin, dass, wenn es sich bei der beschuldigten Partei um den CEO des Unternehmens handelt, die reale Gefahr besteht, dass das Vertrauen des Marktes in das Unternehmen und sein Produkt erheblich beeinträchtigt wird. Sich der SEC ohne die Unterstützung eines großen Unternehmens mit großen finanziellen Mitteln zu stellen, könnte sowohl einen ahnungslosen CEO als auch sein Unternehmen ruinieren. Natürlich geht es darum, die Menschen dazu zu bringen, ihre Verantwortung für die Sicherung der Entwicklung ernst zu nehmen, aber die Angst könnte die Menschen dazu verleiten, sich auf die Seite der Selbsterhaltung zu stellen. Das bedeutet, dass Menschen Cybersicherheitsvorfälle lieber verheimlichen würden, wenn sie der Meinung sind, dass sie einen potenziellen SEC-Fall nicht gewinnen können, oder weil sie befürchten, dass die Kosten und die schlechte Publizität eines solchen Falles so hoch wären, dass es unabhängig vom Ausgang des Gerichtsverfahrens besser ist, sie zu verheimlichen.
Wie kann ich unterschreiben?
Der SSDF-Leitfaden des NIST ist voller Vorschläge und Best Practices, aber nur wenig praktisch. Da jedes Unternehmen einzigartig ist, ist es ziemlich schwierig, ein Produkt oder System zu entwickeln, das für alle funktioniert. In diesem Fall springt der Privatsektor ein, um das Vakuum zu füllen und ein Ökosystem zu schaffen, das Sie bei der Einhaltung der Anforderungen unterstützt.
Zum Beispiel, Schreiber baute eine Plattform basiert auf dem Konzept, Bescheinigungen zu erstellen, zu signieren und die Möglichkeit zur Verifizierung anzubieten. Wir werden in Kürze ein maßgeschneidertes Dokument veröffentlichen CISA-Selbstbescheinigungsformular, um zu zeigen, wie die Scribe-Lösung Ihnen in jedem Abschnitt der Anforderungen helfen kann. Bleiben Sie dran.
Ausprobieren Die Plattform von Scribe ist kostenlos. Ich ermutige Sie, es auszuprobieren und zu sehen, wie Sie die Plattform an Ihre Anforderungen anpassen und gleichzeitig die Selbstbescheinigung von CISA mit gutem Gewissen unterzeichnen können.
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
