Les fournisseurs fédéraux disposent d’un an pour créer un SBOM afin de garantir un développement logiciel sécurisé et d’améliorer la sécurité de la chaîne d’approvisionnement logicielle – CPO Magazine
L’administration Biden a fait un autre pas en avant dans sa forte volonté d’améliorer la cybersécurité nationale, cette fois en abordant la chaîne d’approvisionnement en logiciels avec de nouvelles exigences. Conformément aux conditions précédemment présentées dans le décret exécutif 14028, le Bureau de la gestion et du budget (OMB) a publié un nouveau mémorandum qui établit un cadre d’un an pour que les fournisseurs fournissent des assurances de développement de logiciels sécurisés.
Dans un délai d’un an, les producteurs de logiciels seront tenus de produire une nomenclature de logiciels (SBOM) ou un document équivalent garantissant des pratiques de développement de logiciels sécurisées. Le délai est réduit à 270 jours pour les « logiciels critiques ».
La chaîne d’approvisionnement logicielle au centre des nouvelles commandes d’OMB
Appelant cela une nécessité pour offrir une « expérience gouvernementale sécurisée », l’OMB a donné des instructions aux agences fédérales pour s’assurer que rien d’autre qu’un logiciel sécurisé n’est en place. Cela signifie, principalement, une comptabilité des composants de tout ce qui est utilisé dans la chaîne d’approvisionnement des logiciels ; le mécanisme principal étant un SBOM.
Un certain nombre d’événements récents ont démontré la nécessité de quelque chose comme un SBOM pour vraiment sécuriser les logiciels, mais rien de plus que la vulnérabilité Log4j qui est apparue fin 2021. Une vulnérabilité facilement exploitable dans un composant logiciel largement utilisé dans toutes sortes d’applications mis en évidence le besoin d’un moyen simple et rapide de localiser chacun de ces composants pour un correctif ou une correction lorsqu’un tel problème apparaît.
L’ordonnance exige également que des normes de développement de logiciels sécurisés soient en place à l’avenir et que toutes les agences fédérales et leur chaîne d’approvisionnement en logiciels soient conformes à ces normes. Le mémo ordonne au National Institute of Standards and Technology (NIST) de préparer immédiatement des directives auxquelles ces parties seront invitées à se conformer, qui seront tirées du NIST Secure Software Development Framework (SSDF) SP 800-218 et du logiciel NIST existant. Conseils sur la sécurité de la chaîne d’approvisionnement.
Le mémo est complet, appliquant ces normes logicielles sécurisées à tous les programmes ou applications tiers utilisés sur les systèmes de l’agence ou « affectant autrement les informations de l’agence » (ou les logiciels que les fournisseurs ayant accès à ces systèmes utilisent). Les agences seront responsables de la mise en œuvre des normes de la chaîne d’approvisionnement des logiciels avec les organisations avec lesquelles elles contractent. Les logiciels développés en interne par les agences sont exclus de ces exigences, mais la note de service « prévoit des étapes appropriées » pour mettre en œuvre des pratiques de développement de logiciels sécurisés.
Alors que les agences doivent mettre en œuvre, elles ne supporteront pas l’entière charge de l’inspection ; les éditeurs de logiciels ont un an (ou 270 jours dans certains cas «critiques») pour certifier eux-mêmes que ces pratiques de développement de logiciels sécurisés sont en place. Au minimum, ces déclarations d’auto-attestation nécessiteront une description du produit et une déclaration indiquant qu’une liste détaillée des pratiques logicielles sécurisées a été suivie lors du développement (sur un formulaire standardisé à développer dans les 120 jours). Si le logiciel est jugé suffisamment critique, un SBOM ou une documentation équivalente sera également requis (conformément aux normes établies dans le rapport de la National Telecommunications and Information Administration The Minimum Elements for a Software Bill of Materials ou les directives ultérieures préparées par CISA). Une évaluation par un tiers peut également être requise en fonction du niveau de risque.
Les vendeurs auront 365 jours pour préparer les déclarations nécessaires ; ceux qui ont besoin de SBOM auront 270 jours. La participation à un programme de divulgation des vulnérabilités peut également être requise, selon les décisions de chaque agence. Les agences sont tenues d’inventorier leurs logiciels dans les 90 jours et de noter les applications critiques, et de développer un processus pour communiquer les exigences aux fournisseurs dans les 120 jours.
Les attaques contre la chaîne d’approvisionnement et les infrastructures critiques incitent à la mise en place de logiciels sécurisés
Le gouvernement a une capacité très limitée à dicter des conditions de « logiciels sécurisés » aux entreprises privées, mais espère que la pression exercée sur les sous-traitants gouvernementaux dans la chaîne d’approvisionnement en logiciels (qui incluent les plus grands noms de la technologie tels que Microsoft et Oracle) se traduira à son tour par des produits plus sécurisés à travers le paysage général.
Mais certains analystes de la cybersécurité ne sont pas convaincus que cette approche conduira réellement à des logiciels plus sécurisés, ou du moins la voient comme un processus qui pourrait prendre des années à se dérouler. Alors que les logiciels critiques devront être accompagnés de documentation et que certains logiciels seront soumis à l’examen d’un évaluateur certifié FedRAMP (ou d’un évaluateur nommé par l’agence), la majeure partie de la chaîne d’approvisionnement logicielle fédérale ne sera soumise qu’à l’auto-évaluation la plus élémentaire. -exigences d’attestation.
Certains analystes soulignent un ensemble de conditions similaires en vigueur pour les sous-traitants de la défense depuis 2015. Les vives critiques de ces conditions ont finalement cédé la place à des poursuites judiciaires que les tribunaux ont commencé à trancher en faveur du gouvernement en 2019, les sous-traitants ayant simplement exagéré ou même faussement déclaré. leur capacité et leur préparation. Ces conditions peuvent suivre un schéma similaire, avec des années de violations continues avant que le gouvernement n’augmente la pression et n’augmente ses pratiques d’audit. Dans le cas des entrepreneurs de la défense, l’utilisation réussie de la False Claims Act devant les tribunaux (qui peut exposer les entrepreneurs à des millions de dollars d’amendes dans les pires cas) peut être un élément planifié de cette stratégie étant donné qu’il existe désormais un précédent juridique.
Eric Noonan, PDG de CyberSheath, a eu des mots particulièrement durs pour le mémorandum : « Ce mémo aurait pu être rédigé par la Chine, des lobbyistes ou les deux. Premièrement, oui, il s’agit d’un pas en avant dans la mesure où le gouvernement exige un certain niveau d’assurance de la part de ses fournisseurs quant au respect des minimums de cybersécurité. Mais permettre l’auto-attestation garantit que nous répéterons les péchés du passé. Nous n’avons pas besoin de chercher plus loin que le récent cas de lanceur d’alerte où le géant des contrats de défense Aerojet Rocketdyne a auto-attesté qu’il respectait les normes de cybersécurité sur les contrats fédéraux. L’affaire vient de se régler le mois dernier pour 9 millions de dollars et je doute qu’Aerojets se soit installé en croyant que leur auto-attestation de conformité aux normes de cybersécurité était exacte… La plupart des États n’autorisent pas les Américains à attester eux-mêmes de l’inspection de leurs voitures, mais nous allons autoriser plusieurs milliards de dollars. entreprises internationales à auto-certifier leur cybersécurité ? Les dommages causés à la sécurité nationale parce que nous permettons aux agences et aux entreprises de s’auto-certifier sont longs. Nous avons eu la violation des données de Target, nous avons eu la violation du Bureau de la gestion du personnel, la violation d’Equifax, le piratage du Colonial Pipeline, je pourrais continuer. Le lien entre les violations de données réussies ayant un impact sur la sécurité nationale et l’auto-attestation est irréfutable.
Et Mark Stamford, PDG et fondateur d’OccamSec, s’est demandé si le gouvernement s’était simplement mis en place pour éternellement rattraper les menaces : « Le problème ici est de savoir qui établit les normes ? Si nous avons besoin d’utiliser un logiciel construit à l’aide d’un processus de développement sécurisé, qui le définit ? Et comment fait-on pour l’appliquer ? Et qu’en est-il des organisations qui ne peuvent pas se conformer (c’est-à-dire les petites entreprises), cela va-t-il conduire à ce que les suspects habituels soient acceptables et tout le monde non ? Cela aura un effet négatif net à long terme sur la sécurité de nos nations.
Lorsque vous publiez une norme, tout le monde sait quelles sont vos défenses, et vous avez alors une feuille de route sur la façon de planifier votre attaque. Les normes pour le développement de logiciels sécurisés fonctionnent si vous abordez toutes les façons dont les logiciels peuvent être développés, compte tenu de la multitude d’environnements de programmation ; Allons-nous définir des exigences de codage spécifiques ? Ou à grands traits ? Encore une fois, comment allons-nous tenir cela à jour ? a ajouté Stamford. Ce dont nous avons vraiment besoin, c’est d’une approche plus dynamique qui réévalue constamment la façon dont la posture de risque a changé à la suite d’une nouvelle menace/vulnérabilité/autre – sans cela, nous aurons des normes définies, qui seront mises à jour de temps en temps par tout le monde, mais toujours en train de jouer rattraper. »
La poussée logicielle sécurisée poursuit les efforts antérieurs de l’administration Biden pour améliorer la préparation générale à la cybersécurité dans le pays, suite aux ordres donnés aux agences fédérales d’adopter une approche de « confiance zéro » pour la sécurité du réseau et de créer de nouvelles exigences pour les entreprises de services publics et d’infrastructures critiques.