次の方法で共有

セキュリティ リスク管理ガイド : 第 4 章 : リスクの評価

第 4 章 : リスクの評価

公開日: 2005年1月13日

トピック

概要 計画 簡易データ収集 リスクの優先順位付け 要約

概要

全体的なリスク管理プロセスは、「リスクの評価」、「意思決定支援の実行」、「制御の実装」、および「プログラムの効果の測定」の 4 つの主なフェーズで構成されています。 リスク管理プロセスでは、組織全体のリスクを管理するため、限定されたリソースをまとめる一貫した経路を正式なプログラムがどのように提供するかを示します。 利益は、リスクを受け入れ可能なレベルに導いて評価する、費用効果の高い制御環境を開発することによって実現されます。

「リスクの評価」フェーズでは、組織全体にわたるリスクを特定し、優先順位を付ける正式なプロセスを示します。 マイクロソフト セキュリティ リスク管理プロセスは、リスク評価の実行について詳細な指示を与え、「リスクの評価」フェーズのプロセスを次の 3 つの手順に分割します。

  1. 計画 —適切なリスク評価の基盤を構築します。

  2. 簡易データ収集 — リスクの討議を促進しつつ、リスク情報を収集します。

  3. リスクの優先順位付け — 特定したリスクを一環した反復可能なプロセスでランク付けします。

「リスクの評価」フェーズで作成される情報は、「意思決定支援の実行」フェーズに情報を提供する、リスクの優先順位一覧です。「意思決定支援の実行」フェーズについては「第 5 章 : 意思決定支援の実行」で詳細に説明します。

次の図は、リスク管理プロセス全体と、大規模なプログラム内でのリスクの評価の役割を示しています。 「リスクの評価」フェーズの 3 つのステップについても説明しています。

図 4.1 マイクロソフト セキュリティ リスク管理プロセス : 「リスクの評価」フェーズ

拡大表示する

ここでは、「リスクの評価」フェーズの 3 つのステップ (計画、簡易データ収集、リスクの優先順位付け) の簡単な概要を説明します。 後に続く項で、ご利用の環境で実際のリスク評価を実行するための特定の作業について説明します。

計画

リスクの評価を正しく計画することは、リスク管理プログラム全体を成功させるために重要です。 「リスクの評価」フェーズで、適切な調整、範囲の決定、および承認を得ることに失敗すると、大規模なプログラムにおける他のフェーズの効果が小さくなります。 リスクの評価は、完了するために巨額の投資が必要な複雑なプロセスになる可能性があります。 計画手順の重要なタスクとガイダンスは、この章の次の項で説明します。

簡易データ収集

計画したら、次に、組織全体の関係者からリスク関連情報を収集します。この情報は「意思決定支援の実行」フェーズにも使用します。 簡易データ収集手順で収集される主なデータ要素は、次のとおりです。

  • 組織の資産 — ビジネスにとって価値のあるものすべて

  • 資産の説明 — 「リスクの評価」フェーズ全体の共通理解を促進にするための、各資産の概略、その価値、および所有権

  • セキュリティの脅威 — 資産の機密性、完全性、または可用性の損失によって表される、資産に悪影響をおよぼす原因またはイベント

  • 脆弱性 — 資産に影響する可能性のある弱点またはコントロールの欠落

  • 現在の制御環境 — 現在の制御および組織全体へのその効果の説明

  • 提案された制御 — リスクを削減する初期アイデア

簡易データ収集手順は、「リスクの評価」フェーズでの多数のグループ間コラボレーションと相互作用を表します。 この章の 3 番目の項は、データ収集タスクとガイダンスについて詳細に説明します。

リスクの優先順位付け

簡易データ収集手順では、セキュリティ リスク管理チームが、リスクに優先順位を付けるために収集された大量の情報のソートを開始します。 リスクの優先順位付け手順は、主観性の要素を含む、フェーズ内で最初の手順です。 優先順位付けは、そのプロセスに未来の予測が基本的に含まれるため、結局は主観的になります。 リスク評価で作成される情報は、将来の情報技術 (IT) への投資を左右するため、定義済みの役割と責任を利用してわかりやすいプロセスを確立することが、評価結果の承認を受け、リスク軽減措置を取る動機付けのために重要です。 マイクロソフト セキュリティ管理プロセスでは、一貫した反復可能な方法でリスクを特定し、優先順位を付けるガイダンスを提供しています。 オープンで再現可能な手法だと、セキュリティ リスク管理チームですぐに意見の合意に達するので、リスクの優先順位付けの主観的な性質からくる遅延を最低限に抑えるのに役立ちます。 この章の 4 番目の項では、優先順位付けタスクとガイダンスについて詳細に説明します。

「リスクの評価」フェーズで必要な情報

「リスクの評価」フェーズの各手順には、規範的なタスクおよび関連情報の特別な一覧が含まれます。 このフェーズ自体には、特定の情報ではなく、堅牢に構築された基盤が必要です。 第 1 章で概略を説明したように、「リスクの評価」フェーズには、経営幹部のサポート、関係者の承認、および定義済みの役割や責任という形でのセキュリティ リーダーシップが必要です。 次の各項では、これらの領域について詳細に説明します。

「リスクの評価」フェーズの参加者

「リスクの評価」には、グループ間の情報交換が必要であり、また、さまざまな関係者がプロセス全体にわたるタスクに責任を持つことも必要です。 プロセス全体にわたる役割の混乱を小さくする最善の方法は、互いに確認し合い、リスク管理の役割と責任のバランスを取ることです。 評価を実行する間、関係者が果たす役割について情報を交換し、セキュリティ リスク管理チームがこれらの役割の範囲を尊重することを関係者に約束します。 次の表は、リスク管理プロセスのこのフェーズでの関係者の役割と主な責任を要約したものです。

表 4.1: リスク管理プログラムにおける役割と責任

役割 責任
事業主 ビジネス資産の価値を判断します
情報セキュリティ グループ ビジネス資産への影響の発生確率を判断します
情報技術 - エンジニアリング 技術ソリューションを設計し、エンジニアリング コストを見積もります
情報技術 - 運用 ソリューションの運用コンポーネントを設計して、運用コストを見積もります
組み込まれている技術チェックとバランスの機能については、「リスクの評価」フェーズの計画、簡易データ収集、およびリスクの優先順位付け手順を詳細に検証する以降の項で説明します。 #### 「リスクの評価」フェーズで提供されるツール このリスクの評価プロセス中にリスクに関するデータを収集し、そのデータを使用してリスクの優先順位を付けます。 このフェーズには、手順を支援する 3 つのツールが含まれています。 このガイドと関連ファイルを含むアーカイブをアンパックしたときに作成された "Tools and Templates" フォルダにこれらのツールがあります。 - **データ収集テンプレート** (SRMGTool1-Data Gathering Tool.doc)。 リスク データの収集に関する討議を促進させるテンプレート。 - **資産価値一覧** (SRAPPB.doc)。 組織内に通常ある一部の資産の一覧。 - **リスク優先順位付けテンプレート** (SRMGTool2-Summary Risk Level.xls および SRMGTool3-Detailed Level Risk Prioritization.xls)。 リスクの優先順位付けを支援する Microsoft® Excel のテンプレート。 - **サンプル スケジュール** (SRMGTool4-Sample Project Schedule.xls)。 このスケジュールは、このフェーズの計画作業に役立つ場合があります。 #### 「リスクの評価」フェーズで作成する必要がある情報 「リスクの評価」フェーズで作成する情報は、次の章で説明する「意思決定支援の実行」フェーズで使用される定性的なランク付けと定量的な見積もりを含むリスクの優先順位一覧です。 [](#mainsection)[ページのトップへ](#mainsection) ### 計画 計画の手順は、関係者による承認とリスクの評価プロセス全体を通しての支援を確保するために最も重要であるといえます。 セキュリティ リスク管理チームは他の関係者からの活動参加を必要としているため、関係者の承認は重要です。 リスクを軽減するために新しい制御が必要な場合、評価の結果が関係者の予算編成作業に影響する可能性があるため、支援も重要です。 計画手順の主なタスクは、「リスクの評価」フェーズをビジネス プロセスに結び付け、評価の範囲をきちんと決定し、関係者の承認を得ることです。 以降の項では、これら 3 つのタスクをより詳細に検証し、その成功要因について説明します。 #### 調整 組織の予算編成プロセスの前に「リスクの評価」フェーズを開始するのが理想的です。 調整により、経営幹部からのサポートを得ることが簡単になり、次の会計年度の予算編成作業の間に組織および IT グループ内での認識が向上します。 正しいタイミングを見極めることも、関係者が計画プロセスで積極的な役割を果たせるようになるので、合意形成に役立ちます。 情報セキュリティ グループは、制御の失敗や作業の停止により、組織の活動を中断させたり、ビジネス ユニットを驚かせることがあり、反発的なチームとみなされることがよくあります。 評価を的確なタイミングで行うことは、サポートを構築するために重要です。そして、組織において、セキュリティが全員の責任であり、組織に浸透しているという認識が深まります。 リスクの評価を実行するもう1つの利点は、情報セキュリティ グループが単なる緊急時のポリシー実行者ではなく、積極的なパートナーとみなすことができることを実証する点にあります。 このガイドでは、リスクの評価プロセスを各自の組織に合わせるのに役立つ、サンプル プロジェクト タイムラインを提供します。 言うまでもなく、セキュリティ リスク管理チームは、予算編成サイクルを待っている間にリスク情報を保留すべきではありません。 評価のタイミングの調整は、まさにマイクロソフトの IT 部門における評価の実施から学んだベスト プラクティスです。 **注 :** リスク管理プロセスと予算計画サイクルの的確な調整は、内部または外部の監査作業にも利益をもたらしますが、監査作業の調整と範囲の決定についてはこのガイドで扱いません。   #### 範囲を決定する 計画作業の間に、リスク評価の範囲を明確にします。 組織全体にわたってリスクを効果的に管理するには、リスク評価の範囲を決定する際に、リスクの評価に関与する組織の機能をすべて文書化する必要があります。 組織の規模が原因でエンタープライズ レベルのリスクを評価できない場合は、組織のどの部分が範囲に含まれるかを明らかにして、関連する関係者を定義します。 第 2 章で説明したように、自分の組織がリスク管理プログラムを初めて利用する場合は、プログラムをよく理解したビジネス ユニットからリスクの評価プロセスを実行し始めることができます。 たとえば、特定の人事アプリケーションやリモート アクセスなどの IT サービスが、プロセスの価値を実証し、企業全体でリスクを評価する機運を形成するのに役立つことがあります。 **注 :** 組織では、リスクの評価範囲を正確に決定できないことがよくあります。 評価対象の組織の領域を明確に定義し、経営幹部の承認を得てから、先に進んでください。 プロセス全体を通して、すべての関係者が集まる会議で範囲について頻繁に討議し、理解する必要があります。 計画段階において、リスクの評価自体の範囲も定義する必要があります。 情報セキュリティ業界では、評価という言葉をさまざまな意味で用いるため、技術に詳しくない関係者が混乱することがあります。 たとえば、脆弱性評価は特定の技術に固有の構成や運用上の弱点を識別するために実行されます。 準拠評価という用語は、正式なポリシーに照らし合わせて、現在の制御を監査、または測定する際のやり取りに使われる場合があります。 マイクロソフト セキュリティ リスク管理プロセスは、リスクの評価を*組織に対するエンタープライズ IT セキュリティ リスクを識別して優先順位を付けるためのプロセス*として定義しています。 この定義は各自の組織に合うように調整できます。 たとえば、セキュリティ リスク管理チームによっては、リスクの評価範囲に個人のセキュリティを含める場合もあります。 #### 関係者の承認 リスクの評価には関係者の積極的な参加が必要です。 関係者と非公式にプロセスの初期段階で折衝して、評価の重要性、関係者の役割、必要な時間的な拘束を理解してもらうことをお勧めします。 熟練したリスク評価進行担当者なら、関係者によるプロジェクトの承認とプロジェクトの時間および優先順位の承認の違いを説明できます。 関係者の支援を得るには、リスク評価のコンセプトと作業を事前に説明することをお勧めします。 事前説明には、正式な関与を求める前に関係者と非公式に会うことも含まれます。 先を見越した評価が、今後発生するセキュリティ問題による混乱を回避する制御を特定することにより、長期的に関係者に役立つことを強調してください。 過去のセキュリティ インシデントを例として討議に含めると、組織への影響の可能性を関係者に認識してもらうのに効果的です。 **注 :** 関係者がプロセスを理解するのに役立つように、評価の正当性と価値を説明する簡単な概要を用意してください。 この概要は、できるだけ共有してください。 関係者が互いに評価を説明するのを聞けば、効果があったことがわかるでしょう。 このガイドの概要は、リスクの評価プロセスの価値を伝える絶好の出発点となります。 #### 成功するための準備 : 期待値を設定する 正しい期待値の設定を過度に強調することはできません。 プロセスには、組織全体を代表するさまざまなグループからの大きな貢献が必要であるため、リスクの評価を成功させるには適切な期待値を設定することが重要です。 さらに、参加者は、自分の役割およびより大規模なプロセスの成功要因に同意し、理解する必要があります。 このようなグループの 1 つが理解しなかったり、実際に参加しない場合、プログラム全体の効果が損なわれる可能性があります。 計画手順で合意を形成すると同時に、経営陣の役割、責任に関する期待値、および他の関係者の参加レベルを設定してください。 また、評価によって提示される課題を共有する必要もあります。 たとえば、リスクの識別と優先順位付けプロセスを明確に記述することによって、誤解が生じるのを防ぐことができます。 #### 主観を受け入れる 外部のグループ (この場合、情報セキュリティ グループ) が会計の優先順位に影響を与える可能性のあるセキュリティ リスクを予測することに、事業主が神経質になることがよくあります。 リスクの評価プロセスの目標に関する期待値を設定し、プロセス全体を通して各自の役割と責任が尊重されることを関係者に保証することにより、この自然に発生する対立を緩和することができます。 特に、情報セキュリティ グループが、ビジネス資産の価値を定義するのは事業主であることを認識している必要があります。 これは、組織に影響を与える脅威の確率を評価する際に、関係者が情報セキュリティ グループの専門知識に頼る必要があることも意味します。 将来の予測は、当然ながら主観的なものとなります。 事業主は、情報セキュリティ グループが専門知識を利用してリスク発生の確率を予測していることを認識し、支援しなければなりません。 このような関係を早期に確立し、情報セキュリティ グループと事業主の信頼関係、経験、および共通の目標を示してください。 計画手順を完了して、役割と責任を明確にし、期待値を適切に設定したら、リスクの評価プロセスのフィールド ワークの手順、すなわち簡易データ収集とリスクの優先順位付けを開始できます。 第 5 章で「意思決定支援の実行」フェーズの説明を行う前に、次の 2 つの項でこれらの手順を詳しく説明します。 [](#mainsection)[ページのトップへ](#mainsection) ### 簡易データ収集 この章の「概要」では、リスク評価プロセスを紹介し、計画、簡易データ収集、およびリスクの優先順位付けの 3 つの主な手順を説明しました。 計画作業を完了したら、組織全体の関係者からリスク データを収集します。 この情報をリスクの特定と最終的な優先順位付けに役立てます。 この項は 3 つの部分で構成されています。 第 1 部では、データ収集プロセスを詳細に説明し、リスク情報を収集するときの成功要因に焦点を当てます。 第 2 部では、技術系関係者と非技術系関係者との円滑な会議でリスク データを収集する、詳細な手順を説明します。 第 3 部では、このデータの集積を第 3 章で説明した一連の影響ステートメントに統合する手順を説明します。 リスクの評価プロセスを完了するために、この影響ステートメントの一覧は、次の項で詳細を説明する優先順位付けプロセスにも情報を提供します。 #### データ収集を成功するための鍵 セキュリティの専門的な経験のない人々に、情報技術に関連するリスクについて詳細な質問をすることに疑問を持たれるかもしれません。 マイクロソフトの IT 部門でリスクを評価した経験によれば、技術系および非技術系の両方の関係者に自分が管理する組織の資産に対するリスクについて考えを聞くことは、非常に大きな価値があることがわかっています。 情報セキュリティの専門家は、関係者の懸念事項に関する詳細な知識を得て、それぞれの環境に関する情報をリスクの優先順位付けに反映させる必要があります。 関係者と協力して会議を開くことは、関係者自身が理解できて評価できる言葉でリスクを納得する手助けになります。 また、関係者は IT 費用を制御したり、影響を与えたりします。 その関係者が組織への潜在的な影響を理解していないと、リソースの割り当てプロセスがさらに難しくなります。 さらに、事業主は企業文化を推進し、ユーザーの行動に影響を与えます。 この点だけでも、リスクを管理するときに協力なツールとなります。 リスクが発見された場合、情報セキュリティ グループは、リソースを割り当て、リスクの定義と優先順位付けに関する合意を形成する際に、関係者のサポートが必要になります。 予防的なリスク管理プログラムを持たない情報セキュリティ グループでは、組織を動かすために、リスクへの不安に頼ることがあります。 これは、せいぜい短期的な戦略として使えるだけです。 情報セキュリティ グループは、リスク管理プログラムを長期的に維持する場合、組織のサポートを求めることを学ばなければなりません。 このサポートを形成する第一のステップは、関係者と対面して会議を開くことです。 ##### 支援体制を確立する 事業主には、リスクの評価プロセスにおいて明確な役割があります。 組織の資産を特定し、これらの資産に対する潜在的な影響のコストを見積もる責任があります。 この責任を正式化することにより、情報セキュリティ グループと事業主は、リスクの管理の成功を均等に分かち合えます。 情報セキュリティの専門家と非技術系の関係者のほとんどは、このつながりを無意識に理解することはありません。 情報セキュリティの専門家は、リスク管理の専門家として、リスクのさまざまな討議での知識のギャップを橋渡しするため、イニシアチブを取る必要があります。 前の章で説明したように、組織を理解しているエグゼクティブ スポンサーの協力を得れば、この関係の確立はさらに簡単になります。 ##### 討議と問い合わせ 多くのセキュリティ リスク管理手段では、情報セキュリティ グループが関係者に明示的な質問をして、回答を集める必要があります。 この種の質問の例としては、「職務の適切な区分を保証するポリシーを説明していただけませんか。」とか「どのようなプロセスでポリシーと手順を見直していますか。」といったものがあります。会議の基調と方向性に注意してください。 双方向の討議を容易にするために、自由回答式の質問に重点を置くことをお勧めします。 これにより、関係者もリスク評価進行担当者に対して、自分たちが何を考え、何を聞きたがっているかを自由に答えることができます。 リスクの討議の目的は、組織と組織を取り巻くセキュリティ リスクを理解することで、文書化されたポリシーの監査を実行することではありません。 非技術系の関係者の情報は貴重ですが、通常は包括的なものではありません。 事業主から独立したセキュリティ リスク管理チームは、依然として、資産ごとにすべてのリスクを調査し、研究し、検討する必要があります。 ##### 信用を確立する 情報セキュリティは、リスク軽減の実践が利便性や従業員の生産性の低減とみなされることが多いため、難しいビジネス機能です。 円滑な討議を利用して、関係者との連携を確立してください。 法律、プライバシーの懸念、競合企業からの圧力、さらに消費者の認識の向上により、経営陣やビジネス ディシジョン メーカー (BDM) は、セキュリティが非常に重要なビジネスの構成要素だと認識するようになってきています。 関係者がリスク管理の重要性とより大規模なプログラムでの自分たちの役割を理解できるように支援してください。 情報セキュリティ グループと関係者の間の関係の構築が、会議中に収集される実際のデータよりも生産性を向上させる場合があります。 これは、今のところは小さいながらも、より大規模なリスク管理の取り組みにおいては、重要な成果です。 #### リスクの討議の準備 リスクの討議を開始する前に、セキュリティ リスク管理チームは、討議の対象となる各要素を調査して、明確に理解することに時間を費やす必要があります。 以降では、推奨手順を説明し、関係者との討議をさらに円滑に進める準備として的確に形成されたリスク ステートメントの各要素を定義します。 ##### リスクの評価情報を特定する リスクの評価チームは、関係者に会う前に十分な準備が必要です。 チームが組織、技術環境、および過去の評価活動を明確に理解すれば、チーム自体がより効率的になり、討議の生産性が向上します。 次の一覧は、リスクの評価プロセスへの情報として使用される資料の収集に役立ちます。 - **新しい事業推進者** — 組織の優先順位または前回の評価以降に行なった変更について理解を新たにします。 企業合併および買収の活動に特に注意してください。 - **以前のリスクの評価** — 評価の観点を提供する過去の評価を見直します。 リスクの評価チームは、以前の評価に照らして、新しい評価を調整しなければならない場合があります。 - **監査** — リスク評価の範囲に関する監査レポートを収集します。 監査結果は、評価で、および新しい制御ソリューションを選択するときに報告する必要があります。 - **セキュリティ インシデント** — 過去のインシデントを使用して主要な資産を特定し、資産の価値を理解して、主な脆弱性を特定し、制御の欠陥に注目します。 - **業界イベント** — 組織内の新たな傾向および外部の影響を特定します。 政府の規制、法律、および国際活動がリスクに対する考え方に大きな影響を与えます。 新しい傾向を見つけるには、組織からの十分な調査と評価が必要になる場合があります。 年間を通して調査する担当者がいるとよいでしょう。 - **セキュリティ情報  —  **Web、ニュースグループ、およびソフトウェア ベンダで特定された既知のセキュリティ問題を見直します。 - **情報セキュリティ ガイダンス** — リスク管理の新しい傾向、ツール、またはアプローチを利用できるかどうかを判断するため、調査を実施します。 リスクの評価プロセスの改善や正当化、または新しい制御戦略の特定に、業界標準を利用できます。 業界標準は重要な情報の 1 つです。 このガイドには、ISO 17799 などの多くの標準からのコンセプトが含まれています。 標準を慎重に評価して適用することにより、他の専門家の作業成果を利用し、組織の関係者に十分な信用を与えることができます。 評価が情報セキュリティの適用可能な全領域を対象としていることを確認するために、リスクの討議中に標準を具体的に参照することは有用です。 #### 資産を特定して分類する リスク評価の範囲は、データ収集の討議で検討された組織の領域を定義します。 リスクの討議を推進するために、この範囲内のビジネス資産を特定する必要があります。 資産は、組織にとって価値のあるものと定義されます。 これには、企業の評判やデジタル情報などの無形資産と物的な基盤などの有形資産が含まれます。 最も効果的な手法は、ビジネス資産を定義するときにできる限り具体的に定義することです。たとえば、顧客管理アプリケーションのアカウント情報などです。 資産を定義するときに影響ステートメントを討議する必要はありません。 影響ステートメントは、組織に生じる可能性のある損失または損害を定義します。 影響ステートメントの一例として、顧客管理アプリケーションのアカウント データの可用性があります。 影響ステートメントは、その後のリスクの討議で拡張されます。 討議を通して、各資産に複数の影響が見つかる場合があることに注意してください。 資産を特定する一方で、資産の所有者も特定または確認してください。 資産に責任のある個人またはグループの特定が、見かけよりも困難な場合があります。 リスクの討議を促進する中で、特定の資産所有者を文書化してください。 この情報は、優先順位付けプロセス中に情報を確認し、資産所有者に直接リスクを伝えるために役立つことがあります。 資産の分類を容易にするため、たとえばオンライン バンキング取引やソース コード開発などのビジネス シナリオに資産をグループ分けするよいでしょう。 非技術系の関係者と作業するときは、ビジネス シナリオから資産の討議を始めます。 次に、各シナリオ内の特定の資産を文書化します。 資産を特定した後、事業主が次に行わなければならないのは、組織への影響の可能性という点から各資産を分類することです。 資産の分類は、リスクを全体的に平均化する上で重要な構成要素です。 次のセクションは、このプロセスに役立ちます。 ##### 資産 ビジネス資産には、有形資産と無形資産があります。 事業主が組織に関する資産価値を明確にすることができるように、いずれの種類の資産も定義する必要があります。 関係者は、資産の両方のカテゴリについて、直接的な金銭的損失および間接的な経済的損失の形で見積もりを提供する必要があります。 有形資産には、データ センター、サーバー、および財産などの物的基盤が含まれます。 無形資産には、銀行取引、利息計算、および製品開発計画や仕様など、組織にとって価値のあるデータやデジタル情報が含まれます。 組織によっては、第 3 の資産として IT サービスを定義するとよい場合があります。 IT サービスは、有形資産と無形資産を組み合わせたものです。 たとえば、企業の IT 電子メール サービスには物理的なサーバーが含まれ、物理的なネットワークを使用しますが、このサービスには重要なデジタル データが含まれることがあります。 また、データと物理資産の所有者が通常異なるため、IT サービスを資産として含める必要があります。 たとえば、電子メール サービスの所有者は、電子メールへのアクセスと送信の可用性について責任を負います。 しかし、電子メール内の財務データの機密性や電子メール サービスに関連する物理的制御については、責任を負いません。 IT サービスにはその他に、ファイルの共有、ストレージ、ネットワーク、リモート アクセス、テレフォニーなどがあります。 ##### 資産クラス 評価の範囲内の資産は、定性的グループまたはクラスに割り当てられます。 クラスは、セキュリティ リスクの全体的な影響の定義を容易にします。 また、組織が最重要資産に最初に注目できるようにします。 さまざまなリスクの評価モデルによって、多様な資産クラスが定義されます。 マイクロソフト セキュリティ リスク管理プロセスでは、組織での資産価値の測定に役立つ 3 つの資産クラスを使用します。 クラスが 3 つだけであるのは、 この 3 つで十分な区別が可能であり、適切なクラス指定に関する討議および選択の時間が短縮されるためです。 マイクロソフト セキュリティ リスク管理プロセスで定義する定性的資産クラスは、HBI (high business impact)、MBI (moderate business impact)、および LBI (low business impact) の 3 つです。 このプロセスでは、リスクの優先順位付け手順の間に、資産を数値化するガイダンスも提供します。 組織によっては、リスクの討議を促進する中で資産の数値化を選択する場合があります。 資産を数値化する場合、リスクの討議中に金銭価値の数値化に関して合意に達するための時間が必要であることに注意してください。 このプロセスでは、さらに分析が必要なリスクの数を減らすために、すべてのリスクが識別され、優先順位が付けられるまで待つことをお勧めします。 **注 :** 情報の定義と分類および情報システムの詳細については、米国立標準技術研究所 (NIST) の Special Publication 800-60 ワークショップ「(Mapping Types of Information and Information Systems to Security Categories」、および米連邦政府情報処理規格 (FIPS) 199「Security Categorization of Federal Information and Information Systems」を参照してください。 ###### HBI (High Business Impact) これらの資産の機密性、完全性、または可用性への影響は、組織に重大なまたは致命的な損失を与える原因になります。 影響は、実際の財務項目で表されることもあり、また、金融商品の間接的な損失や盗用、組織の生産性、顧客信頼度へのダメージ、または重大な法律上および規制上の責任に反映される場合もあります。 次の一覧は、HBI クラスに含まれるものの一例を示しています。 - **認証資格情報** — パスワード、プライベート暗号化キー、およびハードウェア トークン - **機密性の高いビジネス素材** — 財務データや知的財産など - **特定の規制要件に基づく資産** — GLBA、HIPAA、CA SB1386、および EU データ保護条例など - **個人を識別できる資産 (PII)** — 攻撃者が顧客や従業員を識別したり、個人的特徴を知ることのできる情報 - **金融取引の認証データ** — クレジット カード番号や有効期限など - **金融プロファイル** — 消費者信用レポートや個人の収入証明書など - **医療プロファイル** — 医療記録の番号や生体認証IDなど このクラスの資産の機密性を保護するために、アクセスは、組織内の関係者のみが使用するように厳格に制限されています。 このデータへのアクセス権を持つ人の数は、資産の所有者により明示的に管理されなければなりません。 このクラスの資産の完全性と可用性には、均等に注意を払う必要があります。 ###### MBI (Moderate Business Impact) これらの資産の機密性、完全性、または可用性への影響は、組織に中程度の損失を与える原因になります。 中程度の損失は、重大な影響や致命的な影響とはなりませんが、通常の組織の機能を中断し、この資産クラス内の影響を最小限にする予防的な制御が必要になるレベルまで達します。 中程度の損失は、実際の財務項目で表されることもあり、また、金融商品の間接的な損失や盗用、事業の生産性、顧客信頼度へのダメージ、または重大な法律上および規制上の責任が含まれることもあります。 これらの資産は、正当なビジネス ニーズを持つ、従業員や従業員以外の承認された個人で構成された指定グループによる使用を目的としています。 MBI クラスに含まれるものの一例を次に示します。 - **内部ビジネス情報** — 従業員名簿、購買発注データ、ネットワーク インフラストラクチャ設計、社内 Web サイトに関する情報、および社内業務専用の社内ファイル共有にあるデータ ###### LBI (Low Business Impact) HBI と MBI のいずれにも該当しない資産は、LBI として分類され、インフラストラクチャの安全を確保する標準的なベスト プラクティスを超える公式の保護要件や追加制御は採用されません。 これらの資産は、通常、広く公開されることを目的としており、不正な開示でも重大な財務損失、法律または規制上の問題、処理上の混乱、または競合ビジネスの不利益につながることはありません。 LBI 資産の例には次のものが含まれますが、これに限定されません。 - 上位の組織構造 - IT オペレーティング プラットフォームに関する基本情報 - 一般にアクセス可能な Web ページへの読み取りアクセス権 - 公開暗号化キー - 発行済みのプレス リリース、製品パンフレット、ホワイト ペーパー、およびリリース済み製品に含まれるドキュメント - 使われていないビジネス情報または有形資産 #### リスク情報を整理する リスクには、資産、脅威、脆弱性、および制御にわたる多数の構成要素が含まれます。 リスク評価進行担当者は、どのリスク構成要素なら会話の流れを中断することなく討議できるかを判断できなければなりません。 討議をスムーズに進行させるには、ツール セクションに格納されているリスク討議用テンプレート (SRMGTool1-Data Gathering Tool.doc) を使用して、出席者がリスク内の構成要素を理解できるようにします。 このテンプレートは、リスク評価記録担当者が会議中にメモを取る作業にも役立ちます。 このテンプレートはどのような順序で使用してもかまいません。 しかし、これまでの経験から、次の疑問に関しては順序を守ることにより、討議の参加者がリスクを理解し、より多くの情報が明らかになることがわかっています。 - どの資産を保護するのか。 - 資産が組織にとってどの程度の価値を持つのか。 - 資産への脅威の発生 (既知の脅威と潜在的な脅威の両方) をどのように回避しようとしているか。 - 損失やエクスポージャはどのように発生するか。 - 資産への潜在的な危険度はどの程度か。 - 資産への損害の発生確率または損害の範囲を小さくするために、現在何を行なっているか。 - 将来の発生確率を小さくするためにどのような措置を実行できるか。 情報セキュリティの専門家は、上記の疑問を、リスクの優先順位を付けるために使われる特定のリスク評価用語およびカテゴリに言い換えます。 ただし、関係者はこの種の用語に慣れていない場合があり、リスクの優先順位付けには関与しません。 これまでの経験から、脅威、脆弱性、および対策などの情報セキュリティの専門用語の使用を避けると、討議の質が向上し、非技術系の参加者が威圧感を覚えることがなくなることがわかっています。 リスクの討議に機能的な用語を使用するもう 1 つの利点は、他の技術系関係者が特殊な用語の微妙なニュアンスで討議することが減ることです。 プロセスのこの時点では、脅威と脆弱性の矛盾する定義について討議するよりも、幅広いリスク領域について理解することがより重要です。 リスク評価進行担当者は、討議の最後まで待って、リスク定義と専門用語に関する疑問を解決しなければなりません。 ##### 多層防御に基づいて展開する リスク評価の記録担当者と進行担当者は大量の情報を収集することになります。 多層防御モデルを使用して、リスクのあらゆる要素に関する討議の展開に役立ててください。 このモデルは、構造化に貢献し、セキュリティ リスク管理チームが組織全体にわたってリスク情報を収集するのに役立ちます。 多層防御の例は、リスクの討議用テンプレートに含まれており、下の図 4.2 のようになります。 「第 6 章 : 制御の実装とプログラムの効果の測定」の「制御ソリューションを編成する」の項で、多層防御モデルをより詳細に説明しています。 ![](images/Cc163154.rmch0402(ja-jp,TechNet.10).gif) **図 4.2 多層防御モデル** 多層防御モデルを補完するもう 1 つの便利な手段は、リスク関連の質問と回答を整理する際に ISO 17799 標準を参照することです。 ISO 17799 のような包括的な標準を参照することも、法律、ポリシー、プロセス、個人、アプリケーション開発などのその他の領域をめぐるリスク討議の促進に役立ちます。 ##### 脅威および脆弱性を定義する 脅威および脆弱性に関する情報は、企業全体にわたるリスクの優先順位付けに使用する技術的な証拠を提供します。 非技術系の関係者の多くが、ビジネスに影響を与える詳細な危険を理解していないことがあるので、リスク評価進行担当者が討議を開始するための事例を提供しなければならない場合があります。 このような場合、事業主が自身の環境におけるリスクを発見して理解するために役立てるという点で、以前の調査が価値のあるものとなります。 参考までに、ISO 17799 では、脅威を組織に対する潜在的な影響と定義しています。 NIST では、脅威をシステムに危害を与える可能性のある事象または実体と定義しています。 脅威に起因する影響は、通常、機密性、完全性、および可用性などの概念を介して定義されます。 業界標準を参照することは、脅威と脆弱性を調査するときに特に便利です。 リスクの討議を促進するという目的から、脅威と脆弱性という用語を非技術系の関係者にもわかりやすい用語に置き換えることは有用です。 たとえば、資産に対してどのような事態が発生するのを回避したいのか、または、恐れているのか、などです。 ビジネスへの影響のほとんどは、業務を遂行するための資産の機密性、完全性、または可用性の点から分類できます。 関係者が組織の資産に対する脅威の意味をよく理解できない場合は、この方法を使用してください。 組織に対する脅威の一般的な例に、財務データの完全性の侵害があります。 回避しようとしている事態を明確にしたら、次に、脅威が組織で発生する経緯を特定します。 脆弱性とは、脅威が悪用する可能性のある資産または資産グループの弱点です。 簡単に言えば、脆弱性は脅威が発生するメカニズムまたは*手段*を示すものです。 その他に、NIST では脆弱性を、脅威によって悪用される可能性のあるセキュリティの手順、技術的な制御、物理的な制御、またはその他の制御の、状態または弱点 (もしくは欠落) と定義しています。 たとえば、ホストの一般的な脆弱性として、セキュリティ更新プログラムの欠落があります。 前述の脅威および脆弱性の例を組み合わせると、「更新プログラムが適用されていないホストは、これらのホスト上にある財務情報の侵害につながる」ということが言えます。 リスクの評価を実行する際、一般的にテクノロジの脆弱性に重点を置くことを忘れがちです。 重大な脆弱性のほとんどが、情報セキュリティに関する定義済みプロセスまたは説明責任の欠如が原因で発生している場合が多いことがわかっています。 データ収集プロセス中に、セキュリティの組織およびリーダーシップに関する側面を見逃さないようにしてください。 たとえば、前述のセキュリティ更新の脆弱性を掘り下げてみると、管理対象のシステムの更新を強制できないということは、これらのシステム上にある財務情報の完全性の侵害につながることになります。 責任の明確化と情報セキュリティ ポリシーの実施の強化は、多くの企業で組織的な問題となることがよくあります。 **注 :** データ収集プロセスを通して、脅威および脆弱性の一般的なグループを見分けることができます。 そのグループを追跡して、類似する制御が複数のリスクの確率を下げているかどうかを確認してください。 ##### 資産の危険度を見積る リスク評価進行担当者が資産、脅威、および脆弱性の特定まで討議を進めたら、次に、資産クラスの定義に関係なく、資産に影響を与える可能性のある損害の範囲を関係者に見積もってもらい、それを収集します。 損害の範囲は、資産の危険度として定義されます。 前述のとおり、事業主は資産の特定と資産または組織の潜在的な損失の見積もりの両方に関与します。 また、資産クラス、危険度、および脅威と脆弱性の組み合わせにより、組織への影響全体が定義されます。 第 3 章で定義したとおり、この影響は確率と結び付けられ、適格に形成されたリスク ステートメントを完成させます。 リスク評価進行担当者は、資産に関連付けられた脅威と脆弱性の組み合わせごとに、次のような潜在的危険の質的カテゴリの例を使用して、討議を開始します。 - 競争上の優位 - 法律/規制 - 運用可能性 - 市場における評価 各カテゴリについて、関係者による次の 3 つのグループ内での見積もり設定を支援してください。 - **高危険度** — 資産の重大なまたは完全な損失 - **中危険度** — 限定された、または中程度の損失 - **低危険度** — 小さい損失または損失なし この章の優先順位付けの項では、上記の危険度カテゴリをさらに詳細に説明しています。 資産を数値化するタスクと同様に、マイクロソフト セキュリティ リスク管理プロセスでは、さらに詳細な危険度レベルの定義は、リスクの優先順位付け段階まで待つことを推奨しています。 **注 :** 討議を進める中で危険度レベルの選択が関係者にとって困難なようであれば、脅威と脆弱性についてさらに詳しく説明すると、資産への損害または損失の潜在的なレベルを伝えられます。 セキュリティ侵害の一般的な例も有効な手段の 1 つです。 支援がさらに必要な場合は、この章の後半にある詳細な優先順位付けの項に定義されているとおり、より詳細なレベルの危険を紹介してください。 ##### 脅威の確率を見積もる 関係者が組織の資産に対する潜在的な影響を見積もったら、リスク評価進行担当者は影響の発生確率について関係者の意見を集めます。 これにより、リスクの討議は終了し、関係者はセキュリティ リスクを特定する思考過程を理解できるようになります。 組織に対する影響の発生確率の見積もりについて最終的な決定を下すのは、情報セキュリティ グループです。 この討議を好意、関係者を親切な建設業者とみなすことができます。 次のガイドラインを使用して、討議で特定されたそれぞれの脅威と脆弱性の確率を見積もってください。 - **高** — 現実性あり、1 年以内に 1 つ以上の影響が予測される - **中** — 可能性あり、2 ～ 3 年以内に影響があると予測される - **低** — 可能性なし、3 年以内には影響はないと予測される これには、最近発生したインシデントの見直しが含まれることがあります。 関係者がセキュリティの重要性およびリスク管理プロセスの全体像を理解するのに役立つように、必要に応じて、このようなインシデントについて討議してください。 マイクロソフト セキュリティ リスク管理プロセスでは、情報セキュリティの制御は展開に長期間かかることが多いことから、高確率のカテゴリには 1 年間の時間枠を設けています。 1 年以内の確率を選択すると、リスクへの注意が喚起され、次の予算編成サイクル内に対策の決定が奨励されます。 確率が高いと、影響の強さと結びついて、関係者とリスク管理チームの全体にリスクに関する討議を余儀なくさせます。 情報セキュリティ グループは、影響の確率を見積もるときにこの責任を自覚する必要があります。 次の作業は、特定した影響の発生確率を下げる潜在的な制御について関係者の意見を集めることです。 この討議は、ブレーンストーミング セッションとして扱い、どんな考えでも批判したり却下したりしないでください。 この討議でも主な目的は、リスクのすべての構成要素を示して、理解を促進することです。 実際の対策の選択は、「意思決定支援の実行」フェーズで行います。 特定された潜在的な各制御について、確率の討議を見直し、前述の質的カテゴリを使用して、発生の減少レベルを見積もります。 リスクの発生確率の低下という概念が、リスクを受け入れ可能なレベルで管理するための主要変数であることを関係者に指摘してください。 #### リスクの討議を促進する このセクションでは、リスクを討議するための会議の準備について概要を説明し、データ収集の討議における 5 つのタスク (組織の資産およびシナリオの決定、脅威の特定、脆弱性の特定、資産の危険度の見積もり、既存の制御および悪用の確率の特定) について説明します。 ##### 会議の準備 細かい点なのですが重要な成功要因の 1 つに、リスクの討議を行なう順序があります。 マイクロソフトの経験では、セキュリティ リスク管理チームが会議ごとにより多くの情報を提供すればするほど、会議の成果がより生産的なものになることがわかっています。 組織全体にわたるリスクの知識ベースを構築して、情報セキュリティ チームと IT チームの経験を活用することは、方法の 1 つです。 環境に関する最新の知識を得るため、まず情報セキュリティ グループと会議を開き、次に IT チームと会議を開きます。 こうすることで、セキュリティ リスク管理チームは、組織における各関係者の領域について理解を深めることができます。 また、必要に応じて、関係者とリスク評価の進行状況を共有できます。 これに続き、データ収集プロセスを完了させるために経営幹部によるリスクの討議を実施します。 経営幹部がリスク評価の方向性を早期に確認したいと思ってることがよくありますが、 これをエグゼクティブ スポンサーシップと混同しないでください。 リスクの評価プロセスの最初と全体にわたって経営幹部の参加が必要です。 各リスクの討議について、参加者一覧の作成には時間をかけてください。 似通った責任と技術知識を持つ関係者グループとの会議を開くことをお勧めします。 目標は、討議の技術レベルを出席者が抵抗なく受け入れられるようにすることです。 さまざまな関係者が組織のリスクに関する他の見解を聞くことによって恩恵を受ける一方、リスクの評価プロセスでは、割り当てられた時間内にすべての関連データを収集することに専念する必要があります。 リスクの討議をスケジュールしたら、組織における各参加者の領域を調査して、資産、脅威、脆弱性、および制御をよく理解してください。 前述のとおり、リスク評価進行担当者は、この情報により、討議を順調に生産的なペースで進めることができます。 #### 討議を促進する 討議を促進するには、形式張らない雰囲気にする必要がありますが、リスク評価進行担当者は、関連資料がすべて取り上げられるように討議を常に進行させる必要があります。 討議は議題から逸れることがよくあります。 関係者が新しい脆弱性をめぐる技術的な討議を始めたり、制御ソリューションを事前に考えている場合があるので注意してください。 リスク評価進行担当者は、会議前の調査と自身の専門知識を利用して、技術的な討議の要約を記録し、会議を先に進めます。 4 ～ 6 人の関係者による会議は、準備を十分に行っている場合、60 分以内に終わらせる必要があります。 最初の数分間を費やして、議題を説明し、リスク管理プログラム全体にわたる役割と責任を明らかにします。 関係者は、自分の役割とどのような貢献を期待されているかを明確に理解している必要があります。 また、個人的なメモを取れるように参加者全員にサンプルのリスク討議ワークシートを提供することをお勧めします。 これは、リスク評価進行担当者がリスクの討議を進めるときに参照することもできます。 さらに、早めに会場に入り、ホワイトボードにリスク テンプレートを描いて、会議中に記録できるようにすることをお勧めします。 60 分の会議の場合、会議のスケジュールは次のようになります。 - **紹介およびリスク管理の概要** – 5 分 - **役割と責任** – 5 分 - **リスクの討議** – 50 分 リスクの討議は以下のセクションに分かれます。 - **組織の資産とシナリオを決定する**  - **脅威を特定する**  - **脆弱性を特定する**  - **資産の危険度を見積もる**  - **脅威の発生確率を見積もる**  - **提案された制御の討議**  - **会議のまとめと次の段階**  会議の実際の流れは、参加者のグループ、討議されるリスクの数、およびリスク評価進行担当者の経験によって左右されます。 これを評価の各タスクに費やす時間の指針として使用してください。 また、関係者がリスクの評価プロセスに関する経験を持っている場合は、会議の前にデータ収集テンプレートを送付することを検討してください。 **注 :** この章の以降の項には、「リスクの評価」フェーズで参照されるツールの使い方を示す例が記載されています。 このサンプル企業は架空の会社で、リスク関連の内容は、完了したリスクの評価に必要なデータの一部だけを表しています。 この例の目的は、このガイドとともに提供されるツールを使用して情報を収集および分析する方法を示すことだけにあります。 マイクロソフト セキュリティ リスク管理プロセスのあらゆる側面を完全に実演すると、相当な量のデータが生じ、このガイドの範囲を超えてしまいます。 架空の会社は、Woodgrove Bank という名前の小口顧客向けリテール バンクです。 この例に関連する内容は、"Woodgrove の例" という見出しで始まります。 ##### タスク 1: 組織の資産とシナリオを特定する 最初のタスクは、リスクの評価範囲内にある組織資産の、関係者による定義を収集することです。 次に示すデータ収集テンプレートを使用して、有形資産、無形資産、または IT サービス資産を必要に応じて指定してください (SRMGTool1-Data Gathering Tool.doc もツールとしてこのガイドに付属されています)。各資産について、関係者が資産クラスの選択とテンプレートへの記録を行えるように支援します。 必要に応じて、資産の所有者も記録します。 関係者が資産クラスの選択に苦労する場合は、討議を簡単にするために資産が詳細レベルで定義されていることを確認します。 関係者がそれでも困難を感じる場合は、このタスクを飛ばして、脅威と脆弱性の討議まで待ちます。 関係者が資産およびビジネス全体への潜在的な脅威を理解すれば、資産の分類がより簡単になる場合があります。 組織の資産をめぐる討議を、いくつかの簡単な質問に制限することができます。 たとえば、その資産は企業の成功にとって重要か、その資産は純収益に実質的な影響を与えるか、などです。 答えが「はい」の場合、その資産は組織に大きな影響を与える可能性があります。 ![](images/Cc163154.rmch0403(ja-jp,TechNet.10).gif) **図 4.3 データ収集テンプレートのスナップショット (SRMGTool1)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0403_big(ja-jp,technet.10).gif) **Woodgrove の例 :** Woodgrove Bank には、利息計算システムや顧客 PII から、顧客財務データや信頼される金融機関としての評判まで、多数の価値の高い資産があります。 この例では、このガイドに付属のツールの使い方を示すために、この資産の 1 つである顧客財務データに重点を置きます。 リスクを討議する会議で資産の所有権について討議し、セキュリティ リスク管理チームは、コンシューマ サービス部門の副社長を資産の所有者として特定しました。 問題となるリスクや費用のかかる軽減戦略が見つかった場合は、この事業主が Woodgrove Bank にとって受け入れ可能なリスクを決める主要な関係者となります。 セキュリティ リスク管理チームは、コンシューマ サービスの担当者と話している間に、顧客財務データがビジネス価値の高い資産であることを確認しました。 ##### タスク 2: 脅威を特定する 一般的な用語を使用して、脅威をめぐる討議を円滑に進めます (例 : さまざまな資産へのリスクの発生を回避するために、関係者は何をしますか)。 *何が*起こるか、および*どのように*起こるかに討議を集中させます。 資産の機密性、完全性、または可用性の点から質問し、データ収集テンプレートに記録します。 **Woodgrove の例 :** 前述の資産を使用して、多数の脅威を特定できます。 説明を簡単にするために、この例では、顧客財務データの完全性が損なわれる脅威にのみ焦点を当てます。 顧客データの可用性と機密性をめぐって、その他にも脅威が存在するかもしれませんが、この例では扱いません。 ##### タスク 3: 脆弱性を特定する 特定された脅威ごとに、たとえば脅威がどのように発生するかなど、脆弱性について意見を交わします。 脆弱性を文書化するときは、関係者に特定の技術的な例を提供することを勧めてください。 それぞれの脅威には複数の脆弱性がある場合があります。 これは、予想されており、リスク管理プロセスの「意思決定支援の実行」フェーズにおいて制御を特定した後の段階で役に立ちます。 **Woodgrove の例 :** 顧客財務データの完全性が失われる脅威を検討し、セキュリティ リスク管理チームは、リスクの討議の間に収集した情報を次の 3 つの脆弱性に要約しました。 1. 信頼された従業員がソーシャル エンジニアリングや盗聴などの非技術的な攻撃方法を悪用することによる、財務アドバイザ資格情報の盗用 2. 期限切れのセキュリティ構成の使用による、ローカル エリア ネットワーク (LAN) のホストからの財務アドバイザ資格情報の盗用 3. 期限切れのセキュリティ構成が原因の、リモート、モバイル、ホストからの財務アドバイザ資格情報の盗用 このシナリオにはさらに多くの脆弱性が存在する可能性があります。 目標は、脆弱性が脅威にどのように割り当てられるかを実証することです。 また、関係者が技術用語を使用して脆弱性を明確化できないことがあるので注意してください。 セキュリティ リスク管理チームは、必要に応じて、脅威と脆弱性のステートメントを修正する必要があります。 ##### タスク 4: 資産の危険度を見積もる リスク評価進行担当者は、すべての脅威と脆弱性の組み合わせに対する危険度の見積もりに討議を進めます。 関係者に、危険度レベルを高、中、低から選択して、テンプレートに記録するように依頼します。 デジタル資産とシステムに関しては、脆弱性が管理レベルまたはルート レベルの資産の制御を可能にする場合、危険度を高に分類するとよいでしょう。 **Woodgrove の例 :** 脅威と脆弱性が特定された後、リスク評価進行担当者は、前に論議した脅威と脆弱性の組み合わせがビジネスに及ぼすおそれのある損害のレベルについて情報を収集するため、討議を進めました。 討議の後、グループは次のように判断しました。 - 信頼された従業員の悪用による完全性の侵害はビジネスに損害を与えるかもしれませんが、深刻な損害ではありません。 各財務アドバイザがアクセスできるのは自分が管理する顧客データのみなので、損害の範囲は限られます。 このため、討議の参加者は、比較的少数の資格情報の盗用は、多数の資格情報の盗用よりも損害が小さいことを認識しました。 - LAN ホストでの資格情報の盗用による完全性の侵害は、重大で、高レベルの損害を引き起こします。 これは、短期間に複数の財務アドバイザ資格情報を収集する自動化された攻撃の場合に特に当てはまります。 - モバイル ホストでの資格情報の盗用による完全性の侵害も、重大で、高レベルの損害をもたらします。 討議の参加者グループは、リモート ホストでのセキュリティ構成が LAN システムに立ち遅れていることが多いことに注目しました。 ##### タスク 5: 既存の制御と悪用の確率を特定する リスクの討議を通して、関係者の現在の制御環境に関する見方、悪用の発生確率に関する意見、および提案する制御のための推奨事項をよりよく理解します。 関係者の観点は実際の実装とは異なるかもしれませんが、情報セキュリティ グループに貴重な参考情報を提供します。 この時点で、関係者にリスク管理プログラムにおける各自の役割と責任を認識させます。 この結果はテンプレートに記述します。 **Woodgrove の例 :** 特定された脅威と脆弱性による企業への潜在的な危険度について討議した後、非技術系の関係者はあるホストが別のホストによって侵害される確率についてコメントする十分な経験を持っていませんでした。 しかし、リモート ホストまたはモバイル ホストが LAN 上と同じレベルの管理を受けないという点については同意しています。 不正な行為についての活動報告を財務アドバイザが定期的に見直す必要があるという討議が交わされました。 このフィードバックは収集されて、「意思決定支援の実行」フェーズでセキュリティ リスク管理チームによって検討されます。 ##### リスクの討議をまとめる リスクの討議の最後に、特定されたリスクを簡単にまとめて、会議を終了できるようにします。 また、関係者にリスク管理プロセスの全体とスケジュールについて知らせます。 リスクの討議で収集された情報は、関係者にリスク管理プロセスでの積極的な役割を与え、セキュリティ リスク管理チームに貴重な明察を提供します。 **Woodgrove の例 :** リスク評価進行担当者は、討議をまとめ、討議された資産、脅威、および脆弱性を強調しました。 また、より大規模なリスク管理プロセスを説明し、セキュリティ リスク管理チームが各脅威と脆弱性の確率を見積もる際にこのプロセスの情報および他の情報を取り込むという事実を、討議の参加者グループに理解させました。 #### 影響ステートメントを定義する 簡易データ収集段階の最後のタスクは、リスクの討議中に収集された、巨大化する可能性のある情報を分析することです。 この分析の結果として、資産、および脅威と脆弱性から生じる潜在的な危険度を示す一覧が作成されます。 第 3 章で定義したように、このステートメントは*影響ステートメント*と呼ばれています。 影響は、資産クラスと資産への潜在的な危険度のレベルを結び付けて決められます。 影響はより大きなリスク ステートメントの半分であることに注意してください。影響と発生確率を結び付けるとリスク ステートメントが完成します。 セキュリティ リスク管理チームは、リスクの討議で収集した情報をまとめ、以前に特定した影響を含め、さらに自らの観察に基づく影響データを取り込んで影響ステートメントを作成します。 セキュリティ リスク管理チームは、このタスクに責任がありますが、必要に応じて追加の情報を参加者に求める必要があります。 影響ステートメントには、資産、資産の分類、多層防御、脅威の説明、脆弱性の説明、および危険度が含まれています。 データ収集テンプレートで収集した情報を使用して、あらゆる討議を促進させる影響ステートメントを定義します。 図 4.4 は、影響固有のデータを収集する概要レベル リスク テンプレートに適用可能な列見出しを示しています。 ![](images/Cc163154.rmch0404(ja-jp,TechNet.10).gif) **図 4.4 概要レベル ワークシート : 資産列と脅威列 (SRMGTool2)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0404_big(ja-jp,technet.10).gif) **Woodgrove の例 :** リスクの討議の間に収集されたサンプル情報は、影響ステートメントを作成することによって整理できます。 セキュリティ リスク管理チームは、影響ステートメントを、たとえば、「リモートで管理されたホストの資格情報の盗用によって価値の高い顧客データが損なわれる可能性がある」といった文章で記述する場合があります。この方法は正確ですが、文章を書くことは、記述、理解、およびデータの整理 (リスクのソートまたはクエリ) の欠如という点で整合性がなく、大量のリスクを見積もることはできません。 より効果的な方法は、影響データを次のような概要レベルの表に記入することです。 ![](images/Cc163154.rmch0405(ja-jp,TechNet.10).gif) **図 4.5 Woodgrove の例 : データ収集プロセス中に収集された情報 (SRMGTool2)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0405_big(ja-jp,technet.10).gif) **注 :** 次の項「リスクの優先順位付け」では、概要レベル リスク プロセスで使用される影響度の選択と文書化についてさらに説明します。 #### データ収集サマリー セキュリティ リスク管理チームは、データ収集の討議で収集された情報を個別の影響ステートメントにまとめることにより、「リスクの評価」フェーズの簡易データ収集手順のタスクを完了しました。 次の項「リスクの優先順位付け」では、リスクの優先順位付けにかかわるタスクを詳しく説明します。 セキュリティ リスク管理チームは、優先順位付けを行っている間、各影響ステートメントの確率を見積もる必要があります。 その後、影響ステートメントと発生確率の見積もりを結び付けます。 この結果、優先順位付きのリスクの包括的な一覧が作成され、「リスクの評価」フェーズが完了します。 リスクの分析時に、別のリスクの発生に依存するリスクが見つかる場合があります。 たとえば、ビジネス影響の低い資産に権限の昇格が発生すると、ビジネス影響の高い資産も危険にさらされることがあります。 これは有効な課題ですが、リスクの依存性は、収集、追跡、および管理するデータを極端に増大させます。 マイクロソフト セキュリティ リスク管理プロセスでは、依存性を可能な限り明らかにすることを推奨していますが、すべてのリスクの依存性を積極的に管理することは、通常、費用対効果に優れていません。 総体的な目標は、ビジネスに対して優先順位が最も高いリスクを特定して管理することです。 [](#mainsection)[ページのトップへ](#mainsection) ### リスクの優先順位付け 前のセクションで説明したとおり、簡易データ収集手順では、組織の資産と潜在的な影響を特定する影響ステートメントの一覧を作成するためのタスクを定義します。 このセクションでは、「リスクの評価」フェーズの次の手順であるリスクの優先順位付けについて説明します。 優先順位付けプロセスは、影響ステートメントに確率の要素を追加します。 適切に形成されたリスク ステートメントには、組織への*影響*と影響発生の*確率*が必要です。 優先順位付けプロセスは、"どのリスクが組織に最も重要かを定義する" 最後の手順と言えます。最終的に得られる結果はリスクの優先順位付き一覧で、「第 5 章 : 意思決定支援の実行」で説明する意思決定支援プロセスへの情報として使用されます。 情報セキュリティ グループは、優先順位付けプロセスの唯一の担当部署です。 このチームは技術系および非技術系の関係者と相談する場合がありますが、組織への潜在的な影響の確率を決定する責任はこのチームにあります。 マイクロソフト セキュリティ リスク管理プロセスを適用することにより、確率のレベルがリスクの認識レベルを組織の最上位レベルまで引き上げることがあり、その一方で、討議しなくてもリスクを受け入れられるほど認識レベルを低下させることもできます。 リスクの確率を見積もるには、セキュリティ リスク管理チームが優先される脅威と脆弱性の組み合わせを個々に完全に評価するために、十分な時間を費やす必要があります。 個々の組み合わせは現在の制御に対して評価され、組織への影響の確率に作用するこれらの制御の効果が検討されます。 このプロセスは、大きな組織では膨大なものとなる場合があり、正式なリスク管理プログラムへの投資の最初の決定を難しくします。 リスクの優先順位付けに費やす時間を減らすために、プロセスを概要レベル プロセスと詳細レベル プロセスの 2 つに分割することを検討してください。 概要レベル プロセスでは、病院の救急治療室で最初に治療の必要な患者を確実に助けるトリアージ手順のように、リスクの優先順位付き一覧が簡単に作成されます。 ただし、このプロセスには、リスク間の高レベルの比較のみが含まれた一覧が作成されるという短所があります。 各リスクが "高" に分類されている長い概要レベル一覧は、セキュリティ リスク管理チームにとって十分なガイダンスとなることはなく、チームに優先順位付けの軽減戦略を提供することはできません。 それにもかかわらず、このプロセスにより、セキュリティ リスク管理チームは、高または中レベルのリスクを特定するためにリスクの優先順位をすばやく設定でき、最も重要とみなされるリスクだけに努力を集中させることができます。 詳細レベル プロセスでは、各リスクをより詳細により簡単に区別できる一覧が作成されます。 詳細なリスクを示すことにより、大量のリスクの順位付けが可能になり、またリスクの経済的な影響の可能性をより詳細に示すことができます。 この量的な要素により、次の章で詳しく説明する意思決定支援プロセスでの制御の討議にかかるコストが軽減されます。 組織によっては、概要レベル リスク一覧をまったく作成しない場合もあります。 一見、この戦略により経営陣の時間が節約されるように思われますが、そうではありません。 詳細レベルの一覧のリスクの数を最小にすると、最終的にリスク評価のプロセスがより効率的になります。 マイクロソフト セキュリティ リスク管理プロセスの主な目標は、リスク分析の精度の向上とリスク計算に必要な労力とのバランスを取ることにより、リスクの評価プロセスを簡略化にすることにあります。 同時に、関係者に組織へのリスクを明確に理解してもらうため、関連するロジックの明確化を推し進め、それを維持しようと努力しています。 リスクの中には、概要一覧と詳細一覧で優先順位が同じものがありますが、この優先順位からも、リスクが組織にとって重要かどうか、意思決定支援プロセスに進むべきかどうかを判断するのに十分な詳細情報を得られます。 **注 :** 「リスクの評価」フェーズの最終目標は、組織にとって最も重要なリスクを特定することです。 「意思決定支援の実行」フェーズの目標は、これらのリスクを解決するために何をすべきかを決めることです。 チームは、この段階で、関係者がさまざまなリスクの重要性を討議している間、行き詰まることがよくあります。 遅延の発生を最小限に抑えるために、組織に応じて、次のタスクを適用してください。 1. 優先順位付けプロセスを開始する前に、組織の高レベルおよび中レベルのリスクを非技術系の用語で定義します。 2. 中レベルと高レベルの境界にあるリスクに注目します。 3. リスクが重要かどうかを特定する前は、リスクの対処法に関する討議を避けます。 事前にソリューションを考えていて、プロジェクトを正当化するためのリスクを見つけようとしている関係者に注意してください。 この項の残りの部分では、概要および詳細レベルのリスクの優先順位を設定するための成功要因とタスクについて説明します。 次のタスクおよび図 4.6 は、この項の概要と、リスクの優先順位付けプロセスを通した主要な成果物を示しています。 #### 主要なタスクと成果物 - **タスク 1 —** 組織への影響の発生確率を見積もる概要レベル一覧を、広範な分類を使用して作成します。   - **作成情報 —** 組織に対するリスクの優先順位をすばやく特定する概要レベル一覧 - **タスク 2 —** 概要レベルの一覧を関係者と見直して、優先順位の高いリスクに関する合意の形成を開始し、詳細レベル一覧に載せるリスクを選択します。 - **タスク 3** — 現在のビジネス環境でリスクの詳細な属性を調べて、詳細レベル一覧を構築します。 これには、それぞれのリスクの量的な見積もりを決めるガイダンスが含まれます。 - **作成情報** — 組織に対する上位のリスクの詳細な一覧を提供する詳細レベル一覧 ![](images/Cc163154.rmch0406(ja-jp,TechNet.10).gif) **図 4.6 リスクの優先順位付けタスク** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0406_big(ja-jp,technet.10).gif) **注 :** 詳細レベルのリスク情報は、第 5 章の意思決定支援プロセスで、関係者によって見直されます。 #### 成功のために準備する 組織に対するリスクの優先順位付けは、簡単ではありません。 セキュリティ リスク管理チームは、いつどのように組織に影響がおよぶかを予測し、これらの予測を関係者に正当化する必要があります。 多くのチームは一般的に、確率決定に関連するタスクを隠し、計算を利用して、事業主がよりすばやく反応すると考えられるパーセンテージやその他の収益額で確率を表しがちです。 しかし、マイクロソフト セキュリティ リスク管理プロセスの開発時の経験では、優先順位付けプロセスのロジックが明確な場合、セキュリティ リスク管理チームの分析が関係者により受け入れやすくなることが証明されています。 このプロセスでは、プロセス全体を通して、関係者の理解に重点が置かれます。 誤解を最小限に抑え、迅速に合意に達するには、優先順位付けのロジックをできる限り単純化する必要があります。 マイクロソフトの IT 部門やその他の企業でリスクの評価を実施した経験から、次の方法もセキュリティ リスク管理チームの優先順位付けプロセスに役立つことがわかっています。 - データ収集プロセス中にリスクを分析します。 リスクの優先順位付けには時間がかかるため、意見の分かれるリスクを予測し、優先順位付けプロセスをできるだけ早く開始するようにします。 セキュリティ リスク管理チームは、優先順位付けプロセスの単独の担当部署であるため、このような近道が可能です。 - 確率を見積もるための信頼を構築する調査を実行します。 過去の監査レポートを使用し、業界の傾向および社内のセキュリティ インシデントを適宜検討します。 必要に応じて、関係者に問い合わせ、その環境にある現在の制御と特定のリスクの認識について学びます。 - プロジェクトに十分な時間を割り当てて、調査を実施し、現在の制御環境の効果と機能の分析を実行します。 - 関係者にセキュリティ リスク管理チームが確率の決定に責任を持つことを通知します。 エグゼクティブ スポンサーもこの役割を認めて、セキュリティ リスク管理チームの分析をサポートする必要があります。 - ビジネス用語でリスクを伝えます。 優先順位付け分析では、懸念事項や専門用語に関連する用語の使用を避けます。 セキュリティ リスク管理チームは、組織に理解される用語でリスクを伝え、危険の程度を誇張しないようにします。 - 新しいリスクと以前のリスクを調整します。 概要レベル一覧の作成時に、以前の評価からリスクを組み込みます。 これにより、セキュリティ リスク管理チームは、複数の評価にわたってリスクを追跡し、必要に応じて、以前のリスク要素を更新する機会を提供します。 たとえば、以前のリスクが対策コストの高さが原因で軽減されなかった場合、リスクの発生確率を再検討して、対策ソリューションまたはコストへの変更を見直します。 #### セキュリティ リスクの優先順位を付ける 次の項では、概要および詳細レベルのリスク一覧の作成プロセスを説明します。 ツール セクションにある各プロセスに対応したテンプレートを印刷するとよいでしょう。 ##### 概要レベルのリスクに優先順位を付ける 概要レベル一覧では、データ収集プロセス中に作成される影響ステートメントを使用します。 影響ステートメントは、概要表示の 2 つある情報のうちの 1 つです。 もう 1 つの情報は、セキュリティ リスク管理チームによって決められた確率の見積もりです。 次の 3 つのタスクは、概要レベルの優先順位付けプロセスの概要を示しています。 - **タスク 1** — データ収集プロセスで収集された影響ステートメントから、影響値を決めます。 - **タスク 2** — 概要レベル一覧の影響の確率を見積もります。 - **タスク 3** — 各リスク ステートメントの影響値と確率値を結び付け、概要レベルの一覧を完成します。 ###### タスク 1: 影響レベルの決定 データ収集プロセスで収集された資産クラスと資産の危険度情報を 1 つの値にまとめて、影響を判断します。 影響は、資産クラスと資産への危険度の範囲を組み合わせたものです。 次の図を使用して、各影響ステートメントの影響レベルを選択してください。 ![](images/Cc163154.rmch0407(ja-jp,TechNet.10).gif) **図 4.7 リスク分析ワークシート : 資産クラスと危険度 (SRMGTool2)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0407_big(ja-jp,technet.10).gif) **Woodgrove の例 :** Woodgrove には、3 つの影響ステートメントがありました。 次の一覧は、資産クラスと危険度の組み合わせることによって、これらのステートメントを要約しています。 1. 信頼された従業員による盗用の影響 : HBI 資産クラスおよび低い危険度。 上図を使用すると、"中の影響" になります。 2. LAN ホストの侵害の影響 : HBI 資産クラスと高い危険度から、"高い影響" となります。 3. リモート ホスト侵害の影響 : HBI 資産クラスと高い危険度から、"高い影響" となります。 ###### タスク 2: 概要レベルの確率の見積もり データ収集プロセスで説明したのと同じ確率カテゴリを使用します。 この確率カテゴリには、次のものが含まれています。 - **高** — 現実性あり、1 年以内に 1 つ以上の影響が予測される - **中** — 可能性あり、2 ～ 3 年以内に少なくとも 1 つの影響があると予測される - **低** — 可能性なし、3 年以内には影響はないと予測される **Woodgrove の例 :** 概要レベルのリスクの優先順位付けは、セキュリティ リスク管理チームのリスク確率に関する見積もりの最初の公式なドキュメントです。 セキュリティ リスク管理チームは、過去のインシデントを引用したり、現在の制御の効果を参照するなど、見積もりを正当化する証拠または事例を提供する準備をしなければなりません。 次の一覧は、Woodgrove の例の確率レベルをまとめたものです。 1. 信頼された従業員による盗用の確率 : 低。 Woodgrove National Bank は信頼できる従業員を雇用していることを誇りにしています。 経営陣は、各従業員の素性を調査してこの信用を確認し、財務アドバイザの活動をランダムに監視しています。 過去に従業員の不正によるインシデントが見つかったことはありません。 2. LAN ホストの侵害の確率 : 中。 IT 部門は最近、過去数年間の一貫性のなさから、LAN 上の更新プログラムと構成プロセスを形式化しました。 銀行の分散した性質のせいで、システムは不適合と判断される場合がありますが、最近数ヶ月間ではインシデントが報告されていません。 3. リモート ホストの侵害の確率 : 高。 リモート ホストは長期間にわたり不適合となることがよくあります。 リモート ホストでは、ウイルスやワームの感染に関する最近のインシデントも確認されています。 ###### タスク 3: 概要レベルのリスク一覧の完成 セキュリティ リスク管理チームが確率を評価したら、次の数字を使用して、概要レベルのリスク ランクを選択します。 ![](images/Cc163154.rmch0408(ja-jp,TechNet.10).gif) **図 4.8 リスク分析ワークシート : 影響と確率 (SRMGTool2)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0408_big(ja-jp,technet.10).gif) **注 :** 組織の必要に応じて、中程度の影響と中程度の確率が結び付いた場合のリスク レベルを高いリスクと定義できます。 リスク評価プロセスとは関係なくリスク レベルを定義することにより、この決定に必要なガイダンスが提供されます。 SMRG は、包括的で一貫したリスク管理プログラムの開発を容易にするツールです。 すべての組織は、その組織固有の高リスクの意味を定義する必要があります。 **Woodgrove の例 :** 影響と確率を結び付けることにより、次のようなリスク評価につながります。 1. 信頼された従業員による盗用のリスク : 低 (影響 "中"、確率 "低") 2. LAN ホストの侵害リスク : 高 (影響 "高"、確率 "中") 3. リモート ホストの侵害 : 高 (影響 "高"、確率 "高") 確認用として、次の図は概要レベル一覧のすべての列を示しています。この一覧は、SRMGTool2-Summary Risk Level.xls にも含まれています。 ![](images/Cc163154.rmch0409(ja-jp,TechNet.10).gif) **図 4.9 リスク分析ワークシート : 概要レベル一覧 (SRMGTool2)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0409_big(ja-jp,technet.10).gif) 組織の必要に応じて、たとえば以前の評価で特定したリスクを区別するために "特定日" の列を追加するなど、サポート情報を含む列を追加してください。 リスクの説明を更新する列や、以前の評価以降に発生したリスクへの変更を強調するための列を追加することもできます。 個々のニーズに合うようにマイクロソフト セキュリティ リスク管理プロセスを調整する必要があります。 **Woodgrove の例 :** 下の図は、Woodgrove Bank の概要レベルのリスク一覧を完成させたものです。 適切に形成されたリスク ステートメントの要素を完了するために、\[確率\] 列と \[概要レベルのリスク\] 列が影響ステートメント情報に追加されました。 ![](images/Cc163154.rmch0410(ja-jp,TechNet.10).gif) **図 4.10 Woodgrove Bank の概要レベルのリスク一覧の例 (SRMGTool2)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0410_big(ja-jp,technet.10).gif) ###### 関係者とのレビュー 優先順位付けプロセスの次のタスクは、関係者との概要結果のレビューです。 目標は、関係者のリスク評価プロセスに関する情報を更新し、詳細レベルの分析を実行するリスクを選択するのに役立つ情報を関係者に要請することです。 詳細レベルの優先順位付けプロセスに含めるリスクを選択するときには、次の基準を使用します。 - **高レベルのリスク** — 高と評価されたリスクはすべて、詳細な一覧に含める必要があります。 高リスクは、意思決定支援プロセス後に解決する必要があります。たとえば、リスクを容認するか、対策ソリューションを開発します。 - **境界線のリスク** — 解決する必要のある中程度のリスク用に、詳細な優先順位分析を作成します。 一部の組織では、中程度のリスクが詳細な一覧に含まれる場合もあります。 - **意見の分かれるリスク** — リスクが新しく、よく理解されていない場合、または関係者によって見解が異なる場合は、詳細な分析を作成して、関係者がリスクをより正確に理解できるようにします。 **Woodgrove の例 :** "信頼された従業員による盗用" リスクは、概要レベルのリスク一覧では低と評価されることに注意してください。 この時点では、このリスクは関係者全員に正しく理解されています。 Woodgrove の例では、このリスクは、詳細レベルのリスク優先順位付け手順に分類する必要のないリスクの例として扱われます。 Woodgrove の例の残りの部分では、LAN およびリモートのホスト侵害リスクだけに優先順位が付けられます。 ##### 詳細レベルのリスクに優先順位を付ける 詳細レベルのリスク一覧の作成は、リスク評価プロセスの最後のタスクです。 詳細な一覧は、会社にとって最も重要なリスクの論理的根拠を組織に理解させることができるため、最も重要なタスクの 1 つでもあります。 リスク評価プロセスを完了した後に行動を開始するには、正しく文書化されたリスクを関係者に通知するだけで十分な場合があります。 正式なリスク管理プログラムを採用していない組織には、マイクロソフト セキュリティ リスク管理プロセスが啓発的な経験となる場合があります。 **注 :** リスクが関係者全員に正しく理解されている場合は、概要レベルの詳細だけで適切な対策ソリューションを決めるのに十分です。 詳細なリスク一覧では、概要レベルの一覧で使用する多くの情報を利用しますが、詳細表示では、セキュリティ リスク管理チームが影響と確率の説明をより詳細にする必要もあります。 概要レベルの各リスクについて、脅威と脆弱性の各組み合わせがリスクを通して一意であることを確認します。 概要レベルのリスクについて、環境内の特定の制御と関連付けるのに十分な情報が記述されていないことがあります。この場合には、発生の確率を正確に見積もることができない可能性があります。 たとえば、次の概要レベルのリスク ステートメントで脅威の説明を改良して、次の 2 つの別々のリスクを記述することができます。 **概要レベルのリスク ステートメント :** 高価値のサーバーが、更新プログラムを適用していない構成が原因で、1 年以内に中程度の影響を受ける可能性があります。 **詳細レベルのステートメント 1:** 高価値のサーバーが、更新プログラムを適用していない構成が原因のワームの伝搬により、1 年以内に *3 日間使用できなくなる*可能性があります。 **詳細レベルのステートメント 2:** 高価値のサーバーが、更新プログラムを適用していない構成が原因のワームの伝搬により、1年以内に*侵害を受けて、データの完全性に影響が出る*可能性があります。 **注 :** データ収集プロセスの前に、詳細なリスク分析に慣れておくことをお勧めします。 これにより、セキュリティ リスク管理チームは、関係者との最初のデータ収集討議で特定の質問をし、フォローアップ会議の必要性を最小限に抑えることができます。 詳細レベルのリスク一覧には、現在の制御環境の効果に関する特定のステートメントも必要です。 セキュリティ リスク管理チームは、組織に影響を及ぼす脅威と脆弱性を詳細に理解したら、現在の制御の詳細を理解する作業を開始できます。 現在の制御環境により、組織への潜在的なリスクの確率が決まります。 制御環境が十分な場合、組織へのリスクの確率は低くなります。 制御環境が不十分な場合、リスクの容認や、対策ソリューションの開発などのリスク戦略を定義する必要があります。 最終のリスク レベルに関係なくリスクを追跡することをお勧めします。 たとえば、リスクが容認可能とみなされる場合、この情報を将来の評価のために保存します。 詳細レベルのリスク一覧の最後の要素は、それぞれのリスクを定量化できる貨幣価値で見積もることです。 関係者間で合意を形成するために時間が必要なので、詳細レベルの一覧で作業が開始されるまで、リスクに対して貨幣価値を選択することはありません。 セキュリティ リスク管理チームは関係者に再度問い合わせて、追加のデータを収集する必要があります。 次の 4 つのタスクは、詳細レベルのリスク一覧を構築するプロセスの概要です。 ツール セクションにある "SRMGTool3-Detailed Level Risk Prioritization.xls." というテンプレートを印刷するとよいでしょう。作成される情報は、現在の組織に影響するリスクの詳細な一覧です。 数量の見積もりは、詳細なリスク値によって決まります。これについては、次の項で説明します。 - **タスク 1** — 影響と危険度を決定します。 - **タスク 2** — 現在の制御を特定します。 - **タスク 3** — 影響の確率を決定します。 - **タスク 4** — 詳細リスク レベルを決定します。 ###### タスク 1: 影響と危険度の決定 まず、概要テーブルから詳細テンプレートに資産を書き込みます。 次に資産の危険度を選択します。 詳細テンプレートの危険度の評価は、概要レベルに比べて精度が追加されており、 1 ～ 5 の値で構成されます。 危険度の評価は、資産への損害の範囲を定義するものです。 次のテンプレートを自分の組織に該当する危険度を特定する指針として使用します。 危険度を示す各値は資産への影響レベルに影響を与えるため、すべての値の中で最も高い値は、表に必要な数値を入力した後に挿入してください。 1 番目の危険度の数値は、ビジネス資産の機密性または完全性の侵害の影響の範囲を測定するのに役立ちます。 2 番目の数値は、資産の可用性への影響の測定に役立ちます。 ![](images/Cc163154.rmch0411(ja-jp,TechNet.10).gif) **図 4.11 リスク分析ワークシート : 機密性または完全性の危険度 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0411_big(ja-jp,technet.10).gif) 潜在的な影響による機密性と完全性の損害の範囲を検討した後、次の数値を使用して、資産の可用性の欠落による影響レベルを決めます。 これら 2 つの表から、危険度レベルとして最も高い値を選択してください。 ![](images/Cc163154.rmch0412(ja-jp,TechNet.10).gif) **図 4.12 リスク分析ワークシート : 可用性の危険度 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0412_big(ja-jp,technet.10).gif) この図を潜在的な各影響の危険度を収集するための指針として使用してください。 データ収集の討議で、潜在的な危険度レベルについて十分な詳細情報が得られなかった場合は、特定の資産所有者とともにこの情報を見直す必要があります。 データ収集セクションで説明したように、リスク討議中に必要に応じて上記の危険度の説明を参照してください。 **Woodgrove の例 :** 次の一覧に、残り 2 つのリスクの危険度をまとめました。 1. LAN ホスト侵害の危険度 : 4。 ビジネスへの影響は深刻で外部から目に見える可能性がありますが、すべての顧客財務データに深刻な損害を与えるものではありません。 このため、4 の評価が選択されています。 2. リモート ホスト侵害の危険度 : 4 (上記と同じ)。 危険度を特定したら、SRMGTool3-Detailed Risk Level Prioritization.xls の該当する列を埋めて、影響度を特定できます。 詳細レベルのリスク プロセスでは、影響は影響クラス値と危険度から生じます。 それぞれの影響度には、資産への損害の範囲を反映したパーセンテージが割り当てられています。 このパーセンテージを危険要因といいます。 マイクロソフト セキュリティ リスク管理プロセスでは、危険度 100 % を 20 % ごとに区切った均等目盛の使用を推奨していますが、組織に応じて調整することもできます。 各影響度は、高、中、または低の質的値と関連付けられています。 この分類は、影響レベルの通知、および詳細なリスク計算を通したリスク要素の追跡に役に立ちます。 次の図も各影響クラスの潜在的な影響度を示しています。参考にしてください。 ![](images/Cc163154.rmch0413(ja-jp,TechNet.10).gif) **図 4.13 リスク分析ワークシート : 影響値の特定 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0413_big(ja-jp,technet.10).gif) **Woodgrove の例 :** 下の図は Woodgrove の例を使用して、影響クラスの値、危険度、および全体的な影響度を決定する方法を示しています。 ![](images/Cc163154.rmch0414(ja-jp,TechNet.10).gif) **図 4.14 影響クラス、危険度評価、および影響度を示す Woodgrove の例 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0414_big(ja-jp,technet.10).gif) ###### タスク 2: 現在の制御の特定 SRMGTool3-Detailed Risk Level Prioritization.xls では、影響ステートメントで定義された脅威と脆弱性の確率を軽減している組織内の現在の制御について説明しています。 制御の効果は、詳細な確率計算でも評価されますが、適用できる制御を文書化すると、リスク要素を通知するときに役立ちます。 また、管理、運用、または技術の制御グループなど、周知のカテゴリで制御の説明を整理することも有用です。この情報は、第 5 章で説明する意思決定支援プロセスでも役立ちます。 **Woodgrove の例 :** "LAN ホストの侵害リスク" に対する主要な制御の一覧の例を次に示します。制御の説明について詳しくは、SRMGTool3-Detailed Risk Level Prioritization.xls を参照してください。 制御の説明は危険度の評価を正当化するためにも使用できます。 - 財務アドバイザは、自身が所有するアカウントにだけアクセスできます。危険度は 100% 未満です。 - 更新プログラムやホストの更新については、すべてのユーザーに電子メールで事前に通知されます。 - ウイルス対策およびセキュリティ更新のステータスは、数時間ごとに測定され、適用されています。 この制御により、LAN ホストが攻撃に対して脆弱である期間が短縮されます。 ###### タスク 3: 影響の確率の決定 確率の評価は、次の 2 つの値で構成されます。 第 1 の値は、脆弱性と悪用の可能性の属性に基づいた、環境に存在する脆弱性の確率を確定します。 第 2 の値は、現在の制御の効果に基づいた、既存の脆弱性の確率を確定します。 両方とも、1 ～ 5 の範囲で表されます。 次の図を指針として、組織への各影響について確率を決定してください。 その後、確率と影響度を掛け合わせて、相対的なリスク評価を特定します。 **注 :** 図 4.15 および 4.17 は、マイクロソフトの IT 部門が自社環境内で発生するリスクの確率を理解するために使用したものです。 各自の組織に適合するように、内容を調整してください。 情報セキュリティ グループは、優先順位付けプロセスを所有し、必要に応じて、優先順位付け属性を調節する必要があります。 たとえば、評価範囲がアプリケーション開発に重点を置いている場合、数値を企業のインフラストラクチャの脆弱性ではなく、アプリケーション固有の脆弱性に重点を置くように変更します。 目標は、自分の環境内のリスクを評価するための基準を矛盾なく収集することにあります。 次の数字には、これらの脆弱性の属性が含まれています。 - **攻撃者数** — 悪用の確率は、通常、攻撃者の数が規模および技術スキル レベルの点で増加するにつれて高くなります。 - **リモート アクセスとローカル アクセス** — 確率は、通常、脆弱性をリモートで悪用できると増加します。 - **悪用の認知度** — この確率は、通常、悪用が認知されていて、公開されている場合に増加します。 - **悪用の自動化** — この確率は、通常、悪用が大規模な環境での脆弱性を自動的に見つけるようにプログラムできる場合に増加します。 悪用の確率の見積もりは、主観的な性質を帯びることに注意してください。 上記の属性を指針として、確率の見積もりを決めて正当化してください。 セキュリティ リスク管理チームは、予測を選択して正当化する際に、専門知識に従って推進させる必要があります。 ![](images/Cc163154.rmch0415(ja-jp,TechNet.10).gif) **図 4.15 リスク分析ワークシート : 脆弱性の評価 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0415_big(ja-jp,technet.10).gif) 次の図で適切な評価を選択してください。 ![](images/Cc163154.rmch0416(ja-jp,TechNet.10).gif) **図 4.16 リスク分析ワークシート : 確率の評価 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0416_big(ja-jp,technet.10).gif) **Woodgrove の例 :** LAN ホストおよびリモート ホストに対して、近い将来、Woodgrove の LAN 環境の内外で、高カテゴリのあらゆる脆弱性属性が発生する可能性があります。 このため、脆弱性の値は両方のリスクに対して 5 になります。 次の図は、現在の制御の効果を評価したものです。 この値は、主観的な性質を持ち、制御環境を理解するためセキュリティ リスク管理チームの経験に依存します。 それぞれの質問に答え、値を合計して、最終的な制御の評価を決定します。 値が低い場合は、制御が効果的で、悪用発生の確率が低減されていることを意味します。 ![](images/Cc163154.rmch0417(ja-jp,TechNet.10).gif) **図 4.17 リスク分析ワークシート : 現在の制御効果の評価 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0417_big(ja-jp,technet.10).gif) **Woodgrove の例 :** 制御効果の値の使用方法を示すために、次の表には LAN ホストの侵害リスクの値だけをまとめます。詳細な例については、SRMGTool3-Detailed Risk Level Prioritization.xls を参照してください。 **表 4.2. Woodgrove の例 — 制御効果の値**
制御効果の質問 値 説明
責任が有効に定義され、適用されているか? 0 (はい) ポリシー作成とホスト コンプライアンスの責任は正しく定義されています。
認識が有効に通知され、追跡されているか? 0 (はい) ユーザーに通知が定期的に送られ、全般的な認識キャンペーンが実施されています。
プロセスが有効に定義され、実施されているか? 0 (はい) コンプライアンスの測定と適用について文書化され、順守されています。
既存の技術または制御が脅威を有効に削減しているか? 1 (いいえ) 既存の制御は脆弱で、更新プログラムが適用されるまで、まだ長時間かかります。
現在の監査は、悪用の検出または欠陥の制御を行うのに十分か? 0 (はい) 測定とコンプライアンスの監査は、最新のツールで効果的に行なわれています。
すべての制御属性の合計 : 1  
次に、脆弱性の図 (図 4.16) の値を現在の制御の図 (図 4.17) の値に追加して、詳細レベルのテンプレートに挿入します。 このテンプレートは次の図のようになります。 ![](images/Cc163154.rmch0418(ja-jp,TechNet.10).gif) **図 4.18 リスク分析ワークシート : 制御による確率評価 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0418_big(ja-jp,technet.10).gif) **Woodgrove の例 :** LAN ホストの例の合計確率は 6 (脆弱性の値 5 に制御の効果の値 1 を加えたもの) になります。 ###### タスク 4 — 詳細リスク レベルの決定 下の図は、特定された各リスクのリスク レベルを決定する、詳細レベルの概要を示しています。 詳細レベルでのリスクの評価は複雑に見えるかもしれませんが、リスク評価の各タスクの背景にあるロジックは、以前の図を使って参照できます。 リスク ステートメント内の各タスクを追跡するこの機能により、リスク評価プロセスの基礎となる詳細情報を関係者が理解するために役立つ重要な価値観が提供されます。 ![](images/Cc163154.rmch0419(ja-jp,TechNet.10).gif) **図 4.19 リスク分析ワークシート : 詳細リスク レベルの確立 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0419_big(ja-jp,technet.10).gif) **Woodgrove の例 :** 次の図は、Woodgrove Bank の詳細リスク一覧の例を示しています。 このデータは、SRMGTool3 にもあります。 ![](images/Cc163154.rmch0420(ja-jp,TechNet.10).gif) **図 4.20 Woodgrove Bank の詳細リスク一覧の例 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0420_big(ja-jp,technet.10).gif) 上の図はリスク評価とそのデータ要素の内容を表示しています。 上記のとおり、リスク評価として、影響度 (評価値 1～10) と確率 (値範囲 0 ～10) より、 0 ～ 100 の値が生じます。 概要レベルのリスク一覧で使用されるのと同じロジックを適用することにより、詳細リスク レベルも高、中、低の質的用語で伝達できます。 たとえば、影響度が中で、確率が高の場合、リスク評価は高になります。 ただし、詳細レベルの一覧は、次の図に示すように、リスク レベルごとに追加の特異性を示します。 ![](images/Cc163154.rmch0421(ja-jp,TechNet.10).gif) **図 4.21 リスク分析ワークシート : 簡易定性評価の確立 (SRMGTool3)** [拡大表示する](https://technet.microsoft.com/ja-jp/cc163154.rmch0421_big(ja-jp,technet.10).gif) 詳細リスク レベルを指針としてのみ使用します。 第 3 章で説明したとおり、セキュリティ リスク管理チームは、高、中、低の各リスクの意味を書面で組織に伝える必要があります。 マイクロソフト セキュリティ リスク管理プロセスは、組織全体にわたってリスクを一貫した反復可能な方法で特定して管理する、単なるツールです。 #### リスクを定量化する 第 2 章で説明したように、マイクロソフト セキュリティ リスク管理プロセスは、最初に定性的な手法を採用して、リスクをタイムリーで効率的な方法で特定して優先順位を付けます。 ところが、最適のリスク軽減戦略を選択するときには、リスクの潜在的な費用の見積もりも重要な検討事項の 1 つです。 このため、優先順位の高いリスクや意見の分かれるリスクの場合、このプロセスは、定量的見積もりを決定するガイダンスも提供します。 費用見積もりで合意に達するには膨大な時間と努力が必要なため、リスクを定量化するタスクは、詳細レベルのリスク プロセスの後になります。 プロセスの初期にリスクを定量化する場合、低いリスクの定量化にかなりの時間を費やすことがあります。 費用見積もりはリスク軽減戦略の多様なコストを比較する際に確かに便利なのですが、無形資産の評価の主観的な性質から、リスクを定量化する的確なアルゴリズムは存在しません。 正確な費用損失の見積もりを実施すると、関係者間に意見の不一致が生じ、実質的にはリスク評価が遅延します。 セキュリティ リスク管理チームは、定量的見積もりがリスクの優先順位または潜在的なコストを決定する多数の値の 1 つでしかないことを示す期待値を設定する必要があります。 定性モデルを使用して、最初にリスクに優先順位を付ける 1 つの利点は、定量的アルゴリズムを矛盾なく適用するのに役立つ、定性的説明を利用できることです。 たとえば、次で説明する定量的な手法では、この章の簡易データ収集のセクションで関係者によって文書化された、簡易リスク討議で特定済みの資産クラスと危険度を使用します。 定性的な手法と同様に、定量的方法の最初のタスクでは合計資産価値を決定します。 2 番目のタスクでは、資産への損傷の範囲を決め、発生の確率を見積もります。 定量的見積もりの主観性を抑えるために、マイクロソフト セキュリティ リスク管理プロセスでは、資産クラスを使用して*合計資産価値*を決定し、危険要因を使用して資産への損傷の*パーセンテージ*を決定することをお勧めします。 この手法では、定量的な結果情報を 3 つの資産クラスと 5 つの危険要因、または 15 の潜在的な定量的資産価値に制限しています。 ただし、確率の見積もり値は制限されていません。 各自の組織に合わせ、確率を時間範囲の用語で伝えることも、リスクのコストを年間で計算することもできます。 目標は、定性的な手法で相対的評価を選択する容易さと、定量的な手法で金銭的評価および確率の見積もりを行う困難さのバランスをとることです。 次の 5 つのタスクを使用して、定量値を決定します。 - **タスク 1** — 金銭的価値を組織の各資産クラスに割り当てます。 - **タスク 2** — 各リスクの資産価値を入力します。 - **タスク 3** — 個別予想被害額 (SLE) を算出します。 - **タスク 4** — 年間発生率 (ARO) を決定します。 - **タスク 5** —  年間予想被害額 (ALE) を決定します。 **注 :** 定量化セキュリティ リスクに関連するタスクは、保険業界で、資産価値、リスク、および適切な補償を見積もるのに使用される手順に似ています。 現時点でも、情報セキュリティ リスクに対する保険契約が発売され始めています。 保険業界が情報セキュリティ リスクの評価経験を積むにつれて、情報セキュリティ用の保険統計表などのツールがリスクの定量化における貴重な参照資料となるでしょう。 ##### タスク 1: 資産クラスへの金銭的価値の割り当て 簡易データ収集のセクションで説明した資産クラスの定義を使用して、ビジネスへの影響が高いクラスの説明に合う資産の定量化を開始します。 これにより、セキュリティ リスク管理チームは、組織に最も重要な資産に最初に重点を置くことができます。 各資産の、組織に対する有形および無形の価値に対して金銭的価値を割り当てます。 参考までに、次のカテゴリを使用すると、各資産の合計影響コストを見積もりやすくなります。 - 交換コスト - 維持/メンテナンス コスト - 冗長性/可用性コスト - 組織/市場の評価 - 組織の生産性 - 年間売上げ - 競争上の優位 - 内部運用効率 - 法律/コンプライアンス責任 **注 :** SRMGTool3 - 詳細レベル リスク優先順位付けワークブックには、このプロセスを支援するワークシートが含まれています。 各カテゴリの金銭的見積もりを行なったら、値を合計して、資産の見積もりを決定します。 ビジネスへの影響が高いクラスに示されたすべての資産に対し、このプロセスを繰り返します。 この結果は、優先順位の高い資産の一覧と、これらの資産の組織に対する金銭的価値についての大まかな見積もりになります。 ビジネスへの影響が中および低いクラスに合う資産についても、このプロセスを繰り返します。 各資産クラス内で、資産クラスの価値を表す金銭的価値を 1 つ選択します。 保守的な手法は、各クラスで最も低いの資産価値を選択することです。 この値は、簡易データ収集の討議中に関係者によって選択された資産クラスに基づいて、資産価値を表すために使用されます。 この手法では、データ収集の討議時に選択した資産クラスを利用することにより、各資産に金銭的価値を割り当てるタスクを簡略化します。 **注 :** 資産価値を決めるもう 1 つの手法は、特定の資産の保険評価と補償範囲データを持つ金融リスク管理チームと共同で作業することです。   ##### ガイダンスとして具体性を使用する 前述の方法による資産クラス値の選択が難しい場合、もう 1 つのアプローチは、米国の株式会社で作成された、財務諸表の具体性の定義に関連付けられたガイドラインを使用することです。 組織の具体性のガイドラインを理解することは、定量的見積もりで高資産価値を選択する際に有用です。 米国財務会計基準審議会 (FASB = Financial Accounting Standards Board) は、株式会社の財務諸表に関して「本書の規定は、無形の項目に適用する必要はない」と説明しています。詳細については、
  • Last updated on