バーチャルパッチは、脆弱性にパッチを適用できるようになるまで、ポリシーやルール、セキュリティツールを使って脆弱性へのアクセスを遮断する。
ゼロデイ脅威とレガシーシステムは、パッチがしばらく存在しない、あるいは永遠に提供されない可能性のある脆弱性が生じる二つの要因だ。そのような場合、セキュリティチームは恒久的な修正が見つかるまで、潜在的な攻撃経路を遮断できる。
サイバー犯罪者は、パッチが利用可能になり、セキュリティチームがテストして導入できるようになる前に、脆弱性やバグ、エラー、設定ミス、未検査のコードを急いで悪用する。そのためセキュリティチームは同じ速さで対応し、パッチを適用できるまで、脆弱性への潜在的な攻撃経路を遮断しなければならない。こうした防御策は、バーチャルパッチと呼ばれる。ここでは、セキュリティチームがこうした防御策を導入する方法に焦点を当てる。
バーチャルパッチの仕組み
外部パッチ、あるいはジャストインタイムパッチとも呼ばれるバーチャルパッチという用語は、数年前に侵入防止システム（IPS）ベンダーが作り出した。バーチャルパッチは、ルールや緩和策、防御措置を使うことで、パッチの開発と導入に伴う複雑で時間のかかるプロセスを回避する。多くの場合、IPSやファイアウォールのレベルでネットワークを補強し、攻撃者やマルウェアがこうした脆弱性にアクセスするのを防ぐ。
バーチャルパッチは、特定のエクスプロイトから保護するという点で、ベンダーが提供するパッチに似ている。主な違いは、バーチャルパッチが脆弱性を含むデバイスや資産ではなく、通常はIPSまたはファイアウォールルールを使ってネットワークレベルで導入されることだ。
IPSソリューションは、悪意のある活動を遮断しながらトラフィックを監視・検査するよう設計されている。バーチャルパッチを使えば、IPSは特定の脆弱性を狙う試みを識別して阻止できる。これにより、資産自体にパッチを適用するのではなく、脆弱な資産の周囲に保護層を形成できる。IPSのシグネチャやバーチャルパッチは、次の機能を組み込んだ次世代ファイアウォール（NGFW）、Webアプリケーションファイアウォール（WAF）、または従来型の単体IPSアプライアンスの侵入防止（IPS）機能を使って、ネットワークレベルで導入できる。
バーチャルパッチは、業務上重要なネットワークトラフィックを優先し、脆弱な資産を保護する能力において効果を発揮し、モバイル、クラウド、ハイブリッド、Webなど異なる環境に迅速かつ正確に導入できるようコーディングされていなければならない。また、Webやネットワークのトラフィックに潜む悪意のあるパケットや攻撃の試みを停止するため、ディープパケットインスペクションを実行できる必要もある。
こちらも読む：脆弱性対策の答えは、サービスとしてのパッチ管理か？
バーチャルパッチのベストプラクティスと段階
バーチャルパッチを正しく実施するには、準備、識別、分析、バーチャルパッチの作成、実装とテスト、復旧とフォローアップという複数の段階を踏む必要がある。
準備
バーチャルパッチは、継続的な攻撃型セキュリティアプローチの一部であるべきだ。つまり、脆弱性が悪用されてから対応するのではなく、悪用される前に防ぐ必要がある。セキュリティの基盤づくりは準備段階で行う。
重要なステップは、すべてのアップデート、パッチ、脆弱性アラートを確実に設定することだ。さらに、承認の遅れを避けるため、バーチャルパッチを事前承認しておくこともできる。バーチャルパッチは資産のコード自体に影響しないため、影響を受けるアプリを徹底的にテストする必要はない。また、実際のパッチが開発・テストされている間、資産の保護にも役立つ。
Open Web Application Security Project（OWASP）は、「バーチャルパッチをアンチウイルスのアップデートやネットワークIDSのシグネチャと同じグループに分類すれば、承認プロセスを迅速化し、テスト段階の長期化を最小限に抑えられる」と推奨している。
バーチャルパッチのツールは導入して稼働させておく必要がある。たとえば、Apacheサーバー向けのModSecurity WAF（Apache以外のサービスでも動作する）や、OWASPのESAPI WAFなどは、インストールして有効化しておくのが望ましい。そうすれば、必要になったときすぐに使える。
識別
脆弱性を識別する方法には、プロアクティブとリアクティブの二つがある。推奨されるのはプロアクティブな識別アプローチだ。この方法では、組織が侵入テストや脆弱性スキャンを実施し、その他のツールも使って、攻撃者に悪用される前に弱点を特定する。リアクティブな識別は、ベンダーや商用アプリケーションソフトウェアの開発者、あるいはセキュリティインシデントによって脆弱性がすでに公表された後に行われる。
分析
脆弱性が特定されたら、パッチを導入する前に分析する必要がある。組織は、どの程度露出しているか、どこに存在するか、どのシステムに影響するか、どのように悪用される可能性があるかを確認しなければならない。その欠陥が業務上重要な資産に影響するかどうかを分析することも不可欠だ。
次に、セキュリティチームはバーチャルパッチのツールがその欠陥を検出できるか判断する必要がある。脆弱性情報を使えば、バグ追跡システムでインシデントを監視し、通知することもできる。脆弱性識別子（CVE名／番号）も再確認しなければならない。
さらに、影響を受けるソフトウェアとシステムの一覧を作成し、問題を引き起こす設定を列挙する必要がある。脆弱性の公表では通常、エクスプロイトコードも明らかになる。このデータを使ってバーチャルパッチを開発・テストできる。
バーチャルパッチの作成
識別段階では、優先度、リスク、修正までの時間というパラメーターを判断できる。リアルタイム環境ではリスクが高く、完全な修正を適用できない場合もある。部分的な修正によって、より包括的なパッチを開発するための時間を確保できる。バーチャルパッチはリスクを低減するためのものなので、必要であれば妥協する準備も必要だ。
バーチャルパッチの開発には、ポジティブ（許可）アプローチとネガティブ（ブロック）アプローチという二つのルールがある。マルウェアが検知を回避するようコーディングされている場合でも、バーチャルパッチは正当なトラフィックを決して遮断してはならず、攻撃を見逃してもならない。
ポジティブ方式の手動バーチャルパッチでは、文字セットや長さなどの有効な入力をモデルにコーディングし、それ以外はアクセスを拒否する。一方、ネガティブ方式のセキュリティブロックでは、パッチルールのリストが特定の攻撃を検知し、それだけをブロックする。ネガティブパッチはより簡単かつ迅速にコーディングできるが、回避されやすい。これに対してポジティブパッチは手動でコーディングするため、大規模な環境では時間内に導入するのが現実的でない場合がある。
企業は、自動脆弱性検出ツールが作成したXMLレポートを使う、バーチャルパッチ作成の自動化ツールからも恩恵を受けられる。こうした自動パッチは、脆弱性データをバーチャルパッチに自動変換して作成される。自動バーチャルパッチ作成ツールの例としては、OWASP ModSecurity Core Rule Set（CRS）スクリプト、ThreadFix Virtual Patching、そして多くのベンダーが提供するWAFデバイスへの直接インポートがある。
実装とテスト
バーチャルパッチを実装するためのツールにはさまざまなものがある。Webブラウザー、CurlやWgetなどのコマンドラインWebクライアント、ローカルプロキシサーバー、ModSecurity AuditViewerなどだ。
テストについては、脆弱性スキャンツールを使った場合や侵入テストで欠陥を検出した場合、バーチャルパッチが機能していることを確認するため、スキャンとテストを再実行すべきだ。通常のトラフィックを遮断していないことを確認するため、バーチャルパッチを実装する際は、まずログのみの設定にする必要がある。
復旧とフォローアップ
バーチャルパッチは、実装とテストで終わりではない。サイバー犯罪者は、進化するマルウェアのエクスプロイトバージョンに合わせて攻撃を更新する。バーチャルパッチはフォローアップし、監視しなければならない。また組織は、サイクルを再開する必要が生じた場合に備え、プロセス全体を文書化しておくべきだ。
トラフィックが不適切な影響を受けていないことを確認するため、バーチャルパッチの性能も管理しなければならない。さらに、バーチャルパッチは一時的な修正であることが多いため、元の資産向けパッチがリリースされ、インストール済みかどうかを確認する必要がある。
パッチ未適用の脆弱性に何が起こり得るか？
サイバー犯罪者は、攻撃を実行するための脆弱性を常に探している。ゼロデイ攻撃はますます一般的かつ危険になっている。さらに、HackerOneのようなバグバウンティプログラムで活動する倫理的ハッカーも、毎日脆弱性を明らかにしている。これらすべての問題が攻撃者によって悪用される。
業務上重要なセキュリティ上の欠陥にパッチを適用しない場合、その結果は深刻だ。大量の機密データ流出、データ窃取、ランサムウェア、罰金、評判と金銭の損失から、システム侵害による業務停止まで及ぶ。大手ベンダーの多くはバーチャルパッチサービスを提供している。自社でバーチャルパッチを開発するリソースを持たない企業にとって、こうしたサービスは有効だろう。
開発者やテクノロジー企業は、正式なパッチをリリースできるようになるまで脆弱性をふさぐため、一時的なパッチや緩和策を提供することが多い。そのため、セキュリティチームはバーチャルパッチの取り組みにおいて一定の支援を得られる。
こちらも読む：
バーチャルパッチのメリットとデメリット
脅威環境が急速に変化しているため、バーチャルパッチが重要であることは間違いない。しかし、バーチャルパッチは一時的な修正として設計されている。脆弱性そのものにパッチを適用するのではなく、トラフィックが脆弱性にアクセスして悪用するのを防ぐものだ。
バーチャルパッチの最も大きなメリットの一つは、セキュリティチームや開発者が本物のパッチを作成するために必要な時間を確保できることだ。バーチャルパッチは脅威に関する情報を収集することで、テストと導入も加速する。ソフトウェアやアプリケーションの修正・コーディングには時間がかかるが、許可・ブロックのルールでトラフィックの流れを防ぐシールドの作成ははるかに容易で、迅速に実行できる。
一方、バーチャルパッチによって組織がサイバー攻撃のリスクを防ぐ時間を確保できるとしても、回避や欺瞞の技術によってだまされる可能性がある。より恒久的なセキュリティパッチやソリューションへの移行を遅らせたり、見送ったりすると、バーチャルパッチは組織に長期的なリスクももたらす。
プライバシーおよびデータコンプライアンス法については、バーチャルパッチによって、GDPRやPCI DSSなどの要件をより適切に満たせるようになる。
サポートやセキュリティアップデートの提供が終了した古いレガシーシステムも、バーチャルパッチの恩恵を受けられる。脆弱性対策のベストプラクティスと、そのメリットおよび限界を十分に理解することで、企業はデジタルトランスフォーメーション、アクセラレーション、モダナイゼーションの新時代において、セキュリティを最新の状態に保てる。
結論：バーチャルパッチ
ハッカーは新たな脆弱性を数日以内に悪用できる一方、ベンダーが正式なパッチを開発してリリースするまでには数週間から数カ月かかることがある。そこでバーチャルパッチは、正式な修正が利用可能になるまで、あるいはレガシーシステムで正式な修正が決して提供されない場合に、その空白を埋める創造的な方法となる。サイバー攻撃がますます危険になる時代に、これはあらゆるサイバーセキュリティチームに必要なスキルだ。
次に読む：パッチ管理のベストプラクティスと手順