今さら聞けない！CVEとCVSS入門 〜セキュリティ脆弱性対策の基本〜

「この脆弱性、本当に対応が必要なの？」、「パッチ適用の優先順位をどう決めればいい？」、「経営層への報告で、どうリスクを説明すれば？」
セキュリティ担当者なら、このような悩みに直面したことがあるのではないでしょうか。脆弱性対応の優先順位付けや、経営層への報告など、日々の業務で直面する判断の場面で、客観的な基準となる指標が求められています。特に近年では、クラウドサービスの普及やデジタルトランスフォーメーションの加速により、セキュリティリスクの評価と対応の重要性が増しています。このような脆弱性に適切に対応するために、世界中で共通の「モノサシ」として使われているのが、CVEとCVSSという二つの重要な指標です。本コラムでは、これらの基礎から実践的な活用方法まで、具体例を交えながら解説していきます。尚、本コラムは独立行政法人情報処理推進機構（IPA）の「脆弱性対策の効果的な進め方」や「共通脆弱性評価システムCVSS概説」を参考に執筆しています。

CVE（シーブイイー）とは何か

CVE（Common Vulnerabilities and Exposures）（シーブイイー）は、公開された脆弱性に対して固有の識別番号を付与する仕組みです。例えば、「CVE-2014-0160」という識別番号は、いわゆる「Heartbleed」と呼ばれる、OpenSSLの重大な脆弱性を示しています。この脆弱性では、暗号化通信に使用されるメモリの内容が漏洩する可能性があり、多くのウェブサイトに影響を与えました。
CVE IDは、「CVE-」というプレフィックスの後に、発見された年と、その年における通し番号で構成されています。たとえば、「CVE-2024-1234」であれば、2024年に発見・報告された1234番目の脆弱性ということになります。最近の具体例を挙げると、2024年に発見されたマイクロソフトタスクスケジューラーの脆弱性「CVE-2024-49039」があります。この脆弱性の悪用を成功させた攻撃者は、通常であれば特権アカウントのみに制限されているRPC機能を実行できるようになるとのことです。この事例からも分かるように、CVEは脆弱性の特定と情報共有において重要な役割を果たしています。
CVE情報は、米国国立標準技術研究所（NIST）が運営するNVD（National Vulnerability Database）や、日本ではIPAが運営するJVN iPediaなどで確認することができます。これらのデータベースでは、各CVEの詳細な技術情報や対策方法を確認することができます。

因みに、日本ではIPAとJPCERT/CCが共同で運営している脆弱性対策情報ポータルサイト「JVN」があります。これは日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供してますが、CVE採番の枠組みに参加しています。その為、JVNで管理されている脆弱性もCVEで採番されているものもあります。しかし、中にはCVEで採番されないJVN独自の脆弱性も存在する場合があるため、日本固有の脆弱性を探す場合はJVNを参考にした方が良いでしょう。脆弱性を調べたい場合、前述した「JVN iPedia」で検索が可能となっています。

CVSS（シーブイエスエス）とは何か

CVSS（Common Vulnerability Scoring System）（シーブイエスエス）とは、情報システムの脆弱性の深刻度を評価するための業界標準の手法として広く認知されています。「共通脆弱性評価システム」と呼ばれるこの指標は、0.0から10.0までのスコアで脆弱性の危険度を定量的に表現し、高いほど深刻度が高いことを示します。この評価値は「脆弱性の特性」、「攻撃状況」、「システムの重要度」の要素を考慮して判定します。例えば、脆弱性の特性が「クロスサイトスプリクティング」、現在の攻撃状況として「攻撃実績あり」となり、システムの重要度が「対外システム」の場合、攻撃実績が既にあり、社外向けのシステムの為重要度が高いことから、深刻度も高くなります。因みに先ほど紹介したHeartbleedの脆弱性は、CVSSスコア7.5という高い値が付けられました。この評価システムの重要性は、近年発生した重大なセキュリティインシデントの対応において、特に顕著となっています。
尚、CVSSにはバージョンのVer2とVer3があり併記されていることが多く、またVer4も出ていますが、ここではVer3の評価基準で解説していきます。 では次から、CVSSのスコアリングや評価方法について解説します。

CVSSスコアの見方

CVSSには環境や状況を踏まえ3段階あり、「基本評価基準」、「現状評価基準」、「環境評価基準」です。上から順番に評価していきます。 まず「基本評価」ですが、これは脆弱性そのものの特性を評価します。例えば、システムの乗っ取りが可能なら危険大、攻撃方法が難しければ危険小といった具合です。この評価は、時間の経過で変化することはなく、固定値となります。
次に「現状評価」を行います。これは、現時点での評価です。攻撃が実際に起こっているのか？パッチはあるのかなど、現時点で攻撃を受ける危険性があるかという点で評価します。例えば、ゼロデイ攻撃があれば危険大、最新パッチ提供ずみなら危険小といった具合です。この評価は、刻々と変化する攻撃状況を評価するため、日々変化していきます。
最後に「環境評価」を行います。これは、自分たちの環境に応じた評価です。脆弱性の基本及び現時点での深刻度はわかりましたが、自分たちの環境として攻撃される条件がなければ、結果として危険は少なくなります。例えば、基本の深刻度は高かったが、自社環境ではファイアウォールを導入しているため深刻度は小であった、といった具合です。環境評価は、二次的な被害も含めて最終評価を行います。利用者の環境のため、自社で評価します。迅速な評価を行うため、事前にシステム毎に環境評価を実施しておくと良いでしょう。

では、各評価についてもう少し深堀していきます。

基本評価基準

まず「基本評価」ですが、脆弱性そのものを評価します。ベンダーやセキュリティ関連企業が評価をし、時間や環境が変化しても数値は変わりません。その数値は攻撃の難易度と影響から算出されます。そしてその数値から深刻度が判定されるのです。

まず攻撃の難易度とは、攻撃者がシステムを容易に攻撃できるかを判断するもので、評価項目として攻撃元区分、攻撃条件の複雑さ、必要な特権レベル、ユーザー関与レベルがあり、この情報を元に評価します。
次に攻撃による影響とは、情報のCIA、つまり情報システムに求められる3つのセキュリティ特性、「機密性（ Confidentiality Impact ）」、「完全性( Integrity Impact ）」、「可用性( Availability Impact ）」に対する侵害影響で評価します。
この2つをかけ合わせた結果が、CVSS基本値（Baseスコア）と呼ばれるこの基準の深刻度になります。因みに深刻度は注意から緊急までの4段階あり、「現状評価基準」「環境評価基準」同じスコアを利用します。例えばCVSS8.2の場合、深刻度重要の7.0～8.9の間にあたるので、「重要」と判断できます。

次に、深刻度を算出する上での評価項目をまとめました。

「攻撃元区分」

どこから攻撃が可能かを評価します。例えばインターネット経由が可能な場合「ネットワーク」対象を物理的に操作する必要がある場合は「物理」となります。物理の場合、例えばパソコンから直接ログインして攻撃するためハードルが高く、危険度としては小さくなります。反面、ネットワーク経由の場合、外部からの攻撃が可能となり危険度が一番大きくなるのです。

「攻撃条件の複雑さ」

攻撃成功の条件が複雑か否かで評価します。攻撃者によって制御できない攻撃条件がある場合は「高」、ない場合は「低」となります。総当たり攻撃や事前の情報収集などは、「高」にあたります。なお、攻撃者のスキルは考慮されません。

「必要な特権レベル」

攻撃に必要なアクセス権限のレベルで評価します。管理者権限が必要な場合は「高」、その他権限が必要な場合は「低」、権限が不要な場合は「なし」となります。

「ユーザー関与レベル」

ユーザーの関与度で評価します。ユーザーの操作が必要な場合は「要」です。例えばクロスサイトスプリクティングのように、 リンクをユーザーにクリックさせる必要がある場合は「要」となります。

「スコープ」

攻撃の影響範囲で評価します。他のコンポーネントにまで及ぶ場合は「変更あり」、及ばない場合は「変更なし」となります。クロスサイトのように、脆弱性の影響がユーザーのブラウザ上に及ぶものは「変更あり」となります。

「機密性」「完全性」「可用性」

「機密性」「完全性」は、すべてまたは重大情報の漏洩や改ざんが可能な場合「高」、一部は「低」となり、「可用性」は、完全に停止または持続的パフォーマンス低下の場合「高」、一時的は「低」となります。なお、一次被害とその悪用条件のみで評価し、例えば管理者の認証情報漏えいは、一次被害として機密性のみ影響ありと判断します。 このような評価項目でベースとなる危険度を判断し、脆弱性そのものの特性を評価するのです。

現状評価基準

次に現状評価です。これは刻々と変化する攻撃状況を評価するものです。ベンダーや脆弱性を公表する組織などが、脆弱性の現状を表すために評価する基準です。攻撃コードの出現有無や対策情報が利用可能であるかといった基準で評価し、CVSS現状値（Temporalスコア）を算出します。この評価は時間の変化に応じて評価も変化する為、危険度も増していきます。

さて評価項目ですが、基本と同様に右に行けば危険度が増します。ところで選択肢に「未評価」がありますが、これは評価しないと選択した場合となることにご注意ください。

「攻撃される可能性」

「攻撃コードや攻撃手法が実際に利用可能であるか」を評価します。攻撃コードを必要としない、またコードがどんな状況でも利用可能な場合は「容易に攻撃可能」、攻撃コードが存在、またほとんどの状況で使用可能な場合は「攻撃可能」、実証コードが存在している、完成度の低いコードが存在している場合は「実証可能」、攻撃コードや実証コードが利用可能でない、攻撃手法が理論上のみで存在している場合は「未実証」となります。

「利用可能な対策レベル」

ベンダーから正式パッチが提供され、かつ、適用、利用可能な場合は「正式」となり、「なし」は対策がない、もしくは、対策があっても適用できない場合となります。

「脆弱性情報の信頼性」

開発者自身が確認している場合は「確認済」、セキュリティベンダー等から複数の非公式の情報がでている場合「未確証」、相反する情報など未確認の情報が存在する場合は「未確認」となります。

このように「基本評価」を元に現在の状況を判断するのが「現状評価」となり、もし攻撃か各地されていた脆弱性の場合は、大変危険な状態だということがわかるのです。

環境評価基準

最後に環境評価です。利用者環境における脆弱性の深刻度について、二次的な被害も含めて、最終的な評価となるCVSS 環境値（Environmentalスコア）を算出します。利用者環境のため、皆さんが評価します。迅速な評価を行うために、事前に環境評価を実施しておくと良いでしょう。

では評価項目についてです。選択肢となる「危険度」と「未評価」については環境評価で説明した内容と同じです。機密性、完全性、可用性の要求度について、壊滅的な影響がある場合は「高」、深刻な影響がある場合は「中」、一部影響に留まる場合は「低」とします。この指標は、資産管理におけるリスク特定を行う際に判定した数値を置き換えて利用すればOKですが、事前に資産の棚卸とリスク特定をしておきましょう。 

そして最後に、環境条件を加味して最初の基本評価の再評価を行います。基本評価の再評価の為、基本と同じです。ですので説明は割愛しますが、利用者環境に併せて再評価を行う、もしくは緩和策の適用後についてリスクを再評価します。これをもって、利用者環境に合わせた最終的な評価となるのです。

これまで３つの評価について説明しましたが、優先度の判断基準に用いる場合、基本評価だけでなく、攻撃状況やシステムへの影響度を踏まえて総合的に判断することが望まれます。それぞれの評価については、基本は脆弱性自体の危険度や技術的特性、現状は攻撃コードの存在有無や実際の攻撃発生状況、環境は各システムの重要度やシステムの公開範囲、といった要素を踏まえて検討し、最終的には環境評価まで判定できることが望まれます。例えば下記の例ではDDoSの場合、基本は低いが現状や環境を踏まえると高くなり、SQLインジェクションの場合は逆で、基本は高いが、環境を踏まえると低い評価になることもあります。

ここまでCVSSについて説明してきました。基本評価や現状評価はベンダーや脆弱性を公表する組織が算出しますが、環境評価は皆さんで評価することとなります。数ある脆弱性やシステムに対して、環境評価まで算出するのは難しい場合もありますが、その時は優先度と対応要否の判断を分けると良いです。例えば、優先度判断は基本と現状評価で、対策を行うかは環境評価も含めて総合的に判断します。環境までは難しくても、基本評価をすることでベースとなる深刻度がわかりますので、まずはここを起点に対応を考えましょう。

CVEとCVSSの実践的な活用方法

次に、実際の組織での活用方法を具体的に見ていきましょう。例えば、あるシステム管理者が新しい脆弱性情報を受け取ったとします。まず、CVE IDを使って、NVDやJVN iPediaで詳細情報を確認します。そして、CVSSスコアを確認し、対応の優先度を決定します。 よく例示される基準としては、リスクに応じた対応期限を設定します。リスク深刻度に応じて1か月以内、3ヵ月以内、半年以内・・・といった形です。期限設定については、組織の状況や脆弱性の影響度などを総合的に各組織で判断して決めていきます。 ここでCVSSの活用例を1つご紹介します。

2021年12月に発生した「Log4Shell」（CVE-2021-44228）の事例は、CVSSの重要性を示す代表的な例です。この脆弱性はCVSSスコア10.0という最高値を記録し、実際に多くの組織がこの評価を基に緊急の対応を行いました。Apache Log4jという広く使用されているログ機能のライブラリに存在したこの脆弱性は、リモートからコード実行が可能という極めて深刻な問題でした。あるECサイトを運営する企業では、この脆弱性の報告を受けて即座に対応チームを編成。CVSSの各評価項目を確認しながら、自社システムへの影響を詳細に分析しました。攻撃の容易さ、必要な権限レベル、影響範囲などの評価結果から、クリスマス商戦直前にもかかわらず、システムの一時停止を含む緊急対応を決断したのです。一方、同年に発生したWindows環境における「PrintNightmare」（CVE-2021-34527）は、基本スコア8.8と評価されました。この脆弱性も重大ではありましたが、特定の条件下でのみ影響が生じる性質から、Log4Shellとは異なる対応が可能でした。ある製造業では、この評価を基に工場の制御システムと事務系システムで異なる対応スケジュールを設定。生産への影響を最小限に抑えながら、計画的なパッチ適用を実現しました。
またある企業のセキュリティチームでは、CVSSを活用した効果的な優先順位付けを実践しています。先月のセキュリティアップデートでは、Webサーバの脆弱性（CVSS: 9.8）が発見され、24時間以内の緊急対応が実施されました。同時期に報告されたデータベースの脆弱性（CVSS: 7.5）は週内の対応とし、社内システムのUI不具合（CVSS: 3.2）は次回の定期メンテナンス時の対応として計画されました。
このような優先順位付けは、組織のセキュリティポリシーにも反映されています。ある製造業では、CVSSスコアに基づいて明確な対応基準を設定しています。スコア9.0以上の脆弱性はCISOの承認のもと24時間以内の対応が必須とされ、即時に経営会議への報告が行われます。7.0から8.9の脆弱性については、セキュリティ管理者の判断のもと1週間以内の対応が求められ、週次報告の対象となります。

このように、組織ごとにポリシー設定や対応スケジュールなどの基準に利用し、脆弱性の対応をしていくことになるのです。

CVSSを使う際の注意点

CVSSの活用には、スコアだけでなく、現在のビジネスのおける背景の考慮も重要です。ある企業では、社内の会計システムで発見された脆弱性（CVSSスコア6.5）に直面しました。通常であれば中程度の優先度となるこの問題でしたが、決算期直前であることを考慮し、優先度が引き上げられました。このケースでは、CVSSスコアに加えて、決算業務への影響リスク、法令遵守の必要性、レピュテーションリスクなど、総合的な判断が行われたのです。
また、脆弱性の評価は時間とともに変化する可能性があることも重要です。Apache Struts2の脆弱性では、初期評価時にCVSSスコア7.5と判定されましたが、1週間後に攻撃コードが公開されたことで、実質的な危険度が上昇し、即時対応が必要となりました。このように、CVSSは静的な指標ではなく、状況に応じて再評価が必要となることがあります。

脆弱性対策のアウトソース

近年、ネットワーク機器の脆弱性を狙ったサイバー攻撃が急増しており、多くの企業様がその対策に頭を悩ませています。特に問題となるのが、上記で述べた通り日々新たに発見される脆弱性情報の収集と分析、そして適切なタイミングでのパッチ適用です。これらの作業には専門的な知識と多大な時間が必要となります。
「ALSOK UTM運用サービス」では、このような課題を解決するため、管理するUTMの脆弱性情報の収集からパッチ適用まで、すべてを月額料金内でサポートいたします。セキュリティの専門チームが24時間体制で最新の脆弱性情報を監視し、重要度の判断から対応までを一貫して代行。システム管理者様の運用負荷を大幅に軽減しながら、常に高度なセキュリティレベルを維持することが可能です。

まとめ