Le gouvernement fédéral a publié des règles qui affecteront bientôt les éditeurs de logiciels. Voici la version courte :
Bonnes nouvelles: Le gouvernement veut protéger tout le monde des perturbations de la chaîne d’approvisionnement.
Mauvaises nouvelles: Délais ! De nouvelles exigences, comme fournir des attestations et des artefacts.
Bonnes nouvelles: C’est seulement si vous vendez des logiciels au gouvernement fédéral.
Mauvaises nouvelles: D’accord, mais vous devez quand même vous y conformer, car les entreprises qui satisfont aux exigences seront des partenaires commerciaux plus attrayants. Soit vous serez l’un d’entre eux… soit vous ne le serez pas.
Bonnes nouvelles: Nous sommes là pour aider à donner un sens à tout cela.
Passons maintenant à la version longue.
Le 14 septembre 2022, le Bureau de la gestion et du budget (OMB) a publié un mémorandum M-22-18 (le mémo de la Maison Blanche) obligeant les agences fédérales à se conformer aux règles pour s’assurer que les logiciels tiers qu’ils utilisent respectent les pratiques de développement de logiciels sécurisés. Alors que les changements affectent les agences fédérales et les entreprises qui leur fournissent des logiciels, l’adoption à l’échelle de l’industrie par tous les fournisseurs de logiciels pourrait aider à prévenir la prochaine cyberattaque massive de la chaîne d’approvisionnement mondiale.
Les efforts du gouvernement fédéral ont commencé par Décret exécutif (EO) 14028, Améliorer la cybersécurité de la nation (12 mai 2021). L’EO a été publié en réponse à l’attaque SolarWinds et à d’autres cyberattaques graves qui ont affecté la chaîne d’approvisionnement des logiciels et a rappelé la nécessité de remédier aux vulnérabilités lors de l’utilisation de logiciels open source. L’un des objectifs de cet EO : “améliorer la sécurité des logiciels en établissant des normes de sécurité de base pour le développement de logiciels vendus au gouvernement”. L’OE a demandé au National Institute of Standards and Technology (NIST) de publier des directives. Le mémo de la Maison Blanche définit désormais les pratiques que les agences fédérales doivent suivre pour se conformer aux « directives NIST » qui en résultent.
La principale exigence du mémo de la Maison Blanche : les agences fédérales “ne doivent utiliser que des logiciels fournis par des producteurs de logiciels qui peuvent attester du respect des pratiques de développement de logiciels sécurisés spécifiées par le gouvernement, telles que décrites dans les directives du NIST”. Le mémo de la Maison Blanche ajoute plus tard que les pratiques de développement de logiciels sécurisés doivent avoir été utilisées «tout au long du cycle de vie du développement de logiciels».
Le premier ensemble d’exigences a une date limite qui tombe le 13 décembre 2022ou 90 jours après la date du mémo de la Maison Blanche.
Portée
Agences fédérales:
- Le mémo de la Maison Blanche exige que chaque fédéral “agence” pour ” se conformer aux directives du NIST lors de l’utilisation de logiciels tiers sur les systèmes d’information de l’agence ou affectant autrement les informations de l’agence “.
- Une agence qui attribue un contrat qui peut être utilisé par d’autres agences doit suivre le mémo de la Maison Blanche.
Logiciel: Le logiciel est défini au sens large. Par conséquent, de nombreuses organisations qui font affaire avec le gouvernement fédéral seront touchées. Les logiciels “incluent les micrologiciels, les systèmes d’exploitation, les applications et les services d’application (par exemple, les logiciels basés sur le cloud), ainsi que des produits contenant des logiciels.”
A partir de quand: Le mémo de la Maison Blanche s’applique à l’utilisation par les agences fédérales (a) des logiciels développés après le 14 septembre 2022 et (b) des logiciels existants qui sont modifiés par des « changements de version majeurs » après le 14 septembre 2022.
Exclusions: Les exigences ne s’appliquent pas aux « logiciels développés par l’agence », mais les agences doivent utiliser des pratiques de développement logiciel sécurisées pour les logiciels développés par l’agence.
Que faire – si vous souhaitez fournir des logiciels aux agences fédérales
Le mémo de la Maison Blanche exige qu’avant qu’une agence fédérale n’utilise un logiciel, le producteur du logiciel doit soumettre (1) une auto-attestation de conformité aux directives du NIST et (2) potentiellement, “des artefacts qui démontrent la conformité aux pratiques de développement de logiciels sécurisés”.
Première exigence : auto-attestation, et exceptions :
L’auto-attestation, une exigence minimale. Les agences doivent obtenir une auto-attestation du producteur du logiciel avant d’utiliser tout logiciel tiers, y compris les renouvellements de logiciels et les changements de version majeurs (sous réserve d’exceptions). Une agence peut également exiger une évaluation par un tiers en raison de la « criticité du service ou du produit en cours d’acquisition ».* L’auto-attestation doit inclure :
- Le nom du producteur du logiciel ;
- Une description du ou des produits auxquels la déclaration fait référence ; et
- Une déclaration attestant que le producteur du logiciel suit des pratiques et des tâches de développement sécurisé qui sont détaillées dans le formulaire d’auto-attestation standard. Les pratiques de base pour le développement de logiciels sécurisés sont incluses dans le Cadre de développement logiciel sécurisé NIST et le Guide de sécurité de la chaîne d’approvisionnement du logiciel NIST.
Exception—documentation et atténuation. Si un producteur de logiciels ne peut pas attester d’une ou plusieurs des pratiques du NIST Guidance, “l’organisme demandeur doit exiger que le producteur de logiciels identifie les pratiques auxquelles il ne peut pas attester, documente les pratiques qu’il a mises en place pour atténuer ces risques et exige un plan d’action et des jalons (POA&M) à élaborer. » Si l’agence est satisfaite de la documentation, elle peut utiliser le logiciel.
Exception—évaluations tierces valides. Utile, en particulier lorsque les produits intègrent un logiciel open source, une évaluation par un tiers est acceptable au lieu d’une auto-attestation, si elle est fournie par une organisation d’évaluateurs tiers FedRAMP (3PAO) certifiée ou approuvée par l’agence, si le 3PAO utilise le NIST Orientation comme base d’évaluation.
Deuxième exigence : “artefacts”
- Préparez-vous à fournir un SBOM. Une agence peut exiger d’un producteur de logiciels qu’il soumette une nomenclature de logiciels (SBOM). Un SBOM est un “enregistrement formel contenant les détails et les relations de la chaîne d’approvisionnement de divers composants utilisés dans la construction de logiciels”.
- Fournir des artefacts/preuves défendables. Une agence peut exiger d’autres artefacts, notamment des preuves de participation à un programme de divulgation des vulnérabilités. NIST, un artefact est simplement « un élément de preuve », et la preuve est « un motif de croyance ou d’incrédulité ; données sur lesquelles fonder la preuve ou établir la vérité ou la fausseté ».
- Des artefacts de bas niveau sont générés pendant le développement de logiciels et comprennent, par exemple, des modèles de menace, des entrées de journal, des fichiers de code source, des rapports d’analyse de vulnérabilité de code source, des résultats de test, la télémétrie ou des décisions d’atténuation basées sur les risques pour un logiciel particulier.
- Les artefacts de haut niveau résument les pratiques de développement logiciel sécurisé dérivées des artefacts de bas niveau. Un exemple : un document accessible au public décrivant la méthodologie, les procédures et les processus qu’un éditeur de logiciels utilise pour ses pratiques sécurisées de développement de logiciels.
Fiabilité des attestations et des artefacts. Les pratiques qui améliorent la sécurité de la chaîne d’approvisionnement logicielle comprennent «l’utilisation d’outils automatisés ou de processus comparables pour maintenir des chaînes d’approvisionnement de code source fiables, garantissant ainsi l’intégrité du code» et «l’utilisation d’outils automatisés ou de processus comparables qui vérifient vulnérabilités connues et potentielles et corrigez-les.”**
Par conséquent, une organisation qui s’appuie sur une conformité automatisée et basée sur les données est mieux équipée pour établir une attestation et fournir des artefacts. La conformité automatisée qui fournit un flux constant de données fiables en temps réel permet une identification plus rapide des vulnérabilités, garantissant ainsi un environnement de développement logiciel plus sécurisé. De plus, un tel système de conformité génère des artefacts crédibles et dignes de confiance pour montrer comment le logiciel qui fait partie de son produit est protégé. Un appel au jugement ne peut pas servir de preuve d’un environnement sécurisé, et une capture d’écran est facilement manipulable. Mais comme un système automatisé de conformité est conçu pour générer des artefacts à utiliser comme preuves fiables dans les audits, ce même système peut produire des artefacts fiables qui prouvent des pratiques de développement de logiciels sécurisées.
L’horloge tourne
Quelques échéances clés dans le cadre du mémo de la Maison Blanche :
- D’ici le 13 décembre 2022, les agences doivent “répertorier tous les logiciels soumis aux exigences du présent mémorandum, avec un inventaire séparé pour les” logiciels critiques “”.
- D’ici le 12 janvier 2023, les agences doivent “élaborer un processus cohérent pour communiquer les exigences pertinentes de ce mémorandum aux fournisseurs et s’assurer que les lettres d’attestation sont collectées dans un système central d’agence”.
- D’ici le 11 juin 2023, les agences doivent “collecter des lettres d’attestation pour les ‘logiciels critiques’ soumis aux exigences du présent mémorandum”.
- D’ici le 14 septembre 2023, les agences doivent “collecter des lettres d’attestation pour tous les logiciels soumis aux exigences du présent mémorandum”.
Il existe également des délais pour l’OMB, le NIST et la Cybersecurity and Infrastructure Security Agency.
Quelle est la taille d’un changement ?
Déterminer si une organisation particulière a beaucoup de travail supplémentaire en réserve dépend de l’utilisation ou non d’outils de conformité automatisés. Ces outils facilitent l’attestation et la preuve des pratiques de développement de logiciels sécurisés. Les organisations qui fournissent des logiciels aux agences gouvernementales devraient commencer à combler toutes les lacunes qui les empêcheraient de continuer. *** Mais d’autres organisations devraient également adopter le mémo de la Maison Blanche et les directives du NIST, afin de mieux sécuriser leur propre environnement de développement logiciel et le chaîne mondiale d’approvisionnement en logiciels. Le fait que le mémo de la Maison Blanche exige une attestation et des artefacts est un argument de poids selon lequel ce sont les meilleures pratiques pour tout producteur de logiciels. Le respect de ces pratiques profite aux entreprises et à leurs partenaires potentiels.
—————
*Dans Note de service CAMO M-21-30le NIST définit un logiciel critique comme “tout logiciel qui a, ou a des dépendances logicielles directes sur, un ou plusieurs composants avec au moins un de ces attributs :
• est conçu pour s’exécuter avec des privilèges élevés ou gérer des privilèges ;
•a un accès direct ou privilégié à des ressources réseau ou informatiques ;
• est conçu pour contrôler l’accès aux données ou à la technologie opérationnelle ;
• remplit une fonction essentielle à la confiance ; ou
• fonctionne en dehors des limites de confiance normales avec un accès privilégié.
La définition s’applique aux logiciels de toutes formes (par exemple, logiciels autonomes, logiciels intégrés à des dispositifs ou composants matériels spécifiques, logiciels basés sur le cloud) qui sont achetés ou déployés dans des systèmes d’information et utilisés à des fins opérationnelles.
**https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ (Section 4(e)(iii) et (iv)).
***Le Congrès travaille à codifier les exigences de l’OE. Le 21 septembre 2022, la loi de 2022 sur la sécurisation des logiciels open source, S. 4913, a été présentée au Sénat. En partie, cela obligerait le directeur de l’Agence de la cybersécurité et de la sécurité des infrastructures à évaluer le risque des composants logiciels open source utilisés par les agences fédérales. Le projet de loi attend l’approbation du Sénat.
