http://www.itmedia.co.jp/enterprise/articles/0507/27/news020.html
いろいろと考えさせられる一件だけど、
カカクコムの場合、こうした副作用リスクの中で一番心を痛めたのが、技術系メディアによる「詳細を公開しないのはけしからん」という論調だったという。
「公開することによるメリットもあるが、公表した場合のリスクが読めないことから言わないようにしていたが……」（遠藤氏）、結果として社員への心理的なダメージは相当大きかったという。原因や詳細の公表に関して同氏は「何らかの社会的なコンセンサスがあればよかったかもしれない」とも述べた。
けっこう読んでいたのねいろいろと、とかいう脊髄反射はさておき（笑）。
もとからセキュリティに関心を持って追いかけている人たちというのは、メディアも含めてこのあたりの議論を何度か経てきているので、感覚として直後に「SQLインジェクション」とかいうキーワードだけでもあれば良かったのに、と思えるわけですよね。しかし、ここで正直に告白されているように、遠藤さんには少なくともそういう感覚が無かったわけですね。ニッチなセキュリティ業界での議論が外にちゃんと届いていなかったから、とも言えるし、そもそもセキュリティに気を配るべき立場なのに、そういう情報をおさえてなかったのねorz、とも言える。しかしまあ、これは永遠の課題なんだろうけど、今のところは知ってる人、気づいちゃった人がいろんな場面で発言、情報公開し続けるしかないのかな、という気がします。事件があるとキーワードだけは流布するようになるけど、じゃあ具体的にSQLインジェクションされないようにプログラムを作るにはどうしたらいいのか？っていう、必要な知識が現場にわたっているのか？というと疑問もあるんだよなあ。そしてさらに疑問なのが、対策することによって予算がかかるんだけど、その予算を出す立場の人に、そうしたものの脅威がどれだけ伝わっているのか、ということなんだよねー。
なんといっても現場がいくらノウハウを持っていたとしても、そのノウハウを使うことにお金が出てこなければやれないわけですよね。
しかし、「だから仕方ないよ」といって逃げているだけでは、いざ事が起きたときには現場に責任をひっかぶされて（また現場の技術者とかってマジメだから、無理筋の責任追及でもまじめに「言われてみればそうかも知れないなあ」なんて受け取っちゃったりして）、いろんな意味で潰されてしまう。そうならないために、リスクヘッジとして、知識や理論武装して事前に「セキュリティの提案」を行っておくべきなんでしょうね。「提案」には1人月追加（テスト含む）かかりますが、どうしましょうか？提案を蹴られた場合には、SQLインジェクション耐性は知りませんが、ってなことを最初に言って、受け入れていただけるのならおっけーだけど、拒否されたら責任は逃げられるような契約にしとかないと、とか思います。
まあもちろん、受け入れられたときにそれに応えられるだけのノウハウが無いと、こういうこともあり得ないんですけどねえ（笑）。
逆に、セキュリティは任せた、とかって放り出されたときも困りますよね（苦笑）。そういうときは出てきた見積もりを見てダメ出しとかされがちですが、放り投げのときほど相手の感覚やら文化やら背景やら予算やらを考慮して、それでもこれだけはやりましょう、というのを提案して詰めていくのが、有る意味コンサルテーションとしての醍醐味だったりするわけで。
いずれにしても危機感を多少なりとも持ってる相手の方が、セキュリティ入れた提案は進めやすいですよね。やはりそうじゃないときに、どうやって振り向かせるか、「情報漏洩しますよ？いいんですか？」と開き直れるかなどがポイントになるのかなあ？
