Émirats · Abu Dhabi · Santé

Tests d'intrusion ADHICS pour la santé à Abu Dhabi

La santé est le secteur où une évaluation de sécurité doit être conçue autour de la contrainte qu'on ne peut pas faire tomber le système. ADHICS fixe les attentes de contrôle pour les établissements d'Abu Dhabi et leurs fournisseurs ; tester contre ce référentiel relève autant de la manière de tester que de ce que l'on trouve.

Ce que couvre ADHICS

La norme Abu Dhabi Healthcare Information and Cyber Security fixe les attentes de contrôle pour les entités de santé opérant sous le Department of Health de l'émirat, et pour les fournisseurs technologiques qui les servent. Elle couvre la gouvernance, le contrôle d'accès, la gestion des actifs, la réponse aux incidents et la protection des données cliniques et patients, avec des exigences d'évaluation de sécurité et de preuves qui la traversent de part en part.

Le périmètre va bien au-delà des hôpitaux. Éditeurs de dossiers médicaux électroniques, plateformes de télésanté, systèmes de laboratoire et d'imagerie, gestionnaires de sinistres et assureurs, et les intégrateurs qui les câblent ensemble finissent tous dans le périmètre — généralement via l'exigence contractuelle d'un établissement plutôt que par une relation directe avec le régulateur. Si votre logiciel touche des données patients d'Abu Dhabi, l'obligation vous trouve par les achats.

Tester en santé sans perturber les soins

Toute autre page de conformité peut traiter le cadrage comme une question commerciale. Ici c'est une question de sécurité clinique, et elle se règle avant tout le reste.

L'hypothèse de travail est que rien dans un environnement clinique n'est sûr à casser :

  • Pas de test de déni de service, et pas d'exploitation automatisée contre les systèmes cliniques. Jamais.
  • Pas de scan agressif des dispositifs médicaux, de la surveillance des patients, ni de rien qui y soit connecté — les dispositifs connectés défaillent sous scan de façon imprévisible, d'une manière que l'équipement informatique général ne connaît pas.
  • Fenêtres de test convenues autour de la charge clinique, avec un contact clinique désigné joignable en permanence et une voie d'arrêt immédiate ne nécessitant pas de convoquer une réunion.
  • Répliques de préproduction lorsque tester en production est inapproprié, l'écart entre préproduction et production étant documenté honnêtement plutôt que masqué.

Tout cela entre dans des règles d'engagement écrites et signées avant le début des tests. Lorsqu'un système ne peut véritablement être testé en sécurité sous aucune forme, la bonne réponse est une revue de configuration et d'architecture assortie d'une justification documentée — et non un test agressif mené prudemment en espérant que tout se passe bien.

Où se situe le vrai risque

Les environnements cliniques partagent un ensemble de caractéristiques qui déterminent ce que cherche un test utile :

  • Réseaux plats. Les parcs cliniques croissent par ajout, et la segmentation entre réseaux administratifs, cliniques et de dispositifs est fréquemment plus mince que ne le suggère le schéma d'architecture. Établir ce qui est réellement atteignable depuis un poste de travail ordinaire est généralement le constat de plus grande valeur dans une mission santé.
  • Dispositifs non corrigeables. Équipements médicaux connectés tournant sur des systèmes d'exploitation non supportés impossibles à mettre à jour sans revalidation. Cela ne sera pas corrigé, donc le constat qui compte n'est pas le correctif manquant : c'est de savoir si le dispositif est isolé de tout ce qui pourrait l'atteindre.
  • Intégrations. La santé fonctionne sur des interfaces entre systèmes — flux HL7 et FHIR, connexions laboratoire et imagerie, liens assurance et sinistres. L'authentification et l'autorisation sur ces interfaces sont habituellement plus faibles que sur les applications utilisateur, parce qu'elles ont été construites entre parties de confiance sur un réseau de confiance, et cette hypothèse a cessé d'être vraie il y a un moment.
  • Dispersion des identités. Identifiants cliniques partagés, comptes de longue durée de personnels partis, comptes d'accès distant fournisseurs à privilège permanent. En termes d'Active Directory c'est un terrain fertile, et c'est ainsi qu'un seul poste compromis devient un problème à l'échelle du parc.
  • Accès distant des fournisseurs. Des prestataires disposant d'un accès permanent aux systèmes cliniques à des fins de support. La compromission de l'un d'eux est votre compromission, ce qui explique précisément pourquoi les établissements répercutent désormais les exigences de test sur leur chaîne d'approvisionnement.

Périmètre de la mission

Typiquement : tests de réseau externe sur le parc exposé sur internet, y compris portails patients et infrastructure d'accès distant ; tests d'applications web et d'API contre les portails, systèmes de rendez-vous, plateformes de télésanté et les interfaces d'intégration derrière ; tests de réseau interne centrés sur la segmentation et l'accessibilité plutôt que sur l'exploitation ; revue Active Directory couvrant privilèges, comptes obsolètes et accès fournisseurs ; et évaluation cloud lorsque des données cliniques ou patients résident dans un tenant cloud.

Pour les fournisseurs plutôt que les établissements, le périmètre se resserre généralement sur la plateforme elle-même plus sa surface d'intégration — ce sur quoi l'équipe achats de l'établissement interroge réellement.

Empilement avec NESA et la PDPL

ADHICS s'applique rarement seul. La santé est désignée infrastructure d'information critique, de sorte que les Information Assurance Standards de NESA s'appliquent couramment à côté — y compris l'attente de retest à 90 jours pour les constats critiques et élevés et la revue des certifications du testeur. La PDPL fédérale ajoute des obligations de protection des données partout où des données personnelles sont traitées, ce qui en contexte de santé est partout.

Cadrée sur les trois dès le départ, une mission produit un corpus de tests et trois jeux de preuves rattachées. Cadrée sur un seul puis rattrapée ensuite, cela signifie généralement retester — alors dites-moi dès la première conversation tous les régimes auxquels vous êtes soumis.

Le livrable

Une synthèse écrite pour un public de gouvernance clinique autant que technique, un corps technique avec étapes de reproduction et notations CVSS, et le rattachement aux contrôles ADHICS concernés par chaque constat — plus NESA et PDPL le cas échéant. Les constats sont priorisés par impact clinique plutôt que par CVSS seul, car un problème de gravité moyenne sur un système touchant aux soins prime sur un problème de gravité élevée sur un site vitrine, et un rapport qui ne fait pas cette distinction n'est pas utile à un hôpital.

Puis un accompagnement à la remédiation, un retest, et une lettre d'attestation — qui pour les fournisseurs est fréquemment le document qui débloque les achats. Un rapport d'exemple montre le format.

Aspects pratiques

À distance depuis Amman, une heure derrière Abu Dhabi, même semaine de travail, en arabe ou en anglais. Les tests internes passent par un VPN ou un rebond dans votre environnement, dans les fenêtres convenues. Les certifications — réclamées tant par les évaluateurs NESA que par les achats hospitaliers — sont OSCP+, eCPPT, eWPT, eCIR, AZ-500, SC-200 et SC-300, toutes vérifiables via le credential wallet OffSec.

Prochaines étapes

Dites-moi si vous êtes établissement ou fournisseur, ce que comprend l'environnement, et si une partie est cliniquement en production. La première conversation porte sur ce qui peut être testé en sécurité et ce qui nécessite une autre approche — cela se règle avant tout devis, car cela détermine le périmètre. Prenez contact — l'arabe est bienvenu.

Sur le même thème : les tests d'intrusion aux Émirats, les exigences NESA, et la vue d'ensemble conformité.

Questions sur ADHICS

Aux établissements de santé opérant à Abu Dhabi sous le Department of Health, et aux fournisseurs technologiques qui les servent — ce qui englobe un large éventail d'entreprises qui ne sont pas elles-mêmes cliniques : éditeurs de dossiers médicaux électroniques, plateformes de télésanté, systèmes de laboratoire et d'imagerie, assureurs et gestionnaires de sinistres, et les intégrateurs qui les relient. Si vous traitez des données patients d'Abu Dhabi ou vous connectez à l'environnement d'un établissement, vous êtes généralement dans le périmètre via l'obligation de votre client, même sans relation directe avec le régulateur.

Oui, et c'est la première chose à convenir. L'approche consiste à supposer que rien n'est sûr à casser : pas de test de déni de service, pas d'exploitation automatisée contre les systèmes cliniques, pas de scan agressif des dispositifs médicaux ni de rien de connecté à la surveillance des patients, et des fenêtres de test convenues autour de la charge clinique. Lorsqu'un système est trop sensible pour être testé en production, les alternatives sont une réplique de préproduction, une revue de configuration et d'architecture, ou des tests manuels soigneusement bornés avec un contact clinique désigné et une voie d'arrêt immédiate. Les règles d'engagement sont écrites et signées avant tout démarrage.

Ils doivent être identifiés et traités comme fragiles par défaut. Les dispositifs médicaux connectés tournent fréquemment sur des systèmes d'exploitation non supportés impossibles à corriger, défaillent de façon imprévisible sous scan, et se trouvent sur des réseaux plus plats que tout le monde ne l'imagine. Le travail utile y relève généralement de l'accessibilité plutôt que de l'exploitation : établir quels dispositifs sont atteignables depuis où, s'ils sont segmentés du réseau général, et ce qu'un attaquant parvenu sur ce segment pourrait faire. Cela répond à la vraie question de risque sans jamais toucher un dispositif relié à un patient.

Ils s'empilent. ADHICS est la norme sectorielle pour la santé à Abu Dhabi ; la santé est désignée infrastructure d'information critique, de sorte que les Information Assurance Standards de NESA s'appliquent couramment à côté ; et la PDPL fédérale apporte des obligations de protection des données partout où des données personnelles sont traitées, ce qui en santé signifie partout. Une mission unique cadrée sur les trois dès le départ produit un seul corpus de tests et trois jeux de preuves rattachées.

De plus en plus oui, et la demande arrive généralement par les achats plutôt que par le régulateur. Les établissements sous ADHICS sont responsables de la sécurité de leur chaîne d'approvisionnement, ils répercutent donc l'exigence vers l'extérieur — ce qui signifie qu'un rapport de test d'intrusion indépendant devient une condition pour remporter ou conserver le contrat. Pour un fournisseur, disposer d'un rapport et d'une attestation à jour raccourcit considérablement le processus d'achat, et ne pas en avoir a commencé à faire perdre des affaires.

Établissement de santé ou fournisseur à Abu Dhabi ?

Des tests cadrés autour de la sécurité clinique, avec les preuves qu'ADHICS et vos clients réclament.

Contact