Skip to main content

Livres de Jeu Sectoriels: ISO 27001 dans les Services Financiers et la Santé

« Le contexte n'est pas un luxe. C'est la différence entre un contrôle qui fonctionne et un contrôle qui existe simplement. »

  • Maxime du praticien SMSI

Introduction : Pourquoi le Contexte Sectoriel Change Tout​

ISO 27001 est conçu pour être agnostique vis-à-vis du secteur. Sa philosophie basée sur les risques évite délibérément de prescrire le même ensemble de contrôles pour un hôpital et un hedge fund, un fournisseur cloud et une société d'eau. La norme fait confiance aux organisations pour comprendre leur propre contexte, évaluer leurs propres risques et sélectionner les contrôles qui traitent ces risques de manière proportionnée.

Cette confiance est bien placée - mais elle place la charge de l'intelligence contextuelle sur le praticien. Un professionnel GRC qui a passé sa carrière dans les services financiers et qui implémente un SMSI pour la première fois dans une organisation de santé constatera que le profil de menaces est différent, l'environnement réglementaire est différent, les contraintes opérationnelles sont différentes, et les contrôles qui représentent les meilleures pratiques dans un secteur peuvent être inadéquats, impraticables ou disproportionnés dans un autre.

Ce chapitre final comble ce manque. Il fournit quatre livres de jeu spécifiques aux secteurs - Finance, Santé, Fournisseurs Cloud et Infrastructures Critiques - chacun structuré comme un guide complet pour le praticien : le profil de menaces unique du secteur, son cadre réglementaire, les contrôles ISO 27001 les plus importants dans son contexte, les pièges d'implémentation spécifiques au secteur, et une liste de contrôle d'implémentation complète.

Livre de Jeu 1 : Services Financiers​

1.1 Le Profil de Menaces du Secteur Financier​

Les institutions financières comptent parmi les organisations les plus ciblées au monde. La raison est directe : elles détiennent de l'argent, traitent de l'argent et détiennent les identifiants et informations de compte qui permettent de déplacer de l'argent. Les acteurs de la menace vont des criminels opportunistes exploitant des vulnérabilités génériques aux acteurs étatiques sophistiqués menant des campagnes d'espionnage et de sabotage à long terme.

Compromission de la messagerie professionnelle (BEC) : La catégorie d'attaque la plus financièrement dommageable pour les entreprises de services financiers. Les acteurs de la menace compromettent ou usurpent des comptes e-mail de dirigeants pour rediriger des virements bancaires, autoriser des paiements frauduleux ou manipuler des employés ayant une autorité financière.

Ransomware ciblant la continuité opérationnelle : Les institutions financières sont des cibles de ransomware à haute valeur parce que leur coût de perturbation opérationnelle est si élevé.

Vol de données d'identification et prise de contrôle de compte : Hameçonnage, credential stuffing et ingénierie sociale ciblant les systèmes d'authentification côté client et internes.

Attaques sur SWIFT et les systèmes de paiement : Le vol de 81 millions de dollars à la Bangladesh Bank en 2016 via de faux messages SWIFT a démontré que même l'infrastructure de messagerie sous-jacente à la finance mondiale est une cible viable.

Menace interne avec accès aux données financières : Les institutions financières détiennent des informations à haute valeur - stratégies de trading, renseignements sur les fusions-acquisitions, profils financiers des clients.

Attaques sur la chaîne d'approvisionnement fintech : L'expansion rapide des services bancaires ouverts, des services basés sur les API et des intégrations fintech a considérablement élargi la surface d'attaque de la chaîne d'approvisionnement.

Menaces Persistantes Avancées : Les acteurs étatiques mènent des opérations à long terme contre les institutions financières.

1.2 Le Cadre Réglementaire des Services Financiers​

DORA (UE) : Exigences complètes de gestion du risque TIC, de notification des incidents et de risque tiers applicables depuis janvier 2025. La réglementation sectorielle la plus exigeante pour les entités financières de l'UE. Couvert en détail au Chapitre 9.

PCI DSS : S'applique à toute organisation traitant, stockant ou transmettant des données de titulaires de carte. PCI DSS v4.0 impose 12 exigences de haut niveau avec des centaines de sous-exigences.

Directives de l'ABE sur la gestion des risques TIC et de sécurité : Attentes détaillées de mise en œuvre pour la gestion des risques TIC et de sécurité dans le cadre des réglementations financières de l'UE.

Exigences FCA/PRA (Royaume-Uni) : Déclarations de politique de résilience opérationnelle.

Règles de cybersécurité de la SEC (États-Unis) : Divulgation des incidents de cybersécurité importants dans les quatre jours ouvrables.

1.3 Contrôles ISO 27001 Prioritaires pour les Services Financiers​

5.7 (Renseignements sur les menaces) : L'adhésion au FS-ISAC, les briefings sectoriels de l'ENISA, les abonnements au renseignement des fournisseurs et la surveillance du dark web doivent tous être actifs.

5.19 à 5.23 (Contrôles fournisseurs) : Les fournisseurs de services TIC doivent être évalués selon les critères DORA - profil d'accès, chaîne de sous-traitance, historique des incidents et conformité contractuelle.

5.24 à 5.28 (Gestion des incidents) : La fenêtre de classification de 4 heures de DORA exige des pipelines de détection automatisés et des notifications pré-rédigées.

8.2 (Droits d'accès privilégiés) : Accès juste-à-temps, enregistrement de session, surveillance comportementale, revue trimestrielle de chaque accès privilégié sans exception.

8.5 (Authentification sécurisée) : L'AMF doit être universelle. AMF résistante au phishing (FIDO2, jetons matériels) pour les rôles à plus haut risque.

8.8 (Vulnérabilités techniques) : Le SLA de remédiation pour les systèmes accessibles depuis Internet devrait être mesuré en heures pour les vulnérabilités critiques.

8.15 et 8.16 (Journalisation et surveillance) : Les exigences de piste d'audit pour les institutions financières sont parmi les plus exigeantes de tout secteur.

1.4 Pièges d'Implémentation dans les Services Financiers​

Piège 1 : Programmes de conformité parallèles. PCI DSS et ISO 27001 se chevauchent substantiellement. L'approche de consolidation des preuves du Chapitre 9 doit être appliquée agressivement.

Piège 2 : Exclusion des systèmes de trading. La technologie de trading opérée par le front office est parmi les actifs les plus ciblés d'une institution financière.

Piège 3 : Sous-estimation des exigences opérationnelles de DORA. L'exigence de classification des incidents en 4 heures de DORA est opérationnellement exigeante.

Piège 4 : Shadow IT dans les fonctions de trading et de risque. Les analystes quantitatifs développent fréquemment leurs propres outils traitant des données financières hautement sensibles entièrement en dehors de tout processus de gouvernance informatique.

Liste de Contrôle : Services Financiers​

Gouvernance et Leadership​

  • Sponsor exécutif identifié avec responsabilité de gestion DORA/NIS2 explicitement documentée
  • Point à l'ordre du jour cybersécurité au niveau du conseil d'administration confirmé au moins trimestriellement
  • Ligne hiérarchique du RSSI appropriée - directement au PDG ou au comité au niveau du conseil
  • Le comité de sécurité de l'information inclut trading, risque, conformité, informatique et représentation juridique
  • Obligations de responsabilité personnelle en vertu de l'Article 20 de DORA communiquées aux membres de l'organe de direction
  • Budget de sécurité examiné et comparé aux pairs sectoriels et aux attentes réglementaires

Gestion des Risques​

  • La méthodologie de risque traite explicitement le risque TIC tel que défini par DORA
  • L'évaluation des risques couvre tous les systèmes en scope incluant trading, paiements et plateformes clients
  • Programme de renseignements sur les menaces établi - adhésion FS-ISAC, abonnements gouvernementaux, surveillance du dark web
  • Risque BEC spécifiquement évalué - contrôles de virement et traitement de l'usurpation des dirigeants documentés
  • Évaluation du risque tiers couvre tous les prestataires de services TIC selon les critères DORA
  • Risques SWIFT et systèmes de paiement spécifiquement évalués et traités
  • Risque de menace interne formellement évalué avec plan de traitement documenté

Contrôle des Accès​

  • AMF universelle appliquée - aucune exception pour tout système accédant aux données financières ou à l'infrastructure de paiement
  • AMF résistante au phishing (FIDO2/jetons matériels) pour les comptes privilégiés et les rôles à haute valeur
  • Revue des accès privilégiés trimestrielle - documentée avec preuves conservées
  • Accès privilégié juste-à-temps implémenté pour l'administration des systèmes de production
  • Enregistrement de session déployé pour toutes les sessions privilégiées sur les systèmes critiques
  • Revue d'accès utilisateur trimestrielle pour tous les systèmes de production
  • Inventaire des comptes de service maintenu - mots de passe alternés, accès limité au minimum requis

Gestion des Incidents​

  • Schéma de classification des incidents aligné sur les critères de gravité DORA
  • Capacité de classification des incidents majeurs en 4 heures démontrée en exercice
  • Modèles de notification DORA préparés et validés juridiquement
  • Coordonnées NCA/AES intégrées dans le guide de réponse aux incidents
  • Modèle de rapport intermédiaire DORA à 72 heures préparé
  • Processus de notification DPA RGPD intégré à la réponse aux incidents
  • Capacité de réponse aux incidents hors heures ouvrables confirmée
  • Exercices annuels couvrant les scénarios BEC, ransomware et fraude aux paiements

Risque Fournisseurs et Tiers​

  • Registre des arrangements TIC maintenu - tous les éléments de données requis par DORA présents
  • Désignations PPT TIC critiques surveillées - registre AES vérifié trimestriellement
  • Clauses contractuelles conformes à DORA dans tous les accords de prestataires de services TIC
  • Inventaire des intégrations fintech complet - toutes les intégrations API documentées et évaluées
  • Évaluation de sécurité annuelle pour tous les fournisseurs TIC de niveau 1
  • Processus de notification de changement de sous-traitant confirmé avec tous les fournisseurs critiques
  • Dispositions de sortie évaluées pour tous les fournisseurs TIC critiques

Contrôles Techniques​

  • SLA de gestion des vulnérabilités pour les systèmes accessibles depuis Internet : vulnérabilités critiques dans les 24 heures
  • Systèmes de trading et de paiement inclus dans le périmètre de scanning des vulnérabilités
  • Segmentation réseau séparant trading, paiements et environnements informatiques d'entreprise
  • DLP déployé sur e-mail, web et endpoint couvrant les classifications de données financières
  • SIEM déployé avec règles de détection de menaces du secteur financier - mis à jour trimestriellement
  • Conservation des journaux répondant aux exigences réglementaires - minimum 5 ans pour les journaux de transactions
  • Chiffrement au repos et en transit pour toutes les données confidentielles et au-dessus
  • Test de pénétration annuel par un cabinet externe qualifié - périmètre incluant l'infrastructure de paiement

Conformité Réglementaire​

  • Évaluation des écarts DORA complétée sur les cinq piliers
  • Calendrier TLPT confirmé si entité significative selon DORA
  • Périmètre PCI DSS défini et contrôles mappés à la base de preuves ISO 27001
  • Processus de divulgation cybersécurité SEC établi pour les entités cotées aux États-Unis
  • Exigences de résilience opérationnelle FCA/PRA traitées pour les entités au Royaume-Uni
  • Calendrier de conformité intégré alignant tous les calendriers de reporting et d'évaluation réglementaires

Livre de Jeu 2 : Santé​

2.1 Le Profil de Menaces du Secteur de la Santé​

La santé est le secteur le plus ciblé par les ransomwares. En 2023 et 2024, les organisations de santé ont collectivement subi plus d'incidents de ransomware que tout autre secteur. Les raisons sont structurelles : données hautement sensibles, systèmes où les pannes de disponibilité ont des conséquences directes sur la sécurité des patients, posture de sécurité historiquement sous-investie et environnements technologiques d'une complexité extraordinaire.

Ransomware ciblant les systèmes opérationnels : L'attaque de ransomware de 2020 à l'Université Hospitalière de Düsseldorf - où un incident de ransomware a forcé la déviation des ambulances d'urgence, contribuant à la mort d'un patient - a illustré la dimension de sécurité des patients de la santé de la manière la plus frappante possible. Pour les professionnels SMSI de la santé, le risque de disponibilité est un risque pour les patients.

Exploitation des dispositifs médicaux : Les environnements de santé modernes contiennent des milliers de dispositifs médicaux en réseau - pompes à perfusion, moniteurs patients, équipements d'imagerie, ventilateurs - beaucoup fonctionnant avec des logiciels obsolètes qui ne peuvent pas être patchés.

Vol d'informations de santé protégées (PHI) : Les dossiers médicaux se vendent de 10 à 40 fois le prix des numéros de cartes de crédit sur les marchés sombres.

Vulnérabilités des logiciels cliniques tiers : Les organisations de santé dépendent fortement des éditeurs de logiciels cliniques dont les produits contiennent des vulnérabilités et dont les cycles de mise à jour sont lents.

Menace interne avec accès aux données cliniques : Les travailleurs de santé ont un large accès aux dossiers patients par nécessité clinique.

2.2 Le Cadre Réglementaire de la Santé​

RGPD - données de santé comme catégorie spéciale : Les données de santé sont explicitement classifiées comme données de catégorie spéciale en vertu de l'Article 9.

HIPAA (États-Unis) : La Règle de Sécurité (mesures de protection techniques, physiques et administratives pour les ePHI), la Règle de Confidentialité et la Règle de Notification des Violations.

NHS Data Security and Protection Toolkit (Royaume-Uni) : Cadre d'auto-évaluation obligatoire pour les organisations NHS et leurs fournisseurs.

NIS2 - secteur de la santé comme entité essentielle : Les prestataires de santé au-dessus des seuils définis sont classifiés comme entités essentielles en vertu de NIS2.

2.3 Contrôles ISO 27001 Prioritaires pour la Santé​

5.30 (Préparation des TIC pour la continuité des activités) : La continuité des activités est un impératif de sécurité des patients. Le SMSI doit inclure des plans spécifiques et testés pour maintenir les opérations cliniques lorsque les systèmes clés ne sont pas disponibles.

8.8 (Vulnérabilités techniques - adapté aux dispositifs médicaux) : La gestion des vulnérabilités des dispositifs médicaux est unique. Un processus spécifique est requis - distinct de la gestion des vulnérabilités informatiques standard.

8.22 (Ségrégation des réseaux) : Les réseaux cliniques, les réseaux de dispositifs médicaux, l'informatique administrative et les réseaux de recherche doivent être segmentés pour prévenir les mouvements latéraux.

6.3 (Sensibilisation - contexte clinique) : Le personnel clinique a des besoins de sensibilisation à la sécurité différents du personnel informatique ou administratif. La formation doit être conçue pour les flux de travail cliniques.

5.9 (Inventaire des actifs - dispositifs médicaux) : L'inventaire des dispositifs médicaux est généralement l'inventaire des actifs le plus incomplet dans une organisation de santé.

2.4 Pièges d'Implémentation dans la Santé​

Piège 1 : Exclusion des dispositifs médicaux. Les dispositifs médicaux connectés aux réseaux cliniques sont des actifs informationnels dans le périmètre SMSI.

Piège 2 : Sous-investissement dans la disponibilité. Un SMSI qui ne peut pas décrire comment les opérations cliniques se poursuivent lorsque le DPI est indisponible présente une lacune critique.

Piège 3 : Procédures de panne inadéquates. Les procédures de panne sont un contrôle de sécurité, pas seulement une contingence opérationnelle.

Piège 4 : Ignorer le shadow IT des chercheurs. Les environnements de recherche dans les systèmes de santé académiques sont fréquemment caractérisés par des systèmes non sanctionnés, des appareils personnels et des pratiques de partage de données qui violeraient clairement le SMSI.

Liste de Contrôle : Santé​

Gouvernance et Leadership​

  • Direction clinique engagée dans la gouvernance SMSI - DMIOC, DSI ou équivalent au comité de sécurité de l'information
  • Sécurité des patients et sécurité de l'information explicitement liées
  • Obligations réglementaires mappées : données de santé RGPD, HIPAA le cas échéant, NIS2, NHS DSPT le cas échéant
  • Propriété de la sécurité des dispositifs médicaux définie - modèle de collaboration informatique et ingénierie clinique documenté
  • Budget de sécurité comparé aux normes sectorielles de la santé - généralement 6 à 8% du budget informatique
  • Sponsor exécutif informé du ransomware comme risque pour la sécurité des patients

Gestion des Risques​

  • L'évaluation des risques inclut les dispositifs médicaux - découverte réseau combinée avec inventaire d'ingénierie clinique
  • Flux de PHI et données de santé mappés - tous les systèmes stockant, traitant ou transmettant des données patients identifiés
  • Évaluation des risques spécifique au ransomware - l'analyse d'impact sur les activités traite la continuité des soins
  • Vulnérabilité des dispositifs médicaux évaluée - avis de sécurité des fabricants suivis
  • Risque de menace interne spécifiquement évalué pour les scénarios d'accès aux données patients
  • Risque des éditeurs de logiciels cliniques tiers évalué - DPI, laboratoire, radiologie, systèmes de pharmacie
  • Risque des données de recherche évalué - processus d'anonymisation, accords de partage de données

Gestion des Actifs​

  • Inventaire des dispositifs médicaux complet - type, fabricant, version firmware, connexion réseau, propriétaire clinique
  • Connexions réseau des dispositifs médicaux documentées - attribution VLAN, flux de données, finalité clinique
  • Inventaire des données PHI complet - tous les systèmes, emplacements et chemins d'accès documentés
  • Évaluation du shadow IT réalisée dans les environnements de recherche et administratifs

Contrôle des Accès​

  • Contrôle d'accès basé sur les rôles implémenté pour le DPI - accès minimum basé sur le rôle clinique
  • Procédure d'accès d'urgence (bris de glace) documentée, journalisée et révisée
  • Revues d'accès trimestrielles pour les comptes privilégiés, semestrielles pour le personnel clinique
  • Révocation d'accès du personnel licencié confirmée - incluant accès des contractants et intérimaires
  • Accès à distance du personnel clinique sécurisé - VPN ou zero-trust avec AMF requis
  • Identifiants par défaut des dispositifs médicaux modifiés

Sécurité des Dispositifs Médicaux​

  • Processus de gestion des vulnérabilités des dispositifs médicaux documenté - séparé du processus VM informatique standard
  • Processus de patch des dispositifs médicaux inclut une étape de validation clinique avant déploiement
  • Segmentation réseau des dispositifs médicaux implémentée
  • Surveillance comportementale des dispositifs médicaux implémentée là où techniquement faisable
  • Risque des dispositifs en fin de support formellement accepté avec contrôles compensatoires documentés
  • Avis de sécurité des fabricants surveillés - abonnements H-ISAC et ISAC des dispositifs médicaux
  • Processus d'acquisition de nouveaux dispositifs médicaux inclut une étape d'évaluation de sécurité obligatoire

Gestion des Incidents​

  • Procédures de panne clinique documentées pour chaque système clinique critique
  • Procédures de panne testées annuellement
  • Évaluation de l'impact sur la sécurité des patients incluse dans la classification de gravité des incidents
  • Procédure de notification de violation de données de catégorie spéciale RGPD - calendrier accéléré pour les données de santé
  • Procédure de notification d'incident NIS2 implémentée si classification entité essentielle applicable
  • Direction clinique incluse dans le chemin d'escalade des incidents
  • Guide de jeu ransomware incluant critères de décision pour l'escalade du paiement de rançon au conseil

Contrôles Techniques​

  • Segmentation du réseau clinique implémentée et testée
  • Stratégie de sauvegarde testée spécifiquement pour la récupération après ransomware - sauvegardes isolées, restauration chronométrée vérifiée
  • Récupération des sauvegardes DPI et systèmes cliniques testée - RTO/RPO confirmés par rapport aux exigences cliniques
  • Protection des endpoints déployée sur toutes les stations de travail cliniques gérables
  • Contrôles USB et supports amovibles - exceptions de nécessité clinique formellement documentées
  • Chiffrement PHI au repos pour tous les magasins de données - appareils portables chiffrés
  • Journalisation d'audit pour l'accès au DPI - accès aux dossiers patients journalisé avec surveillance des anomalies activée

Formation et Sensibilisation​

  • Formation de sensibilisation à la sécurité du personnel clinique - contenu conçu pour le contexte clinique
  • Simulation de phishing incluant des scénarios d'e-mail clinique
  • Formation sur les procédures de panne incluse dans l'intégration du personnel clinique et le recyclage annuel
  • Mécanisme de signalement des incidents communiqué au personnel clinique
  • Formation sur la sécurité des dispositifs médicaux pour l'ingénierie clinique et le personnel des achats

Suite au Chapitre 10B : Livres de jeu Fournisseurs Cloud et Infrastructures Critiques

© ISO 27001 Wiki - Pour les RSSI, Analystes de Sécurité et Professionnels GRC