En septembre 2022, l'Office of Management and Budget (OMB) des États-Unis a publié un mémo historique concernant les étapes nécessaires pour sécuriser votre chaîne d'approvisionnement en logiciels à un degré acceptable par le gouvernement fédéral américain. Toute entreprise souhaitant faire affaire avec le gouvernement et toute agence fédérale produisant des logiciels doit se conformer aux exigences et aux délais énoncés dans le Mémo M-22-18.
M-22-18 s'est concentré sur la sécurité et l'intégrité de la chaîne d'approvisionnement logicielle, en accordant une attention particulière au rôle des SBOM. Il comprenait une liste d'exigences et un calendrier pour la mise en œuvre des étapes nécessaires à la conformité.
Le mémo établissait deux documents principaux produits par le NIST : le cadre de développement logiciel sécurisé (SSDF), PS 800-218 et Guide de sécurité de la chaîne d’approvisionnement logicielle comme les conseils du NIST sur le développement de logiciels sécurisés. Le mémo souligne également la responsabilité des producteurs de logiciels d'attester eux-mêmes de leur conformité aux directives du NIST avant que les agences fédérales ne soient libres d'utiliser leurs produits. Cette auto-attestation prendra la forme d’un « formulaire commun » d’auto-attestation signé. Trois catégories de logiciels nécessitent ce formulaire d'auto-attestation : les achats de nouveaux logiciels, les mises à niveau de versions majeures et les renouvellements de logiciels.
M-22-18 exigeait que la CISA établisse ce « formulaire commun » standard d’auto-attestation dans les 120 jours à compter de la date de ce mémorandum (14 septembre 2022). Ces 120 jours se sont écoulés en janvier 2023 mais la forme est toujours en place. projet de formulaire même si la période de commentaires s'est terminée le 26 juin 2023. C'est à peu près à ce moment-là que le mémo de l'OMB a initialement ordonné aux agences de commencer à collecter des attestations pour les logiciels critiques.
Sur la base de certains des commentaires reçus pour ce formulaire d'attestation commun, l'OMB a jugé bon de publier une modification au M-22-18 le 9 juin 2023. Cette modification est intitulée M-23-16. Le nouveau mémorandum prolonge le délai publié le M-22-18 pour que les agences collectent les attestations des producteurs de logiciels. Les agences sont désormais tenues de collecter les auto-attestation « formulaire commun » des producteurs de logiciels pour les logiciels « critiques » au plus tard trois mois après l’approbation du formulaire commun d’auto-attestation CISA par l’OMB. Tous les autres producteurs de logiciels disposent d'un délai de six mois après l'approbation du formulaire d'auto-attestation par l'OMB.
Depuis cela Le formulaire standard d'auto-attestation semble occuper le devant de la scène, examinons ce qu'il contient un peu plus en détail. Nous verrons également qui est exactement censé le signer et que signifierait une telle signature.
Formulaire commun d’auto-attestation de logiciel sécurisé
En suivant la chaîne de réglementation allant de l'EO 14028 aux documents d'orientation du NIST en passant par les mémos de l'OMB, il est clair que le gouvernement vise à protéger tout le monde, tant les agences fédérales que les entreprises du secteur privé, contre vulnérabilités de la chaîne d'approvisionnement logicielle et les intrusions. Comme le secteur privé n'en a pas fait assez (de l'avis du gouvernement), celui-ci a décidé de créer de nouvelles réglementations que tous ceux qui vendent au gouvernement fédéral doivent se conformer.
Bien sûr, même si vous ne vendez pas (encore) au gouvernement fédéral, il est dans votre intérêt de suivre ces règles et d'attester vous-même que vous êtes « en sécurité », car ces entreprises deviendront un partenaire commercial plus attrayant. Qui voudrait faire affaire avec une entreprise qui ne peut pas confirmer qu'elle fait tout ce qu'elle peut pour protéger son produit et ses utilisateurs ?
Puisque nous avons déjà établi que les directives du NIST constituent la base de la nouvelle réglementation et des meilleures pratiques, il n'est pas surprenant que les mêmes suggestions qui apparaissent, par exemple, dans le SSDF apparaître également dans le formulaire d’auto-attestation.
Voici un court exemple tiré du projet de document :
Tiré du projet de formulaire commun d'auto-attestation de logiciel sécurisé
Nous pouvons voir l'exigence sur la gauche suivie de la section EO associée, puis des pratiques et tâches du SSDF. Il s'agit d'une liste d'exigences assez complète (une page et demie) qui ne serait pas nécessairement tout à fait claire si le lecteur n'est pas dans le domaine de la cybersécurité et/ou du DevOps ou du DevSecOps.
Le document exige que le signataire de l'entreprise atteste PERSONNELLEMENT que toutes les exigences décrites dans le formulaire sont systématiquement respectées et que l'entreprise informera les agences concernées si un élément de la liste n'est plus valide.
Le document ne précise pas qui dans l'entreprise est censé signer le document, mais comme ce formulaire est l'obligation pour l'entreprise de faire affaire avec le gouvernement fédéral et ses agences, il va de soi que le PDG est la personne qui devrait en assumer la responsabilité. ici. Le PDG ne le signera probablement pas aveuglément et ne demandera pas à son CTO et à son RSSI de vérifier (éventuellement par écrit) que l'entreprise respecte toutes ces directives et exigences.
Puisqu'il n'existe pas de produit ou de mode de fonctionnement établi pour recueillir et attester de toutes ces exigences, dans un sens, chaque entreprise signataire doit « réinventer la roue » pour elle-même et espérer que rien de grave ne se produise.
Si quelque chose de grave se produit, le gouvernement fédéral s'en prendra au signataire pour montrer et prouver qu'il peut sauvegarder toutes les exigences des formulaires.
Que se passe-t-il si je ne signe pas ?
Premièrement, toute cette question d'attestation n'est actuellement pertinente que si votre logiciel est utilisé par une agence fédérale, si vous avez l'intention de vendre votre logiciel au gouvernement fédéral ou, si votre logiciel est utilisé par un fournisseur dont le logiciel est utilisé ou est destiné à être vendu au gouvernement fédéral.
Remarquez que j'ai dit « actuellement » car tout indique que la conformité SSDF, que ce soit sous forme d'auto-attestation ou sous une autre forme vérifiable, va devenir une nouvelle « meilleure pratique » dans le domaine de la production de logiciels.
Alors, en supposant que votre entreprise fasse partie du groupe mentionné ci-dessus et que vous ne parveniez pas à signer ce document en toute bonne conscience, tout n'est pas encore perdu. Tant que vous pouvez expliquer où se situe la lacune dans l'attestation et proposer une solution satisfaisante Plan d'action et jalons (POA&M) l'agence fédérale en question peut toujours acheter/utiliser votre produit et demander une extension pour votre logiciel en votre nom auprès de l'OMB.
La mauvaise nouvelle est qu'avec ou sans plan POA&M, vous devrez éventuellement fournir un formulaire d'attestation complet, ce qui signifie que vous devez être en mesure de vérifier auprès d'un tribunal fédéral que toutes les étapes requises par le formulaire ont été suivies par votre entreprise et que votre le processus de développement logiciel est au moins aussi sécurisé que les exigences du formulaire.
Les seuls logiciels actuellement exemptés de cette forme d'attestation sont les logiciels développés par une agence fédérale et les logiciels disponibles gratuitement, alias logiciels open source. Bien sûr, la plupart sécurité de la chaîne logistique logicielle les trous peuvent être attribués d'une manière ou d'une autre à un package open source dans votre code, mais il y a un réel problème à essayer de forcer les développeurs et les mainteneurs open source, qui travaillent gratuitement, à fournir une garantie juridiquement contraignante pour leurs logiciels. Il devrait appartenir à toute personne utilisant un logiciel open source de vérifier sa sécurité, à la fois en général et en ce qui concerne le logiciel dans lequel il est intégré en particulier.
Scénario du pire des cas
Toute cette conscience de la sécurité de la chaîne d'approvisionnement logicielle a commencé après le fameux SolarWinds entaille. Sans entrer dans trop de détails, au moment du piratage, plus de 18,000 9 clients de l’entreprise étaient impactés dont XNUMX agences fédérales.
Ce n'est que maintenant, des années plus tard, que nous commençons à voir certains des résultats juridiques de cet incident. La seconde, Commission américaine des valeurs mobilières et des changes, s'en prend à l'entreprise dans son ensemble ainsi qu'après plusieurs cadres de niveau C. Cela peut être considéré comme un exemple des intentions du gouvernement si un tel incident ou un incident similaire survenait à un producteur de logiciels qui a attesté de ses pratiques de développement sécurisées et qui était pourtant victime d'un piratage.
Dans le cas de SolarWinds, l’entreprise soutient pleinement tout employé visé par de telles poursuites judiciaires. Connaissant le système juridique américain, de telles affaires prendront probablement des années et coûteront très cher. Les amendes ne sont pas exclues et pourraient atteindre des sommes de plusieurs millions selon une estimation des dommages subis.
Vous pouvez imaginer que toutes les entreprises, en particulier les petites et moyennes entreprises, ne protègent pas aussi farouchement leurs employés que SolarWinds. Le problème est que si l'accusé est le PDG de l'entreprise, il y a de fortes chances que la confiance du marché dans l'entreprise et son produit en souffre gravement. Faire face à la SEC sans le soutien d’une grande entreprise aux poches profondes pourrait ruiner un PDG sans méfiance ainsi que son entreprise. Bien sûr, l’intention est d’amener les gens à prendre au sérieux leur responsabilité pour assurer le développement, mais la peur peut les inciter à pécher par excès d’auto-préservation. Cela signifie que les gens préfèrent cacher les incidents de cybersécurité s'ils pensent qu'ils ne peuvent pas gagner une éventuelle affaire auprès de la SEC ou s'ils craignent que le coût et la mauvaise publicité d'une telle affaire soient si graves qu'il est préférable de les cacher quelle que soit l'issue du procès.
Comment puis-je signer ?
Les directives du NIST SSDF regorgent de suggestions et de bonnes pratiques, mais sont peu pratiques. Étant donné que chaque entreprise est unique, il est assez difficile de proposer un produit ou un système qui fonctionnerait pour tout le monde. Dans ce cas, le secteur privé intervient pour combler le vide, créant un écosystème pour vous aider à respecter les exigences.
Par exemple, Scribe a construit une plateforme basé sur le concept de créer des attestations, de les signer et d'offrir la possibilité de les vérifier. Nous publierons bientôt un document sur mesure pour le Formulaire d'auto-attestation CISA, démontrant comment la solution Scribe peut vous aider dans chaque section des exigences. Restez à l'écoute.
Essayer La plateforme Scribe est gratuite. Je vous encourage à l'essayer et à voir comment vous pouvez adapter la plateforme à vos besoins et en même temps signer le formulaire d'auto-attestation de CISA en toute bonne conscience.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
