※ 本記事は、Nancy Kramerによる”Prioritize Business-Critical Risks“を翻訳したものです。
2024年10月18日
リスク管理の要点で説明されているように、リスクのレベルを決定するための基本的な式は、将来の潜在的イベントの可能性にそれらのイベントの予測される影響を乗算することです。その式は様々な方法で拡張できます。この投稿では、ビジネスクリティカルなプロセスとシステムのリスク優先順位付けを容易にし、リスク管理の有効性を向上させるための修正された式を提案しています:
ビジネスクリティカルなプロセスの特定
ビジネス・クリティカルなチーム、プロセスおよびシステムを、自己回復性またはビジネス継続性プログラムの一部としてすでに特定できます。その場合は、この分析にその情報を使用します。この情報がまだ提供されていない場合は、以下のプロセスを指定します。この分析には、重要な業務、安全性、規制コンプライアンス、顧客が業務に頼っている製品/サービスを提供する能力などの考慮事項を含める必要があります。
社内の様々な利害関係者に相談して、経営幹部にすばやくエスカレートするプロセスの中断を特定する必要があります。たとえば、財務システムは通常、不可欠と見なされます。セクター固有の例を次に示します:
- 小売業向けPOSシステムとオンラインストア
- 医療用電子健康記録システム
- 金融機関の支払処理システム
- 公益事業および製造業向け産業制御システム
これらのビジネスクリティカルなプロセスをサポートするシステムの一覧表示
ビジネス・クリティカルなプロセスごとに、これらのプロセスの実行に必要な関連システムを決定する2つの部分があります。最初の部分は、プロセスのエキスパートに質問し、プロセスの手順を分析することで、従業員、パブリックまたは顧客の直接のやり取りでシステムを識別することです。2つ目の部分では、これらのアプリケーションをサポートするITチームに、間接的なシステムの依存関係と重要な統合を特定するよう依頼します。たとえば、オーダー管理システムは外部税金計算システムに依存する場合があります。税金を計算できない場合、オーダー入力プロセスが正しくないか、または中断される可能性があります。
潜在的なイベントを識別し、可能性と影響を割り当て
クリティカルなプロセスおよびサポート・システムに悪影響を及ぼす可能性のあるイベントのタイプを考慮する必要があります。ガイダンスが役に立つ場合は、2024年と2034年のトップ・リスクに関するエグゼクティブの視点、またはリスク管理の必須事項のポストにあるイベントのソースを検討してください。次のカテゴリに潜在的イベントを含めます:
クリティカルなプロセスの中断に対して時間ベースのイベントを定義すると、中断時間が長くなるほど影響スコアが高くなります。たとえば、「金融システムは10分間利用できません」というイベントの影響は、「金融システムは10時間利用できません」というイベントよりも低い場合があります。
影響スコアにビジネス・クリティカルさを適用
ここでは、拡張リスク算式を使用して、イベントごとに固有のリスク・スコアを生成します。ビジネスクリティカルなプロセスまたはシステムに影響するイベントの影響を2倍にし、クリティカルでないイベントの影響を1で乗算するとします。
説明するために、クリティカルな中断とクリティカルでない中断について同様のイベントを比較します。この例では、リスク管理方法では、0から10のイベント発生の可能性および影響値を使用します。両方のイベントに「3」の可能性と「5」の影響を割り当てると、拡張式はクリティカル・システムの固有リスクを「30」としてスコア付けします。これは、クリティカルでないシステム固有のリスク・スコアである「15」と比較します:
固有リスク = 発生の可能性 X (影響 X ビジネス重要度)
「クリティカル・システム2時間停止」イベント固有のリスク = 30
3 X (5 X 2) = 30
「非クリティカル・システム2時間停止」イベント固有のリスク = 15
3 X (5 X 1) = 15
既存のコントロールに基づいてリスク・スコアを調整
リスク管理手法では、ビジネスクリティカルなプロセスをサポートするシステムの有害事象の可能性または影響を低減する予防的および検出的制御を反映するように固有のリスク・スコアを調整することで、残存リスクを決定する必要があります。データ保護に焦点を当てたイベントの場合は、SOC 2 Trust Criteria、ISO 27001、US NIST 800-53、CISなどの業界標準で推奨される情報セキュリティ制御を活用します。
重要な財務システムのリスク・スコアを調整する例について説明します。次のタイプのセキュリティ制御が実施されている場合、残存リスクは軽減されます:
- 厳密なロールベースのアクセスは、「最小権限」アプローチを使用して強制されます
- ログイン(認証)資格証明およびその他の機密データは、伝送およびストレージで暗号化されます
- 適切なセキュリティ・ログの作成、監視、アクション
- システムは物理的にセキュアな場所にあり、アクセスが制限されています
- 週次バックアップと日次バックアップの両方が実行および検証され、バックアップからのリストアが定期的にテストされます
リスク・レベルとエグゼクティブ・リスクの許容度を一致
残存リスク・スコアがエグゼクティブ・ガイダンスを超える場合は、残存リスクが許容レベルになるように、潜在的イベントの発生の可能性または影響を変更する変更を実装します。最初にリスクが最も高いものから始めるか、いくつかの「簡単な勝利」を選択するか、これらのアプローチを組み合わせることができます。
推奨
Oracleは、ビジネスクリティカルなプロセスとサポート・システムのリスクをお客様が管理できるように、これらの提案とリソースを提供しています:
- NIST Risk Management Framework(RMF)、ISO 31000、またはEU ENISAのリスク管理フレームワークのリストに記載されているリスク管理手法を選択して実装します。
- 重要なプロセスとそのサポート・システムに注意しながら、リスク分析を定期的に実行します。プロセス、テクノロジー、ポリシー、買収または規制の変更については、これを最新の状態に保ちます。
- Oracle製品がビジネスクリティカルなシステムで使用される場合:
- セキュリティ・プラクティスを含むOracleのTrust Centerを探索し、ツアー・ビデオをご覧ください。
- OracleのCritical Patch Updates and Security Alertsに関する電子メール通知をサブスクライブします。