Techカテゴリ

Zoom社が公開した VISS(Vulnerability Impact Scoring System) の概要

2023-12-16日頃に、Zoom社が脆弱性スコアリングシステム VISS(Vulnerability Imapct Scoring System) を公開した、というニュースが出てきました。

「突然出てきたな」という印象でしたので確認しました。
詳細な解説ではなく、概要を共有しようと思い、休日にBlogを書き始めました。

※本Blogの内容は会社の見解ではなく、筆者の個人的な見解です。また、認識違いなどがある可能性があるため、参考情報としてください。

exective summary

所謂、今北産業(今来たから3行で要約して、の意)。

  • VISSは、現時点で「Zoom社以外がすぐ使えるフレームワーク」ではないと考えます
  • しかしながら、検討観点としては非常に参考になります
  • 故に、考え方の観点をここから学び、自社の既存運用/トリアージに役立てるのが良いと思われます。

今回はこのように、一部フォーマルでない表記をします。

VISSとは

VISSのサイト https://viss.zoom.com/ によると、以下のようなもののようです。

  • VISS は Vulnerability Impact Scoring System/脆弱性影響スコアリングシステム
  • 脆弱性の客観的な影響特性を示す
  • CVSSとは異なる視点で、保管的な評価システムとして機能する
    • CVSSは、主に攻撃者の視点から脆弱性を主観的に評価し、最悪の場合の影響を想定している
    • VISSは、防御者の観点で、実証された影響を責任を持って測定する
      • 論理的な悪用の可能性を無視し、実際の悪用に焦点を当てている

フレームワークとしては以下のようです。

  • 評価方法
    • 各脆弱性について、13の影響する側面を評価する
  • スコア
    • **評価値は 0-100 **で表示し、補償コントロールメトリック(Compensating Controls metric)で調整できる
  • 算出者
    • 脆弱性が見つかったシステム、環境、ネットワーク、または製品を担当すする組織がVISSを算出する
      • あるいは、バグバウンティ トリアージチームなどの外部団体が、変わりに評価することもできる

特徴として「脆弱性によりどのような影響を受けるか」を念頭に置いたフレームワークのようです。
そして「悪用可能性」という不確実な検討コストがかかる部分を切り捨て、「実際の悪用」に焦点を当てています。これにより、このフレームワークのスコアは現実的な影響を示している=スコアをそのまま受け取って良いもの、として使えそうに見えます。

  • CVSS BaseScoreは”最悪を想定した”評価なので、実際に発生しない可能性があるのかを検討する必要があります。そのため、スコア通りに受け取ることはあまりないように思えます。

この時点では、良さそうなフレームワークなのではないか、と思っていました。
Specificationを読むまでは…

Specifications

https://viss.zoom.com/specifications でv1.0の仕様が公開されています。

  • Versionsを見ると、2023年で頻繁に更新されていました。

Specificationsには全体の図がありますが、実際に利用するには分かりづらい表現に感じました。

Calculatorを見たほうが、分類としては分かりやすいと思います。

全体としてPLIをrootとして以下の分類になっているように見えます。

  • Platform Impacted(PLI)
    • Platform impactグループ
      • Confidentiality/Integrity/Availability Impact(ICI, III, IAI)
    • Tenancy impactグループ
      • Infrastracture/Software/Data Impact(ITN, STN, DTN)
      • Tenants Impact(TIM)
    • Data impactグループ
      • Confidentiality/Integrity/Availability Impact(DCI, DII, DAI)
      • Data Classification Involved(DCL;データ分類の関与)
    • Upstream Compensating Controls(UCI;上流の補償制御)

個人的には、以下の図のようになると考えいます。

Platform Impacted(PLI)

最初に、PLI:Platform Impactedを決定します。

  • 脆弱性の影響を受けるプラットフォームを選択します
  • 選択肢は以下のとおりです
    • N/A
    • サードパーティーの ホストしているもの/ツール/ライブラリ
    • モバイルアプリケーション
    • デスクトップアプリケーション
    • ブラウザアプリ/APIエンドポイント
    • 顧客インフラストラクチャ
    • Zoomインフラストラクチャ
    • ドキュメンテーション

そして注意してもらいたいのは「Zoomインフラストラクチャ(Zoom Infrastructure)」がある点です。
これは「コンテナ、仮想マシン、物理マシン、ネットワーク デバイス、ファイアウォールなどのサービス インフラストラクチャを指します」が、同時に「Zoom のクラウドベースまたはオンプレミスのインフラストラクチャに限定されています。(The demonstrated impact is limited to Zoom’s Cloud-based or on-prem infrastructure.)」となっています。
これは十分に汎用化されたフレームワークではなく、Zoom社での利用が想定されているままのものと考えて良さそうです。”自社インフラストラクチャ”とそのまま読み替えてよいかは要検討だと思われます。

Specificationの1. Introductionでは、各社ごとに変更して利用できる旨が書いてありますが、自社ごとのカスタマイズ負荷を考えると直接利用するのは難易度が高いように思われます。そのため、このフレームワークの考え方を学び現在利用している対応方針に組み込む、程度が現時点では良いように思えます。

観点としては確かに以下がありそうです。

  • サードパーティーでの影響
  • エンドユーザアプリケーションでの影響
  • デスクトップ及びモバイルアプリケーション間のデータでの影響
  • 顧客インフラストラクチャへの影響
  • 自社インフラストラクチャへの影響
  • ドキュメンテーションへの影響

Platform Impact(ICI, III, IAI)

プラットフォームへの影響を表現します。セキュリティのCIAと呼ばれる 機密性/完全性/可用性（Confidentiality/Integrity/Availability）への影響を示します。

しかしながら、略称が I(C|I|A)I なのか、少し直感的ではないように思えます。

  • 例えばICIは The Platform Confidentiality Impact metric ですが、Platform **I**mpacted **C**onfidentiality **I**mpact metric のためだと思われます。
    • 普通に考えたら、P(C|I|A)I じゃんね？、と思います

各metricに設定されている値は以下の図にまとめています。粒度は参考になると思われます。

Tenancy Impact(ITN, STN DTN and TIM)

脆弱性が見つかった（インフラストラクチャ|ソフトウェア|データ）のテナンシーを指定します。

また、TIM(Tenants Impacted)という、脆弱性の悪用が成功した場合に影響を受けるテナントの範囲を指定できます。

各metricに設定されている値は以下の図にまとめています。粒度は参考になると思われます。

Data Impact(DCI, DII, DAI and DCL)

脆弱性の悪用が成功した場合に関係するデータの、機密性/完全性/可用性への影響を示します。

  • 組織は、一連のユーザが関連付けられいる単一のエンティティを示し、単一の組織に関連付けられているすべてのユーザが影響を受けます。
  • 組織感は、ある組織で発生したものが、他の組織のデータに影響を与えることを示します。
  • セッションテイクオーバー(乗っ取り)は、攻撃社が認証済みセッションへのアクセスを想定してますが、パスワードリセット等ができずにアカウント乗っ取りまでエスカレートできないことを想定されています。

DCL:Data Classification Involved（データ分類の関与）は、組織内のデータ分類により影響範囲が変わることを想定されています。

  • テストデータであれば、これが公開されても驚異はなく、組織に影響はないと考えられる。
  • ここでも Zoom社に於いての定義 が出ているが、社内での内部/機密/制限のある 情報と捉えて良さそうです。
  • かけがえのないお客様データは、一度削除すると復元できないデータとして想定されています。
    • お客様が、（どうでもいい|かけがえのない）の2分類に分かれていなくてよかった。。

各metricに設定されている値は以下の図にまとめています。粒度は参考になると思われます。

Upstream Compensating Controls(UCI)

見つかった脆弱性の悪用成功に対して、プラスの防御効果をもたらすセキュリティ制御の存在を指定できる、とされています。

  • 追加のセキュリティ制御で、影響を軽減できるか、というような想定

各metricに設定されている値は以下の図にまとめています。粒度は参考になると思われます。

まとめ

VISSは端々にZoom社での値が残っており、直接そのまま使うことはできないと考えられます。

  • 自社に合うように修正するのは、工数がかかる
    • metricの取りうる値を、自社のビジネスに合うか変更が必要と思われる
  • また、決定項目が詳細なため、「すでに、かなり脆弱性対応/判断ができている組織」ではないと実装は難しいと思われる

とはいえ、検討観点については非常に有用なので、検討観点を今の自組織の対応に追加要素として持ち込めれば良いように思いました。

  • 例えば、、
    • PLIがDocumentationだと、Data Impactの完全性(DII)飲みに影響がある、とする
    • 影響のあるデータがテストデータのみ(DCL: Test Data Only)であれば、レーティングは低くなる
    • など

とはいえ、「脆弱性によりどこまで影響が及ぶか」を詳細に判定できる必要があり、一般的な「CVSS BaseScoreで判断する」という企業では難しい（そこまで踏み込んで判断できる人員/時間/工数/コスト が不足している）と思われます。故に、自組織でのトリアージの際に、これらの観点を追加要素として取り入れ、無理のない範囲で実践するのが良いかと考えられます。これは、VISS自身が”CVSSを置き換えるものではない””追加要素として使う”ことを想定している部分と合うと思います。

今後、VISSがもう少し汎用的になった際は、再度詳細に確認しようと思いますが、現時点では「雰囲気を知る」だけで良いように思います。

宣伝

このような記事を継続して書くためには、記事があることでFuturVulsトップページへの流入が増える、という内部評価が必要です。
もしよろしければ FutureVulsのトップページ https://vuls.biz/ も訪問いただけると助かります。

また、セキュリティコンサル/脆弱性対応コンサルも行っております。ある程度は無償でご相談をお受けすることはできると思いますので、私のメールまでご連絡ください。

  • k。inoue。xz@future。co。jp
    • 。を.に変換ください。

よろしくお願いいたします。