脆弱性の対策と運用2020.3.14ここでは、脆弱性の「情報」をベースにした「脆弱性管理」が、なぜ情報セキュリティ対策として有効なのか、他のセキュリティ対策の具体的な問題点を挙げ、説明します。脆弱性の対策の方法は?情報セキュリティにおける脆弱性(セキュリティホール)の対策には、一般的に3つの方法が挙げられます。実は、上記すべての対策における基点となっているものは「脆弱性情報」です。レガシーな脆弱性スキャナーによる診断では、実際に攻撃コードを実行して診断することは一般的ではありません。これは、実際に攻撃コードを動作させてしまうと本当に対象システムをダウンさせてしまう危険性があるためです。対象をダウンさせてしまうと、限られた時間内で行う診断そのものの進捗に影響を与えてしまい、脆弱性診断サービスとして成立しなくなってしまいます。したがって多くの場合、問題が発生することの確証を得るための脆弱性情報(特定の文字列やバージョン情報など)を持ち、診断ツールがそれらの複数の要素を検証し、診断の精度を上げるようになっています。これがいわゆる疑似攻撃の仕組みです。防御ソリューション・製品では、正常なアクセスを正しく疎通させることが最優先されます。制御が複雑化しているアプリケーションレイヤーの製品であるWAFや仮想パッチなどではブラックリスト型のアクセス制御が好まれる傾向にあり、このブラックリストは特定の文字列パターンや長さ等を脆弱性情報を元に作成されたものです。修正プログラムやパッチなどのアップデートプログラムは、そのアップデート内容がセキュリティに関するものであれば、対象となるプロダクトにおいて影響を受けるアーキテクチャやバージョン情報などの脆弱性情報と同じタイミングで公開されます。これらは適用する際に影響の有無を判断する必要があるためです。スキャナーによる脆弱性診断は脆弱性が検出されない可能性があるレガシー脆弱性スキャナーを利用した脆弱性診断は、一般的に疑似攻撃であるがために避けて通れない問題があります。それが《誤検知》です。誤検知には2種類あり、本来は脆弱性があるにも関わらず検出されなかった場合(フォルス・ネガティブ)と、脆弱性がないにも関わらず検出した場合(フォルス・ポジティブ)に分類されます。リスクの観点から言えば、フォルスポジティブは問題は生じませんがフォルスネガティブは結果的にリスクを見逃すことになってしまいます。脆弱性を診断する場合を挙げます。Apacheでは、HTTPレスポンスを返す場合には標準でServerヘッダを返すように設定されています。text/html上記のようなレスポンスが返れば脆弱性診断では、Apacheのバージョン2.2.29が動作しているのであろうと推測します。その上でバージョン2.2.29に存在する脆弱性情報を照らし合わせて脆弱性の存在を推定したり、さらに深追いして別のパターンを試したりします。ApacheではServerヘッダにバージョンを出さないように設定することができます。脆弱性診断においては、バージョンがわからないため他の手法を試していくしかありません。一般的に検出確度の高いものから試していきますが、最終的に診断パターンが無くなった時、診断は完了します。診断にて「わからない状態」が続くと実際には脆弱性が残存していても、最終的に検出できない場合があるのです。近年は脆弱性診断(ツール)の精度が上がってきていますが、こうした仕組みである限り診断結果が100%信頼できるものにはならず、脆弱性が残存するリスクはつきまといます。防御ソリューション・製品などでは回避攻撃により、脆弱性を迂回される可能性がある仮想パッチを含め防御ソリューション・製品では、その防御する仕組みはブラックリストだったりホワイトリストだったりヒューリスティックだったり、と様々です。防御製品であったとしてもソフトウェアで動作する以上、それそのものに脆弱性や不具合が存在する可能性があるということは純然たる事実です。ハードウェアアプライアンス製品であってもその中身のソフトウェアが無ければ動作しません。したがって、その防御機構を回避しようとする攻撃(回避攻撃)は常に存在します。過去に存在した回避攻撃の概要を挙げます(なお、現在は修正対応されています)。防御パターンとしてパラメータ内に<script>を含む場合はブロックするように設定するとします。以下のようなリクエストを送信します。複数の同じパラメータ名の値に、文字列を分割して入力します。パラメータはブロックするルールにマッチせずWAFをすり抜けます(回避攻撃)。受け取った場合にはこれら複数のuseridパラメータは一つに纏められ、useridは<scri,pt>として解釈されます。この値をアプリケーションのロジックで連結して使ってしまった場合、見事に防御をすり抜けて<script>として解釈されてしまう、といった事が発生します。脆弱性に対するアプローチとして、リスクを無くすことができるのは脆弱性管理だけしたがって、情報セキュリティ対策として残存するリスクそのものを無くすことができるのは、修正プログラム・パッチなどアップデートを適用した場合のみです。このためには、日々発見される脆弱性の「情報」を起点として、パッチ適用までのワークフローを確立するのが一番の近道となります。記録」といったフローを実行することになります。すべてのシステム運用の現場で徹底されているかというと残念ながらそうではないようです。その原因の一つは、今までこうしたことを行う統合的な脆弱性管理ツールがなかったことによるものです。本質的な問題として、脆弱性を管理して対策を行うためのタスクには、以下のような単純ではない難しさが内在しているのです。脆弱性情報の収集を独自に行おうとすると思った以上に人と時間が必要であることに気づくはずです。なると重要なものに絞って収集するわけですが、結果、情報を網羅的に収集しなくなってしまうため、どのような脆弱性やリスクが残っているのかわからなくなってしまいます。大規模システムでは通常、維持管理チームとして複数人がシステムの運用にあたります。ない場合、運用規模を言い訳に脆弱性管理を行わないことがあります。防御ソリューション・製品での対応が一時的であることが忘れられて恒久的になってしまうケースや、アップデートによる不具合を恐れてアップデートを適用しないケースなど、リスク把握が適切に行われておらず管理も行われません。脆弱性管理を正しく行うには何らかの管理の仕組みが必要ですが、その仕組みに多くの工数を伴うため管理が実施されなくなってしまいます。開発しお客様に提供しております。脆弱性情報を起点として、情報資産(ホスト)内のソフトウェア脆弱性の特定を行う機能を備えます。脆弱性の検出から対処まで記録は自動的に行い、脆弱性別やホスト別に脆弱性への対処状況・危険性を包括的に視認でき、運用管理機能も備えています。今後はどうなっていくのか?組織のエンドポイントを含めたIT資産の脆弱性を人手だけで管理・対策する時代は終わりました。膨大な脆弱性情報から自動的に特定し、リスクに応じた対応までを自動化する工程を取り入れなければ、現在、最も求められている組織全体の情報資産の衛生管理は不可能です。ような脆弱性管理ツールを積極的に利用し、対策までの自動化を図り効率化を行う必要があるでしょう。脆弱性管理といえども万能ではありません。脆弱性情報としてまだ挙がってこない、または修正プログラムがまだ提供されていない脆弱性(ゼロデイ)への対処は別途必要になります。各製品ベンダーのセキュリティへの取り組みの改善により、以前よりもゼロデイで放置される製品は減っており、修正パッチの提供も早くなってきているように思えますが、これらに有効に作用する対策ソリューションを導入しておくことは望ましいと考えられます。管理対象のホストで使用するソフトウェアで新しく報告された脆弱性のピックアップを行い、影響判定や対策工程の把握まで、脆弱性管理をトータルでカバーいたします。脆弱性の調査やパッチ探しは一切不要!脆弱性対策を自動化できるので工数大幅削減!さらに自社の脆弱性状況を全て可視化できるので管理がグッと楽になる!それらを全て実現するサービスがあります。各種サービスの使用法や購入において気になる点などお気軽にお問い合わせ下さい。実際に無料で使ってみてください。