Imaginez que vous envisagez une nouvelle voiture pour votre famille. Avant d’effectuer un achat, vous évaluez ses cotes de sécurité, son efficacité énergétique et sa fiabilité. Vous pourriez même le prendre pour un essai routier pour vous assurer qu’il répond à vos besoins. La même approche doit être appliquée aux logiciels et aux produits matériels avant de les intégrer dans l’environnement d’une organisation. Tout comme vous n’achètez pas de voiture sans connaître ses caractéristiques de sécurité, vous ne devriez pas déployer de logiciels sans comprendre les risques qu’il présente.
La menace croissante des attaques de chaîne d’approvisionnement
Les cybercriminels ont reconnu qu’au lieu d’attaquer une organisation de front, ils peuvent s’infiltrer à travers la chaîne d’approvisionnement du logiciel, comme le glissement de pièces contrefaites dans une chaîne de montage. Selon le 2024 Rapport sur l’état de la chaîne d’approvisionnement du logicielles attaquants infiltrent les écosystèmes open source à un rythme alarmant, avec plus de 512 847 packages malveillants détectés l’année dernière, une augmentation de 156% par rapport à l’année précédente. Les outils et processus de sécurité traditionnels manquent souvent ces menaces, laissant les organisations non préparées.
Un exemple majeur en 2024 a été une attaque de chaîne d’approvisionnement d’un an découverte dans l’indice de package Python (PYPI). Les attaquants ont téléchargé des forfaits malveillants déguisés en outils légitimes de chatbot d’IA, espérant inciter les développeurs à les intégrer dans leurs projets. Ces packages contenaient du code nocif conçu pour voler des données sensibles et exécuter des commandes distantes sur les systèmes infectés. Parce que le PYPI est largement utilisé dans diverses industries, cette attaque a le potentiel de compromettre des milliers d’applications devant les chercheurs en sécurité Kaspersky détecté et signalé l’activité malveillante. Cet incident met en évidence la façon dont les attaquants exploitent de plus en plus des référentiels de confiance pour distribuer des logiciels malveillants, renforçant la nécessité de mesures approfondies supplémentaires lors de l’évaluation des logiciels.
Une approche pratique de l’évaluation des risques: tests de sécurité des produits
Les organisations ont besoin d’un moyen structuré et reproductible d’évaluer les risques logiciels et matériels avant de les introduire dans leur environnement. Ce processus, appelé test de sécurité des produits (PST), consiste à répondre aux questions clés:
- Quels risques ce produit présente-t-il à mon réseau?
- Devrions-nous utiliser ce produit ou y a-t-il une alternative plus sûre?
- Si nous l’utilisons, quelles atténuations devraient être mises en place pour minimiser les risques?
Le PST ne consiste pas seulement à scanner des vulnérabilités – il s’agit de comprendre comment un produit se comporte dans votre environnement spécifique et de déterminer son impact sur le risque global. Compte tenu du grand nombre de composants tiers utilisés dans l’informatique moderne, il n’est pas réaliste de examiner tous les logiciels également. Au lieu de cela, les équipes de sécurité devraient hiérarchiser leurs efforts en fonction de l’impact commercial et attaquer l’exposition à la surface. Les applications à grande privilège qui communiquent fréquemment avec les services externes doivent subir des tests de sécurité des produits, tandis que les applications à risque à moindre risque peuvent être évaluées par des méthodes automatisées ou moins intensives aux ressources. Qu’il soit fait avant le déploiement ou en tant qu’analyse rétrospective, une approche structurée du PST garantit que les organisations se concentrent d’abord sur la sécurisation des actifs les plus critiques tout en maintenant l’intégrité globale du système.
Apprendre à penser rouge, agir bleu
Le Cours SANS SEC568 est conçu pour développer des compétences pratiques en PST. Il se concentre sur les tests noirs, une méthode qui simule les conditions du monde réel où le code source n’est pas disponible. Cela le rend très applicable pour évaluer les produits tiers sur lesquels les organisations n’ont pas de contrôle direct. Le cours suit le principe de Think Red, Act Blue – en apprenant des tactiques offensives, les organisations peuvent mieux se défendre contre eux.
Bien que les tests de sécurité des produits n’empêcheront jamais la violation d’un tiers de votre contrôle, il est nécessaire de permettre aux organisations de prendre des décisions éclairées sur leur stratégie de posture et de réponse défensive. De nombreuses organisations suivent un processus standard d’identification d’un besoin, de sélection d’un produit et de le déployer sans évaluation de sécurité profonde. Ce manque de contrôle peut les laisser se précipiter pour déterminer l’impact lorsqu’une attaque de la chaîne d’approvisionnement se produit.
En incorporant le PST dans le processus décisionnel, les équipes de sécurité obtiennent une documentation critique, notamment la cartographie des dépendances, les modèles de menaces et les atténuations spécifiques adaptées à la technologie utilisée. Cette approche proactive réduit l’incertitude, permettant des réponses plus rapides et plus efficaces lorsque les vulnérabilités émergent. Plutôt que de s’appuyer uniquement sur de larges atténuations de l’industrie, les organisations ayant une documentation PST peuvent mettre en œuvre des contrôles de sécurité ciblés qui minimisent les risques avant même une infraction.
Qui tire parti des tests de sécurité des produits?
Quel que soit le titre du poste, avoir une base solide dans les tests de sécurité des produits conduit à une meilleure posture de sécurité et à une préparation au sein de toute l’organisation. Bien que l’ajustement évident soit que les équipes de test de sécurité des produits peuvent tirer parti de ces méthodologies pour évaluer les logiciels tiers ainsi que leurs propres produits internes – les tests de sécurité des produits ne sont pas limités à un rôle spécifique. Il s’agit d’un ensemble de compétences précieux qui améliore divers postes au sein d’une organisation. Les auditeurs de sécurité peuvent utiliser le PST pour adapter les évaluations aux risques uniques et aux besoins de conformité d’une organisation, tandis que les testeurs de pénétration peuvent aller au-delà des analyses de vulnérabilité simples pour analyser les protocoles inconnus et les logiciels propriétaires. Les développeurs d’applications bénéficient de comprendre comment les attaquants exploitent les défauts de sécurité, les aidant à écrire un code plus sécurisé dès le début, tandis que les analystes SOC peuvent utiliser ces compétences pour détecter et atténuer les menaces introduites par de nouveaux logiciels et matériels. Même les décideurs obtiennent des informations de la PST, car cela les aide à faire des choix éclairés sur les risques, les investissements en sécurité et les stratégies d’atténuation. Il est important de se rappeler qu’il est impossible de détecter, d’atténuer, d’exploiter ou de développer ce que nous ne comprenons pas.
Pour acquérir une expérience pratique dans les tests de sécurité des produits, envisagez d’assister à la Sec568 à Orlando du 13 au 18 avril 2024. Cette formation fournira les fondements techniques nécessaires pour évaluer efficacement la sécurité des logiciels et du matériel. Tout comme la prise d’une voiture pour un essai routier avant d’acheter, l’application d’une approche structurée aux tests de sécurité des produits permet aux organisations de bien comprendre les risques potentiels avant le déploiement. En suivant une méthodologie reproductible, les équipes de sécurité peuvent réduire les risques et être mieux préparés pour les menaces futures.
Note: Cet article a été rédigé de manière experte et apportée par Douglas McKee, directeur exécutif de la recherche sur les menaces de Sonicwall, ainsi que l’auteur et l’instructeur de SANS568.