企業のセキュリティ対策概論（3/5 ページ）

[Mayank-Sharma，Open Tech Press]

より優れた製品に対する圧力

　組織のセキュリティ確保に当たっては、予防的対策の実施に勝るものはない。その一方でクルス氏が勧めているのは、組織同士が手を携え、本質的にセキュアなアプリケーションの供給をソフトウェアサプライヤーに迫ることだ。

　「その方法の1つが、ソフトウェアサプライヤーが自社製品にかんして把握している脆弱性の情報を無理にでも公開させることだ。ここでいっているのはエクスプロイトコードのことではなく、eEyeが更新している脆弱性情報のページのようなものだ」（クルス氏）

　クルス氏はそうした対策の必要性を、例を挙げて説明している。会社や製品の名前は出さなかったが、彼は幾つかのセキュリティ業務を請け負ってきたという。その中に、A社の製品（既存ユーザー数は1000程度）を評価してほしいという依頼があったとしよう。その製品から複数の重大な脆弱性が見つかると、A社は、その製品の購入に当たってコンサルタント（この場合はクルス氏）に評価を依頼していた会社と一緒になって“ダメージコントロール”（損害回避）の活動を行うのだという。場合によっては、その会社に対してA社が取引上の便宜を図ったり、見つかった問題に対処する特別なパッチを提供することになる。

　もっと深刻な問題は、A社が脆弱性の情報を既存の1000におよぶ顧客には公開しないことである。最終的に（半年〜1年後になることもある）そうしたパッチは公式リリースに取り込まれるが、その際、セキュリティ上の修正が行われたことや、アップグレードを適用しないと顧客が危険にさらされ続けるという事実は公表されないのが普通だ。一方、セキュリティコンサルタントの方も、機密保持契約（NDA：Non-Disclosure Agreement）を幾つも結んでいて、評価結果に関する情報は一切公表できない。

　「関係者全員のモラルの問題もあるが、最大の問題は、このやり方が業界における“セキュアな”製品の開発のためにならないことだ。例えば、B社が（A社の製品と）同じような製品を開発したとしよう。B社の製品はセキュリティ面で優れているものの、使い勝手とパフォーマンスの点では劣っているとする。両製品の真のセキュリティ性能が考慮されない場合、よりセキュアであるにもかかわらず、B社の製品を顧客が選ぶことはないだろう」（クルス氏）