いっぱいなのですよw
あれこれと…
仕様にないから瑕疵ではない…ってw
教訓はなぜ生かされなかったのか(日経ITProの記者の眼)の中にある「ベンダの言い分」がいい感じに香ばしい…。
契約内容にもよるけど、論点はいくつかあって…
「サーバーとネットワークはNECネクサソリューションズの資産またはリース物件で,システムはすべてNECネクサソリューションズが所有,作成,または選定したもの。当社はNECネクサソリューションズからソースコードの開示を受けていない。またアクセスログはネクサが保有し,管理している。ネクサは当社に対しアクセスログを提供していない」(ワコール)
システムに関する瑕疵があった場合の保守をどうするか?というあたりが疑問だったりする。ただ、以下の文がその前にあり、これが事実とするならば、システム提供を行った側はシステムの安全な動作を担保していない、というように取られても仕方がない。
実はワコールの担当者は,システムを開発したNECネクサソリューションズに対し,2005年7月末に問い合わせを行っていたという。「うちのシステムは大丈夫か」と。
もっとも、この記者の眼を書いた高橋氏は、
筆者がかかわった範囲での事実を紹介しておくと,2000年の12月に発行された日経オープンシステム(4月から日経SYSTEMSとして新創刊)という雑誌で,Webアプリケーションのセキュリティに関する特集記事を執筆したことがある。この特集でSQL文を外部から入力される危険性について紹介している。取材の際,多くのセキュリティ専門家がこの問題を「基本的な問題」と指摘していた。
NECネクサソリューションズが主張するように,2000年8月当時,SQLインジェクションという手口がセキュリティ専門家以外にどれだけ知られていたかについては議論の余地があろう。ただし,SQLインジェクションは「'」などSQL文組み立てに使用される特殊文字を無効化することで防ぐことができる。データとして本来有効な文字種だけを受け付けるようにしていれば被害を防げたと考えられ,サムターン回しに例えることが適切なのかどうかも議論になろう。
としている。
2000年内の見直し/対策はムリにしても、それから2〜3年というスパンで見直しを行うのは可能だったはずだし、それ以前に「入力チェック」「出力チェック」については、別にWebアプリケーションに限らず、レガシでは普通に実施されていたことでもある。システム提供を行った会社自体は
日々新しいセキュリティ・ホールが発見されている。あらゆるケースをすべて網羅して穴をふさぐことはできない
ということを述べてはいるが、発見された時点で「自分の管理下にあるもの」について点検をすることは可能だし、「問合せがあったもの」については契約に従ってサポートを行う、というのが当然の義務であろう。
ちなみに1点だけ惜しい、と思ったのは、
しかし,システムがインターネット上で稼動している中で,状況にあわせてシステムを変化させていくことは,セキュリティ確保だけでなく,ビジネスの面でも必須だ。ハードウエアのように“売り切る”商習慣が制度疲労を起こしていると言える。ユーザーが必要としているものはモノではない。日々価値を生み出すプロセスである。変化への対応を織り込んだ,サービスとしての利用が最も適切な契約形態だろう。
この点である。ワコールの事件は、サービスとして提供されているものを利用していても発生した。サービスとして提供されているからといって、サポート内容に不安があるケースも(残念ながら)存在する。この部分は、実際にサービスを使ってみてのベンダ対応などについて、ユーザ企業間で情報交換を行ったりということが有用だろう。
…つぅか、ベンダのセールストークを鵜呑みにして痛い目にあった人/会社なぞ、山ほどあるんですがorz
DSA-965-1 New ipsec-tools packages fix denial of service
これ、以前書いたIKE実装の脆弱性チェックの結果、racoonに発見された脆弱性がDebianのipsec-toolsにも存在してたって話すね。
思い当たる人はアップグレードを。