Forescout | Architecture Zero Trust pour les soins de santé

La richesse des données personnelles et financières sensibles gérées par les hôpitaux et les systèmes de santé, associée aux vulnérabilités connues en matière de cybersécurité, fait du secteur de la santé une cible attrayante pour les cyberattaques. Au cours des trois dernières années, 93 % des organismes de santé ont subi une violation de données, et 57 % en ont subi plus de cinq.

La transformation numérique a entraîné une croissance explosive de l'informatique interconnectée, de l'IoT, de l'OT et, pour les organismes de santé, de l'IoMT et des dispositifs médicaux conçus pour améliorer les soins et les résultats des patients. Ces innovations s'accompagnent d'une surface d'attaque toujours plus grande.

L'IoMT et les dispositifs médicaux en particulier partagent des informations et communiquent avec divers Endpoints, ce qui en fait de puissants vecteurs de dommages. Ils sont également exposés aux vulnérabilités de la chaîne d'approvisionnement, comme celles révélées dans notre récente divulgation Access:7, qui pourraient permettre aux hackers d'exécuter à distance un code malveillant sur des appareils d'imagerie et de laboratoire, par exemple. 

Les cyberattaques sur les dispositifs médicaux peuvent conduire à des erreurs de diagnostic ou à des mauvais traitements, entraînant dans le pire des cas des blessures graves ou des pertes de vie, et dans le meilleur des cas, une perte importante d'activité et une atteinte à la réputation.

Il n'est pas étonnant que l'architecture Zero Trust ( ZTA ) gagne du terrain dans le secteur des soins de santé. Dans cet article, basé sur la récente intervention de Tamer Baker ( Vice President, Global Healthcare ) au Healthcare Cyber Security Summit, il partagera avec vous quelques conseils, bonnes pratiques et pièges à éviter dans votre cheminement vers le Zero Trust. Il s'appuie sur plus de 100 conversations qu'il a eues avec des responsables de la cybersécurité dans le secteur des soins de santé et d'autres secteurs.

Les normes NIST SP 800-207 pour l'architecture Zero Trust

Le concept de base du Zero Trust consiste à "ne jamais faire confiance, toujours vérifier". Cette architecture a été introduite il y a plus de 10 ans, il existe donc de nombreux guides, mais aujourd'hui, la principale source de vérité dans les secteurs public et privé est le NIST SP 800-207. Il décrit les 7 étapes de l'introduction de la ZTA dans un réseau à architecture périmétrique :

1. Identifier les acteurs de l'entreprise
2. Identifier les actifs appartenant à l'entreprise
3. Identifier les processus clés et évaluer le risque associer à leur exécution
4. Formuler des politiques pour le point d'application des politiques ( PEP ) candidat à la ZTA
5. Identifier les solutions PEP candidates
6. Commencer le suivi du déploiement
7. Étendre la ZTA

La ZTA est une approche de conception de la sécurité, et non une solution ou une technologie unique qui peut être achetée auprès d'un seul fournisseur.
L'un des principaux avantages de la norme NIST SP 800-207 est qu'elle définit une approche multifournisseurs et agnostique ( et d'autres aides sont en préparation ). La mise en œuvre d'une architecture Zero Trust est un projet à venir du NIST National Cybersecurity Center of Excellence ( NCCoE )  qui fait appel à plusieurs fournisseurs pour démontrer des approches pratiques du Zero Trust en utilisant les principes du SP 800-207. Forescout est l'un des quelques fournisseurs sélectionnés par le NCCoE pour collaborer à ce projet.

Passons maintenant aux différents pièges à éviter ! 

Piège n°1 : Sous-estimer la réalité de votre terrain numérique

Le Zero Trust commence par un utilisateur et un appareil qui doivent être vérifiés avant de pouvoir accéder à des données sensibles. C'est déjà là que le premier piège majeur se présente dans de nombreuses organisations : leur cas d'utilisation de la ZTA suppose qu'il y a un humain et un appareil géré. Dans un réseau hospitalier, la plupart des appareils communiquant sur le réseau, le data center et le cloud sont des entités non humaines. Les postes de travail gérés, utilisés par des humains, représentent généralement 30 à 50 % d'un réseau.

En plus de l'informatique administrative et clinique, pensez à tous les appareils connectés dans un écosystème hospitalier typique à travers les postes d'infirmières, les chambres des patients, les centres de chirurgie, les laboratoires et les pharmacies, dont la plupart gèrent des informations de santé personnelles sensibles ( PHI ) :

• IoMT connectant les principaux équipements chirurgicaux et d'imagerie, les pompes à perfusion et les distributeurs de pharmacie.
• IoT / OT qui gèrent les systèmes d'automatisation des bâtiments ( BAS ), notamment les caméras de sécurité, les lecteurs de badges et les systèmes de chauffage, de ventilation et de climatisation, ainsi que les imprimantes Zebra et les lecteurs RFID.
• Accès sans fil nécessaire pour héberger les appareils des invités, des patients, des visiteurs et des entrepreneurs.
• Fournisseurs non gérables nécessitant un accès aux dispositifs médicaux pour le support et la maintenance.

Cet aperçu ne représente que la connectivité sur le site. Il n'inclut pas les exigences relatives à la télésanté et aux travailleurs à distance. Vous pouvez d'ores et déjà comprendre que si vous ne tenez pas compte de l'ensemble de votre environnement numérique dès le départ, vous devrez certainement revoir votre ZTA et éventuellement la modifier pour en tenir compte plus tard. 

Piège n°2 : Commencer par le PEP

Dans le cadre du Zero Trust, chaque appareil doit passer par le même processus de vérification chaque fois qu'il tente de se connecter à votre réseau. Tout d'abord, un PDP, ou point de décision de la politique, doit déterminer son niveau de confiance, puis un PEP, ou point d'application de la politique, doit lui refuser l'accès le moins privilégié en fonction du niveau de confiance spécifié.

Trop souvent, les organisations passent directement à l'évaluation des fournisseurs de PEP, qui constitue l'étape 5 du guide du NIST. Si vous commencez plus de la moitié du processus, vous ne parlerez qu'aux fournisseurs PEP, qui peuvent essayer de vous convaincre qu'ils sont tout ce dont vous avez besoin pour une confiance zéro. Il existe 4 approches d'application des politiques à prendre en compte et des dizaines de fournisseurs pour chacune d'entre elles. Voulez-vous utiliser une approche centrée sur l'argent, sur le périmètre, sur l'accès au réseau ou sur l'application ? Sur la base de l'analyse ci-dessus, il est clair que le Zero Trust va nécessiter un mélange de ces options, et vous n'avez pas encore assez d'informations pour les évaluer.

Les étapes 1 à 3 vous obligent à identifier et à classer tout ce qui traverse les différentes frontières de votre réseau et à comprendre les flux de communication entre ces éléments. Ce n'est qu'ensuite que vous pourrez vous attaquer à l'étape 4 : créer des politiques pour déterminer ce qui doit être communiqué avec quoi. La conception de votre politique dictera l'étape 5 : les solutions PEP candidates dont vous avez besoin dans chaque cas.

Piège n°3 : Ne pas utiliser toutes les informations disponibles sur la conformité et les menaces dans votre PDP

Les PDP ont leur propre lot de problèmes. Un PDP intelligent repose sur des renseignements continus sur la conformité et les menaces provenant de sources multiples. Plus le contexte est important, plus le point de décision est intelligent. La plupart des organisations disposent de nombreuses sources de ces informations, mais elles ne sont pas exploitées en permanence et rassemblées pour informer chaque décision d'accès.

Le PDP dispose d'un moteur de politique qui doit refléter les entrées provenant des agents de sécurité et des abonnements, du système CDM et du système SIEM, des journaux d'activité et des outils de sécurité utilisés pour l'évacuation des vulnérabilités ( VA ), la protection des Endpoints, la protection contre la perte de données, etc. Vous souhaitez également intégrer des informations sur la conformité aux normes et aux politiques telles que le NIST CMF, la gestion des identifiants et l'accès aux données. Ces informations collectives, provenant de plusieurs fournisseurs, outils et sources, devraient se manifester dans diverses politiques sous forme de contrôles spécifiques à effectuer. Par exemple, avant qu'une infirmière puisse accéder au DME / DSE sur un poste de travail, des contrôles d'identité pour l'utilisateur et la machine doivent être effectués, ainsi que des contrôles VA pour les vulnérabilités critiques exploitées et des contrôles EDR pour les menaces ou les IoC.

Ces contrôles doivent être continus, automatiques et se dérouler à la vitesse de la machine afin de ne pas perturber les flux de travail et, surtout, de couper l'accès au réseau si un contrôle échoue.

Piège n°4 : Formuler des politiques sans découverte, classification et regroupement

La visibilité est la base du Zero Trust. Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir. Avant de commencer à créer des politiques, vous voulez savoir, avec une grande fidélité, quels sont les appareils connectés à votre réseau, qui sont les utilisateurs, avec quoi ils communiquent et quels sont les processus et les risques existants.

Le processus de découverte produit une liste brute d'adresses IP qui n'est guère utile pour les humains qui créent des politiques. Elles doivent être traduites dans votre logique métier, c'est-à-dire classées par type de dispositif et d'utilisateur, puis regroupées par fonction métier. Par exemple, les appareils à rayons X et les serveurs PACs peuvent être regroupés dans la catégorie de l'imagerie médicale, tandis que les scanners de badges et les serrures de portes électroniques peuvent appartenir à la catégorie BAS. Ces étapes ouvrent la voie à la rédaction des politiques de groupe, nécessaires pour évaluer la confiance et l'accès au moindre privilège, le cœur du Zero Trust. Cela peut sembler être une entreprise énorme, mais l'ensemble du processus peut être automatisé pour inclure la découverte, la classification et l'évaluation continues et passives sur le campus, le data center, le cloud, l'IdO, l'IoMT, les appareils médicaux et les environnements OT.

Piège n°5 : Perturbation de l'activité pendant la mise en œuvre de la politique

Ensuite, il est temps de visualiser et d'analyser les flux de trafic. Quels types d'utilisateurs, de dispositifs et de machines communiquent avec quels autres types d'utilisateurs, de dispositifs et de machines ? Certaines de ces autorisations sont-elles inappropriées ? Comment pouvez-vous optimiser les communications ? Grâce à cette compréhension, vous pouvez définir exactement comment vous voulez que ces humains communiquent avec ces entités non humaines, que cette station de travail communique avec ce dispositif d'imagerie, et ainsi de suite.

Un moyen infaillible de tuer votre projet de Zero Trust est de provoquer une perturbation de l'activité. Cela se produit généralement lorsque vous mettez en place de nouvelles politiques de Zero Trust qui ont un impact sur les communications et peuvent causer des désagréments ou des dommages. Par exemple, vous pouvez créer une politique sur la façon dont la machine d'imagerie d'un radiologue communique avec un serveur PACS sur la base de configurations de port et de protocole documentées. Cependant, il arrive souvent que des communications non documentées mais valides se produisent également.

La meilleure façon d'éviter les perturbations est de simuler les politiques et de surveiller les flux de trafic avant de déployer de nouveaux contrôles. Le NIST SP 800-207 ne fait pas expressément référence à la simulation, mais recherchez-la dans les principaux outils de sécurité utilisés pour le Zero Trust. Par exemple, Forescout peut être exécuté en mode simulation pour signaler les violations de politiques qui pourraient avoir des conséquences inattendues sur le réseau. Cela vous permet d'affiner et de valider vos politiques avant la mise en service.

Piège n°6 : Ne pas séparer le PDP dans le plan de contrôle du PEP dans le plan de données

Enfin, vous êtes prêt pour l'étape 5 : l'évaluation de différents fournisseurs et PEP. Imaginez que vous commenciez ici, sans comprendre les types d'utilisateurs, de dispositifs et de modèles de trafic dans votre environnement. En procédant séquentiellement à partir de l'étape 1, lorsque vous atteindrez ce point, vous saurez : "Ceci doit être un pare-feu, cela nécessite un accès défini par logiciel, j'ai besoin d'argent ici". La plupart des points d'application adéquats se trouvent probablement déjà sur votre réseau. Il suffit de les relier à un moteur de politique macro. Ne vous fiez pas à des moteurs de politique PEP cloisonnés, ils ne tiendront pas compte de votre macro-écosystème, qui comprend de nombreux autres outils de cybersécurité.

Un autre concept majeur de la ZTA du NIST est l'extrapolation physique du plan de contrôle à partir du plan de données. Vous connaissez déjà cette pratique pour la gestion des identités. Vous vous souvenez quand c'était un cauchemar ? 
Chaque application, chaque serveur et chaque objet avait sa propre identité pour chaque utilisateur. Aujourd'hui, la meilleure pratique consiste à gérer les identités à partir d'un emplacement central dans le plan de contrôle et à les mettre en correspondance avec les applications dans le plan de données. La même pratique s'applique aux politiques Zero Trust. Un seul PDP situé dans le plan de contrôle peut rédiger toutes les politiques nécessaires et les faire respecter par les différents PEP du plan de données.

Piège n°7 : Déployer petit et penser petit

Tout étant en place, vous êtes prêt pour le déploiement et la surveillance initiales de ZTA. On vous conseillera de ne pas manger tout l'éléphant en une seule bouchée. Il est vrai que vous ne voulez pas tout activer d'un seul coup, mais vous voulez planifier l'ensemble de votre mise en œuvre dès le départ pour éviter de devoir revoir la conception ou, pire, de voir le déploiement s'arrêter.

Il est sage de commencer votre mise en œuvre dans de petites sections de votre écosystème et de l'étendre petit à petit. Cependant, si vous vous concentrez sur un petit secteur sans avoir une vue d'ensemble, vous risquez de ne pas avoir confiance dans ce secteur, mais de devoir redémarrer pour accomplir le reste, ou de ne jamais le terminer.

Ready, Set go !

Pour conclure, reformulons les pièges à éviter en impératifs à suivre. Tamer Baker en a cité 7, même s'ils ne correspondent pas nécessairement aux 7 principes du NIST SP 800-207 : 

1. Comprendre la réalité de l'ensemble de votre terrain numérique.
2. Ne commencez pas par le PEP. Commencez par la sensibilité et l'inventaire des actifs, qui sont les fondements du Zero Trust.
3. Incorporez tous les renseignements disponibles sur la conformité et les menaces dans votre PDP.
4. Découvrez, classez et regroupez tout ce qui est connecté à votre réseau avant de concevoir des politiques.
5. Simulez toutes les nouvelles politiques de Zero Trust et contrôlez leur impact avant de les mettre en œuvre.
6. Placez le PDP dans le plan de contrôle et les PEP dans le plan de données.
7. Déployez de manière incrémentielle, mais tenez compte de l'ensemble du tableau dès le départ.

Si vous respectez ces règles et accordez une attention particulière aux considérations relatives à l'environnement des soins de santé, vous serez sur la bonne voie pour le Zero Trust.

La planification de votre architecture Zero Trust pour les soins de santé ne s'arrête pas aux utilisateurs et aux postes de travail gérés. Voici comment démarrer et éviter les pièges !

À propos de l'auteur : 

Tamer Baker, Vice-Président, Global Healthcare, aime aider les clients à élaborer des stratégies et des politiques de conformité réglementaire, à améliorer leur position en matière de cybersécurité et à positionner leur organisation comme un fournisseur de premier ordre sur la base des cadres NIST, CIS, Zero Trust et autres. Il s'est spécialisé dans les stratégies d'automatisation de la conformité dans les domaines suivants : CDM, C2C, santé, finance / banque, etc.