俺たちはマルチステークホルダー間のセキュリティインシデントから何を学ぶのか

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2020 LayerX Inc. 社内勉強会資料 Intro • 今回のインシデントは、銀行と資金移動業者がキャッシュレス推進の波に乗り、リスクが顕在化してしまった例です • （キャッシュレスのような社会的イノベーションの前で、）伝統企業に代表される「レガシーだがセキュア」と考えられていた体制を、事業社側が見つめ直す必要性が出たと考えられます • 伝統的な大企業や金融事業者の「信頼」という1つの機能がアンバンドリングされ、機能が新しいプレイヤーに広がるチャンスにもなります • 一方、信頼が損なわれることにより銀行での解約等が起こっており、取り付け騒ぎからの（国内）システミック・リスクに繋がってしまう可能性も否定はできなかった • 銀行が悪い、資金移動業が悪い、証券が悪い、という話ではなく、顧客の体験と資産を毀損した時点で、全ステークホルダーに責任があります • 本件は様々な種類の「他山の石」になりえる。皆さんご自身で「我々だったら何を学べたか」考えるきっかけになることを望みます • 今後、非金融事業者が金融事業者と金融サービスを提供する流れは今後十分に考えられる • そして、ステークホルダー間で「顧客の資産を保護するためにお互いどういう責任をはたしていくべきか」議論をし、責任を明確に分離・負いつつ、顧客本位を最優先に協力的な体制を整え、信頼を得られる金融サービスを提供するための準備ができるようになることを望みます

Slide 18

Slide 18 text

© 2020 LayerX Inc. 社内勉強会資料 • ローカル認証 vs リモート認証 • キャッシュカードへ物理アクセスが必要 + 認証されるまでの経路がPoS端末だけ -> ローカル認証 • 悪者がウヨウヨいるのでローカル認証の実装が使えるけど使ってはいけない -> リモート認証 • 昭和で地銀向けに提供されていた本来、弱い認証を選べてしまうシステム • なぜ、今まで問題にならなかったかは不明 • 大事になってない、顧客と直接対応して表に出てない可能性はある • インターネットバンキングつくったタイミング & 数年以内に統合するのが筋 • でも残っちゃった。銀行とNTTデータ間でどのようなやり取りがあったか不明 • （妄想）NTTデータ「やったほうがよくないすか？」銀行「お金ない。判断できない」-> FIN • キャッシュレス大航海時代到来! でも、スタートアップはCAFISつなぐための体力も時間もない… • キャッシュレス事業社「Webの入り口があるCNSとかどうよ」ということで事例が増える • 流行 + お金があるということは、それを狙って攻撃者（リスク）もやってくる… • 本来は、銀行側がWeb口振受付の契約を申し込む収納企業が審査・リスク評価するはず... • 銀行が気づきNTTデータに相談したかは不明 • また、NTTデータが気づかないわけないが、そのときにNTTデータと銀行間で、そのようなやりとりがあったかは不明 • ドコモや7payだって気づけたはずだが… キャッシュレス消費者還元施策するよ!!! 9/15 銀行の認証で弱かったポイントはどこか銀行事業者 Web 口振受付システムなりすまし登録銀行利用者なりすまし認証インターネットバンキング口座に対するネットワーク経由での認証店舗で使うキャッシュカード名義照合物理的な認証提供「松」「竹」「梅」といった具合にセキュリティー強度の異なる選択肢が用意 NTT DATA

Slide 20

Slide 20 text

© 2020 LayerX Inc. 社内勉強会資料キャッシュレス消費者還元施策するよ!!! 9/15 銀行の認証で弱かったポイントはどこか • ローカル認証 vs リモート認証 • キャッシュカードへ物理アクセスが必要 + 認証されるまでの経路がPoS端末だけ、ということでローカル認証 • ネットワーク経路は悪者がウヨウヨいるのでローカル認証の実装が使えるからと言って、使ってはいけない • 元々、昭和で地銀向けに提供されていて、本来、弱い認証を持つシステム • インターネットバンキングつくって数年以内に統合するのが筋 • でも残っちゃった。銀行とNTTデータ間でどのようなやり取りがあったか不明 • NTTデータ「やらなくていっすか？」銀行「お金ない」Fin… • キャッシュレス推進! でも、startupsはCAFISつなぐための体力も時間もないということで2019年に流行 • 流行 + お金があるということは、それを狙って攻撃者（リスク）もやってくる… • 本来は、銀行側がリスク評価して「いや、ちょっとまって」と言わないといけなかった • 銀行が気づきNTTデータに相談したかは不明 • また、どっかのタイミングでNTTデータは気づかないわけないが、そのときにNTTデータと銀行間で、そのようなやりとりがあったかお不明銀行事業者口振受付システムなりすまし登録銀行利用者なりすまし認証インターネットバンキング口座に対するネットワーク経由での認証店舗で使うキャッシュカード名義照合物理的な認証 https://news.biglobe.ne.jp/it/0909/imn_200909_8151351951.html https://www.resonabank.co.jp/hojin/service/eb/urikakekin/webkouza/ https://novtan.hatenablog.com/entry/2020/09/10/095100 提供 - 認証の口を複数つくってしまう、全体システム設計上の悪手ローカル認証をインターネット認証に適用する、認証設計上の悪手 - 認証の口を統合しない、ロードマップ設計上の悪手 - 社会的変化にリスク再評価をしなかった、あるいは誤評価した - 銀行側と事業社側の認識のちがい -「銀行はレガシーだけどセキュア」神話の崩壊 - 銀行というシステムへのトラストがアンバンドリングされた

Slide 32

Slide 32 text

© 2020 LayerX Inc. 社内勉強会資料銀行側のミス（証券側でも起こりうる） • 毀損されたポイント • 証券システムのログオン、口座設定、出金 • ログオンも取引時パスワードも↓雑魚 • 半角英数字6文字以上10文字以内 • 銀行のKYCプロセス(!!!) • キャッシュレスさーびすどころか、G-SIBSでもあるガチガチUFJ が、やられている • 暗黙的な銀行の（本人確認）信頼度が崩れた • 証券口座と銀行口座の紐付けは、銀行側の身元確認照合が信頼できる前提でなりたっていた • 件数、金額、KYC突破状況から考えて、事前に標的を決めていたのでは？（個人の考え） • 標的がまだもっていない口座じゃないと、標的になりすまして口座を開設できない • 9864/6/120 = 13年分のNISA額/被害者なので、ある程度の資産を保持している対象になる（日本では少ないはず） • 良い子の皆はパスワードマネージャ使うんだよ… 不正ログイン銀行証券 ①証券利用者なりすまし認証 ①口座登録 ②出金口座設定 ③出金 0. 標的選別入出金システムなりすまし登録されちゃいました 2020/09/16 えっ？えっ？名義照合だけぢゃダメじゃん… 不正な口座への送金リスクだけ見ると、証券口座が本人以外の銀行口座に紐付けできるリスクの脆弱性のが優先度は高い（私見）セキュリティちゃんとコストかけてちゃんとやってます。だから本人確認情報をAPIでとれるようなビジネスも考えています。事業者えっ？銀行口座ってあんだけやって、不正登録されちゃうの？証券口座側の本人とは限らなくなっちゃうなら名義照合だけじゃダメじゃん… そうかも… じゃあ、名義照合だけでいいか… Before 2020/09/16 そうかも… じゃあ、名義照合だけでいいか… Before 2020/09/16 ④不正送金そうかも… じゃあ、名義照合だけでいいか… Before 2020/09/16 ゆうちょ UFJ

Slide 35

Slide 35 text

© 2020 LayerX Inc. 社内勉強会資料図 • 毀損されたポイント • 証券システムのログオン、口座設定、出金 • ログオンも取引時パスワードも↓雑魚 • 半角英数字6文字以上10文字以内 • 銀行のKYCプロセス(!!!) • キャッシュレスさーびすどころか、G-SIFSでもあるガチガチUFJが、やられている • 件数、金額、KYC突破状況から考えて、事前に標的を決めていたのでは？（個人の考え） • 標的がまだもっていない口座じゃないと、標的になりすまして口座を開設できない • 9864/6/120 = 13年分のNISA額/被害者なので、ある程度の資産を保持している対象になる（日本では少ないはず） • 良い子の皆はパスワードマネージャ使うんだよ… 不正ログイン銀行証券 ①証券利用者なりすまし認証 ①口座登録 ②出金口座設定 ③出金 0. 標的選別入出金システム FATF的に考えると、他者に送金可能な銀行側のKYCが毀損されたのがまずい。これは資金移動業よりさらにインパクトがでかいし、証券側の不正ログインよりリスクがでかいと思われる（のに、何も続報がない） - 証券は口座連携する際に、銀行口座が不正登録されたものであることを勘案したリスク対策を建てる必要が発生 - なので、最初から2FAを用意して、送金時や口座設定・変更時に2FA側の認証をかけるなどをするのがコストが安い - でなければ、出金時の挙動からヒューリスティクスなモニタリングなどの統計的検知手法に頼らざるをえなくなる - とはいえ、銀行側も規模や予算、体制までまちまちであり、絶対にミスしない、ということはありえない - その前提にたちリスクアペタイトを考え、「銀行からの情報でも検証する」というTrust, But Verifyな姿勢にすべき

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text