マイクロソフトのセキュリティ リスク管理プロセスでは、「リスクの評価」フェーズは、さらに大きなリスク管理プログラム内のスケジュールされた活動として説明されています。 「リスクの評価」フェーズでは、その組織で既知のリスク シナリオを特定して優先順位付けを行う手順を定義します。 結果として、概要レベルおよび詳細レベルの両方で、優先順位付けされたリスクの一覧が作成されます。 スケジュールされたリスク評価により、リスク管理プログラムの他のフェーズにも情報が提供されます。 スケジュールされたリスク評価は大きな価値をもたらしますが、その一方、企業に対するリスクはビジネスの通常の一部として継続的に変化、発展します。 したがって、セキュリティ リスク管理チームには、リスク管理サイクルのフェーズに関わりなく、リスクの特定および分析を行う定義されたプロセスが必要です。 次回にスケジュールされたリスク評価ラウンドまで新しいリスクの分析を控えることは賢明な方法とは言えません。 即座にリスクを認識する必要はいつでも生じる可能性があります。 たとえば、潜在的に存在するかまたはあまり認知されていない脅威をめぐるリスクの程度について、意見が統一されていないことが明らかになる場合があります。 このような場合、さまざまな関係者が相反する意見や対策を持ち出す可能性があります。 セキュリティ リスク管理チームは、リスクの位置付けを文書化して、正式なリスク管理プログラムだけでなく意思決定支援プロセスを推進するためにも、これを役立てる必要があります。 セキュリティ リスク管理チームは、リスクのすべての要素を理解していないと得ることができない特定のシナリオの機能要件の作成を求められる場合があります。 すなわち、即時の ad-hoc リスク評価が必要ということです。 事前に頭にあるソリューションまたは展開の正当化手段としてリスク評価プロセスを悪用しようとするようなリスク評価要求には注意する必要があります。 リスク評価は、特定の問題に関連する実際のリスクの公平な評価とならなければなりません。 マイクロソフトのセキュリティ リスク管理プロセスでは、複数のリスク シナリオを評価し、次にその優先順位付けを行いました。 ad-hoc リスク評価では、リスクはそれぞれ個別に分析されます。 ad-hoc リスク評価で重点が置かれるのは、「ビジネス ゲストへの無線ネットワーク アクセスの提供に関連するリスクは何か」とか「モバイル デバイスにエンタープライズ リソースへの接続を許可することによって発生するリスクは何か」など、単一のリスク問題です。ad-hoc リスク評価では、管理プロセスで説明した方法が使用されますが、リスクの優先順位付けおよび他のエンタープライズ リスクに対するソリューションは必須ではありません。 正式な優先順位付けは、対策ソリューションが高価な場合にのみ必要となることがあります。 多くの場合、類似のリスクと比較することで、ad-hoc リスク評価の優先順位は十分に把握することができます。 もちろん、ad-hoc の結果は正式なプロセスに適切に組み込まれます。 このガイダンスの「ツール」セクションに含まれているリスク評価テンプレートは、ad-hoc リスク評価に使用することもできます。 ただし、データ収集を行う場合、関係者とのミーティングを開かなくても調査だけで十分という場合もあります。 それでも、セキュリティ リスク管理チームはこのテンプレートの主要な質問に回答する必要がありますが、チーム自体がその回答のソースである場合もあります。 たとえば、チームがモバイル デバイスに関連するリスクを理解しようとする場合、デバイスの損失率の調査が必要な情報となることがあります。 この情報は、外部調査により、またはサービス エリアの運営担当の IT チームにより発見されます。 ad-hoc リスク評価は、次の各項目で構成された文書により報告します。 | • | 概要 この概要では、評価全体を包括し、リスク評価の内容が単独の文書として要約されている必要があります。 | | • | ad-hoc リスク評価の範囲および目的に関する前提条件一覧。 | | • | 保護対象資産およびその資産のビジネス価値の説明。 | | • | マイクロソフト セキュリティ リスク管理プロセスで説明されている、正しいフォームのリスク ステートメント。このステートメントでは次の質問に回答します。 | • | 資産に対する発生を防ぐリスクの内容。 | | • | 損失またはエクスポージャ発生の考えられる経緯。 | | • | 資産に潜在する危険度。 | | • | リスク発生の確率を最小にし、防御策が失敗した場合のリスクの影響を最小にするために現在行われている対策。 | | • | 全般的なリスクの内容。 「この攻撃により、影響度が中のデジタル資産の完全性が損なわれる可能性が高い、したがって組織へのリスクは高い」など。 | | • | 将来的に確率を低減する可能性のある措置。 | | • | 可能な制御を実装した場合の全般的なリスクの内容。 |
|
1 つのリスク評価に、複数の脅威シナリオが含まれる場合があります。 上で挙げたゲストの無線アクセスの例では、第 1 のシナリオとして、ゲストが別のゲストを攻撃するリスクが挙げられます。第 2 のシナリオとして、ゲストの誰かに対する外部からの攻撃、第 3 のシナリオとして、ゲストのアクセス悪用によるインターネット経由での特定対象への攻撃の可能性が挙げられます。 適用可能なすべてのシナリオに対してリスク ステートメントを作成する必要があります。 リスクの内容を理解したら、それについて通知するだけで十分な場合もあります。 また、セキュリティ リスク管理チームが作成した機能要件ステートメントだけが要求される場合もあります。 機能要件が作成された場合、対応する特定のリスクに割り当てる必要があります。 セキュリティの機能要件を備えたリスク評価文書は、企業がリスクを理解して最善の対策ソリューションを決定する際に役立つ効果的なツールです。
| 
