脆弱性管理とは? ~脆弱性管理の基礎知識~
更新日:2024-12-27
年々、脆弱性の報告件数は増え、脆弱性がウイルスや不正アクセスなどの攻撃に悪用される事件も増加しています。
下の図は、登録されている脆弱性(CVE)の件数の推移です。
脆弱性が増加する一方で、どのような脆弱性から優先的に対策していけばよいでしょうか?
参考となる脆弱性管理の方法について解説します
1. 脆弱性管理はなぜ必要なのか?
脆弱性管理とは?
脆弱性管理とは、サーバーなどのシステムに内在するソフトウェアについて、脆弱性情報を収集し、システムの評価を行ない、脆弱性対応を計画し、脆弱性対応(緩和策の実施やセキュリティパッチの適用)を行なう一連の流れを指します。
どのようなメリット(デメリット)があるか
- 脆弱性管理を行うメリット
- システムに内在するソフトウェアの脆弱性情報を把握できる
- サイバー攻撃の標的になりづらい
- 法令・規制遵守(コンプライアンス)
- 脆弱性管理を行わないデメリット
- 悪意をもった攻撃者に放置している脆弱性を悪用されてサイバー攻撃を受ける可能性がある
- サイバー攻撃されるとブランドイメージの毀損や株価の低下が起こる可能性がある
- サービス廃止や長期間の利用停止を余儀なくされる場合がある(これらの復旧にかかるコストは 数千万〜数億円 と言われています)
2. 脆弱性管理を始めるポイント
脆弱性情報をどこから入手するか
脆弱性には、それぞれに番号が割り当てられています。番号は CVE(Common Vulnerabilities and Exposures) と呼ばれ、アメリカの MITRE 社によって管理されています。報告者は脆弱性を見つけたら MITER 社へ報告する、あるいは MITER 社と連携する組織(CNA) に報告することで CVE として脆弱性を登録することができます。
脆弱性情報に関する公的なサイトには以下のようなものがあります。
【脆弱性情報を取得する場合】
CVE
(Mitre)
Mitre 社が公開している CVE のサイトです。CVE の検索や脆弱性の報告が可能です。
CVE ごとに、脆弱性に関する以下の情報が掲載されています。
- CVE-ID:CVE 番号
- Description:脆弱性の説明
- Reference:公式ベンダー情報などの参考情報
- Assigning CNA:登録した組織
- Date Record Created:登録した日付
また、CVE Descriptioopn に下で説明する NVD へのリンクも掲載されています。
NVD
(National Vulnerability Database)
NVD は、各 CVE を評価した結果のデータベースです。アメリカ国立標準技術研究所(NIST)が管理しています。NVD
では、ベンダーに依存しない共通の CVE の評価方法として、CVSS(Common Vulnerability Scoring System)
と呼ばれるスコアを利用します。
IPA:重要なセキュリティ情報一覧
日本語の脆弱性情報には、IPA が公開している「重要なセキュリティ情報」があります。放っておくとインシデントにつながる危険性の高い脆弱性について随時公開されています。これらには、脆弱性の影響度に応じて、緊急度が割り当てられています。[1]
JVN (Japan Vulnerability Note)
JVN
は、日本で使用されているソフトウェアなどの脆弱性関連情報と、その対策情報に関するレポートが掲載されています。JPCERT/CC と IPA が共同で運営しています。
JVN iPedia
JVN iPedia は、JVNに 掲載される脆弱性対策情報のほか、国内外問わず公開された脆弱性対策情報がデータベース化されています。JVN では、各脆弱性対策情報データベース登録番号ごとに脆弱性に関する以下の情報が掲載されています。
- 脆弱性対策情報データベース登録番号
- CVSS による深刻度
- 影響を受けるシステム
- 想定される影響
- 対策
- ベンダー情報
- CWE による脆弱性タイプ
- CVE 情報
- 参考情報
- 更新履歴
【特定のOSやソフトウェアの脆弱性を調べる場合】
OS やソフトウェアの公式ベンダー OS やソフトウェアの各公式ベンダーが、該当製品における脆弱性に関する情報を公開していることがあります。また、脆弱性情報を定期的にメールなどでユーザーに提供しているベンダーも存在します。
たとえば、Cisco にはセキュリティアドバイザリ[2]があり、Cisco 製品の脆弱性について公開されています。ここでは、脆弱性の概要、該当するバージョンや製品、回避策等が掲載されます。
Cisco の他に、Microsoft[3] やオープンソースコミュニティの
Debian[4] なども、該当ソフトウェアに対する脆弱性の情報を公開しています。お使いの OS やソフトウェアに影響する脆弱性を確認する場合は、まずは公式のベンダーの情報を確認することが確実です。
2021年に話題になった sudo の脆弱性では、以下のような情報が公開されました。
【sudo の脆弱性】
各種ベンダー
このように、公式の情報に紐付いた情報が公開されています。
脆弱性の緊急性をどのように判断するか
脆弱性の評価基準として、脆弱性を評価しているデータベース NVD※ に掲載される CVSS が一般的に用いられています。 CVSS スコア を利用することで、システムにおける脆弱性の重大性について一貫した総合的な評価が可能です。また、対応すべき脆弱性の優先度づけが明確になります。ただし、基本標準のスコアだけで判断するのではなく、3 つの評価基準を適切に評価することが重要です。(3 つの評価基準の評価方法については後述します)
※NVD は、NIST が管理している各脆弱性(CVE) を評価した情報のデータベースです。評価結果には、CVSS、CWE、CPE などが利用されます。
脆弱性を評価する CVSS とは何か?
CVSS は、脆弱性の特性と重大性を評価するための標準化されたフレームワークです。CVSS によって算出される結果は「 CVSS スコア 」などと呼ばれます。数多く存在する脆弱性に対して、一貫性のあるスコアを算出することが可能なため、脆弱性の対処のための優先度づけに利用されることがあります。2015年には、CVSS V3 のバージョンが公開されました。2019年には V3 の標準の定義が明確化された CVSS V3.1 がリリースされています。
このCVSS V3.1 では、以下の3つの基準を利用してスコアが算出されます。
- 基本評価基準(Base Metrics)
- 現状評価基準(Temporal Metrics)
- 環境評価基準(Environmental Metrics)
【CVSS V3.1 基本標準 Base Metrics】
基本標準は、時間の経過とともに一定であり、さまざまな環境全体において一貫した脆弱性の重大度を反映します。以下の要素から計算されます。
- 攻撃元区分(AV:Attack Vector)
- 攻撃条件の複雑さ(AC:Attack Complexity)
- 必要な特権レベル(PR:Privileges Required)
- ユーザー関与レベル(UI:User Interaction)
- スコープ(S:Scope)
- 機密性への影響(情報漏えいの可能性、C:Confidentiality Impact)
- 完全性への影響(情報改ざんの可能性、I:Integrity Impact)
- 可用性への影響(業務停止の可能性、A:Availability Impact)
基本標準のスコアには、対応する数値によって Severity や深刻度、重大性と呼ばれる脆弱性のレベルが定義づけられています。
- 重大性 Severity 基本標準スコア Base Score
- 緊急 Critical 9.0~10.0
- 重要 High 7.0~8.9
- 警告 Medium 4.0~6.9
- 注意 Low 0.1~3.9
- なし None 0
【CVSS V3 現状評価基準 Temporal Metrics】
現状評価基準は、悪用可能なコードの可用性など、時間の経過とともに変化する要因に基づいて、脆弱性の基本評価基準のスコアを調整します。
以下の要素から計算されます。
- 攻撃される可能性(E:Exploit Code Maturity)
- 利用可能な対策のレベル(RL:Remediation Level)
- 脆弱性情報の信頼性(RC:Report Confidence)
【CVSS V3 環境評価基準 Environmental Metrics】
環境評価基準は、特定のシステム環境に合わせて、緩和策などの要因に基づいて上記 2 つのスコア(Base / Temporal Metrics)を調整します。以下の要素から計算されます。
- 対象システムのセキュリティ要求度 (CR、IR、AR:Security Requirements)
- 環境条件を加味した基本評価の再評価 (Modified Base Metrics)
【CVSS 計算機】~CVSSスコアリングの仕組みは?
上記、3 つの評価基準の関係について、次のように図にまとめました。
CVSS のスコアの仕組み < 3 つの評価基準の評価方法について>
ここで 3 つの評価基準を計算機で計算することで 、CVSS 3 つの基準値からなる脆弱性の重要性を把握することが可能です。NVD で公開される CVSS の情報は、基本標準 (Base) のスコアのみ、あるいは基本標準 (Base) と現状評価標準 (Temporal) のスコアのみが公開されるので、ユーザーが環境評価基準 (Environment) のスコアを追加して、全体の CVSS のスコアを計算します。CVSS スコアは以下のサイトの計算機から算出することができます。
- FIRST : CVSS 計算機
- NIST NVD : CVSS 計算機
- 各脆弱性詳細ページについて:Severity の項目内の Base Score (数値)をクリック
- JVN iPedia
- 各脆弱性ページについて:CVSSv2、または CVSSv3 の基本値(数値)をクリック
【CVSS V2 と CVSS V3 の違い】
冒頭のように、現在CVSSの最新版はV3です。では以前のCVSS V2 と比べて、 どのような変更が加えられたのでしょうか? CVSS V3 には、以下のような違いがあります。
- 基本標準要素の変更
- 基本標準要素の追加
- ユーザー関与レベル
- スコープ
- 必要な特権レベル
- 評価対象の変更
- 影響を受ける範囲の評価ではなく、重要な情報に対する影響の評価
- 環境評価基準要素の追加
V2 では、攻撃対象となるホストやシステム全般への影響を評価する要素のみでしたが、V3 では、環境条件を加味した基本評価の再評価 (Modified Base Metrics) が追加され、システムの実態に合わせて評価することができます。
たとえば、環境条件を加味した基本評価の再評価には「緩和策後の必要な特権レベル (MPR:Modified Privileges Required) 」という項目があり、脆弱性のあるコンポーネントを攻撃する際に必要な特権のレベルを評価します。ここで、脆弱性が内在するが、特権が不要な場合「低(L)」の評価が適用されます。
【CVSS V3 と CVSS V3.1 の違い】
なお、CVSS V3 と CVSS V3.1 の違いですが、これは先に説明したように評価基準には大きな変更はありません。V3.1 は「既存の基準を明確化すること」を目的に作成されました。以下のような違いがあります。
- CVSS 基本評価基準の明確化
システムのリスクについて総合的な評価が必要とされる場合に、基本評価基準 Base Score のみが利用されることが懸念されます。CVSS v3.1仕様書には、CVSS 基本評価基準 Base Score は、時間の経過とともにユーザー環境全体で一定であり、脆弱性の固有の特性のみを表すことが明確に記載されています。
つまり、リスク評価のために「 CVSS 基本評価基準 Base Score のみで判断してはいけない」ということです。
ここで重要なのは、基本評価基準だけでなく、現状評価基準、環境評価基準を加味した包括的な評価を実施することです。
- スコアリングガイダンス、名称の変更
- 拡張フレームワークの追加
- あいまいさ排除のためのCVSS スコア算出のための数式の変更
詳細な変更についてはFIRST の仕様書をご確認ください。
CVSS スコアの例
ここからは、具体的な CVSS スコアの例を取り上げてみましょう。たとえば、前編で紹介した sudo の脆弱性 (CVE-2021-3156) について、JVN iPedia を利用して CVSS スコアを見てみましょう。
① JVN iPedia で 該当する脆弱性の詳細ページを表示する
https://jvndb.jvn.jp/ja/contents/2021/JVNDB-2021-001020.html
sudo の脆弱性 (CVE-2021-3156) についての JVN iPedia のページ
前述したように、CVSS V2 のスコアと CVSS V3 のスコアには違いがあります。
➁ 基本値の数値をクリックし、CVSS 計算機のページへ
下にスクロールすると、スコアとともに各評価基準の評価が選択されたページが確認できます。 前述したように、基本評価基準、現状評価基準の評価はベンダーが提供する値です。 システムを総合的に評価するためには、ユーザーによる環境評価基準の再評価が必要です。
③ 環境評価基準の評価
緩和策後の攻撃元区分を再評価してみましょう。
たとえば、攻撃元から特にファイアウォールなどの対策を講じておらず、ネットワーク経由で攻撃可能な場合、評価は「ネットワーク」に該当します。
そこで攻撃元から攻撃可能な「ネットワーク」を選択してみました。
すると環境評価が加味され、右上の CVSS スコアの値が 7.8 から 8.8 に変化していることがわかります。
このようにして、CVSS はシステム環境を総合的に評価することが可能になっています。
3. 継続して脆弱性管理を行うには
脆弱性管理ツールを使用した自動化/効率化により、手作業での脆弱性対策に比べて 5 年間で約 7,500 万円 (約 65% )* の費用(工数)の効率化が可能です。
※ 100 台で 10 種の OSS サーバー管理を想定した場合(サイバートラスト試算)
[1] https://www.ipa.go.jp/security/announce/about.html
[2] https://www.cisco.com/c/ja_jp/support/docs/csa/psirt-index.html
[3]https://msrc.microsoft.com/update-guide/
[4]https://www.debian.org/security/