「事件・事故発生時の対策 有事に混乱しないための準備、技術、事例」を聞いてきました
以下のイベントを初めて聴講してきました。
登壇された5名の専門家の皆さまが持ち寄られた気になるトピックスについて45分間のパネルディスカッションが行われました。
ディスカッションされたトピックスは以下の5つになります。
- EC-CUBE 4.0 のXSSの脆弱性（徳丸さん）
- 事故原因報告のあり方（北河さん）
- ユーザー企業側で防ぎにくい攻撃（根岸さん）
- 知ってほしい事故対応事例（辻さん）
- オンラインでの本人確認（eKYC）（piyokangoさん）
以下に各トピックを持ち寄った専門家の方の補足説明と、議論についての議事を記載します。[議論]については、私の認識間違いがあるかもしれませんので、流し読みでお願いします。
EC-CUBE 4.0 のXSSの脆弱性（徳丸さん）
クロスサイトスクリプティング（XSS）は有名な脆弱性であるものの、悪用事例があまり知られておらず、対策が後回しになる傾向があるEC-CUBE 4.0のXSSはクレジットカード情報漏洩に至ったことが発表され、今後ウェブサイトへの攻撃のトレンドが変わる可能性を感じる*1
議論
- 管理画面の脆弱性で、本製品は中小零細企業で多く利用されているが、対策がおろそかになっている傾向がある（徳丸さん）
- 決済代行事業者からECサイトオーナーに注意喚起をしている状況（徳丸さん）
- 自分達が利用している製品の脆弱性を管理できているかが大切（根岸さん）
- XSSはアラートが出るだけという認識が広まっているのが良くなかった（徳丸さん）
- サイト運営者が、構築時のベンダーと連絡も取れず、運用保守まで手が回っていない（徳丸さん）
- EC-CUBE は注意して対応しているが、それでもなりやすいのか（北河さん）
- このような製品の場合、表示箇所のすべてが脆弱性となりうるし、管理画面のため脆弱性対応が薄かった（徳丸さん）
- XSSは脆弱性の高中低の中で、「中」と診断されがちだが、今後「高」と判断されることもあると思うか（辻さん）
- あるべき論としてはそうなりうるのではないか（徳丸さん）
事故原因報告のあり方（北河さん）
2020年10月 北米現地法人に設置していた旧型VPN装置から侵入。別型のVPN装置を導入済みだったが通信障害が発生した際の緊急避難用として1台のみ残存していた*2
具体的なメーカーや機種、脆弱性などについては、「詳しい情報を公開すると田曽式に影響を及ぼす恐れがある（同社広報）」などとして、コメントを避けた*3
議論
- 侵入原因の詳細が明らかでないため、具体的な対策が取りにくい。他社企業が対策しやすいように、より詳細な事由を公開をした方が良いのでは（北河さん）
- VPNの利用増加のあった4月から離れた10月に事件が起きたことから、なぜその脆弱性に気づけなかったのか知りたい。（北河さん）
- 事故対応アワードという取り組みの中で、事故情報の公開をいかにすべきかを議論している。被害を受けた企業自らどこまで公開するのが適切かを判断するのが難しかったのではないか。出さない方が社内的な判断として楽。（根岸さん）
- 〇HKの事例踏まえ、企業広報としてよく見せたいという心理もあるのではないか（徳丸さん）
- 基準がはっきりしていないので、広報等の関係者が藪蛇となるのを避けたい。関係者が多いことによるふわっとした怖さがある。（辻さん）
- 当事者の人たちが公開すべき部分とそうでない部分を判断できない。マイナスになることはないと専門家サイドは考えている（根岸さん）
- セキュリティを専門としないITエンジニアにとっても、攻撃手法を公開することに抵抗感がある（徳丸さん）
- 「旧型」の概念が企業によって異なるので・・・（徳丸さん）
ユーザー企業側で防ぎにくい攻撃（根岸さん）
アプライアンスやクラウドサービスの脆弱性による情報漏洩、サプライチェーン攻撃によるマルウェア感染など、ユーザー企業側で防ぎにくい攻撃にどう対処すべきか*4*5
議論
- ベンダー側の管理が原因となる問題が最近目立っている印象。ユーザーはこれらにどう向き合えばいいのかという質問に、専門家として答えにくいように感じる（根岸さん）
- 事前対応を捨てて、インシデントレスポンスに注力する等（徳丸さん）
- メルカリがCodecov社の脆弱性によって攻撃を受けた事件では、ソースコードだけでなく顧客情報も窃取されたことを踏まえ、プライベートなGitHubリポジトリにアクセスキーを置くのは控えたほうがいいとされている
- 機微な情報を散在させないという予防はできるのではないか（徳丸さん）
- 各ユーザーでクラウドサービスに機微な情報を業務上置くこともあるが、ちゃんと判断する必要がある。（根岸さん）
- 複数の事例が出てくる中で、すべてのユーザーが管理するのは難しい。利用者からすると何が起きているかわからない。全体的な統制を取る仕組みが必要と感じる（piyokangoさん）
- 様々な企業が提供しているサービスに対して、ユーザーと提供企業ではない、第三者の立場から統制するような組織が必要（piyokangoさん）
- アメリカでは飛行機調査の様に、セキュリティの問題についても事故調査を実施する第三者委員会が必要という議論がある（根岸さん）
- 広く影響が及ぶようなケースは、ベンダー側に強力な働きかけができる組織が必要（piyokangoさん）
- 日本企業が海外製品で被害を受けた事例はあまり聞かない。日本の製品を利用しているときに、自分がその製品ユーザー内で何番目にあたるのか、脆弱性がっ見つかった際にどれくらい攻撃を受ける確率が高いのか等を意識して製品を利用することも必要なのでは（北河さん）
知ってほしい事故対応事例（辻さん）
ノルウェーのサプライヤVolue社のランサム事案対応
① 被害が発生した当日の公表
② 自組織以外のチャネル（SNS、動画配信）の活用
③ 頻繁で積極的な情報公開
④ 顧客に向けたガイダンスの公開
⑤ リーダーシップの可視化
議論
- ここまで出していいんだと判断する一つの事例とはなる。完全に真似するのは難しいとは思うが、いいところは取り入れてほしい（根岸さん）
- リーダーシップの可視化は大切（徳丸さん）
オンラインでの本人確認（eKYC）（piyokangoさん）
- オンラインで実行者が本人であることを確認する手段
- 決裁アプリをはじめ様々なサービスでeKYCの導入が進んでいる
- パスワードがたどった道をたどらないかの懸念
（数えられないほどのパスワード情報が流通しているが、本人確認で利用されている運転免許証やパスポートといった本人確認用画像データが今後どこかに流出したことをきっかけにインターネット上で巡り巡ることにならないかの懸念） - コントロールが効かない範囲に漏れた後の最適解はあるか
（上記画像データが流出した場合の、ユーザーの最適解は何なのか）
議論
- eKYCのサービス提供事業者によっては、ライブネス判定を入れている企業もある
- 対面でやっていた本人確認をインターネットで完結できるような流れが生まれており、金融機関以外の企業がそうした認証をするときにどう守るかが問題。（根岸さん）
- 郵送での確認フェーズを含むことが多く、画像データのみで口座が作られることは一般的にはない。オンラインで完結させる企業は厳しい対応をしているように思う。（北河さん）
*1:【重要】EC-CUBE 4.0系における緊急度「高」の脆弱性(JVN#97554111)発覚と対応のお願い(2021/5/24 17:00 更新)|ECサイト構築・リニューアルは「ECオープンプラットフォームEC-CUBE」
*2:不正アクセスに関する調査結果のご報告【第4報】 | 株式会社カプコン (capcom.co.jp)
*3:【セキュリティ ニュース】カプコンへの不正アクセス、侵入経路は予備に残した以前のVPN機器（2ページ目 / 全2ページ）：Security NEXT (security-next.com)
