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

トピック

	概要
	制御を特定して比較する
	要約

概要

組織は、「リスクの評価」フェーズを終了して、最も価値のある資産に対するリスクの優先順位一覧を作成しました。 次に、それらを軽減する適切なアクションを決定して、最も重大なリスクに対処する必要があります。 このフェーズは「意思決定支援の実行」と呼ばれます。 セキュリティ リスク管理チームは、前のフェーズで、資産、それらの資産に対する脅威、その脅威が悪用することにより資産に影響を及ぼす可能性のある脆弱性、および資産を保護するために既に確立されている制御を特定しました。 その後、リスクの優先順位付き一覧を作成しました。

意思決定支援プロセスには、組織の境界を越えて定義された役割と責任による正式な費用対利益分析が含まれています。 費用対利益分析は、リスクを許容レベルに引き下げるための、最も効果的かつ効率的な対策ソリューションを特定し、その適用範囲を決定し、そして選択するための一貫した総合的な仕組みを提供します。 リスク評価プロセスと同じように、費用対利益分析を効果的に行うには、厳密な役割定義が必要です。 また、費用対利益分析を行う前に、セキュリティ リスク管理チームは、エグゼクティブ スポンサーを含むすべての関係者が、プロセスを承認して合意していることを確認する必要があります。

「意思決定支援の実行」フェーズでは、セキュリティ リスク管理チームは、最も効果的かつ効率的に主要なリスクに対処する方法を決定する必要があります。 その結果として、リスク評価プロセスで特定された上位の各リスクを制御、容認、移管、または回避するための明確な計画が作成されます。 「意思決定支援の実行」フェーズは、6 つの手順で構成されています。

下の図 5.1 は、これら 6 つの手順と、「意思決定支援の実行」フェーズとマイクロソフト セキュリティ リスク管理プロセス全体との関係を示しています。

図 5.1 マイクロソフト セキュリティ リスク管理プロセス : 「意思決定支援の実行」フェーズ
拡大表示する

特定の制御の値と別の制御の値を比較する場合に、単純な式はありません。 このプロセスは、さまざまな理由から実行が難しい場合があります。 たとえば、一部の制御は多くの資産に影響を与えます。 セキュリティ リスク管理チームは、さまざまな組み合わせの資産に影響を与える制御の値の比較方法について合意する必要があります。 さらに、これらの制御の実装範囲を越える制御に伴いコストが発生します。 検討が必要な関連する質問は、次のとおりです。

この章の残りの部分では、これらの質問に対する答えについて説明します。

明確な経路に従い、参加者が各手順でそれぞれの役割を理解していれば、意思決定支援プロセスで成功を収めることができます。 次の図は、セキュリティ リスク管理チームが意思決定支援プロセスを実行する方法を示しています。 対策責任者は、リスクを軽減する制御を提案し、各制御のコストを決定します。 提案された各制御について、セキュリティ リスク管理チームは、制御が実現すると期待されるリスク軽減度を予測します。 これらの情報に基づいて、チームは、効果的な費用対利益分析を制御に対して実行し、その実装を推奨するかどうかを決定できます。 そして、セキュリティ運営委員会が、どの制御を実装するかを決定します。

図 5.2 「意思決定支援の実行」フェーズの概要
拡大表示する

役割を明確に定義すると、1 つのグループのみが意思決定に責任を負うこともあり、遅延が減ります。 しかし、これまで経験から、各責任者が他の関係者と協力すると、リスク管理プログラムの全体的な効果が増すことがわかっています。

注 : リスクの管理は永続的なサイクルなので、協力の精神を維持すると関係者のモラルが高まります。また、関係者が、自分の貢献の効果を認識し、タイミングよくリスクの軽減活動を行うことができるので、ビジネスに対するリスクが実際に削減される場合があります。 もちろん、リスク管理プロセスおよび意思決定支援プロセス全体でこの姿勢を維持して高めるよう努力する必要があります。

「意思決定支援の実行」フェーズで必要な情報

「意思決定支援の実行」フェーズで必要な情報は、「リスクの評価」フェーズで作成された情報、つまり、軽減する必要のあるリスクの優先順位一覧のみです。 「第 4 章 : リスクの評価」で説明した手順に従った場合、この情報は、このガイドと関連ファイルを含むアーカイブをアンパックしたときに作成された "Tools and Templates" フォルダに入っている SRMGTool3-Detailed Level Risk Prioritization.xls Microsoft® Excel ワークブック内の Detail Risk ワークシートに記録されています。 プロセスのこのフェーズでは、この同じワークシートを引き続き使用します。

「意思決定支援の実行」フェーズの参加者

「意思決定支援の実行」フェーズの参加者は、「リスクの評価」フェーズの参加者とほぼ同じです。実際には、チーム メンバの全員が前のフェーズに参加していなくても、ほとんどのメンバがこのフェーズに参加します。 費用対利益分析が、意思決定支援プロセスのタスクの大部分に通知されます。 しかし、費用対利益分析を開始する前に、すべての関係者が各自の役割を理解していることを確認してください。

次の表に、意思決定支援プロセスにおける各グループの役割と主な責任を示します。

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

セキュリティ リスク管理チームは、特定された各リスクにセキュリティ技術者を割り当てる必要があります。 窓口を 1 つにすると、セキュリティ リスク管理チームが矛盾するメッセージを作成するリスクが減り、費用対利益分析全体ですっきりした提携モデルが構成されます。

「意思決定支援の実行」フェーズで提供されるツール

プロセスのこのフェーズで収集された情報は、SRMGTool3-Detailed Level Risk Prioritization.xls Excel ワークブックの Detail Risk ワークシートに記録する必要があります。このワークブックは、このガイドと関連ファイルを含むアーカイブをアンパックしたときに作成された "Tools and Templates" フォルダにあります。

「意思決定支援の実行」フェーズで作成する必要がある情報

マイクロソフト セキュリティ リスク管理プロセスのこのフェーズでは、「リスクの評価」フェーズで特定した上位の各リスクに関する重要な情報を定義して選択します。 次の表に、これらの重要な要素を示します。各要素については、この章の以降の項で詳しく説明します。

表 5.2: 意思決定支援の実行で作成が必要な情報

意思決定支援オプションを検討する

組織がリスクを処理する方法として、リスクの容認と、リスクを軽減する制御の実装の 2 つの基本的な方法があります。 リスクの容認を選択した場合は、リスク全体またはリスクの一部を、保険会社や管理サービス会社などの第三者に移管することを決定できます。 次の 2 つの項では、リスクの容認と、リスクの軽減を容易にする制御の実装の、2 つのリスク対処方法について説明します。

注 : 多くのセキュリティ リスク管理担当者は、各リスクを処理するもう 1 つのオプションとして "回避" があると考えています。 しかし、リスクの回避を選択した場合、そのリスクを引き起こす、あらゆるアクティビティを停止することになるので注意する必要があります。 セキュリティ リスク管理という点からリスクを回避するには、組織はリスクを抱えた情報システムの使用を停止する必要があります。 たとえば、"1 年以内に、更新プログラムが適用されていないサーバーがマルウェアによって危害を受けて、財務データの完全性が損なわれる可能性がある" というリスクの場合、このリスクを回避する唯一の方法は、サーバーの使用を停止することです。しかし、おそらくこれは現実的なオプションでありません。 マイクロソフト セキュリティ リスク管理プロセスは、ビジネス バリューを提供する資産の調査のみに関心があり、サービスは維持する組織を前提にしています。 したがって、このガイドではオプションとしての回避を説明しません。

現在のリスクを容認する

セキュリティ運営委員会は、リスクを生産的に軽減してコスト効率の高い制御がないと判断した場合、現在のリスクを容認することを選択する必要があります。 これは、組織が、1 つまたは複数の制御を実装しても、リスクに効果的に対処できないという意味でありません。制御を実装するコスト、または組織のビジネス遂行能力に対する制御の影響力が、保護が必要な資産の価値に比べて高すぎるという意味です。 たとえば、次のシナリオについて考えてみてください。

セキュリティ リスク管理チームは、組織の重要な資産に対する最も重要なリスクの 1 つが、企業ネットワークにログオンする際のユーザー認証をパスワードに依存していることであると判定しました。 そして、認証用パスワードの使用を減らして最終的になくすには、スマート カードなどの 2 要素による認証技術を展開することが最も効果的な方法であると特定しました。 これに対し、対策責任者は、組織全体へのスマート カードの展開コストおよび組織の既存のオペレーティング システムとアプリケーションへの影響を算出しました。 展開コストは非常に高くなりますが、正当化できないほどではありません。ところが、社内で開発したビジネス アプリケーションの多くがパスワードベースの認証に依存しているため、これらのアプリケーションの書き直しや置き換えに巨額の費用がかかり、しかも数年かかることをチームが気づきました。 最終的にチームは、全社員へのスマート カードの使用をセキュリティ運営委員会に対して当分の間推奨しないことを決定しました。 しかし、実際には、危害を受ける可能性があるので、ドメイン管理者や主要な上級管理職など、特に強力な権限を持つアカウントまたは機密性の高いアカウントを持つユーザーはスマート カードによって認証する必要があることを認識しています。 セキュリティ運営委員会は、最終的に「スマート カードは全社員には必要ない」というセキュリティ リスク管理チームの勧告に従うことにしました。

リスクの容認の一種として、第三者へのリスクの移管があります。 IT 資産に対する保険契約が利用可能になり始めています。 または、管理セキュリティ サービスを専門とする別の会社と契約することもできます。このアウトソーシング企業は、組織の IT 資産を保護する責任の一部または全部を請け負う場合があります。

リスクを軽減する制御を実装する

制御は、対策または保護手段とも呼ばれ、組織、手順、またはテクノロジによるリスク管理手段です。 対策責任者は、セキュリティ リスク管理チームからのサポートを受けて、可能なすべての制御を特定し、各制御の実装コストを計算し、ユーザーの不便さや制御の継続的なメンテナンス コストなど制御に関連するその他のコストを決定し、各制御によって可能なリスク軽減度を評価します。 チームはこれらの情報をすべて利用して、提案された各制御の費用対利益分析を効果的に実行することができます。 組織にとって相応なコストで重要な資産へのリスクを最も効果的に軽減する制御は、チームが最も熱心に実装を推奨する制御です。

成功するための鍵

「リスクの評価」フェーズと同じように、「意思決定支援の実行」フェーズを成功させるには、合理的な予測を行うことが重要です。 意思決定支援では、事業全体を構成するさまざまなグループからの大きな貢献が必要です。 これらのグループの 1 つでもプロセスを理解していなかったり、プロセスに積極的に参加しないと、プログラム全体の効果が損なわれることがあります。 役割、責任、参加の程度を含め、「意思決定支援の実行」フェーズで各参加者に求められていることを明確に説明してください。

合意を取り付ける

セキュリティ リスク管理チーム全体が、可能な限り合意によって決定に達することが重要です。合意していないと、チームが勧告をセキュリティ運営委員会に提出した後に、同意していないメンバのコメントによって勧告が歪められる場合があります。 委員会が推奨された制御を承認した場合でも、表に出ない意見の相違によって、その後の制御実装プロジェクトが失敗する場合があります。 リスク管理プロセス全体を成功させるには、すべてのチーム メンバが推奨した制御に合意し、支援する必要があります。

議事妨害を防ぐ

このフェーズの目的の 1 つは、合意によって制御の一覧を作成することなので、どの関係者も議事妨害を行って進行を遅らせたり停止させることができます。 つまり、「意思決定支援の実行」フェーズに参加するすべての関係者が、特定の制御の推奨に合意することを拒否できます。 逆に、特定の制御の推奨が危うい場合には、多数意見に対して自分の少数意見を押し付けようとすることができます。 議事を妨害するような状況が発生した場合にリスク評価進行担当者がそれを解決することが非常に重要です。 このような課題の処理についてさまざまな助言を行うことは、このガイドの目的ではありません。しかし、有効な方法としては、その人の意見に対する主な理由を特定し、チーム全体が受け入れ可能と思われる効果的な代替案または折衷案をチームと協力して見つけるよう努力する方法があります。

ページのトップへ

制御を特定して比較する

ここでは、対策責任者が潜在的な制御ソリューションを特定し、提案された各制御の実装に伴うコストの種類を決定する方法、および、セキュリティ リスク管理チームが、提案した各制御によって実現されるリスク軽減レベルを予測する方法について説明します。 対策責任者とセキュリティ リスク管理チームは、調査結果と推奨するソリューションをセキュリティ運営委員会に提出して、制御ソリューションの最終一覧から実装する制御を選択できるようにします。

次の図は、前の章で詳細なリスク評価を実行するのに使用した Excel ワークブック内の Detail Risk ワークシートからの抜粋です。 このワークシート SRMGTool3-Detailed Level Risk Prioritization.xls はこのガイドに同梱されており、"Tools and Templates" フォルダにあります。 図には、費用対利益分析中に使用されたすべての要素が表示されています。 それぞれの列については、以降の手順で説明します。

図 5.3 詳細リスク ワークシート (SRMGTool3) の [意思決定支援] セクション
拡大表示する

注 : このワークシートは、リスク軽減レベルを決定する際の影響の確率を下げることに重点を置いています。 資産の価値は、リスク評価期間内に変化しないものと仮定しています。 通常、危険度 (資産に対する損害の範囲) は一定です。 脅威と脆弱性の説明が十分に詳しく明記されている場合、通常、危険度は変化しないことがわかっています。

手順 1: 機能要件を定義する

機能セキュリティ要件は、リスクへの対策に必要な制御を説明したステートメントです。 "機能" という用語は重要です。なぜなら、記述されているテクノロジと異なり、制御は必要な機能の点から表現する必要があるからです。 代替の技術的なソリューションを利用できる場合があります。また、機能セキュリティ要件を満たしている場合には、どの解決策も使用できます。 セキュリティ リスク管理チームが、費用対利益分析の最初の成果物である機能要件を定義します。 潜在的な制御を適切に特定するには、セキュリティ リスク管理チームは、ビジネスに対するリスクを軽減するために制御が実現しなければならないことを定義する必要があります。 チームが所有権を保持していますが、対策ソリューションの責任者と協力することを強くお勧めします。

機能要件は、「意思決定支援の実行」フェーズで論議したリスクごとに定義する必要があります。作成された情報は "機能要件定義" と呼ばれます。機能要件の定義と所有権は、費用対利益分析プロセスにとって非常に重要です。 この文書は、特定されたリスクを軽減するために行う必要がある処理を定義しますが、リスクの軽減方法や具体的な制御の定義方法は指定しません。 この違いにより、セキュリティ リスク管理チームには自分たちの専門分野での責任が与えられ、また、対策ソリューションを実装する対策責任者はビジネスの実施と支援に関する決定権を所有することができます。 各リスクへの対応は、SRMG3-Detailed Level Risk Prioritization.xls の [セキュリティ機能要件] 列に記述されます。 機能要件は少なくとも 1 年に一度確認して、まだ必要か、それとも変更する必要があるかどうかを判断する必要があります。

図 5.4 「意思決定支援の実行」フェーズの手順 1
拡大表示する

前のフェーズで完了した作業により、組織は自社のリスクの位置を理解し、最も重大なリスクを軽減するためにどの制御を実装する必要があるかを合理的に判断することができます。 エグゼクティブ スポンサーと事業主は、情報セキュリティ グループが考えている、各リスクについて組織が実行すべきことを把握する必要があります。 情報セキュリティ グループは、機能セキュリティ要件を作成してこれに回答します。 つまり、リスクごとに、リスクを軽減するために導入する必要のある機能またはプロセスの種類について明快なステートメントを作成します。

Woodgrove の例 : 前の章で使用した Woodgrove Bank の例に基づくと、ウイルス対策定義ファイルの古い設定、ホスト構成、または古いセキュリティ アップデートによって、管理対象のローカル エリア ネットワーク (LAN) から資格情報が盗まれるリスクに対する有効な機能要件は、次のようになります。

ユーザーがローカル ネットワークにログオンする際に複数の要因によって身元を認証する機能が必要です (MUST)。

機能ではない要件の例は次のとおりです。

ソリューションでは、ユーザーの認証にスマート カードを利用する必要があります (MUST)。

2 番目のステートメントは、特定のテクノロジの使用について記述しているので、機能ではありません。 機能要件を満たす特定の制御ソリューションの一覧を提供するのは、対策責任者の責任です。つまり、機能要件を技術的制御ソリューションおよび管理制御 (ポリシー、標準、ガイドラインなど) に変換するのは、対策責任者です。

詳細レベルのリスク優先順位付け手順で調査した 2 番目のリスク、つまり、セキュリティ構成が古いためにリモート モバイル ホストから資格情報が盗まれるリスクに対する機能要件は、次のようになります。

ユーザーが遠隔地からネットワークにログオンする際に複数の要因によって身元を認証する機能が必要です (MUST)。

各リスクの機能要件を SRMGTool3-Detailed Level Risk Prioritization.xls の [セキュリティ機能要件] 列に記録してください。

http://www.ietf.org/rfc/rfc2119.txt (英語) の Internet Engineering Task Force (IETF) Request for Comments (RFC) 2119 に、要件ステートメントで使用される重要な単語と語句に関するガイダンスが説明されています。 これらの用語は、"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" で、通常すべて大文字で表記されます。マイクロソフトでは、RFC 2119 で説明されている次の定義に従って、機能要件ステートメントにこれらの重要な単語を使用することをお勧めします。

リスクごとに機能要件を定義して文書化したら、「意思決定支援の実行」フェーズの次の手順に進むことができます。

手順 2: 制御ソリューションを特定する

このフェーズの次の手順では、対策責任者が、リスクの機能要件に対処する、各リスクの潜在的な新しい制御の一覧を作成します。 多くの組織では、情報セキュリティ グループのメンバは、前のフェーズで特定して分類した各リスクの一連の潜在的な制御を特定して、支援することができます。 この目的を達成するための十分な専門知識が社内に備わっていない組織では、対策責任者をコンサルタントで補うことを検討できます。

図 5.5 「意思決定支援の実行」フェーズの手順 2
拡大表示する

潜在的な制御を特定するプロセスは、対策責任者の多くまたは全員が経験したことがない場合は特に、困難に思えるかもしれません。 チームが新しいアイデアを考え出すのに役立つ方法が 2 つあります。多くの組織は、両方とも使用するのが最も効果的であると考えています。 1 つ目は、非公式なブレインストーミング方法です。2 つ目はより組織的で、制御をどのように分類および構成できるかに基づいています。 セキュリティ リスク管理チームは、これら 2 つの方法を組み合わせて使用する必要があります。

ブレインストーミング方法では、各リスクについて、リスク評価進行担当者がチームに次の一連の質問を提示します。 リスク評価記録担当者は、SRMGTool3-Detailed Level Risk Prioritization.xls の [提案する制御] 列にすべての回答を記録します。 この作業は、上位のリスクがすべて調査されて、チームが各制御に関連するコストの決定作業に移るまで続きます。

潜在的な新しい制御を特定する 2 つ目の方法では、制御を組織、運用、およびテクノロジの 3 つの大きなカテゴリに分類します。 これらはさらに、予防、検出復旧、および管理を行う制御に分類されます。 予防的制御は、リスクが発生しないようにするために実装されます。たとえば、侵害が発生する前に侵害を停止します。 検出制御と復旧制御により、組織はセキュリティ イベントが発生した日時を特定し、その後に通常の運用を再開することができます。 管理制御は必ずしもそれ自体では保護を提供しませんが、他の制御を実装するために必要です。 これらのカテゴリについては、この後詳しく説明します。

組織制御

組織制御は、組織の人間が各自の任務をどのように実行する必要があるかを定義した手順とプロセスです。

このカテゴリの予防的制御は次のとおりです。

このカテゴリの検出制御は次のとおりです。

このカテゴリの管理制御は次のとおりです。

運用制御

運用制御は、組織内の人間がデータ、ソフトウェア、ハードウェアをどのように取り扱う必要があるかを定義します。 これには、後で説明するように環境および物理的な保護も含まれます。

このカテゴリの予防的制御は次のとおりです。

このカテゴリの検出および復旧制御は次のとおりです。

テクノロジ制御

テクノロジ制御は複雑さが大幅に異なります。 これには、システム アーキテクチャの設計、エンジニアリング、ハードウェア、ソフトウェア、およびファームウェアが含まれます。 これらはすべて組織の情報システムの構築に使用されるテクノロジ構成要素です。

このカテゴリの予防的制御は次のとおりです。

このカテゴリの検出および復旧制御は次のとおりです。

このカテゴリの管理制御は次のとおりです。

制御ソリューションを検討するときには、「第 6 章 : 制御の実装とプログラムの効果の測定」の「制御ソリューションを編成する」の項も参照することをお勧めします。この項には、組織での情報システムのセキュリティ強化を支援するために作成された各種の規範的なガイダンスへのリンクが記載されています。

Woodgrove の例 : 1 番目のリスクである、財務アドバイザのユーザー資格情報が LAN へのログオン中に盗まれる可能性があるというリスクは、企業ネットワークにローカル接続する際のユーザー認証にスマート カードを使用するように義務付けることによって対処できます。

2 番目のリスクである、財務アドバイザのユーザー資格情報が遠隔地からネットワークにログオンしているときに盗まれる可能性があるというリスクは、企業ネットワークにリモート接続する際のユーザー認証にスマート カードを使用するように義務付けることによって対処できます。 各リスクに対して提案された各制御を、SRMGTool3-Detailed Level Risk Prioritization.xls の [提案する制御] 列に記録してください。

手順 3: ソリューションと要件を比較検討する

セキュリティ リスク管理チームは、制御が定義済みの機能要件を満たすことを確認するために、制御ソリューションを承認する必要があります。 費用対利益分析プロセス全体で協力するもう 1 つの利点は、プロセス固有のチェック アンド バランスを期待できることです。たとえば、対策責任者がセキュリティ要件定義に含まれていれば、通常、ソリューションは要件に適合します。 特定のリスクの機能要件を満たさない制御は、Detail Risk ワークシートから削除されます。

図 5.6 「意思決定支援の実行」フェーズの手順 3
拡大表示する

Woodgrove の例 : セキュリティ リスク管理チームは、ユーザー認証へのスマート カードの使用について比較検討して、その実装が機能要件を満たすかどうか判定しました。 この場合、スマート カードは、この例で使用されている 1 つ目と 2 つ目の両方のリスクの機能要件を確かに満たします。 提案された制御のうち拒否された制御には、SRMGTool3-Detailed Level Risk Prioritization.xls で別の書式を設定してマークしてください。

手順 4: リスク軽減を予測する

セキュリティ リスク管理チームは潜在的な対策を承認したら、ビジネスに対する総合的なリスク軽減量を計算し直す必要があります。 リスク軽減量は対策ソリューションのコストと比較されます。 これは、費用対利益分析で定量的な金額が値として示される最初の手順です。 通常、リスク軽減は、ビジネスに対して影響が発生する確率を拡大して予測されます。 高、中、または低の確率評価にはそれぞれ、影響が与えられそうな場合の予想期間が含まれていることに注意してください。

図 5.7 「意思決定支援の実行」フェーズの手順 4
拡大表示する

影響が与えられそうな時期の予測を 1 年から 3 年以上に拡大すると、セキュリティ リスク管理チームとセキュリティ運営委員会に重要な値が提供されます。 金額的な損失予測は減らないかもしれませんが、損失が近い将来発生する可能性は低くなります。 目標は影響をゼロにすることではなく、ビジネスに対するリスクの許容レベルを定義することである点に注意してください。

短期間でリスクを軽減するもう 1 つの利点は、技術制御コストが時間とともに減少して効果が増加する一般的な傾向と関連しています。 たとえば、現在のパッチ管理戦略を改善すると、すぐにホスト侵害の確率が大幅に減少する場合があります。 その一方で、更新プログラムとセキュリティ更新プログラムの展開を効果的に管理する、新しいガイダンスとツールが利用可能になると、これらの処理のコストが減少する場合があります。 2 つの要素による認証を使用したコストの削減は、この傾向のもう 1 つの例です。

制御の相対的なリスク軽減度を決定する場合には、制御がリスクに影響を与えるすべての方法を検討してください。 検討が必要な質問は、次のとおりです。

特定の制御が複数の脆弱性と資産に影響を与える場合、これらの質問は複雑になります。 この手順の目的は、最終的に、各制御がリスクのレベルをどのくらい下げるかを予測することです。 各リスクの危険度評価、確率評価、およびリスク評価の新しい値を、SRMGTool3-Detailed Level Risk Prioritization.xls の [新しい制御を使用した場合の危険度]、[新しい制御を使用した場合の確率]、および [新リスク評価 ] 列に記録してください。

Woodgrove の例 : 1 番目のリスクである、財務アドバイザのパスワードが LAN クライアントの使用中に盗まれるリスクに関して、セキュリティ リスク管理チームは、ローカル認証にスマート カードを実装した後の危険度評価が 8 で、確率評価が 1 に下がり、それにより新しいリスク評価が 9 になるという結論に達しました。 2 番目のリスクである、財務アドバイザのパスワードが、ネットワークにリモート アクセスしている間に盗まれるリスクに関して、セキュリティ リスク管理チームは同じような値になることを確認しました。 提案された各制御の新しい危険度評価、確率評価、およびリスク評価を、SRMGTool3-Detailed Level Risk Prioritization.xls の Detailed Risk ワークシートの [新しい制御を使用した場合の危険度]、[新しい制御を使用した場合の確率]、および [新リスク評価] 列に記録してください。

手順 5: ソリューション コストを予測する

このフェーズで行う次のタスクは、対策責任者が、提案された各制御の相対的なコストを予測することです。 IT エンジニアリング チームは、各制御を実装する方法を決定し、各制御の取得、実装、およびサポートにかかるコストを合理的に正確に予測できる必要があります。 マイクロソフト セキュリティ リスク管理プロセスには、ハイブリッド リスク管理プロセスが伴うので、正確なコストを計算する必要はなく、予測で十分です。 費用対利益分析中に、絶対的な財務数値ではなく、各制御の相対的な価値とコストが比較されます。 チームはこれらの予測を作成する場合、制御に関連する、次の直接および間接経費をすべて考慮する必要があります。 各制御のコストを SRMGTool3-Detailed Level Risk Prioritization.xls の [制御コストの内訳] 列に記録してください。

図 5.8 「意思決定支援の実行」フェーズの手順 5
拡大表示する

取得コスト

これらのコストには、提案された新しい制御に関連するソフトウェア、ハードウェア、またはサービスが含まれます。 一部の制御では、取得コストがかからない場合があります。たとえば、組織が既に使用しているネットワーク ハードウェアのこれまで使用されていない機能を有効にするだけで、新しい制御を実装できる場合です。 その他の制御では、分散ファイアウォール ソフトウェアやアプリケーション層フィルタリング機能付きの専用ファイアウォール ハードウェアなどの新しいテクノロジの購入が必要になる場合があります。 また、一部の制御では、購入するものはなくても、第三者組織の雇用が必要になる場合があります。 たとえば、ある組織が別の会社を雇って、毎日更新される既知のスパム発信者のブロック リストを提供してもらい、自分の組織のメール サーバーに既にインストールされているスパム フィルタにそのリストを組み込むことができます。 組織が自社での開発を選択する制御もあります。制御の設計、開発、およびテストにかかるすべてのコストは、組織の取得コストの一部になります。

実装コスト

この経費は、提案された新しい制御をインストールして設定するスタッフまたはコンサルタントにかかるコストです。 一部の制御では、適切に指定、設計、テスト、および展開するために大規模なチームが必要になる場合があります。 あるいは、組織がエンタープライズ管理ツールを既に展開している場合には、知識の豊富なシステム管理者が、すべてのデスク コンピュータとモバイル コンピュータ上にある少数の未使用システム サービスをわずか数分間で無効にすることができます。

運用コスト

このコストは、管理、監視、メンテナンスなど、新しい制御に伴う継続する活動に関するものです。 予測するのが非常に困難だと思われる場合は、タスクに必要な人数、およびタスクを実行するのに必要な毎週 (または毎月、毎年) の時間数の点から考えてみてください。 世界中に支社がある大企業の場合は、堅牢な分散型ネットワークベースの侵入検出システムについて考えてみてください。 このようなシステムでは、スタッフがシステムを毎日 24 時間監視する必要があり、スタッフには警告を理解して効果的に対応できる能力が必要です。 組織がこの複雑な制御の潜在能力を十分に発揮させるには、8 〜 10 人、またはそれ以上のフルタイムの社員が必要です。

通信コスト

この経費は、新しいポリシーや手順をユーザーに通知する際にかかるコストです。 サーバー ルームに電子ロックを取り付けていて、社員が数百人の組織の場合は、IT スタッフと上級管理者に電子メールを送信するだけで十分です。 しかし、たとえば、スマート カードを展開する組織では、スマート カードとリーダーを配布する前後に大量のやり取りが必要になります。それは、ユーザーが、自分のコンピュータにログオンするためのまったく新しい方法を習得する必要があり、さまざまな新しい状況や予想外の事態に間違いなく直面するためです。

IT スタッフのトレーニング コスト

これらのコストは、新しい制御を実装、管理、監視、および保守する必要のある IT スタッフに関連するものです。 スマート カードの展開を決定した前述の例の組織について考えてみてください。 IT 組織内の各チームの職責はそれぞれ異なるので、さまざまなタイプのトレーニングが必要です。 ヘルプ デスク スタッフは、カードやリーダーの破損、PIN を忘れたなどの一般的な問題をエンド ユーザーが解決できるように支援する方法を知っている必要があります。 デスク トップ サポート スタッフは、スマート カード リーダーをインストール、トラブルシューティング、診断、および交換する方法を知っている必要があります。 IT 組織内のチーム、人事部内のチーム、または組織内の物理的なセキュリティ部門のチームは、新しいカードや代わりのカードを配布し、退職する社員からカードを回収する必要があります。

ユーザーのトレーニング コスト

この経費は、新しい制御を操作するために、新しい使用方法を習得する必要のあるユーザーに関連するものです。 前述のスマート カードを展開する例では、すべてのユーザーがスマート カードとリーダーの操作方法を理解し、さらにカードの適切な取り扱い方も理解する必要があります。これは、ほとんどのスマート カードは、クレジット カードや銀行のカードよりも物理的な衝撃に弱いからです。

生産性と利便性に対するコスト

これらの経費は、新しい制御によって影響を受ける仕事を持つユーザーにかかるものです。 前述のスマート カードの例では、カードとリーダーの展開と、ユーザーの初期問題の解決支援にかかる最初の数週間または数か月が過ぎれば、その後は特に問題はないと思うかもしれません。 ところが、ほとんどの組織がこれに当てはまりません。 たとえば、多くの組織で、既存のアプリケーションがスマート カードと互換性がないことに気付きます。 場合によってはこれが問題にならないかもしれませんが、機密の社員情報の管理に人事部が使用しているツールではどうでしょうか? もしくは、全顧客の重要なデータを追跡するために組織全体で使用されているCRM (顧客関係管理) ソフトウェアではどうでしょうか?

このような重要なビジネス アプリケーションが、スマート カードと互換性がなく、ユーザー認証が必要となるように設定されている場合、組織は難しい選択を迫られることになります。 ソフトウェアをアップグレードすることはできますが、これには新しいライセンス、展開、トレーニングの点からさらに多くのコストがかかります。 または、認証機能を無効にすることもできますが、そうするとセキュリティが大幅に低下します。 ほかに、これらのアプリケーションにアクセスするときにユーザーにユーザー名とパスワードの入力を要求することもできます。しかし、ユーザーは再びパスワードを覚えなければならず、スマート カードの重要な利点の 1 つがなくなります。

監査および効果を確認するためのコスト

組織は、提案された新しい制御の実装後に、これらの経費を負担することになります。 これらのコストをさらに定義するための質問事項の一例を次に示します。

組織は、誰も制御を誤ってまたは故意に変更もしくは無効にしていないことを立証できる必要があります。また、この確認を行う担当者を決定する必要があります。 機密性の非常に高い資産の場合には、複数の人間がその結果を検証する必要があります。

Woodgrove の例 : 対策責任者が決定したリスクのコストを、下の表 5.3 および 5.4 に示します。 提案された各制御のコスト予測を SRMGTool3_Detailed Level Risk Prioritization.xls の [制御コストの内訳] 列に記録してください。

表 5.3: VPN および管理アクセス用にスマート カードを実装する際のコスト

表 5.4: ローカル アクセス用にスマート カードを実装する際のコスト

手順 6: リスクへの対策ソリューションを選択する

費用対利益分析の最後の手順は、対策ソリューション後のリスクのレベルと対策ソリューション自体のコストを比較することです。 リスクとコストのどちらにも、厳密な金銭的な観点から測定するのが難しい主観的な値が含まれています。 適切な比較テストとして量的な値を使用します。 発生するリスクの無形のコストは無視できません。 資産所有者には、リスクが実際に発生した場合の予想される状況について尋ねます。 このとき、対策ソリューションの重要性を評価するのに役立つように、回答の文書化を依頼します。 この方法は、量的数値の算術比較と同じくらい説得力があります。

図 5.9 「意思決定支援の実行」フェーズの手順 6
拡大表示する

費用対利益分析では、一般的に、リスク軽減量と対策ソリューション後のリスク量の差に注目することを忘れがちです。 通常、対策ソリューション後のリスク量は残留リスクと呼ばれます。 量的な数値を使用した簡単な例を挙げます。現在、リスクが 1000 ドルとして表示され、提案された制御がリスクを 400 ドル削減するとします。この場合、事業主は対策ソリューションを採用した後に 600 ドルのリスクを容認する必要があります。 対策ソリューションが 400 ドル未満でも、600 ドルの残留リスクがあります。

Woodgrove の例 : すべてのユーザー認証にスマート カードを採用するとコストが非常に高くなるので、銀行は、リモート アクセスのみにスマート カードを実装することになりそうです。 マイクロソフト セキュリティ リスク管理プロセスの次のフェーズに進む前に、推奨されたセキュリティ ソリューションのうち、実装することにしたソリューションを記録してください。

ページのトップへ

要約

「意思決定支援の実行」フェーズでは、セキュリティ リスク管理チームが、「リスクの評価」フェーズで特定した上位の各リスクに関する重要な追加情報を収集します。 チームは、組織の各リスクへの対応として、制御、容認、移管、または回避のいずれを行うべきかを決定します。 そして、各リスクの機能要件を定義します。 次に、対策責任者が、セキュリティ リスク管理チームと協力して、潜在的な制御ソリューションの一覧を作成します。 その後、チームが、各制御によって実現されるリスク軽減度と、各リスクに伴うコストを予測します。 最後に、セキュリティ運営委員会が、次の章で説明する「制御の実装」フェーズで、対策責任者が実装する必要のある制御ソリューションを選択します。

ページのトップへ

6 of 12