Le 12 mai 2021, le président Biden a signé le décret sur l'amélioration de la cybersécurité de la nation. Élaboré à la suite de la très préjudiciable violation de la chaîne d'approvisionnement du logiciel Orion de SolarWinds, ce décret ordonne à plusieurs agences du gouvernement fédéral américain de mieux coordonner la prévention, la détection, la réponse et l'atténuation des incidents et des violations de la sécurité, en prenant les mesures suivantes
Ce décret s'appuie sur les précédents décrets relatifs à la cybersécurité et exige des agences qu'elles établissent des normes uniformes fondées sur le NIST, dont l'application débutera en mai 2022.
Étant donné que cet EO introduit plusieurs nouvelles exigences en matière de gestion des risques liés aux tiers que les agences fédérales doivent mettre en œuvre, ce post se concentre sur la section 4. Renforcer la sécurité de la chaîne d'approvisionnement des logiciels. Si les fournisseurs de logiciels ne sont pas en mesure de répondre à ces exigences, ils seront retirés du règlement d'acquisition du gouvernement fédéral - ce qui signifie qu'ils ne peuvent plus vendre au gouvernement. Le gouvernement fédéral publiera ces exigences, y compris les critères de test et d'évaluation, plus tard dans l'année.
Les systèmes informatiques critiques du gouvernement fédéral sont depuis longtemps la cible d'attaques de l'État. Les acteurs malveillants savent que le chemin le plus facile et le moins sûr vers les systèmes fédéraux passe souvent par des services et des logiciels tiers. Les fournisseurs tiers peuvent ne pas disposer des processus ou des contrôles nécessaires pour détecter les activités ou les codes malveillants, et ils peuvent potentiellement exposer un large éventail d'informations sensibles.
Lestechnologies et les processus de gestion des risques par des tiers peuvent aider à répondre aux directives du décret exigeant que les organisations évaluent la sécurité des logiciels et en rendent compte. Les critères de l'EO comprennent l'évaluation des contrôles de sécurité des développeurs et des fournisseurs, ainsi que la documentation qui démontre l'adhésion à des pratiques sécurisées.
Le tableau ci-dessous résume certaines des exigences les plus importantes en matière de gestion des risques liés aux tiers abordées dans l'EO, ainsi que les capacités recommandées par Prevalentpour évaluer les pratiques des fournisseurs.
Orientation de l'OT | Capacités recommandées |
---|---|
4 (e) (i) (A)-(F) Ces orientations comprennent des normes, des procédures ou des critères concernant : |
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. |
Alors que les exigences décrites dans le décret sur l'amélioration de la cybersécurité du pays prendront forme au cours de l'année prochaine, il est temps pour les entreprises de logiciels informatiques d'élaborer ou de perfectionner leurs propres programmes de gestion des risques liés aux tiers. Les considérations clés devraient inclure :
Prevalent peut vous aider. Nous proposons une solution SaaS qui automatise les tâches essentielles requises pour identifier, évaluer, analyser, corriger et surveiller en permanence les risques liés à la sécurité, à la confidentialité, aux opérations, à la conformité et aux achats des tiers à chaque étape du cycle de vie des fournisseurs. Pour en savoir plus sur la façon dont Prevalent peut vous aider, lisez les informations sur nos capacités TPRM pour l'Executive Order on Improving the Nation's Cybersecurity ou contactez-nous aujourd'hui pour une discussion stratégique.
Prenez en compte ces bonnes pratiques pour vous assurer que les fournisseurs de services tiers protègent correctement les données NPI de vos clients.
09/04/2024
La mise en conformité étant obligatoire d'ici janvier 2025, le moment est venu pour les organisations d'examiner leurs...
09/03/2024
Aucune approche n'est idéale pour toutes les organisations, mais certains cadres couramment utilisés servent de...
08/19/2024