Que contient le logiciel commercial et open source que vous utilisez ? Quelle partie a été écrite par le fournisseur et quelle partie est du code tiers ? Peut-on faire confiance à tout ce code ?
Les menaces sont réelles
La récente vague de cyberattaques de grande envergure démontre amplement le coup- sur les effets des cyberincidents agressifs. Le piratage de SolarWinds a exposé ses clients’ réseaux à la menace de compromission par les cybercriminels. L'attaque Codecov a exposé leurs utilisateurs’ environnements d'intégration continue/de déploiement continu aux acteurs de la menace.
CONNEXESPiratage SolarWinds : que s'est-il passé et comment vous protéger ?
Dans les deux cas, l'attaque contre les organisations s'est propagée en aval aux autres clients de cet écosystème— Les attaques qui paralysent les infrastructures critiques ont un impact beaucoup plus large. Ce ne sont pas seulement les clients de l'organisation ou du service concerné qui sont touchés, les répercussions s'étendent vers des secteurs non liés et la société au sens large.
L'attaque de ransomware de mai 2021 contre la Colonial Pipeline Company a entraîné la fermeture d'un pipeline de 5 500 milles. Parmi les autres carburants raffinés, le pipeline fournit 45% de l'approvisionnement en essence – 2,5 millions de barils par jour d'essence à la côte est. La livraison d'essence s'est tout simplement arrêtée. Les prix à la pompe ont grimpé en flèche et la panique s'est installée. Des milliers de stations-service ont dû fermer en raison du manque d'approvisionnement.
L'attaque de la Colonial Pipeline Company était motivée par des considérations financières. Il s'agissait d'une attaque de ransomware, une forme courante d'extorsion numérique. Colonial Pipeline a payé aux cybercriminels une rançon de 75 Bitcoins—environ 4,4 millions de dollars, selon les taux de change—pour que leurs systèmes leur soient restaurés.
Mais s'il s'agissait d'un acte de cyberterrorisme ou de cyberguerre, il n'y aurait pas eu d'option pour acheter le programme de décryptage requis pour remettre les systèmes touchés en ligne. Un État-nation doté de capacités cyber-offensives peut empêcher un autre pays de fonctionner en interne via une campagne de cyberattaques stratégiques.
CONNEXES : Besoin de payer la rançon ? Négocier d'abord
Répondre aux menaces
Le 21 mars 2021, le président Biden a signé un décret sur l'amélioration de la la cybersécurité du pays. Il énonce un ensemble de normes et d'exigences que tous les systèmes d'information fédéraux doivent respecter ou dépasser.
L'article 4 du décret traite des moyens d'améliorer la sécurité de la chaîne d'approvisionnement des logiciels. Cela impose aux ministères du gouvernement des obligations liées à la date de fournir des conseils, des normes et des procédures pour de nombreux aspects du développement et de l'achat de logiciels. Les fournisseurs de logiciels doivent respecter les normes et suivre les procédures afin d'être des fournisseurs de logiciels éligibles pour le gouvernement.
La transparence est citée comme une exigence. Les fournisseurs de logiciels doivent révéler tous les composants et bibliothèques tiers qui ont été utilisés dans le développement de leurs produits. Cette exigence se répercute tout au long de la chaîne d'approvisionnement, de sorte que les fournisseurs de ces bibliothèques et composants doivent à leur tour répertorier tous les composants logiciels externes qu'ils ont utilisés dans leurs produits.
Les logiciels open source sont spécifiquement mentionnés. Le décret parle de « garantir et d'attester, dans la mesure du possible, l'intégrité et la provenance des logiciels open source utilisés dans n'importe quelle partie d'un produit.
Ce n'est pas surprenant. Un rapport de 2021 sur la sécurité open source a révélé que le nombre moyen de composants open source dans les projets commerciaux non triviaux est de 528. Cela représente une augmentation de 259% par rapport à il y a cinq ans, lorsque la moyenne était de 84 composants open source. par projet.
CONNEXES : Comment utiliser en toute sécurité le code Open Source dans votre projet
Open-Source en tant que consommable
De toute évidence, les projets open source doivent répondre aux normes et procédures qui seront édictées à la suite du décret. À première vue, la partie transparence devrait être facile. Les projets open source suspendent leur code source pour tout type d'examen. Mais bien sûr, les projets open source utilisent d'autres composants open source, qui utilisent d'autres composants open source, etc., imbriqués comme des poupées russes.
De plus, les applications logicielles ont des dépendances. Ils s'appuient sur d'autres progiciels pour fonctionner. En choisissant d'inclure un seul composant open source dans votre propre projet de développement, vous pourriez involontairement inclure de nombreux autres produits open source en tant que dépendances.
Donc, avoir votre code source disponible pour examen n'est pas suffisant. Vous devez fournir une liste des ingrédients logiciels de votre produit, tout comme la liste des ingrédients alimentaires et chimiques sur un emballage de barre chocolatée. Dans le monde du logiciel, cela s'appelle une nomenclature logicielle ou un SBOM.
La nomenclature logicielle
CONNEXESComment se défendre contre les rootkits
La sécurité commence par la connaissance. Vous devez savoir ce que vous avez afin de vous assurer que vous l'avez sécurisé. C'est pourquoi les registres des actifs informatiques et les registres informatiques sont si importants. Un SBOM (prononcé ess-bomb) est un document spécifique à une application qui répertorie tous les éléments logiciels qui composent un produit logiciel.
C'est une connaissance précieuse. L'avoir permet aux utilisateurs de ce logiciel de prendre des décisions en matière de sécurité. Si vous connaissez les composants présents dans le logiciel, le risque associé à chacun d'eux et la gravité de chaque risque, vous pouvez faire des choix réfléchis et éclairés.
Vous pourriez lire la liste des ingrédients sur l'emballage d'une barre chocolatée et découvrir qu'elle contient quelque chose auquel vous êtes allergique. Avec un SBOM, vous pouvez examiner les versions de build, les numéros de version des ingrédients logiciels et décider de continuer ou non. Par exemple, vous pourriez refuser catégoriquement d'utiliser un produit qui intègre (disons) telnet, ou un produit qui utilise une version de SSH qui présente une vulnérabilité connue.
Créer un SBOM détaillé n'est pas’ ta tâche de cinq minutes. Mais il doit être précis et suffisamment détaillé, sinon il ne servira pas son objectif. Au minimum, pour chaque composant logiciel d'un projet logiciel, un SBOM doit contenir :
- Nom du fournisseur : Le fournisseur ou les personnes qui ont écrit le logiciel.
- Nom du composant : le nom du composant.
- Identifiant unique : Un identifiant universel unique (UUID).
- Chaîne de version : les détails de la version et de la version du composant.
- Hachage du composant : hachage cryptographique du composant. Cela permet à un destinataire de vérifier, s'il a des soupçons, si un binaire qui lui a été fourni a été modifié.
- Relation : la relation entre les composants logiciels décrit les dépendances entre les composants et les composants qui ont été compilés et liés à d'autres composants.
- Licence : le type de licence que le composant logiciel est publié sous.
- Nom de l'auteur : l'auteur du SBOM. Ce n'est pas nécessairement le fournisseur du logiciel.
S'il doit y avoir une large adoption des SBOM, il doit y avoir une norme définissant les formats de données, le contenu des données et les processus et normes acceptés. Cela est susceptible d'apparaître dans le cadre des directives que le décret a demandé de créer.
Il existe plusieurs normes SBOM concurrentes. Les trois précurseurs dans cet espace sont Software Package Data Exchange (SPDX), la norme ISO 19770-5:2013 Software Identification (SWID) et CycloneDX. Il sera intéressant de voir si l'un d'entre eux est adopté par le gouvernement fédéral comme norme préférée.
L'automatisation peut vous aider
RELATEDQu'est-ce que le typosquattage et comment les escrocs l'utilisent-ils ?
Plusieurs classes d'outils peuvent aider à la production et à l'utilisation de SBOM. Des packages logiciels sont disponibles qui peuvent analyser des projets, déterminer les dépendances et générer des SBOM—ou des SBOM presque complets dans lesquels vous pouvez déposer quelques détails de finition.
Les SBOM seront probablement disponibles sous forme de téléchargements ou dans le cadre du logiciel packagé, un peu comme un “readme” déposer. Une fois que vous êtes en possession du SBOM de quelqu'un d'autre, vous devez le revoir.
Cela va prendre du temps. Chaque composant devra être vérifié pour s'assurer qu'il est autorisé selon les critères que votre organisation a définis, et que la licence de chaque composant ne cause aucun conflit pour vous.
< p>Un logiciel est disponible qui peut effectuer ces vérifications pour vous. Les packages les plus complets répertorient les vulnérabilités connues pour chaque composant et la gravité de ces vulnérabilités.
La sécurité commence par la connaissance
La provenance des progiciels et de tous leurs composants va devenir un outil essentiel pour les consommateurs de logiciels pour évaluer et prendre des décisions d'achat. Ce sera également un élément différenciateur pour les fournisseurs et les producteurs de logiciels, qu'ils créent des logiciels pour d'autres développeurs ou pour les utilisateurs finaux.