セキュリティ管理のメモ帳

セキュリティに関する備忘録

情報セキュリティリスクマネジメントについて(9)

ー6.リスクコミュニケーションー

はじめに

 情報セキュリティリスクマネジメントのリスクコミュニケーションプロセス(図中の赤枠部分)について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図1 リスクマネジメントプロセス上の リスクコミュニケーション の位置付け

 注)なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。(誤りに気付いた方は、コメントいただけると幸いです)

1)リスクコミュニケーションとは

 先ずはリスクコミュニケーションで実施すべきこと、考慮すべきことを理解するために、JIS Q 27000:2019 に記載されている用語の定義を確認します。

JIS Q 27000:2019 から引用

3.65 リスクコミュニケーション及び協議(risk communication and consultation)
 リスクの運用管理について、情報の提供、共有又は取得、及びステークホルダーとの対話を行うために、組織が継続的に及び繰り返し行う一連のプロセス。
 注記1 情報は、リスクの存在、特質、形態、起こりやすさ、重大性、評価、受容可能性及び対応に関係することがある。
 注記2 協議とは、ある事柄に関する意思決定又は方向性の決定に先立って、組織とそのステークホルダーとの間で行われる、その事柄についての情報に基づいたコミュニケーションの双方向プロセスである。協議とは、次のようなものである。
 − 権力によってではなく、影響力によって、意思決定に影響を与えるプロセスである。
 − 共同で意思決定を行うことではなく、意思決定に対するインプットとなる。

 実施すべきことを具体的に考えるため、上記の内容を元に5W1Hの観点で整頓します。

① 実施者(誰が)
 リスク所有者(リスクの運用管理に責任を有する者)
② 実施目的(なぜ)
 リスクを運用管理するため
③ 実施時期(いつ)
 継続的に繰り返し行う
④ 実施対象(どこと)
 利害関係者(ステークホルダー
⑤ 実施内容(何を)
 情報(主にリスクの存在、特質、形態、起こりやすさ、重大性、評価、受容可能性及び対応に関係する)
⑥ 実施手段(どのように)
 情報の提供、共有又は取得、及び対話により行う

 上記6項目について、次項で具体的に考えてみます。
 ※)本稿では、利害関係者という用語が頻発しますが、用語の前に”内部”や”外部”という言葉がない場合は、組織内外全ての利害関係者を意味します。

2)具体的な実施方法

2-1)実施者(誰が)

 ここでは、だれがリスクコミュニケーションを管理すべきかについて考えてみます。
 リスクコミュニケーションは、前項で確認したその用語定義の冒頭に記載されている通り、「リスクの運用管理」の一部として実施されると解釈できます。
 次のように、リスクの運用管理責任は、リスク所有者が有していますので、リスクコミュニケーションについても同様にリスク所有者が実施すると判断できます。

JIS Q 27000:2019 から引用

3.71 リスク所有者(risk owner)
 リスクを運用管理することについて、アカウンタビリティ及び権限をもつ人又は主体。

 リスク所有者は、状況の設定プロセスで決定されます。詳細については過去ブログにて確認できます。

blg8.hatenablog.com

2-2)実施目的(なぜ)

 リスクコミュニケーションの実施目的はリスクを運用管理するためです。
 さらに掘り下げて考えるためには、リスク所有者の役割について理解する必要があります。
 リスクを運用管理するために、リスク所有者が実施すべきことには次のようなものが考えられ、それがコミュニケーションを実施する目的となります。

① リスクに関し正確な意思決定を行う

 リスク所有者個人(委任される実施責任者も含め)は、自身の専門領域の知見に基づくリスクの特定及び理解はできますが、例えば、ビジネスリスク、財務リスク、セキュリティリスクなどの様々なリスクの影響全てに対し同じように特定できることは稀です*1
 また、法的要件のようなコンプライアンスに関する判断をする際にも専門知識が必要です。特に社会的な要件については判断が難しいケースがありますので、そのような場面では外部の専門家の意見が判断材料として効果的に働くことがあります。
 リスク所有者は、コミュニケーションにより次のような情報を得ることで効率的に正確な意思決定を行うことができます。

  • 利害関係者が有する異なった領域の専門知識
  • 利害関係者からの要求、ニーズ、期待
  • 実施責任者からの報告(各プロセスで得られた意思決定を支援する情報)
② リスクを監視する

 リスク対応で実装される管理策の中には、例えば、要員との雇用契約就業規則、教育など人的管理策を人事部、マルウェア対策、技術的脆弱性管理などの技術的管理策をシステム運用部というように効率的に運用するために共通管理策として専門部署により一括管理されていることが多くあります。
 このような状況下で、業務プロセス所有者がリスク所有者に就く場合、個々の管理策の有効性(例えば、上記例では、リスク所有者の管理下にある要員のセキュリティリテラシーやPCに対する脆弱性対応の実施状況など)を監視し、それに不備があれば共通管理策の管理を行う専門部署に是正を要求することでリスクの運用管理に責任を持ちます。
 リスク所有者は自らのアカウンタビリティを確保するために、専門部署とのコミュニケーションにより各管理策の有効性を確認できる情報を入手し、監視しなければなりません。

③ 利害関係者と認識を共有する

 例えば、リスク所有者に業務プロセス所有者が就く場合は自部署の業務の重要度を重めに考えたり、セキュリティ統括組織が就く場合はセキュリティが最優先されるなど無意識のバイアスが様々な判断に影響し、組織全体で考えるとリスクの運用管理が最適な状態にならない可能性があります*2
 また、コンプライアンス要件を含む利害関係者からの要求、ニーズ、期待を誤って理解してしまっている場合、誤った方向性でリスクの運用管理が継続されます。
 リスク所有者は、次のような内容に関し自らの判断とリスクの影響を受ける利害関係者の認識にギャップがないことをコミュニケーションにより解消し、必要に応じ合意を得なければなりません。

  • リスク基準やリスク受容などの重要な判断を下す際には利害関係者の異なった見解を考慮する
  • リスクアセスメントの結果やリスク対応計画の情報を利害関係者に提供し、セキュリティ要件に対する充足度を確認する
  • リスクアセスメントの結果やリスク対応計画の情報を内部の利害関係者に提供し、対応のために必要なリソースを報告する
  • 管理策の実施部署へ、リスク監視結果のフィードバックと必要に応じ是正を依頼する

 インシデント発生時に利害関係者と情報を共有することは多くの組織で実施されていますが、リスクアセスメント時に想定される事象とその対応方法について事前に協議(合意)しておくことにより、事後対応はスムーズに行え、損害の発生も低く抑えられる可能性があります。

④ 利害関係者の協力を得る

 上記のように、リスクを運用管理するためには多くの場面で利害関係者の協力が不可欠です。協力及び支持を得るためには日常的に情報を共有するためのコミュニケーションが欠かせません。

⑤ 利害関係者からの信頼を得る

 JIS Q 27001:2014 (ISO/IEC 27001:2013)の序文には、「リスクを適切に管理しているという信頼を利害関係者に与えるため」との一文があり、これをISMSの実施目的と解釈することができます。この実施目的についてはリスク所有者ではなくマネジメントに責任がありますが、リスクコミュニケーションに係る内容となるため触れておきます。
 最近、有価証券報告書でサイバーセキュリティ関連のリスク対策、ガバナンス体制などについて開示する企業が増えています。また、サステナビリティ報告者やセキュリティ報告書のような特化したレポートによる公開も同様です。このような取り組みは利害関係者からの信頼を得るために実施されているリスクコミュニケーションの一例と言えると思います。

2-3)実施時期(いつ)

 リスクコミュニケーションは図1に示されている通り、リスクマネジメント全般に関わるプロセスであり、継続的に繰り返し行います。
 各プロセスでは、次のようなコミュニケーションが考えられます。

① 状況の設定プロセス

 リスク基準などの情報セキュリティリスクマネジメント方針を策定する前に、コンプライアンス要件を含む組織内外の状況を十分に理解するため、また必要に応じ、策定後には、その内容について理解及び合意を得るために利害関係者とのコミュニケーションが必要です。

② リスク特定プロセス

 リスクの特定漏れを防ぐためには、組織内外の状況と課題を網羅的に把握することが不可欠であるため利害関係者とのコミュニケーションを確立し、情報を収集します。

③ リスク分析プロセス

 リスク分析手法を含め、分析に有用な専門知識を組織内外を問わず集約することでより正確な結果が得られます。

④ リスク評価プロセス

 リスク所有者が下したリスク評価結果(特に受容と判断したリスク)の妥当性について利害関係者の意見を集約し、調整の要否を判断します。

⑤ リスク対応プロセス

 リスク対応計画のスピード感の確認や必要なリソースの調達のための承認には、利害関係者とのコミュニケーションが欠かせません。

2-4)実施対象(どこと)

 実施対象は、利害関係者です。具体的に内部と外部に分けてあげると次のようになります。

① 内部の利害関係者
  • 要員
  • 他部署
  • トップマネジメント
  • 対外的な窓口(法務、営業、広報、セキュリティ)
② 外部の利害関係者
  • 行政府・公的機関
  • 業界団体
  • 情報共有機関(ISAC、ISAOなど)
  • 顧客
  • 業務委託先

 コミュニケーションすべき、外部の利害関係者に関しては、下記リンクの過去ブログにて触れていますので参考になると思います。

blg8.hatenablog.com

blg8.hatenablog.com

③ 留意事項

 組織内の脆弱性など、それを知ることで、脅威アクターに有利になったり、脅威の起こりやすさに影響を及ぼすような性質を持った情報を共有する場合はその共有対象を慎重に選ばなければなりません。リスクコミュニケーションにおいても、セキュリティの原則である「知る必要性」を適用し、必要な相手に限定し情報を共有します。

2-5)実施内容(何を)

 コミュニケーションの内容は、主にリスクの存在、特質、形態、起こりやすさ、重大性、評価、受容可能性及び対応に関係する情報です。
 具体的には2-2)、2-3)項で述べた内容です。

2-6)実施手段(どのように)

 情報の提供、共有又は取得、及び対話によりコミュニケーションを行います。
 例えば、対面によるヒアリングや集合型会議、電子メール(メーリングリスト)、Webサイト上の投稿機能、アンケート(記名、無記名)、チェックシートによるセルフチェック結果の集約、Webサイト上での告知、マスコミを経由した公表など様々な手段が考えられます。
 情報の内容、コミュニケーションの実施対象により、最適な手段は異なりますので、多様なチャンネルを設けることで対応します。

2-7)その他(委員会組織によるコミュニケーション)

 組織の規模が大きくなると、特に縦割り組織の場合はコミュニケーションを円滑にするために全社横断的な横串機能として各部署の代表者により構成されるセキュリティ管理委員会あるいはその上位のリスク管理委員会が設けられていることがあります。
 委員会を設置することで、他にも共通管理策の実装によるリスク所有者のリスク運用管理の軽減、リスク基準の標準化や部署間の整合などの効果も期待することができます。
 委員会機能を通じたリスクコミュニケーションの実施例を下図に示します。

図1 委員会機能を利用したリスクコミュニケーションの例

まとめ

 今回はリスクコミュニケーションについて具体例を交え考察しました。
 セキュリティリスクマネジメントの形骸化とリスクコミュニケーション不足には、深い関係があると筆者は感じています。例えば、本文で紹介した委員会機能にしても、実際には事務局が全て抱え込んでしまいコミュニケーションが機能していない例を見ることがあります。そのような状態では、リスクアセスメントやリスク対応のための判断や決定の根拠となる情報が不足することで誤った対応をする可能性があります。また、情報が共有されていない場合は、不在時に各種対応が滞ることも考えられます。
 また、最近、発生しているインシデントからは、システムの運用業務の委託など、サプライチェーン上の利害関係者との間で曖昧に責任共有(責任境界)が決まられており、セキュリティ要件が明確になっていなかったり、必要な管理策が実装されていなかったことに起因するものが多くみられます。これもリスクコミュニケーションが不足している事例と言って良いと思います。
 リスクコミュニケーションはリスクマネジメントの質を高め、かつ、組織全体として活動するためには不可欠なプロセスです。

参考資料

 本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

  • ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • JIS Q 27000:2019 情報技術−セキュリティ技術-情報セキュリティ マネジメントシステム-用語
  • JIS Q 27001:2014 情報技術−セキュリティ技術-情報セキュリティマネジメントシステム-要求事項

脚注

*1:本稿が、セキュリティリスクマネジメントをテーマとしているため、他のリスクが登場することに違和感を感じることもあると思いますが、実際の組織運営では、セキュリティのみ、又はセキュリティを最優先することはあり得ないため、他のリスクとのバランスが求められます。

*2:リスク所有者に対し、組織全体を俯瞰し客観的にリスクを最適なバランスで運用管理する、言ってみればリスクの全体最適を理想として求めるとトップマネジメントが適任ですが、個々のリスクの運用管理まで実施することは難しく、方針による戦略レベルの方向付けを示すまでが現実的だと思います。

情報セキュリティリスクマネジメントについて(8)

ー5.モニタリング及びレビューー

はじめに

 情報セキュリティリスクマネジメントのモニタリング及びレビュープロセス(図中の赤枠部分)について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図1 リスクマネジメントプロセス上の モニタリング及びレビュー の位置付け

 注)なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。(誤りに気付いた方は、コメントいただけると幸いです)

1)モニタリング及びレビューとは?

 先ずはモニタリング(監視)及びレビューで実施すべきこと、考慮すべきことを理解するために、JIS Q 27000:2019 に記載されている用語の定義を確認します。

JIS Q 27000:2019 から引用

3.46 監視(monitoring)
 システム、プロセス又は活動の状況を明確にすること。
 注記 状況を明確にするために、点検、監督又は注意深い観察が必要な場合もある。

3.58 レビュー(review)
 確定された目的を達成するため、対象となる事柄の適切性、妥当性及び有効性を決定するために実行される活動。

 モニタリング及びレビューは、確定された目的を達成するために、システム、プロセス又は活動の状況を明確にし、対象となる事柄の適切性、妥当性及び有効性を決定するプロセスです。
 ※)ISMS(ISO/IEC 27001:2013)では、箇条9のパフォーマンス評価に相当するプロセスです。

 次項では、上記の内容をより具体的に考えてみたいと思います。

2)具体的な実施例

 前項で述べた確定された目的とは、組織のセキュリティ方針及びセキュリティ目的により決定されますが、情報セキュリティリスクマネジメント本来の実施目的から考えると次のようなものを上げることができます。

  • セキュリティリスクを適切にコントロールするため
  • 組織が定めるセキュリティ目的を達成するため
  • リスクを適切に管理しているという信頼を利害関係者に与えるため

 上記を更に具体的に考えると、例えば、セキュリティリスクを適切にコントロールするためには、刻々と変化するリスクの発生や変質を時機を失さずに適切に捉えるための継続的なモニタリングとその結果のレビューが求められます。
 また、組織が定めるセキュリティ目的を達成するためには、リスクマネジメントの有効性が確保されていることを確認するためのモニタリングとレビューが欠かせません。
 リスクを適切に管理しているという信頼を利害関係者に与えるためには、リスクモニタリングとレビューにより適切な情報を利害関係者に提供する必要があります。
 ここまでの内容を図にまとめると次のようなイメージになります。

図 リスクモニタリングとレビューのイメージ

2-1)セキュリティリスクを適切にコントロールするため

 前述のように、リスク及びリスクに影響を及ぼす組織の内外の状況は常に変化し続けています。その変化の理解はリスク特定プロセスで実施されるため、リスクモニタリングとレビューも同プロセスで実施されることが多くなります。
 具体的には、次のような実施内容が含まれます。

① 脅威の検知

 システムやサービスのログ、ネットワークのトラフィックなどを継続的にモニタリングし、不正アクセスや攻撃者の侵入の兆候*1を検知することで、迅速な対応ができます。同様に、不審なメールの送信元や内容をモニタリングし、要員の教育・訓練に反映させることでフィッシングなどの脅威を未然に防ぐことができます。
 また、脅威検知の結果はレビューされることで、アラート条件のチューニングに反映させることができます。

脆弱性の特定

 システムやアプリケーションの脆弱性を定期的にスキャンし、既知の脆弱性の有無を確認することで、攻撃を受ける前に脆弱性を修正することができます。また、人的な脆弱性の状況についても内部インシデントの発生状況、不審なメールに対する訓練結果などをモニタリングすることで把握することができます。

③ 脅威情報の収集

 情報共有分析センター(ISAC)や監督官庁、同業者、セキュリティベンダーなどから得られるTTPsの傾向などのセキュリティ情報を継続的に収集し、最新の脅威を理解することで、新たな脅威に対する対策を早期に準備することができます。

脆弱性情報の収集

 公的な公開サイトやソフトウェアベンダーのサイトから定期的に脆弱性情報を収集することで、早期に対応することができます。

⑤ 法・規制情報の収集

 関連法令や規制などの改定状況をモニタリングすることで、コンプライアンス違反の発生を防ぐことができます。

⑥ 組織内外のインシデント

 組織内外のインシデントから得られる情報は、脅威を早期に検知するために有用であると同時に、自組織のリスクアセスメントの検証にも役に立ちます。具体的には、リスクシナリオに基づきアセスメントした結果と実際に起こったインシデントの結果を比較することにより、リスクアセスメントの検証及び改善が可能になります。

 上記以外にもリスクに影響を与える組織及びその内外の状況の理解に関し、継続的なモニタリングによるリスク特定が必要です。

blg8.hatenablog.com

 このリスクモニタリングの実施は、OODAループにより時期を失さずに実施することが多くなると思われます。過去ブログで紹介した運用サイクルでのリスクアセスメントの実施方法が参考になります。

blg8.hatenablog.com

 リスクの運用管理の一部として実施されるため、一般的には、リスク所有者がその責任(アカウンタビリティ)を有します。  

2-2)組織が定めるセキュリティ目的を達成するため

 セキュリティ目的を達成するためには、リスクマネジメントが有効に機能し、適切な結果が得られることが前提となります。
 リスクマネジメントの各プロセス又は結果におけるモニタリング及びレビューを実施することでその活動の有効性を検証でき、更には次のプロセス又はマネジメントサイクルの改善につなげることができ、結果の精度が向上します。
 セキュリティリスクマネジメントの精度向上を目的とした次のような各プロセスにおけるモニタリングが考えられます。

① 状況の設定プロセス

 セキュリティ目的に影響を与える組織内外の変化(例えば、上位方針、事業内容、保有資産など)をモニタリングすることで、組織が置かれている状況を反映したセキュリティ目的を維持することができます。

② リスク特定プロセス

 前項で述べた通り、セキュリティリスクを適切にコントロールするためには、時機を失さずに組織及びその内外の状況を理解しなければなりません。そのためには組織内外の様々な変化をモニタリングすることが必要です。

③ リスク分析プロセス

 リスク分析時のインプット情報や手法に関する最新の情報をモニタリングすることで、分析結果の精度は向上します。

④ リスク評価プロセス

 実際に起きた結果とリスク評価(リスクアセスメント)により予測された結果を比較検証することで、次回以降のリスクアセスメントの改善に役立てます。

⑤ リスク対応プロセス

 リスク対応において実施した各種管理策の有効性を確認することで、もし、期待通りの効果が得られていない場合には、早期に代替、追加管理策の実施により補うことができます。更に、有効性確認から得られた結果を次回のリスク対応プロセスに適切に反映することでリスクマネジメントの精度を向上することができます。
 また、リスク対応時に、期間限定的にリスク保有することを決めたリスクに関してはモニタリングを継続し、もし、そのリスクに変質が見られるような場合は、早期に代替、追加管理策の実施により補うことが必要です。

 このリスクモニタリングは、PDCAサイクルによる継続的な改善の一部として実施されることが多くなると思われます。過去ブログで紹介した戦略サイクルでのリスクアセスメントの実施方法が参考になります。

blg8.hatenablog.com

 リスクの運用管理の一部として実施されるため、一般的には、リスク所有者がその責任(アカウンタビリティ)を有しますが、ISMSの箇条9のパフォーマンス評価の一部として実施される場合は、マネジメントが就く可能性もあります。
 マネジメントの責任については、過去ブログが参考になります。

blg8.hatenablog.com

2-3)リスクを適切に管理しているという信頼を利害関係者に与えるため

 リスクを適切に管理しているという信頼を利害関係者に与えるためには、適切なリスクモニタリングとレビューから得られた正確な情報による円滑なリスクコミュニケーションが欠かせません。適切にリスクモニタリングされた結果を利害関係者に提供することで次のような効果が得られます。

① 内部利害関係者

トップマネジメントに対して
 例えば、リスクモニタリングにより得られたリスクの状況や変化を確認し、レビューにより有効性や妥当性を確認することで正確な情報をタイムリーに共有できるため、組織のリスクマネジメントに対する理解を深め、支援や協力を得られやすい環境が構築されます。
要員に対して
 リスクモニタリングとレビューを実施しその結果を可視化することで、セキュリティリスクに対する意識を高め、組織全体でセキュリティ対策に取り組むことができます。

② 外部利害関係者

 最近では、外部の利害関係者向けのセキュリティレポートの中でリスクアセスメントやリスクレイティングの結果を公表する組織が増えています。これも利害関係者からの信頼を得るために実施されていると理解できます。

まとめ

 今回はリスクモニタリングとレビューについて考察しました。本文でも述べましたが、リスク及びリスクに影響を与える組織内外の状況は常に変化しており、その変化に対応し続けるために、リスクのモニタリングとレビューを継続的に実施します。
 その実施により、「リスクの変化の早期検知と対応」、「リスクマネジメント全体の継続的な改善」、「利害関係者との円滑なリスクコミュニケーション」など複数の効果が得られると考えます。
 リスクモニタリングを形骸化させないためには、利害関係者がリスクは変化しており、以前行ったリスクアセスメントの結果が常に有効であるとは限らないことを認識する必要があります。そのためには、リスクモニタリングの計画を明らかにし、その成果を可視化し共有することが有効と思われます。
 本文では、触れていませんがモニタリングの内容、頻度は状況の設定プロセスで決定しますが、その内容についてもリスクの変化に応じ柔軟に対応することで変化に追従することが可能になります。

参考資料

 本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

  • ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • JIS Q 27000:2019 情報技術−セキュリティ技術-情報セキュリティ マネジメントシステム-用語
  • JIS Q 31000:2019 リスクマネジメント−指針
  • JIS Q 27001:2014 情報技術−セキュリティ技術-情報セキュリティマネジメントシステム-要求事項

脚注

*1:事前にリスクシナリオに基づきトリガー条件(MITRE ATT&CKのDetectionにあたる内容)を設定します。代表的な事象としては、ネットワークトラフィックの上昇、異常なファイル変更、認証エラーの頻発などがあげられ、広義には、物理的監視や監査なども含まれます。

情報セキュリティリスクマネジメントについて(7)

ー4.リスク対応ー

はじめに

 情報セキュリティリスクマネジメントのリスク対応プロセス(図中の赤枠部分)について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図1 リスクマネジメントプロセス上の リスク対応 の位置付け

 注)なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。(誤りに気付いた方は、コメントいただけると幸いです)

1)リスク対応とは

 先ずはリスク対応プロセスで実施すべきこと、考慮すべきことを理解するために、JIS Q 27000:2019 に記載されている用語の定義を確認します。

JIS Q 27000:2019 から引用

3.72 リスク対応(risk treatment)
 リスクを修正するプロセス。
 注記1 リスク対応には、次の事項を含むことがある。
 − リスクを生じさせる活動を、開始又は継続しないと決定することによって、リスクを回避すること
 − ある機会を追求するために、リスクをとる又は増加させること
 − リスク源を除去すること
 − 起こりやすさを変えること
 − 結果を変えること
 − 一つ以上の他者とリスクを共有すること
 (契約及びリスクファイナンシングを含む。)
 − 情報に基づいた選択によって、リスクを保有すること
 注記2 好ましくない結果に対処するリスク対応は、“リスク軽減”、“リスク排除”、“リスク予防”及び“リスク低減”と呼ばれることがある。
 注記3 リスク対応が、新たなリスクを生み出したり、又は既存のリスクを修正したりすることがある。

 リスク対応プロセスでは、リスクアセスメント(リスク評価)により対応が必要と判断したリスクへの対応を行います。その対応は、原則、対象となるリスクのリスクレベルが受容基準に適合するまで繰り返し行われ、実施内容には次のような内容が含まれます。

  • リスク対応の種別の選択と実施又は強化する管理策の選択
  • リスク対応計画の策定
  • リスク対応による効果の確認

 上記、各項目に関する具体例を次項以降で考えたいと思います。

2)具体的な実施方法

2-1)リスク対応方針の決定

 ここでは、各リスクへの対応方針を決定します。一般的には次のような選択肢から手法を選びます。

表1 リスク対応の選択肢

 各手法に関し、具体例により補足します。

① リスクを生じさせる活動を開始又は継続しないと決定することによってリスクを回避する

 インシデント発生時に大きな損害が予想される情報の取扱いが必要となる事業に参入しない、又は撤退することです。
 狭義には、組織内ルールや技術的対策による制限により脅威となる行為を禁止することもリスク回避に分類できると思います。最近では稀なケースだと思いますが、例えば、クラウドサービスやリモートワークを禁止にするなどセキュリティを優先するあまり業務効率が低下する可能性があることにも留意が必要です。

② ある機会を追求するために、リスクを取る又は増加させる

 セキュリティに限定して考えると適切な事例を思いつきませんが、事業、業務に好影響を与えるという観点で考えると、上述のような、リモートワークによる要員のワークライフバランスの向上を目的とする環境整備は、セキュリティ上のリスクが増加する傾向があるため、このケースに当てはめることができますし、積極的なクラウドサービスの利用による業務効率化もセキュリティリスクにプラスとマイナスの両面で変化をもたらすことが予測されます。

③ リスク源を除去する

 ソフトウェアの脆弱性を悪用した攻撃を想定した場合、更新やセキュリティパッチを適切に行うことでソフトウェアの脆弱性というリスク源を除去することができます。また、故障する可能性の高い老朽化した支援資産を廃棄することも可用性に関連するリスク源の除去と言えます。

④ 起こりやすさを変える

 マルウェア検出・修復ツールを導入することで、既知のマルウェアから保護できる可能性が高く、感染の起こりやすさは低くすることができます。

⑤ 結果を変える

 外部に漏洩すると組織に大きな影響を与えるデータを事前に暗号化しておくことで、万が一、それが脅威アクターの手に渡ったとしても価値のないものになりますし、バックアップの実施自体は、事象の起こりやすさを低減するものではありませんが、復旧が可能になりますので事象発生後の結果を変えることができます。

⑥ (例えば、契約、保険購入によって)リスクを共有する

 サイバーセキュリティ保険へ加入することにより、インシデント発生時の損害を補填できます。ただし、二次損失や金額以外が補填されない可能性があることを考慮しなければなりません。

⑦ 情報に基づいた意思決定によって、リスクを保有する

 対象リスクのリスクアセスメント結果がリスク受容基準を大きく超えてはおらず、リスク対応の時点で、適当な費用対効果の管理策が無い場合などはリスクをそのまま保有することがあります。その場合は、保有する期間を明らかにし、リスクの変質を監視するなどの特別な管理対象とすることも検討が必要です。
 詳しくは過去ブログで説明しています。

blg8.hatenablog.com

2-2)管理策の採否と優先度の決定

 リスク対応方針に従い、必要となる全ての管理策を決定します。
 具体的には、既に実施している管理策の強化、又は未実施の管理策を組織内のベースライン管理策、若しくは汎用ベースラインカタログから選択することになりますが、その中に適切な管理策が見つからない場合は、組織独自の管理策を実装することになります。
 ベースライン管理策については下記ブログが参考になります。

blg8.hatenablog.com

 ベースライン管理策から選択するといっても、数多くの管理策の中から選ぶのは難しいと思います。
 そのような時は、根拠のある考え方を時間をかけずに得ることができるという点でベストプラティクスに頼ることも選択肢の一つです。汎用ベースラインカタログの中には、様々な観点でレベル分けし、その個々のレベルに対し実装すべき管理策が提示されているものがあります。今回は、その中から3件紹介します。

  • 組織に及ぼす影響度によるレベル分け(NIST SP800-53B)
  • 組織の規模によるレベル分け(CIS Controls)
  • 管理策の費用と効果によるレベル分け(CISA CPGs)
① 組織に及ぼす影響度によるレベル分け(NIST SP800-53B)

 リスクマネジメントの原則から考えると、リスクが顕在化した時のその結果が組織に与える影響の大きさにより管理策の採否及び優先度を決めることは最も合理的と言えると思います。
 FIPS PUB 199は、リスクが顕在化した場合にその結果が組織の保有する情報及び情報システムに与える影響の度合いに応じ「低位」、「中位」、「高位」の3段階に分類することを規定した文書です。NIST SP800-53Bではその各分類で実装すべき管理策が提示されています。
 概要を表にまとめると次のようなイメージで、中位は低位を、高位は中位をそれぞれ包含する構造になっています。

表2 FIPS PUB 199による分類例とNIST SP800-53Bにより適用される管理策の数

② 組織の規模によるレベル分け(CIS Controls)

 いざ、管理策を実装することを決めても、その運用のための体制(例えば、導入費用、維持費用、運用のための人員など)が組織内で確保できない場合、無駄なものになってしまいます。
 CIS Controlsでは、組織の規模により、保護すべき対象や想定される脅威が異なるとの考え方で、全ての組織が適用すべきサイバー防御の基本的な管理策(基本的なサイバーハイジーン)と定義されているIG1からIG2、IG3と3段階に分類され、個々のレベルに応じ実装を推奨する管理策が提示されています。
 概要を表にまとめると次のようなイメージで、IG2はIG1を、IG3はIG2をそれぞれ包含する構造になっています。

表3 CIS Controlsによる分類例と推奨される管理策の数

③ 管理策の費用と効果によるレベル分け(CISA CPGs)

 セキュリティに関する個々の管理策の費用対効果の算定は、実施者により差が生じることが多いと思います。それは、効果の部分をどのように解釈するかによって結果が変わるからです。このことがセキュリティツール(ソリューション)を導入する際の妥当性の検討や承認を得る際の説明などを困難にしている原因となっていることも多いと思います。
 下表のように費用と効果に言及しているベースラインカタログがありますので一部、紹介します。

表4 CISA CPGsによる各管理策の比較

 上表は、米国サイバーセキュリティーインフラストラクチャー・セキュリティー庁(CISA)により、発行されているベースラインカタログで「サイバーセキュリティー・パフォーマンス・ゴールズ(CPGs)」と呼ばれる8カテゴリー、37の管理策を提示しているガイドラインと、その別紙として発行されている実施状況を確認するためのチェックリストマッピングしたものです。
 それぞれの管理策について、COST(費用)、IMPACT(効果)、COMPLEXITY(複雑さ)が示されています。COST($の数)が少なく、IMPACTが高く(HIGH)、COMPLEXITYが低い(LOW)項目が費用対効果が高い管理策と判断することができます。(黄色で網掛けした14管理策が対象です)
 まず、組織内で上記の14管理策の実施状況を確認し、実施しておらず容易に実施可能なものがあれば優先して対応することで費用対効果の高いリスク対応が可能になります。

 各リスクに対応するための管理策は複数選択されることが多いため、リスク対応の効果を見積もるためには各管理策間の相互作用や補完性を考慮した管理策全体としてのケイパビリティを把握することが必要になります。
 例えば、管理策を多層的に実装することでリスク対応能力は向上します。多層防御については下記ブログが参考になります。

blg8.hatenablog.com

2-3)リスク対応計画の策定

 適切にリスク対応が実施されるように次の情報を含むリスク対応計画により進捗を管理します。

① 対応の実施完了日

 原則はリスクアセスメント時に決定したスピード感、優先順で対応することになりますが、もし変更する場合には、その理由を明らかにします

② 対応計画の承認者

 通常は各リスクのリスク所有者が務めます

③ 実装又は強化する管理策

 実装又は強化する管理策を全て書き出します
 個々のリスクに対し適切に管理策を実装するため、組織内のベースライン管理策、若しくは汎用ベースラインカタログから選択する場合はその参照元を、独自の管理策を実装する場合はその管理策の定義を詳細に対象リスク毎に決定し記録します

④ 対応後のリスクレベル

 全ての管理策が実装された後のリスクレベルを予測します

⑤ 管理策の実施責任者

 管理策実装の実施責任を有する者を明らかにします

⑥ 必要となるリソース

 設備、人、クラウドサービスなど管理策実装のために必要なリソースを書き出します

⑦ 実施状況

 定期的な進捗確認ができるように実施状況を明らかにします

2-4)リスク対応による効果の確認

 リスク対応完了後に、再度リスクアセスメントを実施しリスクレベルを確認し、その結果がリスク受容基準を超えている場合は、再度、リスク対応を実施します。

まとめ

 今回はリスク対応について考えてみました。
 リスクを適切にコントールするためにはリスク対応により意図した結果が得られなければならないため、リスク対応の方向性、選択される管理策はリスクマネジメント全体に大きな影響を与えます。
 また、計画時に期待していた効果が実際には得られないこともありますので、その場合は、他の管理策の実施などにより受容できるまでリスク対応を繰り返すことになります。更にリスク対応により得られた結果は、リスクアセスメント結果や計画時に試算した効果と比較することで次回のリスクマネジメントサイクルの改善に活かすことができます。

参考資料

 本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

  • ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • JIS Q 27000:2019 情報技術−セキュリティ技術-情報セキュリティ マネジメントシステム-用語
  • JIS Q 27001:2014 情報技術−セキュリティ技術-情報セキュリティマネジメントシステム-要求事項
  • Federal Information Processing Standards Publication 199
  • NIST SP800-53B Control Baselines for Information Systems and Organizations
  • CIS Controls Ver. 8
  • CISA CROSS-SECTOR CYBERSECURITY PERFORMANCE GOALS

脚注

情報セキュリティリスクマネジメントについて(6)

ー3.3.リスク評価ー

はじめに

 情報セキュリティリスクマネジメントのリスク評価プロセス(図中の赤枠部分)について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図1 リスクマネジメントプロセス上の リスク評価 の位置付け

 注)なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。(誤りに気付いた方は、コメントいただけると幸いです)

1)リスク評価とは

 先ずはリスク評価プロセスで実施すべきこと、考慮すべきことを理解するために、各ガイドラインに記載されている内容を確認します。

JIS Q 27000:2019 から引用

3.67 リスク評価(risk evaluation)
 リスク及び/又はその大きさが受容可能か又は許容可能かを決定するために、リスク分析の結果をリスク基準と比較するプロセス。
 注記 リスク評価は、リスク対応に関する意志決定を手助けする。

JIS Q 27001:2014 (ISO/IEC 27001:2013) から引用

6.1.2 情報セキュリティリスクアセスメント
 組織は、次の事項を行う情報セキュリティリスクアセスメントのプロセスを定め、適用しなければならない。
(中略)
e) 次によって情報セキュリティリスクを評価する。
 1) リスク分析の結果と6.1.2 a) で確立したリスク基準とを比較する。
 2) リスク対応のために,分析したリスクの優先順位付けを行う。

 リスク評価プロセスでは、主に次の二つのことを行います。

  • リスク分析結果とリスク基準を比較し、各リスクが受容可能か又は許容可能かを決定する
  • 各リスクに対するリスク対応の優先順位を決定する

 次項以降で、上記を決定するための実施方法をなるべく具体的に考えてみます。

2)具体的な実施方法

2-1)リスク受容可否の決定

 リスク分析結果とリスク受容基準を比較し、各リスクの受容可否を決定します。
 リスク分析とリスク受容基準については過去ブログで述べている通りです。

   リスク分析については、過去ブログ情報セキュリティリスクマネジメントについて(5)で考察しています。

blg8.hatenablog.com

 リスク受容基準については、過去ブログ情報セキュリティリスクマネジメントについて(2)で考察しています。

blg8.hatenablog.com

 ここでは、リスク分析を定性的に行い、リスクマップによりリスクレベルを表した結果、各リスクが下図のような分布を示しているケースについて考えてみます。

図2 リスク分析結果とリスク受容基準の比較例

 上図のようなケースの場合は、R2、R08、R10の3つのリスクが受容基準を超えているため、リスク対応*1が必要と判断し、それ以外のリスクに関しては受容可能と判断されます。このように、実施するのは分析結果と基準の比較のみですので、判断に迷うこともなく容易に行うことができます。

2-2)リスク許容について

 ここからは、リスクの許容可否について考えます。
 多くのガイドラインでは、組織のリスク選好(Risk Appetite)に応じリスク受容基準が定められるとの要旨を見ることがあります。

 以下は、上記に関する個人的な見解です。
 リスク受容基準を定める際に組織のリスク選好度合いを多少考慮することは可能だと思いますが、原則は外部のコンプライアンス要件を満たし、かつ社会的に受け入れられる合理性を持った内容(社会通念上相当)とすることを優先すべきであり、それと大きく乖離する基準を組織で定めることは好ましくないと考えます*2
 具体的には、リスク受容基準を定めた際に参照した要求事項及び管理策が記載されているガイドラインを明らかにし、定めた時点で一般的とされている要求事項と管理策の網羅性を示すことにより基準の妥当性を示すことが可能です。
 しかしながら、実際には、価値観や事業目的、規模、方針のような組織の状況により、リスク選好には差が生じ*3 、その結果としてリスクへの対応が異なる可能性があります。
 もし、一般的にリスク対応することが妥当と判断されるリスクを組織の判断で許容する場合は、リスク評価プロセスで受容するのではなく、リスク対応プロセスでリスク保有を選択することが望ましいと考えます。その場合、当該リスクが受容基準を超えていることを明らかにし、次のような制限や特別な管理対象とすることも含めリスク所有者による明確な意思と承認が必要です。

  • リスク保有する期間に期限を設ける
     - ○○年○○月にリスク対応のためのツールを導入するまで
     ー 脆弱性の修正によって生じるリスクの検証が完了するまでの○○日間
  • リスクの変質の可能性を高頻度で監視し、結果に応じ速やかにリスクを再評価する
     - 当該リスクに関連する事象やヒヤリ・ハットの発生状況を監視する(詳しくは、ハインリッヒの法則を参照願います)
     - 脆弱性の対応が完了するまでWAFにより暫定対応するが、その間はログの監視を強化する
  • リスクが顕在化することを想定したインシデント対応訓練を実施する
     - 事前に訓練しておくことでリスクの結果を変えることができます

 上記で、あえて受容と許容の言葉を使い分けましたが、その意図については過去ブログ risk acceptable(受容可能なリスク)と risk tolerable(許容可能なリスク)の違いについて をご参照ください。

blg8.hatenablog.com

2-3)リスク対応優先度の決定

 図2に紹介したようなリスクマップを参照し、各リスクへの対応の優先順位を決定します。
 原則、リスクレベルの大きいVH、H(M、L、VL)のエリアにプロットされたリスク順に優先的に対応を実施しますが、実際には、受容基準で一律に対応要否を判断したり、リスクレベルの大きさに応じた優先順位に従い対応することが必ずしも効率的な運用にならないことがあります。具体的には、対応による費用対効果、マネジメントの意向など、組織の状況に応じ考慮すべき事柄が増える可能性がありますので、それらを含め総合的に判断することになります*4

 なお、上記は、リスク対応のために実装する各管理策レベルでの採否及び優先度の合理性も併せて検証することで正確な判断が可能になります。その詳細については、別途、リスク対応プロセスで考えてみたいと思います。

blg8.hatenablog.com

まとめ

 今回はリスク評価について具体例を交え考察しました。本文でも述べましたが、原則、リスク評価はリスク基準(リスク受容基準)に従い判断しますが、それ以外の要素を全て排除することはできません。もし、リスク評価の判断に柔軟性を求める場合は、マネジメント、組織内外の専門家、組織内外の利害関係者などとのリスクコミュニケーションを密にとり、記録することによりその判断に至った意思や合理性を明らかにすることができます。
 リスク評価の判断が難しいことも多々ありますが、そのような場合はベースライン管理策などの一般的な基準を参考にすることにより助けになる可能性がありますので、活用を検討する価値があると思います。

参考資料

 本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

  • ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • JIS Q 27000:2019 情報技術−セキュリティ技術-情報セキュリティ マネジメントシステム-用語
  • JIS Q 27001:2014 情報技術−セキュリティ技術-情報セキュリティマネジメントシステム-要求事項

脚注

*1:どのような対応を行うのか?については、次のリスク対応プロセスで決定します

*2:リスク所有者がアカウンタビリティを有していることを考えると、外部に対し設定した基準の合理性を説明する責任があります

*3:例えば、スタートアップ企業のように早期の成長や拡大を目指す場合、リスク選考が旺盛になる傾向は高いと思われます。

*4:組織がセキュリティを最優先し事業を蔑ろにすることはあり得ませんし、事業上、大きなリスクを取りに行く場面に直面することもあると思います。そのような場面では、セキュリティ面だけではなく総合的及び合理的に判断することになるため、セキュリティを担当する立場としてはリスクコミュニケーションによりセキュリティに関するリスク以外の内容もマネジメントと共有し、適切な判断が下せるような材料を提供しなければなりません。さらに、組織としてリスクマネジメントを実施する以上、費用対効果を考えずして効果的、効率的な結果は得られませんので、同様に考慮が必要になります。

情報セキュリティリスクマネジメントについて(5)

ー3.2.リスク分析ー

はじめに

 情報セキュリティリスクマネジメントのリスク分析プロセス(図中の赤枠部分)について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図1 リスクマネジメントプロセス上の リスク分析 の位置付け

 注)なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。(誤りに気付いた方は、コメントいただけると幸いです)

1)リスク分析とは

 先ずはリスク分析プロセスで実施すべきこと、考慮すべきことを理解するために、各ガイドラインに記載されている内容を確認します。

JIS Q 27000:2019 から引用

3.63 リスク分析(risk analysis)
 リスクの特質を理解し、リスクレベルを決定するプロセス。
 注記1 リスク分析は、リスク評価、及びリスク対応に関する意思決定の基礎を提供する。
 注記2 リスク分析は、リスクの算定を含む。

JIS Q 27001:2014 (ISO/IEC 27001:2013) から引用

6.1.2 情報セキュリティリスクアセスメント
 組織は、次の事項を行う情報セキュリティリスクアセスメントのプロセスを定め、適用しなければならない。
(中略)
d) 次によって情報セキュリティリスクを分析する。
 1) 6.1.2 c) 1) で特定されたリスクが実際に生じた場合に起こり得る結果についてアセスメントを行う。
 2) 6.1.2 c) 1) で特定されたリスクの現実的な起こりやすさについてアセスメントを行う。
 3) リスクレベルを決定する。

 リスク分析とは、リスク特定によりリスト化された各リスクについて顕在化した場合に起こり得る結果その起こりやすさを分析し、それぞれの分析結果を組み合わせリスクレベルを算定するプロセスです。

2)具体的な実施方法

 リスクアセスメントにより得られる結果を判断するために使用する基準、特にリスクレベルを決定するためにはリスクの構成要素を理解する必要があります。本稿では、情報リスクの要因分析を行うためのフレームワークを提供しているFAIR(Factor Analysis of Information Risk)が提唱しているリスク構造に基づき考察します。
 FAIRのリスク構造モデルでは、下図のように一般的にリスクの要素とされている「損失事象の発生頻度」と「損失事象の大きさ」(JIS Q 31000: 2019では、それぞれ「起こりやすさ」と「結果」と表現されています。)を更に細分化し、組織の状況をより詳細に分析できるようになっているため、イベントベースアプローチにより想定した脅威シナリオに基づき個々の指標のレベルを評価し、右から左に組み合わせていくことにより最終的にリスクレベルの値を知ることが可能になります。

図2 FAIRによるリスク構造

 FAIRで提示される個々の指標は、単独ではなく関連しています。例えば国家の重要インフラに関わる事業を行っている組織の場合、接触頻度、実行の発生確率、脅威の能力それぞれが高い値を示します。また、同じ脅威シナリオを想定した場合でも、影響の及ぶ範囲を考え、起こりやすさについては関連する要因を組み合わせて分析するなど、関連する指標を考慮することで結果の精度は向上します。

 各要素について次項以降で概説しますが、個人的には、構造、個々の指標の考え方が、情報システムの脆弱性に対する評価手法として公開されている共通脆弱性評価システム CVSS( Common Vulnerability Scoring System)と似ている感じる部分が多く、理解の助けになると考えています。

2-1)起こりやすさの分析

接触頻度(Contact Frequency)

 脅威アクターとターゲット*1との接触の起こりやすさを表し、具体的には、次のような点を考慮し判断します。

  • ターゲットと脅威アクターとの間で防御壁として機能する管理策の有無
     外部の攻撃者が組織内の機密情報を窃取する攻撃を企てているとの事象を想定すると、ターゲットとなる組織における機密情報の保管環境が関連します。例えば、「保管場所がパブリッククラウド上なのか?、オンプレミス上なのか?」、「FWによりネットワーク分離がされているのか?」などが判断の基準となります。
     また、想定する脅威アクターによっても接触のしやすさは異なります(例えば、外部の攻撃者、一般要員、業務上の管理者、特権を有するシステム管理者など)。脅威シナリオによっては、内部協力者の有無も影響すると思われます。

  • 脅威アクターの量
     内部不正という事象を想定した場合、不正に関与する可能性のある者が組織内部にどれ程存在するのかが判断材料となります。例えば、欧米では、公務員だけではなく、経済安全保障の観点で先端技術の流出を防ぐためにその研究に携わる民間に対しても、セキュリティクリアランス*2による厳しいスクリーニングが実施されており、最近は国内でもそれに準じるべきとの議論がされています。セキュリティクリアランスの実施は、組織内部に脅威アクターが入り込むことを防ぐ効果があります。

  • ターゲットの量
     内部、外部の脅威に曝される可能性のあるターゲットの保有量です。例えば、不要な情報及びその他関連資産をいつまでも保有することは脅威との接触の可能性を高めることになってしまいます。 *3

 一見、エアギャップ内のPCは脅威との接触が無いように思えてしまいますが、USBメモリや要員をリスク源として考えるとゼロではない事が理解できます。このように脅威シナリオを想定する際には、網羅的にリスク源やターゲットを洗い出すことが求められます。

 接触頻度そのものを表すものではありませんが、脅威インテリジェンスを用い、例えば、「ダークWeb上で自組織の脆弱性やクレデンシャルのような認証に係る情報が売買されていないか?」あるいは、「組織で設置しているセキュリティ機器から収集しているログに疑わしい振る舞いが記録されていないか?」などの実際に外部脅威が組織内に対し接触を試みている兆候を検知することも重要です。

② 実行の発生確率(Probability of Action)

 脅威アクターがターゲットの状況を理解し、その後、目的達成のための行動を実行に移す確率(実行しようとする意欲)を表します。行動を実行に移す際に脅威アクターが重視する点は、目的を達成するためにかかる労力と得られる利益の比較です。そのため、実行に移行させないための策としては、「目的達成は容易ではない」、「目的を達成しても得られるものが少ない」と脅威アクターに認識させることが有効です。
 また、内部不正を想定する場合は、「不正のトライアングル」の観点で、3要素「動機」、「不正の正当化」、「実行機会」を低下させる管理策が有効です。

 具体的には、次のような点を考慮し判断します。

  • ターゲット組織の堅牢さ
     脅威アクターが認識しているターゲット組織の堅牢さです(脅威アクターから堅牢そうに見えるか?であり、実際に堅牢かどうかではありません)。
     例えば、「ターゲットが運営するWebサイトに脆弱性が存在する 」、「ダークWeb上で、ターゲット組織への侵入や攻撃方法が売買されている」など、脅威アクターが組織の脆弱性に係る情報を接触の段階で入手していると、実行に移行する可能性は高くなります*4
     今年は、自動車産業サプライチェーンを狙った攻撃が多く見られますが、より価値の高い物(産業規模の大きさ)を比較的容易に手に入れられる(サプライチェーン上の最も弱い箇所を狙う)との理論が働いていると考えることもできます。
     また、技術的な堅牢さ以外にも、例えば、過去にランサムウェアに対する身代金支払い実績がある組織の場合、再度、支払いに応じるというように脅威アクターからは組織の体制上の脆さと捉えられる可能性があります。

  • ターゲットの資産価値
     脅威アクターから見たターゲットの資産価値の高さです。脅威アクターは、実行の前段階でソーシャルエンジニアリングなどにより、ターゲット組織の事業内容、売上金額は元より、金融資産、知的財産、新規性のある製品情報を保有している可能性を調査し、当該組織が重要と考える情報、関連資産を資産価値を含め特定します。
     したがって、価値の高い資産を保有していることを脅威アクターに悟られないことも必要です。例えば、機密情報や重要設備を保管している施設の入口に「重要情報保管 関係者以外立ち入り禁止」と表示をすることは、抑止効果が得られると同時に不要な好奇心をかきたてることになりかねません。

  • 実行した場合のリスク
     脅威アクターが、実行した場合のリスクをどの程度見積もるか?です。例えば、内部不正を想定した場合、発覚する可能性が高いことを認識させるために各種ログを取得し、監視していることを周知したり、内部不正が発覚した場合に厳正な処罰を与えることを定めた罰則規定などは実行の発生確率を抑える効果が期待できます。

③ 脅威の能力(Threat Capability)

 脅威アクターが有する(又は調達できる)ターゲットに対して適用可能な攻撃能力を表します。
 想定する脅威アクターのスキルそのものを把握することが重要ではありますが、近頃は、RaaS(Ransomware-as-a-Service)やAaaS(Access as a Service)、MaaS(Malware as a Service)というような攻撃をサポートするサービスにより複数の脅威アクターによる分業化が進み、また、ダークWeb上で攻撃マニュアルが公開されるなど、高度な攻撃に要求されるスキルが低下していることも考慮すべきだと考えます。

 具体的には、次のような点を考慮し判断します。

  • 脅威アクターのスキル
     脅威シナリオで想定する脅威アクターのスキルそのものです。言い換えると、高度なスキルを持った脅威アクターが自組織をターゲットとして接触してくる可能性と言えます。例えば、自組織が重要インフラを担っていたり、高額な身代金支払い能力がある場合は、高度なスキルを持った脅威アクターにより狙われる可能性が高いと考えられるため、脅威アクターのスキルを高く見積もる必要があります。

  • 攻撃手法
     脅威シナリオで想定する脅威アクターが使用すると思われる攻撃手法の種類です。例えば、MITRE ATT&CKなどのサーフェイスWebや攻撃者のコミュニティなどのダークWeb上で既知となっている攻撃手法やその亜種による攻撃を想定した場合、既知の情報を応用することによりスキル不足を補うことができるため脅威アクターの能力は上がります。
     言い換えれば、既知の攻撃手法に関しては、ターゲットを守る側の組織においても事前に分析し、有効な管理策により対応することで、後述する「④ 抵抗力の強さ」を強化できるため、全体的なリスクレベルは下げることが可能です。

  • リソース
     脅威シナリオで想定する脅威アクターが使用すると思われるツールやサービスの種類です。例えば、脆弱性を起点とした脅威シナリオにおいて、その脆弱性を悪用するエクスプロイトが公開されている場合は、利用によりスキル不足を補うことができるため脅威アクターの能力は上がります。
     エクスプロイトの公開有無に関しては、次のサイトなどで確認することが可能です。
     ー KNOWN EXPLOITED VULNERABILITIES CATALOGCISA
     ー Exploit Database (Offensive Security)
     他に、ネット上の実証コード(PoC)を解析し、脆弱性の悪用の可能性(Expected Exploitability)をスコアリングし公開しているサイトもあります。
    ※)エクスプロイトの公開情報はダークWeb上のサイバー犯罪フォーラムでも調査することができますが、不要な危険を招く結果となる可能性もあるため、専門的な知識を有していない限り近づかない方が良いと思われます。

     脅威シナリオで脅威アクターのスキルを想定する場合、主観的な立場で実施すると、例えば安全側にバイアスがかかり脅威の能力を必要以上に高く見積もったりするなど、正確な判断が難しくなることが考えられます。そこで、客観的な視点を入れた実施例を以下で説明します。
     脅威アクターのスキルの分布を下図のように仮定した場合、脅威シナリオにおいて想定した脅威アクターがどの区分に位置付けられるのかという観点で考えると、その脅威の能力を理解することができます。脅威シナリオから脅威アクターのスキルを割り当てた例も併せて載せています。

図3 脅威アクターのスキル分布の例

④ 抵抗力の強さ(Resistance Strength)

 脅威に対する抵抗力の強さを表します。具体的には、ベースライン管理策の中から対象となる脅威に関連する管理策を抽出し、その実施状況と有効性を確認します。
※)管理策の実施状況と有効性を確認する時には、各管理策の組合せによる相互補完も考慮した対象脅威に対する全体的な能力(Capability)を分析します。(ベースライン管理策とCapabilityについては、過去ブログが参考になります)

blg8.hatenablog.com

 組織内の抵抗力の強さに関しては、ベースライン管理策が整備されていれば比較的容易に分析が可能だと思いますが、リスクアセスメントの範囲にサプライチェーン全体を含める場合は、範囲全体で管理策の実施状況を確認することになります。そのような場合、現状は、セルフチェック済チェックシートの回収や定期的な第二者監査の実施、若しくは、第三者監査結果の提出などにより実施されているのが一般的だと思われます。

⑥ 二次損失の発生頻度(Secondary Loss Frequency)

 想定する事象が発生した場合に利害関係者に関連する二次損失が発生する可能性(起こりやすさ)を表します。例えば、次のような損失が考えられます。

  • 社会的信用の失墜
     個人情報保護などの法的な管理義務を果たしていないなど、組織の社会的な評判の失墜(レピュテーションリスク)の結果として、以下の二次的な損失の発生が考えられます。
     - 事象とは直接関わりのない顧客の喪失(取引停止や競合他社への顧客流出)
     - 株価などの企業価値の低下
     - 社内のモラル・士気低下、要員からの訴訟、人材の流出、雇用難
     - 株主代表訴訟
  • 顧客との関係悪化
     顧客から預かった機密情報や個人情報が漏洩した場合の訴訟や損害賠償請求

2-2)結果の分析

⑤ 一次損失の大きさ(Primary Loss)

 リスクが顕在化した場合に、発生が想定される事象により組織が直接被る損失を表し、具体的にはサイバー攻撃によるシステム停止に伴う業務の停滞、BECによる不正送金などが挙げられます。一次損失には、事象発生後に必要になる調査や復旧・顧客対応に係る委託費用や社内工数なども含みます。
 損失はその大きさと範囲の2つの視点で捉えられ、損失の大きさを試算する時の考慮事項としては、事象発生による業務の停滞、技術情報や営業秘密の流出による優位性の低下などが考えられます。
 損失の影響範囲の試算は、組織内に限定され、外部の利害関係者への影響は、二次損失に含め検討します。例えば、ターゲットをドメインコントローラと想定した場合、影響が及ぶシステムの範囲を特定する必要があります。また、業務が停滞した場合も、納期遅延、営業機会の喪失などを含めどのような結果を招くのか考えなければなりません。

⑦ 二次損失の大きさ(Secondary Loss Magnitude)

 「⑥ 二次損失の発生頻度」で検討した事象が発生した場合の損失の大きさを表します。大きさの試算方法は 、「⑤ 一次損失」と同様です。

 なお、「顧客から預かっている機密情報」、「顧客の個人情報」などの情報を暗号化し、鍵を有効に管理(暗号化した情報とその復号鍵を同時に窃取されないような管理)しておくことにより、万が一、情報が窃取された場合でも、その情報が脅威アクターにとって意味のないものとなり、結果を変えられる可能性があります。
 また、インシデント発生時に上記のような自組織におけるリスク対応の正当性(有効性)を時機を失さずに訴えることは、社会的な評判の低下を防ぎ、損害賠償や訴訟の結果にも好影響を与える可能性もあります。

 起きてしまったインシデントは記録として残ります。現在は、情報化社会のため、その記録は組織に対する負の情報として、予想以上に長く残り続ける可能性があることも考慮した方が良いかもしれません。
 また、リスク共有(リスク移転)としてサイバーセキュリティ保険へ加入することで一次損失を補填することが可能ですが、二次損失までを含めてカバーすることが出来ない可能性を考慮する必要があります。

2-3)リスクレベルの算定

 ①~⑥までの各要素の分析結果から、損失事象の発生頻度(想定した事象の起こりやすさ)と損失事象の大きさ(想定した事象によりもたらされる結果)を算出し、最終的なリスクレベルを算定します。
 下表が組織内外の状況から特定したリスクに対し起こりやすさと結果を定性的に分析した実施例です。

表1 イベントベースアプローチで特定したリスクの分析例

 上表の各リスクの分析結果をリスクマップにプロットすることによりリスクレベルを表すことができます。

図4 リスクマップによるリスク分析結果の表示例

まとめ

 今回はリスク分析について考えてみました。せっかく網羅的にリスクを特定できていてもその大きさを正確に分析できないと精度の良いリスクマネジメントを実施することができません。しかしながら、何も基準がないと判断に迷うことになります。そのような迷いをなるべく払しょくするために、今回はFAIRを利用しリスク構造を見えるようにしました。このようなフレームワークを使うことで何もない状態で進めるよりもリスク分析を効率的、効果的に進めることができるようになると考えます。

参考資料

 本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

  • ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • JIS Q 27000:2019 情報技術−セキュリティ技術-情報セキュリティ マネジメントシステム-用語
  • JIS Q 27001:2014 情報技術−セキュリティ技術-情報セキュリティマネジメントシステム-要求事項
  • FAIR(Factor Analysis of Information Risk)
  • JIS Q 31000:2019 リスクマネジメント-指針
  • 共通脆弱性評価システム CVSS( Common Vulnerability Scoring System)

脚注

*1:例えば、営業秘密を含む情報は、保有している組織側の視点では保護すべき対象ですが、脅威アクターはターゲット(窃取する対象)として捉えています。

*2:重要なポジションに就く可能性のある者を雇用する際、採用予定者の債務状況(多額の債務を抱えると冷静な判断ができなくなり、不正の動機となり得ます)や犯罪歴、交友関係、飲酒・薬物使用歴などのバックグランドを詳細に調査する適性評価

*3:不要な情報及びその他関連資産を保有しないことは、最も有効なリスク回避策です。

*4:セキュリティリスクレイティングサービスを利用するなど、適切にアタックサーフェースマネジメントすることで実行の発生確率を低くすることが可能です。

情報セキュリティリスクマネジメントについて(4)

ー3.1.リスク特定ー

はじめに

 情報セキュリティリスクマネジメントのリスク特定プロセス(図中の赤枠部分)について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図1 リスクマネジメントプロセス上の リスク特定 の位置付け

 注)なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。(誤りに気付いた方は、コメントいただけると幸いです)

1)リスク特定とは

 先ずはリスク特定プロセスで実施すべきこと、考慮すべきことを理解するために、各ガイドラインに記載されている内容を確認します。

JIS Q 27000:2019 から引用

3.68 リスク特定(risk identification)
 リスクを発見、認識及び記述するプロセス。
 注記1 リスク特定には、リスク源、事象、それらの原因及び起こり得る結果の特定が含まれる。
 注記2 リスク特定には、過去のデータ、理論的分析、情報に基づいた意見、専門家の意見及びステークホルダーのニーズを含むことがある。

JIS Q 27001:2014 (ISO/IEC 27001:2013) から引用

6.1.2 情報セキュリティリスクアセスメント
 組織は、次の事項を行う情報セキュリティリスクアセスメントのプロセスを定め、適用しなければならない。
(中略)
c) 次によって情報セキュリティリスクを特定する。
 1) ISMSの適用範囲内における情報の機密性、完全性及び可用性の喪失に伴うリスクを特定するために、情報セキュリティリスクアセスメントのプロセスを適用する。
 2) これらのリスク所有者を特定する。

 リスク特定とは、組織が定めた情報セキュリティ目的達成の成否を不確かにする影響を特定することです。
 具体的には、次のことを実施するプロセスです。

  • リスクを発見する
    目的達成に対し負の影響を及ぼし得る、組織及びその内外の状況と課題を理解します
  • リスクを把握する
    目的達成に対し負の影響を及ぼす力を潜在的に有する事象、脅威、脆弱性などのリスク源やその結果による影響を把握します
  • リスクを記述する
    上記により把握した内容を記録します(リスクのリスト化)

 情報セキュリティリスクマネジメントでは、上記にて作成されたリストに記載される個々のリスクに対し、リスク分析とリスク評価を行い、必要なリスク対応を行います。したがって、このプロセスで特定漏れとなったリスクは、その組織にとっては想定外となってしまい、この後のプロセスでは対象とならず放置されることになるため、リスクマネジメント全体の中でも重要な位置づけとなっており、網羅的、及び動的に実施しなければなりません。

2)組織及びその内外の状況の理解

 前述の通り、リスク特定(リスクの発見)は網羅的、及び動的に実施することが求められます。他方、リスクを特定するためには、組織の情報セキュリティ目的に影響を与える組織内外の状況の変化を正確に把握しなければなりません。
 そのため、ISO規格の中でも、リスク特定の前提タスクとして次のように組織及びその状況の理解が求められています。

JIS Q 27001:2014 (ISO/IEC 27001:2013) より

4 組織の状況
4.1 組織及びその状況の理解
 組織は、組織の目的に関連し、かつ、そのISMSの意図した成果を達成する組織の能力に影響を与える、外部及び内部の課題を決定しなければならない。

 具体的な実施のタイミングについては、過去ブログ 情報セキュリティリスクマネジメントについて(3) の2-1)リスクアセスメントの実施時期で述べている通りです。

blg8.hatenablog.com

※)変化を検知するためのモニタリングについては、過去ブログ「脅威インテリジェンス」についてで紹介した内容、特に戦略インテリジェンス(Strategic Intelligence)、戦術インテリジェンス(Tactical Intelligence)などの手法が参考になります。

blg8.hatenablog.com

 一言で「組織及びその状況の理解」と言っても何の指針もなく理解するのは難しく、結果の網羅性について検証することもできないため、次のようなISMSの用語説明に記載されている例示などを参照しながら進めることになると思います。

JIS Q 27000:2019 から引用

3.22 外部状況(external context)
 組織が自らの目的を達成しようとする場合の外部環境。
 注記 外部状況には、次の事項を含むことがある。
 − 国際、国内、地方又は近隣地域を問わず、文化、社会、政治、法律、規制、金融、技術、経済、自然及び競争の環境
 − 組織の目的に影響を与える主要な原動力及び傾向
 − 外部ステークホルダー(3.37)との関係並びに外部ステークホルダーの認知及び価値観

3.38 内部状況(internal context)
 組織が自らの目的を達成しようとする場合の内部環境。
 注記 内部状況には、次の事項を含むことがある。
 − 統治、組織体制、役割及びアカウンタビリティ
 − 方針、目的、及びこれらを達成するために策定された戦略
 − 資源及び知識としてみた場合の能力[例えば、資本、時間、人員、プロセス、システム及び技術]
 − 情報システム、情報の流れ及び意思決定プロセス(公式及び非公式の両方を含む。)
 − 内部ステークホルダーとの関係並びに内部ステークホルダーの認知及び価値観
 − 組織の文化 − 組織が採択した規格、指針及びモデル
 − 契約関係の形態及び範囲

 また、SWOT、PESTLE、HAZOP、特性要因図、3Cなどの一般的なフレームワークを活用することでより具体的に課題抽出のイメージが湧くと思います。一般的なフレームワークではありませんが、筆者が実際に行っている実施例を一部紹介します。

 下図のようなイメージで、現状の組織内標準と、内部、外部、現状、変化の4象限のそれぞれの状態との乖離をリスク要因と捉え、特定します。*1
 組織内でこのような指針を定めておくことで組織の現況の抽出作業がスムーズに行えると考えます。

図1 組織内外の状況把握のイメージ

 上図の①~⑤を特定する際に指標とする項目の一部を以下に羅列します。

① 組織内標準

② 内部の現状

  • 組織構造(事業、情報セキュリティ)
  • セキュリティ上の役割と責任
  • 情報及び関連資産の各種台帳(目録)、業務フロー
  • 組織の特徴(事業目的・戦略、リスク選好の度合など)
  • 所在地
  • 情報及びその他資産の保有状況と重要度(セキュリティが損なわれた場合の事業への影響)
  • 脆弱性の状況(使用ソフトウェアのVer.情報、脆弱性診断結果など)
  • リスクアセスメント結果
  • 内部監査、外部監査の結果
  • 組織内インシデント・事象の発生状況

③ 外部の現状

  • 所属業界・団体、監督官庁
  • 取引先(顧客、委託先)との契約内容
  • 委託先の管理状況と委託業務の範囲
  • 委託先でのインシデント発生状況
  • クラウドなど、外部サービスの利用状況

④ 内部の変化

  • 経営方針などの上位方針
  • 事業形態(参入、撤退)
  • 拠点の新設・統廃合
  • 新システム(サービス)の導入
  • 各種ログ解析から発せられるアラート

⑤ 外部の変化

  • 既存ICT技術の陳腐化
  • ソフトウェア(OS)のサポート終了、脆弱性発覚
  • 外部脅威(組織外でのインシデント発生、セキュリティベンダによる脅威予測、各種ハザードマップの改定)
  • 脅威インテリジェンスから得られる情報
  • 法、規制の改正
  • 顧客、市場からの要求、ニーズの変化
  • ISO、NISTなど、関連するマネジメントシステム、ガイドライン、管理策フレームワークなどの改定

 外部からの情報入手先については、過去ブログ 「専門組織との連絡」についてが参考になると思います。
blg8.hatenablog.com

3)リスク特定の実施例

3-1)リスクの特定

 ”2)組織及びその内外の状況の理解” の実施結果から得られた情報を元にリスクを特定します。このリスク特定の手法は一つに限定されず、そのリスクに応じた様々な方式が用いられます。
 新たな事業を始めることにより、(例えば、新規顧客から提供される情報、新製品の技術情報、個人のプライバシー情報などの)今まで取り扱われていなかった情報やそれを取り扱う業務フローが増える場合、そのリスクの変化を特定するためには、アセットベースアプローチとベースラインアプローチの活用が適切かもしれません。
 また、外部において新たな攻撃手法が増加している場合は、攻撃シナリオを想定し、攻撃者が最終目標に至るまでの各プロセスにおける事象と関連する管理策の実施状況と有効性をイベントベースアプローチにより特定することが適切かもしれません。

 重要なのは、このプロセスで、極力漏れなくリスク特定できていることと、この次のプロセスであるリスク分析に対し有用なインプット情報を渡すことであり、リスクアセスメント全体で考えるとより正確な評価結果が得られることが重要です。

 リスクの定義上、次の項目を明らかにすることにより正確なリスク評価結果を得られる可能性は高くなりますので、リスクを特定する上で考慮が必要です。

  • 起こり得る事象の内容
  • 結果及び結果が目的に与える影響
  • リスク源
  • 脅威アクター
  • ターゲットとなる情報及びその他関連資産

 なお、イベントベースアプローチ、アセットベースアプローチなどの手法、戦略サイクル、戦術サイクルなどの実施タイミングに関しては、過去ブログ 情報セキュリティリスクマネジメントについて(3) が参考になります。

blg8.hatenablog.com

3-2)リスク所有者の特定

 JIS Q 27001:2014 (ISO/IEC 27001:2013)では、このリスク特定プロセスでリスク所有者を特定することとなっていますが、過去ブログ 情報セキュリティリスクマネジメントについて(2) で述べている内容と重複するため、割愛します。(詳しくは、下記をご確認ください)

blg8.hatenablog.com

まとめ

 今回はリスク特定に関し考察しました。本文中に書きましたがこのプロセスで特定漏れしたリスクは組織にとっては想定外となり、放置されるこことなってしまうため、非常に重要なプロセスと言えます。時期を失さずにリスクに対応するためには網羅的、動的にリスク特定することが求められます。

参考資料

 本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

  • ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • JIS Q 27000:2019 情報技術−セキュリティ技術-情報セキュリティ マネジメントシステム-用語
  • JIS Q 27001:2014 情報技術−セキュリティ技術-情報セキュリティマネジメントシステム-要求事項
  • JIS Q 31000:2019 リスクマネジメント-指針
  • JIS Q 31010:2022 リスクマネジメント-リスクアセスメント技法

脚注

*1:学術的には、未だ起きていないことを予見したものがリスクであり、世の中で既に起きていることはリスクとは定義しないという考え方もあります。(例えば、他組織で起きたインシデントを対象に行う対応はリスク対応ではなく、是正対応であるとの考え方です)それに従うと下図の考え方では、リスク以外の要素も含まれてしまいますが、本来の目的である「セキュリティ目的に対する不確かさの影響」の特に影響を見極めるという観点で考えると、実務としてはそれほど的外れでもないと考えています。あくまで筆者の個人的な見解です。

情報セキュリティリスクマネジメントについて(3)

ー3.リスクアセスメント

はじめに

 情報セキュリティリスクマネジメントのリスクアセスメントプロセス(図中の赤枠部分)について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図1 リスクマネジメントプロセス上の リスクアセスメント の位置づけ

 注)なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。(誤りに気付いた方は、コメントいただけると幸いです)

1)リスクアセスメントとは?

 ISMSに関連する用語を定義しているJIS Q 27000:2019には、リスクアセスメントについて次のように記載されています。

JIS Q 27000 : 2019 より

3.64 リスクアセスメント
リスク特定、リスク分析、及びリスク評価のプロセス全体。

 リスクアセスメントは、リスクマネジメントにおいて、対象とするリスクの重大性(主に起こりやすさとその結果)を明らかにするプロセスです。その結果は主に以下のような様々な判断の材料として活用されます。

  • リスク受容基準との比較により、リスク対応要否を判断する
  • 他のリスクのアセスメント結果との比較により、リスク対応の優先順位を判断する
  • リスク対応前や過去の結果との比較により、リスクの変化を見極める

図2 リスクアセスメント結果の活用イメージ

 リスクアセスメントプロセスは、次のアクティビティにより構成されます。

① リスク特定
 リスクを発見し、理解した内容をリスト化する。
② リスク分析
 リスク特定でリスト化した個々のリスクに対し重大性を算定する。
③ リスク評価
 リスク分析結果をリスク基準と比較し、受容可否(リスク対応の要否)を決定すると共に、個々のリスク分析結果を比較し、それぞれのリスク対応の優先順位を決定する。

 上記、各アクティビティにおける具体的な実施内容については、次回以降で紹介したいと思います。

2)具体的な実施例

2-1)リスクアセスメントの実施時期

 リスクに影響を及ぼす可能性のある組織内外の状況は時間の経過とともに刻々と変化します。リスクに対する対応を時機を失さず行うためには、その変化と兆候を可能な限り察知し、リスクにどのような影響を与えるのかを特定することが重要です。
 上記については、JIS Q 27001:2014(ISO/IEC 27001:2013)でも次のように要求されています。

JIS Q 27001:2014 8.2 情報セキュリティリスクアセスメント より

組織は、あらかじめ定めた間隔で、又は重大な変更が提案されたか若しくは重大な変化が生じた場合に、6.1.2 a) で確立した基準を考慮して、情報セキュリティリスクアセスメントを実施しなければならない。

 上記により、リスクの変質に気付かず対応漏れとなることを防げますが、把握した全ての変化に対し、一律に実施すると(多くの組織ではリソースが限られているため)優先順位に応じた効率的な対応ができない恐れがあります。
 効率的な運用のためには、トリガーとなる組織内外の変化(事象の性質や大きさ)に応じたリスクアセスメントの実施が必要です。例えば、ISO/IEC DIS 27005:2021やEBIOS RMのようなリスクアセスメントを実施するためのガイドラインでは、戦略サイクル運用サイクル の二種類の実施サイクルが提示されており、トリガーとなる変化の内容に合わせ使い分けることにより効果的・効率的な運用が可能になります。

2-1-1)「あらかじめ定めた間隔」とは?

 職場において、「JIS Q 27001:2014に記載されている ”あらかじめ定めた間隔” とは、どの程度の間隔・頻度が妥当なのか?」という質問をよく受けます。以下、筆者の個人的な見解を述べます。
 リスクに影響を及ぼす重大な変更重大な変化を時機を失さず、モニタリングできていれば「あらかじめ定めた間隔」でのレビューは不要だと考えます。しかしながら、実際には、特定漏れは発生すると考える方が妥当であり、その期間を長く放置しないための補完的な措置として定期的なレビューは必要だと認識しています。
 その考え方に従うと、「あらかじめ定めた間隔」は次のような指標を基に組織で決定することになります。また、その間隔自体も組織の状況の変化に応じ柔軟に見直します。

  • 変化に気付かない(リスクが放置されている可能性のある)期間をどの程度受容できるか
  • 変化の起こりやすさはどの程度か(成熟した組織とスタートアップでは変化のスピードは異なります)
2-1-2)戦略サイクルと運用サイクル

 前述のとおり、リスクアセスメントを実施するためのガイドラインでは「戦略サイクル」と「運用サイクル」 の二種類の実施サイクルが紹介されています。筆者はそれぞれの特徴を下表のように解釈しています。

表1 「戦略サイクル」と「運用サイクル」のイメージ

2-2)リスクアセスメントのアプローチ方法

 ISO/IEC DIS 27005:2021では、情報セキュリティリスクを特定する際の着眼の手法として、イベントベースアプローチアセットベースアプローチの2種類が紹介されています。
 次項で各アプローチの内容について触れてみたいと思います。
 なお、このようにリスク特定するためのアプローチが異なる場合でも、リスクアセスメントの原則である実施結果に対する高い一貫性は求められます。

2-2-1) イベントベースアプローチ

 組織の内外の状況から想定されるイベント(事象)をベースにリスクアセスメントを行うアプローチ手法です。
 例えば、組織の情報を窃取しようとする外部の攻撃者や過失を犯す可能性のある要員などのリスク源から想定される脅威シナリオを組み立て、その個々のイベントの連なりから想定される運用シナリオからリスクを特定する手法です。運用シナリオ想定時には、脅威インテリジェンスの手法(特にTTPsの観点)、及びそこから得られる情報(例えば、緩和策例など)を活用することで効率的に進めることができます。
 おおまかな実施の流れと実施時に参考になる情報を紹介します。

① リスク源と結果
 組織及び内外の状況から、リスク源とそのリスクによる結果を仮説する
 組織及び内外の状況の洗い出しの方法については、次回ブログで紹介予定です

blg8.hatenablog.com

② 戦略シナリオの特定
 上記で仮説した結果に至る過程(例えば脅威アクターが最終目的を達成するために使うであろう戦術の流れ)を特定する
 MITRE ATT&CK TTPs
 STRIDE (Microsoft))
 Cyber Kill Chain (Lockheed Martin)
 Attack tree analysis

③ 運用シナリオの特定
 各戦術を確立するために使用される技術・手法を特定する
 MITRE ATT&CK TTPs
 Attack tree analysis

脆弱性の確認
 運用シナリオが成立するための条件として悪用される可能性のある脆弱性を特定し、関連する管理策(低減策、検知・対応)の実施状況を確認する
 具体例として、二重脅迫型ランサムウェアによる攻撃を想定したイベントベースアプローチのイメージを下図に示します。

図3 イベントベースアプローチの実施イメージ

 次項で考察するアセットベースアプローチと比較すると、結果(事象による影響)が初期段階である程度明らかになるため、詳細なリスクアセスメントの実施要否を早期に判断することが可能になります。

 また、イベントベースアプローチによるリスクアセスメントには戦略的な視点が必要とされるため、知識、経験を有する専門家に外部委託することも可能です*1リスクアセスメントを組織内でのみ実施し続けると、状況の変化を見落としがちになりますので、例えば、先入観を持たない外部の知見によるアセスメントを数年に一度実施し助言を求めることは、リスク特定の網羅性を高め、リスクアセスメントの不確かさを防ぐためにも有効だと思います。

2-2-2) アセットベースアプローチ

 アセット(資産 *2 )とそこに内在する脆弱性を特定し、その脆弱性を悪用する脅威の起こりやすさ、資産の事業上の重要性からリスクを特定する手法です。
 イベントベースアプローチと比較すると、 戦術的(運用的)な視点による実施内容となります。
 組織内ですでに業務機能一覧や業務フロー、業務手順書などのドキュメント類が整っている場合は、資産の重要度を比較的容易に知ることができ、詳細アセスメントの優先度も初期段階で判断できるため、作業量は少なくなる傾向があります。

◆ 資産特定の粒度について
 資産特定の粒度については、ISMSユーザーズガイド ーリスクマネジメント編-(JIPDEC)に参考になる記載がありましたので紹介します。

ISMSユーザーズガイド ーリスクマネジメント編-(JIPDEC)
3.2.2 作業2 リスクを特定する ③資産のグループ化 から引用

例えば、資産価値や属性(保管形態や保管期間、用途等)が一致するものを一つのグループとする等です。重要性や属性が同じで、結果的に適用されるセキュリティ対策が同じであれば、同じグループとしてまとめて管理することが効率的です
(中略)
そもそも資産の洗い出しをする目的は、ISMSの適用対象全体で適切なセキュリティ対策を決定することです。組織の全ての資産を網羅し、一つひとつの資産の属性を明記した詳細な資産台帳を作成することが必ずしも最終目標ではありません

 日頃から実務としてリスクアセスメントに接している筆者も同意見です。特に、業務プロセスのために必要となるリソース(例えば、要員、XXサーバ、XXシステム、情報)として資産を捉えることができるため、業務プロセス単位でグループ化することが妥当だと考えます。

 ここまでの内容を踏まえ、アセットベースアプローチの流れを次に示します。業務プロセスが資産価値や用途を表し、それに関連する”情報および関連する資産”の属性に対する管理策の有効性からリスクを分析します。(下表は説明のために大幅に簡略化しており、実運用では管理すべき項目はもっと多くなるはずです)

① 主要資産
 各業務プロセスの資産価値に応じ、その主要資産に求める機密性、完全性、可用性を定める
② 遵守要件
 業務プロセスで取り扱われる情報ごとに法令や契約などの遵守すべき要件の有無を明らかにする
③ 支援資産と属性
 各情報の保管状況など、支援資産の現状(属性)を明らかにする
④ 関連するベースライン管理策
 支援資産と属性情報を条件として、ベースラインから関連する管理策を抽出する
⑤ 管理策の有効性確認
 抽出された管理策に対する現状の実施状況と有効性を確認し、脆弱性レベルを分析する
⑥ 脅威の起こりやすさ分析
 上記脆弱性を悪用する脅威の起こりやすさを分析する

図4 アセットベースアプローチの実施イメージ

 ベースライン管理策については過去ブログで紹介しています。

blg8.hatenablog.com

 業務プロセス単位でグループ化する利点は、その資産価値(例えば、可用性が損なわれ当該業務が滞った場合の影響度)の評価結果の合理性にあります。また、例えば、事業リスク(BCPを検討する際のBIAの実施)、業務リスク(非効率な業務を改善・改革するための現業務の分析)のような他のリスク分析の際にも、同じように事業(業務)への影響の大きさは特定しなければならないため、リスクマネジメント全般における目的別の連携や作業の共通化による効率的な運用が可能になる利点があります。

 今回紹介した2つアプローチの良い面を活かすために、次のように役割ごとに手法を使い分け、組織全体として併用することも可能です。

表2 リスク特定アプローチの併用例
 リスク特定のアプローチの手法は、上記2種類に限定されません。自組織の特徴に合わせ独自の手法を採用することも可能です。

まとめ

 今回はリスクアセスメントについて具体例を交え考察しました。今回、紹介した以外にも多くの手法がガイドラインなどにより提示されていますので、組織の状況にあったものを選び、テーラリングすることにより、効果的な運用が可能になると思われます。
 次回以降、リスクアセスメントの個々のアクティビティであるリスク特定、リスク分析、リスク評価について考えてみたいと思います。

参考資料

 本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

  • JIS Q 27001:2014 情報技術−セキュリティ技術− 情報セキュリティマネジメントシステム−要求事項
  • JIS Q 27000:2019 情報技術−セキュリティ技術-情報セキュリティ マネジメントシステム-用語
  • ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • EBIOS RM EBIOS Risk manager
  • MITRE ATT&CK TTPs
  • STRIDE (Microsoft)
  • Cyber Kill Chain (Lockheed Martin)
  • JIPDEC ISMSユーザーズガイド ーリスクマネジメント編-(JIPDEC)

脚注

*1:各社からリスクアセスメントサービスが提供されており、中にはその結果に対応するためのアドバイザリーサービスを選択できるものもあります。

*2:ここで用いている”アセット(資産)”という用語は、他のブログで”情報及び関連する資産”と表現しているものと同義です。