情報セキュリティにおけるリスク管理

ISRMの段階

特定

• 資産の特定：組織にとって最重要と見なされるのは、どのデータ、システムやその他の資産でしょうか？例えば、組織が最も大きな影響を受けるのは、どの資産の機密性、整合性または可用性が侵害された場合でしょうか？ソーシャルセキュリティ番号や知的財産といったデータの機密性が重要な理由は簡単に理解できます。しかし整合性はどうでしょうか？例えば、企業がSarbanes-Oxley（SOX）規制要件の対象となる場合、財務レポートのデータにおけるささいな整合性の問題が巨大なコストを発生させる可能性があります。または、組織がオンライン音楽ストリーミングサービスを提供していて、音楽ファイルの可用性が損なわれた場合、サービス加入者を失う可能性があります。
• 脆弱性の特定：資産の機密性、整合性と可用性に危険を及ぼすのは、どのシステムレベルまたはソフトウェアの脆弱性でしょうか？情報侵害の原因となる可能性があるのは、組織のプロセスにおけるどの弱点や欠如点でしょうか？
• 脅威の特定：資産または情報侵害の原因となる可能性があるのはどのような事項でしょうか？例えば、組織のデータセンターの所在地は、竜巻、洪水といった環境の脅威がよく発生する地域でしょうか？同一業界の企業は、既知の犯罪組織やハクティビストグループまたは政府に支援された団体によって頻繁に標的にされハッキングされているでしょうか？脅威モデリングは、既知の脅威とリスクを結び付け、脅威が脆弱性を悪用することでリスクを現実化するさまざまな方法を明らかにして、コンテキストを追加するのに役立つ重要な作業です。
• コントロールの特定：特定された資産を守るため、すでに導入されているものには何があるでしょうか？コントロールは、特定された脆弱性または脅威を完全に修正する（修復）またはリスクが現実のものとなる可能性やその影響を軽減する（緩和）ことで、脆弱性や脅威に直接的に対処します。例えば、解雇されたユーザーが特定のアプリケーションへのアクセス権を保持するリスクが見つかった場合は、ユーザーの解雇時に該当のアプリケーションからそのユーザーを自動削除するプロセスをコントロールとすることができます。代替コントロールは「安全ネット」のコントロールで、間接的にリスクに対処します。上記と同じ例で考えると、4半期ごとのアクセス権レビュープロセスを代替コントロールとすることができます。このレビューの際には、アプリケーションのユーザーリストを会社のユーザーディレクトリと解雇リストと相互参照して、必要のないアクセス権を持つユーザーを探し、見つかった場合には事後策として不正アクセス権を削除します。

アセスメント
これは、資産、脆弱性とコントロールについて収集した情報を組み合わせ、リスクを定義するプロセスです。このためのフレームワークとアプローチは数多くありますが、いずれにしても次の方程式に類たものを利用することになります。

リスク =（脅威 x 脆弱性（悪用の可能性 x 悪用の影響）x 資産価値）- セキュリティコントロール

注：これは、非常に簡素化された式の例です。残念ながら、確率論的リスクの計算はこれほど簡単なものではありません。

対応
リスクの評価と分析が完了したら、組織は対応オプションを選択する必要があります。

• 修復：元となるリスクを完全またはほぼ完全に修正するコントロールの実装です。
  例：最重要資産が保存されているサーバーで脆弱性が見つかった場合、その脆弱性に対するパッチを適用します。
• 緩和：リスクの可能性や影響を軽減しますが、完全には修正しません。
  例：最重要資産が保存されているサーバーで脆弱性が見つかった場合、脆弱性のパッチを適用する代わりに、脆弱性のあるサービスとの通信を特定のシステムのみに許可するファイアウォール規則をサーバー上で実装します。
• 移転：リスクが現実化して発生したコストを組織が回収できるよう、リスクを別のものに移転します。
  例：脆弱なシステムが悪用された際に発生するあらゆる損失を補償する保険を購入します。（注：これは、リスクの修復と緩和を補完するのに利用するべきもので、修復と緩和を完全に置き換えるものではありません。）
• リスクの受け入れ：リスクの修正を行いません。これは、明らかに低リスクで、リスクが現実化した場合に発生するコストよりも、修正に必要な時間と労力の方が大きい場合に適切な対応です。
  例：サーバーの脆弱性が見つかったものの、サーバー上には機密情報がないことがわかりました。他の最重要資産にアクセスするエントリーポイントとしてこのサーバーを利用することは不可能で、その脆弱性の悪用を成功させるのは非常に複雑です。このため、この脆弱性を修正するために時間とリソースを費やす必要はないと判断します。
• リスク回避：特定されたリスクへのエクスポージャーをすべて排除します。
  例：間もなくサポートが終了し、作成者からのセキュリティパッチを受け取ることができなくなるオペレーティングシステム（OS）で稼働しているサーバーが見つかりました。これらのサーバーは機密データと機密でないデータの双方を処理、保管しているので、機密データが侵害されるリスクを回避するため、機密データをすぐにパッチの適用が可能な新しいサーバーに移動しました。サーバー利用を停止し、機密でないデータを他のサーバーに移動する計画を立てる間、サーバーは機密でないデータの処理と実行を続けることができます。

コミュニケーション：
リスクに対してどのような対応をするにしても、その意思決定について組織内でのコミュニケーションを取る必要があります。ステークホルダーは、リスクに対応した場合と対応しなかった場合のコストと意思決定の背後にある合理性を理解する必要があります。義務と責任を明確に定義して、組織内の個人やチームに割り当てる必要があります。プロセス内の適切な時期に適切な人員が対応に取り組む必要があるためです。

同じ手順の繰り返し
：これは継続的なプロセスです。コントロールの実装が必要な対応計画を選択した場合、そのコントロールを継続的に監視する必要があります。このコントロールを導入するのは、経時的に変化し続けるシステムになります。ポートの開放、コードの変更やその他多数の要素によって、最初の実装後、数か月または数年の間にコントロールが壊れる可能性があります。

責任管理

ISRMプロセス内には数多くのステークホルダーが存在し、それぞれが異なる責任を持っています。このプロセスにおけるさまざまな役割と、各役割に関連した責任を定義することは、このプロセスの円滑な運用にとって最も重要なステップです。

プロセス責任者：ハイレベルで見ると、組織には企業リスク管理（ERM）プログラムの責任者である財務チームまたは監査チームがあるかもしれません。一方で、情報セキュリティまたは情報保証チームが、ERMにフィードを送るISRMプログラムの責任者となっているかもしれません。このISRMチームは現場で常にプロセスを実践する必要があります。

リスク責任者：個々のリスクについては、問題修正のための費用を予算から支払うことになる組織のメンバーが責任者となるべきです。つまり、リスク責任者は、リスクに対する適切な対応が確実に行われるようにする責任があります。予算を承認したら、リスクに対する責任を負うことになります。

リスク責任者に加えて、選ばれた対応計画に影響を受けたり、対応計画の実装に関与することになるシステム管理者、エンジニア、システムユーザーなど他のタイプのステークホルダーもいます。

例えば、情報セキュリティチーム（プロセス責任者）はISRMプロセスを実践します。企業の顧客関係管理（CRM）システムの可用性へのリスクが見つかった場合、プロセス責任者は、IT責任者（CRMシステム責任者）とこのシステムを日常的に管理するIT担当者（CRMシステム管理者）と連携してリスクの評価に必要な情報を収集します。

CRMソフトウェアが導入されたのは、企業の販売部門が有効利用できるようにするためで、CRMソフトウェア内のデータが利用できなくなると最終的には販売に影響を及ぼすと仮定した場合、販売部門責任者（最高販売責任者など）がリスク責任者となります。リスク責任者は、情報セキュリティチーム、システム管理者、システム責任者などが提供する異なる対応計画の実装について意思決定を行い、残るリスクを受け入れる責任があります。しかし、対応計画を実装することになった場合、システム責任者とシステム管理者は再び関与することになると考えられます。日常的にCRMソフトウェアを利用する販売担当者などのシステムユーザーも、あらゆる対応計画によって影響を受ける可能性があるため、このプロセスのステークホルダーとなります。

リスクの管理は継続的な作業であり、その成功は、リスクの評価、計画のコミュニケーション、そして役割の遂行がどれほど適切に行われるかに依存します。最重要な人員、プロセスとテクノロジーを特定して前述の手順に対応することで、組織におけるリスク管理戦略とプログラムのための堅牢な土台を構築することが可能で、その後、時間をかけてさらに発展させることもできます。