Marriott a fait de la base de données de réservation de Starwood une frontière de confiance avec les tiers

Résumé

• L'environnement de réservation de Starwood a été compromis fin juillet 2014, plus de deux ans avant que Marriott ne finalise l'acquisition de Starwood le 23 septembre 2016. Le dossier d'acquisition de Marriott se trouve àhttps://www.sec.gov/Archives/edgar/data/1048286/000119312516718014/d241360d8k.htm, et l'avis de pénalité final de l'ICO britannique est disponible àhttps://ico.org.uk/media2/migrated/2618524/marriott-international-inc-mpn-20201030.pdf.
• La question fondamentale de responsabilité n'est pas de savoir si Marriott aurait pu connaître tous les faits cachés avant la clôture. Il s'agit de la rapidité avec laquelle l'autorité post-clôture s'est transformée en un contrôle vérifié sur la base de données de réservation héritée, les identifiants privilégiés, la surveillance des bases de données, l'inventaire cryptographique, les limites des prestataires de services et la mise hors service des données.
• Les régulateurs ont par la suite emprunté des voies différentes: l'ICO a imposé une amende de 18,4 millions de livres sterling pour des défaillances de sécurité pendant la période du RGPD, les États américains ont conclu un accord de 52 millions de dollars, et la FTC a imposé une injonction de 20 ans. Marriott n'a pas reconnu sa responsabilité dans le cadre de l'accord avec les États et n'a pas fait appel de la pénalité de l'ICO.
• Le dossier met en évidence un risque opérationnel hérité, une découverte tardive, une surveillance incomplète, une protection inégale des passeports, des descriptions cryptographiques changeantes et des mesures correctives exécutoires. Il n'établit pas un nombre précis de personnes uniques, une identification publique de l'attaquant ou la preuve que chaque client concerné a subi une fraude avérée.

L'acquisition n'est pas une attestation de sécurité

L'acquisition d'une entreprise est souvent décrite en termes commerciaux: marques, chambres, membres de programmes de fidélité, marchés et valeur de transaction. La violation de Starwood montre pourquoi un système de données en production est également une frontière de confiance vis-à-vis des tiers. Avant la clôture, l'acheteur peut recevoir des déclarations, des documents de diligence raisonnable, des rapports de conformité, des résumés d'architecture et des divulgations de violations. Après la clôture, l'acheteur hérite de l'autorité opérationnelle. La vérité sécuritaire peut être en retard sur les deux.

Marriott a accepté d'acquérir Starwood en novembre 2015 et a finalisé l'acquisition le 23 septembre 2016. Starwood est devenue une filiale indirecte en propriété exclusive. La transaction a créé la plus grande entreprise hôtelière mondiale en termes de chambres et de marques, avec une empreinte de réservation mondiale décrite dans les documents d'acquisition àhttps://www.sec.gov/Archives/edgar/data/1048286/000119312516718014/d241360dex991.htm. Pourtant, la vérité sécuritaire de la base de données de réservation n'était pas identique à sa valeur commerciale. Selon l'ICO, l'intrusion ultérieurement liée à la violation de la réservation a commencé fin juillet 2014.

Cette chronologie est importante parce que Marriott ne possédait pas Starwood lorsque l'attaquant est entré pour la première fois. Elle est également importante parce que Marriott possédait l'entreprise alors que le système de réservation compromis restait en fonctionnement après la clôture. L'ancien directeur général de Marriott a déclaré à une sous-commission du Sénat américain en 2019 que l'examen technologique préalable à la clôture était limité parce que Marriott et Starwood restaient concurrents, que Marriott avait décidé de mettre hors service la plateforme de réservation de Starwood et que le transfert de 1 270 hôtels avait pris deux ans. Le témoignage est disponible àhttps://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/Soresnson%20Testimony.pdf. Ces contraintes sont réelles. Elles ne suppriment pas l'obligation post-clôture de vérifier l'environnement qui continuait à traiter les données des clients.

La distinction réside dans la frontière de confiance. Avant l'acquisition, Starwood était un tiers. Après l'acquisition, le système de Starwood est devenu le système opérationnel hérité de Marriott, même s'il était techniquement séparé du réseau plus large de Marriott. L'ICO a constaté que les réseaux Starwood et Marriott au sens large restaient cloisonnés et que l'attaquant n'avait pas pu accéder aux données traitées uniquement sur des systèmes non-Starwood. Ce cloisonnement a réduit la surface d'attaque. Cela signifiait également que le système hérité pouvait rester un lieu distinct où un intrus persistait.

La question de responsabilité post-clôture est donc fondée sur des preuves: quels comptes privilégiés ont été revalidés, quels identifiants de prestataires de services ont été renouvelés, quelles tables de base de données ont été surveillées, quelles exports ont été journalisés, quelles déclarations cryptographiques ont été testées, quels champs de données ont été cartographiés, quelles copies ont été mises hors service et à quelle vitesse la vérité du système hérité a remplacé la documentation du vendeur.

L'historique caché est entré en collision avec un historique de sécurité connu

Il ne faut pas confondre la violation de la base de données de réservation de Starwood avec la violation antérieure des terminaux de point de vente de Starwood, mais cette dernière s'inscrit dans le contexte du risque d'acquisition. Le rapport annuel 2015 de Starwood àhttps://www.sec.gov/Archives/edgar/data/316206/000156459016013371/hot-10k_20151231.htmavait divulgué des logiciels malveillants affectant les systèmes de point de vente de certains hôtels et indiquait à l'époque qu'aucun élément n'indiquait que les systèmes de réservation ou de fidélité étaient affectés par cet incident. Cette déclaration n'a pas révélé l'intrus caché dans la réservation. Elle a montré que Starwood avait eu récemment des problèmes de sécurité nécessitant un examen attentif de la part de l'acheteur.

La plainte de la Federal Trade Commission de 2024 àhttps://www.ftc.gov/system/files/ftc_gov/pdf/1923022marriottcomplaint_0.pdfa par la suite allégué des défaillances plus larges dans plusieurs violations, y compris des faiblesses liées à Starwood et Marriott. La plainte a été résolue par consentement et ne doit pas être traitée comme une décision de procès. Son intérêt ici est de montrer le type de thèmes de contrôle que les régulateurs ont par la suite soulignés: segmentation, contrôles d'accès, correctifs, authentification multifacteur, surveillance, protection cryptographique, conservation des données et évaluation des entités acquises.

L'ordonnance finale de la FTC àhttps://www.ftc.gov/system/files/ftc_gov/pdf/1923022marriottfinalorder.pdfa transformé ces thèmes en obligations à long terme. Elle exige un programme de sécurité, des éléments de programme de confidentialité, des évaluations liées aux acquisitions, une analyse des risques, des contrôles d'accès, une surveillance, des tests, des contrôles de suppression et de conservation, des rapports au conseil d'administration, une certification et une évaluation indépendante. L'ordonnance ne prouve pas toutes les allégations de la plainte. Elle montre ce que les régulateurs considéraient comme un contrôle prospectif nécessaire après un risque de violation hérité et répété.

Pour les équipes de transaction, la leçon est pratique. La divulgation d'une violation antérieure par un vendeur n'est pas un blanc-seing pour les systèmes adjacents. Un rapport de conformité peut couvrir un environnement et en manquer un autre. Une déclaration selon laquelle les systèmes de réservation ne semblaient pas affectés par un incident de point de vente ne prouve pas qu'ils étaient exempts d'une intrusion distincte. Un acheteur a besoin d'un plan de chasse aux menaces et de vérification des contrôles post-clôture pour les systèmes hérités à haute valeur, en particulier lorsque la migration prendra des années.

Chronologie: le contrôle commercial, la détection technique et la notification aux clients sont des horloges différentes

Au moins cinq dates jalonnent le dossier. Fin juillet 2014 marque l'entrée de l'intrus dans l'environnement Starwood. Le 23 septembre 2016 marque la clôture de l'acquisition par Marriott. Le 25 mai 2018 marque l'applicabilité du RGPD pour l'analyse juridique de l'ICO. Les 7 et 8 septembre 2018 marquent l'alerte de la base de données et l'escalade vers Marriott. Le 19 novembre 2018 est la date à laquelle Marriott a déclaré que les enquêteurs avaient déchiffré des fichiers et confirmé que des informations personnelles de la base de données de réservation de Starwood étaient impliquées.

L'avis de pénalité de l'ICO reconstitue l'entrée de fin juillet 2014 via un shell web sur un appareil prenant en charge une application pour les employés de Starwood. L'attaquant a utilisé des outils d'accès à distance, récolté des identifiants, s'est déplacé dans l'environnement et a finalement exporté des tables de base de données. Le dossier public ne fournit pas une liste complète des hôtes, une liste complète des fichiers ou la vulnérabilité initiale exacte. Il établit une longue présence non autorisée avant et après l'acquisition.

Le 7 septembre 2018, IBM Guardium a généré une alerte après qu'un compte administrateur a interrogé le nombre de lignes d'une table protégée de profils clients. Accenture, qui gérait la base de données de réservation des clients de Starwood, a escaladé vers Marriott le 8 septembre. Marriott a appris que la personne dont les identifiants avaient été utilisés n'avait pas effectué la requête. Cet événement était la détection d'une activité suspecte, pas la connaissance immédiate de chaque fichier exporté. Cela a lancé le chemin de découverte final.

Les jours suivants montrent pourquoi l'alerte, le confinement et la délimitation de l'étendue sont distincts. Marriott a déclenché la réponse aux incidents et fait appel à des enquêteurs externes. Le 10 septembre, selon l'ICO, une autre table liée aux passeports a été exportée dans un fichier de vidage. Le 17 septembre, les enquêteurs ont identifié un cheval de Troie d'accès à distance et bloqué l'activité de commande et de contrôle. En octobre, les enquêteurs ont découvert des preuves qui faisaient remonter l'historique de l'intrusion à 2014. Le 13 novembre, ils ont trouvé des traces de fichiers chiffrés et supprimés.

Le 19 novembre, ils ont déchiffré des fichiers et confirmé qu'ils contenaient des informations personnelles de la base de données de réservation.

Marriott a notifié l'ICO le 22 novembre et a divulgué publiquement le 30 novembre. L'avis de l'entreprise àhttps://marriott.gcs-web.com/news-releases/news-release-details/marriott-announces-starwood-guest-reservation-database-securityindiquait que la base de données se trouvait aux États-Unis et donnait les premières catégories de champs et les estimations de population. Une copie stable auprès de la SEC de la divulgation initiale se trouve àhttps://www.sec.gov/Archives/edgar/data/1048286/000162828018014745/a2018118k.htm.

L'ICO n'a par la suite pas rendu de décision finale concernant une violation de l'article 33 ou de l'article 34 à l'encontre de Marriott, après avoir examiné la chronologie de l'enquête et les déclarations de l'entreprise. Il s'agit d'une limite juridique. Cela n'efface pas la réalité opérationnelle selon laquelle la notification aux clients dépendait de la capacité de l'organisation à découvrir, déchiffrer et classer les fichiers exportés des mois après la première alerte.

Les décomptes et les champs doivent rester délimités

Le premier avis de Marriott utilisait un plafond d'environ 500 millions de clients, avec un sous-ensemble d'environ 327 millions d'enregistrements contenant des combinaisons plus larges de champs. Sa mise à jour de janvier 2019 àhttps://marriott.gcs-web.com/news-releases/news-release-details/marriott-provides-update-starwood-database-security-incidenta abaissé la limite supérieure à environ 383 millions d'enregistrements et a averti que les doublons signifiaient moins de clients uniques. L'ICO a par la suite utilisé 339 millions de dossiers clients dans le monde, dont 30,1 millions associés aux États de l'EEE et 7 millions associés au Royaume-Uni. L'accord multi-États de 2024 a utilisé 131,5 millions de dossiers clients associés aux États-Unis.

Ces chiffres ne doivent pas être additionnés. Les enregistrements ne sont pas des personnes uniques. Les sous-ensembles régionaux ne sont pas des ajouts mondiaux. Les populations des litiges et des régulateurs servent des objectifs procéduraux différents. Le rapport annuel 2018 de Marriott àhttps://www.sec.gov/Archives/edgar/data/1048286/000162828019002337/mar-q42018x10k.htma mis à jour les estimations pour les catégories de passeports et de cartes de paiement et a enregistré les coûts de l'incident et les recouvrements d'assurance, mais il n'a pas converti chaque enregistrement en la même exposition de données.

Les combinaisons de champs variaient également. L'avis initial énumérait les noms, les adresses postales, les numéros de téléphone, les adresses e-mail, les numéros de passeport, les informations du programme Starwood Preferred Guest, les dates de naissance, le sexe, les informations d'arrivée et de départ, les dates de réservation, les préférences de communication et certaines données de cartes de paiement.

L'ICO a décrit des détails au niveau des tables tels que les drapeaux VIP, les données de chambre et de séjour, les détails de vol, le pays et le numéro de passeport, le statut d'enregistrement et le nombre d'adultes ou d'enfants dans les chambres. Certains champs facilitent la fraude. D'autres facilitent un contact ciblé. Certains révèlent des schémas de voyage ou un contexte familial même sans identifiants financiers.

La description de la protection des paiements et des passeports a également changé dans les communications publiques. Marriott a d'abord décrit certains numéros de cartes de paiement et certains numéros de passeport comme étant protégés par un chiffrement AES-128. En avril 2024, Marriott a mis à jour ses pages d'incident pour indiquer que les numéros de carte de paiement concernés et certains numéros de passeport avaient plutôt été protégés par SHA-1. La page consommateur de la FTC àhttps://consumer.ftc.gov/consumer-alerts/2018/12/marriott-data-breacha par la suite noté la distinction. La page sur les fonctions de hachage du NIST àhttps://csrc.nist.gov/Projects/hash-functionset l'avis de transition SHA-1 àhttps://www.nist.gov/news-events/news/2022/12/nist-transitioning-away-sha-1-all-applicationsexpliquent pourquoi SHA-1 est une fonction de hachage et pourquoi une protection moderne ne devrait pas le traiter comme un chiffrement ordinaire.

La correction de 2024 ne prouve pas que toutes les valeurs protégées ont été inversées ou utilisées abusivement. Elle montre une défaillance de l'inventaire cryptographique. Un responsable du traitement gérant des données mondiales de réservation et de passeport devrait savoir quels champs sont en clair, chiffrés, hachés, tokenisés ou autrement transformés; quel algorithme s'applique; où se trouvent les clés ou les secrets; et comment ces faits sont vérifiés avant la notification publique. Une correction de cinq ans du chiffrement au hachage modifie la façon dont les personnes concernées et les régulateurs perçoivent le risque.

Ce que l'ICO a trouvé, et ce qu'elle n'a pas trouvé

L'avis de pénalité final de l'ICO est le dossier administratif public le plus solide pour la violation de la base de données de réservation de Starwood. Son champ d'application était plus étroit que l'histoire complète de 2014 à 2018. Il portait sur le traitement par Marriott du 25 mai 2018, date à laquelle le RGPD est devenu applicable, jusqu'au 17 septembre 2018, date à laquelle le cheval de Troie d'accès à distance a été identifié et contenu. Il n'a pas imposé de responsabilité au titre du RGPD pour la période antérieure au RGPD ni jugé que la diligence préalable de Marriott avant la clôture avait été juridiquement inadéquate.

Le texte du RGPD àhttps://eur-lex.europa.eu/eli/reg/2016/679/ojexige que les responsables du traitement mettent en œuvre des mesures techniques et organisationnelles appropriées, l'adéquation étant jugée en fonction du risque, de l'état de l'art, du coût, du contexte et des droits des personnes. L'ICO a constaté des violations des principes de sécurité et de l'article 32. Ses quatre principales conclusions en matière de sécurité concernaient une surveillance insuffisante des comptes privilégiés, une surveillance insuffisante de la base de données, un contrôle inadéquat des systèmes critiques et l'absence de chiffrement de tous les numéros de passeport.

La conclusion relative aux comptes privilégiés est importante parce que l'attaquant a utilisé des identifiants légitimes. Une session de base de données ou à distance peut sembler autorisée si la surveillance s'arrête à la validité des identifiants. La conclusion relative à la surveillance de la base de données est importante parce que l'alerte qui a finalement compté était liée à une table ayant une pertinence pour les cartes de paiement, alors que d'autres données personnelles ne bénéficiaient pas d'une alerte équivalente.

La conclusion relative au contrôle des systèmes critiques est importante parce que les systèmes capables d'atteindre de grands magasins de données personnelles devraient avoir des contrôles de renforcement et d'exécution. La conclusion relative aux passeports est importante parce que des millions de numéros de passeport n'étaient pas chiffrés et qu'aucune évaluation documentée des risques ne justifiait la protection inégale.

L'ICO a également supprimé ou n'a pas finalisé plusieurs questions souvent brouillées dans les récits publics. Elle a supprimé le point relatif à l'authentification multifacteur incomplète de la pénalité finale après avoir examiné le recours de Marriott aux assurances et aux rapports de conformité des cartes de paiement. Elle n'a rendu aucune décision finale sur une violation de l'article 33 (notification de violation) ni sur une violation de l'article 34 (notification individuelle). Elle a reconnu que la diligence approfondie avant la clôture peut être limitée dans le cadre d'une acquisition entre concurrents.

Ces limites ne rendent pas la violation petite. Elles rendent le dossier juridique précis.

Marriott a répondu à la décision finale de l'ICO àhttps://marriott.gcs-web.com/news-releases/news-release-details/marriott-international-update-conclusion-uk-ico-investigation, déclarant qu'elle ne ferait pas appel et n'admettant aucune responsabilité. Une posture de non-admission est procédurale. Elle coexiste avec les conclusions administratives finales de l'ICO.

Confiance dans les prestataires de services et la plateforme

La base de données de réservation de Starwood n'était pas une application interne unique détenue et touchée par une seule équipe. Accenture gérait la base de données de réservation des clients de Starwood, Guardium a généré l'alerte clé, les opérations hôtelières alimentaient les enregistrements de réservation, les processus de fidélité et de centre de contact dépendaient de la plateforme, et Marriott devait maintenir la continuité des activités tout en migrant les hôtels. Cela fait du système une frontière de confiance de plateforme, et pas seulement une base de données.

La gestion par des tiers modifie la question des preuves. Un responsable du traitement peut externaliser l'exploitation, mais il a toujours besoin de preuves de journalisation, d'escalade, d'examen des accès privilégiés, de contrôle des modifications, de surveillance des exportations, de conservation et de réponse aux incidents. Un prestataire de services gérés peut voir une alerte avant le responsable du traitement. Le responsable du traitement a toujours besoin de suffisamment de contexte pour décider si les données des clients sont en danger et si les obligations de notification ont commencé.

La séquence de septembre 2018 montre qu'une chaîne d'alerte peut fonctionner tout en laissant la délimitation de l'étendue non résolue pendant des semaines.

L'accord des États annoncé par le Connecticut àhttps://portal.ct.gov/ag/press-releases/2024-press-releases/multistate-settlement-with-marriott-for-data-breach-of-starwood-guest-reservation-databaseet le jugement enregistré du Vermont àhttps://ago.vermont.gov/sites/ago/files/documents/2024.10.09%20Marriott%20Judgment%20VT%20and%20Appendix%20final.pdfmontrent comment les autorités de poursuite des États américains ont traduit cette leçon en exigences. L'accord comprenait des contrôles de sécurité à long terme, une évaluation des entités acquises, des obligations liées aux franchisés et aux prestataires de services, une assistance aux consommateurs et un paiement. Il comprenait également une non-admission de responsabilité. Les conditions injonctives sont importantes parce qu'elles traitent les frontières de l'acquisition et des tiers comme des obligations de contrôle continues plutôt que comme des problèmes ponctuels de clôture.

L'ordonnance finale de la FTC ajoute une autre couche de frontière de confiance. Elle couvre non seulement l'incident de la réservation de Starwood, mais aussi un ensemble plus large d'allégations de sécurité concernant Marriott et Starwood. Ses dispositions en matière d'acquisition sont centrales ici: un acheteur doit évaluer et traiter les risques des entreprises acquises et les intégrer dans un programme de sécurité. C'est exactement le problème que la base de données de Starwood a révélé. Le système peut être cloisonné, programmé pour être mis hors service et commercialement nécessaire.

Il détient toujours des données de clients sous le contrôle de l'acheteur.

La localisation des données n'était qu'un seul fait

L'avis initial de Marriott indiquait que la base de données de réservation des clients de Starwood se trouvait aux États-Unis. C'était un fait de stockage utile. Il ne répondait pas à qui étaient les clients, quels hôtels et franchisés alimentaient les enregistrements dans la base de données, où le personnel et les prestataires de services y accédaient, quels régulateurs avaient autorité, quelles copies existaient ou où les fichiers exportés et les images forensiques résidaient par la suite.

L'ICO a compté les enregistrements associés à l'EEE et au Royaume-Uni parce que les personnes et le contexte de traitement importaient en vertu du droit européen. Les États américains ont compté les enregistrements associés aux États-Unis pour leur accord. La déclaration de confidentialité actuelle de Marriott àhttps://www.marriott.com/about/privacy.midécrit les transferts mondiaux, les mécanismes de transfert, les engagements de sécurité et de conservation dans l'activité actuelle. Elle ne prouve pas l'architecture Starwood de 2014-2018, mais elle illustre pourquoi un groupe hôtelier mondial ne peut pas traiter un emplacement de base de données unique comme la seule réponse de gouvernance.

La souveraineté des données dans un système de réservation a plusieurs couches. La localité de stockage demande où se trouvent la base de données principale, les répliques, les sauvegardes, les exportations, les journaux et les images forensiques. La localité d'accès demande quels employés, sous-traitants, exploitants d'hôtels et prestataires de services peuvent atteindre les données et d'où. La localité juridique suit les clients, les hôtels, les responsables du traitement, les sous-traitants, les accords de franchise et la portée réglementaire.

La localité commerciale suit la signification d'un séjour: dates de voyage, compagnons, drapeaux VIP, détails des compagnies aériennes, besoins de chambre et destination.

La violation de Starwood montre qu'une base de données basée aux États-Unis peut toujours créer une exposition réglementaire mondiale et un préjudice mondial pour les clients. Elle montre également pourquoi la diligence d'acquisition doit cartographier les copies et les accès, pas seulement le stockage principal. Un acheteur qui sait où se trouve le système principal mais pas qui peut exporter des tables ou quels champs de passeport sont protégés a une connaissance de l'emplacement sans connaissance du contrôle.

L'économie de l'abus de contact dans les données de voyage

Les données exposées n'avaient pas besoin d'inclure des mots de passe ou des numéros de carte complets pour réduire le coût de l'abus. Un enregistrement de réservation peut rendre un message crédible. Il peut mentionner une marque d'hôtel, une date de séjour, une relation de fidélité, une destination de voyage, un détail de vol, une préférence de chambre, un indice de composition familiale ou une préférence de communication. Ce contexte aide un escroc à paraître moins générique.

Les conseils de la CISA sur le hameçonnage àhttps://www.cisa.gov/sites/default/files/2024-02/Update%20to%20Phishing%20General%20Security%20Postcard_01.01.2024.pdfdécrivent le hameçonnage ciblé comme utilisant des informations clés sur une personne. Les conseils aux consommateurs de la FTC concernant Marriott àhttps://consumer.ftc.gov/consumer-alerts/2018/12/marriott-data-breachont mis en garde les consommateurs contre les escroqueries qui pourraient exploiter la violation. Les conseils d'IdentityTheft.gov àhttps://www.identitytheft.gov/databreachfournissent des étapes générales de réponse en cas d'exposition d'informations personnelles. Ces sources ne prouvent pas qu'un client spécifique a subi une escroquerie particulière. Elles soutiennent le chemin de risque créé par les catégories de données.

Les données de voyage ont également un contexte personnel au-delà de la fraude. Les dates d'arrivée et de départ peuvent révéler une absence du domicile, des voyages d'affaires, des voyages médicaux, des visites familiales ou des relations. Les numéros de passeport sont des identifiants durables. Les informations de fidélité peuvent relier les séjours au fil du temps. Un drapeau VIP ou une demande de chambre peuvent révéler des attentes de service ou des circonstances familiales. L'économie de l'abus de contact appartient donc à l'analyse d'impact même lorsque la fraude à la carte n'est pas établie.

La question de la minimisation des données s'ensuit. Combien de temps les anciennes données de réservation doivent-elles rester dans les systèmes en production? Quels champs sont nécessaires après le départ, après le crédit de fidélité, après les fenêtres de litige, après les périodes fiscales ou après les conservations légales? Quels champs peuvent être tokenisés, masqués, supprimés ou séparés? Les sauvegardes et les exportations ont besoin de la même logique de conservation que la production.

Sinon, une base de données héritée peut conserver des données parce qu'elle reste opérationnellement pratique, et non parce que chaque champ reste nécessaire.

Une note typographique pour les enregistrements de risques hérités

Les enregistrements de sécurité des systèmes acquis doivent être lisibles à la fois par les dirigeants, les ingénieurs, les avocats, les prestataires de services et les régulateurs. Des conclusions denses peuvent cacher des lacunes décisives. Le bloc typographique suivant est inclus parce que la présentation du risque hérité affecte la capacité des responsables du contrôle à voir ce qui doit changer.

La typographie est l'art et la technique d'agencer les caractères pour rendre le langage écrit lisible, compréhensible et visuellement attrayant. Elle implique le choix des polices, des tailles de points, des longueurs de ligne, de l'interlignage et de l'espacement des lettres.

• La typographie est née avec l'invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés comprennent le choix de la police, le crénage, l'approche et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.

Pour une acquisition, des enregistrements lisibles signifient une carte de frontière d'une page qui sépare les faits connus, les déclarations du vendeur, les affirmations non vérifiées, les tests requis, les actions sur les identifiants, les copies de données, le statut cryptographique, les obligations des prestataires de services et les dates de mise hors service. Si ces éléments sont enfouis dans les documents de transaction et les exportations d'outils, l'organisation peut croire qu'elle a accepté un risque sans savoir quel risque elle a accepté.

Responsabilité par le contrôle pratique

L'attaquant contrôlait l'intrusion non autorisée, la persistance, l'utilisation abusive des identifiants et l'exportation des données. Aucun dossier public examiné ici n'identifie l'attaquant ou ne statue sur un motif ou une affiliation étatique. La responsabilité de l'accès criminel incombe à l'acteur ou aux acteurs qui l'ont perpétré.

Starwood contrôlait l'environnement lorsque la compromission initiale s'est produite. Elle possédait ou exploitait les systèmes, les identifiants et la surveillance qui ont permis à l'attaquant d'entrer et de persister avant l'acquisition de Marriott. Elle a également porté l'historique de la violation antérieure des terminaux de point de vente dans la transaction. Cela ne prouve pas que Starwood était au courant de l'intrus dans la réservation. Cela signifie que l'environnement caché était l'objet de confiance du côté du vendeur.

Marriott contrôlait l'environnement post-clôture et le plan de migration. Une fois qu'elle était propriétaire de Starwood, elle contrôlait si les identifiants hérités étaient réinitialisés, les comptes privilégiés surveillés, les alertes de base de données élargies, les systèmes critiques renforcés, les champs de passeport évalués, les déclarations cryptographiques vérifiées et la trajectoire de mise hors service accélérée ou atténuée. Marriott contrôlait également la notification aux clients et les mises à jour publiques après la découverte. Son contrôle était limité par la continuité des activités et l'échelle, mais pas absent.

Les prestataires de services contrôlaient les opérations gérées, les alertes et l'escalade à leur frontière. Le rôle d'Accenture dans la gestion de la base de données et l'escalade de l'alerte Guardium montre pourquoi les opérations de tiers doivent avoir des seuils d'incident clairs, un transfert de preuves et une autorité du responsable du traitement. Un prestataire de services peut être un détecteur précoce. Le responsable du traitement doit toujours décider de la notification, de la délimitation de l'étendue et de la remédiation.

Les régulateurs contrôlaient la correction exécutoire. La pénalité de l'ICO, l'accord des États et l'ordonnance de la FTC ont traduit les leçons de sécurité en obligations. Ils ne prouvent pas toutes les réclamations privées. Ils indiquent clairement que l'acquisition ne gèle pas la responsabilité à l'état de la connaissance avant la clôture. La propriété entraîne l'obligation de tester et d'améliorer les contrôles hérités.

Les clients contrôlaient très peu de choses. Ils réservaient des chambres, adhéraient aux programmes de fidélité, fournissaient des données de passeport et de contact et comptaient sur les opérations hôtelières. Ils pouvaient surveiller les cartes ou répondre aux avis après coup. Ils ne pouvaient pas inspecter la surveillance de la base de données de Starwood, renouveler les identifiants privilégiés, vérifier les déclarations de chiffrement ou accélérer la mise hors service du système. Cette asymétrie est la raison pour laquelle cela figure dans un dossier de responsabilité.

Ce qu'exigerait une intégration vérifiable

La leçon de réparation n'est pas « ne jamais acquérir de systèmes hérités ». C'est que l'intégration d'acquisition doit inclure une recherche de la vérité sécuritaire avec des preuves.

Un acheteur doit classer les systèmes hérités à haut risque avant la clôture, puis commencer la vérification post-clôture immédiatement: réinitialisation des identités privilégiées, examen des accès des prestataires de services, chasse aux points finaux et aux serveurs, journalisation des exports de base de données, comparaison de la couverture des contrôles, inventaire cryptographique, examen de la conservation des données, cartographie des sauvegardes et évaluation des risques de migration.

Pour une base de données de réservation, les preuves doivent être au niveau des champs et des copies. Quelles tables contiennent des numéros de passeport? Lesquelles contiennent des restes de cartes de paiement? Lesquelles contiennent des compagnons de voyage, des enfants, des identifiants de fidélité et des préférences de communication? Quels champs sont en clair, chiffrés, hachés ou tokenisés? Quelles applications peuvent les demander? Quels utilisateurs peuvent les exporter? Quels journaux montrent des copies de tables complètes? Quelles sauvegardes les conservent? Quelle finalité juridique ou commerciale justifie la conservation?

Pour la confiance des tiers, l'acheteur doit savoir quels prestataires gèrent le système, quelles alertes ils reçoivent, quels seuils nécessitent une escalade, quels journaux ils conservent, quels identifiants ils détiennent, comment les sous-traitants sont gouvernés et comment le responsable du traitement peut obtenir des preuves après une violation suspectée. Un rapport de fournisseur ne suffit pas s'il ne peut pas être lié au système et aux catégories de données spécifiques.

Pour la notification, l'organisation doit être capable de produire une explication spécifique au client: quels champs, quelle période, quelle source d'enregistrement, quelles mesures de protection, quelle incertitude demeure et quelles mises à jour suivront. Un avis général peut être nécessaire au début, mais une correction ultérieure doit être attendue lorsque les décomptes, les champs ou les faits cryptographiques changent.

La mise hors service n'est pas la même chose que la suppression du risque

Le plan de Marriott de mettre hors service la plateforme de réservation de Starwood était commercialement et opérationnellement important. La mise hors service peut être un contrôle fort: elle réduit la surface d'attaque en direct, force la migration vers une plateforme mieux gouvernée et peut mettre fin à la dépendance aux identifiants et outils hérités. Mais la mise hors service n'est pas une suppression instantanée du risque. Un système programmé pour l'arrêt peut rester hautement sensible tant qu'il traite encore des réservations, prend en charge les hôtels et contient des enregistrements historiques.

La migration de deux ans décrite par Marriott a créé une période de transition. Pendant cette période, la plateforme héritée avait encore besoin de surveillance, de renforcement, d'examen des identifiants, de journalisation des exports et de minimisation des données. Une date de mise hors service ne justifie pas des contrôles plus faibles avant l'arrivée de cette date. Dans certains cas, cela peut créer le risque inverse: les équipes peuvent hésiter à investir dans les contrôles d'un système qu'elles s'attendent à décommissionner, tandis que les attaquants bénéficient de la fenêtre restante.

Un plan de mise hors service sécurisé devrait avoir des jalons au-delà de « cesser d'utiliser le système pour les opérations commerciales ». Il devrait identifier les sauvegardes, les répliques, les exportations, les images forensiques, les comptes administrateur, les comptes de service, les accès des fournisseurs, les clés de chiffrement, les magasins de journaux, les flux de données et les copies en aval. Il devrait décider ce qui doit être conservé pour des raisons juridiques ou commerciales et ce qui doit être supprimé ou transformé. Il devrait vérifier que les identifiants décommissionnés ne peuvent toujours pas atteindre les archives.

Il devrait conserver les preuves nécessaires aux litiges ou à l'examen par les régulateurs sans laisser de données inutiles exposées.

Le cas Starwood montre pourquoi cela est important. La base de données de réservation en direct aurait été mise hors service d'ici la fin 2018, mais l'enquête sur la violation, les actions réglementaires, les recours collectifs, les accords des États, l'ordonnance de la FTC et la correction cryptographique se sont poursuivis pendant des années. Un système peut quitter la production et rester central pour la responsabilité. Le dossier de ce qu'il contenait, qui y a eu accès, comment il était protégé et comment les copies ont été gérées devient la base de preuves pour toute procédure ultérieure.

La mise hors service interagit également avec les droits des clients. Si un client demande quelles données étaient impliquées, la réponse ne peut pas disparaître avec l'ancienne plateforme. Si un régulateur demande pourquoi un champ a été conservé ou comment il était protégé, l'organisation a besoin d'enregistrements après la migration. Si une entreprise corrige ultérieurement une description cryptographique, elle doit comprendre l'ancien comportement de l'application et les valeurs stockées suffisamment bien pour expliquer la correction.

Le décommissionnement sans conservation des preuves de contrôle peut rendre plus difficile la recherche ultérieure de la vérité.

La gestion cryptographique est un contrôle de gestion

La correction AES-à-SHA-1 est souvent traitée comme une note technique. Il est préférable de la comprendre comme un signal de contrôle de gestion. La cryptographie ne protège les personnes que lorsque l'organisation sait quelle protection est réellement appliquée. Cette connaissance doit survivre aux fusions, aux opérations des fournisseurs, aux applications héritées, aux avis publics et aux litiges.

Un inventaire cryptographique au niveau des champs devrait répondre à plusieurs questions. Quel champ est protégé? La transformation est-elle un chiffrement réversible, un hachage à sens unique, une tokenisation, un masquage, une troncature ou une autre méthode? Quel algorithme et quel mode sont utilisés? Des sels ou des clés sont-ils présents? Où sont stockées les clés ou les secrets? Quelle application peut demander la valeur d'origine? Quels journaux montrent l'utilisation? Quelles anciennes versions utilisaient une méthode différente? Quels avis ou politiques décrivent la protection?

Qui a le pouvoir de certifier la déclaration avant qu'elle ne soit publiée?

Dans un système acquis, ces réponses peuvent être dispersées dans les documents du vendeur, le code, les paramètres de base de données, les notes des fournisseurs, la mémoire des développeurs et les anciens rapports de conformité. L'acheteur doit supposer que les étiquettes peuvent être erronées jusqu'à ce qu'elles soient testées. « Protégé » ne suffit pas. « Chiffré » ne suffit pas. Un nom de champ se terminant par token ou hash ne suffit pas. La preuve nécessite l'inspection des valeurs stockées, des appels d'application, des services de clés et des chemins de récupération.

La conclusion relative aux numéros de passeport renforce le même point. Le problème n'était pas seulement que des millions de numéros de passeport n'étaient pas chiffrés. C'est que Marriott manquait d'une évaluation documentée des risques expliquant pourquoi certains numéros de passeport étaient traités différemment des autres. La protection sélective peut être rationnelle. Elle peut refléter des contraintes héritées, un besoin commercial ou une migration par phases. Mais elle doit être documentée et examinée en fonction des conséquences de l'exposition. Sinon, une protection inégale ressemble à un accident plutôt qu'à une décision de risque.

La gestion cryptographique affecte également la qualité des avis. Si une organisation dit aux gens que leur valeur de carte ou de passeport a été chiffrée, la personne peut raisonnablement inférer un risque différent que si la valeur a été hachée avec SHA-1 ou laissée non chiffrée. Si l'organisation modifie ultérieurement cette description, la correction doit dire ce qui a changé, quelles valeurs sont affectées, ce que cela signifie pour l'abus et quelle incertitude demeure. Ce n'est pas simplement de l'hygiène de communication. Cela fait partie de la gestion responsable des données d'identité.

Le manuel d'acquisition devrait nommer les inconnues

La culture des transactions récompense la confiance. L'intégration de la sécurité a besoin d'une liste d'inconnues. L'acheteur doit savoir quelles parties de l'environnement hérité sont vérifiées, lesquelles sont déclarées par le vendeur, lesquelles sont supposées pour la continuité des activités et lesquelles restent non testées. Un registre des risques qui étiquette une inconnue comme un risque accepté est plus fort qu'un mémo de diligence qui cache l'inconnue derrière de larges assurances.

Pour une plateforme de réservation mondiale, les inconnues devraient inclure les copies de données, les comptes privilégiés, les accès des prestataires de services, les systèmes exposés à l'extérieur, les anciens artefacts de violation, les logiciels non pris en charge, les lacunes de journalisation, le statut cryptographique et la conservation. Chaque inconnue devrait avoir un responsable et une date. Certaines seront résolues par la migration. Certaines auront besoin de contrôles compensatoires pendant que le système reste en production. Certaines peuvent devenir inacceptables une fois que l'acheteur comprend le volume de données.

Cette approche protège également l'acheteur contre le recul rétrospectif. Elle reconnaît que tous les faits ne peuvent pas être connus avant la clôture. Elle crée ensuite une obligation post-clôture de réduire l'incertitude. L'échec n'est pas l'incapacité de tout savoir le premier jour. L'échec est de laisser l'incertitude du premier jour devenir l'incertitude de la deuxième année alors que le système hérité continue de détenir des données de clients.

La qualité de la notification dépend de la qualité de l'intégration

La notification aux clients est souvent traitée comme un problème de délai légal. L'incident Starwood montre que la qualité de l'avis dépend de la qualité de l'intégration bien avant que la violation ne soit confirmée. Si l'organisation ne sait pas quelles tables contiennent quels champs, comment les doublons correspondent aux personnes, combien de numéros de passeport sont en clair, quelles valeurs sont protégées et quels enregistrements appartiennent à quelles régions, alors l'avis sera soit large, soit tardif, soit corrigé, soit les trois.

Le premier avis de Marriott a utilisé des plafonds prudents parce que les enquêteurs étaient encore en train de classer les enregistrements et les doublons. Cela peut être inévitable dans un grand système hérité. Mais la leçon de contrôle à long terme est que des catalogues de données clients devraient déjà exister pour les systèmes à haut risque. Ils devraient décrire la finalité du champ, la sensibilité, la région, la conservation, l'état cryptographique, les rôles d'accès et les chemins d'exportation. Ils devraient être rapprochés du contenu réel de la base de données, pas seulement de la documentation de l'application.

Cela affecte également les régulateurs. Un régulateur évaluant le délai de notification ou son adéquation a besoin de savoir quand le responsable du traitement a pris conscience que des données personnelles étaient impliquées et quels faits étaient raisonnablement disponibles. Si le processus d'intégration du responsable du traitement ne peut pas distinguer une table de compte d'une table de passeport ou un enregistrement en double d'un client unique, alors l'analyse juridique s'emmêle avec la dette technique. Une meilleure intégration réduit à la fois la confusion lors des incidents et l'incertitude juridique ultérieure.

Le même principe s'applique aux corrections publiques. La mise à jour de Marriott en 2024 concernant SHA-1 était matériellement différente de la description de chiffrement d'origine. Une correction des années plus tard peut être l'acte responsable une fois qu'un fait est connu, mais elle montre aussi que la chaîne de preuves d'origine n'était pas assez solide. Un programme de sécurité post-acquisition devrait inclure une règle selon laquelle les descriptions cryptographiques publiques sont vérifiées par les responsables techniques avant l'avis et périodiquement réexaminées si les preuves héritées changent.

Dépendance au cloud dans l'hôtellerie

Le manifeste classe partiellement ce cas comme une dépendance aux services cloud parce que la plateforme de réservation fonctionnait comme une infrastructure partagée pour une entreprise hôtelière mondiale, même si ce n'était pas un cloud public au sens moderne. Les hôtels, les centres de contact, les services de fidélité, les prestataires de services gérés et les équipes d'entreprise dépendaient tous de la disponibilité et de l'intégrité d'une plateforme centrale. Cette plateforme concentrait les données de nombreuses propriétés et juridictions.

Cette dépendance est la raison pour laquelle la violation a affecté plus que le propriétaire corporatif. Les franchisés, les hôtels gérés, les clients, les équipes de cartes de paiement, les détenteurs de passeport, les membres de fidélité, les régulateurs et les prestataires de services avaient tous un intérêt dans le même système hérité. Un hôtel local ne pouvait pas inspecter la surveillance de la base de données. Un client ne pouvait pas savoir si les champs de passeport étaient chiffrés.

Un prestataire de services pouvait escalader une alerte, mais seul le responsable du traitement pouvait coordonner la notification aux clients et la réponse mondiale.

Pour la planification des acquisitions, le contrôle pratique est la cartographie des dépendances. Quelles fonctions commerciales s'arrêtent si la plateforme de réservation héritée est isolée? Quels hôtels en dépendent encore? Quels flux de données continuent pendant la migration? Quels tiers peuvent y accéder? Quels engagements clients en dépendent? Un acheteur qui ne cartographie que les composants technologiques manque la pression commerciale qui peut maintenir un système risqué en vie. Un acheteur qui cartographie les dépendances peut justifier des contrôles compensatoires pendant que la migration progresse.

L'évaluation finale est un impact élevé et une confiance élevée. Marriott a hérité d'une plateforme de réservation en production et compromise. Ce fait ne fait pas de Marriott l'intrus initial ni ne prouve qu'il aurait pu connaître chaque détail avant la clôture. Cela rend Marriott responsable de la période post-clôture pendant laquelle il contrôlait le système acquis, traitait les données des clients et devait transformer la confiance des tiers en un contrôle vérifié. L'acquisition peut acheter une marque du jour au lendemain. Elle ne peut pas acheter la certitude. La certitude doit être construite, testée et démontrée.