Rançongiciel ChipSoft: sauvegardes immuables et isolées indispensables

Début avril 2026, l’éditeur hospitalier ChipSoft (HiX) a subi une attaque par rançongiciel: des hôpitaux ont déconnecté des services, des portails ont été coupés et des données patients ont été volées. Voici comment éviter de basculer à l’arrêt, et répondre aux exigences DORA/NIS 2.

Les faits

Le 7 avril 2026, ChipSoft, fournisseur du dossier patient électronique HiX utilisé par une large part des hôpitaux néerlandais et frontaliers, a été frappé par un rançongiciel. L’organisme sectoriel Z‑CERT a confirmé l’incident et conseillé aux établissements de santé de couper les liaisons VPN et de surveiller les flux, plusieurs composants (Zorgportaal, HiX Mobile, etc.) ayant été mis hors ligne par précaution. Des vols de données patients ont été reconnus pour les clients hébergés dans le cloud de l’éditeur, et le rétablissement des hôpitaux s’est étalé sur plusieurs semaines. Sources : Z‑CERT (09/04/2026), The Register (08/04/2026), NL Times (08/04/2026) et DutchNews.nl (29/04/2026).

Au‑delà de l’éditeur, l’impact a été systémique: coupures préventives chez des hôpitaux, opérations ralenties, puis une phase de reprise de plusieurs semaines avant retour à la normale (Computable.nl, 18/05/2026). C’est un cas d’école de risque « supply‑chain » où la continuité clinique dépend de la résilience technique d’un tiers.

Le cadre légal qui s’applique

Même si l’incident touche la santé, les obligations de résilience concernent l’ensemble des secteurs critiques en Europe et, pour la finance, sont explicitement détaillées par DORA. Pour les entités financières, les exigences DORA (art. 12) imposent des sauvegardes fiables, testées et séparées. La directive NIS 2 (art. 21(2)(c)) impose quant à elle la continuité d’activité incluant la gestion des sauvegardes et de la reprise après incident aux entités essentielles et importantes.

• DORA – Article 12: politiques et procédures de sauvegarde, restauration et reprise. Le règlement (UE) 2022/2554 impose aux entités financières de disposer de sauvegardes fiables, testées, séparées logiquement/physiquement, et de procédures de restauration chiffrées et documentées, intégrées aux plans de continuité et de crise. Texte officiel : EUR‑Lex — DORA.
• NIS 2 – Article 21 (2)(c): continuité d’activité incluant la gestion des sauvegardes et de la reprise après incident, pour les entités « essentielles » et « importantes ». Texte officiel : EUR‑Lex — NIS 2. La Commission rappelle cette exigence de gestion des risques et de continuité : Commission européenne — NIS 2.

En clair, les régulateurs attendent des organisations qu’elles puissent :

• restaurer rapidement des services critiques à partir de sauvegardes intègres et non chiffrées par l’attaquant ;
• démontrer l’isolation des sauvegardes vis‑à‑vis du réseau de production ;
• prouver (tests, journaux, procédures) que ces mécanismes fonctionnent en situation réelle.

La solution technique à déployer

Objectif: rendre la prise d’otage inefficace. Deux piliers se complètent.

1) Sauvegardes immuables (« WORM »)

• Principe: écrire les données sur une cible qui empêche toute altération/suppression pendant une durée de rétention (verrouillage matériel/objet, snapshots immuables).
• Mise en œuvre: stockage objet S3 compatible avec « object lock », snapshots immuables sur appliances de sauvegarde, coffres numériques (« vaults »), et conservation hors ligne (« air‑gapped » logique).
• Contrôles clés: rétention non contournable, clés KMS/HSM dédiées, séparation des rôles, MFA/approbations pour toute modification de politique, chiffrement au repos (AES‑256) et en transit (TLS 1.2+).
• Référentiels: ISO/IEC 27001 Annexe A.8.13, NIST SP 800‑209, CIS Controls v8 — Control 11.

2) Isolation réseau et segmentation de la chaîne de sauvegarde

• Principe: empêcher la propagation latérale (du SI compromis vers l’infrastructure de sauvegarde) et circonscrire l’exfiltration.
• Mise en œuvre:
  • réseau dédié pour les serveurs de sauvegarde (VLAN/VRF séparés) ;
  • accès via passerelles d’administration bastionnées (PAM) et authentification forte ;
  • interdiction des connexions entrantes non sollicitées depuis la production ;
  • comptes de service dédiés, rotation automatique des secrets ;
  • filtrage L3/L7, inspection TLS, et micro‑segmentation sur charges critiques (plateformes de sauvegarde, référentiels d’images, dépôts IaC).
• Contrôles: tests de restauration réguliers (mensuels/trimestriels), « tabletop » et exercices techniques, RTO/RPO mesurés et consignés.

Coups de ciseaux sur l’attaque : même si l’éditeur ou un tiers est compromis (cas ChipSoft), une politique 3‑2‑1‑1‑0 modernisée (3 copies, 2 médias, 1 hors site, 1 immuable/isolée, 0 erreurs vérifiées par restauration testée) empêche la paralysie prolongée et le chantage sur les données.

Comment Luxgap déploie cela

• Notre gouvernance ISO 27001 (Lead Implementer/Auditor certifiés) pour traduire DORA/NIS 2 en politiques concrètes: cartographie des systèmes critiques, définition RTO/RPO, choix des cibles de sauvegarde, matrices de séparation des rôles, procédures de restauration et preuves d’audit.
• Notre SOC managé 24/7 pour surveiller la chaîne de sauvegarde: détection d’événements anormaux (purges inhabituelles, réplications massives, accès admin hors plage), corrélation SIEM, alertes et réponse outillée (isolation réseau, bascule sur copies immuables).
• Nos consultants CISO/DPO externalisés pour aligner technique et conformité: registres de tests de restauration, preuves de contrôles d’accès, intégration au PCA/BCP, communication réglementaire (incidents majeurs).

Concrètement, nous opérons par sprints:

1. cadrage et évaluation de maturité (cartographie sauvegardes, tests de restauration, dépendances éditeur/tierce maintenance) ;
2. architecture cible (immuable + réseau isolé + chiffrement + PAM) ;
3. déploiement outillé (politiques WORM, vaults, durcissement, micro‑segmentation) ;
4. exercice de restauration « à froid » et « à chaud », puis production des preuves DORA/NIS 2.

Cas concret au Luxembourg ou en UE

Une entreprise régulée (finance) opérant au Luxembourg, avec systèmes critiques hébergés chez un éditeur européen, a basculé vers des sauvegardes immuables objet‑lock et une réplication vers un « vault » réseau isolé, administré via PAM et clés HSM. En 6 semaines:

• RTO réduit de 48h à 8h sur l’applicatif critique, RPO passé de 24h à 4h validé par tests mensuels ;
• preuve documentaire DORA art. 12 et NIS 2 art. 21(2)(c) intégrée au PCA ;
• scénario « éditeur compromis » testé: déconnexion préventive, restauration validée sur copie immuable, continuité assurée sans payer ni négocier.

Premiers pas concrets

1. Vérifier votre « chaîne de vie » des sauvegardes cette semaine: dernière restauration testée, durée réelle (RTO), point de reprise (RPO), et preuves à jour.
2. Isoler vos sauvegardes: segment dédié + bastion + comptes de service à droits minimaux, et bloquer toute administration directe depuis le réseau de production.
3. Activer l’immuabilité: verrouillage WORM sur votre cible principale (snapshots immuables / object‑lock), rétention codifiée et contrôlée par HSM/KMS dédiés.
4. Simuler un sinistre « fournisseur/SaaS compromis » sur une appli critique: débranchez la connectivité sortante et restaurez depuis la copie immuable. Mesurez RTO/RPO constatés et écarts.
5. Documenter pour DORA/NIS 2: politiques, schémas réseau, journaux de tests de restauration, registres d’autorisations, plan de communication (interne, clients, autorités). Intégrez ces éléments à votre plan de continuité.

Sources officielles

• Incident et impacts :
  • Z‑CERT — Ransomware chez ChipSoft (09/04/2026)
  • The Register — Ransomware knocks Dutch healthcare software vendor offline (08/04/2026)
  • NL Times — Ransomware attack on company that manages hospitals’ patient files (08/04/2026)
  • DutchNews.nl — Stolen patient data has been destroyed (29/04/2026)
  • Computable.nl — Rétablissement presque achevé (18/05/2026)
• Cadre réglementaire :
  • EUR‑Lex — Règlement (UE) 2022/2554 (DORA), art. 12 « Backup policies and procedures… »
  • EUR‑Lex — Directive (UE) 2022/2555 (NIS 2), art. 21(2)(c) continuité/gestion des sauvegardes
  • Commission européenne — NIS 2

En résumé: l’attaque ChipSoft rappelle que la question n’est plus « si », mais « quand ». Des sauvegardes immuables et un réseau de sauvegarde isolé sont aujourd’hui le socle technique pour se relever vite — et pour prouver aux régulateurs que votre continuité d’activité n’est pas négociable.

Contactez‑nous pour évaluer et renforcer votre dispositif.