DevSecOps 2024.01.25

リスクベースの脆弱性トリアージの必要性を考えよう

脆弱性トリアージ

3行でわかる本記事のサマリ

OSS利用増加で脆弱性が急増、CVSSスコアだけでは実際の攻撃リスクを正確に評価できず。
米CISAがKEVに焦点、CVSSセベリティだけでなく実際の攻撃リスクを考慮した対応が求められている。
SSVCのリスクベースアプローチと自動化ツール（例: LeanSeeks）が、脆弱性トリアージにおいて効果的な対応手法を提供。

はじめに

今日は脆弱性のトリアージをテーマにお話します。昨今DevSecOpsといったキーワードや、それを実現するための「シフトレフト」というアプローチが重要といわれています。私達のビジネスの中で実際にDevSecOpsやシフトレフトに取り組む様々な組織の方々とお話する機会がありましたが、残念ながら「シフトレフト」がスムーズに運用できている組織は、わたしたちの知る限りはほとんどありません。
今回のブログでは、「シフトレフト」がうまくいかない理由やCVSSセベリティをもとにしたトリアージの問題点、その解決のアプローチの例について書いていきます。

1. シフトレフトでの脆弱性対応検討の課題

世の中のソフトウェア開発のコードベースの7割以上がOSSと言われています。ソフトウェア開発にOSSを用いることは現在のスタンダードな考え方であり、これを避けて通ることはできません。OSSを多用するソフトウェアにおいては、既知の脆弱性情報はスキャンを行うたびに数百個など大量に検出されることも珍しくありません。NVDにレポートされる脆弱性の数は年々登録が増え続けている傾向があり、ここ数年では年間2万件をこえています。

2024/1/22時点でNVDより取得した年別のCVE数の累計　マクニカ調べ

このように大量に検知される脆弱性は数ヶ月の期間をかけて一つ一つの対応判断をするという組織もありますが、膨大な工数や時間を要し、やっと終わる頃には新たな脆弱性が多数見つかることもよくあることで、いつまでたってもリリース判断ができません。
または、よほど世の中で騒がれているような脆弱性が該当しなければ、基本的には「見て見ぬふり」となってしまう組織も非常に多く、「セキュリティのシフトレフト」には大きな課題があることがうかがえます。

こういった背景から、OSSの利用を前提としたモダンなアプリケーション開発では「脆弱性のトリアージ」の需要が高まっています。「脆弱性のトリアージ」とは、どの脆弱性に優先的に対応すべきかを決定する優先順位付けのことです。
多くの組織ではトリアージに「CVSSスコア」を用いることが一般的と聞きますが、実は多くの脆弱性スキャナが出力する「CVSSスコア」はCVSSの「基本評価基準」という脆弱性単体の技術評価情報であり、本来リスクを評価するために必要な「その脆弱性に対する攻撃の実現性」や「攻撃されることによる影響」といった情報が含まれず、リスク評価の指標としては正しい情報とは言えません。
また、CVSSの「基本評価基準」は評価する人によってスコアのブレが発生することも多く確認されており、評価ベンダーによってCVSSセベリティが大きく異なるケースも多く確認されています。

2. 米CISAによるKEV(Known Exploited Vulnerabilities)の公開

2021年末ごろ、米政府機関のCISAは「拘束力のある運用司令 22-01 」(Reducing Significant Risk of Known Exploited Vulnerabilities)(出典: https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities)を発行しました。「拘束力のある運用司令 22-01 」は米国政府の関連機関を対象とした運用司令であり、KEV(Known Exploited Vulnerabilities)(出典: https://www.cisa.gov/known-exploited-vulnerabilities-catalog)のリストに公開された脆弱性については、同リスト上に掲載された期日までに修正を必須とするというものです。

CISAはKEVの発行の背景として、以下の理由を解説しています。

a. CVSSは脆弱性が実際にシステムの攻撃に使用されているかどうかを考慮していない
b. Criticalに限らずHighやMedium、Lowも攻撃に活用されている
c. 2019 年までの過去の脆弱性データの調査では、すべての既知の脆弱性のうち、実際に攻撃者によって使用されたものは 4% 未満
d. 実際の攻撃では決して使用されない可能性のある数千の脆弱性ではなく、アクティブな脅威である脆弱性に焦点を移すべきである

実はCVSSセベリティがCriticalであっても、実際のリスクが少ないと判定されるものは非常に多いです。Criticalだからという理由でその脆弱性の調査を行うのは時間のロスであり、こういった時間を使い、HighやMedium、Lowに埋もれている本来リスクの高い脆弱性も含めて調査や対応を行う方針に舵を切っていくことが必要です。

3. リスクベースの脆弱性トリアージとSSVC

本当に優先的に対応すべき脆弱性を絞り込むためのアプローチとして、米カーネギーメロン大学によりSSVC(Stakeholder-Specific Vulnerability Categorization) (出典： https://resources.sei.cmu.edu/asset_files/WhitePaper/2021_019_001_653461.pdf)があり、こちらは前述の米国政府機関のCISAの脆弱性評価でも、KEVの運用とあわせて用いられています。SSVCでは検知された脆弱性ごとにエクスプロイトの有無を確認するところをスタートラインとして、その完成度や影響度をデシジョンツリーと呼ばれるフローに沿って分類するフレームワークです。SSVCは脆弱性をリスクの大きさに応じて4つのカテゴリに分類し、対応すべき優先度を明確化します。これがリスクベースのトリアージと呼ばれるアプローチです。

出典: https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide%20508c.pdf

SSVCのフレームワークは本当のリスクの抽出に非常に役立つものですが、実際に運用に適用しようとする場合に、次のような課題があります。

a. エクスプロイトの存在や完成度の調査の工数
b. 調査に利用するインテリジェンスの精度の見極め
c. 技術・公共影響度の判定基準の検討
d. すべての脆弱性ごとにデシジョンツリーの適合プロセスを回していく工数

4. リスクベースのトリアージの自動化を検討

SSVCのフレームワークは優れていても、そのまま運用を検討するには上記の課題に対処する必要があります。
もしエクスプロイトの存在や完成度に対しての情報がすでにあるなら、その情報を利用して自動で処理を回すことができる仕組みを検討するのが最も効率的と考えられます。なお、エクスプロイトの存在や完成度の情報は、可能な限り頻繁に最新の情報に更新し続けることが望ましいです。
商用製品のサンプルとしては、LeanSeeksというSSVCをベースとしたトリアージの自動化製品があります。
LeanSeeksを利用する場合、ユーザーが予めアプリケーションごとの特性を定義すると、あとは自動的に信頼性の高いインテリジェンスから取り寄せた情報をもとにExpliotの完成度や攻撃経路、過去の攻撃実績情報(KEV)などの付帯情報を利用して情報を数値化し、脆弱性カテゴライズの処理を自動的に遂行します。

SSVCのアプローチの重要なポイントは、対処すべきセベリティCriticalの脆弱性の数を減らして絞り込むだけでなく、HighやMedium、Lowといった低めのセベリティに埋もれてしまっている重大なリスクをあぶり出してくれる点にあります。
さらに、実際に検知される大量の脆弱性の数は、ほとんどのケースで1割未満まで絞り込めるなど、現実的に対処可能な数量まで減らすことが可能です。
APIによるトリアージの実行や結果の取得が可能なため、既存のスキャナやアラートシステムと連携することも容易です。

5. まとめ

今回はCVSSの問題点や、KEVやSSVCといった、新しいアプローチのリスクベースとよばれる脆弱性対処方法について紹介しました。もしエクスプロイトのインテリジェンスがなかったり、SSVCの自動化の仕組みの構築にハードルがある場合にも、LeanSeeksのようなソリューションを利用することで、ビルドのパイプラインでの脆弱性検知とトリアージを自動化したり、リリース済みの製品のリスクを定期的に自動監査するような仕組みを構築することが可能です。

本ブログ内容に関して、ホワイトペーパーをご用意しております。
詳しく知りたい方は、是非ダウンロードください。