Événements récents, comme ceux affectant SolarWinds et Log4j, démontrent l’ampleur des perturbations en matière de cybersécurité qui peuvent résulter d’un manque de vigilance en matière de gestion des composants tiers dans les systèmes logiciels. À mesure que les systèmes deviennent de plus en plus gourmands en logiciels et complexes, ces composants tiers se sont répandus et nécessitent une approche intégrée en matière d’acquisition, d’ingénierie, de développement et d’exploitation pour garantir une sécurité et une résilience suffisantes. Cependant, un récent rapport de SecurityScorecard a examiné plus de 230 000 organisations et a constaté que les systèmes de 98 pour cent parmi eux, des composants logiciels tiers ont été piratés au cours des deux années précédentes.
À la lumière de ces réalités, les personnes chargées de gérer les systèmes logiciels doivent considérer les dépendances et les risques des logiciels tiers de manière nouvelle et collaborer avec des experts métier pour développer de nouvelles techniques d’identification et de gestion des risques potentiels. UN nomenclature du logiciel (SBOM) peut faciliter ces tâches. Cet article du blog SEI met en lumière notre travail visant à tirer parti des connaissances du SEI. Cadre de sécurité des acquisitions pour la gestion des risques de la chaîne d’approvisionnement et l’adapter pour une utilisation dans la gestion de logiciels tiers, ce qui a abouti à la Cadre SEI SBOM.
Défis de cybersécurité des logiciels et de la chaîne d’approvisionnement
Le risque tiers constitue un enjeu majeur pour les organisations cherchant à limiter leur exposition aux risques de cybersécurité. Les logiciels tiers étant devenus un facteur très important dans la sécurité des systèmes vastes et complexes, la gestion des relations avec les fournisseurs tiers est essentielle au succès.
Les organisations ont souvent une vision limitée des composants, des sources et des fournisseurs impliqués dans le développement et le fonctionnement continu d’un système. Un aspect essentiel de la gestion des risques liés aux fournisseurs est de pouvoir accéder aux informations sur les intrants des fournisseurs et leur importance relative, puis de gérer les mesures d’atténuation pour réduire les risques.
Cependant, un programme ne peut pas gérer efficacement à lui seul les risques de cybersécurité, car la gestion des risques liés à la sécurité et aux fournisseurs ne relève généralement pas du champ d’application du programme. De plus, les informations critiques nécessaires à la gestion des cyber-risques sont souvent réparties dans de nombreux documents, comme un plan de protection du programme (PPP), plan de cybersécurité, plan de développement de système (SDP) ou plan de gestion des risques de la chaîne d’approvisionnement. De même, de nombreuses activités essentielles à la gestion des cyber-risques sont réparties entre les unités de l’organisation. Ces unités doivent aborder en collaboration la gestion des cyber-risques tout au long du cycle de vie et de la chaîne d’approvisionnement et intégrer ce travail à la gestion des risques du programme (Figure 1).
Figure 1 : La gestion des risques nécessite une approche intégrée, collaborative et basée sur les données tout au long du cycle de vie et de la chaîne d’approvisionnement.
SBOM et opportunités pour leur utilisation
Le Département américain du Commerce (DOC) définit un SBOM comme suit dans son document Les éléments minimum pour une nomenclature logicielle (SBOM):
Un SBOM est un enregistrement formel contenant les détails et les relations dans la chaîne d’approvisionnement de divers composants utilisés dans la création de logiciels.
Les responsables de programmes s’appuient de plus en plus sur des techniques basées sur le SBOM pour collecter des informations sur les composants, ainsi que sur leurs sources ou fournisseurs, qui composent les systèmes logiciels. Les premiers efforts pour innover dans les méthodes SBOM se sont concentrés sur la définition des éléments de données et la gestion des vulnérabilités connues. En conséquence, plusieurs méthodes de gestion des informations et des risques ont émergé qui identifient les données critiques et connectent les équipes de support, les fournisseurs et les parties prenantes pour réduire les risques.
Le SBOM a gagné en importance avec Décret exécutif (EO) 14028Améliorer la cybersécurité de la nation. Publié le 12 mai 2021, l’EO 14028 exige que les agences gouvernementales américaines améliorent la sécurité et l’intégrité de la chaîne d’approvisionnement en logiciels, en donnant la priorité au traitement des logiciels critiques. s La transparence est un élément clé pour garantir la sécurité et l’intégrité de la chaîne d’approvisionnement logicielle. Les SBOM pour les logiciels critiques peuvent contribuer à établir cette transparence dans la chaîne d’approvisionnement logicielle. C’est pourquoi l’EO 14028 appelle à des normes, procédures et critères pour fournir des SBOM pour les produits directement ou pour les publier sur un site Web public.
Notre enquête sur les publications et les orientations du SBOM a révélé une forte importance accordée à la définition du contenu et du format des SBOM. S’il est important d’établir une norme pour le contenu SBOM, les organisations ont également besoin de conseils sur la manière de planifier, développer, déployer et utiliser les SBOM. Par conséquent, nous avons concentré nos activités de recherche sur le cycle de vie du SBOM (c’est-à-dire l’ensemble des activités nécessaires pour planifier, développer et utiliser un SBOM). Cependant, les SBOM doivent également soutenir (1) une réflexion proactive sur la meilleure façon de gérer les risques posés par des tiers, et (2) le développement de mesures d’atténuation efficaces à mesure que de nouvelles menaces et vulnérabilités émergent.
Il existe un large soutien en faveur d’une augmentation de l’utilité des SBOM. Une prochaine étape nécessaire consiste à développer des pratiques exemplaires et des processus de soutien. Le développement de cadres de pratique SBOM plus complets et collaboratifs offrira des techniques permettant d’établir et de gérer efficacement des informations logicielles proactives et des programmes de gestion des risques. Les SBOM peuvent également offrir aux développeurs de logiciels, aux intégrateurs et aux gestionnaires de risques une opportunité unique de collecter des informations qu’ils peuvent analyser, surveiller et exploiter pour gérer les composants logiciels, les fournisseurs, les dépendances, la provenance, les vulnérabilités, etc. : les possibilités sont infinies.
Nous reconnaissons également que le cycle de vie SBOM n’existe pas de manière isolée. Elle s’effectue plutôt dans un contexte organisationnel. En plus des activités de base du cycle de vie, nous devons envisager de permettre et de soutenir d’autres activités, telles que celles effectuées par la direction du programme, le soutien organisationnel (par exemple, technologie de l’information, gestion des risques et gestion du changement) et des tiers. À l’avenir, il est important d’examiner de manière créative comment les données SBOM peuvent être utilisées pour gérer les risques et l’efficacité des logiciels, et comment elles peuvent apporter un soutien aux équipes qui peuvent bénéficier d’efforts collaboratifs pour résoudre les problèmes.
Construire le cadre SBOM
Nous avons commencé à développer le framework SBOM en examinant les cas d’utilisation publiés. Sur la base de cet examen, nous avons développé des pratiques SBOM de base, axées principalement sur le développement de SBOM et leur utilisation pour gérer les vulnérabilités de sécurité connues et les risques associés. Nous avons ensuite élargi cet ensemble initial de pratiques en considérant une perspective de cycle de vie, qui a identifié des pratiques pour spécifier les exigences, développer des plans et allouer les ressources nécessaires à la création et à l’utilisation des SBOM. Enfin, nous avons identifié des pratiques pour les activités qui permettent et soutiennent l’utilisation opérationnelle des données SBOM, y compris les pratiques de gestion et de support, les pratiques de tiers et les pratiques d’infrastructure. Le résultat est un cadre SBOM comprenant les objectifs suivants (avec des pratiques tierces incluses dans les objectifs Exigences et Gérer/Support) :
- Exigences
- Planification
- Construction de bâtiments
- Déploiement/Utilisation
- Gestion/Assistance
Notre cadre SBOM fournit un point de départ pour intégrer les SBOM aux pratiques de gestion des risques de sécurité d’un programme. Au fur et à mesure que nous recueillons les enseignements tirés du pilotage du cadre et les commentaires de la communauté, nous mettrons à jour les objectifs et les pratiques du cadre, le cas échéant.
Tirer parti des informations SBOM
Les SBOM ont été principalement conçus pour aider les organisations à structurer davantage la gestion des risques logiciels. Les pratiques de gestion doivent non seulement identifier, mais atténuer efficacement les risques de sécurité et de résilience des systèmes. Cependant, les données et informations issues des SBOM, bien qu’elles constituent un facteur clé dans la gestion des risques, ont de nombreuses autres utilisations et innovations possibles.
L’obtention de résultats SBOM efficaces nécessite une planification, des outils adaptés à l’échelle, des ressources formées pour effectuer le travail, des mesures et/ou une surveillance. Les informations recueillies à partir d’un SBOM peuvent offrir un aperçu des défis rencontrés par les groupes engagés dans la gestion d’un système. La figure 2 présente certaines des équipes d’assistance qui pourraient utiliser et bénéficier des informations SBOM et les questions clés que ces informations peuvent résoudre pour améliorer les logiciels et les systèmes.
Figure 2 : Équipes pouvant bénéficier des informations SBOM.
Les données sur les risques et les vulnérabilités des logiciels sont riches et étendues. Malheureusement, les informations sur les risques contenues dans les SBOM ne font qu’ajouter à un flux d’informations déjà écrasant. Organiser et hiérarchiser ces informations est un défi, mais nous espérons que le cadre SBOM aidera les utilisateurs dans ces tâches.
L’analyse des données SBOM peut également aider à visualiser des relations et dépendances concrètes ou, dans certains cas, invisibles. Ces relations et dépendances peuvent être inestimables pour les équipes qui gèrent des logiciels dans des environnements techniques de plus en plus complexes. Cet avantage a été décrit dans Les éléments minimum pour une nomenclature logicielle (SBOM):
Un SBOM doit contenir tous les composants principaux (niveau supérieur), avec toutes leurs dépendances transitives répertoriées. Au minimum, toutes les dépendances de niveau supérieur doivent être répertoriées avec suffisamment de détails pour rechercher les dépendances transitives de manière récursive.
Aller plus loin dans le graphique fournira plus d’informations. Alors que les organisations démarrent le SBOM, la profondeur au-delà des composants principaux peut ne pas être facilement disponible en raison des exigences existantes avec les fournisseurs de sous-composants. L’adoption éventuelle des processus SBOM permettra d’accéder à une profondeur supplémentaire grâce à des niveaux de transparence plus profonds au niveau des sous-composantes.
En gardant à l’esprit cet appel à une meilleure visualisation des données, nous avons complété notre développement du cadre SEI SBOM avec un projet parallèle visant à représenter graphiquement les données exportées à partir d’un outil SBOM. Nous ingérons les données pour créer les prototypes graphiques pour des recherches et analyses plus approfondies (en Format SDPXqui est un standard ouvert pour communiquer des informations SBOM).
Un cadre pour étendre l’utilité des SBOM
Les SBOM deviennent cruciales dans la gestion des risques et de la résilience des logiciels et des systèmes. Motivés par l’EO 14028, de multiples efforts sont en cours pour étendre leur utilisation. Plus important encore, il est largement reconnu que les risques posés par le manque de transparence des logiciels doivent être pris en compte pour contribuer à garantir la sécurité et promouvoir la résilience des systèmes. Nous pensons que les pratiques et processus décrits dans notre cadre SBOM peuvent fournir un point de départ pour structurer les efforts SBOM. Ce cadre aborde la mise en place de processus pour gérer plusieurs SBOM et les vastes données qu’ils peuvent fournir ; cependant, ces processus nécessiteront probablement des ajustements supplémentaires à mesure que les activités pilotes fournissent des informations sur les améliorations et les outils.
Nous espérons que notre cadre SBOM contribuera à promouvoir l’utilisation des SBOM et à établir un ensemble plus complet de pratiques et de processus que les organisations pourront exploiter lors de l’élaboration de leurs programmes. Entre-temps, nous continuerons à communiquer largement sur les avantages et les utilisations potentielles des SBOM et à recueillir les commentaires des pilotes. Nous continuerons également à explorer les possibilités de projets pilotes. Lorsque l’adoption du cadre SBOM a eu lieu, nous étudierons les leçons apprises pour nous aider à apporter des améliorations.
Pour une discussion plus complète sur le cadre SEI SBOM, nous vous encourageons à lire notre livre blanc, Cadre de nomenclature logicielle : tirer parti des SBOM pour réduire les risques. Si vous souhaitez piloter le cadre ou collaborer sur des travaux futurs, contactez-nous à [email protected].
