脆弱性管理とリスク評価

令和7年度 情報処理安全確保支援士試験にて脆弱性診断とそのリスク評価周りの問題が出題され無事爆死。
今後のトレンドになりそうな空気感を若干感じたので、個人的学習も兼ねて記事とする。

なお、本稿はIPAが公開している資料 脆弱性対応におけるリスク評価手法のまとめ_ver1.1 を下敷きにしている。

リスク評価とは - なぜトリアージを行うのか

すべての脆弱性に対応することは不可能だから。

「脆弱性」そのものを識別する番号として、CVE(Common Vulnerabilities and Exposures)というものがあり、2024年5月地点で約23万件の脆弱性が採番されている。

共通脆弱性識別子CVE概説 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構

このCVE、脆弱性が見つかるたびに採番されるわけだが、2023年度の登録実績から単純計算すると、一日におよそ70件ほどの脆弱性が報告されているようである。
その全てに対応することは現実的に不可能であり、仮に可能であったとしても、真に脅威となりうる脆弱性への対応が不完全なものになってしまいかねない。
そこで、何かしらの基準でもって、脆弱性によってもたらされるリスクを評価し、対応すべき脆弱性を見定める必要が出てくる。

リスク評価の観点

リスクを評価する際は、以下の3点を係数として考慮する。

• 脅威
• 脆弱性
• 資産

脅威

その脆弱性を用いて、攻撃者が実際に攻撃可能か、あるいは攻撃を行う可能性が高いか。
悪用実績や、攻撃コード（Exploitコード）が公開されているかなどが指標となる。

脆弱性

脆弱性そのものの深刻度。
その脆弱性が与える、システム・データへの潜在的な影響の度合い。
つまり、脆弱性を悪用することで攻撃者が何を行えるかを指標とする。
たとえば「任意コード実行」などは高く評価される。

資産

その脆弱性を抱えているシステム自体のCIAの要求度。
たとえば機密性に焦点を当てると、顧客情報を扱うようなシステムなら高く評価すべきだが、一方簡単なバッチシステムなら低く見積もることもありうる。

CVSS v4.0

ここでは、2023年10月に公開されたCVSSの最新バージョンv4.0を題材に扱う。

脆弱性の深刻度を表す国際的な指標として、CVSS（Common Vulnerability Scoring System）がある。

Common Vulnerability Scoring System SIG

リスク評価に利用可能な指標値である。
先述のCVEと紐づけて公開されることが多いため、リスク評価でよく用いられる。

CVSSの主な目的は、ベンダに依存しない共通の評価方法を定量的に示すことにある。

CVSSは主に以下3つの評価基準を有し、それぞれから脆弱性の深刻度を表すスコアを算出する。

• 基本評価基準（B）
• 脅威評価基準（T）
• 環境評価基準（E）

また、算出されるスコアは0.0 ~ 10.0で示される（高いほど深刻）。

リスク評価時には、基本評価基準（B）をベースに、脅威評価基準（T）あるいは環境評価基準（E）を組み合わせて利用する。
各組み合わせは、イニシャルを取って以下の通りに表記する。

• CVSS-B
• CVSS-BT
• CVSS-BE
• CVSS-BTE

基本評価基準

脆弱性そのものの特性を評価する基準。

大枠としては以下の2点を軸に据えて評価を行う。

• 攻撃の難易度
• 攻撃による影響

攻撃の難易度では字のごとく、その攻撃を成功させるための難易度を評価する。
たとえば、「攻撃のルート（インターネット～物理）」「攻撃の複雑さ（無条件～暗号鍵の窃取が必要）」「必要な特権レベル」など。

攻撃による影響では、その攻撃がシステムのCIA（機密性・完全性・可用性）にどれほどの影響を及ぼすかを評価する。

時間経過（対策状況）やシステムへの要求項を考慮しないため、脆弱性そのものに対するベーシックな評価として利用できる。

この基準から算出されるスコアをCVSS基本値という。
上述の特徴から、脆弱性の評価に用いる。

原則として、ベンダや公表機関が算出・評価する。

脅威評価基準

脆弱性の現在の深刻度を評価する基準。
主に「攻撃コードの公開・出現有無」や「悪用状況」などから評価を行う。
つまり、概ね攻撃される可能性の高さを指し示す。

脅威評価は以下の4段階で評価する

評価	評価名	内容
X	未定義	この項目を評価しない
A	攻撃確認	攻撃活動が報告されている、攻撃可能な状況にある
P	概念実証	実証コードは存在しているが、悪用には至っていない
U	未報告	実証コードや攻撃活動は報告されていない

この基準から算出されるスコアをCVSS脅威値という。
上述の特徴から、CVSS脅威値は脅威の評価に用いる。

ベンダなどが算出することもあるが、一般的にはユーザが算出を行う指標である。

環境評価基準

ユーザの利用環境も含め、最終的な脆弱性の深刻度を評価する基準。
脆弱性を抱えるシステムにおけるCIAそれぞれの要求度に応じて変動する。

この基準から算出されるスコアをCVSS環境値という。
上述の特徴から、資産の評価に用いる。

ユーザの環境を勘案に含めるため、ユーザが算出を行う。

KEV

KEV（Known Exploited Vulnerabilities; 悪用された既知の脆弱性）とは、実際に悪用が確認された脆弱性を掲載したカタログである。

CISA(アメリカ合衆国サイバーセキュリティ・社会基盤安全保障庁)が公開・管理している。

Known Exploited Vulnerabilities Catalog | CISA

悪用実績のある脆弱性が掲載されるため、KEVに掲載された脆弱性については脅威が極めて高いと考えることができる。
よって、KEVは脅威の評価に用いる。

以下の3点を満たした脆弱性がKEVに掲載される。

• CVEが割り当てられている
• 悪用の証拠がある、あるいは悪用が観測されている
• 明確な修復措置がある

CVEが割り当てられている

冒頭で述べた、CVE脆弱性識別子（CVE-ID）が割り当てられていること。
つまり、一意なものとして認識されている脆弱性のみが扱われる。

悪用の証拠がある、あるいは悪用が観測されている

「証拠がある」というのは、ハニーポット上での攻撃は観測されているが、実環境への攻撃成功は観測されていない状況を指す。
一方、「観測されている」というのは、実環境への攻撃成功がすでに観測されている状況を指している。

明確な修復措置がある

KEVカタログの大きな特徴。
メーカーやベンダからパッチが公開されていることを示している。
また、サポートが終了している製品の場合は、緩和策や回避策が提示されていることが示されている。

EPSS

EPSS（Exploit Prediction Scoring System）は、脆弱性対応の優先度を判断するための指標となるべく開発されたシステムである。

CVSSと同じ管理母体が公開している。

Exploit Prediction Scoring System (EPSS)

今後30日以内に脆弱性が悪用される蓋然性を一定の計算式によって算出するものとされている。
よって、脅威の評価に用いる。

日次でスコアが更新されるため、リアルタイムな指標として利用可能なのも特徴のひとつである。

https://api.first.org/data/v1/epss?cve=CVE-2021-44228

リスク評価の流れ

以上の指標を用いて、「脅威・脆弱性・資産」の3点から脆弱性に対するリスク評価を行うのであるが、日々更新される膨大な脆弱性情報のすべてにリスク評価を行うことは現実的ではない。

そこで、リスク評価を段階に分けて実施することで要対応の脆弱性を抽出し、段階的にリソースを投入することに重点を置く。
段階初期ではユーザに負荷が少ない定常的な値を指標とし、最終評価ではユーザ環境を勘案に入れ、実態に即したリスク評価を行う。

また、リスク評価の結果に応じて、実際の対応の指標を定めておくとなお良い。
一例として、以下のように4段階で定めることができる。

レベル	対応	対応日数
S	即時対応が求められる	0~3日
A	即時対応は必要としないが、優先的に対応するのが望ましい	30日以内
B	緊急の対応は不要とし、将来的に対応することが望ましい	定期メンテナンス時等
C	リスク受容が妥当であり、脆弱性への対応は行わない	対応しない

資産評価（CIA要求度）の整理

リスク評価に先立って実施されていることが望ましい。
脆弱性対応の対象となりうる自社資産に対して、あらかじめ資産評価を実施する。

資産評価は、機密性・完全性・可用性への要求度を低・中・高の3段階で評価する。
また、判定合計値を資産重要度と定める。

その資産が公開資産（インターネットへ公開されている資産）か否かについても把握しておくこと。

ただし、資産評価をあらゆる資産に対して行うというのは運用負荷が高い。
そのため、攻撃のターゲットとなりやすいアタックサーフェスを認識し、優先的に評価するとよい。

脆弱性情報の収集

脆弱性情報の収集にあたっては、公開サイトから収集する方法と、契約しているベンダ等から得る方法がある。

前者については、NVD・JVN・JPCERT/CC等のサイトを参照する。
定常的にこれらのサイトを閲覧することはコストが高いため、自動化されていることが望ましいとされている。

脆弱性情報とあわせて、脅威情報の取得も行うのが望ましい。
情報源として、KEV・JPCERT/CC 注意喚起・SNS等がある。
ただし、SNSからの情報取得については一定度のリテラシーを以て参考とする。

自社資産に影響する脆弱性について情報が得られたら、1次評価を行う。
ただし、0次評価はその脆弱性の緊急性に応じて適宜行う。

0次評価 - 攻撃の流行度に基づくリスク評価

0次評価では、緊急性が高く、即応が求められる脆弱性かを評価する。

KEVやJPCERT/CCの注意喚起などに掲載されるような脆弱性、つまり、極めて攻撃可能性が高く悪用実績が確認されている脆弱性に該当するかを評価する。
また、SNSや一般ニュース等にまで取り上げられているような脆弱性については、注目度、影響度および攻撃可能性が高い傾向があるため、これも評価の一基準とする。

評価対象の脆弱性が以上に該当した場合、次いで脆弱性を抱えるシステムが公開資産か否かに応じて対応を決定する。

• 公開資産である場合、攻撃可能性が極めて高いのであるから、原則的には即時対応を行う。
  • ただし、資産のCIA要求度や人的リソースを鑑み即時対応を行わない場合は、2次評価へ移行する。
• 非公開資産である場合は攻撃容易性が低下するので、それに従って即応の必要性も低下する。なので、この場合は2次評価へ移行する。

1次評価 - 定常的な簡易リスク評価

1次評価では、脅威と脆弱性を加味した簡易リスク評価を行う。

1次評価の目的は、公表された膨大な数の脆弱性から、対応の必要性が高い脆弱性を抽出することにある。
抽出の必要性に照らせば、この段階では可能な限り低コストで、単一のスコアが得られるものを指標とするのが望ましい。

まず脆弱性の評価に用いる指標としては、CVSS基本値を用いる。CVSS基本値については必ずベンダが算出を行うため、ユーザは値を参照するのみでよく、コストが低い。

一方、脅威の評価に用いる指標として、同CVSSにCVSS脅威値があったが、これは一般的にユーザによる算出が必要である。算出には専門的な知識を要することもあり、コストが高い。
そこで、1次評価ではEPSSを利用することにする。
先述のとおり、EPSSは今後30日間における攻撃可能性の高さを示したものであり、脅威の評価に適している。
また、機械的手段によって日次で算出される値であることから、ユーザ負荷が低いだけでなく即応性も期待できる。

EPSSを併用するもう一つの目的として、CVSS基本値のみでは取りこぼしてしまう技術的な深刻度は低いが、脅威の高い脆弱性を見逃さない事がある。

例えば、CVE-2014-0160（通称 HeartBleed）はCVSS(2.0)-Bでは5.0とかなり低いスコアが付された一方、攻撃コードの存在からEPSSは高く評価されていた

CVSS基本値とEPSS値の両者にしきい値を設け（2次マトリクス）、一定度の脅威・深刻度を有すると判断された脆弱性についてのみ、2次評価を実施する。

2次評価 - 自社環境を考慮したリスク評価

2次評価では、自社環境も加味して、その脆弱性への対応を決定する。
1次評価で算出した脅威・脆弱性の深刻度に加えて、影響を受ける自社資産が要求するCIAレベルを勘案する。
また、攻撃成立時のCIAへの影響度は、CVSS基準値を参照すればよい。

なお、0次評価のときと同じく、非公開資産に対するリスク評価は、公開資産に対するそれより低く見積もることができる。

非公開サーバにおいては、公開サーバに比べ攻撃者が脆弱性を突いた攻撃を実施する難易度や攻撃に要する時間が大きく異なることから、緊急対応が必須となる脆弱性は基本的にはないとの考えのもと

基本的な事例については、1次評価とCIA要求度の突合で充足するが、より厳密なリスク評価を行う場合にはCVSS環境値などの利用をあわせて検討する。

2次評価を以て脆弱性に対する最終評価とし、対応を決定する。
以下、再掲。

レベル	対応	対応日数
S	即時対応が求められる	0~3日
A	即時対応は必要としないが、優先的に対応するのが望ましい	30日以内
B	緊急の対応は不要とし、将来的に対応することが望ましい	定期メンテナンス時等
C	リスク受容が妥当であり、脆弱性への対応は行わない	対応しない