セキュリティ ウォッチセキュリティ情報入手後の操作
Christopher Budd
マイクロソフトの毎月のセキュリティ情報リリース プロセスは、お客様からの要望に応えて、2003 年 10 月に確立されました。こうしたお客様からの大きな要望の 1 つが、セキュリティ情報のリリース スケジュールを予測可能にすることでした。そこで、プロセスに磨きをかけ改善できるように、規則性と予測可能性を使用できるようにしました。
Microsoft セキュリティ情報検索サイトでは、図 1 に示すように、最新のセキュリティ情報や過去の情報を検索できます。図 2 は、2006 年 8 月のセキュリティ情報の例を示しています。
図 1** Microsoft セキュリティ情報のサイト **(画像を拡大するには、ここをクリックします)
マイクロソフトから毎月リリースされるセキュリティ情報は、多くのユーザーにとって、マイクロソフト セキュリティ更新プログラムを展開するプロセスを成熟させていくのに役立ってきました。ユーザーはセキュリティ情報がリリースされる日を予測できるので、そのタイミングに合わせてセキュリティ情報を処理する、独自の定期プロセスを構築しています。こうしたユーザーは、セキュリティ更新プログラムの評価プロセスと展開プロセスのタイムラインと手順を独自に作成しています。このようなプロセスでは、マイクロソフトの毎月のセキュリティ情報のリリース日を予測できるので、タイムラインをそのタイミングに合わせて統合します。ユーザーは、このようなプロセスを使用して、更新プログラムを体系的に分析、テスト、および展開します。その結果、セキュリティの全体的な状態が向上し、ダウンタイムや中断を軽減できます。
図 2** 2006 年 8 月のセキュリティ情報 **(画像を拡大するには、ここをクリックします)
しかし、決められた手順を用意しないで、セキュリティ更新プログラムの評価と展開を処理するユーザーもいます。更新プログラムの展開を非体系的に行うことは可能で、それにより問題が発生しないとしても、我々が考えるセキュリティ更新プログラムを管理するためのベスト プラクティスとは根本的に逆行します。
これまでセキュリティ情報のリリースの方法とタイミングに関して役立つ情報を提供してきましたが、セキュリティ情報を扱う処理とその情報を独自のプロセスに統合する方法に関するガイダンスについてはあまり提供してきませんでした。そのため、ユーザー自身にとってメリットのあるプロセス、またはそうしたプロセスを構築する最善の方法に気付いていないユーザーもいるかもしれません。
そこで、このコラムでは、セキュリティ更新プログラムの評価と展開に関して推奨する手順とプロセスの概要について説明します。規模の大小を問わず、どのような組織でもこうした手順に従うことができます。大きな組織では、その内部構造に基づいて、さまざまなグループ間で手順を分担する方が適切な場合もあります。小さな組織では、これらすべての手順を 1 つのグループまたは個人が担当できます。役割の割り振りに関係なく、評価プロセスと展開プロセスでこれらの手順をすべて明確に考慮する必要があります。図 3 は、このプロセスの概要を示しています。
図 3** セキュリティ情報の評価と展開のプロセス **
1. 事前通知の受信
毎月のセキュリティ情報のプロセスでは、まず、次回のセキュリティ更新プログラムの事前通知を受信することを確認します。マイクロソフトは、標準の月次リリース日 (毎月第 2 火曜日) の 3 営業日前 (前週の木曜日) のほぼ午前 10 時 (太平洋標準時) に Web サイトに情報を掲載します。
事前通知の目的は、実際のリリースに先駆けて展開を計画する際に役立つ情報を提供することです。掲載する情報の詳細度のレベルと、セキュリティ更新プログラムのリリースまでユーザーを保護する必要性とのバランスを保ち、攻撃を助長する可能性のある情報を公開しないようにしています。事前通知では、今後予定されている更新プログラムに関する情報を製品名別 (Microsoft® Windows® や Microsoft Office など) に収集します。この場合、特定のバージョンに関する情報は収集しません。このような各エントリでは、その製品に関してリリースされるセキュリティ情報の数、セキュリティ情報の最も高い深刻度、更新プログラム適用時に再起動が必要かどうか、およびセキュリティ情報に適用される検出ツールが明示されます。
事前通知では、見落としがなく、できるだけ混乱を最小限に抑えるために、同じ日にリリース予定のセキュリティ情報以外の更新プログラムに関する情報も提供します。具体的には、Microsoft Update (MU) や Windows Update (WU) でリリースされる優先度の高いセキュリティ以外の更新プログラムの数や、Microsoft Windows 悪意のあるソフトウェアの削除ツールに対する更新プログラムも明示します。
最後に、MS06-019 の "代理送信" アクセス許可の変更で行ったように、展開時に遅延の原因になる可能性のある問題に関する情報も提供します。
毎月、Security Notification Service Comprehensive Edition (SNSCE) から通知が送信されるタイミングで、新しい事前通知が掲載されます。SNSCE に登録することができます。
2. 考えられる影響の評価
事前通知を受け取ったら、次に、使用している環境における次回リリースの妥当性を評価します。影響を受ける製品に関して限られた情報しか事前通知に含まれていないとしても、次回のセキュリティ情報が現在使用している環境に妥当かどうかを判断できるだけの情報は示されます。
たとえば、最大深刻度が "緊急" に格付けされ、再起動を必要とする、Microsoft Exchange に関するセキュリティ情報が事前通知に 2 件記載されているとします。Microsoft Exchange を実行していなければ、使用している環境にはこれらのセキュリティ情報が妥当ではないことがすぐにわかります。逆に、Exchange Server 2003 を実行している場合は、再起動を要する、"緊急" に格付けされるセキュリティ情報が最大 2 つ火曜日にリリースされることがわかります。
計画を策定するという目的からは、セキュリティ情報の数、深刻度、および再起動に関する展開への影響という観点で、組織に対して考えられる最大の影響を判断する際に、こうした事前通知が役立つツールであると考えています。更新プログラムの妥当性と考えられる最大の影響を評価したら、次のアクション アイテムを含むスケジュールを作成できます。
- リスクの評価、テスト、および展開のための要員
- テスト計画とテスト ラボの時間
- 展開計画と (必要に応じて) 再起動のスケジュール設定
事前通知の情報は変更される可能性があるため、この時点でのスケジュールはすべて一時的なものです。また、事前通知の情報の種類には制限があるので、完全な詳細を確認してから、変更を加えることができます。
最後に、機能変更などの追加情報がある場合は、事前通知から実際のセキュリティ情報のリリースまでの時間を利用して、問題を調査し、その問題の環境への考えられる影響を評価します。調査に基づいて一時的なスケジュールの改訂が必要になることもあります。
3. 新しいマイクロソフト セキュリティ情報の受信
マイクロソフトは、毎月第 2 火曜日に、セキュリティ情報をリリースします。リリース目標時刻は午前 10 時 (太平洋標準時) ですが、リリースは大規模で複雑な相互に関連するプロセスの一部なので、さまざまな理由から遅れる可能性があります。リリースでは、セキュリティ情報、セキュリティ更新プログラム、Microsoft Baseline Security Analyzer (MBSA) や Windows Server® Update Services (WSUS) などの検出ツールや展開ツールの更新、Enterprise Scan Tool (EST) の新しいバージョンなどの新しい検出ツールがすべてマイクロソフト Web サイト上に掲載されます。
マイクロソフト セキュリティ情報ページでは、RSS フィードのサポートが有効になっています。セキュリティ情報に更新プログラムが含まれていると、RSS フィードも更新され、その結果、RSS アグリゲータと RSS ビューアも更新されます。また、通知は Security Notification Service (SNS) と SNSCE の両方を使用して送信されます。通知は、電子メールと MSN® アラートの両方で送信されます。
新しいセキュリティ情報を利用できるかどうかを知るには、提供されるすべての通知メカニズムに登録します。RSS フィード (英語) や、SNS と SNSCE の両方を購読できます。
4. セキュリティ情報の妥当性の評価
新しいセキュリティ情報を確認し、使用している環境への妥当性を評価する役割を明確に割り当てることが重要です。この評価の一環として、セキュリティ情報から特定の情報を取得し、必要に応じて、一時的なスケジュールを改訂および調整できます。例に話を戻しましょう。緊急のセキュリティ更新プログラムがリリースされる可能性を Exchange 管理チームに通知した場合でも、その後 Exchange Server に影響しないことがわかったら、そのリソースのスケジュールを調整できます。
組織に対するセキュリティ情報の妥当性を評価したら、プロセス内で関連するセキュリティ情報の処理を先に進めます。
5. リスク評価の実行とセキュリティ情報の格付け
この時点で、関連するセキュリティ情報のリスク評価を行う必要があります。役割を分担している組織では、多くの場合、この手順はセキュリティ グループが実行します。各マイクロソフト セキュリティ情報には最大深刻度の格付けが含まれていますが、その格付けは、影響を受けるすべての製品のすべての脆弱性のうち最も高い深刻度を表しています。マイクロソフトによる深刻度の格付けは、適用される組織によっては記載されている格付けとは異なる場合があり、使用している環境のバージョンでの問題の深刻度に依存します。重要なのは、セキュリティ情報の「要点」にある「深刻度および脆弱性識別番号」の表を参照し、特定のバージョンに関する特定の脆弱性の情報を入手することです。
その後、「問題を緩和する要素」などの補足技術情報や各脆弱性に関する FAQ によって技術的な詳細を確認し、使用している環境やポリシーに基づいてリスク評価を調整します。また、組織のポリシーにより、脅威が生じる環境や組織に対する特定のアプリケーションの致命度など、技術面以外の環境要素を考慮する評価が指定されている場合もあります。
このプロセスの最後に、セキュリティ情報とそれに関連付けられた更新プログラムごとにリスクの評価を行います。先ほどの例に戻り、Exchange 管理グループが、セキュリティ情報に詳しく記載された変更に基づいて、セキュリティ更新プログラムを "警告" に格付けしたとします。ここで組織のポリシーに基づき、必要に応じて、スケジュールを更新および変更します。たとえば、ポリシーでは、"警告" に格付けされた更新プログラムのテストは "注意" に格付けされた更新プログラムよりも 1 ～ 2 日多くの期間が必要であることが指定されているかもしれません。
特定の深刻度に格付けされたセキュリティ情報には回避策の実装の検討も必要であることが、ポリシーで指定されている場合もあります。たとえば、"緊急" に格付けされたすべてのセキュリティ更新プログラムについては、できるだけ早く回避策を調査して展開する必要があると組織のポリシーで示されているとします。その場合は、回避策について追加でリスク評価を実行し、実装内容とタイミングを判断します。
このプロセスの最後には、使用している環境に展開する更新プログラムの一覧が、それぞれに関連付けられたリスクの格付けと共にできあがります。さらに、テストと展開のスケジュールの更新に使用する、実装する回避策の一覧もできあがります。スケジュールの変更では、ポリシーで指定されているタイムラインを反映します。たとえば、緊急のセキュリティ更新プログラムに関しては、すべて回避策は 24 時間以内に展開し、更新プログラムは 7 日以内に展開しなければならないことがポリシーで指定されていることもあります。
6. セキュリティ更新プログラムや回避策による、考えられる組織への影響の特定
セキュリティ更新プログラムや回避策の環境への影響を把握することは、評価プロセスの重要な手順です。役割を分担している組織では、多くの場合、この手順はセキュリティ更新プログラムや回避策の影響を直接受けるシステムを管理するグループが実行します。
考えられる影響を把握すれば、セキュリティ更新プログラムや回避策自体がもたらすリスクを認識および特定できます。これについては、セキュリティ情報の「このセキュリティ更新プログラムに関するよく寄せられる質問」を参照してください。セキュリティ更新プログラムで脆弱性を解決する方法については、「脆弱性の詳細」の脆弱性に関するよく寄せられる質問を参照してください。
この手順の目的は、更新プログラムや回避策のリスクの程度を判断することです。先ほどの例に戻り、Exchange 管理グループが、セキュリティ情報に詳しく記載された変更に基づいて、セキュリティ更新プログラムを "警告" に格付けしたとします。ここで組織のポリシーに基づき、必要に応じて、スケジュールを改訂します。たとえば、ポリシーでは、"警告" に格付けされた更新プログラムのテストは "注意" に格付けされた更新プログラムよりも 1 日多くの追加テストが必要であることが指定されているかもしれません。
また、リスクの格付けがどの程度スケジュールに影響するかによって、回避策の展開に関する決定の再検討が必要になる場合もあります。たとえば、テストを 2 日間延長する必要があり、システムがポリシーで許容されるよりも長時間無防備な状態のままになることがわかる場合があります。このような場合は、ポリシーに準拠するように回避策の展開を再検討することになります。
最後に、この手順で得た情報を使用して、更新プログラムのテスト計画の作成に進みます。
7. テスト計画の定義
テストの効果を得られるように、テストを体系的に行う必要があります。また、有意義な計画を策定する必要があります。テストは、使用している環境で最も問題が表面化する可能性が高い領域を対象にします。環境はそれぞれ異なるので、効果的なテスト計画用の標準テンプレートを提供することはできません。
役割を分担している組織では、多くの場合、テスト計画は複数のグループがデザインします。セキュリティ更新プログラムや回避策の影響を直接受けるテクノロジやシステムを管理するグループが、担当する特定の専門知識を提供できます。テスト グループは、テスト ケースの作成に関する専門知識、テスト ツールのオプション、および実用的なタイムラインに関する知識を提供できます。
この段階では、セキュリティ更新プログラムや回避策のリスクの格付けに対するテスト計画の影響に注意し、それに応じてテストおよび展開のスケジュールを変更します。たとえば、満足のいくまで更新プログラムをテストするようなテスト計画を作成できないと判断したら、そのリスクの格付けを引き上げ、展開を遅らせることを選択し、その間に回避策を実装することもあります。
8. 展開計画の作成
展開とは、セキュリティ更新プログラムや回避策が提供する保護を、実際に実装するプロセスです。実際には、展開がこのプロセスの最終目的なので、使用可能な展開方法を理解し、その方法を評価に織り込むことは、セキュリティ リスク評価と同じく重要です。役割を分担している組織では、多くの場合、セキュリティ更新プログラムに考えられる展開方法の決定は、ソフトウェア更新インフラストラクチャを管理するグループ (Systems Management Server (SMS) を管理するグループなど) が実行します。Active Directory などの構成管理テクノロジを管理するグループが、回避策に考えられる展開方法の決定に関与できます。
この手順の目的は、考えられる展開方法を把握し、それに基づいて、セキュリティ更新プログラムや回避策の展開に使用する計画を作成することです。この手順で理解すべき重要な点は、考えられる展開方法がどのようにスケジュールに影響し、どのように必要な変更を行うかということです。たとえば、組織の主要な展開手法が WSUS なのに、セキュリティ更新プログラムが WSUS でサポートされていなければ、更新プログラムの展開には本来の計画よりも 2 日長くかかると判断されるかもしれません。その場合は、この展開に許される時間枠内に、必要な保護を提供する回避策を実装することを決断することもあります。
展開方法に関する情報は、セキュリティ情報の「このセキュリティ更新プログラムに関するよく寄せられる質問」に記載されています。回避策の実装方法に関する情報は、各回避策と共に記載されています。各回避策は、各脆弱性に関連付けられています。
これで、計画段階は終了です。この時点で、評価のすべての要素を反映したスケジュールと、セキュリティ リスク、セキュリティ更新プログラムや回避策のリスク格付け、テスト、および展開に関する計画ができあがります。こうした段階からわかるように、各段階には複雑な相互関係があり、必ずしも直線的な関係ではありません。これらの各段階を同時に行う組織もあれば、順番に行う組織もあります。組織のポリシー、ニーズ、およびリソースに基づいて、これらの手順の実装を決定します。こうした手順にとって最も重要なのは特定の構造や順序ではなく、このようなさまざまな各段階で相互に情報の提供や応答を可能にすることです。すべての実装の鍵は、柔軟性と順応性を維持することです。
9. 更新プログラムと回避策のテスト
テスト段階では、上記で定義したテスト計画をテスト環境で使用して、セキュリティ更新プログラムと回避策をテストします。テスト環境の目的は、運用環境の重要な要素を再現することです。セキュリティ更新プログラムや回避策のテストでは、運用環境に展開する前に、発生する可能性のある問題を検出することに取り組みます。
テスト中に問題が明確になった場合は、その問題の深刻度と問題の解決に必要な手順を判断します。検出される問題には、影響が許容レベルに収まるそれほど重要ではないものもあれば、更新プログラムを展開する前に解決しなければならないものもあります。許容できる問題であれば、サポート スタッフ向けにその問題を記録しておきます。
問題を解決するために、マイクロソフト製品サポート サービス (PSS) に事例を公開できます。これにより、セキュリティ更新プログラムに関連する問題に対して無償サポートが提供されます。PSS への問い合わせ方法については、https://support.microsoft.com/security を参照してください。問題を解決する場合は、テスト時間が延長され、展開を遅らせる場合があるので、問題の解決を選択する前に、スケジュールに影響する可能性を考慮します。
すべての問題が解決または文書化されてテストが完了すると、セキュリティ更新プログラムまたは回避策の運用環境への展開を保証できます。
10. 更新プログラムと回避策の展開
セキュリティ更新プログラムや回避策がテストによって保証されたら、展開プロセスを続行できます。展開中には、実際にセキュリティ更新プログラムや構成の変更をシステムに適用できるようにガイドする計画を使用します。通常、計画の作成に関与したグループが、実際の展開を行います。
展開時に問題が発生した場合 (更新管理インフラストラクチャからセキュリティ更新プログラムを正常にインストールできない場合など)、その問題を慎重に調査する必要があります。問題によって遅延が生じる場合は、システムを保護するために、オプションを再調査したり、回避策を検討する場合もあります。
展開する前に、テスト プロセスで運用時に発生する可能性のある問題をすべて特定するのが理想的です。ただし、運用環境に展開した後に問題が発生した場合は、テスト中に問題が発生した場合と同じ手順を実行します。問題を評価し、それを許容するか解決するかを決定します。
セキュリティ更新プログラムが正常に適用されると、保護が機能し、これらのプロセスの最終目的が達成されます。ただし、正常に適用されない場合は、システムは脆弱な状態のままになります。
システムによっては正常に更新されていない可能性があるので、展開プロセスには非常に重要な最後の手順があります。この最後の手順では、システムを監査し、展開が成功したことを確認します。組織によっては、独立した監査グループが監査を行う場合もあります。こうした監査グループは、多くの場合、セキュリティ チームと連携して作業を行います。WSUS、MBSA、SMS などのマイクロソフトのツールを使用すると、セキュリティ更新プログラムが正常に適用されているかどうかを監査できます。また、セキュリティ更新プログラムが正常に適用されたかどうかを確認する方法については、セキュリティ情報の「セキュリティ更新プログラムに関する情報」を参照してください。
まとめ
マイクロソフトから毎月リリースされるセキュリティ情報リリースを使用すれば、セキュリティ更新プログラムを管理する場合に、定期的な計画とプロセスを実装できます。定期的な手順やプロセスを構築すれば、システムの保護を強化できると同時に、中断やダウンタイムの可能性を最小限に抑えることができます。
すべての組織がセキュリティ更新プログラムを管理する独自のプロセスを構築し、そのプロセスにはこのコラムで推奨している手順を含めます。セキュリティ チームと更新チームを個別に用意する必要はありませんが、セキュリティ リスクの評価と展開計画の作成はどちらも実行する必要があります。
このコラムの主な論点は、計画の重要性です。優れた計画では、実際の作業に関する手順 (テスト段階や展開段階など) が順調に進み、その結果、セキュリティ更新プログラムのプロセスが正常に完了します。
Christopher Buddは、Microsoft Security Response Center (MSRC) のセキュリティ プログラム マネージャで、IT プロフェッショナルやセキュリティ プロフェッショナルなどのソフトウェア ユーザーとの技術的なコミュニケーションを専門にしています。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.