リスクベースの脆弱性管理プログラムを運用することは、安全なビジネスコンピューティング環境を維持するうえで不可欠です。以前のブログ「リスクベースのパッチ管理の実装が、悪用が確認されている脆弱性への対応を優先させる仕組み」では、脆弱性の優先順位付けについて考察しました。そのプロセスでは、システムを保護するための運用面を磨き上げることが不可欠です。

組織でパッチ運用を実施することは、複雑なプロセスになり得ます。脆弱性の優先順位について一定の見通しがあったとしても、次の点を考慮する必要があります。

  • パッチのリリース頻度。
  • このプロセスを効果的にするための支援ポリシー。
  • 更新プログラムを展開するためのキャンペーン。
  • サービスレベル契約（SLA）とコンプライアンス測定。

調整すべきことが多いように感じられるかもしれませんが、計画済みのイベントを管理し、予期しない事態にも対応できる柔軟なシステムがあれば、完全にコントロールできます。

貴社はコントロールできていますか。

パッチリリースには、計画できる側面と計画できない側面があります。

たとえば、セキュリティパッチのリリース頻度を考えてみましょう。毎月第2火曜日のPatch Tuesdayに、Microsoftは最新の更新プログラムをまとめてリリースしようとします。これには、オペレーティングシステム、Officeやその他のユーザーアプリケーション、Visual Studioなどの開発ツール、Azureのクラウドコンポーネントなどの更新プログラムが含まれます。

2023年10月に20周年を迎えたPatch Tuesdayは、多くのパッチプログラムの基盤であり、最新のMicrosoft更新プログラムと利用可能なサードパーティ更新プログラムを一括配布するためのタイミングを提供しています。組織のパッチプログラムを推進するうえで、これほど大きな影響を与えたベンダーは他にありません。そして現在でも、Patch Tuesdayを基準とする月次パッチサイクルは業界標準であり続けています。

他のベンダーもこれに倣い、スケジュールに沿って更新プログラムをリリースしようとしてきました。

  • OracleはCritical Patch Updateを四半期に1回リリースしています。
  • Adobeは通常、月に1回、Patch Tuesdayと同期する形で更新プログラムをリリースしています。
  • Googleは最近、週に1回の単一更新プログラムのリリースを開始しました。

しかし、ほとんどのベンダーは脆弱性にできるだけ迅速に対応するため、可能な限り早く、また頻繁にセキュリティ更新プログラムをリリースします。その結果、組織全体で継続的に優先順位を付け、配布しなければならない更新プログラムが、予測しにくく終わりなく発生し続けます。

ポリシーとキャンペーンのためのパッチ管理プロセス

パッチリリースの混沌を制御するには、明確に定義された一連のルールと、それを適用するためのインフラストラクチャが必要です。パッチの領域では、これはポリシーとキャンペーンに相当します。

パッチポリシーでは、脆弱性の優先順位付けだけでなく、更新プログラムが業務運用に与える影響、異なる種類のシステムへの適用性、更新プログラムに対する制御の度合い、その他の要因など、幅広い事項を考慮する必要があります。

パッチポリシーは、ビジネスによって大きく対照的な内容になります。重要なビジネスアプリケーションをホストするサーバーの場合、そのポリシーには、厳格な構成管理の下で明確に定義された一連の更新プログラムが含まれ、定義済みのメンテナンスウィンドウ内でのみ実施され、完了時にはシステムが完全に更新されるよう必ず再起動が強制されます。一方、マーケティング担当ユーザーのノートPC向けのパッチポリシーでは、存在する場合としない場合がある承認済み更新プログラムを含む一連のアプリケーションを特定し、ユーザーが都合のよいタイミングまで更新と再起動を延期できるようにします。

キャンペーンはこれらのポリシーを考慮に入れながら、絶えずリリースされる多数のパッチを制御します。

最新のパッチ管理のベストプラクティスでは、月1回にとどまらない、より頻繁なパッチ適用が求められます。Google Chromeのパッチは毎週リリースされており、ゼロデイパッチはいつでもリリースされる可能性があります。月次キャンペーンだけでは、多くのシステムが長期間にわたり脆弱な状態に置かれます。

3種類のキャンペーンを確立する

ベストプラクティスは、定期メンテナンス、優先更新、緊急展開という3種類のキャンペーンを確立することです。

定期メンテナンスキャンペーン

定期メンテナンスキャンペーンでは、現在ほとんどの組織が使用している標準的な月次の段階的パッチ展開を実施します。このキャンペーンには次が含まれます。

  • パッチが計画どおりにインストールされることを確認するため、管理された環境で初期テストを実施する。
  • 問題を報告できるよう注視している早期導入者からなる、より大きなパイロットグループへ展開する。
  • 全体的な配布を完了するため、事前に定義された本番システムのグループへ展開する。

メンテナンスキャンペーンに含まれるパッチには、Microsoft Patch Tuesdayのリリースのように比較的頻度の低いセキュリティ更新プログラムに加え、パフォーマンス改善やアプリケーションのアップグレードが含まれます。このキャンペーンの対象システムには、メンテナンスウィンドウが限られており、業務への大きな影響なしには中断できないシステムも含まれる場合があります。ほとんどのパッチは、優先更新キャンペーンに分類される可能性が高いでしょう。

優先更新キャンペーン

優先更新キャンペーンは、新たな脆弱性に継続的にさらされているものの、より頻繁に更新できるシステムに迅速に対応するために設計されています。生産性アプリケーションやブラウザを実行しているユーザーシステムはこのキャンペーンの対象となり、フィッシング、マルウェア、ランサムウェアにさらされるため、多くの場合、最も高いリスクに置かれます。

このキャンペーンに関連するパッチは、悪用が確認されている脆弱性に対応するため優先度が最も高いことが多い一方で、ブラウザやアプリケーションの再起動を必要とする程度で、業務への影響が比較的低い場合もあります。そのため、ポリシーではリリース前のテストサイクルを短縮し、ビジネスクリティカルではない大規模なシステム群へより迅速に配布することがあります。たとえば、サーバーにはブラウザがインストールされていない場合がありますが、営業担当者のノートPCにはインストールされています。

ゼロデイ対応キャンペーン

ゼロデイ対応キャンペーンは、短期間で適用しなければならない、企業または業界の要請による緊急パッチ展開のために用意されます。このキャンペーンは他のすべてに優先します。

このキャンペーンのポリシーでは、満たすべきSLAに応じて、段階的展開の各ゲート間の期間を短縮したり基準を緩和したりすることも、場合によってはそれらを完全に省略することもできます。ゼロデイ対応キャンペーンで最も重要なのは、これが依然として管理されたパッチ配布であり、キャンペーンイベントの完了までを正確に追跡するため、すべてのアクティビティが引き続き報告されるという点です。

曝露時間がコンプライアンスを左右する

コンプライアンスを完全にパッチ適用済みのマシン数で測定する場合、この指標では、ほとんどのシステムが毎月限られた時間しか準拠状態にないことになります。技術的には正確ですが、リスクベースのプログラムにおいて、時間の経過に伴うシステムのセキュリティを示す指標としては不十分です。特定の脆弱性または脆弱性群に対する「曝露時間」を示すことで、リスクをより適切に把握できます。

例を挙げます。CVE-2024-4761は、5月14日にリリースされたGoogle Chromeの更新プログラムで修正されたと報告されました。この日は偶然にも5月のPatch Tuesdayでした。翌日、このChromeパッチは優先更新キャンペーンに追加され、グループ1の500台のシステムとグループ2の1,000台のシステムに対して、2週間の配布期間が設定されました。ほとんどのシステムがその2週間の期間内に正常に更新されたと仮定すると、レポートには各システムがいつ更新されたかが示されます。しかし、さらに重要なのは、これら1,500台の各システムがどれだけの期間パッチ未適用のまま、つまりその脆弱性にさらされリスクを抱えた状態にあったかが示されることです。

これは、1つの脆弱性と1つのパッチによるシンプルな例です。しかし、キャンペーンに複数のパッチが含まれ、それぞれに複数の脆弱性がある場合、その情報を集約して、より包括的なキャンペーンビューを提供できます。同じ期間に複数のキャンペーンが実行された場合は、結果を重ね合わせたり統合したりすることで、さらに正確なリスク評価を提供できます。

このデータがあれば、監査担当者にシステムの真のセキュリティ状態を示すことができます。さらに重要なのは、結果の評価を始め、最新のパッチ管理運用の有効性を向上できることです。その時点で、運用に振り回されるのではなく、貴社が運用を主導している状態になります。