脆弱性検査は“黒”から“白”へ（その1）：三輪信雄「ここが変だよみんなの対策」（情報元のブックマーク数）
三輪さんが脆弱性検査を始めた経緯とか、色々。昔は確かにApacheの脆弱性とか色々ありましたし、FireWallが甘かったりしましたよねぇ。
国内で最初に脆弱性検査をセキュリティビジネスとして展開してきました。最初にホームページにそうしたサービスを掲載したのは96年のことで、当時はファイアウォール検査サービスなどと呼んでいました。まだ、Webアプリケーションの脆弱性などは認識されていないころでした。
脆弱性検査は“黒”から“白”へ（その1） | 日経 xTECH（クロステック）
Webアプリケーションの脆弱性は問題視されていなくとも、サービスを提供できなくするDoS（Deny of Service）攻撃を受ける脆弱性などがOSやミドルウエアなどの基盤ソフトに存在しました。たった数バイトのパケットを送りつけるだけでWindows NTがブルースクリーンになったり、Apacheを標準設定でインストールするとCGI経由でコマンド入力を許すような脆弱性があったり、メールサーバーのsendmailにもバッファオーバフローやコマンド入力を許す脆弱性があったりした時代でした。
そのころから、それらの脆弱性を突いたホームページの改ざんが日常的に起こりました。そのような被害に遭うサイトが日本でも増えたために、脆弱性がないかどうかを調べるサービスをいろいろな会社が提供し始めました。
当時は見つかる脆弱性と言えば、OSそのものやApache、sendmailなどのサービスを提供する上で基盤となるソフトのバージョンが古かったり、FTPやtelnetでアクセスするためのパスワードの設定が甘い、といったものがほとんどでした。
そのようなことを調べるために脆弱性検査サービスは活況を呈していましたが、今では、Webアプリケーション関連の脆弱性を調べることが多くを占めるようになりました。Webアプリケーションの脆弱性については、今さらここで説明する必要はないでしょう。
確かにタスクとして脆弱性検査結果を処理する人にとっては、指摘項目から類推できる類似した脆弱性に対応するとは思えないし、指摘した項目も全部網羅するとは思えないですね。
それだけコストをかけて検査したにもかかわらず、検査によって発見された脆弱性を指摘された当事者は、「指摘された項目だけ」修正しようとします。多くの企業や組織でそのような対応をしていることでしょう。ところが、その後に起こることは以下のような事象です。
これらは珍しいことではなく、むしろよくあることです。そのために「定期検査」が行われるのですが、その費用も基本的には営業的なディスカウントはあっても、基本的には相応の費用がかかります。そして、上記のような事象が繰り返されています。
脆弱性検査は“黒”から“白”へ（その1） | 日経 xTECH（クロステック）
こういう素晴らしい考え方ができる余裕がある会社も少ないとは思いますが、検査だけで脆弱性を作りこむ仕組みを変えることはできないということですね。
理想的な考えからすれば、一つの小さな問題を広く大きくとらえて、みんなで話し合い、同様の事象が他にないか点検・修正し、今後の行動に役立てることが重要になります。しかし、開発の現場では「バグは日常茶飯事」のこと。仕様変更やバグ対応などで追われる現場では、言われたことだけに対応するだけで手一杯なのです。これは、開発の現場の立場に立つとよく分かります。しかも、最近の経済不況を受け、受注単価も下降傾向にあります。そのような中で独自に品質を上げる取り組みができている優良な開発企業は多くはありません。脆弱性検査をセキュリティ品質の向上に役立てるのには限界があるということです。
脆弱性検査は“黒”から“白”へ（その1） | 日経 xTECH（クロステック）
