SCAP, SSVC, 解説

脆弱性評価で使われるCVSSについて

共通脆弱性評価システムCVSS(Common Vulnerability Scoring System)について解説します。

概要

オッス、オラGPT3.5！
稼働しているサーバに見せるために、それっぽくテキストを生成してるぞ！以下の呪文を唱えて、手動で追加文章差し込んで調整して投稿してるから、手間かかってんぞ！
一般的な「如何でしたブログ」よりはまともなものにしてっから、ヨロシクな！

あなたは、サイバーセキュリティの研究者です。CISAのリリースや、NISTのSPシリーズなどを理解しています。
脆弱性の表現で使われるCVSSについて、セキュリティ関係者に分かるように説明をしてもらえますか？
以下の構成を参考にしてください。
1. 概要
2. CVSSとは何なのか
3. どのような読めばよいのか
4. Vectorはどのように扱えばよいのか
5. どのように使えばよいのか

2022/0506-  hogehuga

CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を数値化して評価するための指標であり、セキュリティ関係者に広く採用されています。

CVSSとは何なのか

CVSSは、脆弱性の深刻度を評価するための国際的な規格であり、スコアを算出することで脆弱性の重要度を評価することができます。CVSSは、基本評価基準、影響度、環境評価基準の3つのメトリックからなり、これらのメトリックを組み合わせてスコアを算出します。

手動補足！

米国で、脆弱性対策の重要性が認識され多事によりFISMA(連邦情報セキュリティマネジメント法)やSOX法などが施行されたことにより、連邦機関の膨大な数のシステムの脆弱性管理が必要になった。その為、脆弱性管理の自動化が必要になり、SCAP(Security Content Automation Protocol：セキュリティ設定共通化手順)が開発された。

SCAPは脆弱性管理や測定や評価を自動化するための共通言語として利用されるのだが、日本国内では一部の基準しか利用されていないように思われる。代表的な物が、CVEやCVSSやCPE辺りで、システム運用者なら一度は聞いたことがあるはずだ(ref: https://csrc.nist.gov/Projects/Security-Content-Automation-Protocol/SCAP-Releases/scap-1-3 )。主要なものを例示する。

  • XCCDF：eXtensible Configuration Checklist Description Format/セキュリティ設定チェックリスト記述形式
  • OVAL：Open Vulnerability and Assessment Language /セキュリティ検査言語
  • CPE：Common Platform Enumeration/共通プラットフォーム一覧
  • CVE：Common Vulnerabilities and Exposures/共通脆弱性識別子
  • CVSS：Common Vulnerabilities Scoreing System/共通脆弱性識別子
  • etc

雑にまとめるとこれらで、対象を一意に識別し(CPE)、脆弱性を一意に識別し(CVE)、脆弱性の危険度を表し(CVSS)、自動で検査(OVAL, XCCDF etc)することで状況を明らかにする。残念ながらこれらの仕組みは「状況を示す」だけで、「アクション」は示していない。これは「CVSS Base Scoreで8.5です！」は示すが、「8.5だからどうすればいいの？」や「N日以内に対策をせよ」という指標にはなっていない。この部分はSSVC(Stakeholder Specific Vulnerability Categorization)などが対応できる分野と考える。SSVCは、脆弱性自体の脅威や保護対象の状況や脆弱性の悪用状況などを加味し、すぐやれ/定期メンテ前にやれ/定期メンテ時でやれ/リスク許容できるはず、のアクションを提示する(利用するツリーにより、output(アクション提示)は変わる)。 (ref. https://democert.org/ssvc/ )

日本ではあまり使われていないように思われる/Windowsでは実質使われていない気もするが、XCCDFなどを用いてセキュリティポリシーと合致しているかを調べることができる。RedHatにおいてはこの部分は十分用意されており、SCAP Security Guide(SSG)のセキュリティポリシーガイドを基に、OpenなSCAPの実装である”OpenSCAP”を用いて検査することができる(ref. https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sect-auditing_system_settings_with_ssg_example )。

日本でCVSS解説資料は、IPAのサイトのものが一応まとまってはいるが、内容は古いようにも思える。原典であるFIRSTのCVSS v3.1等を一時資料とすべきと思われるが、概要理解には依然有用である。

  • https://www.ipa.go.jp/security/vuln/scap/cvss.html
  • https://www.ipa.go.jp/security/vuln/scap/cvssv3.html
  • https://www.ipa.go.jp/security/vuln/scap/scap.html
  • https://www.first.org/cvss/v3.1/specification-document

どのように読めばよいのか

CVSSのスコアは、0から10までのスケールで表現されます。スコアが高いほど、脆弱性の深刻度が高くなります。CVSSのスコアには、基本評価基準、影響度、環境評価基準の3つのメトリックがあります。

手動補足！

CVSSで用いられるScoreは、0.0-10.0の小数点1桁の数値で表現される。そして一般的に利用されているのはCVSS Base Scoreである。

なぜBaseを強調するのかといえば、CVSSの3つのグループ(BaseMetric|TemporalMetric|EnvironmentalMetric)のBaseMetricのみのScoreを指していることが大半であるからだ。雑に言えば、　Temporalが示す時間的指標や、Environmentalが示す環境指標が考慮されていない、「脆弱性それ自体の性質」しか見ていない事を示している。これは実環境を想定すると、「他の防護策が行われているからリスクは軽減されている」「PoCなどの有無など、攻撃が有利に使われる状況なのか」などが考慮されていない指標という事を意味する。危険な物(=攻撃を受けて事業に対するリスクが発生する確率が高い物)から対応しようとする場合、考慮が足りないことになる。

因みに、各MetricGroupは以下のMetricsで構成されている

Base Metric Group：
Exploitability metrics(AttackVector, Attack Complexity, Privileges Required, User Interaction), Impact metrics(Confidentiality Impact, Integrity Impact, Availability Impact) and Scope

Temporal Metric Group：
Exploit Code Maturity, Remediation Level, Report Confidence

Environmental Metric Group：
Modified Base Metircs, Confidentiality Requirement, Integrity Requirement, Availability Requirement

おそらく、Temporal/Environmental Metricsは一般的には利用するのが困難だと考えられる。なぜならば、時間的に変動数要素があり定期的な情報収集が必要(temporal)、システムに対しての理解や定義が必要(CDP:Collateral Damage Potential/二次被害の可能性 や対象システムのセキュリティ要求度などの定義が必要で、運用というより会社の経済活動としての定義が必要)(Environmental)。

またTemporal/Environmentalを用いて運用できる運用能力があるのであれば、わざわざSSVCのフレームワークに乗せる必要はないのではないか、という問題もある。SSVCのスコア算出が(Temporal/Enviromnentalを考慮したとして)それが本当に現実に即しているのか、という問題がある。例えば、8.0以上は即時対応と定義した場合、7.9の場合は問題が無いのという問題や、ベンダによりVectorの見立てが異なる(=BaseScoreも異なる)のをどう見るか、等固定的に評価がされる物でもないという問題もある。

Vectorはどのように扱えばよいのか

CVSSのスコアを算出する際には、基本評価基準、影響度、環境評価基準の3つのメトリックに加えて、Vector（脆弱性の属性を表す文字列）が必要です。Vectorは、脆弱性の基本的な情報を表す文字列であり、攻撃者のリスクアセスメントや脆弱性の修正のために必要な情報を提供します。

手動補足！

基本評価基準、と言っているもの(BaseMetricGroup)にVectorが含まれている。CVSS的には、BaseMetrics/TemporalMetric/EnvironmentalMetricを見て対応を検討すればよいと考える。

Vector的には、AC:Attack Vector(攻撃元区分)でどの範囲のネットワークから攻撃可能かを見て、AC:Attack Complexity(攻撃条件の複雑さ)は簡単なものほど対応優先度を高くすべきだし、PR:Privileges Requiredで権限等が不要なものを優先し、S:Scope(スコープ/計算機資源に対する管理権限の範囲を考慮する必要がある)が拡大するものを優先し、セキュリティのCIA(C:Confidentiality Impact(機密性への影響), I:Integrity Impact(情報改ざんの可能性), A:Availability Impact(可用性への影響))で被害を考慮して、対応優先度を決定する(所謂トリアージ)必要がある。

これらを考慮したのがBase Scoreなので、BaseScoreを見て有線対象を決め、各Vectorを見ていくのが本来的には良さそうではある。そして、Environmental/TemporalはBaseScoreの増減ではなく、考慮事項とする(そもそもそれすら難しい組織は多いので、無視される)位が現状と考える。自動化という意味では、スコアリングは特定の基準でできたが、本当に対象の環境にマッチしたスコアリングになっているのかは不明、且つスコアとアクションの関係が未定義、という問題は残っている。

どのように使えばよいのか

CVSSは、脆弱性情報を共有し、リスクを最小限に抑えるために広く使用されています。セキュリティ関係者は、CVSSのスコアやVectorを確認し、脆弱性の深刻度を評価し、必要な対策を講じることができます。また、CVSSは、脆弱性情報の共有や、セキュリティ関連の意思決定に役立ちます。

手動補足！

役立ちはするが、それだけで決定するのは難しい。究極的には「BaseScore（or Temporal/Environmentalで補正したScore)が NN.N以上なら対応、未満ならリスク許容」みたいなところにしかならず、事業リスクとして対応が必要かどうかまでは見れていない。

CVSSは、脆弱性それ自体の影響を速報として理解するためには非常に有用で、そこから先のアクションを導出するのをCVSSでやろうとすること自体がそもそもの設計意図から外れていると考える。

そこで比較的対応意思決定に寄与できるのが、先述のSSVCと思われる。今後、このハニポブログでもSSVCについて述べる可能性を残しつつ、今回の記事手動補足の筆をおくことにする。尚、一度書いた後の推敲や誤字脱字チェックは一切していない。

次回からは、Line的な対話形式吹き出しデザインで記事を生成するかもしれない。