パッチ管理フェーズ 3 - 評価と計画
公開日: 2004年6月2日
トピック
モジュールの内容
目的
適用対象
モジュールの使用方法
概要
適切な対応策を決定する
リリースを計画する
リリースを作成する
受け入れテスト
要約
展開段階に移行する
モジュールの内容
このモジュールでは、4 段階パッチ管理プロセスの第 3 段階 "評価と計画" について説明します。評価と計画の段階では、更新プログラムを展開するかどうかの決定、展開に必要な条件の判定、運用同様の環境でのソフトウェア更新プログラムのテストを行って、ビジネスに不可欠なシステムとアプリケーションが損なわれないことを確認します。
このモジュールの目的は、パッチ管理プロセスの評価および計画段階の原則を説明し、Microsoft® Software Update Services (SUS) や Microsoft Systems Management Server (SMS) を使用して評価と計画を実行できるようにするタスクの種類を紹介することです。
評価と計画のプロセスを完了しないと、更新プログラムを展開するかどうかを決定するときに役立つ明確な基準セットが得られません。また、更新プログラムの展開に必要な条件を把握することも、信頼できるテスト済みのリリース ソフトウェアを作成するための手順を確立することもできません。
目的
このモジュールの目的
更新プログラムの展開が実際に必要かどうかを判断する。
ソフトウェア更新プログラムのリリースを計画する。
リリースを作成する。
リリースの受け入れテストを実施する。
適用対象
このモジュールは、すべての Microsoft 製品およびテクノロジに適用されます。
モジュールの使用方法
このモジュールでは、SUS と SMS を使用して評価および計画を実行するのに必要な基本タスクについて説明します。詳細な手順については、方法が説明されている次の一連のモジュールを参照してください。
このモジュールから最大限の成果を得るには、以下を参照してください。
「パッチ管理のプロセス」を参照してください。このモジュールでは、4 段階パッチ管理プロセスの各段階の概要について説明しています。また、Microsoft Windows® オペレーティング システム環境のパッチ管理をサポートするために利用可能なツールの導入情報も提供しています。
次のモジュールを参照してください。
概要
評価と計画の段階は、図 1 で示されるパッチ管理プロセスの第 3 段階です。
.jpg)
図 1パッチ管理プロセス
この第 3 段階では、ソフトウェア更新プログラムを評価して (展開用に承認されることが前提)、運用環境に展開できるよう計画します。
評価と計画の最初の段階は、運用環境に関連があるものとして識別されている、ソフトウェア更新プログラムに応じた変更の要求 (RFC) になります。
評価と計画の段階の終了までに、変更の要求を緊急として分類するかどうかを決定する必要があります。また、要求の確認と承認を行って、承認された変更を運用環境に展開するのに必要なタスクを判断する必要があります。運用環境に類似した環境でソフトウェア更新プログラムをテストして、ビジネスに不可欠なシステムおよびアプリケーションが損なわれないことを確認する必要もあります。
このモジュールでは、評価と計画に関する次の主な要件に注目します。
適切な対応策を決定する。
ソフトウェア更新プログラムのリリースを計画する。
リリースを作成する。
リリースの受け入れテストを実施する。
適切な対応策を決定する
RFC では、ソフトウェア更新プログラムの展開や脆弱性を軽減する対策の適用 (またはその両方) など、運用環境に必要な変更の種類を決定して、他人も操作できるよう必要な変更点を記述します。
評価と計画の最初の手順では、RFC を確認して、ソフトウェアの脆弱性または脅威に最も適した対応策を決定します。次の決定を行います。
要求の優先順位付けと分類
ソフトウェア更新プログラムを展開するための承認の取得
ソフトウェア更新プログラムの要求の優先順位を付けて分類する
ソフトウェア更新プログラムの要求を承認する前に、その優先順位とカテゴリを決定する必要があります。優先順位とカテゴリは、変更開始者によって最初に割り当てられ RFC に含まれますが、これらの割り当ては変更要求の承認前に確認され、合意または変更される必要があります。
ソフトウェア更新プログラムの優先順位を付ける
優先度は、ソフトウェア更新プログラムを変更プロセスに適用する速さを決定するので、特に重要です。次の考慮事項は、ソフトウェア更新プログラムの優先度を判断するときに役立ちます。
重要なビジネス資産は何か。これらのビジネス資産は、ソフトウェア更新プログラムがインストールされるまで、セキュリティ違反やシステムの不安定性などのリスクにさらされる可能性があるか高価値資産に更新プログラムを適用する/しない場合の影響に基づいて、変更要求の優先順位を決定する必要があります。
ソフトウェア更新プログラムは、基幹業務アプリケーションなど、過去に攻撃者の対象となっておりビジネスに不可欠なサービスを実行するシステムに適用されるか。これは、変更要求の優先順位を上げる有効な理由になる場合があります。
特定のセキュリティ脆弱性の脅威を軽減する対応策は既に展開しているか。ここでは、変更要求の優先順位を下げられる可能性があります。ただし、それでも脆弱性をなくすソフトウェア更新プログラムを展開することをお勧めします。
運用環境にとって問題となっている脆弱性の脅威とはどのようなものか。セキュリティ情報と関連するソフトウェア更新プログラムは、その多くが環境内の数台のコンピュータにのみ適用されます。脆弱性の脅威のレベルが低い場合は、要求の優先順位を下げられる可能性があります。
次の表は、要求の優先順位を他の要求との関連で評価するときに役立ちます。表 1 では、優先度を、推奨期限と最低限の推奨期限に関連付けます。
表 1: 更新プログラムの優先順位と推奨展開期限
| 優先順位 | 推奨期限 | 最低限の推奨期限 |
|---|---|---|
| 緊急 | 24 時間以内 | 2 週間以内 |
| 高 (High) | 1 か月以内 | 2 か月以内 |
| 中 (Medium) | 可用性によって、この脆弱性の解決を含む、新しい Service Pack または更新プログラムのロールアップを、4 か月以内に展開。 | 6 か月以内に、ソフトウェア更新プログラムを展開。 |
| 注意 (Low) | 可用性によって、この脆弱性の解決を含む、新しい Service Pack または更新プログラムのロールアップを、1 年以内に展開。 | 1 年以内に、ソフトウェア更新プログラムを展開するか、まったく展開しないことも選択可能。 |
| 環境/組織の要因 | 優先順位の調整 |
|---|---|
| 高い価値または高い公開資産が影響を受ける。 | 上げる |
| 過去に攻撃者の対象となった資産。 | 上げる |
| 脅威を最小限にする対応策などの、軽減要因が適所にある。 | 下げる |
| 低い価値または低い公開資産が影響を受ける。 | 下げる |