組織には脆弱性への対応が求められるが、増加する脆弱性の公開数に対して、脆弱性への対応を行う人的リソースは限られている。本記事では脆弱性管理の一環として、対応すべき脆弱性の優先度を定めるトリアージについて解説する。
昨今、増加しているサイバー攻撃に関する報道の中で、「脆弱性」という言葉を目にすることが多くなった。
組織には脆弱性への対応が求められるが、増加する脆弱性の公開数に対して、対応を行う人的リソースは限られている。本記事では脆弱性管理の一環として、対応すべき脆弱性の優先度を定めるトリアージについて解説する。
日々発見される脆弱性
脆弱性とは、コンピューターのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生した情報セキュリティ上の欠陥のことで、「セキュリティ・ホール」とも呼ばれる。
現在、一般的に脆弱性はCVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）で管理されている。CVEは個別製品中の脆弱性を対象として、米国政府の支援を受けた非営利団体のMITRE社が採番している識別子だ。現在、主要なベンダーなどから脆弱性情報が公開される際にはCVE-IDが付与された上で公開されていることが多い。
脆弱性報告件数の推移（2023年は2月までの値）
※CVE Detailsの公開値をもとに作成
CVEの発行情報をもとに2011年以降の脆弱性報告件数の推移を見ると、2016年から2017年を境に脆弱性の報告・公開件数が急増しており、現在は2万件前後の脆弱性が毎年報告されている※。
2017年の報告件数急増の理由は、CVEの採番機関 CNA（CVE Numbering Authority）になるための認定基準が緩和され、CVE採番機関の数が増加したこと*1、同時期にグーグル社のDmitry Vyukov氏が開発したsyzkaller/Syzbotなどファジングテストの自動テストツールが普及したこと*2が要因と考えられる。
前述のように、年間2万件前後報告されている脆弱性だが、サイバー攻撃にはゼロデイ脆弱性と呼ばれる、公に報告されていない脆弱性が使われることもある。米Flashpoint社の調査では、2022年上半期に収集した脆弱性11,860件のうち、27.3%はCVE/NVDに未報告または詳細データがない脆弱性であったことが示されている*3。このことから、攻撃者に知られる脆弱性の実数はより多いということが推測される。
*1 IPA - 脆弱性対策情報データベースJVN iPediaの登録状況 2017年第4四半期（10月～12月）
*2 NTTデータ - 逃げるsyzbot、追うカーネル開発者たち
*3 FLASHPOINT - The State of Vulnerability Intelligence: 2022 Midyear Edition
脆弱性への対応
脆弱性はありとあらゆる攻撃の糸口となり、組織は脆弱性への対応が求められる。しかし、日々大量に報告される脆弱性への対応は、見落としや対処漏れが発生する可能性があり一筋縄ではいかない。このため、脆弱性管理のプロセスを定義し、運用することが重要となる。
脆弱性管理のプロセス
脆弱性管理のプロセスにはいくつかのフェーズがある。
1. 対象の把握・識別
自組織が持つ資産を知らなければ、日々発見される脆弱性の対象に自組織の資産が含まれているのかを判断することはできない。日頃から資産管理やSBOM（ソフトウェアが含んでいるライブラリーやモジュールを一覧化した構成情報）の整備を行い、自組織のIT資産を予め識別しておくことが重要だ。
さらに、識別したIT資産に対して、「対応の優先度」を定めておくと、どの資産グループがより注意を必要としているかを理解するのに役立つとともに、リソース割り当ての意思決定プロセスを効率化することにもつながる。
2. 脆弱性を把握・特定
公開された脆弱性情報を収集・把握し、自組織の資産が対象となっている脆弱性を特定する。脆弱性情報の収集には次のようなWebサイトが参考となる。
- IPA - 重要なセキュリティ情報
- JPCERT/CC - 注意喚起
- CISA - Cybersecurity Alerts & Advisories
- IBM X-Force Exchange
- 各製品ベンダーが提供するセキュリティアドバイザリ
また、組織では多くの製品やサービスが使われている。利用しているすべての製品・サービスについて、日々大量に報告される脆弱性への対応ができているのか、確認することが難しい場合もあるだろう。こうした場合には、脆弱性診断サービスを活用することも有効な手段の1つだ。脆弱性診断ではその時点で既知となっている脅威について対策ができているのか、網羅的に検査することができる。こうしたサービスを定期的に活用することにより、対策ができていない資産と脆弱性を特定することができるだろう。
3. 脆弱性の分析・評価 ／ 4. 脆弱性への対応
3と4は密接に関連するため、2つ併せて紹介する。
脆弱性対応の理想は特定した脆弱性すべてに対して速やかに、パッチや緩和策の適用などの対応を行うことだ。しかし、パッチや緩和策を適用する際は、脆弱性への対応を行ったことによる他のシステムや業務への影響有無や、適用のためのシステム停止が可能なのかも検討する必要がある。また、前述の通り脆弱性は日々大量に公開されているため、その全てを速やかに対処することが難しい場合もあるだろう。
このことから、特定した脆弱性がどの程度の危険性や緊急性があるのか、［3. 脆弱性の分析・評価］で分析し、どの脆弱性から対応するのか、その対応はいつまでに必要なのかを判断する、脆弱性のトリアージが重要となる。
トリアージとは、医療分野の用語で大規模な災害や事故の現場などで、傷病者の緊急度や重症度に応じて適切な処置や搬送を行うために治療優先順位を決定することをいう。この考えを脆弱性管理に応用し、トリアージによって定めた対応の優先度に沿って、［4. 脆弱性への対応］で脆弱性への対応を行うことで効率的に脆弱性管理を行うことができる。
大量に報告される脆弱性、その優先度は？
脆弱性への対応の優先度を判断するトリアージの基準はさまざまだが、ここでは「脆弱性を悪用する攻撃の有無」、「脆弱性そのものの危険度」を取り上げて紹介する。
脆弱性を悪用する攻撃の有無
数ある脆弱性の中でも悪用され攻撃が観測されている脆弱性には最優先で対応するべきだろう。米国のセキュリティ企業 Kenna Security 社の調査結果*4によると、2019年に発行された18,000件以上のCVEのうち、実際に攻撃が観測された脆弱性は473件であり、2019年に発行されたCVE全体の3％にも満たないことが示されている。前述の通り、近年は年間2万件程度（未報告の脆弱性が30%程度あることを加味すると約3万件）の脆弱性が報告されているが、実際に悪用される脆弱性の割合を Kenna Security 社の調査結果と同等と仮定すると、実際に悪用される脆弱性の数は数百件と推定できる。これらの脆弱性を特定し、自組織で使用している製品に影響がある場合は高い優先順位で対応を進める必要がある。
*4 Kenna Security - Prioritization to Prediction Volume 6: The Attacker-Defender Divide
脆弱性そのものの危険度
脆弱性を評価する方法は複数存在する。それらの中で一般的な指標が、脆弱性の深刻度を評価する尺度を数値化するCVSS（共通脆弱性評価システム）だ。
脆弱性の影響度判断に使用されることも多いCVSSだが、スコアの出し方や運用について問題を指摘する声もある。NISTが管理するNVD（National Vulnerability Database）のエントリーには脆弱性のCVSSスコア（基本値）が含まれている。しかし、脆弱性データベースを手掛けるVulnCheck社の調査結果*5によると、NVDに登録されている脆弱性のうち、NISTとベンダーから発表されたスコアを持つ脆弱性エントリーは約25,000（CVSS v3スコアを持つ脆弱性の20%）であり、それらの約14,000（56%）が相反するスコアを持っていたと報告されている。本来、CVSSのスコア（基本値）は、算出する組織に依存せず一意の値になるはずだ。NISTとベンダーが公開する値が異なるということは、少なくともいずれか一方が公開しているCVSSスコアの値が誤っていることを示している。誤った値が公開されている例を紹介しよう。
*5 VulnCheck - Who to Trust? National Vulnerability Database CVSS Accuracy Issues
公開スコアが誤っている例
CVE-2022-36446：Webminに影響するコマンドインジェクションの脆弱性
CVE-2022-36466には、脆弱性発見者による技術的な解説記事が公開されている。解説記事では、この脆弱性の悪用には、「Software Package Updates」モジュールへのアクセス、つまりebminへの認証が必要だが、NISTの算出ベクトルではPR:N（攻撃する際に必要な特権レベル：不要）で算出されている。このベクトルを本来の値であるPR:Hに修正すると、スコアが9.8（クリティカル）から7.2（高）に下がることとなる。CVSSスコア（基本値）によって優先度を設定している場合、このスコアの低下により、CVE-2022-36446の優先度は大幅に低下することとなる。
また、CVSSによる運用の最も大きな問題は、基本値のみの運用で数字だけが一人歩きしている点だ。CVSSのスコアには基本評価基準（Base Metrics）をもとに算出した基本値のほか、現状評価値、環境評価値があるが、多くの場合、基本値のみで運用されている。
しかし、この基本値の算出基準には攻撃コードの公開状況は加味されていないため、CVSS基本値のみで対策の優先度を決定すると、「脆弱性を悪用した攻撃が既に観測されている脆弱性」より、「CVSSスコアは高いが攻撃コードは公開されておらず攻撃される可能性が低い脆弱性」への対処を優先してしまうという事態も発生しうる。こうした状況の打開策として脆弱性対応の優先度判断するためのCVSSに代わる管理手法や評価指標が提案されている。
KEV（Know Exploited Vulnerabilities Catalog）*6
KEVとは、CISAが公開している実際に悪用が確認されている脆弱性情報のカタログのこと。
登録条件には、Clear Remediation Guidance（明確な改善策ガイダンスが公開されていること）が含まれているので、 KEVを参照することで、多くの脆弱性の中から、悪用されるリスクが高く、かつ明確な改善策が公開されている脆弱性にいち早く気づくことができる。また、米国連邦政府機関では、このカタログに掲載された脆弱性に関し期間を指定した対処が求められる（BOD 22-01）。
*6 CISA - Know Exploited Vulnerabilities Catalog
SSVC（Stakeholder-Specific Vulnerability Categorization）*7
SSVCとは、CVSSの課題に対応するために提案された、脆弱性の評価指標のこと。
命名由来は「CVSS」の逆転だといわれている。ディシジョンツリー（決定木分析）を用いた脆弱性管理手法となっている。分岐の1番初めはExploitation（攻撃が観測されているか、攻撃コードが公開されているか）であるため、KEVなどとの併用が望ましい。
*7 CISA - Stakeholder-Specific Vulnerability Categorization
必ずしもKEVやSSVCがCVSSより優れている訳ではないが、CVSSのスコア、特に基本値のみで優先度を判断すると、本来優先して対応すべき脆弱性の優先度を見誤る可能性があることは先に示した通りだ。優先度を判断する際の指標として、こうした評価指標や公開情報もあるという点を留意するのもいいだろう。
脆弱性管理におけるトリアージの重要性とその指標を解説し、指標として現在広く使用されているCVSSの問題を紹介した。今回は説明を割愛したが、優先的に対処する脆弱性を判断した後には、いつまでに対処を行うのかという点も重要となる。
Kenna Security社の調査結果には、脆弱性の半数以上はCVE公開時点で攻撃コードが公開されている点や、セキュリティパッチ公開からの2日以内に5%、1ヶ月以内に45%の脆弱性について攻撃が観測されている点も示されている。日々大量に公開される脆弱性への対応で、何から手をつけていいか分からなくなったときはこうした管理手法にも立ち返り、対応の優先度を検討してはどうだろうか。
