En bref : la fuite de trackers HIPAA de Kaiser Permanente, 13,4 millions de personnes concernées
- Pas de hack, fuite quand même : Pas de détournement. Pas d'acteur malveillant. Kaiser Permanente a quand même laissé fuiter 13,4 millions de dossiers de membres parce que le marketing avait installé des trackers que l'ingénierie n'avait jamais cadrés, et chaque équipe pensait que l'autre portait le risque.
- Trackers sur pages HIPAA : Les pixels fuités exfiltraient noms, adresses IP, URLs visitées, état de connexion et termes de recherche dans l'encyclopédie santé, sur des pages couvertes par HIPAA. cside peut restreindre un script à un périmètre défini au niveau de la page et signaler tout déclenchement là où il ne devrait pas se produire.
- Cadrez ou retirez : Si un tracker de votre site peut se charger sur une page contenant des données PHI, PII ou de paiement, cadrez-le dès aujourd'hui. Si vous ne pouvez pas le cadrer, retirez-le avant que votre prochaine lettre d'audit ne devienne une lettre de notification de violation.
Peu de temps ? Découvrez le blocage Magecart et skimmer dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
Le 29 avril, le géant de la santé Kaiser Permanente a divulgué une fuite de données touchant 13,4 millions de membres actuels et anciens de son assurance. L'incident trouve son origine dans une gestion inadéquate de scripts tiers.
L'incident
Kaiser Permanente utilisait des codes de suivi pour surveiller la façon dont ses membres naviguaient sur son site web et ses applications mobiles. Certaines de ces pages contenaient des données de santé sensibles, ce qui a conduit les scripts tiers à transmettre par inadvertance des informations à des fournisseurs tiers qui n'étaient pas censés les recevoir.
Bien que la violation ne résulte pas d'un détournement de script, elle met en évidence une lacune courante dans la façon dont le secteur de la santé, et les entreprises ailleurs, gèrent les scripts tiers.
L'incident soulève également un problème plus large : les équipes d'ingénierie se voient souvent demander, de manière ponctuelle, d'implémenter des scripts tiers choisis par les équipes marketing, data ou juridiques. Cela peut amener les ingénieurs à implémenter le script sans disposer du contexte nécessaire, et à le déployer sur l'ensemble du site. Ça fonctionne, mais ça touche désormais des données qu'il ne devrait pas toucher.
Les outils adéquats pour détecter ou prévenir ce type de problème n'étaient vraisemblablement pas en place.
Les risques
Le problème central était un manque de compréhension et de divulgation appropriée concernant le code de suivi utilisé, et non une intention malveillante. Les données partagées comprenaient les noms, les adresses IP, les pages visitées, le statut de connexion des utilisateurs et les termes de recherche utilisés dans l'encyclopédie de santé en ligne de Kaiser. Bien que de tels scripts de suivi soient très courants, dans le secteur de la santé, ils doivent se conformer aux réglementations sur la vie privée telles que le Health Insurance Portability and Accountability Act (HIPAA) et d'autres.
Les risques d'une divulgation insuffisante
Les prestataires de soins de santé traitent des informations sensibles, et toute fuite de données peut avoir de graves répercussions. Même si les données partagées par Kaiser ne sont peut-être pas classifiées comme informations de santé protégées sous forme électronique (ePHI), la violation pourrait tout de même entraîner des sanctions et, très certainement, nuire à la réputation de l'entreprise. L'incident montre que de nombreuses entreprises dotées d'équipes solides en matière de sécurité et de conformité souffrent encore d'une mauvaise gestion des scripts tiers. Un problème que nous observons bien trop souvent.
Une solution concrète
Pour remédier à ce type de problème, les entreprises peuvent mettre en place des politiques de sécurité du contenu (CSP) robustes afin de gérer les scripts tiers sur les pages sensibles. Bien que cette solution présente certains inconvénients, comme des journaux de console bruyants, elle atténue efficacement le risque de partage non autorisé de données.
Idéalement, plutôt que de déployer les scripts de manière globale, il conviendrait d'utiliser le rendu conditionnel, en définissant les pages sur lesquelles les scripts doivent se charger.
En utilisant cside, vous pouvez également gérer vos scripts tiers de manière plus propre, en voyant quels scripts s'exécutent sur des pages spécifiques et en arrêtant le code malveillant avant qu'il ne s'exécute.
cside
cside peut signaler toute détection de scripts sur des pages contenant des informations sensibles, grâce à des règles fines et générées automatiquement permettant d'empêcher leur exécution sans journaux de console intempestifs sur ces pages.
Pour répondre aux enjeux de sécurité des scripts tiers, notre solution analyse les scripts avant qu'ils n'atteignent le navigateur de l'utilisateur. En proxifiant les scripts et en utilisant l'IA pour détecter les intentions malveillantes, cside s'assure que les menaces potentielles sont neutralisées avant de pouvoir causer des dommages. Cette approche proactive, combinée à une analyse du contexte historique, permet une surveillance efficace et une réponse adaptée aux violations liées aux scripts tiers.
Nous surveillons naturellement aussi tous les scripts, ce qui signifie qu'avec notre solution en place, ce problème aurait pu être évité.
