本文の内容は、2022年4月20日にMiguel Hernándezが投稿したブログAre vulnerability scores misleading you? Understanding CVSS severity and using them effectively(https://sysdig.com/blog/vulnerability-score-cvss-meaning/）を元に日本語に翻訳・再構成した内容となっております。
脆弱性はどこにでもあります。セキュリティ専門家にとって、これらの脆弱性を大規模に調査し、緩和し、是正することは大変な作業です。どの組織も、すべての脆弱性を見つけて修正する能力を持っているわけではないことを心に留めておいてください。重要なのは、脆弱性とは何かを理解し、CVSSスコアの意味を解釈し、制約された時間制限や納期内でリソースの優先順位付けと有効利用を行うことです。
2016年以降、毎年報告される新たな脆弱性は約3倍に増加しています。2022年4月現在、新たな脆弱性の数に関する予測は、引き続き的中しています。
増加する傾向が続いています。基本的に、コードが多ければ多いほど、脆弱性も増えるという訳です。そして、コードは今やアプリケーションやソフトウェアだけでなく、さまざまな形で存在しています。組み込みシステムやIoTデバイスの中にもコードが存在し、ハードウェアから生まれる脆弱性がありますし、DevOpsの実践の一環としてインフラの定義や運用にもコードが使用されています。セキュリティエンジニアやアナリストの間では、毎週インターネットが壊れるのが当たり前になっています。開発者不足も手伝ってか、このような状況になっています。
過去数年間の脆弱性
すべての重要な脆弱性は、ソフトウェアパッケージの普及、悪用可能性、影響力という点で log4j や spring4shell に相当するものではありません。
サイバーセキュリティプログラムの理想的な状態は、組織に本当に影響を与え、対処可能な脆弱性を迅速に特定できるようになることです。すべての脆弱性を追いかけることで、ITチームやセキュリティチームを疲弊させることは許されません。
Log4jの脆弱性と最新のSpring4shellについて説明したブログをご覧ください。この記事では、次のことを説明したいと思います：
- 脆弱性とは何ですか？
- CVSSスコアの意味は何ですか？
- CVSSスコアに影響を与える変数とは？
- CVSSは、脆弱性管理の中で優先順位をつけるのに最適な方法ですか？
- リスクベースの優先順位付けのために、CVSSに代わるものはありますか？
脆弱性の意味は何ですか？
MITREは、脆弱性を次のように定義しています。“ソフトウェアやハードウェアのコンポーネントに見られる計算ロジック（コードなど）の弱点で、悪用された場合、機密性、完全性、可用性に悪影響を及ぼすもの “です。
このため、あなたには全く影響のないコードに重大な脆弱性が存在することもあり得ます。例えば、このコードが他のセキュリティ制御に依存するIoTデバイス上で動作していて、組み込みコードに潜在する脆弱性の悪用可能性を効果的に緩和できる場合などです。
一方、アプリケーションの機密性に悪影響を及ぼす、深刻度の低い脆弱性がある場合もあります。この問題を修正すると、可用性に直接影響するため、できるだけ早く修正することが優先されるでしょう。
CVSS 深刻度スコアの理解先に述べたように、主な問題は、新しい脆弱性に絶えずさらされる一方で、古い脆弱性とも格闘しており、それらすべてを管理する簡単な方法がないことです。私たちは、本当に重要なものが発見された場合、迅速に検出・解決し、脆弱性のエコシステムの残りの部分を忘れることなく、そこに労力の大半を割かなければなりません。理論的には簡単なことであり、最新のセキュリティプログラムを支えるものですが、実際のところ、脆弱性の優先順位付けは、セキュリティにおける最大のギャップの1つとなっています。
脆弱性管理をより深く理解するために、脆弱性が公表されたときにどのようなプロセスがあるのかを説明します。
脆弱性のライフサイクル
脆弱性の起源は、誰が定義するわけでもありません。時には、企業が自社のコードを定期的にテストし、アプリケーションの問題や依存関係の悪用を示すために多大な労力を費やした大規模な調査であることもあります。また、独立したセキュリティリサーチャーが空き時間にシステムを調査し、その結果を責任ある情報公開の一環として報告したり、システムを悪用する概念実証（PoC）を作成してTwitterで詳細を公開したりした結果、脆弱性が発見されることもあります。
これらは、公式に公開される前の0-dayの一般的な例です。脆弱性がすでに知られている場合は0-dayではないので、大袈裟なバズワードと言えます。このため、この種の脆弱性はブラックマーケットで金となるのです。攻撃者が未確認の脆弱性を熟知している場合、少なくとも最初のアクセスや悪用の段階では、ほとんどの組織で検知・保護メカニズムが欠けている可能性があるため、容易に悪用することができるのです。
リサーチャーが行う良い方法は、登録する前に、開発者が脆弱性を修正するためのパッチに着手する時間を与えることです。そうしないと、修正されないまま何日も経ってしまう可能性があるからです。
では、どうするのがベストなのでしょうか？0-dayが公開されたときにできるだけ早く準備できるようにプロセスを改善し、その瞬間から検出し、適切な緩和策を提供し、多くの場合、この脆弱性が過去に使われていないこと（本当に0-dayだったところ）を検証することです。
CVSS深刻度スコア 脆弱性のライフサイクル脆弱性が登録されると、その脆弱性を特定するIDを取得します。これによって、脆弱性を特定し、影響を受けているかどうかを確認することができます。しかし、どこに登録されているのでしょうか？
最も一般的なサイトの一つが（これだけではありませんが）、Common Vulnerabilities and Exposures (CVE)です。MITRE Corporationは、一般に公開されているサイバーセキュリティの脆弱性を特定、定義、カタログ化し、そのCVE-IDの情報を一般に公開している組織です。脆弱性情報は、NISTの組織とも共有され、さらなる詳細やセキュリティガイダンスを提供するために追加情報が加えられることもあります。この情報は、NISTのナショナル脆弱性データベース（NVD）内に保管され、CVE-IDによって整理されています。
他の国家は、中国国家脆弱性データベース（CNNVD）や日本脆弱性ノート（JVN）のように、脆弱性をカタログ化して保存する独自のシステムを持っています。しかし、この記事では、NVDに焦点を当てます。
脆弱性が実在し、悪用可能で、IDがあることが確認できたら、次の工程は深刻度を評価することです。
脆弱性のスコアの算出方法
Common Vulnerability Scoring System (CVSS) は、脆弱性の主要な特徴を捉え、その深刻度を反映した数値スコアを算出する方法を提供します。多くのセキュリティチームやSOCは、インシデント対応プロセス、欠陥の追跡と解決、または緩和策の実施など、脆弱性管理活動の優先順位を決めるためにCVSSを使用しています。最新版である CVSS v3.1 で使用される測定基準は、悪用プロセスや影響度に依存するさまざまな要素を評価し、最終的に深刻度スコアが算出されます。ドキュメントで最初に見つけることができるのは、CVSSはリスクではなく、深刻度を測定するということです。
CVSSは、コンテキストなしに脆弱性のいくつかの属性を設定すると、”客観的 “なスコアとなり、数式によって、”深刻度 “にも対応するスコアが生成されます。以下、Spring4Shellの脆弱性のCVSSの実例ですが、深刻度は9.8 CRITICALで採点されています。
CVE-2022-22963 CVSSの深刻度スコアの例基本スコアは、8つの変数で計算されます。
- 攻撃ベクター(AV)：脆弱性を悪用するためのアクセス方法を表す4つのオプションがあります。ネットワークは、リモート接続を可能にし、攻撃者がどこからでも悪用できることを意味するため、最も高く評価されます。残りは、制限の高いものから低いものへと続きます。Localの場合、脆弱性のあるコンポーネントはネットワークスタックに紐づいておらず、攻撃者の経路はハードウェアアクセス、リモート、ソーシャルエンジニアリングによる正規ユーザのIDの乗っ取りとなります。
- 攻撃の複雑さ（AC）：LowまたはHighの2つのオプションがあります。バージョン3.1では、脆弱さはシステム要件に依存するように更新され、ある構成を攻撃を受ける可能性が高いと取るか、低いと取るかは議論があり得ます。複雑性が高い場合、攻撃の成功は攻撃者が制御できない条件に依存しますが、脆弱なコンポーネントに対する準備または実行において、攻撃者が測定可能な量の労力を費やす必要があるものと定義されます。たとえば、攻撃者は競合状態に勝つためにはブルートフォース攻撃を使用する必要があり、単一のコマンドによるlog4jのような銀の弾丸は必要としません。
- 必要な特権 (PR)：3つのオプションがあります。Noneは、認証なしで脆弱性が悪用される場合です。これはまた、属性や悪用後に攻撃者がたどった経路がわかりにくくなります。この指標が高い場合、攻撃者は、例えばコンポーネント全体の設定へのアクセスを可能にするために、管理者権限またはそれに類するものを必要とします。
- ユーザーとの対話（UI）：インタラクションを必要とする場合、低いスコアとなります。これは、ユーザーのデバイスに侵入するためにユーザーが脅威（マルウェア）と対話する必要があるモバイルアプリケーションでよく見られます。別の例では、フィッシング攻撃と同様、それ自体はリスクではありませんが、攻撃者はソーシャルエンジニアリングを用いて被害者にリンクをクリックさせ、身ぐるみ剥がされるように仕向けるのです。
- スコープ（S）：脆弱性が特定のコンポーネントのみに影響するのか、アプリケーション全体に影響するのかによってスコアが変わります。
- CIA（Confidentiality、Integrity、Availability）：機密性、整合性、可用性を意味します。セキュリティシステムやポリシーの開発の基礎となる、定評あるセキュリティモデル「CIAの3要素」。ここに、脆弱性がもたらす実際の影響があります。もうひとつは、悪用されるまでのプロセスです。RCEでは、攻撃者は被害マシンを完全に制御し、特権が十分であれば、3要素すべてに高い深刻度で影響を及ぼします。
この最初の部分はベーススコアに相当し、時間の経過とともに安定し、組織間で一貫性を保つべき客観的な値です。補足として、時間的および環境的な測定基準があります。これらの値は、スコアリングをより複雑にするため、脆弱性管理の初期段階において、組織が注意を払うべきものではない可能性があります。
経時的メトリクスは、エクスプロイト技術や概念実証コードの可用性の現状、パッチや回避策の存在、脆弱性の記述に対する信頼度を測定します。これは、脆弱性のライフサイクルに沿って変化するものです。なぜなら、改善策の準備が整っているかいないかで、大きな差が生じるからです。環境メトリクスを使用すると、影響を受けるIT資産の重要度やビジネスクリティカルさに応じて、CVSSスコアをカスタマイズすることができます。
RedHat や Debian などのベースディストリビューションプロバイダーは、特定のコンテキスト（ディストリビューション内のパッケージなど）において脆弱性の深刻性を評価します。顧客は、MITRE や NIST が割り当てる一般的なスコアよりも、ベンダーのスコアの方が通常より正確であるため、より信頼できるかもしれません。
見ての通り、このスコアは、修正部分や修正プロセスには影響されません。この脆弱性を解決するために多大な労力を必要とする場合、最終的なスコアに影響を与えません。また、同じスコアの2つの脆弱性でも、経済分野や業種によって、影響や可能性が大きく異なる場合があります。
CVSSスコアの計算から、システムの安全性を評価する際に参考となるいくつかの導出式が現れます。そのいくつかを紹介します。
- Common Misuse Scoring System (CMSS)：CMSS（Common Misuse Scoring System）：悪用される脆弱性を持つソフトウェアの深刻度を評価するもの。誤用脆弱性とは、本来有益であるはずの機能を、攻撃者が悪意のある目的で使用することを可能にする脆弱性です。このスコアは、システム全体のセキュリティ状況を定量的に評価するためのデータとして、企業に提供される可能性があります。
- Common Configuration Scoring System（CCSS）：CCSSは、CVSSとCMSSをベースにしています。最も顕著な違いは、悪用のタイプ（能動的か受動的か）です。能動的悪用とは、攻撃者が設定ミスを利用して行動を起こすことを指し、受動的悪用とは、セキュリティイベントに対して監査ログが生成されないように設定されているなど、許可された行動が発生しないような設定ミスがあることを指します。
- Common Weakness Scoring System（CWSS）：概念的にはCVSSとCWSSはよく似ています。CWSSは、新たな脆弱性を公表する初期の段階で適用することができます。さらに、脆弱性レポートにおける一部の情報の不足を補完する役割も果たします。保守的なアプローチではスコアが膨らんでしまうため、影響を受ける技術を深く理解することで、このような入手不可能な情報の一部を得ることができるのです。新しい脆弱性が報告された場合、CVSSと同じように、悪用された週、CWE-ID / CWSSと一緒に報告することが可能です。
CVSSと関連付け、脆弱性管理を改善するために、より多くの情報をシステムに提供する必要があることは明らかです。リスクベースの優先順位付けが、現代のすべてのサイバーセキュリティプログラムの目標であることを忘れないでください。
ノイズを排除し、本当に重要な脆弱性に優先順位をつけるには、Risk Spotlight が利用できます。
CVSSスコアに代わるものを使用してセキュリティリスクに優先順位を付ける
脆弱性の深刻度の意味を深く掘り下げると、CVSS スコアを計算する際に、他の特性により興味を持つかもしれません。当然ながら、ユースケースや事業分野によっては、脆弱性の管理に優先順位をつけるために、CVSSの代替となるものを見つけることが可能です。特に、サードパーティのコードやパートナーとの統合の場合、必ずしも迅速にパッチを当てることができるとは限りません。この場合、シフトレフトアプローチでは不十分であり、影響を受けるソフトウェアを早期に検出・特定し、緩和するセキュリティコントロールの実装を促進することができる、もう一つのセキュリティ層として、ランタイムセキュリティを使用することをお勧めします。
エクスプロイト予測スコアリングシステム
ある脆弱性が攻撃者に悪用される実際の確率はどの程度なのでしょうか。その確率は、Exploit Prediction Scoring System (EPSS)によって説明されます。EPSSモデルは、スコアが高いほど、脆弱性が悪用される可能性が高いという確率のスコアを生成します。このスコアは、CVSSと同じ組織であるMITREによって管理されており、上記の脆弱性分類法や分類システムとの整合性を保証しています。過去30日間で最も高い評価を受けた脆弱性を見れば、脆弱性の潜在的な実際の影響力がよりよく理解できます。例として、MasterStudy LMS WordPressプラグインに関連するCVE-2022-0441をご覧ください。
EPSSの例 CVSSの深刻度 CVE パーセンテージを計算するために、EPSSはCVSSスコアの一部を使用しますが、脆弱性を悪用することがいかに容易であるかを確認するために脅威インテリジェンスも使用します。例えば、脆弱性を悪用することで、他の脆弱性の悪用が可能になり、影響が大きくなる可能性があります。複雑な攻撃の連鎖の一部として、攻撃者は1つの脆弱性を悪用してRCEを達成し、その後、他の脆弱性を悪用して特権を昇格させ、より大きな影響を与えることができるかもしれません。また、Metasploit や Exploit-db など、脆弱性攻撃の手順に関する知識を必要としない攻撃ツールやリポジトリが利用可能であることも、スコアに加味される場合があります。
ステークホルダー別の脆弱性分類
Stakeholder-specific Vulnerability Categorization (SSVC) は、ほとんどが脆弱性管理のための概念的なツールです。SSVC の目的は、一律的な解決策を避け、脆弱性管理者がその状況に応じて適切に選択し使用できる、明確に定義されテストされた部分を持つモジュール式の意思決定システムを採用することです。SSVCの目標は、リスク指向で、計算プロセスをより透明化し、自動化によって脆弱性リスクの定量化を拡張できるようにすることです。
ベンダーのスコアリング
Vulnerability Priority Rating (VPR) は Tenable 社によって管理されており、EPSS と同様に深刻度と悪用される容易さも使用します。脆弱性優先度評価（VPR）は、脆弱性のエクスプロイトコードが利用可能になったり、成熟度が上昇するなど、現在の脅威状況を反映してTenableがVPRを更新するため、脆弱性のCVSSスコアが提供するデータとダイナミックに連動しているのが特徴です。VPRの値の範囲は0.1～10.0であり、値が高いほど悪用される可能性が高いことを表しています。
Snyk 社のような他のベンダーは、CVSS と、エクスプロイトの成熟度、修正プロセス、コミュニティでの言及など、上記の他の要素を使用して優先順位付けのための独自のスコア（Snyk Priority Score）を作成し、CVE-ID とは関連しないが優先順位付けに価値のある独自の脅威リサーチの一部として脆弱性のランク付けを行っています。
業種別アプローチ
医療分野に関連するものとして、RSS-MD（Risk Scoring System for Medical Devices）が検討されており、より一般的なレベルとなっています。やはり、この業界の脆弱性は人々の健康や安全に直接影響するため、この種の脆弱性と相対的な影響を別個に管理するための独自の尺度が必要です。製造業に関連するものとして、IVSS（Industrial Vulnerability Scoring System）があり、物理的セキュリティなどの要素を計算の一部に組み込んでいます。このスコアは、特に、被害が都市全体や市民の生活に影響を与える重要なインフラに影響を与える産業用制御システムの脆弱性を対象として設計されています。
次のステップは？脆弱性フィードの取り込みと是正の推進
上記のように、最終的な結果を「ビタミン化」するために、アクセスおよび処理可能なできるだけ多くの情報を関連付けることによって、脆弱性や関連するリスクに対して最適なスコアを計算する傾向があります。ある手法が他の手法と矛盾するのは不思議なことです。通常、最終的な深刻度については、どれも似たような見方をしますが、こうした小さな違いが、巨大な規模の脆弱性管理では非常に重要になります。これらのスコアリングメカニズムの中には、信じられないほど複雑になるものもあるので、単純化というアプローチは強調する価値があります。多くの組織では、リスクスコアリングを単純化することによって、リスクの認定や定量化に時間を費やす代わりに、セキュリティ問題への対処に労力を集中させることができるようになります。
また、影響を受けているかどうかをできるだけ早く把握し、それによって引き起こされるリスクを効果的に削減するためには、常に状況を完全に把握することが必要です。
これらの情報をもとに、今度は脆弱性管理プロセスとそれをサポートするツールを組織内に導入する必要があります。
これらの脆弱性スコアは、アドホックに見ることができますが、効果的なサイバーセキュリティには、システムのライフサイクルの関連する段階に役立つ適切なセキュリティツールに脆弱性のフィードを取り込むことが必要です。
Sysdig は、ライフサイクルを通じてセキュリティ機能を提供するように設計されているため、何らかの製品を提供したい場合には、Sysdig のようなプラットフォームの力が役に立ちます。この言葉は控えめに使わないと、営業的すぎると思われるかもしれません。例えば、脆弱性（CVSSスコアのような）に素早く対処するためのビルドパイプラインでのイメージスキャン機能、または、ランタイムに出現する脅威を特定し、SecOpsチームがDFIRワークフローを起動する必要があるような機能について話す方がよいかもしれません。
重要なのは、新しい脆弱性に備え、脆弱性のリリースと検出プロセスの間のギャップを埋めるために、あなたの環境で柔軟に対応できるようにすることです。
CVSS Severity Score ライフサイクルの脆弱性 最も有名なフィードの1つはVulndbで、脆弱性の信頼できるデータベースとしてNational Vulnerability Database (NVD) を使用し、登録された脆弱性情報も所有し、セキュリティ企業と協力して可能な限り最新の状態に保っています。
脆弱性の明示的な詳細が不明な場合でも、潜在的なリスクがあることを認識した上で、それを受容、回避、軽減する必要があります。それに敏感になるための代替案が必要なのです。
Sysdigのシステムコールに対する深い可視性は、実行時にロードされるパッケージの脆弱性を正確に特定することで、コンテナにおける脆弱性の優先順位付けからすべての当て推量を排除します。
修正に関して克服すべき重要なハードルは、影響を受けたり悪用される可能性がある資産や依存関係をすべて迅速にパッチできることであり、これらのプロセスは拡張できる必要があります。新しい機能やパフォーマンスの低下に影響を与える可能性のある古いバージョンにパッチを適用するのは簡単ではありません。 大規模な方法でそれを行うか、適用しなければ他の影響を及ぼします。この問題は、推移的依存関係によってさらに悪化します。つまり、あなたのコードやシステムは、おそらく他の多くのコードベースやシステムに依存しており、依存関係の連鎖は実際にはかなり入れ子状態になります。時には、まだ配布されている古いバージョンにパッチを当てる必要があることさえあります。これをRedHatはバックポーティング（Backporting）と呼んでいます。
バックポーティング
バックポーティングとは、基本的に自動化によってアップデートを管理し、関連するリスクを最小化することです。新バージョンの修正が旧バージョンに悪影響を及ぼす可能性はあります。できるだけ早くアップグレードしたい場合は、そのタイミングを見極める必要があります。ベンダーがセキュリティ修正プログラムをバックポーティングすることを申し出た場合、その修正プログラムが望ましくない副作用をもたらさないようにし、以前にリリースされたバージョンにも適用されるようにします。
まとめ
毎日何百もの脆弱性が存在する世界では、優先順位をつけることが必要です。私たちは、攻撃者に狙われるようなソフトウェアを継続的に開発し、すでにアプリケーションやシステムで使用されているライブラリ、ファームウェア、または共通の依存関係を追加しています。そのためには、MITREのような組織が共有する脆弱性情報を取り込み、他の情報源との相関関係を通じてより良い指標を生成し、資産（および関連する攻撃ベクター）の完全な可視性を維持して、影響を迅速に検出する必要があります。これがなければ、脆弱性軽減プロセスを効率的に計画して脆弱性のノイズと時間を削減し、サイバーセキュリティプログラムで効果を発揮することは不可能です。
手動プロセスは無限大に拡張することはできませんし、すべてのセキュリティニーズを満たすために十分な人員を確保することもできません。セキュリティは、シームレスかつ自動化されたものである必要があります。log4j や spring4shell のような重要な脆弱性の波に乗り遅れないよう、組織には適切な計画が必要です。
Sysdigを利用すると、どの脆弱性が本当のリスクなのかを迅速かつ簡単に特定することができます。
もう、脆弱性を一行ずつスクロールする必要も、スプレッドシートに延々と書かれた問題からリスクを推定する必要もありません。Risk Spotlightを使用すれば、重要な脆弱性を簡単に見つけ、集中的に修正することができます。
30 日間の無料トライアルに登録し、ご自身の目でお確かめください！