仮想パッチ：ゼロデイ攻撃への即時対応

アプリケーション脆弱性への恒久的なパッチを適用するには数か月かかることがあり、その間デジタル資産が攻撃を受ける可能性を残すことになります。そのような場合は、仮想パッチが有効になります。

アプリケーションの脆弱性が発見された場合、望ましいのはすぐに恒久的なパッチをあててコードを修正することです。ですが、パッチをあてるのにサーバーの停止が必要だったり、事前の検証が困難だったりすると、簡単にはいきません。商用アプリケーションの場合は、ソースコードを自分で変更することはできず、ベンダーが公式パッチをリリースするまで待たなければならないでしょう。その間、アプリケーションは攻撃の危険にさらされます。

仮想パッチを適用!

Webアプリケーションのファイアウォールと呼ばれることもある仮想パッチは、主にWebアプリケーションを保護するために使用されます。悪用を防止するセキュリティポリシー実施層を利用して、既知の脆弱性をついた攻撃を迂回する方法を提供します。これは、まだ修正が行われていないアプリケーションに対するゼロデイ攻撃への大きな対抗策です。このパッチはトランザクションを分析して、攻撃を途中でインターセプトし、悪意あるトラフィックがターゲットとするアプリケーションに到達できないようにします。

仮想パッチの重要な役割

Webアプリケーションのソースコードを即座に編集して恒久的なパッチをあてるのは様々な事情により難しい場合が多く、仮想パッチの適用は重要です。仮想パッチは拡張もしやすく、すべてのホストにパッチを適用するのではなく、いくつかの場所にインストールすればすみます。

ビジネス上もいくつかのメリットがあります。

　·　パッチをあてるために停止することができない重要なシステムを保護
　·　緊急パッチ適用のための時間と費用を節約
　·　ベンダー提供のパッチがテストしてリリースされるまで、リスクを軽減
　·　ライブラリやサポートコードファイルの変更がないので、コンフリクトも発生しにくい
　·　急ぐことなく、通常のパッチ適用サイクルを維持

ソースコードに修正を加える通常のパッチ適用では、コードの変更後に広範な回帰テストが必要なケースも多く、適用前の検証に数ヶ月かかってしまうことさえあります。

仮想パッチの留意点

仮想パッチは、他の多くのセキュリティプロセスと同様、一貫した繰り返し可能なプロセスで行うべきです。ワークフローは、準備、特定、分析、作成、実装、テスト、および回復からなる、ITインシデント対応のための業界の一般的な作業方式に合わせる必要があります。

プロセスは、事前に確立しておくのが理想的です。新たに発見された脆弱性のためにあわてて仮想パッチを行おうとするのは危険です。オープンWebアプリケーションセキュリティプロジェクトによって公開されたバーチャルパッチのベストプラクティスは、仮想パッチの方法論を確立するのに役立つ素晴らしいリソースです。

ステップはそれぞれ重要ですが、作成フェーズには特に注意を要します。仮想パッチを作成するときは、ITセキュリティツールの2つの主要ポイントを守ってください：正当なトラフィックをブロックしない（偽陽性をなくす）ことと、攻撃を見逃さない（偽陰性をなくす）こと。

脆弱性が特定されたら、脆弱性を引き起こす技術データを入手して攻撃が成功するために必要なすべての条件を検索し、作成フェーズを開始します。変動値の変更は1つずつ行う必要があります。これには、文字列、長さの値、文字コード、ホワイトスペースなどが含まれます。

攻撃の成功に重要な変数がすべて特定できたら、全体的に満たされなければならない基準がクリアできたことになります。複数の異なる攻撃ベクトルがある場合は、それぞれを個別に分析します。

次に、偽陰性がゼロの仮想パッチ・ロジックを記述します。関連するWebアプリケーションの攻撃トラフィックが、仮想パッチが探している特性とまったく同じものでなければ阻止できないので、見落としがないよう注意が必要です。偽陰性ゼロの仮想パッチが準備できたら、偽陽性の点でパッチの精度を評価します。

この段階では、通常のWebトラフィックでは発生しない特性を少なくとも1つ特定します。通常トラフィックでは起こり得ず、攻撃の成功に重要な特性が存在する場合、ゼロ偽陰性仮想パッチはゼロ偽陽性シグネチャでもあります。

仮想パッチのセキュリティモデル

仮想パッチは、ネガティブかポジティブのどちらかのセキュリティモデルを採用することができます。どちらを使用するかは、状況によって異なります。

ネガティブ・セキュリティモデル

ネガティブ・セキュリティモデルは、有効なトラフィックのみを許可するのではなく、特定の既知の攻撃を検出する一連のルールに基づいて構築できます。入力フィールドに入力可能な文字を制限するというのが1つの例です。文字セットは閉じたセットなので、許可された文字のホワイトリストを提供することは、事実上、禁止文字のブラックリストを提供することと同等です。

ポジティブ・セキュリティモデル

ポジティブ・セキュリティモデルの仮想パッチは、独立した入力検証エンベロープをアプリケーションに提供する包括的なセキュリティメカニズムです。有効な入力の特性（文字セットや長さなど）を指定し、適合しないものはすべて拒否します。アプリケーションの各ページのすべてのパラメータにルールを指定することによって、アプリケーションはコードから独立した追加のセキュリティ・エンベロープによって保護されます。

両セキュリティモデルの比較

ネガティブ・セキュリティモデルは、通常、より迅速に実装できますが、検出し切れずにすり抜けられてしまう可能性があります。ポジティブ・セキュリティモデルは、より優れたプロテクションを提供しますが、このアプローチは手動プロセスであることが多く、拡張性に乏しいので、大規模なサイトや動的サイトの管理に適用するのは困難です。サイト全体に対して手作業でセキュリティルールを指定することは難しいかもしれませんが、ある特定の場所が脆弱性問題として警告されている場合は、その部分に対して選択的にポジティブ・セキュリティモデルを適用することも考えられます。

正式アップグレードを待つことなくアプリケーションを保護

仮想パッチを適用すると、アプリケーションにパッチをあてなくてもアプリケーションを保護することができます。脆弱性の発見後すぐに恒久的なパッチを適用することができない場合は、特に有用です。仮想パッチ適用のアプローチは、アプリケーション言語でのプログラミングなしに迅速に対処でき、通常のパッチ適用のサイクルを守りながらセキュリティを強化できます。

そして、何よりも、仮想パッチは重要な業務システムを停止することなく適用できます。