SSVCにおける Human Impact 決定方法例

概要

SSVC で Deployer Tree を使う際に、HUMAN IMPACT の設定に戸惑うことが多いと思います。SSVC の定義上でも、複雑なので詳細が避けられているように見えます。
また、実運用上でも「脆弱性ひとつずつ」HUMAN IMPACT を定義することは難しく（脆弱性毎に定義をすることになる）、何らかの標準化が必要となります。

本記事では、SSVC の定義上での HUMAN IMPACT について確認し、実運用上のHUMAN IMPACTの定義で利用できそうなフレームワークをご紹介します。

Exective summary

本来的に HumanImpact は、Situated Safety Impact と Mission Impact をもとに考えるのが良いと思われています。
しかしながら現時点の SSVC の考え方では、実装の簡素化のため、Mission Impact で決定します。

Mission Impact 部分については、SSVC での定義や(NIST SP800-63を参照している)デジタル社会推進ガイドラインや OWASP Risk Rating Methodology などが利用できます。

最終的には、上記の指標をそのまま利用するか、各指標が考慮している事項をもとに、レーティングをしていく必要があります。

これらの決定は、組織や事業の継続性にかかるリスクアセスメントになるため、ビジネスオーナーや CISO などが関与することが望ましと考えます。

SSVC(Deployer Tree)でのHumanImpact

SSVC における HumanImpact についてみてみます。

基となる資料は以下の通りです。

• CarnegieMellonUniversity: Priorizating Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization(Version 2.0)
  • https://insights.sei.cmu.edu/library/prioritizing-vulnerability-response-a-stakeholder-specific-vulnerability-categorization-version-20/
• CISA: Stakeholder-Specific Vulnerability Categorization(SSVC)
  • https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc

SSVC の論文では以下のように考えることが望まれています。(P.26付近)

• Human Impactは、Situated Safety Impact と Mission Impact の複合で決定する
  • Mission Essential Function(MEF: ミッション必須機能)とミッションの両方で考える
• 4段階のスケールにマッピングする
  • Low, Medium, High, VeriyHigh

まずは、Situated Safety Impact と Mission Impact を見て、SSVC としてはどのように考えているのかを見てみます。

Situated Safety Impact

Situated Safety Impact は、以下のように示されています。

• Deployer（Tree）の実装を簡素化するために、Mission Impact と組み合わせる物であるため、このトピックは今のところ延期します。
  • We defer this topic for now because we combine it with Mission Impact to simplify implementation for deployers.

突然の延期。。

Situated Safety Impact 自体は、Safety Impact で定義しているものを参考にようとしています。
しかしながら、あまりにも手間がかかるため、実用上では Mission Impact と合わせることで簡素化するという方向になったようです。

簡素化の為に先延ばしにされましたが、考慮すべき観点として以下が示されています。

• 安全への影響に関する決定値は、航空ソフトウェアの危険カテゴリに基づいている
• 5段階評価とする
  • None, Minor, Major, Hazardous, Catastorophic

具体的には、想定されている RTCA DO-254, 2000 では、以下のカテゴリのようになっています。

• Physical Harm/身体的危害
  • 身体的不快感、労働安全上の危険、など
• Environment Harm/環境への害
  • 物理的損害、環境的損害、広範囲な環境被害、公衆衛生上のリスク、など
• Financial Harm/経済的損害
  • 経済的損失、社会技術システム（選挙や金融網など）への影響、など
• Psycological Harm/精神的危害
  • 複数の人に対する感情的または心理的危害

これらの指標をもとに評価し、例えば「一番評価が重いものに設定する」（1つだけHazardousで、その他はMajorの場合は、Hazardousとして扱う）などが示されています。

とはいえ、SSVC 2.0 の時点では直接の評価対象にしなくてよいと思います。
本資料のこの章の意味は、このような判断基準があることを知っておく、という点にあります。

Mission Impact

組織の “ミッション（使命）に不可欠な機能” (Mission Essential Functions:MEFs) への影響で定義されています。

MEFとは「組織のミッション達成に直接関連する機能」を意味します。ミッション（使命）は組織が存在する理由であり、MEFはそのミッションに影響を与える機能を示します。

上記のように「ミッション」を特定し、ミッションへの影響を考える必要があります。

• SSVC の文書では、今後の課題とされています。
  • This paper does not exhaustively discuss how a stakeholder should answer a question; that is a topic for future work.
• FEMAガイダンスのContinuity Directive2(Fenton2017)かOCTAVE FORTE(Tucker 2018)が参考になると記載されています。
  • https://www.fema.gov/sites/default/files/2020-07/Federal_Continuity_Directive-2_June132017.pdf
  • https://insights.sei.cmu.edu/library/advancing-risk-management-capability-using-the-octave-forte-process/
• 脆弱性管理チームは、ミッションの優先順位やリスク軽減のその他の側面を理解するために、上級管理者と対話する必要があります。 との記載もありますね。

上記をもとに、おおよそ以下のような指標が提示されています。

Human Impactのまとめ

前述のように、Situated Safety Impact と Mission Impact をもとに、Human Impact を決定することになっています。

しかしながら、脆弱性毎に Situated Safety Impact と Mission Impact を個々に計算するのは現実的に不可能です。
そのため、自動で設定することが難しい Situated Safety Impact は除外し、Mission Impact で考えるようにすることが、SSVC で自動的に判断させるための肝になると考えられます。脆弱性個別の Mission Impact ではなく、対象システムの組織における位置づけで Mission Impact を設定するのが、現時点での最適解と思われます。

本論文では Mission Impact を決めるための情報が不足しているため、次に示すような別のフレームワークをもとに決めるとよいと考えます。

Mission Impactを決める

今回は、Mission Impact(=システムの価値として設定)を決めるために利用できる、2つのフレームワークを利用します。

• OWASP Risk Rationg Methodology
• デジタル庁 デジタル社会推進標準ガイドライン
  • DS-201 政府情報システムにおけるセキュリティリスク分析ガイドライン ～ベースラインと事業被害の組み合わせアプローチ～
    • 対象部分は 実質NIST SP800-63

各フレームワークの概要を示します。

OWASP Risk Rating Methodology

OWASP が公開している OWASP Risk Rating Methodology は、アプリケーションやシステム向きのリスク評価手法です。

• https://owasp.org/www-community/OWASP_Risk_Rating_Methodology

以前、以下の Blog で概要をお伝えしています。

• https://vuls.biz/blog/articles/20231019a/

全体として、リスク = 可能性 x 影響 としており、可能性と影響のスコアをつけることでリスクを可視化することができます。

• 可能性
  • 攻撃者側の要因
  • 脆弱性の要因
• 影響
  • 技術的な要素
  • ビジネスインパクトファクター

今回は HumanImpact の代替えとしてのシステムの価値 に対応するものを検討しているため、「影響」が示している部分を注視してみます。

「影響」を見積もるための要素

本来的には「攻撃が成功したときの影響」という指標ですが、裏を返せば「ビジネス上どれだけの価値があるか」を意味するかととらえてよいと思います。特に、システムの価値をどのように決めたらよいのか分からない方にとっては、どの観点で考えるのかという点の参考になると思われます。また、スコア化された評価があるので、どの程度の重大さで勘案すべきかの指標となります。

影響についての定義と、それをシステムの価値として読み変えた場合の例を示します。
※あくまで筆者の現時点での想定であり、弊社および幣サービスがこのように考えているとは限りません。

技術的な要因とビジネスへの影響について、アプリケーションやシステムに重度の影響があった場合に、どこまで影響範囲が広がるかという観点で見るとよいと思われます。

• 技術的な観点
  • 対象のセキュリティの CIA（機密性/完全性/可用性）が、どの程度サービス（前述だと”ミッション”）に影響をするかを評価
  • これに、説明責任の喪失（Loss of Accountability）度合いを加味する
    • 説明責任を果たせることは重要で、後段のビジネスインパクトの信用などにも影響をすると考えられる
    • 近年は悪意のある攻撃をすべて防げない場合もあり、その際は説明責任を果たせることが重要となる
• ビジネス影響の観点
  • 経済的損失や風評被害、プライバシー侵害は一般的に想定可能と思われる
  • コンプライアンス違反については、法的な要求（業法など）も加味する必要がある
    • ニッチな例だと、警備業法では発報（異常検知からの通報）から25分以内（または地域事情に合わせ30分以内）に現場に到着すべきとなっており、センターシステムで障害が発生した場合はこの警備業法を守れない場合がある、などが該当する

これらの要因で、平均点をとることで重大度（Severity）を決定することになっています。

本来は、ここでは解説していない「可能性を推定する為の要素」（脅威因子の要因や脆弱性の要因）と合わせて全体のリスクを決定していますが、今回は「システムの価値」という観点なので、技術的要素とビジネスインパクトを利用します。

• 本来では、技術的要素 x 可能性の要素 と ビジネスインパクト x 可能性の要素 を見比べて決定する、事になります。
• 「システムの価値」という側面では、ビジネスインパクトを主に見つつ、技術要素はビジネスインパクトの補強要素とみるのが良いと思われます。
• これでおおよそ、システムの価値として 致命的/高/中/低い を導出できると思われます。

以上をまとめると、OWASP Risk Rationg Methodology を使った「システムの価値」決定は、「技術的な要因」および「ビジネスインパクトファクター」の重大度でスコアリングできそうです。「発生可能性」は除外してよいと思われます。
あくまでここで出てきたものは指標であり、SSVC の実際の運用に合わせて調整して利用する必要があります。

なお、WEBブラウザ上で計算ができる OWASP Risk Rating Calculator もあるので、試してみるとよさそうです。

• https://owasp-risk-rating.com/

DS-201 (NIST SP800-63)

デジタル庁が出している、デジタル社会推進実践ガイドブック DS-201 ”政府情報システムにおけるセキュリティリスク分析ガイドライン ～ベースラインと事業被害の組み合わせアプローチ～” において、参考になりそうな物があるので紹介します。

• https://www.digital.go.jp/resources/standard_guidelines

P.14の「3.3. システム・プロファイルの作成」内の、「図3-2 システムの保証レベルのデシジョンフロー」が参考になりそうです。内容としては NIST SP 800-63 rev3 のものと同じようです。
図を引用しようとしましたが、文字がつぶれていたり 所々日本語が変なので、HumanImpact に対応するという点を念頭に一部書き直してみました。

本来はNIST SP 800-63 rev3で出てくる AAL（Authenticator Assurance Level: 認証システムのセキュリティ的な強度）なので「システムの価値」とは異なりますが、認証強度が必要なものほど価値が高いシステム、と読み替えてもよいでしょう。
本記事は、あくまで「システムの価値となる HumanImpact をどのように設定してよいかわからない」という方に設定するためのヒントとなることを目的としており、若干の正確性の誤差は許容できると考えます。

• https://pages.nist.gov/800-63-3/sp800-63-3.html

最初の6項目のチェック部分は、OWASP Risk Rating Methodology でも同じようなことを対象にしていたと思います。
これに対し、後段でフローを設けることで評価をしやすくなっている、と読んでよいと思います。

まとめ

OWASP Risk Rating Methodology と DS-201 を基に、SSVC の HumanImpact をどのように考えるかを書きてきました。

• まずは、OWASP Risk Rating Methodology や DS-201(NIST SP 800-63 rev3. AAL) などを使って、評価してみましょう
• 既存の仕組みを利用して評価し、適用してみたフィードバックをもとに、必要に応じてその評価値を変えてみましょう

異論があることは十分理解しますが、まずどうしたらよいのか分からないという方向けに、他のフレームワークではどのように評価を考えているのかを知っていただくことが重要と考えます。
「これは違う」「こう考えるべきというのがあるのであれば、そのように実施頂ければよいと思います。「こうしたい/あるべき」という意思ができているので、後は落としどころを探るだけです。

注意すべき点とすれば、「自分たちは超重要と考えていても、客観的に見れば”超”が付くほど重要ではない」こともありうるということです。事業の継続性など、システムではなくビジネス全体の中での位置づけを考える必要があります。そのため、システム担当者ですべてを決めるのではなく、CISOなどの経営層との話が重要になると考えます。日本ではこの点が一番難しい気もしますが…

SSVCについては、まずは想定した設定値でやってみて、運用に支障が出る判定が多ければ設定を見直すというやり方が良いと思われます。システムの価値の設定を Medium なのか High なのか で悩むよりも、まずは High に設定してやってみて想定より対応が難しければ Medium に変える、ような機動的な運用のほうが幸せになる確率は高いと思われます。機動力がないとそのような運用は難しいですが、SSVC を導入しようとしている時点でその素質はあり、大丈夫だと思います。頑張って！

脆弱性管理は、最終的には「運用で脆弱性を気にしなくてよい世界」になるのが幸せだと思われます。クラウド上で Docker 環境ですべてが構築され日ごとに image が更新されたり、マイクロサービス化/サーバレス、などいろいろ方法はあります。しかしながら、すべてがそのような環境に適合するわけでもありません。従来環境は残り、VPN-Gateway も残ります。これらは、やはり今まで通り脆弱性管理が必要となります。
脆弱性管理自体は、やらなくてよければやらないほうが良い（人間が管理せずとも自動で管理される。管理せず放置、ではない。）ことは確かなので、SSVC や EPSS、KEV Catalog などにより運用や対象選定の負荷を減らしていくことが必要です。負荷を削減するためには自動化が必要で、自動化のためには「現在の状況」をきちんと把握しておく必要があります。SBOM などもその助けになるでしょう。現状を把握するのは、やはり人間がやるしかないので、そこは頑張るしかありません。頑張って集めた情報は、自動化で利用し、運用を楽にしたいですね。

以上、SSVC の HumanImpact とシステムの価値について、私 井上が思う点を書きました。お疲れ様でした。