前回記事に引き続き決済代行会社のメタップスペイメント社への不正アクセス事件についてPCI DSS（専門家）の視点でこの事件を考えてみます。
※関連記事
メタップスペイメントへの不正アクセス事件を考えてみた その１（セキュリティコード）
メタップスペイメントへの不正アクセス事件を考えてみた その２（侵害検知）
【限定】メタップスペイメントへの不正アクセス事件を考えてみた その３（ASVスキャン）
【限定】メタップスペイメントへの不正アクセス事件を考えてみた その４（時系列）
メタップスペイメントへの不正アクセス事件を考えてみた その５（インシデント対応）
公式発表
・不正アクセスによる情報流出に関するご報告とお詫び（2/28）[魚拓] ※第2報
・不正アクセスに関するご報告とお詫び（1/25）[魚拓] ※第1報
キタきつねの所感
※お断り：私自身はPCI DSSに関する専門家（有資格者）の1人ですが、メタップスペイメント社の審査やフォレンジック調査、コンサル業務等には一切携わっておりません。本記事に記載の内容は、メタップスペイメント社が公開した情報や関連報道等を元に、第三者の立場として推測した内容となります。今後のマスコミ等の報道内容や、メタップスペイメント社が4月以降に発表する可能性がある最終報告内容と合致しない可能性もありますので、その旨ご了承下さい。
■事件を検知できなかったメタップスペイメント
公式発表を読んでまず気づいたのが、2021年8月の攻撃が発生してからメタップスペイメント社が攻撃を検知出来なかった事です。カード情報漏えいに”最初に誰が気づいたのか？”というのは、事件規模に関わる非常に重要な点なのですが、今回の事件の場合はメタップスペイメントではなく「クレジットカード会社」からの連絡で情報漏えいが発覚しています。
2021/12/14
クレジットカード会社より弊社提供サービス「イベントペイ」での不正利用懸念の連絡を受領
攻撃の細かい経緯は発表されていませんので、約4か月攻撃を検知出来なかったメタップスペイメント社にどの程度の問題があったのかを判断する事は出来ませんが、PCI DSSの観点では「多層防御が上手く働かなかった」事に他ならず、メタップスペイメント社のセキュリティ対策に”想定外”が発生してしまった可能性を強く感じます。
PCI DSS基準では、侵害を想定した規定がいくつもあり、多層防御でセキュリティ侵害に対抗する（影響を最小化する）設計思想になっています。
今回の不正アクセスを防げた可能性がある要件をざっと考えてみると、FW（要件1）、IDS/IPS（要件11.4）、WAF（要件6.6）、ファイル整合性監視（要件10.5.5）、ログレビュー（要件10.6）等が挙げられます。
中でもログレビュー（要件10.6）は、全てのセキュリティ関連のログを日次でチェックする（要件10.6.1）事が要求されているのですが、普通だとここで引っかかる”はず”の規定となっています。
10.6.1毎日一度以上以下をレビューする
・すべてのセキュリティイベント
・CHD や SAD を保存、処理、または送信するすべてのシステムコンポーネントのログ
・すべての重要なシステムコンポーネントのログ
・すべてのサーバとセキュリティ機能を実行するシステムコンポーネント（ファイアウォール、侵入検出システム/侵入防止システム（IDS/IPS）、認証サーバ、電子商取引リダイレクションサーバなど）のログ
逆に言えば、要件10.6.1で今回の侵害アクティビティが”何も引っかからなかった”場合、設定ミスやログの確認手法に問題があった様な人為的ミスを除いて、何らかの”想定外”が発生した可能性が高いと思います。
※ゼロディ脆弱性を含む攻撃だった場合、こうしたセキュリティ対策を潜り抜けられてしまう事も想定されますが、公式発表を見る限りAPT攻撃だったと判断できる内容は書かれていない様に思えます。本来どこかの対策で、少なくてもログにはその痕跡が残っている”べき”なのですが、ログの見落とし、またはログを取っていない経路（勝手口・裏口）を想定外で攻撃されたと考えた方がしっくりきます。
今回の侵害原因について公式発表では、以下の3点と説明されておりますが、
① 社内管理システムへの不正ログイン
② 一部アプリケーションへのSQLインジェクション
③ 不正ファイル（バックドア）の設置
（第2報より引用）
普通に考えると、原因②のSQLインジェクションはWAFで防げるはずです。
PCI DSSの要件6.6では「既知の攻撃≒SQLインジェクションから確実に保護する」事が要求されており、メタップスペイメント社の様な規模で多岐に渡る決済サービスを提供している企業の場合、WAFを導入するのが一般的かと思います。
要件6.6
一般公開されているWebアプリケーションで、継続的に新たな脅威や脆弱性に対処し、これらのアプリケーションが、次のいずれかの方法によって、既知の攻撃から保護されていることを確実にする。
・一般公開されているWebアプリケーションは、アプリケーションのセキュリティ脆弱性を手動/自動で評価するツールまたは手法によって、少なくとも年 1 回および何らかの変更を加えた後にレビューする 注： この評価は、要件 11.2 で実施する脆弱性スキャンとは異なる。
・ Web ベースの攻撃を検知および回避するために、一般公開されている Web アプリケーションの手前に、Webベースの攻撃を自動的に検出・防止する技術的な解決策（Webアプリケーションファイアウォールなど）をインストールする。
無論、要件では必ずWAF導入をしろとは書かれておらず、他の代替手段によって「確実に保護する」事を実現しても良いのですが、既知の脆弱性の代表格であるSQLインジェクションを素通りさせる代替手段があるか？と考えると非常に疑問です。
こうした事態を引き起こす原因として考えられるのが、例えばWAF等の設定ミスに気付かなかったといったケースですが、要件6.6のガイダンスでは、設定ミスなどのレビューを「アプリケーションのセキュリティを専門とする組織」がレビューする事が求められており、こうしたミスが起きる事自体が「確実に保護する」のに失敗している事に他ならず、規定違反の状態となります。
しかし、メタップスペイメント社及び審査会社（QSAC）がこの要件を見落とすとは（あまり）想像ができないので、WAF等は導入していた中で「想定外」が発生した可能性を感じます。
第2報では攻撃が「複合的に行われた」と説明されていますが、
攻撃は、2021年8月2日から2022年1月25日にわたって以下の事項が複合的に行われ、決済情報等が格納されているデータベースにまで達し、個人情報を含む情報が外部に流出したことが判明いたしました。
（第2報より引用）
事件の原因の中に、普通のカード情報漏えい発表ではあまり見る事のない原因が１つ混じっていて、ここが”想定外”を引き起こした可能性を感じます。それが「社内管理システム」です。
① 社内管理システムへの不正ログイン
不正ログイン対策として、ログイン認証方式の強化を実施しております。また、不正ログインを起因とした同一環境下への影響を防止するため、システム環境の分離を完了しております。
（第2報より引用）
「社内管理システム」について公式発表では説明が全くないのですが、文字を素直に読むと、システム管理者のみがアクセスできるメタップスペイメント社内部のシステムであると思われます。
特権IDの接続経路が各種のセキュリティ対策を「バイパス」していた・・・メタップスペイメント社が最初に挙げている事を考えると、あり得ない話ではなさそうです。
上記の「社内管理システム」ではありませんが、メタップスペイメント社の「イベントペイ」での管理画面（ユーザ用）の説明ページがありました。
このユーザ向けの画面例、及びメタップスペイメント社が対策済として説明している「不正ログイン対策として、ログイン認証方式の強化を実施しております」を併せて考えると、
強化策が”ログイン認証方式”の強化とある事から、「社内管理システム」が外部からアクセス可能であり、1要素認証であった（≒多要素認証ではなかった）可能性を強く感じます。
※2要素認証が既に導入済の場合は、不正アクセスの耐性がかなり高いと思いますので（ゼロディ攻撃や設定ミス等を除き）”ログイン認証方式”の強化という書き方にはならないと思います。他に考えられる強化策としては、パスワードリスト攻撃等のツール攻撃の防御としてCAPTCHA認証ツールが考えられます。「強化」が、こうした対策を指しているのであれば、管理者のログイン認証を潜り抜けた事によって、本来想定してない所（例えばWAFの先）まで侵入された可能性が現実味を帯びてきます。
仮に管理者アクセスという部分から、カード会員データ環境（CDE）にリーチされたのだとすると、PCI DSSの要件8.3に違反していた可能性も考えられます。
8.3
CDE に対する、すべての非コンソール管理アクセス、ならびにすべてのリモートアクセスについて、多要素認証を使用して安全に保護する。
侵害を受けたメタップスペイメント社の『社内管理システム』は、カード会員データ環境とネットワークが分離された為に、要件8.3の対象外として1要素認証にしていた事も想像されますが、その場合、何らかの形でネットワーク分離されている”はずの”ネットワークが繋がっていた事となりますので、今度はセグメンテーションミスが疑われ、今度は要件11.3（侵入テスト）に違反していた可能性があります。
11.3
少なくとも以下を含むペネトレーションテスト方法を開発し、実装する。
・業界承認のペネトレーションテスト方法（NIST SP800-115 など）に基づいている
・ CDE 境界と重要システム全体を対象とした対応を含める
・ネットワークの内部と外部からの侵入テスト
・セグメンテーションと範囲減少制御の有効性テストを含める
公式発表における事件の原因説明（1.本件の概要）では、この仮説を裏付ける様な記述があります。
また、不正ログインを起因とした同一環境下への影響を防止するため、システム環境の分離を完了しております。
対策内容から、「社内管理システム」に対しシステム環境の分離が必要だった読み取れます。つまりカード会員データ環境（CDE≒PCI DSSスコープ）の対象外と考えていた「社内管理システム」が、実はきちんとセグメンテーション（NW分離）されておらず、このルートから攻撃者にカード会員データ環境（CDE）に横移動（ラテラルムーブメント）された事が推定されます。
もしここが”想定外ルート”だったとすると、「社内管理システム」の認証ログ（失敗、成功・・・）が取られてなかった、又は要件10.6.1のログ日次レビューの「対象から除外されていた」事によって侵害検知に失敗した事が考えられます。
PCI DSSに準拠していたからと言って、全ての攻撃を防げるという事は当然無いのですが、外に繋がっている”接続口”（認証アクセス）がカード会員データ環境（CDE）に影響を与えるかも知れないという視点で本来評価すべき所が漏れていた、あるいは対策（ログ監視対象）が不十分だった事が主な原因だったのだとすれば、このインシデントは防げた可能性がある気がしてなりません。
尚、初期侵入が成功してしまった要因はいくつか考えられますが、私はセグメンテーションの失敗、に対するチェック不備（要件11.3）が最大の要因（ミス）だった可能性が高いと考えます。
※長くなりそうなので何回かに分けて投稿します
（次回以降はサブスク記事とする予定です）
本日もご来訪ありがとうございました。
Thank you for your visit. Let me know your thoughts in the comments.
更新履歴
