L’attaque de la chaîne d’approvisionnement de SolarWinds, révélée en décembre 2020, reste l’événement de sécurité de la chaîne d’approvisionnement le plus lourd de conséquences de l’époque récente. Des attaquants liés au SVR russe ont obtenu l’accès à l’infrastructure de compilation de SolarWinds et inséré du code malveillant dans le processus de compilation de la plateforme de supervision informatique Orion. Ce code malveillant a été compilé dans des mises à jour légitimes du logiciel Orion, signé avec la clé de signature de code authentique de SolarWinds et distribué par le mécanisme légitime de mise à jour logicielle de SolarWinds à environ 18,000 clients, dont des agences fédérales américaines, des entreprises de la défense et de grandes entreprises. L’attaque est restée dans l’infrastructure de compilation pendant environ quatorze mois avant d’être découverte. Pendant ces quatorze mois, les attaquants ont eu un accès complet aux réseaux de milliers d’organisations par le canal de mise à jour logicielle de confiance.
Les leçons que SolarWinds devait enseigner sont précises et directement applicables au TPRM : la sécurité du pipeline de compilation compte autant que celle de l’environnement de production ; la signature de code n’offre qu’une assurance limitée si l’infrastructure de signature est compromise ; les mécanismes de mise à jour logicielle sont des cibles d’attaque de grande valeur ; et le temps de présence de quatorze mois a été possible parce qu’aucune surveillance ne visait l’infrastructure de compilation. Ces leçons ont été largement publiées et discutées, mais elles n’ont en grande partie pas été intégrées aux listes de contrôle d’évaluation TPRM standard, qui restent centrées sur la sécurité de l’environnement de production, les contrôles SOC 2 et la posture de sécurité opérationnelle, tout en laissant hors du périmètre d’évaluation la sécurité du pipeline de compilation, la protection des clés de signature, la gouvernance des mécanismes de mise à jour et la surveillance de la chaîne d’approvisionnement.
La défaillance systémique tient au retard des cadres d’évaluation. Les cadres d’évaluation de la sécurité sont mis à jour au fil du temps pour couvrir de nouvelles catégories de menaces, mais ce cycle de mise à jour est lent et progressif. Les questionnaires et cadres d’évaluation standard conçus avant SolarWinds reflètent un modèle de menace qui exclut le vecteur d’attaque mis en évidence par SolarWinds. Les praticiens qui utilisent des cadres standard sans les compléter par les exigences de sécurité de la chaîne d’approvisionnement post-SolarWinds évaluent selon un modèle de menace antérieur à SolarWinds : ils confirment que les fournisseurs sont protégés contre les attaques de 2019 tout en laissant de côté les attaques de 2020 et des années suivantes.
Pourquoi c’est important
Les leçons non retenues de SolarWinds comptent pour le TPRM, car elles traduisent un écart systématique entre les capacités actuelles d’attaque de la chaîne d’approvisionnement et les questions d’évaluation posées par la plupart des programmes TPRM. Un éditeur de logiciels qui réussit toutes les évaluations de sécurité standard tout en ayant un pipeline de compilation sans surveillance, une clé de signature stockée dans un fichier sur un serveur et un mécanisme de mise à jour sans détection des anomalies est un fournisseur vulnérable à une attaque de type SolarWinds, quel que soit son statut SOC 2.
- Sécurité du pipeline de compilation absente de l’évaluation : le point d’entrée de SolarWinds n’est pas traité
- Protection des clés de signature non évaluée : stockage dans un fichier ou dans un HSM, la question n’est pas posée
- Sécurité du mécanisme de mise à jour non évaluée : le vecteur de distribution de SolarWinds n’est pas traité
- Surveillance de la chaîne d’approvisionnement non évaluée : sans elle, une présence de quatorze mois est possible
- Cadre d’évaluation non mis à jour après SolarWinds pour le risque lié à la couche de compilation
À quoi ressemblent les bonnes pratiques
Les cadres d’évaluation post-SolarWinds ajoutent la sécurité du pipeline de compilation, la protection des clés de signature, la gouvernance des mécanismes de mise à jour et la surveillance de la chaîne d’approvisionnement au périmètre d’évaluation standard, afin de traiter spécifiquement les quatre lacunes de contrôle dont SolarWinds a démontré l’insuffisance.
- Sécurité du pipeline de compilation dans le périmètre d’évaluation : intégrations tierces, identifiants, isolement
- Protection des clés de signature dans l’évaluation : HSM ou stockage dans un fichier, politique de rotation
- Sécurité du mécanisme de mise à jour dans l’évaluation : authenticité, intégrité, contrôle par l’entreprise
- Surveillance de la chaîne d’approvisionnement dans l’évaluation : journaux du pipeline de compilation, surveillance du registre d’artefacts
- Cadre d’évaluation mis à jour pour refléter le modèle de menace post-SolarWinds de la chaîne d’approvisionnement
Outils
Référence sur les leçons de SolarWinds : recommandations de la CISA sur SolarWinds ; contrôles propres à la chaîne d’approvisionnement de la NIST SP 800-161 Rev. 1, mis à jour après SolarWinds
La CISA a publié, à la suite de la révélation de l’attaque SolarWinds, des recommandations précises portant sur les contrôles techniques utiles contre la compromission des pipelines de compilation et pour la détection des attaques de la chaîne d’approvisionnement. La NIST SP 800-161 Rev. 1 a été mise à jour pour traiter spécifiquement la sécurité de la chaîne d’approvisionnement logicielle en réponse à l’attaque SolarWinds et aux décrets présidentiels. Ces documents apportent aux cadres d’évaluation les mises à jour post-SolarWinds que les questionnaires standard n’ont pas encore intégrées.
Enjeux de gouvernance
La difficulté de gouvernance liée aux leçons non retenues de SolarWinds tient à l’inertie des cadres d’évaluation. Les questionnaires standard sont mis à jour par des comités selon des cycles pluriannuels. Les praticiens qui attendent que les cadres standard intègrent des questions post-SolarWinds sur la sécurité de la chaîne d’approvisionnement continueront d’évaluer selon un modèle de menace antérieur à SolarWinds. La solution de gouvernance consiste à compléter les cadres standard par des questions propres à la chaîne d’approvisionnement qui traitent explicitement le vecteur d’attaque de SolarWinds.
- Compléter les cadres d’évaluation standard par des questions sur la sécurité du pipeline de compilation
- Ajouter la protection des clés de signature au périmètre d’évaluation standard
- Ajouter la sécurité du mécanisme de mise à jour au périmètre d’évaluation standard
- Ajouter la surveillance de la chaîne d’approvisionnement au périmètre d’évaluation standard
- Faire explicitement référence au modèle d’attaque SolarWinds dans les exigences de sécurité de la chaîne d’approvisionnement
Si vous êtes une petite équipe
Ajoutez à votre prochaine évaluation d’éditeur de logiciels quatre questions qui ne figurent pas dans votre questionnaire actuel : (1) Comment votre pipeline de compilation est-il isolé de votre environnement de production ? (2) Comment vos clés privées de signature de code sont-elles protégées contre l’extraction ? (3) Comment détectez-vous les accès anormaux à votre pipeline de compilation et à votre registre d’artefacts ? (4) Comment gouvernez-vous votre mécanisme de mise à jour logicielle pour garantir que seules des mises à jour légitimes sont distribuées ? Ces quatre questions traitent directement les quatre lacunes de contrôle de SolarWinds et s’ajoutent en cinq minutes à n’importe quel cadre d’évaluation.
- Ajouter une question sur l’isolement du pipeline de compilation à l’évaluation
- Ajouter une question sur la protection des clés de signature à l’évaluation
- Ajouter une question sur la surveillance de la chaîne d’approvisionnement à l’évaluation
- Ajouter une question sur la sécurité du mécanisme de mise à jour à l’évaluation
Ce qu’il faut exiger
Demandez directement :
« Au regard du modèle d’attaque SolarWinds (compromission du pipeline de compilation, accès à la clé de signature et distribution par des canaux de mise à jour légitimes), de quels contrôles précis disposez-vous pour chacun de ces trois vecteurs d’attaque, et comment surveillez-vous les activités anormales dans votre infrastructure de compilation et de distribution ? »
Preuves attendues
- Contrôles d’isolement et de surveillance du pipeline de compilation
- Protection des clés de signature : HSM ou équivalent
- Sécurité du mécanisme de mise à jour et gouvernance par l’entreprise
- Périmètre de surveillance de la chaîne d’approvisionnement et capacité de détection
Il convient de poser les quatre questions post-SolarWinds à un fournisseur qui réussit une évaluation de sécurité standard. Les évaluations standard s’appuient sur le modèle de menace de 2019. Les questions post-SolarWinds s’appuient sur le modèle de menace de 2020, que les cadres standard n’ont pas encore intégré.
Comment le prouver
- Complément aux évaluations post-SolarWinds
- Dossiers d’évaluation de la sécurité du pipeline de compilation
- Évaluation de la protection des clés de signature
- Vérification du périmètre de surveillance de la chaîne d’approvisionnement
À retenir
SolarWinds: 2020. Build pipeline compromised. Signing key accessed. 18,000 organisations reached through legitimate update channel. Fourteen months undetected. Assessment checklists four years later: same questions as 2019. The four control gaps SolarWinds demonstrated , build pipeline isolation, signing key protection, update mechanism security, supply chain monitoring , are absent from most standard assessment frameworks. Adding four specific questions to the next software vendor assessment takes five minutes and directly addresses the attack vector that the standard questionnaire predates and has never been updated to cover.