デバイスへのパッチ適用やアップデートは煩雑で、業務の中断を招くこともあります。しかし、パッチが適用されていない脆弱性は、攻撃者に大きな被害をもたらす格好の機会を与えます。調査によると、未対処の脆弱性はすべての侵害の30～60％に関与していると推定されています。
パッチ管理ポリシーは、すべてのシステムとソフトウェアに適時パッチを適用し、アップデートすべきという基本的なIT要件を正式なものにします。パッチ適用とアップデートの要件を説明するルール、実行・報告・確認が可能な明確なプロセス、テストと検証が可能な基準を定めるものです。
この記事では、基本的な概要とテンプレートを通じて、規模を問わずあらゆる組織がそのプロセスを始められるよう支援します。
- 無料のパッチ管理ポリシーテンプレート
- パッチ管理ポリシーを4つの手順で作成する方法
- パッチ管理ポリシーの一般的なセクション
- パッチ管理ポリシーのベストプラクティス5選
- 効果的なパッチ管理ポリシーの主なメリット6つ
- 結論：パッチ適用ポリシーが優れたプロセスを促進する
関連記事：パッチ管理プロセスの11の重要な手順
無料のパッチ管理ポリシーテンプレート
パッチ管理ポリシーの策定を始めるにあたり、eSecurity Planetは、ダウンロードして編集できるテンプレートを作成しました。テンプレートの使用方法などを説明する注記は[角括弧内]に記載されており、最終原稿からは削除してください。
「パッチ管理ポリシーのサンプルテンプレート」にアクセスしてください。
サンプルのパッチ適用ポリシーには多くのセクションがありますが、すべての組織にすべてのセクションが必要とは限らず、より詳しい内容が必要になる場合もあります。詳しくは、以下の「パッチ管理ポリシーの一般的なセクション」を参照してください。
パッチ管理ポリシーを4つの手順で作成する方法
すべてのセキュリティポリシーの策定には、共通する4つの重要な手順があります。詳しくはITセキュリティポリシー：重要性、ベストプラクティス、主なメリットで解説しています。機能するパッチ管理ポリシーについて、これらの手順を次のようにまとめます。
- パッチ管理ポリシーを決定する：責任者、対象となる人や物、基本的なプロセス、検証方法、報告内容を特定します。これらは、多くの場合、現在の運用を基に決めます。
- パッチ管理ポリシーを検証する：手順1で作成した基本ポリシーが、組織のあらゆるニーズとコンプライアンス要件を満たしていることを正式に確認します。
- パッチ管理ポリシーを承認する：正式な文言を起草し、影響を受ける関係者や役員に回覧して承認を得ます。
- パッチ管理ポリシーを見直し、変更する：ポリシーが最新の状態を保ち、組織の変化するニーズを満たし続けていることを定期的に確認します。
基本は変わりませんが、パッチ管理は規制の対象となることが多い要件です。そのため、組織はコンプライアンス要件の検証に際して特に注意する必要があります。コンプライアンス要件を満たさないルールは調整しなければなりません。
例えば、消防署では実務上、四半期ごとにパッチを適用しているかもしれません。しかし、州のサイバーセキュリティ要件によって毎月のパッチ適用が求められていることが判明した場合、準拠するために適用頻度を毎月に変更する必要があります。
実務上の制約も非常に重要です。ポリシーチームはパッチ適用チームと連携してルールをテストすべきです。ITチームが現在のリソースでは基準や要件に対応できない場合、組織はルールとリソースのどちらを調整すべきでしょうか。
先ほどの消防署の例では、空き時間にパッチを適用していたボランティアの消防士を、パッチ管理ツールまたはサービスで置き換えるか、支援する必要があるかもしれません。そうしたツールやサービスなら、毎月の規制要件を満たせます。
パッチ管理ポリシーの一般的なセクション
パッチ管理ポリシーを作成する際は、必須、推奨、追加（あると望ましい）セクションを検討してください。
必須ポリシーセクション
次の基本セクションは、パッチ管理に関するすべてのポリシーに含めるべきものです。
- 適用範囲：ポリシーの対象となる資産と、対象に含めるソフトウェアやデバイスの特定方法。
- パッチ管理の権限：パッチ管理ポリシーとその実行の責任者。
- パッチ適用の優先順位：深刻度、リスク、その他の要因に基づき、パッチの優先順位とその判断基準を決める方法。
- パッチ適用のスケジュール：優先順位に基づき、パッチのリリースから組織がインストールするまでの期間。
- パッチ管理の準備：パッチが失敗してシステムを復元する必要が生じた場合に備えて、バックアップなど、あらかじめ実施しておくべきシステムの準備。
- 手動でのパッチ管理：特にメンテナンスのためのダウンタイムが必要なシステムに、手動でパッチを適用する方法。業務システムのダウンタイムをスケジュールし、承認を得るプロセスを説明します。
- 例外への対処方法：失敗するパッチ、業務を中断させるパッチ、単に不要なパッチもあります。システムの復旧方法、例外の追跡方法、未解消の脆弱性を保護するための緩和策のプロセスを説明します。
- パッチとアップデートの報告：報告内容や報告方法を含め、レポートによってパッチ管理の成功とコンプライアンスを測定する方法。
推奨ポリシーセクション
これらのセクションは、組織を保護する追加ルールを設け、IT部門の準備に役立てることで、パッチ管理ポリシーをより充実させます。
- 資産リスト：パッチ適用やアップデートの対象として追跡するシステムとソフトウェアの範囲を定義するための、リソースまたは資産リストへのリンク。
- パッチとアップデートの入手：有効なパッチやアップデートの入手先を定めます。
- パッチのテスト：パッチが正常に機能し、他の業務システムに影響を与えないことを確認するためのテスト環境またはパッチのテスト。
- 自動パッチ適用：組織は、パッチ適用の遅延を減らし、ITチームの負担を軽減するため、自動化されたパッチ適用プロセスを好むことがよくあります。
- 監査管理と統制：パッチ管理の成功を追跡し、パッチが正常に適用されたことを検証するために、内部・外部監査人が求めるレポート、ログ、情報を定めます。
- 強制措置：パッチ管理プロセスを実行しなかった場合のIT部門への罰則、パッチ管理プロセスを妨げた従業員への罰則、パッチ管理ポリシーに準拠しない資産への対処方法。
- 配布：パッチ管理ポリシーを受け取らなければならない、または受け取るべき人。
- ポリシーのバージョン：パッチ管理ポリシーのバージョンと承認の追跡。
追加／あると望ましいポリシーセクション
これらのセクションはパッチ管理ポリシーの中核要素を変えるものではありませんが、ポリシーをより使いやすく、包括的にできます。
- 概要：ポリシーへの期待と目標を設定します。
- コンプライアンス付録：組織が準拠しなければならない関連コンプライアンスフレームワークのコピーまたはリンク。
- BYODへの対処方法と個人所有の機器。
パッチ管理ポリシーのベストプラクティス5選
すべてのセキュリティポリシーの策定には、共通する5つのベストプラクティスがあります。詳しくはITセキュリティポリシー：重要性、ベストプラクティス、主なメリットで解説しています。機能するパッチ管理ポリシーについて、これらを次のようにまとめます。
- 方法ではなく、すべきことに焦点を当てる：目標や目的に焦点を当てることで、ポリシーは基準を設定しながら、パッチ管理チームが目標や目的を達成する最善の方法を柔軟に決められるようにします。
- 実用的なポリシーにする：パッチ管理チームがポリシーを理解し、実行できるようにする必要があります。
- 適切な長さにする：短すぎると検証に十分な要件を盛り込めず、長すぎると規定が過剰になったり、理解しにくくなったりします。
- ポリシーを明確に分ける：重複するポリシーは、矛盾を生じさせたり、最新の状態を保つことを難しくしたりします。
- 検証可能なポリシーにする：効果的なポリシーには、ポリシーが導入され、実際に機能していることを証明するレポートが必要です。
「eSecurity Planetのテンプレートは、組織によっては必要以上に包括的な内容を目指しています。そのため、すべての組織がテンプレートを確認し、自社のニーズに合わせて内容を追加・削除すべきです。
標準的なベストプラクティスに加えて、パッチ管理にはさらなる考慮事項があります。例えば、パッチ管理ポリシーを実用的なものにする際は、共通脆弱性評価システム（CVSS）などの既存のリソースを使ってリスクを判断し、パッチの優先順位を付けます。ただし、組織固有の状況も考慮し、これらのリソースとのバランスを取る必要があります。
例えば、一部の組織では、脆弱性へのパッチ適用をスコアが7以上のものに限っています。ただし、これらの評価は脆弱性のリスクを示すだけであり、悪用される可能性や、組織にとっての資産価値も合わせて考慮する必要があります。
公開済みの文書しか含まないマーケティング用Webサーバー上のデータ窃取バグのスコアが8.0であっても、会社のActive Directory（AD）サービスにある、スコア6.5のリモートコード実行の脆弱性より優先度を高くすべきではありません。ADが完全に侵害された場合の組織への影響はあまりにも大きく、悪用される可能性がわずかであっても、リスクを冒すことはできないからです。
パッチ管理における特別な考慮事項として、多くの組織が自動化ツールを導入しています。こうしたソリューションは有効であり、使用すべきです。ただし、オペレーティングシステムやMicrosoft Office、Adobe Acrobatなどの一般的なソフトウェアといった、ITエコシステムの特定の部分に焦点を当てる傾向があります。
ツールでは、サードパーティー製アプリケーション、ファームウェア、モノのインターネット（IoT）デバイス、ネットワーク機器、バックアップアプリケーションなどを包括的にカバーできないことがよくあります。ポリシーでは、パッチ適用の対象となる資産リストの判断を、ツールやパッチ管理サービスに依存すべきではありません。IT部門は、パッチが必要なすべてのリソースを追跡し、パッチを適用できるようにする必要があります。パッチの適用が困難であったり、手動での適用が必要になったりする場合も同様です。
効果的なパッチ管理ポリシーの主なメリット6つ
多くの組織は、文書化されていないパッチ管理プロセスを書面にまとめる時間を取っても、改善にはつながらないと考えています。しかし、この考え方は、あらゆるセキュリティポリシーに共通する6つの重要なメリットを見落としています。
- ITのセキュリティ強化：セキュリティポリシーを作成または見直すプロセスによって、セキュリティ対策の評価と改善の可能性が促されます。
- 雇用上の防御：経営幹部が承認した書面のポリシーに準拠することで、侵害が発生した場合にITチームとセキュリティチームを守る根拠になります。
- 経営幹部や取締役の安心：経営層の関係者は、効果的なポリシーで作成が義務付けられた平易な言葉によるレポートから、組織のセキュリティ態勢を容易に理解できます。
- 訴訟からの保護：合理的なセキュリティ対策を含むポリシーへの準拠を示すレポートやその他の証拠は、侵害が発生した場合に、訴訟や規制当局への対応における保護となります。
- コンプライアンス対応の簡素化：ポリシーにコンプライアンス要件がすでに含まれていれば、ポリシーで作成が義務付けられたレポートを監査人が自動的に利用できるようになります。
- 業務効率とレジリエンスの向上：効果的なポリシー、特にパッチ管理ポリシーは、サポート終了となった資産を検出し、使いやすさや機能性を高める最新機能が確実に導入されるようにします。
結論：パッチ適用ポリシーが優れたプロセスを促進する
優れたパッチ管理ポリシーは、効率的で信頼性の高いパッチ管理プロセスを構築するための有用なチェックリストになります。パッチ適用によるサイバーセキュリティリスクの低減と、レポートによるコミュニケーションの改善が、全体的な業務プロセスと経営層の信頼を向上させます。
ただし、パッチ適用ですべての問題を解決できるわけではありません。パッチ管理では、組織のニーズに合った適切なソフトウェアが導入されているかどうかや、ソフトウェアの設定が適切かどうかまではカバーできません。
パッチ管理ポリシーは、サイバーセキュリティプログラム全体における有用な要素ですが、レジリエンスの高い組織を実現するには、他の重要なポリシーや戦略と組み合わせる必要があります。
パッチ管理と関連トピックの詳細：