Failles supply chain : leçons de SolarWinds, MOVEit et XZ pour les PME suisses

Un fournisseur de confiance, premier vecteur d'attaque

En décembre 2020, la mise à jour légitime d'Orion (SolarWinds) dépose un backdoor nommé SUNBURST sur les systèmes de 18 000 clients — agences fédérales américaines, grandes entreprises, mais aussi des filiales et fournisseurs européens. En juin 2023, la faille dans MOVEit Transfer (CVE-2023-34362) expose les données de plus de 2 500 organisations dans le monde via un seul outil de transfert de fichiers. En mars 2024, une backdoor est découverte dans XZ Utils 5.6.0 et 5.6.1, une bibliothèque de compression présente dans la quasi-totalité des distributions Linux — l'insertion avait été préparée pendant deux ans par un contributeur fictif. Ces trois incidents partagent un point commun : l'attaquant n'a pas forcé la porte frontale. Il est passé par la livraison de logiciel.

Pour une PME romande de 40 à 150 endpoints, la menace supply chain est doublement insidieuse : les alertes de sécurité ciblent les grandes entreprises, et les équipes IT internes n'ont pas toujours les moyens de surveiller l'intégrité de chaque composant logiciel. Pourtant, la chaîne d'approvisionnement logicielle d'une fiduciaire genevoise ou d'un bureau d'études lausannois passe par les mêmes éditeurs, les mêmes dépôts open source et les mêmes outils de transfert de fichiers que ceux des multinationales.

Anatomie des trois incidents : ce qui s'est vraiment passé

SolarWinds Orion (2020) : l'intégration continue comme vecteur

Les attaquants — attribués au groupe Cozy Bear / APT29 — ont compromis le pipeline de build de SolarWinds. Le code malveillant était inséré avant la signature de la mise à jour. Résultat : le binaire livré était cryptographiquement valide. Les mécanismes de vérification d'intégrité habituels (hash SHA-256, signature Authenticode) ne détectaient rien d'anormal. Le malware dormait 14 jours après l'installation pour échapper aux sandbox automatisées, puis établissait un canal C2 via HTTPS (port TCP 443) vers des sous-domaines d'avsvmcloud[.]com, imitant du trafic SolarWinds légitime.

Leçon technique : la signature de code garantit l'intégrité depuis le moment de la signature — pas la propreté du code source. Un pipeline CI/CD compromis peut produire des artefacts signés légitimement malveillants.

MOVEit Transfer (2023) : une injection SQL dans un produit périmétrique

CVE-2023-34362 est une injection SQL non authentifiée dans le module de gestion des sessions HTTP de MOVEit Transfer. Exploitée par le groupe Cl0p, elle permettait d'exfiltrer l'intégralité des fichiers stockés sur le serveur, puis de déposer un webshell (LEMURLOOT) pour maintenir l'accès. Plusieurs organisations suisses figurent parmi les victimes indirectes via des prestataires de paie ou de RH.

Le délai entre la disponibilité publique de l'exploit (27.05.2023) et le déploiement de correctifs par les entreprises a varié de 24 heures à plusieurs semaines. Pour les organisations sans inventaire précis de leurs applications exposées sur Internet, MOVEit n'apparaissait même pas dans leur liste d'actifs critiques.

XZ Utils (2024) : ingénierie sociale sur deux ans

La backdoor dans XZ Utils 5.6.0–5.6.1 (CVE-2024-3094) est le cas le plus sophistiqué. Un contributeur identifié sous le pseudonyme « Jia Tan » a construit une réputation dans le projet open source pendant deux ans, obtenu les droits de commit, puis inséré une modification dans le script de build (m4/build-to-host.m4) qui injectait du code malveillant uniquement lors de la compilation sur des systèmes Debian/RPM — pas sur les builds de test standards. Le code ciblait le daemon SSH systemd (sshd) pour permettre une authentification non autorisée via une clé RSA privée connue de l'attaquant uniquement.

La faille a été découverte par chance par Andres Freund (ingénieur Microsoft) qui avait remarqué une latence anormale de 500 ms sur les connexions SSH. Les versions affectées n'avaient pas encore atteint les distributions stables majeures, limitant l'impact réel — mais la méthode est réutilisable sur n'importe quel projet open source critique.

Cadre légal suisse : obligations des PME en cas d'incident supply chain

nLPD et notification au PFPDT

Depuis le 01.09.2023, la nouvelle Loi fédérale sur la protection des données (nLPD) impose aux responsables du traitement de notifier le Préposé fédéral à la protection des données et à la transparence (PFPDT) en cas de violation de données susceptible d'entraîner un risque élevé pour les personnes concernées. Il n'existe pas de délai fixe de 72 heures comme en RGPD — la notification doit intervenir « dans les meilleurs délais » (art. 24 nLPD). En pratique, le PFPDT attend une notification dans les 72 à 96 heures suivant la prise de connaissance de la violation.

Un incident supply chain tel que MOVEit — où un prestataire RH suisse expose des données de salaires de PME clientes — tombe directement dans le champ de l'art. 24 nLPD. La PME cliente reste responsable du traitement même si l'incident technique est chez son sous-traitant (art. 9 nLPD sur les sous-traitants).

Signalement au NCSC

Le Centre national pour la cybersécurité (NCSC) dispose d'un formulaire de signalement en ligne pour les cyberincidents. Le signalement est volontaire pour les PME non critiques, mais fortement recommandé : il permet au NCSC d'émettre des alertes nationales et d'alerter d'autres organisations potentiellement victimes du même vecteur. Pour les opérateurs d'infrastructures critiques (santé, énergie, finance), une obligation de notification est en cours d'introduction via la révision de la LEI.

Responsabilité contractuelle envers les clients

Si une PME suisse subit une fuite via un outil tiers (ex. : logiciel de transfert de fichiers partagé avec des clients), sa responsabilité civile envers ces clients peut être engagée. Les contrats de prestation doivent inclure des clauses de notification d'incident avec délais contraignants, des SLA de correction (ex. : correctif critique appliqué sous 24 h, important sous 72 h), et une obligation de tenue d'un registre des incidents (art. 12 nLPD).

Architecture de défense pour une PME avec 20 à 150 endpoints

Inventaire des composants logiciels (SBOM)

Un Software Bill of Materials (SBOM) est la liste exhaustive des composants logiciels d'une application ou d'un système. Pour une PME, l'objectif minimal est un inventaire des logiciels tiers installés sur les endpoints et des outils exposés sur Internet (VPN, transfert de fichiers, portails RH). Des formats standardisés existent : SPDX (ISO 5962) et CycloneDX. Sans SBOM, une alerte comme XZ Utils prend 48 à 72 heures à qualifier — avec SBOM, la requête prend moins de 5 minutes.

Gestion des mises à jour et vérification d'intégrité

Les trois incidents montrent que les mises à jour automatiques sans vérification sont un risque. Les CIS Benchmarks recommandent pour les environnements critiques un processus en deux temps : déploiement sur un groupe pilote (5 à 10 % du parc) pendant 48 à 72 heures, puis déploiement global. Pour les correctifs de sécurité CVSS ≥ 9.0, ce délai est réduit à zéro — déploiement immédiat post-validation.

Pour les logiciels open source critiques, vérifier systématiquement le hash SHA-256 de l'archive téléchargée contre la valeur publiée par le projet, et ne jamais compiler depuis une source non vérifiée.

Segmentation réseau et principe du moindre privilège

SolarWinds Orion fonctionnait avec des droits d'administration sur l'Active Directory dans de nombreuses organisations. Sans ces droits, l'impact de SUNBURST aurait été limité à la machine hôte. Pour une PME :

• Les outils de monitoring réseau, de transfert de fichiers et de gestion IT ne doivent pas avoir de droits d'administration sur les contrôleurs de domaine.
• Les flux sortants des serveurs de fichiers vers Internet doivent être filtrés (liste blanche de domaines). Le C2 de SUNBURST utilisait TCP 443 vers avsvmcloud[.]com — un proxy sortant avec inspection TLS aurait détecté ce domaine inconnu.
• La micro-segmentation entre workstations et serveurs réduit le rayon de blast en cas de compromission latérale.

Gestion des accès fournisseurs

Chaque accès accordé à un prestataire externe (MSP, éditeur, support) est un vecteur potentiel. Pratiques minimales : accès temporaires avec expiration automatique (ex. : 4 heures pour une intervention de support), authentification multi-facteur obligatoire pour tout accès VPN ou RDP, journalisation complète des sessions (logs conservés 180 jours minimum selon les recommandations NIST Cybersecurity Framework).

Cas pratique : fiduciaire vaudoise de 35 collaborateurs, incident MOVEit

Contexte

Fiduciaire Dupraz & Associés SA, Lausanne. 35 collaborateurs, 280 dossiers clients PME actifs. Utilisation d'un logiciel de paie externalisé (SaaS) dont le prestataire utilisait MOVEit Transfer pour les échanges de fichiers avec ses clients fiduciaires. Le 31.05.2023, le prestataire notifie par e-mail que MOVEit a été compromis et que des fichiers de paie pourraient avoir été exfiltrés.

Procédure de réponse étape par étape

1. J0 — Réception de la notification (31.05.2023, 14h30) : Le DSI (responsable IT interne) isole immédiatement les connexions vers le portail du prestataire. Il ouvre un ticket d'incident et notifie la direction (associé gérant).
2. J0 — Qualification de l'incident : Le DSI détermine quels dossiers clients ont transité par MOVEit : 147 bulletins de salaire de mai 2023, soit des données de 147 employés de clients fiduciaires (noms, salaires, numéros AVS partiels). Le RSSI (externalisé) est contacté à 15h45.
3. J0/J1 — Évaluation du risque nLPD : Le juriste de la fiduciaire confirme que les numéros AVS et données salariales constituent des données personnelles sensibles. Le risque pour les personnes concernées est évalué comme élevé (vol d'identité, discrimination salariale). La notification au PFPDT est obligatoire.
4. J1 — Notification au PFPDT (01.06.2023) : Formulaire soumis via edoeb.admin.ch avec : description de l'incident, catégories de données concernées (salaires, numéros AVS partiels de 147 personnes), mesures prises, coordonnées du responsable. Le PFPDT accuse réception et demande un rapport complémentaire sous 30 jours.
5. J1 — Signalement NCSC : Formulaire de signalement rempli sur ncsc.admin.ch — permet au NCSC de corréler avec d'autres signalements d'organisations suisses victimes du même prestataire.
6. J1-J3 — Notification aux personnes concernées : Les 18 entreprises clientes concernées sont notifiées par courrier recommandé et e-mail, avec description des données exposées et recommandations (surveillance des relevés bancaires, vigilance phishing).
7. J3-J30 — Revue contractuelle : Audit du contrat avec le prestataire de paie : absence de clause de notification d'incident avec délai contraignant. Mise en demeure pour intégration d'un SLA de notification sous 4 heures et d'un audit de sécurité annuel (ISO 27001 ou SOC 2). Si refus, changement de prestataire planifié sous 6 mois.
8. J30 — Rapport complémentaire PFPDT : Rapport détaillé incluant les mesures correctives : mise en place d'un inventaire des outils tiers avec données sensibles, processus de vérification des correctifs pour les outils exposés sur Internet, formation du personnel sur le phishing ciblé post-incident.

Coût estimé de l'incident

Heures internes DSI/RSSI externalisé : environ 40 heures × CHF 180/h = CHF 7 200. Communication juridique et révision contractuelle : CHF 3 500. Notification aux clients et gestion de la relation : CHF 1 800 (temps associés). Total direct : environ CHF 12 500. Sans notification au PFPDT dans les délais, les sanctions administratives peuvent atteindre CHF 250 000 pour les personnes physiques responsables (art. 60 nLPD).

Récapitulatif opérationnel

• Inventaire immédiat : Lister tous les logiciels tiers utilisés pour le transfert de fichiers, la paie, le monitoring et la gestion IT — identifier ceux exposés sur Internet.
• SBOM minimal : Pour chaque outil critique, maintenir la liste des versions déployées et vérifier les flux d'alertes CVE (NVD, CERT.ch).
• Processus de patch critique : Définir par écrit le SLA interne de déploiement : CVSS ≥ 9.0 sous 24 h, CVSS 7–8.9 sous 72 h, reste sous 14 jours.
• Contrats fournisseurs : Exiger une clause de notification d'incident sous 4 heures et un droit d'audit annuel pour tout prestataire traitant des données personnelles de vos clients.
• Segmentation et moindre privilège : Aucun outil tiers ne doit disposer de droits d'administrateur de domaine ni d'accès non chiffré aux données clients.
• Journalisation : Logs des accès fournisseurs conservés au minimum 180 jours, centralisés et non modifiables par les comptes opérationnels.
• Plan de notification nLPD : Avoir un template de notification PFPDT prêt, avec les coordonnées du responsable désigné et la procédure d'escalade (DSI → direction → juriste → PFPDT sous 72 h).
• Vérification d'intégrité : Pour les logiciels open source critiques, vérifier le hash SHA-256 avant toute installation en production.
• Test de réponse : Simuler une fois par an un scénario « alerte CVE critique sur outil en production » — mesurer le temps de détection, qualification et déploiement du correctif.

Les équipes qui accompagnent des PME suisses dans la gestion de leurs endpoints, comme SynGuard, intègrent ces contrôles dans la configuration MDM de base — mais la gouvernance contractuelle et juridique reste du ressort de chaque organisation.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nouvelle LPD en vigueur depuis le 01.09.2023, incluant les obligations de notification (art. 24) et de sous-traitance (art. 9).
• Signalement d'incidents — NCSC (ncsc.admin.ch) — Page de procédure officielle pour le signalement volontaire de cyberincidents par les entreprises suisses.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de contrôle suisse pour la protection des données, destinataire des notifications en cas de violation nLPD.
• CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée pour systèmes d'exploitation et applications, incluant les recommandations de gestion des mises à jour.
• NIST Cybersecurity Framework — nist.gov — Cadre de référence pour la gestion du risque cyber, incluant les fonctions Identify, Protect, Detect, Respond et Recover applicables aux risques supply chain.