NIST SP 800-218 (SSDF) :

Vue d'ensemble

SoftwareLa norme NIST SP 800-218 v1.1 (février 2022) définit le « Secure Software Development Framework » (cadre de développement sécurisé des applications : un ensemble de pratiques axées sur les résultats, et non une liste de contrôle normative), organisé en quatre grandes catégories : « Préparer l’organisation », « Protéger l’ Software », « Produire des applications bien sécurisées » et « Réagir aux vulnérabilités ». Le décret présidentiel n° 14028 et les circulaires de l’OMB qui en ont découlé ont fait de la conformité au SSDF une condition préalable à la vente d’ software s au gouvernement fédéral.

Les producteurs doivent signer le formulaire d’attestation hébergé par la CISA, et le PDG ou une personne désignée à cet effet atteste, au mieux de ses connaissances, que ces pratiques sont respectées. Le référentiel ne prévoit pas de dispositif officiel de certification par un tiers ; la démonstration de la conformité repose donc sur des preuves internes et une attestation plutôt que sur un certificat d’audit, ce qui fait peser sur l’organisation la responsabilité de conserver des preuves qui tiendraient la route si l’attestation venait à être contestée.

Pourquoi c'est important

L'attestation relève de l'autocertification, mais il s'agit d'une déclaration formelle ayant une valeur juridique : le signataire est tenu de conserver des preuves suffisantes pour la défendre en cas de contestation, et une fausse attestation expose à des poursuites en vertu de la loi sur les fausses déclarations (False Claims Act), ce qui représente un enjeu bien plus important qu'un simple manquement à la conformité.

Les points PS.2 et PS.3, qui visent à protéger le code contre toute altération et à fournir un mécanisme permettant de vérifier l’intégrité des versions, comptent parmi les pratiques nécessitant le plus de preuves ; elles correspondent directement aux fonctionnalités de signature de code et de traçabilité de la compilation que de nombreux éditeurs de logiciels de sécurité ( software ) n’ont pas encore formalisées. Le SSDF est également devenu le vocabulaire de référence utilisé par les acheteurs non gouvernementaux dans les questionnaires de sécurité adressés aux fournisseurs ; par conséquent, les lacunes dans ce domaine apparaissent de plus en plus souvent dans les cycles de vente commerciaux, tout comme dans les cycles fédéraux.

En quoi cela s'applique-t-il à la cryptographie ? 

La norme NIST SP 800-218 (SSDF) aborde la cryptographie à travers plusieurs domaines de contrôle étroitement liés. Les principaux domaines ayant des implications cryptographiques directes sont les suivants :

Préparation à l'audit

Les évaluations et les contrôles, qu'ils soient menés en interne, réalisés par une autorité de régulation ou examinés par un évaluateur indépendant, se concentrent sur les preuves concrètes plutôt que sur les simples déclarations de principe. Voici les principaux domaines sur lesquels les contrôleurs et les évaluateurs s'attardent généralement :

• Dossier justificatif de l'attestation : L'organisme est-il en mesure de fournir les pièces justificatives sur lesquelles repose son attestation CISA, et pas seulement le formulaire signé lui-même ?
• Protection des clés de signature de code : les clés de signature de code sont-elles protégées contre toute compromission, leur accès étant limité aux systèmes de compilation et au personnel autorisés ?
• Mécanisme de vérification de l'intégrité des versions : Existe-t-il un mécanisme opérationnel, et pas seulement une déclaration de principe, permettant à un consommateur de vérifier qu'une version correspond bien à ce que le producteur a publié ?
• Éléments de preuve relatifs au contrôle d'accès au pipeline de compilation : l'accès à l'infrastructure de code source, de compilation et de publication est-il restreint et consigné de manière à permettre l'attestation PS.2 ?
• SBOM et signature de la traçabilité : les nomenclatures « Software » et les attestations de traçabilité sont-elles signées, ce qui permet une vérification rapide lorsqu’une vulnérabilité d’un composant est révélée ?
• Validité juridique de l'attestation du PDG ou de son représentant : les éléments de preuve versés au dossier suffiraient-ils réellement à étayer l'attestation si celle-ci était contestée, plutôt que de simplement supposer qu'ils sont suffisants ?

TRANSMETTEZ CELA À LA DIRECTION

Lorsque nous soumettons l’attestation CISA, notre PDG ou une personne désignée et habilitée signe personnellement un document ayant une valeur juridique, et la validité de cette signature dépend entièrement des preuves qui la sous-tendent. Les points PS.2 et PS.3, qui visent à protéger notre code et à prouver l’intégrité des versions, correspondent exactement aux pratiques pour lesquelles la signature de code et la gestion des clés ont été conçues ; il ne s’agit donc pas d’une nouvelle fonctionnalité à développer, mais de preuves que nous sommes peut-être déjà en passe d’obtenir, à condition de pouvoir les produire.

Cette exigence ne concerne plus uniquement les pouvoirs publics. Les acheteurs du secteur privé, notamment dans les domaines de la finance et de la santé, posent désormais des questions sur la conformité à la norme SSDF dans leurs questionnaires destinés aux fournisseurs, ce qui signifie qu’une lacune à ce niveau nous fait perdre des cycles de vente que nous ne considérons absolument pas comme relevant du secteur public. En clarifiant notre approche en matière de signature de code et de traçabilité, nous répondons à la fois aux attentes de ces deux publics.