SIDfm VMは、脆弱性情報をベースにした脆弱性管理ユーティリティです。脆弱性情報をベースにした「脆弱性管理」がなぜ情報セキュリティ対策として有効なのか、他のセキュリティ対策の具体的な問題点を挙げ、説明します。
SIDfm VMは、脆弱性情報をベースにした脆弱性管理ユーティリティです。ここでは、脆弱性情報をベースにした「脆弱性管理」がなぜ情報セキュリティ対策として有効なのか、他のセキュリティ対策の具体的な問題点を挙げ、説明します。
セキュリティ対策の方法は
情報セキュリティにおける脆弱性（セキュリティホール）の対策には、一般的に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はとして解釈されます。この値をアプリケーションのロジックで連結して使ってしまった場合、見事に防御をすり抜けてとして解釈されてしまう、といった事が発生します。
脆弱性に対するアプローチとして、
リスクを無くすことができるのは脆弱性管理だけ
したがって、情報セキュリティ対策として残存するリスクそのものを無くすことができるのは、修正プログラム・パッチなどアップデートを適用した場合のみです。 「脆弱性情報の収集」・「対象の特定」・「脆弱性と対象の分析」・「脆弱性への対処」・「対処状況の記録」といったフローを実行していく脆弱性管理は以前と比べれば一般的になってきました。しかし、すべてのシステム運用の現場で徹底されているかというと残念ながらそうではないようです。
なぜ、まだ脆弱性管理が行われないケースがあるのでしょうか？これは、幾つか要因が考えられます。
- 脆弱性情報の網羅性の問題
脆弱性情報の収集を独自に行おうとすると思った以上に人と時間が必要であることに気づくはずです。そうなると重要なものに絞って収集するわけですが、結果、情報を網羅的に収集しなくなってしまうため、どのような脆弱性やリスクが残っているのかわからなくなってしまいます。 - 運用体制の問題
大規模システムでは通常、維持管理チームとして複数人がシステムの運用にあたります。そうでない場合、運用規模を言い訳に脆弱性管理を行わないことがあります。 - リスク把握の問題
防御ソリューション・製品での対応が一時的であることが忘れられて恒久的になってしまうケースや、アップデートによる不具合を恐れてアップデートを適用しないケースなど、リスク把握が適切に行われておらず管理も行われません。 - 管理効率の問題
脆弱性管理を正しく行うには何らかの管理の仕組みが必要ですが、その仕組みに多くの工数を伴うため管理が実施されなくなってしまいます。
SIDfm での脆弱性管理は、網羅的な情報を、一人運用からでも、リスクを的確に示しつつ、効率的に、運用することができます。
ただし、脆弱性管理といえども万能ではありません。脆弱性情報としてまだ挙がってこない、または修正プログラムがまだ提供されていない脆弱性（ゼロデイ）への対処は別途必要になります。各製品ベンダーのセキュリティへの取り組みの改善により、以前よりもゼロデイで放置される製品は減っており、修正パッチの提供も早くなってきているように思えますが、これらに有効に作用する対策ソリューションを導入しておくことは望ましいと考えられます。