- Une base de données publique liée à la société HealthTech ESHYFT, basée dans le New Jersey, a exposé 86 341 enregistrements et 108,8 Go de données. La plateforme met en relation des établissements de santé et du personnel infirmier dans 29 États
- Les données exposées comprenaient des profils et images de visage, des CSV de plannings mensuels, des certifications professionnelles, des contrats d’affectation, des CV ainsi que d’autres données personnelles identifiables (PII)
- Certains fichiers semblent être des documents médicaux téléversés dans l’application pour justifier des absences ou congés maladie, avec des informations de diagnostic, de prescription et de traitement potentiellement soumises à la réglementation HIPAA
- Après une notification responsable du chercheur, l’accès à la base de données a été restreint plus d’un mois plus tard, mais le responsable de l’administration, la durée d’exposition et l’éventuel accès par des tiers restent inconnus
- Les plateformes de personnel médical devraient mettre en place le chiffrement des données sensibles, des audits de sécurité réguliers, une conservation minimale et l’anonymisation, un stockage séparé selon le niveau de sensibilité, le MFA, ainsi qu’un plan de réponse aux incidents et un canal de signalement dédié
Exposition constatée dans la base de données publique d’ESHYFT
- Le chercheur en cybersécurité Jeremiah Fowler a découvert une base de données sans protection par mot de passe ni chiffrement, puis l’a signalée à Website Planet
- La base contenait 86 341 enregistrements semblant appartenir à ESHYFT, pour un volume total de 108,8 Go
- Le nom de la base de données et des documents internes indiquaient que ces enregistrements appartenaient à ESHYFT, et la plupart des documents se trouvaient dans un dossier « App »
- ESHYFT est une société HealthTech basée dans le New Jersey, qui exploite une plateforme mobile mettant en relation des établissements de santé et du personnel soignant
- Le personnel concerné comprend des Certified Nursing Assistants (CNAs), Licensed Practical Nurses (LPNs) et Registered Nurses (RNs)
- L’application est disponible sur l’Apple App Store et le Google Play Store
- Sur le Google Play Store, elle compte plus de 50 000 téléchargements
- Apple ne fournit plus de statistiques utilisateurs
Fichiers exposés et sensibilité des informations médicales
- Un échantillon limité a permis d’identifier plusieurs types de fichiers
- Profils utilisateur ou images de visage
- Fichiers .csv contenant des journaux mensuels de planning
- Certifications professionnelles
- Contrats d’affectation
- CV et résumés de carrière, ainsi que d’autres informations personnelles identifiables (PII)
- Un seul document de type tableur contenait plus de 800 000 entrées
- ID interne des infirmiers
- Nom de l’établissement
- Dates et horaires de garde
- Temps de travail, etc.
- Des documents médicaux apparemment téléversés dans l’application ont aussi été identifiés
- Il pourrait s’agir de fichiers destinés à justifier l’absence d’un infirmier ou un congé maladie
- Les rapports médicaux incluaient des informations de diagnostic, de prescription et de traitement
- Ces informations pourraient relever du champ d’application de HIPAA
Mesures prises après la notification et incertitudes persistantes
- Le chercheur a immédiatement adressé à ESHYFT une notification responsable
- L’accès public à la base de données n’a été restreint qu’après plus d’un mois
- La réponse d’ESHYFT a été : « Thank you! we’re actively looking into this and working on a solution »
- Plusieurs points restent à confirmer
- La base de données était-elle directement détenue et administrée par ESHYFT, ou par un prestataire tiers ?
- Depuis combien de temps était-elle exposée avant sa découverte par le chercheur ?
- D’autres personnes y ont-elles accédé ?
- Un éventuel accès supplémentaire ou une activité suspecte ne pourrait être identifié qu’au moyen d’un audit forensic interne
Une charge de sécurité croissante à mesure que les plateformes de personnel médical grandissent
- ESHYFT met en avant le fait qu’elle permet aux infirmiers de choisir des missions adaptées à leur planning, tout en donnant aux établissements de santé accès à un personnel infirmier W-2 vérifié
- La plateforme est disponible dans 29 États américains
- AL, AZ, AR, CA, CT, DE, FL, GA, IL, IN, IA, KS, KY, MD, MI, MN, MO, NE, NJ, OH, PA, RI, SC, TN, VT, VA, WA, WI, WV
- Selon un rapport de la Health Resources & Services Administration (NCHWA), le taux de pénurie d’infirmiers diplômés aux États-Unis pourrait atteindre 10 % d’ici 2027
- Avec la hausse de la demande en personnel soignant, des plateformes comme ESHYFT contribuent à combler les pénuries de main-d’œuvre
- À mesure que le personnel infirmier travaillant sur site s’intègre aussi aux technologies en ligne, les sociétés HealthTech doivent renforcer leurs dispositifs de protection de la vie privée
- Plus les hôpitaux et professionnels de santé dépendent de la technologie pour le stockage des données, la gestion des soins et le recrutement, plus la charge de cybersécurité du secteur augmente
- Les hôpitaux sont considérés comme des infrastructures critiques, et plusieurs réseaux ont subi de graves attaques par ransomware ces dernières années
Risques potentiels et mesures de sécurité nécessaires
- L’exposition des données personnelles identifiables, des informations de paie et de l’historique professionnel du personnel infirmier peut créer des risques à la fois pour les individus et pour les établissements employeurs
- Si des scans de pièces d’identité comme un permis de conduire ou une Social Security card sont combinés à des adresses et coordonnées, ils pourraient être utilisés pour de l’usurpation d’identité ou des fraudes financières
- La divulgation d’informations personnelles et professionnelles peut aussi mener à du phishing ciblé exploitant des données réelles
- Les victimes peuvent être trompées par de fausses offres d’emploi ou incitées à divulguer davantage d’informations personnelles et financières
- Cela ne signifie toutefois pas que les données d’ESHYFT ou de ses utilisateurs ont effectivement été utilisées pour des fraudes ou des actes malveillants
- Les sociétés HealthTech et éditeurs de logiciels médicaux devraient envisager les mesures suivantes
- Protocoles de chiffrement obligatoires pour les données sensibles
- Audits de sécurité réguliers afin d’identifier les vulnérabilités de l’infrastructure interne
- Limitation du stockage des données sensibles et anonymisation lorsque c’est possible
- Définition d’une date d’expiration pour les données qui ne sont plus utilisées
- Stockage séparé selon la sensibilité des documents
- Dans ce cas, les fichiers utilisateurs semblent avoir été téléversés dans un dossier unique sans séparation selon leur niveau de sensibilité
- Les images de profil peuvent présenter une faible sensibilité
- Les justificatifs d’examens médicaux peuvent présenter une sensibilité élevée
- En théorie, ces deux types de documents ne devraient pas être stockés dans le même dossier
- La séparation et le chiffrement des données sensibles fournissent une couche de protection supplémentaire en cas d’exposition accidentelle ou d’attaque malveillante
- Les applications donnant accès à des informations ou documents sensibles devraient exiger le MFA
- Même si des identifiants comme un nom d’utilisateur et un mot de passe sont compromis, cela rend plus difficile l’accès direct à l’application ou au tableau de bord utilisateur
- Les sociétés HealthTech devraient disposer d’un plan de réponse aux violations de données et d’un canal de communication dédié au signalement des incidents de sécurité potentiels
- Se limiter au support client ou aux contacts commerciaux peut retarder l’escalade vers les responsables clés censés agir en cas de violation de données
- Quand des données sensibles sont exposées publiquement, tout retard dans l’atténuation et la remédiation peut être critique
- Après un incident de données, une notification responsable et en temps utile doit être fournie aux utilisateurs potentiellement directement affectés
- Les utilisateurs devraient aussi être informés de la manière d’identifier les tentatives de phishing liées à l’application ou au service concerné
- Cela ne signifie pas que Shiftster LLC dba ESHYFT, ses prestataires ou ses affiliés ont commis des actes illégaux, ni que des données internes ou utilisateurs faisaient l’objet d’un danger imminent
1 commentaires
Avis sur Hacker News
J’ai récemment entendu dire que cette entreprise, avant de proposer des missions, utilise le rapport de crédit pour déterminer le niveau d’endettement, autrement dit le degré de désespoir, puis s’en sert pour ajuster à la baisse le taux horaire proposé.
Si cette fuite leur cause des torts, ils semblent bien mériter encore pire.
Quand elles acceptent un appel, elles doivent activer une appli de géolocalisation ; si elles se retrouvent dans les embouteillages ou perdent le signal mobile, elles accumulent des pénalités, qui se traduisent ensuite par une baisse de salaire.
C’est une façon de transformer en arme des conditions de travail infirmier déjà déplorables : trop de patients, pas assez de personnel de soutien, et des dossiers à remplir même après des gardes de 12 heures. Ma femme est infirmière, donc ça me paraît d’autant plus concret.
Surtout pour une infirmière expérimentée, il n’y a aucune raison d’utiliser une appli minable qui tire les salaires vers le bas ; elle devrait pouvoir être embauchée presque immédiatement par n’importe quel établissement de santé, et pour une RN, les options en télémédecine semblent aussi nombreuses.
Elle peut avoir un conjoint, ses parents peuvent payer ses factures de carte de crédit, une personne avec un mauvais crédit peut s’en soucier assez peu, ou il peut y avoir de l’argent familial.
On peut aussi avoir peu de dettes et avoir désespérément besoin d’un emploi ; je me demande si ça fonctionne vraiment.
La section Data Security de la politique de confidentialité indique qu’ils utilisent des mesures de protection physiques, administratives et techniques pour améliorer l’intégrité et la sécurité des informations collectées et conservées, mais qu’aucune sécurité n’est parfaite ni impénétrable, et qu’ils ne garantissent pas l’absence de fuite, de consultation, de divulgation, d’altération ou de destruction.
En particulier, le service précise qu’il n’est pas conçu pour stocker ou protéger des informations de santé protégées au sens de la HIPAA ; je ne sais pas si dire « désolé, nous ne l’avons pas conçu comme un système conforme à la HIPAA » peut vraiment faire disparaître leur responsabilité.
0 : https://eshyft.com/wp-content/uploads/2019/06/ESHYFT-Privacy...
L’article dit que les infirmières semblent avoir téléversé dans l’appli des documents médicaux contenant des informations de diagnostic, de prescription et de traitement pour justifier des absences ou des congés maladie, et que cela pourrait relever des informations de santé protégées.
Le fait que cette entreprise soit soumise ou non à la HIPAA dépend de son statut de covered entity ou de business associate ; à la lecture de la politique de confidentialité, il semble peu probable qu’elle ait conclu un Business Associate Agreement.
Ajoutons que la HIPAA elle-même n’est pas non plus un standard de sécurité idéal : de grandes entreprises échangent de grandes quantités d’informations de santé protégées via Gmail au motif que Gmail est conforme à la HIPAA.
0 : https://www.hhs.gov/hipaa/for-professionals/covered-entities...
Grosso modo, cela vise les prestataires de soins qui acceptent l’assurance et les assureurs ; un prestataire de soins qui n’accepte pas l’assurance n’a pas à se conformer à la HIPAA.
Ici, ESHYFT semble n’être qu’une entreprise fournissant de la main-d’œuvre, donc la HIPAA ne paraît pas directement pertinente, et ce n’est pas très différent d’un grand cabinet de conseil proposant des services de renfort en personnel.
Cela dit, son périmètre est plus étroit qu’on ne s’y attend et les sanctions sont faibles. Même si Facebook fait installer des pixels de suivi et aspire ainsi des données médicales personnelles, il y a de fortes chances que ce ne soit pas une violation de la loi, et qu’on puisse seulement se retourner contre ceux qui ont créé la fuite.
Dans ce cas aussi, il ne semble pas facile de limiter les dommages via la HIPAA. Cela ressemble plutôt au cas d’un médecin qui aurait mis des données de patients sur Google Drive, puis où elles auraient fuité via un sous-traitant de Google ou un piratage.
Les données protégées par la HIPAA ne sont ni nécessaires ni utiles au service ESHYFT, donc il semble difficile de gagner facilement sur le terrain d’une violation de la HIPAA, mais d’autres responsabilités en dommages et intérêts restent possibles.
En raison de l’autorité dont disposent les professionnels de santé, il est facile de se tromper, mais il vaut mieux ne jamais donner son numéro de sécurité sociale à un médecin ou à un hôpital.
Ils n’en ont pas besoin. Vérifier une pièce d’identité ne veut pas dire la scanner ni la photographier.
Les médecins, hôpitaux et cliniques font partie des pires en matière de sécurité de l’information ; ils ont très peu de formation, sont peu sanctionnés en cas d’erreur, et ce type d’information sert surtout à vous retrouver si vous ne payez pas une facture.
Je me demande quel âge a ce bucket S3. À partir d’un certain moment, AWS a rendu les nouveaux buckets S3 privés par défaut.
Dans ce cas, il y a de fortes chances que ce soit un vieux bucket, ou qu’ils l’aient imprudemment ouvert au public parce que les chargements/téléchargements de fichiers ne fonctionnaient pas dans l’application mobile ou le service.
Je me demande pourquoi le titre utilise « Uber pour infirmières » au lieu du vrai nom de l’entreprise.
La semaine dernière, on accusait Firebase ; cette fois, on va accuser AWS ?
Les procédures de sécurité qu’on applique quand on bricole un truc à 3 h du matin pour le montrer à des amis ne devraient pas être reprises telles quelles dans un produit qui héberge des données personnelles identifiables. La sécurité de base des données doit être mise en œuvre par l’exploitant lui-même.
Il faut faire en sorte que les développeurs tombent dans le piège de la réussite : être en sécurité même en suivant simplement les paramètres par défaut.
Dans ce cas, les buckets S3 devraient être privés et chiffrés par défaut, avec une désactivation explicite par le développeur. C’est possible aujourd’hui, mais ça ne l’était pas par le passé.
Le secteur de la santé est cassé de bout en bout, et même les entreprises tech qui gravitent autour donnent l’impression d’être incompétentes.
Comme des hôpitaux bon marché appartenant à des groupes ne veulent pas embaucher les infirmiers comme salariés W2, le travail infirmier se retrouve ubérisé, et l’avarice des hôpitaux a probablement conduit au choix d’apps aussi médiocres.
Il se peut même que l’administrateur qui a approuvé ait touché un pot-de-vin ; ESHYFT devrait faire faillite pour ça, mais en réalité il est plus probable qu’il ne se passe rien.
Tant que des dirigeants n’iront pas en prison, ce genre de chose continuera. Quelqu’un a très probablement gagné beaucoup d’argent avec cette activité sans investir dans la sécurité de l’information.
Le prix des économies réalisées a été payé par des gens qui n’avaient rien à voir avec les bénéfices, et dans quelques années ces dirigeants iront peut-être donner des conférences sur la façon de bâtir une entreprise à succès.
Si ce genre de comportement n’a aucune conséquence, le public continuera à payer le coût des profits privés.
Les grands systèmes de santé disposent de leur propre vivier d’infirmiers volants ou de systèmes internes de propositions.
L’accès à des dispositifs de gestion des congés et des postes vacants fait aussi partie des arguments utilisés pour convaincre lors d’une vente à un grand système.
Les personnes qui savent que c’est mal sont justement celles qui en bénéficient, elles ont donc très peu d’incitations à corriger le problème.
On fait encore semblant de croire qu’il existe des régulateurs fonctionnels capables d’agir sur ce genre de choses ?
Je ne comprends pas pourquoi ça se répète sans cesse. On a l’impression qu’il y a une nouvelle fuite depuis un bucket S3 ouvert tous les mois.
Le plus important, c’est qu’il y a beaucoup de gens fortement motivés à scanner en masse. Aujourd’hui, il est très facile de parcourir Internet — GitHub, IP, domaines, etc. — et la détection de « mauvaises configurations S3 » se fait au niveau de scripts accessibles à tout le monde, sans nécessiter de compétences avancées en programmation.
Cette politique peut ensuite ne plus convenir à l’environnement de production. Je ne dis pas que c’est correct, seulement que c’est comme ça que les choses se passent dans la pratique.
Si la personne qui a construit l’infrastructure l’a fait en étant complètement épuisée, puis s’est réveillée le matin en découvrant ça, c’est vraiment triste.