デンマークに本社があるサクソバンク証券が、7月の個人情報漏えい事件の件で金融庁から業務改善命令を受けましたが、この内容を見ると金融資産や個人情報は2要素認証が導入されていても不十分な時代になりつつある様です。
公式発表
キタきつねの所感
7月に発生したサクソバンク証券の個人情報漏えい事件について、詳細は公式発表（9/17調査結果）をご覧いただくと良いかと思います。
概要だけ書きますと、外部ベンダーが開発した入出金ツールが不正に利用され、入出金ツールが格納されていたサーバ内に保管されていた一部顧客の個人情報（氏名、住所、生年月日、連絡先情報、銀行口座情報、本人確認書類）38,026件が、サイバー攻撃により流出したと発表されています。
そして事件を受けて、サクソバンク証券は以下の様に実施済の対策を発表しています。
お客様へ多大なるご心配、ご迷惑をお掛けいたしましたことを心よりお詫び申し上げます。すでに当社では、取引システムログイン時における2要素認証の導入、本件外部委託先の運用停止、オンライン上での金融機関情報変更の停止等の対策を実施し、情報セキュリティ対策を進めつつあります。一方で、社内態勢の再構築等なお課題があることを認識しており、今般の行政処分は厳粛かつ真摯に受け止めるとともに、1日も早く皆様からの信頼を回復すべく、情報管理態勢を含む一層の内部管理態勢の強化・拡充に努めてまいる所存です。
（公式発表9/18から引用）
ここでひっかかったのは、2要素認証の導入が既に実施済なのですが、どうやらこの内容では不十分と金融庁に判断され、業務改善命令を受けた点です。
サクソバンク証券側の認識としては、「社内体制の再構築」がメインの課題と受け止めている様ですが、金融庁の業務改善命令の内容を見ると、それだけでは不十分と読み取れる内容が書かれています。
【業務改善命令】
今回発生した事案について、徹底した事案の解明及び深度ある原因分析を行ったうえで、個人情報の安全管理義務と外部委託先の監督義務を履行するため、システムリスク管理及び外部委託先管理に関して、適正かつ確実な業務運営を確保するための態勢を構築すること。
今回発生した事案について、引き続き、顧客に適切に周知・説明を行うとともに、顧客からの問合せには、万全の対応を行うこと。
本件に係る責任の所在の明確化を図ること。
上記（1）から（2）までについて、その対応・実施状況を令和2年10月19日（月）までに書面で報告するとともに、その後の進捗状況を当面の間、随時、書面で報告すること。
（公式発表9/18から引用）
この前段部分に「徹底した事案の解明及び深度ある原因分析」と書かれており、初期サクソバンク側の原因分析（及びその対策）に問題があった可能性を示唆しています。
業務改善命令（9/18）が出される前日の9/17に、第三者調査機関による調査結果（の概要）がリリースされており、リリースには書かれていませんが、この調査結果の中に事件の詳細原因が書かれていたのかと推測します。
その部分が開示されてないので、以下根拠のない推測となりますが、ドコモ口座やゆうちょ銀行、SBI証券などの現在騒がれている事件と、攻撃のパターンが似ている気がしています。
サクソバンクは個人情報の漏えいですので、ハッカーが得た最終的な「成果（＝個人情報）」は、前述の事件（＝金融資産）とは違いますが、サクソバンクの場合は幸いログインのIDとパスワード、取引口座情報はサクソバンク本体側のサーバーに格納されていて無事だったので、金融資産の不正売却といった成果にたどり着かなかった事や、時期的に近い事を考えると、金融機関等の口座振替を集中的に狙った攻撃キャンペーンだった可能性があります。
その場合、金融庁の業務改善命令内容である、「徹底した事案の解明及び深度ある原因分析」部分を深読みすると、サプライチェーンを含めた（口座振替運用）スキームのリスクアセスメント不足と読み替えられる気がします。
サクソバンクの場合、恐らく外部ベンダーのサーバーに個人情報を置いていた合理的な理由があるのかと思いますが、この外部ベンダー（サプライチェーン）のセキュリティ体制をチェック／監督が不十分だった事が金融庁の文面からも伺えます。
個人情報は外部ベンダーではなく、今回被害を受けてない（より堅牢な）サクソバンク側のサーバーで管理する事も選択肢の１つだったかと思います。
一方で、ドコモ口座の事件では、提携先の地銀の本人確認部分のばらつきについて当然ドコモ側でも気づいていたと思いますが、「銀行の暗証番号」は安全という前提で、ドコモ以外のユーザーを受け入れる際に、（想像ですが）サプライチェーンの穴をリリース前にチェックせずに運用を開始した事も影響したと思います。
私の専門のPCI DSSで考えると、以下の要件あたりに該当します。
要件11.3.1に「外部のペネトレーションテストを少なくとも年に一度および大幅なインフラストラクチャまたはアプリケーションのアップグレードや変更（オペレーティングシステムのアップグレード、環境へのサブネットワークの追加、環境への Web サーバの追加など）後に実行する。」というものがあります。
これは、外部連携先と新しい接続があった際に侵入テストを実施して新たな脆弱性が出ないか確認するという要件内容なのですが、ここ2週間に出てきた事件を俯瞰すると、金融資産が関係する複合的なシステムに対する、変更リリース前のテスト（リスクアセスメント）が不足している気がしてなりません。
参考まで、PCI DSS要件11.3.1のガイダンス（解説）を貼っておきます。
ペネトレーションテストを定期的およびは環境に大きな変更があったときに実施することは、悪意のある者が CDE（カードデータ環境） にアクセスする可能性を最小限にとどめるための予防的なセキュリティ手段です。
大幅なアップグレードや変更が何を意味するかは、環境の構成によって大きく左右されます。アップグレードや変更がカード会員データのアクセスを許可する、またはカード会員データ環境のセキュリティに影響する場合は、大幅なアップグレードや変更と見なされます。ネットワークのアップグレードや変更後にペネトレーションテストを実行すると、アップグレードや変更後も、実装されているコントロールが動作していることを確認できます。
本日もご来訪ありがとうございました。
Thank you for your visit. Let me know your thoughts in the comments.
更新履歴
