この攻撃は当初、チェーンのゲスト予約データベースに5億件のレコードを公開したと考えられていましたが、その後の調査により、その数値が下方修正されました。
公開されたデータには、暗号化せずに保存された525万人のゲストのパスポート番号、1850万の暗号化されたパスポート番号、910万の暗号化されたクレジットカード番号が含まれていました。
公共の傷害に侮辱を加え、ICOはマリオットの罰金を当初の信号値である9,900万ポンドから5分の4に削減し、その後、繰り返しかかとを引きずりました。
情報コミッショナーのエリザベス・デナム氏は、「企業が顧客のデータの管理に失敗した場合、その影響は罰金の可能性があるだけでなく、最も重要なのは、データを保護する義務がある一般市民です」と述べています。
（The Register記事より引用）※機械翻訳
キタきつねの所感
マリオットは不正行為に対する2019年7月の巨額の罰金提示（9,900万ポンド）を拒否していましたが、規制当局側が、マリオットのインシデント対応（調査への協力）と、COVID-19のビジネスの経済的影響を考慮して、当初の罰金額を1/5に減額した形となりました。
GDPRは2018年5月発効で、この事件は2014年から侵害が開始されて2018年9月まで検出されなかった事件だったので、GDPRの巨額なペナルティの対象なのかという観点でも当時議論がありました。
※2018年5月からのGDPR違反部分を対象とした罰金という形になっている様です。
最終的な罰金額1,840万ポンド（約25億円）は、巨額な罰金額ではありますが、コロナの影響を受けて規制当局が割引したという部分には、少し違和感がありました。（それで企業の業績が傾いたら元も子も無いと考えたのだとは思いますが）
GDPRの怖い罰金判例はさて置き、Registerの記事には、私自身が知らなかった事件の詳細が書かれていました。これは、10/30に出されたICO（※英国の規制当局）の通知書から引用したものの様です。
スターウッドは2016年にマリオットに買収されましたが、買収したチェーンのシステムは、買収後にマリオットが閉鎖されるまで、マリオット自身のIT資産から分離されたままでした。
身元不明の悪意のある人々が、2014年7月にスターウッドホテルのネットワーク内のマシンにWebシェルを忍び込みました。その後、そのシェルを使用して、スターウッドのシステムとパスワードを大量に消費するオープンソースツールMimikatzにさまざまなリモートアクセストロイの木馬（RAT）を植え付けました。攻撃者は、より多くのネットワークアカウントを侵害していました。
これらのアカウントには、多要素認証のないアカウントと、主要なデータベースの管理者資格を持つアカウントが含まれていました。それでも、攻撃者の行動は見過ごされていました。
（The Register記事より引用）※機械翻訳
今までこうした詳細経緯は表に出てきてなかったかと思います。この通知書、91ページにも及ぶのですが、色々細かく（一部詳細は黒塗りで）書いてます。
引用（機械翻訳）しようと思ったのですが、PDFが画像化（文字をコピーできない）されて構成されているので、パッと読んで大事そうな所だけ拾ってみます。
※PCI関係の方は読んでみると色々面白い事が書かれていて勉強になります。
※（普通の方は）上のRegisterの記事を見れば概要理解としては十分かと思います。
攻撃の経緯の所ですが、侵入の部分は上の記事にも書かれていますが、Webシェル→RATだった様です。記事には、最終的にどうやってマリオット側が事件に「気づいたか」の所までが順を追って書かれています。
2015年4月以降、何度かハッカーの攻撃の痕跡があるのですが、6回目の攻撃で（2018年9月）でようやく検知できています。
なかなか検知出来なかった理由の１つが、正規の認証情報(管理者含む）が窃取されて攻撃されている点と、テーブルの全データコピーが監視ソフト（Guardium）のアラート対象外だった事、そしてメモリスクラッピングマルウェア（2017/1）を仕掛けられた事を検知出来ていなかった事にありそうですが、最後にソフトが検知できたのは、テーブルが何行あるかをハッカーが調べようと数えた際に、保護対象であるカード情報が含まれていたので（ギリギリ）検知できたようです。
マリオットのITチームと契約してスターウッドのゲスト予約システムを管理していたAccentureは、2018/9/8ソフトの前日のアラートを見て調査に入りますが、マリオットがスターウッドを買収してから初めての（Guardiumの）アラートだった様です。
しかし、皮肉な事に、最後の成果物であるデータファイルは、2018/9/10と調査に入って2日後に外部にエキスポートされてしまいます。ここで再度Guardiumがアラートを出し、”事故”である事をマリオットが認識する事になります。
買収したスターウッドのシステムが元々侵害を受けていた事に起因する事件なのですが、買収時のセキュリティチェック（自社セキュリティ体制への切替）が甘かったという事が、あったのかと思います。
更に皮肉な事に、、、ゲスト予約システムを管理していたAccentureの従業員アカウントもこのデータ侵害事件で悪用されていた事が判明します。
事件を引き起こした原因（脆弱点）についても、この通知書では書かれています。
PCI DSS（カード情報漏えい側）視点では、PCI DSSの監査（QSA監査）を通っていたとは言え、この分析では、多要素認証がカードデータ環境（CDE）に対する全てのアカウントとシステムアクセスで実施されていなかった事が指摘されています。
この点についてマリオットは、QSAが問題無いと判断した事を持って抗弁した様ですが、最終的に多要素認証の穴（ミス）があったと判断された様です。
フォレンジック（事故）調査は、Verizonが実施した様で、この辺りでは、ログ監視についての不備が書かれています。読んでいくと、マリオット側は自社で実施してる年次の侵入テスト結果を持っていたのですが、ログ（監視）設定について適切であるかどうかは、こうした脆弱性テストではチェックされてなかったと書かれています。
PCI DSSの専門家の1人として考えると、正直に言えば、ここは判断が結構難しい所です。おそらく非常に巨大なシステムだったと思いますので、私も監査等で提示される一部の証跡だけでチェックしていたとすれば、（ログのスコープの妥当性に気づかず）問題無いと判断したかも知れません。
フォレンジック調査の結果から言えば、ログチェックすべき点が抜け落ちていた、PCI DSS認定を継続している他社にとっても意識しておくべき点です。
ログの問題点について、（フォレンジック調査の結果として）2点指摘されています。
最大のポイントは、データーベースにおける重要アクションが監視（ログ記録）対象外であった事です。
2点目は、データベースから全てのデータがダンプファイルとして持ち出される（生成される）部分について防御（＝制限又は監視）してなかった点です。データベース全体の持ち出しは、2015年の段階からされていた様ですので、ここが制限または監視されていたとすれば、ここまで大型の漏えい事件にならずに抑え込めた可能性があります。
もう1か所、上のポイントの方が原因（脆弱ポイント）として大きいのですが、ここも監視しておくべきだったのでは、と思ったのが、データベースの暗号化されたテーブルへスクリプトでのアクセスです。
メンテナンス等の理由で、正常命令である事もあるかと思いますが、（クレジットデータを含む）データベースの全データを要求する様なスクリプト動作について、何も監視せず、アクセス出来ていた所は、やはり問題だったのかと思います。
もう少し面白い内容がありそうな（歯ごたえがありそうな）通知書PDFですが、久々に英語をまじまじと読んで疲れてしまったのと、恐らく誤訳のボロが（普段機械翻訳を使いすぎなので・・・）出てきてしまうかと思いますので、この辺にしておきます。