Gestion des risques liés aux tiers dans le cadre du décret sur l'amélioration de la cybersécurité nationale

4 (e) (i) (A)-(F)

Ces orientations comprennent des normes, des procédures ou des critères concernant :
(i) les environnements de développement de logiciels sécurisés, y compris des actions telles que :
(A) l'utilisation d'environnements de construction administrativement séparés ;
(B) l'audit des relations de confiance ;
(C) la mise en place d'une authentification multifactorielle fondée sur les risques et d'un accès conditionnel dans l'ensemble de l'entreprise ;
(D) documenter et minimiser les dépendances aux produits de l'entreprise qui font partie des environnements utilisés pour développer, construire et modifier les logiciels ;
(E) le recours au cryptage des données ; et
(F) surveiller les opérations et les alertes et répondre aux tentatives et aux incidents réels de cyber ;

Lors de l'évaluation des pratiques de sécurité logicielle des tiers, tirez parti des modèles de questionnaires d'évaluation des risques normalisés acceptés par l'industrie, notamment le Standard Information Gathering (SIG), le NIST, le CMMC et les évaluations connexes. L'utilisation d'une seule évaluation standardisée pour l'ensemble de vos fournisseurs permet aux agences de comparer plus efficacement les pratiques de sécurité logicielle de leurs fournisseurs.

Remarque : les agences peuvent également tirer parti des réseaux d'échange, qui contiennent des évaluations des risques de sécurité déjà réalisées, afin d'accélérer le processus d'identification des risques.

4 (e) (ii)

(ii) produire et, à la demande d'un acheteur, fournir des artefacts qui démontrent la conformité aux processus énoncés au paragraphe (e)(i) de cette section ;

Lorsque vous évaluez les pratiques de développement de logiciels sécurisés d'un tiers, assurez-vous que vous avez la capacité de centraliser les preuves à l'appui avec une gestion intégrée des tâches et des acceptations, ainsi que des fonctions de téléchargement obligatoire. Un dépôt de documents sécurisé garantit que les parties concernées peuvent examiner la documentation et les artefacts en conséquence.

4 (e) (iii)

(iii) l'utilisation d'outils automatisés, ou de processus comparables, pour maintenir des chaînes d'approvisionnement en code source de confiance, garantissant ainsi l'intégrité du code ;

Voir 4 (e) (i) (A)-(F) ci-dessus.

4 (e) (iv)

(iv) l'utilisation d'outils automatisés, ou de processus comparables, qui vérifient les vulnérabilités connues et potentielles et y remédient, et qui fonctionnent régulièrement, ou au moins avant la sortie d'un produit, d'une version ou d'une mise à jour ;

Les tiers doivent analyser, trier et corriger les vulnérabilités de leurs logiciels et codes, et en attester. Mais les menaces ne s'arrêtent pas là. Les équipes de sécurité doivent également surveiller l'Internet et le dark web à la recherche de cyber menaces, de fuites d'informations d'identification ou d'autres indicateurs de compromission qui peuvent ouvrir des voies d'accès aux systèmes fédéraux s'ils ne sont pas détectés.

4 (e) (v)

(v) fournir, à la demande d'un acheteur, les artefacts de l'exécution des outils et des processus décrits aux paragraphes (e)(iii) et (iv) de cette section, et mettre à la disposition du public des informations sommaires sur l'achèvement de ces actions, afin d'inclure une description sommaire des risques évalués et atténués ;

L'établissement de rapports est essentiel ici. Les équipes de sécurité informatique fédérales devraient être en mesure de révéler les tendances en matière de risques, l'état d'avancement, les mesures correctives et les exceptions au comportement commun pour les fournisseurs individuels ou les groupes avec des informations d'apprentissage automatique intégrées. Cela permettrait aux équipes d'identifier rapidement les aberrations dans les évaluations, les tâches, les risques, etc. qui pourraient justifier une enquête plus approfondie.

4 (e) (vi)

(vi) maintenir des données précises et à jour, la provenance (c'est-à-dire l'origine) du code ou des composants logiciels, et des contrôles sur les composants, outils et services logiciels internes et tiers présents dans les processus de développement de logiciels, et effectuer des audits et l'application de ces contrôles de manière récurrente ;

Les équipes informatiques fédérales devraient être en mesure de mettre automatiquement en correspondance les informations recueillies lors des audits internes avec les normes ou les cadres réglementaires applicables dans le cadre de cet EO - y compris le NIST, le CMMC et d'autres - afin de visualiser et de traiter rapidement les lacunes importantes en matière de contrôle, et d'attester des pratiques.

4 (e) (vii)

(vii) fournir à un acheteur une nomenclature logicielle (SBOM) pour chaque produit, directement ou en la publiant sur un site web public ;

Voir 4 (e) (i) (A)-(F) ci-dessus.

4 (e) (viii)

(viii) la participation à un programme de divulgation des vulnérabilités qui comprend un processus de rapport et de divulgation ;

Voir 4 (e) (i) (A)-(F) ci-dessus.

4 (e) (ix)

(ix) attestant de la conformité aux pratiques de développement de logiciels sécurisés ; et

Voir 4 (e) (ii) ci-dessus.

4 (e) (x)

(x) garantir et attester, dans la mesure du possible, l'intégrité et la provenance des logiciels libres utilisés dans toute partie d'un produit.

Voir 4 (e) (vi) ci-dessus.