たぶんだがね、

HackerSafeのやってるSQLインジェクションチェックは、
サードパーティ製品などに見付かっている既知の問題クエリとかで、決まったパターン。
で、今回問題だったのは、サイトカスタムなSQLインジェクションで、決まってないパターン。

まぁ、売る側からすれば「SQLインジェクション」診断してますと言うが、
実際には無駄なパターンを数多くたれ流しているだけに過ぎず、いざというときの役に立たない。

安かろう、悪かろうな典型だわな。
だがこれは、別にHackerSafeが悪いわけじゃない。

問題は、正しくリスク分析ができなかった連中が悪いんだ。

今回の件くらいの規模のリスクが発生することを見越していれば、
定期的に人力で診断するなりなんなり出来たはずだろう。

>そのOffice事件を受けてIPAやJPCERTなどの取り組みが制度的に整備されました。
(略)
>その教訓はきちんと生かされているのではないでしょうか。

レスありがとうございます。
この部分、自分でも最後まで触れずにいようかと思いましたが、やはり触れることにしました。
このようなツッコミが入る程度には、IPAの活動は周知されているのか、普通にOffice事件から
進展がないと受け止めている人が多いのか解らなかったからです。

あれ以降、確かに軽微なものはリスクを負う事無く報告されるようになりました。
そして問題が起きた後のインシデントレスポンスの体制は整ったかもしれません。
しかし、今回の経緯 [srad.jp]を見て、そして自分が通報したときの経験からすると充分といえません。

・「海外における善意の第三者」の通報には対応していないか、窓口が知られていない
逆に一見日本語が提供されていても、グローバル企業、日本以外に本拠点のあるサイトへの対応は弱い
・今回のような脆弱性を全個所（SQLインジェクション以外の部分）報告する事は歓迎されない
そこを糸口にした影響範囲を調査する事は逆に制限がついている
・報告しても放置が多いのに全く公開されず公開できず、その間ユーザーは危険に晒されつづける
具体的事例を蓄積しているはずなのに、統計的にしか知ることが出来ない

という問題を依然抱えているように思えるからです。

>Office事件は通報者自身の不手際
これがたまたま、比較的オープンな集会であったために発覚しましたが、今回のようにアンダーグラウンドで
取引されているような脆弱性情報 [impress.co.jp]のような、
即警察にも動いて欲しい事案を報告するにはIPAの窓口だけでは不足です。
（場所によっては、裏切り者となって殺されるリスクがあるかもしれません）
そして、ソフトウェア事例ですが一太郎の脆弱性が、シマンテックのブログで公開された事例について
高木浩光氏 [takagi-hiromitsu.jp]も「一太郎zero-day攻撃のニュースは、
次のように、いつも Symantecの blog が一次情報源になっている。」と書いています。
（まあ、氏のblogなので、やや煽り気味である表現があるのは無視して読むことが必要ですが）
要するに、海外の善意の第三者は依然Office流とも言える対応をしているし、悪意のある人間は尚更です。
日本国内の善意の第三者だけが守るような取り組みで、その善意の示し方も慎重なやり方に制限されています。
結果的に、通知された側は本当のリスクが見えなくなっています。

脆弱性を通知された組織の側から、間近に問題がどう受け止められたかを見た事もあります。
私は当該アプリケーションの実装もしていなければ、何か決定する権限が与えられている訳では
ありませんが、他に誰もその脆弱性報告がどういう攻撃をされるのに利用されて、
一番大事な所ですがビジネスリスクになるのが解らないという事で相談された事があります。
IPAからの報告は、技術者に届かなければ意味が通じず効果がないという事なのです。
統計的なデータ [security-next.com]だけでは、わが社に限って狙われることは無いと思ったりするのです。
特にクロスサイトスクリプトのようなものは、「これまでにこれでこういう事例があった」
みたいな一時報告者は知らなくてもIPAが蓄積しているであろう具体的なソースを提示しないと、
すぐにエスカレーションされる機会が殆ど無いのです。

例えばSQLインジェクションでは、会員の情報を抜いて見せて報告をすればいいのですが、
一度そういう報告をすると「これ…訴えられるかもしれないよ」とお叱りを頂きます。
だからシングルクォートを入れたらSQLエラーが画面に出た、程度の情報で報告します。
では、そこからIPAが相手と同意をとって検証して、会員情報リストが抜ける形を示して
くれるかというとそうでは無いので、よほど日頃からセキュリティ事情に関心をもっている、
CIOでも置いていない限りビジネスリスクとして認識してくれません。
オフショアに丸投げにして作られたものなどは、解っていても「契約外、仕様外」といって、
直すのに新規構築に負けないくらいの金と労力がとられるので躊躇する場面もあるようです。

まあ、SQLインジェクションは、もはや名前だけが一人歩きするようになっているので、
「とにかく対策しなければ」と思う人のほうが多いと思ってしまいます。
しかし、44件残っているうち1年以上放置されているのが20件 [nikkeibp.co.jp]というのが実情です。
しかも、今回のような事案の場合、「この欄に'を入れたらエラーが出たよ」どまりの報告では、
抜本的な対策を取る事無く別欄のインジェクションで攻撃されている不安が残ります。
ラックさんとの協力でツールを公開 [atmarkit.co.jp]してくださったようですが、
これは複数台サーバーにわたる膨大なログを定期的に自動処理出来ないので実行コストが嵩みます。
すると、結局元々意識の高い会社が「ああやっぱり攻撃されてなかったね、よかったね」という確認を
自主的に行って安心する程度になってしまう可能性が高いです。

これまでの、「統計的な取り組みは評価に値する」「あの頃に比べれば改善したと思う」という意味で、
その認識は貴方と同じですが、今回の事例からハッカーセーフを導入するようにはなったが、
しかしそのソリューションが一体何を守っているのか解っていないでやっているという実態が
明らかになり、ウェブをやってるのは技術者がいる会社だから技術者に解る内容で公開すればいい、
という性善説的な従来の限界、日本国内ルールの限界が見えてきたと思います。

IPAの実効性に論点が膨らみすぎましたので、Office事件後と事件前の話だけに絞りましょう。
Office氏のやった事は、発表の場とプロセスが悪かったにせよ具体的なプレゼンでありました。
あれ以降、IPAに報告をすることで、具体的なプレゼンを必要としなくなってはいるが、
それだけに充分相手に伝わらなくなっているという事です。

(っд`)ｱﾁｬｰ

陳腐化するものといいながら、「最強のセキュリティ」というものはどうなんでしょうね。

国防省ぐらいコストをかけているなら最強といってもいいけど、
セキュリティ専門家すらいない低コストで運用している一中小企業が、最強のセキュリティを手にいれられるわけないでしょうが。

せいぜい、現時点で、対処できる施策の中で、コストとリスクを考えた上で、もっともよい施策を選んだ程度でしょ。

>>サウンドハウスは今、およそ最強のセキュリティ管理体制を整えつつあります。
>なんかまた安心してしまっているような…、気のせい？

対応策には「4.プログラムの除去 外部から挿入された疑いが高い不正プログラムの除去を実施。」とあって、OSを入れ替えました、とか、再インストールしました、とは明確に書いてないんですよね。少なくとも任意のシェルコマンドを実行可能だった疑いのある期間があったわけですから、真っ先にそこをどう対策したのか書くべきじゃないのかな、と思います。最強のセキュリティ管理体制が早く整うと良いなぁ、と願うばかりです。

＞何か悲しいこと

・・・一人三交代とか・・・
・・・社内ひきこもりとか・・・
・・・サーバールームに巣くう巨大な蓑虫とか・・・
・・・昼間社員で夜警備員とか・・・

> すでにサイトは無くなっていましたが、

これは [mop.com] 復活してるのだろうか？それともキャッシュを見てる？

自力で見つけたんではなく、元コメントの中から適当にキーワードを選んでググったんですが。

図が見えるので、それなりに参考になろうかと。

> 時間を稼ぎたかったのでしょう

そんな後ろ向きな理由じゃなくてもね、いくら人数を確保したところでどんな受け答えができるというんですか？ よくわからなくてもいいから知らせてほしいと言った人は問い合わせをして「現在調査中です」って返事を聞いて納得する？たぶん聞いたら怒るんじゃない？だとしたら、きちんとした情報を得てから公表するほうが無駄なやり取りがない分いいんじゃないのかな。