ここでは、脆弱性の「情報」をベースにした「脆弱性管理」が、なぜ情報セキュリティ対策として有効なのか、他のセキュリティ対策の具体的な問題点を挙げ、説明します。

脆弱性の対策の方法は？

情報セキュリティにおける脆弱性（セキュリティホール）の対策には、一般的に3つの方法が挙げられます。

1. レガシー脆弱性スキャナー診断による脆弱性の特定
2. 防御ソリューション・製品などによるブロック
3. 修正プログラム・パッチ（アップデート）の適用

実は、上記すべての対策における基点となっているものは「脆弱性情報」です。

レガシーな脆弱性スキャナーによる診断では、実際に攻撃コードを実行して診断することは一般的ではありません。これは、実際に攻撃コードを動作させてしまうと本当に対象システムをダウンさせてしまう危険性があるためです。対象をダウンさせてしまうと、限られた時間内で行う診断そのものの進捗に影響を与えてしまい、脆弱性診断サービスとして成立しなくなってしまいます。したがって多くの場合、問題が発生することの確証を得るための脆弱性情報（特定の文字列やバージョン情報など）を持ち、診断ツールがそれらの複数の要素を検証し、診断の精度を上げるようになっています。これがいわゆる疑似攻撃の仕組みです。

防御ソリューション・製品では、正常なアクセスを正しく疎通させることが最優先されます。特に制御が複雑化しているアプリケーションレイヤーの製品であるWAFや仮想パッチなどではブラックリスト型のアクセス制御が好まれる傾向にあり、このブラックリストは特定の文字列パターンや長さ等を脆弱性情報を元に作成されたものです。

修正プログラムやパッチなどのアップデートプログラムは、そのアップデート内容がセキュリティに関するものであれば、対象となるプロダクトにおいて影響を受けるアーキテクチャやバージョン情報などの脆弱性情報と同じタイミングで公開されます。これらは適用する際に影響の有無を判断する必要があるためです。

スキャナーによる脆弱性診断は脆弱性が検出されない可能性がある

レガシー脆弱性スキャナーを利用した脆弱性診断は、一般的に疑似攻撃であるがために避けて通れない問題があります。それが《誤検知》です。誤検知には2種類あり、本来は脆弱性があるにも関わらず検出されなかった場合（フォルス・ネガティブ）と、脆弱性がないにも関わらず検出した場合（フォルス・ポジティブ）に分類されます。 リスクの観点から言えば、フォルスポジティブは問題は生じませんがフォルスネガティブは結果的にリスクを見逃すことになってしまいます。

簡単な例として、Apache HTTP Server (以下Apache) の脆弱性を診断する場合を挙げます。 Apacheでは、HTTPレスポンスを返す場合には標準でServerヘッダを返すように設定されています。

 HTTP/1.1 200 OK
 Date: Thu, 05 Mar 2015 01:14:05 GMT
 Server: Apache/2.2.29
 Last-Modified: Wed, 28 Jan 2015 05:20:31 GMT
 ETag: "3004c93a-6d9f-50daf87b865c0"
 Accept-Ranges: bytes
 Content-Length: 28063
 Vary: Accept-Encoding
 Content-Type: text/html 

上記のようなレスポンスが返れば脆弱性診断では、Apacheのバージョン2.2.29が動作しているのであろうと推測します。 その上でバージョン2.2.29に存在する脆弱性情報を照らし合わせて脆弱性の存在を推定したり、さらに深追いして別のパターンを試したりします。 このとき、返すServerヘッダが標準状態でない場合はどうでしょうか？ ApacheではServerヘッダにバージョンを出さないように設定することができます。脆弱性診断においては、バージョンがわからないため他の手法を試していくしかありません。一般的に検出確度の高いものから試していきますが、最終的に診断パターンが無くなった時、診断は完了します。つまりは診断にて「わからない状態」が続くと実際には脆弱性が残存していても、最終的に検出できない場合があるのです。 近年は脆弱性診断（ツール）の精度が上がってきていますが、こうした仕組みである限り診断結果が100%信頼できるものにはならず、脆弱性が残存するリスクはつきまといます。

防御ソリューション・製品などでは回避攻撃により、脆弱性を迂回される可能性がある

仮想パッチを含め防御ソリューション・製品では、その防御する仕組みはブラックリストだったりホワイトリストだったりヒューリスティックだったり、と様々です。 しかし、防御製品であったとしてもソフトウェアで動作する以上、それそのものに脆弱性や不具合が存在する可能性があるということは純然たる事実です。 例えハードウェアアプライアンス製品であってもその中身のソフトウェアが無ければ動作しません。 したがって、その防御機構を回避しようとする攻撃（回避攻撃）は常に存在します。

具体例として、オープンソースの WAF である ModSecurity に過去に存在した回避攻撃の概要を挙げます（なお、現在は修正対応されています）。 防御パターンとしてパラメータ内に<script>を含む場合はブロックするように設定するとします。

 SecRule REQUEST_URI "<script>" 

この時、WAFを経由するサービスの URL へ以下のようなリクエストを送信します。 つまり、複数の同じパラメータ名の値に、文字列を分割して入力します。

 http://www.anywhere/application?userid=<scri&userid=pt> 

脆弱なバージョンの製品を使っている場合には、上記の userid パラメータはブロックするルールにマッチせずWAFをすり抜けます（回避攻撃）。この後、影響を受けるかどうかは受け手のアプリケーションサーバの種類にも依りますが、IIS で受け取った場合にはこれら複数のuseridパラメータは一つに纏められ、useridは<scri,pt>として解釈されます。この値をアプリケーションのロジックで連結して使ってしまった場合、見事に防御をすり抜けて<script>として解釈されてしまう、といった事が発生します。

脆弱性に対するアプローチとして、リスクを無くすことができるのは脆弱性管理だけ

したがって、情報セキュリティ対策として残存するリスクそのものを無くすことができるのは、修正プログラム・パッチなどアップデートを適用した場合のみです。このためには、日々発見される脆弱性の「情報」を起点として、パッチ適用までのワークフローを確立するのが一番の近道となります。これを実施するためには、「脆弱性情報の収集」・「対象の特定」・「脆弱性と対象の分析」・「脆弱性への対処」・「対処状況の記録」といったフローを実行することになります。しかし、すべてのシステム運用の現場で徹底されているかというと残念ながらそうではないようです。

なぜ、まだ脆弱性管理が行われないケースがあるのでしょうか？ その原因の一つは、今までこうしたことを行う統合的な脆弱性管理ツールがなかったことによるものです。ただ本質的な問題として、脆弱性を管理して対策を行うためのタスクには、以下のような単純ではない難しさが内在しているのです。

• 脆弱性情報の網羅性の問題

  脆弱性情報の収集を独自に行おうとすると思った以上に人と時間が必要であることに気づくはずです。そうなると重要なものに絞って収集するわけですが、結果、情報を網羅的に収集しなくなってしまうため、どのような脆弱性やリスクが残っているのかわからなくなってしまいます。

• 運用体制の問題

  大規模システムでは通常、維持管理チームとして複数人がシステムの運用にあたります。そうでない場合、運用規模を言い訳に脆弱性管理を行わないことがあります。

• リスク把握の問題

  防御ソリューション・製品での対応が一時的であることが忘れられて恒久的になってしまうケースや、アップデートによる不具合を恐れてアップデートを適用しないケースなど、リスク把握が適切に行われておらず管理も行われません。

• 管理効率の問題

  脆弱性管理を正しく行うには何らかの管理の仕組みが必要ですが、その仕組みに多くの工数を伴うため管理が実施されなくなってしまいます。

弊社では上記の問題を全て解決した SIDfm VM を開発しお客様に提供しております。脆弱性情報を起点として、情報資産（ホスト）内のソフトウェア脆弱性の特定を行う機能を備えます。脆弱性の検出から対処まで記録は自動的に行い、脆弱性別やホスト別に脆弱性への対処状況・危険性を包括的に視認でき、運用管理機能も備えています。

脆弱性情報とマッチング、即座に特定、危険度の評価が可能

今後はどうなっていくのか？

組織のエンドポイントを含めたIT資産の脆弱性を人手だけで管理・対策する時代は終わりました。膨大な脆弱性情報から自動的に特定し、リスクに応じた対応までを自動化する工程を取り入れなければ、現在、最も求められている組織全体の情報資産の衛生管理は不可能です。SIDfm VM のような脆弱性管理ツールを積極的に利用し、対策までの自動化を図り効率化を行う必要があるでしょう。

ただし、脆弱性管理といえども万能ではありません。脆弱性情報としてまだ挙がってこない、または修正プログラムがまだ提供されていない脆弱性（ゼロデイ）への対処は別途必要になります。各製品ベンダーのセキュリティへの取り組みの改善により、以前よりもゼロデイで放置される製品は減っており、修正パッチの提供も早くなってきているように思えますが、これらに有効に作用する対策ソリューションを導入しておくことは望ましいと考えられます。