Security NEWS TOPに戻る
バックナンバー TOPに戻る
contents
～とある会社Aと脆弱性診断の結果を受け取った関係者とのやり取り～
脆弱性診断を受けたA社では入社3年目のセキュリティ担当・Bさんが結果に頭を抱えています。なぜなら、社内ネットワークに使っているスイッチにCVSSスコア9.8の脆弱性、リモートアクセスに使用しているVPNゲートウェイにCVSSスコア8.8、オンラインショップ用の受発注管理に利用しているデータベースにCVSSスコア7.5の脆弱性が見つかってしまったからです。リスクはどれも「高」レベルとして報告されたため、Bさんは上司に相談し、すべてに修正パッチを当てるようスイッチとVPNゲートウェイについてはインフラチームの担当者に、データベースについては開発部に連絡することにしました。
インフラチームのCさんとSlackでやり取りをしていたBさんはCさんからこんなことを伝えられます。
インフラチームCさん「修正パッチを適用するとなると、インフラチームは基本みんなリモートだから、誰かを土日のどこかで休日出勤させるか、急ぎだったら平日の夜間に勤務させて、パッチを当てることになるけど、どれぐらい急ぎなの？」
「あと、VPNとスイッチ、どっちを先に作業したほうがいいの？パッチの情報を調べてみたら、VPNのほうは一度途中のバージョンまで上げてから最新バージョンまで上げないといけないみたいで、作業時間がすごくかかりそうだから、別日で作業しないとだめかもしれないんだよね」
Bさんは答えに詰まってしまいました。リスクレベルは高だといわれているけれども、どれぐらい急ぐのかは誰も教えてくれないからです。
答えに詰まって「確認してから折り返し連絡します」と返したところ、「セキュリティ担当はいいなあ。土日とか夜間に作業しなくていいし、すぐに答えなくてもいいんだから」と嫌味までいわれてしまいました。
Bさんは脆弱性診断の結果が返ってきてから1週間後、開発部門のD部長にセキュリティ担当と開発部門の定例会議の際に報告事項としてパッチ適用の件を報告しました。するとD部長はこういいました。
開発部D部長「この件、1週間ほど報告に時間を要したようですが、脆弱性診断の結果以外に何か追加の情報はありますか？あと、この脆弱性診断の結果によるとリスクレベル高とありますが、社内の規定としてどの程度急ぐかといった判断はされましたか？」
開発部のほかの人にもこんなことをいわれてしまいます。
開発部担当者「パッチを適用する場合、ステージング環境で影響を調査したうえで必要であればコードや設定の修正などを行う必要がありますが、その時間や工数は考慮されていないですよね。通常の開発業務とどちらを優先すべきかといった判断はどうなっているんですか？」
Bさんはまたもや言葉に詰まってしまいます。セキュリティ担当は自分と上司の2人だけ、上司は別の業務との兼務でパッチの適用の優先順位付けまで考えている時間はありません。自分もEDRやファイアウォールの運用をしながら脆弱性診断の依頼や結果を受け取るだけで、とても他の部門の業務内容や環境のことまで把握しきる余裕がないのです。
ここまで、架空の会社A社と脆弱性診断の結果を受け取った関係者の反応を物語形式でお送りいたしました。現在、弊社の脆弱性診断サービスでは脆弱性単体のリスクの度合いの結果をご提供させていただくことはあっても、その脆弱性をどういった優先度で修正しなければならないかといった情報はご提供しておりません。なぜならば、パッチを適用するにあたって優先順位をつけるためにはお客様しか知りえない、以下の要素が必要になるためです。
パッチ適用の優先順位をつけるための3つの要素
- 脆弱性を持つアセットが置かれている環境
・インターネット上で公開された状態か、IPSやFWなどで制御されたネットワーク内か、もしくはローカル環境依存といった非常に限定的な環境かといった分類
・CVSSでいう環境スコア（CVSS-E）の攻撃区分（MAV）にあたる、実際の環境依存の要素 - アセットが攻撃を受けた場合に事業継続性に与える影響
- アセットが攻撃を受けた場合に社会や社内（運用保守・人材）に与える影響
冒頭のA社のケースでは以下のように整理できるでしょう。
アセットが置かれている環境
- VPN：インターネット上で公開された状態
- データベース：設定を間違っていなければIPSやFWなどで制御されたネットワーク配下だが、公開ネットワーク寄り
- スイッチ：設置環境によって制御されたネットワーク内かローカル環境になる。
アセットが公開されている場合、攻撃者からよりアクセスしやすいことからより緊急度が高いといえるので、VPN＝データベース＞スイッチの順になると考えられるでしょう。
アセットが攻撃を受けた場合に事業継続性に与える影響
アセットが攻撃を受けた場合に自社の事業継続にどの程度影響が出るかといった要素です。
仮にランサムウェア攻撃によって影響を受けた場合、それぞれのアセットの停止でどの程度の影響が出るかを想定してください。A社の場合事業継続性への影響度順でいうと、データベース＞VPN＞スイッチの順になると考えられます。
今回の場合はデータベースが事業に直結しており、顧客情報を含むデータを持っているため、継続性への影響度が高いという想定です。アセットの利用目的や環境によってはこの順番が入れ替わることもあります。
アセットが攻撃を受けた場合に社会や社内に対して与える影響
A社がランサムウェア攻撃を受けた場合はオンラインショッピングサイトのデータベース関連で以下の影響が見込まれます。
- 顧客情報の漏洩
- 運用およびシステムの復旧にかかる費用と工数
このほかにVPNやスイッチもフォレンジック調査の対象となって業務が行えなくなる可能性が高いと考えられます。VPNに関しては利用できない期間、社員の出社が必須になるなどワークスタイルへの影響も出る可能性もあります。こういったことから、社会および社内に対して与える影響でA社の例を考えると影響度は、データベース＞VPN＝スイッチと考えられるでしょう。
SSVCとは
こうした情報があったうえで利用ができようになる優先順位付けの方法があります。それが「SSVC（Stakeholder-Specific Vulnerability Categorization）」です。SSVCは脆弱性管理プロセスに関与する利害関係者のニーズに基づいて脆弱性に優先順位を付けるための方法論とされており、経営・マネジメント層、システム開発者、システム運用者といったステークホルダーと一緒に脆弱性に対処していくための方法論といえます。SSVCは脆弱性そのものの技術的評価ではなく、脆弱性にどのように対処するかという観点での評価を行うフレームワークになります。
SSVCの3つのモデル
- ソフトウェアやハードウェアの供給者、すなわちパッチを開発する人が用いる「Supplier Decision Model」
- ソフトウェアやハードウェアを利用する側、つまりパッチを適用する人が用いる「Deployer Decision Model」
- CSIRTやPSIRT、セキュリティ研究者やBug Bounty Programなど、脆弱性に対して何らかの調整やコミュニケーションのハブとなりうる人、コーディネーターが用いる「Coordinator Decision Model」
このうち、「Deployer Decision Model」と「Supplier Decision Model」ではプライオリティ（対応優先度）付けの結果を4つにわけています。
SSVCで得られるプライオリティ付けの結果
| Deployer Model | Supplier Model | |
|---|---|---|
| Immediate | すべてのリソースを投入し、通常業務を止めてでもパッチの適用を直ちに行うべきである | 全社的にすべてのリソースを投入して修正パッチを開発し、リリース |
| Out-of-cycle | 定期的なメンテナンスウィンドウより前に、やむを得ない場合は残業を伴う形で緩和策または解消策を適用 | 緩和策または解消策を他のプロジェクトからリソースを借りてでも開発し、完成次第セキュリティパッチとして修正パッチをリリース |
| Scheduled | 定期的なメンテナンスウィンドウで適用 | 通常のリソース内で定期的な修正パッチのリリースタイミングでパッチをリリース |
| Defer | 現時点で特に行うことはない | 現時点で特に行うことはない |
ここではDeployer Decision ModelをもとにA社がどのようにパッチを適用すべきか検討してみましょう。
まず、Bさんは上司に相談したうえで、前述した3つの要素、「脆弱性を持つアセットが置かれている環境」、「事業継続性への影響」、「社会や社内への影響度」を定義していく必要があります。また、この定義に当たっては実際の環境や利用用途、部門内のリソースなどをよく知っているインフラチームや開発部といった当事者、つまりステークホルダーの関与（少なくとも承認）が必要となってきます。このほかに優先順位付けの結果、”Immediate”や”Out-of-Cycle”が出た場合の対応プロセスも用意しておく必要があります。Bさん１人で何かできることはそれほど多くはなく、社内のステークホルダーへの聞き取りや経営層への説明、必要なプロセスの準備と合意形成など、上司や部門全体も含めて組織的に取り組まなければならないといえます。さらに、Bさんは脆弱性自体が持つ以下の要素を調べる必要があります。
脆弱性が持つ要素
自動化の可能性
攻撃者がツール化して脆弱性を悪用するかどうかを判定するものとなります。これは攻撃者がツール化した場合、攻撃者間でツールの売買が行われるなど汎用的に悪用される可能性があるため、把握が必要な要素となります。一部の脆弱性はCISA VulnrichmentやCVSS4.0のSupplement MetricsのAutomatableの値が参照できますが、情報の参照先がないものについてはPoCの有無やPoCの内容から自動化の可否を判断する必要があります。この点はSSVC利用の難点として挙げられることもあります。
悪用の状況
実際に攻撃されていることを示すActive、PoCのみを示すPoC、悪用されていないことを表すNoneの3つに分類されます。この情報は時間の経過とともに変化する可能性が最も高く、逐次状況を確認する必要があります。情報の参照先は、KEVカタログ、CISA VulnrichmentのExploitationの値、CVSS4.0のThreat MetricsやNVDのReferenceのPoCの有無といったものが利用できます。唯一難点があるとすれば、日本国内でシェアの高い国内メーカー機器の情報がKEVカタログやCISA Vulnrichmentなどにあまり反映されない点にあります。
まとめ ～CVSSとSSVCの活用～
これまではCVSSが高い値のものだけ対処していた、という組織も多いでしょう。CVSSは脆弱性の単体評価ができ、脆弱性が広く悪用された場合の深刻度を測るための評価システムです。ただし、その脆弱性が存在するアセットがどのように利用されているか、そのアセットが業務継続性や運用保守、ひいては社会全体に対してどのような影響を与えるかといった観点が欠けていることが長らく問題視されてきたのも事実です。
脆弱性管理は手間がかかる、登場人物が多い、意見がまとまらないといったこともあるでしょうし、「自動化の可能性とかわからないし、攻撃の状況をずっと見ているほどの時間の余裕はない！」といった様々なお声があるかと思います。しかし、今この瞬間どの企業がいつサイバー攻撃を受けるのか全く見当もつかない状況の中、少しでもリスクを回避したい、どこにリスクがあるのか手がかりをはっきりしておきたいという企業の皆さまもいらっしゃるかもしれません。本記事を通じて、こういった脆弱性管理手法があることを知っていただき、活用することでリスク回避ができるようになるための役立つ情報提供となれば幸いです。
参考情報：
- 独立行政法人情報処理推進機構（IPA）「共通脆弱性評価システムCVSS v3概説」
https://www.ipa.go.jp/security/vuln/scap/cvssv3.html - カーネギー・メロン大学「SSVC: Stakeholder-Specific Vulnerability Categorization」
https://certcc.github.io/SSVC/
公開日：2024年9月10日
更新日：2026年5月13日
編集責任：木下
Security NEWS TOPに戻る
バックナンバー TOPに戻る
サイバーインシデント緊急対応
ウェビナー開催のお知らせ
最新情報はこちら
Youtubeチャンネルのご案内
SQATチャンネル（@sqatchannel9896）では毎月、アナリストが語る「セキュリティトピック」解説動画やウェビナー動画を更新しています。 ぜひチャンネル登録をして、チェックしてみてください。
