Dans cet article je vais vous donner des indications sur les moyens simples que vous pouvez mettre en œuvre pour faire des contrôles de sécurité. Je vais commencer par le plus simple pour aller vers le plus complet. Si un des tests échoue, alors inutile d’aller plus loin. Il faut demander à l’éditeur un test d’intrusion (pentest) par un prestataire de sécurité. Je reviendrai sur les pentest à la fin de l’article.
Les logiciels hospitaliers sont de plus en plus connectés à des applications SaaS dans lesquelles sont stockées des données de patients.
Les équipes en place sont organisées pour contrôler/inspecter la sécurité des applications installées dans le Datacenter de l’hôpital ou résidant sur les postes. Par contre quasi inexistants sont les cas où la sécurité des applications SaaS est contrôlée.
Ceci est d’autant plus dommage que certains de ces tests de sécurité sont extrêmement simples à réaliser et ne prennent que quelques minutes. Vous pourrez ainsi mesurer la maturité de l’éditeur sur les questions de sécurité ainsi que la robustesse du logiciel SaaS. Le succès à ces tests n’implique pas une sécurité aux normes mais l’échec à ces tests simples indique un non-respect des règles élémentaires de sécurité.
Je cite les logiciels que j’ai utilisé, qui m’ont été conseillé. Je n’ai aucun lien d’intérêt avec ces entités, ni aucune rémunération. Ce sont simplement des exemples. Évidemment il y a de nombreuses autres solutions.
- L’infrastructure
Si le logiciel SaaS manipule des données de santé, il doit être hébergé sur un système certifié HDS : Hébergeur de Données de Santé. Pour le savoir il suffit de demander le certificat d’hébergement.
Les serveurs doivent être protégés par un firewall, c’est à dire un logiciel qui bloque les entrées et les sorties en fonction de règles qui peuvent être sur une url, sur une adresse IP ou sur un port. Demander la matrice des flux est un bon moyen de vérifier si l’éditeur gère activement ce point. Pour contrôler ce firewall vous pouvez utiliser un logiciel comme celui-ci : https://www.ipfingerprints.com/portscan.php
Si d’autres ports que les 80 et 443 sont ouverts sur internet cela demande une explication, une justification claire du besoin, ainsi qu’une liste des mesures de sécurité mises en place afin de limiter la surface d’attaque sur ces services, appelées “contre-mesures”.
- La sécurité de l’application
La sécurité repose sur le trinôme Confidentialité, Intégrité et Disponibilité des données et des services. Les failles Web les plus communes sont listées dans ce que l’on appelle le TOP 10 OWASP (https://owasp.org/www-project-top-ten/, https://avengering.com/examiner-les-10-principaux-risques-de-securite-lies-a-owasp/). Le test exhaustif de toutes ces failles n’est pas l’objet de cet article mais il est possible de faire des sondages simples pour révéler des failles évidentes.
A. Confidentialité
Configuration du serveur web :
Tous les échanges d’information doivent être effectués en HTTPS avec des algorithmes réputés sûrs. Pour le vérifier, rien de plus simple : SSLlabs (https://www.ssllabs.com/ssltest/) vous permet de contrôler la qualité du HTTPS. Le résultat doit être au moins A.
Au-delà de la configuration HTTPS, il existe des en-têtes de sécurité qui doivent être placés. Pour le vérifier, il suffit d’utiliser cet outil : https://securityheaders.com. Le résultat doit être au moins A.
Une faille très fréquente provient de mot de passe faible. Pour le vérifier, demandez à créer un compte sur l’application et vérifiez que le système n’autorise pas de mot de passe de moins de 8 caractères, sans chiffre, majuscule et caractère spécial.
B.Intégrité
Certains outils permettent de tester les failles d’injection et XSS qui sont des failles concernant entre autres l’intégrité des données. Pentest-tools (https://pentest-tools.com/website-vulnerability-scanning/sql-injection-scanner-online#) permet de faire un contrôle simple. Ce n’est pas exhaustif mais cela donne une indication de maturité. Il ne doit y avoir aucun risque « high » ou « medium ».
C.Disponibilité
La disponibilité fait partie intégrante des critères de sécurité. Celle-ci est simple à mesurer avec un logiciel tel que Uptime robot (https://uptimerobot.com). Avant de débuter, il faut demander à votre fournisseur un relevé de disponibilité mensuel sur les 6 derniers mois. La non-disponibilité de ce rapport n’est pas acceptable.
Cet outil indique la disponibilité de l’URL indiquée, pas l’état fonctionnel de l’application. Cependant c’est une mesure a-minima intéressante. Le résultat est en %, généralement une mesure mensuelle en deçà de 99,90% n’est pas acceptable.
Il est aussi intéressant de mesurer la disponibilité en fonction de la charge de l’application. Pour cela l’outil K6 (https://k6.io) permet de mesurer le temps de réponse en fonction du nombre de connexions simultanées. L’idéal est de mesurer le temps de réponse sur une page clé de l’application. À défaut, la page d’accueil de l’application permet de donner une indication de la charge acceptable
Un bon résultat à tous les tests ci-dessus ne garantit pas une application sécurisée. Mais le contraire indique un manque de maîtrise de la sécurité. Le cas échéant, demandez un pentest. J’ai travaillé avec 2 sociétés (Orange cyber défense et CNPP Cybersecurity) toutes deux très compétentes et agréables.
Alexis Hernot, Cofondateur de Calmedica