セキュリティ リスク管理ガイド

この章は、このガイドで、マイクロソフトのセキュリティ リスク管理プロセスの全体的な概要を最初に紹介する章です。 概要を紹介した後、プロセスを展開する過程で参照できるいくつかの項目について検討します。 これらの項目を参照すると、優れたセキュリティ リスク管理プログラムのための強固な基盤を用意することができます。これには次のような項目があります。

また、リスク管理は、企業の上層部がビジネスを監視し情報を得た上での決断を行うためのより大きな統治プログラムの一部にすぎないことも、忘れないようにしてください。 統治プログラムは非常に多様ですが、すべてのプログラムで、セキュリティ リスクの優先順位を付けて軽減対策を行う構造化されたセキュリティ リスク管理コンポーネントが必要です。 マイクロソフトのセキュリティ リスク管理プロセスの概念を統治プログラムに適用することで、リスクを定義して許容可能なレベルまで管理することができるようになります。

トピック

	マイクロソフト セキュリティ リスク管理プロセスの 4 つのフェーズ
	要約

マイクロソフト セキュリティ リスク管理プロセスの 4 つのフェーズ

「第 2 章 セキュリティ リスク管理方法の概観」では、マイクロソフトのセキュリティ リスク管理プロセスについて紹介し、リスク管理を 4 つの主要なフェーズによる進行プロセスと定義しました。

要約すると、上記 4 段階のリスク管理のサイクルが、マイクロソフトのセキュリティ リスク管理のプロセスであり、このガイドの内容もすべて、このサイクルに従って説明されています。

ただし、マイクロソフト セキュリティ リスク管理プロセス内の具体的な方法を定義する前に、より大きなリスク管理プロセスとそのコンポーネントを理解することが重要です。 サイクルの各フェーズには、複数の詳細な手順が含まれています。 次の一覧は各手順の概略を示したもので、これを参照すると、このガイドの各フェーズの重要性を全体的に理解することができます。

次の図は、各フェーズと関連する手順を示したものです。

図 3.1 マイクロソフト セキュリティ リスク管理プロセス
拡大表示する

このガイドの以降の章では、マイクロソフト セキュリティ リスク管理プロセスの各フェーズについて順番に説明します。 ただし、このプロセスを実行する前に、いくつかの項目を事前に検討する必要があります。

労力レベル

組織がリスク管理に比較的慣れていない場合は、マイクロソフト セキュリティ リスク管理プロセスの中で通常セキュリティ リスク管理チームに最も大きな労力が要求される手順を検討しておくと便利です。 次の図は、プロセス全体にわたる相対的な労力の度合いを示したもので、マイクロソフトの IT 部門内で実行されたリスク管理活動に基づいています。 この全体図は、リスク管理に慣れていない組織に全体的なプロセスと期限を説明する際に利用できます。 相対的に示された労力レベルを参照して、全体的なプロセスのあるポイントで時間がかかりすぎる事態を防ぐこともできます。 プロセス全体の労力レベルを要約すると、データ収集には中程度の労力、概要分析には低い労力、詳細なリスク一覧の作成および意思決定支援プロセスの実行には高い労力が必要なことが、この図からわかります。 タスクとそれに関連する労力を示した他の資料については、Tools フォルダにあるサンプル プロジェクト スケジュール、SRMGTool4-Sample Project Schedule.xls を参照してください。 このガイドの残りの章では、下の図の各手順について、さらに詳細に説明します。

図 3.2 マイクロソフト セキュリティ リスク管理プロセス中の相対的な労力レベル
拡大表示する

マイクロソフト セキュリティ リスク管理プロセスの基盤を固める

セキュリティ リスク管理への取り組みを開始する前に、マイクロソフト セキュリティ リスク管理プロセスの基本となる前提知識およびタスクをしっかりと理解することが重要です。それには次のものがあります。

リスク管理と リスク評価

第 2 章で説明したように、"リスク管理" という用語と "リスク評価" という用語は代わりに使用できるものではありません。 マイクロソフトのセキュリティ リスク管理プロセスでは、"リスク管理" は、ビジネス全体で許容可能なレベルにリスクを管理する全体的なプロセスと定義されています。 "リスク評価" は、ビジネスに対するリスクを特定して優先順位を付けるプロセスと定義されています。 上の図で概要を説明したように、リスク管理は、リスクの評価、意思決定支援の実行、制御の実装、およびプログラムの効果の測定の 4 つのフェーズで構成されています。 リスクの評価は、マイクロソフトのセキュリティ リスク管理プロセスでは、より大きなリスク管理サイクル内の「リスクの評価」フェーズのみを指します。

リスク管理とリスク評価のもう 1 つの違いは、各プロセスの開始頻度です。 リスク管理は、進行中のサイクルとして定義されますが、通常は定期的な間隔で再起動され、管理プロセスの各段階でデータが更新されます。 リスク管理プロセスは、通常のビジネス プロセスを制御するためのさまざまな予算要求の時期を合わせるために、通常は組織の財務会計サイクルに足並みを揃えます。 新しい制御ソリューションを年間予算サイクルに合わせるために、リスク管理プロセスの間隔は 1 年に設定されるのが最も一般的です。

リスク評価は、リスク管理プロセスの必要とされる個別のフェーズですが、情報セキュリティ グループは、現状のリスク管理フェーズまたは予算サイクルとは関係なく複数のリスク評価を実行する場合があります。 情報セキュリティ グループは、新しいビジネス慣習の導入や脆弱性の発見、インフラストラクチャの変更など、ビジネス内でセキュリティ関連の変更が発生する可能性がある場合はいつでも、リスク評価を開始します。 このように頻繁に行われるリスク評価は、多くの場合 ad-hoc リスク評価、または範囲限定リスク評価と呼ばれ、公式なリスク管理プロセスの補足と考えられています。 ad-hoc 評価では、通常、ビジネス内のリスクの 1 つの領域に重点が置かれ、リスク管理プロセス全体と同量のリソースは必要とされません。 「付録 A: ad-hoc 評価」では、ad-hoc リスク評価の概要が説明されており、テンプレートの例を参照することができます。

表 3.1: リスク管理と リスク評価

リスクを通知する

リスク管理プロセスのさまざまな関係者が、"リスク"という用語を異なる意味合いで定義していることがよくあります。 リスク管理サイクルのすべての段階で一貫性を確保するために、マイクロソフト セキュリティ リスク管理プロセスでは、関係者はリスクという用語を 1 つの定義で理解してこれに同意することが必要です。 「第 1 章 セキュリティ リスク管理ガイドの紹介」で定義したように、リスクとは、ビジネスに発生する影響の確率です。 この定義には、影響ステートメント、および影響発生時期の予測つまり影響の確率が含まれる必要があります。 リスク ステートメントにこの両方の要素 (確率と影響) が含まれる場合、プロセスでは、これを "正しいフォームのリスク ステートメント" と呼びます。 リスクの複雑な性質の一貫した理解を確保するために、この用語を役立ててください。 次の図は、最も基本的なレベルでリスクを説明したものです。

図 3.3 正しいフォームのリスク ステートメント
拡大表示する

リスク管理プロセスに関与するすべての人間が、リスクの定義の各要素に内在する複雑さを理解する必要があります。 リスクを完全に理解することによってのみ、企業はリスクを管理するときに具体的なアクションを取ることができます。 たとえば、ビジネスへの影響を定義するには、影響を受ける資産、発生する可能性のある損害の種類、および資産に対する損害の範囲に関する情報が必要です。 次に、影響が発生する確率を判定するには、それぞれの影響が発生する経緯、現在の制御環境のリスクの確率の削減への効果を理解する必要があります。

次のリスク ステートメントでは、「第 1 章 セキュリティ リスク管理ガイドの紹介」で定義した用語を使用して、影響および影響の確率という両方の要素を示すガイダンスが示されています。

リスクとは、現在の環境で脆弱性が悪用され、資産の機密性、完全性、または可用性の一定程度の損失につながる確率のことです。

マイクロソフト セキュリティ リスク管理プロセスでは、各リスクの損失の確率と程度を絶えず通知および計測するツールが用意されています。 このガイドの各章では、正しいフォームのリスク ステートメントの各コンポーネントを作成して、ビジネス全体にわたるリスクを特定して優先順位を付けるプロセスを順を追って説明します。 次の図は、前述した基本のリスク ステートメントに基づいて、リスクの各要素の関係を示したものです。

図 3.4 正しいフォームのリスク ステートメントのコンポーネント
拡大表示する

リスク ステートメントで影響の範囲と確率の程度を通知するため、マイクロソフト セキュリティ リスク管理プロセスでは、高、中、低などの相対的な用語を使用して優先順位付けを開始します。 この基本用語を使用するとリスク レベルを容易に選択できますが、費用対利益分析を実行して最も効率的な対策オプションを選択する場合に必要な詳細な内容のものは、これでは用意できません。 基本的な定性的手法のこの弱点を解決するため、プロセスでは、リスクの詳細レベルの比較を作成するツールを提供しています。 プロセスにはまた、制御の選択のための費用対利益分析に役立つ定量属性も組み込まれています。

リスク管理の統制では一般的に、高、中、低など、ビジネスに対するリスクの定性的な定義を考慮に入れないことが多いという欠点があります。 多くのリスクは、セキュリティ リスク管理プログラムで特定されます。 マイクロソフト セキュリティ リスク管理プロセスでは、リスクの定性的および定量的な評価を一貫して適用するガイダンスが提供されますが、特定のビジネス用語で示されるそれぞれの値の意味を定義する責任は、セキュリティ リスク管理チームにあります。 たとえば、ビジネスに対する高いリスクは、1 年以内に脆弱性が発生して、組織のほとんどの重要な知的財産の完全性の損失につながることを意味する場合があります。 セキュリティ リスク管理チームは、正しいフォームのリスク ステートメントの各要素の定義を入力する必要があります。 次の章では、リスク レベルの定義に関する規範的なガイダンスを紹介します。 これを参照して、固有のビジネスのリスク レベルを定義することができます。 このプロセスにより実行が容易になり、プロセス全体にわたる一貫性と可視性の達成に役立てることができます。  

組織のリスク管理の成熟レベルを判定する

組織は、マイクロソフトのセキュリティ リスク管理プロセスを実装する前に、セキュリティ リスク管理に関する成熟度を調査する必要があります。 セキュリティ リスク管理に関連する公式なポリシーまたはプロセスが存在しない場合、プロセスのすべてを一度に実行することはきわめて困難です。 ほとんどの従業員が適正に従う公式なポリシーおよびガイドラインが存在する組織でさえ、このプロセスには対処しきれないと判明する可能性があります。 このような理由から、自分の組織の成熟度を見積もることが重要です。 組織の成熟度がまだ比較的高くないと判明した場合は、1 つのビジネス ユニットに試験的に導入してサイクルを数回実行するという手段で、プロセスを数か月にわたって段階的に導入することを希望する場合があります。 セキュリティ リスク管理チームは、このパイロット プログラムによってマイクロソフトのセキュリティ リスク管理プロセスの効果を実証した後、組織全体で使用されるようになるまで、プロセスを他のビジネス ユニットに徐々に導入していくことができます。

組織の成熟レベルを判定する方法を紹介します。 IT Governance Institute (ITGI) には、CobiT (Control Objectives for Information and related Technology) の一部として IT ガバナンスの成熟度モデルがあります。 自分の組織の成熟レベルを判定する詳細な方法として、CobiT を入手して参照してください。 マイクロソフト セキュリティ リスク管理プロセスでは、CobiT で使用されている要素がまとめられており、マイクロソフト サービスが開発したモデルにも基づく簡易アプローチが紹介されています。 ここで説明されている成熟レベルの定義は、ISO (International Standards Organization) の「Information technology — Code of practice for information security management」(別名 ISO 17799) に基づくものです。

次の表に記載されている定義と比較すると、組織の成熟レベルを見積もることができます。

表 3.2: セキュリティ リスク管理の成熟レベル

組織のリスク管理成熟レベルの自己評価

次の質問の一覧を利用すると、組織の成熟レベルをさらに厳密に測定することができます。 質問から導き出される回答は主観的なものですが、それぞれの回答を誠実に検討することで、マイクロソフト セキュリティ リスク管理プロセスを実装する準備が組織にどの程度できているかを判定できます。 0 点〜 5 点の評価で組織の点数を付けます。上述の成熟レベルの定義をガイドとして使用してください。

上記の項目すべての点数を合計して、組織の点数を算出してください。 理論上は、合計点数は 0 点から 85 点の範囲となりますが、この最低点または最高点になる組織はあまりありません。

51 点以上なら、組織はマイクロソフト セキュリティ リスク管理プロセスをすべて導入して活用する準備ができています。 34 点から 50 点の場合、組織はセキュリティ リスクを制御する有効な手段を多数実行しており、段階的にプロセスを導入する準備ができています。 この点数の組織は、組織全体にプロセスを適用する前に、数か月間少数のビジネス ユニットにプロセスをロールアウトすることを検討してください。 34 点未満の組織は、マイクロソフト セキュリティ リスク管理プロセスの開始をきわめて慎重に検討する必要があります。そのためには、中心となるセキュリティ リスク管理チームを創設し、最初の数か月間はプロセスを 1 つのビジネス ユニットに適用します。 プロセスを使用することでそのビジネス ユニットのリスクが無事低減され、その価値が実証されたら、別の 2 つか 3 つのビジネス ユニットに可能な限りプロセスを拡張します。 プロセスによって導入される変化は大きなものになる可能性があるため、移行はそのまま慎重に続けてください。 組織が混乱して、任務を効率的に遂行する機能に支障が発生するような事態は避ける必要があります。 この点に関しては、最善の判断をしてください。保護しないままになっているシステムはすべて、セキュリティおよび賠償リスクになる可能性があります。自分のシステムについては、自分の知識がベストです。 急を要するため、慎重な移行という推奨を無視して迅速な移行を行う場合は、そうしてもかまいません。

パイロット プログラムの使用対象とするビジネス ユニットについては、慎重に検討する必要があります。 検討すべき問題として、そのビジネス ユニットにとってのセキュリティの重要性があります。この場合、セキュリティは、情報とサービスの可用性、完全性、および機密性という意味で定義されます。 たとえば、次のような疑問が挙がります。

プログラム拡張対象のビジネス ユニットを選択する際にも、同じ問題を検討してください。

注 : 米国立標準技術研究所 (NIST) では、成熟レベルの判断に役立つ IT 自己評価の別のサンプルを提供しています。http://csrc.nist.gov/ (英語) の「特別公報 (special publication) 800-26」を参照してください。

役割と責任を定義する

リスク管理プログラムを成功させるためには、グループ間の協業および責任の分割化が必要です。役割と責任の明確化は、リスク管理プログラムの重要な成功要因です。 次の表は、マイクロソフト セキュリティ リスク管理プロセスの全体を通して使用される主な役割と責任を示したものです。

表 3.3: マイクロソフト セキュリティ リスク管理プロセスの主な役割と責任

セキュリティ リスク管理チームは、リスク管理プロセスで、自分の役割を完全に理解していない可能性がある初めての参加者に出会うことになります。 必ず、プロセスの概要を説明し参加者を紹介する機会を作ってください。 合意を形成して、すべての参加者がリスクの管理に責任があるという事実を明確にすることが目的です。 次の図は、主な参加者をまとめて大まかな関係を示したものです。この図を利用すると、上で定義した役割と責任を通知する場合に役立ちます。また、リスク管理プログラムの概要の説明にもなります。

要約すると、エグゼクティブ スポンサーは、許容可能なリスクを定義する最終的な責任を持ち、ビジネスに対するリスクのランク付けに関して、セキュリティ リスク管理チームにガイダンスを提供します。 セキュリティ リスク管理チームは、リスクの評価に責任を持ち、リスクを許容可能なレベルまで軽減する機能要件を定義します。 次に、セキュリティ リスク管理チームは IT グループと共同作業を行います。IT グループは、対策ソリューションの選択、実装、運用を担当します。 下の図で定義された関係は最終的に、セキュリティ リスク管理チームによる制御の効果の測定の監視で終わります。 これは通常、監査報告書の形で行なわれ、エグゼクティブ スポンサーにも提供されます。

図 3.5 マイクロソフト セキュリティ リスク管理プロセスの全体で使用される役割と責任の概要
拡大表示する

セキュリティ リスク管理チームを構築する

リスク評価プロセスを開始する前に、セキュリティ リスク管理チーム内の役割を明確に定義する必要があることを忘れないでください。 リスク管理の範囲にはビジネス全体が含まれるため、情報セキュリティ グループ以外のメンバが、チームの一員となることを求める場合があります。 この場合、各メンバの明確な役割の概要を示し、前述のリスク管理プログラム全体の定義された役割と責任に合わせるようにします。 役割の定義を早期に行っておくと、混乱が少なくなり、プロセス全体での意思決定支援に役立ちます。 チームのすべてのメンバは、情報セキュリティ グループがプロセス全体を担当していることを理解している必要があります。 情報セキュリティ グループは、幹部への報告など、プロセスのあらゆる段階で主要な関係者の役割を努める唯一のグループであるため、担当内容の定義は重要です。

セキュリティ リスク管理チームの役割と責任

セキュリティ リスク管理チームを構成した後、具体的な役割を作成して、プロセス全体でその役割を維持することが重要です。 リスク評価進行担当者およびリスク評価記録担当者の主要な役割について、次に説明します。

リスク評価進行担当者は、リスク管理プロセス全体についての広範な知識を持ち、ビジネスを完全に理解し、ビジネス機能の陰に隠れた技術的なセキュリティ リスクを理解している必要があります。 リスク評価進行担当者は、ビジネス シナリオを技術的なリスクに変換しながら、リスクの検討を実行できる必要があります。 一例として、リスク評価進行担当者は、モバイル ワーカーおよびこのようなワーカーのビジネス価値の、技術的脅威および脆弱性の両方を理解している必要があります。 たとえば、モバイル ワーカーが会社のネットワークにアクセスできない場合、顧客の支払いが処理されなくなります。 リスク評価進行担当者は、こうしたケースを理解して、モバイル機器の構成や認証要件などの技術的なリスクと潜在する制御要件を特定できる必要があります。 可能であれば、過去にリスク評価を実行したことがあるか、またはビジネスの全体的な優先度を理解しているリスク評価進行担当者を選択してください。

リスク評価の経験がある進行担当者がいない場合は、資格のあるパートナーまたはコンサルタントの協力を得てください。 ただし、ビジネスを理解している情報セキュリティ グループのメンバと利害関係者は必ず含めてください。

注 : リスク評価の進行を担当する役割をアウトソーシングする方法は魅力的に見えますが、担当したコンサルタントがいなくなると、関係者同士の関係、ビジネス、およびセキュリティの知識が失われます。 リスク管理プロセスにより関係者および情報セキュリティ グループにもたらされる価値を過小評価しないでください。

リスク評価記録担当者は、メモを取り、計画策定およびデータ収集活動について文書化する責任を持ちます。 この責任は、この段階で役割を定義するには非公式すぎる役割に思えるかもしれませんが、確実に記録を取るスキルがあると、プロセス後半の優先順位付けおよび意思決定支援プロセスを実施する際に役立ちます。 リスク管理の最も重要な点の 1 つは、各関係者が理解し自分の業務に適用できるという意味で、リスクを通知することです。 優れた記録担当者は、必要に応じて文書を提供し、このプロセスをより簡単にします。

ページのトップへ

要約

第 1 章から第 3 章では、リスク管理の概要を説明し、目標と手法を定義して、マイクロソフトのセキュリティ リスク管理プロセスを正しく実装するための基盤の構築を開始できるようにしました。 次の章では、最初のフェーズである「リスクの評価」について詳細に説明します。 それ以降の章では引き続き、リスク管理プロセスのそれぞれのフェーズ、「意思決定支援の実行」、「制御の実装」、「プログラムの効果の測定」について説明します。

ページのトップへ

4 of 12