流石にダラダラ書きすぎなので、そろそろまとめです。
会社としての問題をピックアップしつつ、まとめの小並感ですｗ
会社としての問題
事件発生後の対応や体制は？
被害の報告は、早くもサービス開始の翌日の7月2日にもたらされたということです。
緊急記者会見が7月4日14:00。
これが速いのか遅いのかは意見が分かれそうですね。
どちらかというと、「もっと早くやるべき」という意見を多く見る気がしますが。
まあ、ECサイトを含めた決済サイトで、開始後に3桁以上の不正アクセスによる被害が発生した速さなら、世界レベルで1位が狙える速さなので、それと比べたら遅く感じるかもしれませんね！
システム的な対応ですが、不正アクセス目的がほとんどと見られる海外からの通信は既に遮断した、と会見のときに言っていましたね。
それで不正アクセスの通信が全部遮断されるわけじゃないですけどね。
Torの出口ノードを日本指定にしたり（まあこれはこれで別の意味でコワイけど）、日本のオープンプロキシ経由してきてたらどーするんですかね。
また、パスワードリセットの仕様上の不具合も対応したといっていましたが。
有志が確認したところ、「元の画面からcss（スタイルシート）で非表示にしていただけ」ということが発覚。
こんなの、ちょっと工夫して隠しているパラメータにアドレス入れたら、元と同じく送付先アドレスに送れるじゃない。
本来なら、サーバサイドの処理を修正すべき。
流石に、セキュリティと今回の事件をナメてませんかねｗ
運用の対応ですが、チャージをできなくしたり、新規登録を順次おこなったようですが。
その対応ペースが遅かったり、チャージ済みのものはそのまま使えたりと、どうも疑問に思う対応だったと思います。
ここ最近で発生したサイバー攻撃被害の対応では、多くが一時サービス停止しており、それに比べると緩い印象ではあります。
そのあと経産省から激しくツッコミいれられたようですけどね！
システム、運用の対応を見ていると、場当たり的な対応に終始している印象。
「こういう場合はこういう対応をする」といったルールなどは策定していなかったのではないか、と思われます。
それが確認の遅れ、対処の漏れ、対応が後手後手になった原因になのではないかと思います。
確かに、サイバー攻撃は色んな手法が用いられ、フレキシブルな対応も必要となりますが、それは基本ができているのが前提です。
まあ、会見で言っていた、「これをきっかけにさらに安心安全を・・・」って、言っていたのも印象的ですね。
何をのんきなことをｗｗｗ
のんきというのもありますが、きっかけも何も、こういう被害の発生しない、安心安全なシステムをつくってからサービスインするものですよ？と、ごく当たり前のツッコミを誰かしてあげなよｗ
開発時の体制って本当に大丈夫だったの？
開発したメンバーのセキュリティ知識に関しては、パスワードリセットの仕組みの不具合対応を見ている限り、絶望的レベルということは分かっているとして。
開発の「体制」自体にも問題がなかったか？という点は大いに気になるところです。
設計の仕様上の問題など、脆弱性診断以前のセキュリティの問題点の抽出をちゃんとやっていたのか、甚だ疑問です。
やっていたと言うかもしれませんが、それはセキュリティ知識がある人がやらなければ意味がありません。
二段階認証・・・？とか言ってる人がやっても無意味ですからね！
また、グループ内のシステムが複数あって連携しているようですが、そこの意思疎通は十分図られているか疑問です。
今回の事件では、パスワードリセットにも不具合が見つかりましたが、こちらはセブンペイの持ち物ではなく、グループの別の会社の担当の可能性も考えられます。
と、いうのは、パスワード関連は認証基盤が担当しますが、グループで共通の認証基盤を利用している場合、その担当がグループ会社内で独立であってしかるべきと考えられるためです。
この場合、組織が縦割りで風通しが悪いと、仮にセブンペイの担当者が認証基盤側の不具合に気づいていても、意見が通らないことも考えられますね。
もっとも、セブンペイも自分の担当外だからとチェックせず、セブンペイの仕組み全体を俯瞰してみていなかった可能性も十分考えられますが。
組織が縦割りで意見交換ができていなかったか、セブンペイが仕組み全体を俯瞰する視点に欠けていたか、その両方か。
開発といっても、単純に技術だけでなく、「体制」も重要だと考えさせられる事件です。
認証基盤の問題
開発の体制で少し触れましたが、今回の事件とは直接は関係ない可能性があるものの、今後も問題になりそうな当グループの認証基盤について考えてみます。
（と、いっても、今回は関係しなかったかもしれませんが、2013年の事件では関係してたと思われるんですけどね・・・。）
認証基盤は、ユーザが本人であることを確認する基盤であり、不正アクセスを論理的・技術的に防ぐ要です。
例えば、このシリーズのメモの中で挙げた、hiddenパラメータなどのID書き換えで他人になりすましが可能であったなら、認証基盤としては役目を果たしていないと言えます。
流石に、そこまでは酷くないだろうと思っていたら、7payに関してはこんな記事を見かけました。
狙われた7pay｢外部ID連携｣の脆弱性の全貌。急遽“遮断”した理由
https://www.businessinsider.jp/post-194660
7pay騒動から見えた、モバイル決済の懸念 生き残るために必要なものとは？
(中盤にOAuthに関する記述あり。)
https://www.itmedia.co.jp/mobile/articles/1907/17/news100.html
もしコレが本当なら、ID書き換えで成りすましができちゃうのと大差ないようなｗ
ペネトレーションテストしてればひっかかるはずなんだけども。
「セキュリティ審査はした」というのは何だったのか。
流石に、ウソであってほしいような内容ですが、「ありえる」と思えるのが、今回の顛末で顕になっているセキュリティの意識と技術レベルを表していますね。
この考察で気になるのは、今回の事件は7payだけの問題ではないのではないか、という点です。
そう考えると、認証、トークンの発行の基準が、7payだけが低かったのではなく、グループ全社として同じ水準だったのでは、という懸念が生じます。
もちろん、連携しているセブングループの認証基盤そのものにも問題がありそう、というわけです。
もしそうであれば、問題は非常に根深くなります。
7payばかりに気をとられているが、認証基盤やセッション管理の不備から同社の関連サイトが今も攻撃に晒されているかも・・・？という懸念が生じます。
今回の事件を受けて、こういった点もちゃんと見直しできるか？は将来また同様の事件が起きないか、の重要な指標になるのではないかと思います。
7pay問題に隠れてあまり話題になってないような気がしますが、グループ全体のシステムのセキュリティの見直しが今後を左右するのではないかと考えています。
個人情報の流出に関する危機意識
どうしてもお金の実害が見えているのでそちらがピックアップされていますが、個人情報の流出も一つの懸念です。
なにしろ、不正にアプリに登録できる段階で、ID、パスワードが漏れているか、少なくともなりすましの認証はできた、ということです。
そうであれば、登録者自身の個人情報にもアクセスは可能だった、と見るのが自然です。
特に例の会見では、「利便性」という言葉を、半ば免罪符のように連発していました。
「顧客のためにやっていたことだから仕方が無い」と言いたいのでしょうか。
しかし、「利便性」のために個人情報が流出してもいい、ということはありません。
自社の都合を優先して顧客を守る意識が薄いのではないか、ということを危惧しています。
実際のところ、個人情報などを安価で守りたいなら、紙に印刷して金庫にいれておけば、そうそう簡単に盗めません。
Webなどはインターネットにインターフェスを持つ以上、不正アクセスなどによる流出の危険性は高くなります。
それでもインターネットで個人情報にアクセスできる仕組みを導入するなら、相応のセキュリティが必要です。
今回の事件で垣間見えるセキュリティのレベルから、果たしてどれくらい顧客を守るという意識があったのか？ということは、注意してみるべき点だと思います。
世間のセキュリティ意識・常識との格差
別記事で述べたとおり、インターネットの黎明期は、そもそも自分の研究や意見を発表するという、情報を広める仕組みとして機能していました。
当時は、メールのような一部の機能を除くと、多くが公開情報で、公開する気が無いならば置かない、というのが基本でした。
しかし、プライバシーの高い情報を扱ったり、音声や動画の配信のような放送のような機能を持つようになったり、通信のインフラとして発展していくに従って徐々に変化をしていきました。
ビジネスをはじめ、インターネットを利用するということは、この技術的な変化や、それに伴う価値観の変化についていく必要があります。
セブンペイの事件の会見では、世間一般とセブングループの経営者との間に「今のインターネットやプライバシーの価値観」の乖離があり、それが非難の原因になったと思います。
対応のスピード感としては、「今のところそれほど何か対応が遅くなったという認識ではない」という認識で、「今のところそれほど何か対応が遅くなったという認識ではない」と言っています。
ただ、不正アクセスが複数確認された段階で、注意喚起や利用の一時停止など、もっと早くできたのでは？と考える人も多いのではないでしょうか。
最近では、こういった事例が発覚するとサービスを一旦停止するケースも多いため、それと比べて、といった面もありそうです。
また、被害者への補償はすると言っていますが、最近はニュースが減ったせいか、具体的にどこまで進んでいるかははっきりしません。
多くの人が対応にまずさを感じるのは、やはり事前の準備不足ではないかと思います。
BCPだけでなく、サイバー犯罪の可能性が発生したときの対応マニュアルも整備されていなかったのではないでしょうか？
たまに、「マニュアルにこだわらず、知見に基づいて対応するのが大事」と言う人がいます。
これは、「マニュアルを理解して、それは一通りできる人」という前提があると考えています。
マニュアルというのは、平時において、落ち着いた環境でいろんな想定を元に作れることが大きなメリットです。
サイバー攻撃などが発覚し、緊急対応をしなければならないとき、どんなに落ち着いているつもりでも人間の頭は混乱し、抜け漏れが発生します。
また、事態発生直後や推移する中では、100%の情報が得られることはなく、不完全な情報の中で可能な限り正しい判断と迅速な対応をしなければなりません。
それをカバーするのは、緊急事態を想定したマニュアルと訓練が必要になります。
緊急時のマニュアルが無ければ、緊急時にまずこれはやらなきゃといった対応をするものの、その段階で見落としがいくつも発生します。
また、状況が一部分かったところで、さらに追加でこの情報も欲しいとなり、その段階になってようやく新たな情報収集が始まります。
当然、そのときから情報を収集し始めるので、情報が集まるまで時間がかかります。
緊急時にマニュアルがある場合、そういった情報は機械的にとりあえず集めます。
そのため、さらに追加でこの情報も欲しいとなったとき、もうそこに集まっているということになってきます。
これが、状況把握や対応の速度に決定的な差を生じさせる要因となります。
また、マニュアルを整備したり、訓練をしていると、こういった情報や機器が無いと対応できない、ということが判明することもあります。
つまり、セキュリティの設備、体制の見直しのきっかけにもなることも見逃せません。
事件に関する情報の公開についても、「不足している」と思った人が多かったのではないでしょうか。
詳細を言わずじまいで済まそう、という態度が見えているようにも感じられました。
記者会見から2週間あまり過ぎましたが、やはりセブンペイに関する記事は減ってきました。
「人の噂も75日」とはよく言ったもので、このままフェードアウトさせようという意図があっても、その通りになるかもしれませんね。
「～ペイは不安」と漠然とした不安を持ったり、私のように2013年の事件への対応の段階で信用していないといった人もいるとは思いますが、多くの人からは忘れられるかもしれません。
しかし、「公表しない」ことでなし崩しにせず、抜本的な改善を行ったかというのは、ユーザ側も見極めないといけないでしょう。
それにしても、原因など非公表な情報がいろいろあると思いますが。
実は、セキュリティ対策が杜撰で、伏せているのではなく、わからないんじゃないか・・・？ということまで疑ってしまいます。
事後対応も含め、事前の対策不足は否めない状況なので、調査に必要な情報を十分残していなかったのではないか、と勘ぐってしまいます。
問題点をつらつらと並べただけで、最後も特にまとめませんが。
もちろん、私見ばかりのため、同意できる点、同意できない点それぞれだと思います。
多少でも参考になる内容があったなら、それを利用してセキュリティ対策に生かしてもらえれば、と思う次第です。