脆弱性対応の際に組織の事業継続性という観点でトリアージをしますが、その際にリスク評価を行う事になります。
今回は、OWASP Risk Rating Methodology（リスク評価手法）を参考に、リスク評価としてどのように考えるのか/使えるのかを記載します。

対象リソースの対訳的翻訳ではなく、要点を纏めてお伝えします。

※毎回のことながら、本記事については筆者の見解であり、弊社及びOWASPでの見解ではない事に注意してください。読む人の数だけ正解があると思いますので…

OWASP Risk Rating Methodologyとは

OWASP Risk Rating Methodology

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

OWASPのリスク評価手法は、アプリケーションのセキュリティ向けにカスタマイズされた物になっているようです。
一般的なリスク評価手法は下記のように複数参照できますが、最初に参照するには負担が大きいような気もします。まずはOWASP Risk Rating Methodologyで軽く始めるのが良いと思います。

• NIST; SP 800-30 Guide for Conducting Risk Assessments¹
• Canadian Centre for Cyber Security; Harmonized TRA Methodology(TRA-1)²
• Mozilla; Assessing security risk³
• Mozilla; Rapid Risk Assessment⁴

リスク評価

脆弱性を発見することは重要ですが、ビジネスに関連するリスクを推定できることも同様に重要です。
組織のセキュリティ対応はビジネスへの影響を防ぐ/軽減するために行うもので、全ての脆弱性に対応することが目的ではありません。
何らかのリスク評価システムで画一的に評価できれば良いのですが、ある組織にとって重大なリスクであっても、別の組織ではそれ程重要ではないという場合もあります。その為、組織に合わせて「カスタマイズできる」フレームワークが必要になります。

OWASPのフレームワークは、正確なリスク推定を行いつつ、使いやすくなるように設計した、とのことです。

アプローチ

標準的なリスクモデルでは、リスク=可能性×影響で定義します。

OWASP Risk Rating Methodologyでは可能性と影響を構成する要素を分類しており、これらの組み合わせでリスクの全体的な重大度を判断する方法をとっているようです。

Step1 リスクの特定

最初の段階としてリスクの特定を行います。これは、悪意のあるものの攻撃や残存する脆弱性、侵害時にビジネスへの影響がどの程度どこにあるのか、等を検討します。
おそらくこの部分が一番重要かつ難しい場面になると思います。ビジネスへの影響は経営観点も必要であり、またリスクの対象となるものの棚卸も必要になります。

Step2 可能性を推定するための要素

次は発生の可能性（likelihood）を推定します。特定の脆弱性が、攻撃者により発見され、悪用される可能性がどの程度あるか、の大まかな指標となります。

判断要素としては、”攻撃者側の要因”と”脆弱性の要因”が想定されています。そして、影響度によってOWASPでは数値を振っているようです（1は影響が少ない、9は影響が大きい）。

攻撃者側の要因

• スキルレベル
  • 攻撃者はどの程度技術的に熟達しているか
• 動機の程度
  • 攻撃者はこの脆弱性を発見して悪用する動機はどの程度か
• 機会の必要性
  • 攻撃者はこの脆弱性を見つけて悪用するには、どのようなリソースと機会が必要か
• 攻撃者のサイズ（規模/範囲）
  • 攻撃者はどのような規模/所属なのか

脆弱性の要因

• 発見の容易さ
  • 攻撃者がこの脆弱性を発見するのはどれくらい簡単か
• 悪用の容易さ
  • 攻撃者がこの脆弱性を実際に悪用するのはどれくらい簡単か
• 認識されているか
  • この脆弱性は攻撃者にどの程度知られいているか
• 侵入検出可能か
  • Exploitが検出される可能性はどれくらいか

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

攻撃が成功したときの影響を見積もります。 OWASPでは以下の2種類の影響について重視しています。

• 技術的影響
  • アプリケーション、それが使用するデータ、それが提供する機能、に対する技術的影響
• ビジネスインパクト
  • アプリケーションを運用するビジネスや企業への影響

最終的には「ビジネスへの影響の方が重要」としています。しかしながらビジネス影響を検討する全ての情報がそろわない場合もあるため、その場合は技術的影響で意思決定をすることが想定されています。

技術的な影響要因

• 機密性の喪失
  • 開示される可能性のあるデータの 量と密度 はどれくらいになるのか
• 整合性の喪失
  • どれだけのデータが整合性が無くなる（破損する）可能性があるのか
• 可用性の損失
  • どの程度サービスが失われるか
• 説明責任の損失
  • 攻撃者の行動を追跡できるか

ビジネスインパクトファクター

• 経済的損害
  • Exploitによりどの程度の経済的損害が発生するか
• 風評被害
  • Exploitによりビジネスに影響を与えるような風評被害が発生するか
• コンプライアンス違反
  • コンプライアンス違反はどの程度か
• プライバシー侵害
  • 個人を特定できる情報はどの程度開示されるか

Step4 リスクの重大度の判断

Step2,3の情報を使い、リスクの重大度の判断をします。

再現可能な評価方法として、各要素の平均値で判断することを提示しています。

• 「攻撃者の要因」と「脆弱性の要因」の平均値による、「可能性」の評価
  • 攻撃者の要因である4項目と、脆弱性の要因である4項目、これらすべての平均値とする
  • 0.0-3.0未満を”低”、3.0-7.0未満を”中”、7.0以上を”高”と判定することを提示しています
• 「技術的影響」と「ビジネスへの影響」による、「インパクト」の評価
  • 基本的には、可能性とビジネスへの影響で評価し、ビジネスへの影響が不確定の場合は技術的影響で判断する
  • 0.0-3.0未満を”低”、3.0-7.0未満を”中”、7.0以上を”高”と判定することを提示しています

これらを全体的なリスクの重大度のマトリックスに当てはめて判断します。

例として、例えば各種要因が以下のように記録されたとします。

• 攻撃者の要因及び脆弱性の要因で全体平均値をとると、4.375となった
  • これは判断基準から、中程度と分類できた
• 同様に技術的要因とビジネスインパクトも平均をとる
  • 技術的要因は、7.25で高となった
  • ビジネスインパクトは、2.25で低いとなっている
• 全体的なリスク重大度判断の表に適合させるが、技術的影響要因を主としてみるか、ビジネスインパクトを主としてみるかで判断が異なることになる
  • 基本的にはビジネスインパクトを重視する為、中程度、と判断できる。
  • ビジネスインパクトを判断できない場合は、技術的影響要因を考慮して 高 と判断することも可能

Step5 何を修正するかを決定する

リスクが分類されると、修正すべき内容の優先順位を付けることができます。原則として、最も重大なリスクを最初に修正する必要があります。
また、全てのリスクを修正する必要があるわけではなく、リスクに基づき、損失と比べた修正コストに基づいて判断されるべきです。修正コストが膨大な場合、リスクの移転を検討するなど、脆弱性管理以外の方法に頼る必要があると思われます。

一般的には、リスクへの対応は以下のように考えます。⁵

1. リスク回避
2. リスク軽減（低減）
3. リスク移転
4. リスク保有

リスク回避は「リスクを生じさせる要因に関与し、リスクが発生する可能性を取り去る」事を意味します。
インターネットからの不正侵入というリスクに対しインターネットとの接続を断つ、脆弱性に対してアップデートをする、該当製品の仕様を終了する、等が例示されます。

リスク軽減（低減）は「リスク源の除去、起こり易さの低減、結果の変更」を意味します。
データの搾取というリスクに対し暗号化や入退室管理等のセキュリティ施策を行う、脆弱性の軽減設定を行う、等が例示されます。

リスク移転は「（保険等により）リスクを他に移す」事を意味します。
マルウェアやランサムウェアに対して保険に加入して対応する、システムの運用保守を外部に委託する、等が例示されます。

リスク保有は「そのリスクにより起こり得る損失を受容する」事を意味します。
脆弱性により起こりうることは事業に影響を及ぼさないので対応しない、等が例示されます。

脆弱性対応の観点では、リスク回避（アップデート）やリスク軽減（設定変更等の軽減策）の策をとることになると思われます。リスク移転は脆弱性対応というよりリスク管理の範疇で、脆弱性対応としては失敗と考えてよいかもしれません。

Step6 リスク評価モデルのカスタマイズ

組織や業態によって、本評価モデルをカスタマイズする必要がある旨を説いています。

• 要素の追加
  • 軍事用途では人命や機密情報損失に関連する影響要因、等が判断材料として挙げられると思われます。その為、「攻撃者の機会」「暗号化アルゴリズムの強度」を可能性要因として追加することが例示されています。
• オプションのカスタマイズ
  • 情報の分類を利用者に合わせて変えることが例示されています。
  • 例えば、”脆弱性の要因”の”発見の容易さ”は4段階で分類されていますが、これを利用者に合った内容に変更するなどを意味していると考えます。
• 重みづけ係数
  • 分類している各種要因は全て同等に重要としていますが、これに重みづけをすることが例示されています。
  • 例えば、ビジネスインパクトについては”経済的損害”を他の要素より重みを付ける(1.5倍する)等が想定されると考えます。

まずはカスタマイズせずに利用し、利用している中で必要になった場合に変更を加えるのがよいでしょう。

OWASP Risk Rating Methodologyでの記載は以上になります。

脆弱性対応ではどのように考えればよいのか

さて、脆弱性管理ではどのように利用できるのかを考えていましょう。

以下の点は、特に考えておく必要があると思います。

• 組織としては、ビジネスへの影響を重視して対応判断する必要がある
• 脆弱性修正コストと損失を比較して、対応判断をする必要がある
• 脆弱性それ自体もあるが、環境情報（攻撃者側の情報、ログ管理などのシステム状況）等もリスクには関連する

ビジネスへの影響を特定できるように、システム毎にどのような情報資産を持つのか、等の整理をしておくとよいと考えます。
また、”脆弱性の要因”の”侵入検出”など、プラットフォームとして別途管理施策をしておくことも重要です。

SSVC（Stakeholder-Specific Vulnerability Categorization）⁶も同様の基準で判断しているので、そちらも参考にするとよいでしょう。

まとめ

脆弱性対応において、リスク評価は必要な物です。そして、できるだけフレームワークのような再現可能な方法で判断できることが望ましいと考えます。
まずはOWASP Risk Rating Methodologyを対応のための評価やトリアージとして使い、システムや組織のリスク管理としてNIST SP800-30辺りを読み込み/適用していくとよいように思われます。

(あと、OWASPのページをChrome等でWeb翻訳したもので十分読めると思いますので、原文確を確認いただくと良いと思います。)

参考