　まず、「脆弱性対策情報の公開」。脆弱（ぜいじゃく）性とは、OSやWebブラウザ、アプリケーションなどに残ってしまった「弱点」だ。そこを攻撃されることにより、アプリケーションが使えなくなるだけならまだしも、さらに別のプログラムを実行されたり、管理者権限を不正に奪取されたりすることで、端末やサーバのコントロール権を奪われてしまう。脆弱性は簡単に攻撃できるものから、理論上は攻撃が可能というレベルのものまでたくさん存在する。

　基本的に脆弱性は、修正プログラムの適用によって修正されるものだ。一般的には「現バージョンには●●という脆弱性がある」というアナウンスが「緊急度」や「予想される被害範囲」の開示とともに行われる。この際、脆弱性そのものの詳細については伏せられる。

　該当製品やサービスを利用するユーザーは、このアナウンスを基にして、修正プログラムを即座に適用するかどうかを判断する。だが、多くの組織では修正プログラムを適用した結果、何が起きるのかを確認するためのテストを実施する。修正プログラムの適用によって、業務システムに想定外の不具合が発生することを回避するためだ。

　このタイムラグを攻撃者は見逃さない。例えば、オープンソースのプログラムでは、修正プログラムのソースも確認できる。知識を持ったクラッカーであれば、ここから実際にどのような攻撃が可能になるかを推測できるわけだ。

　最近では、解析から攻撃コード、つまり「マルウェア」を作るまでにさほど時間はかからない。近年、組織が修正プログラムを適用するタイミングよりも前に大規模な攻撃が行われてしまう事例が増えている。例えば、複数の脆弱性が明らかになっている「Apache Struts 2」では、脆弱性公開の翌日にはネットワーク上で攻撃が観測され、3日後には重要インシデントが発生した。

　根本対策は「修正プログラムを可及的速やかに適用する」ことだが、現実問題として影響度合いが把握できなければパッチの適用が難しいのも事実だ。時間を稼ぐための手段としてWebアプリケーションファイアウォール（WAF）の導入といった緩和策の検討が必要だろう。

　また、脆弱性情報が明らかになった時に、修正プログラムを適用する以外の一時的な回避策があるかどうかを調べることも重要だ。そのためにも、自社で利用しているプログラムについて普段から脆弱性情報の収集と把握をきっちり行っておきたい。