セキュリティコミュニティ「WEST-SEC」

セキュリティ初心者の方でも参加できる「わかりやすい」セキュリティイベント、8割解けるCTFを開催しています。

脆弱性管理

1.脆弱性とは

1.1 脆弱性とは

脆弱性とは、情報セキュリティ上の弱点や欠陥です。似たような言葉に、バグやセキュリティホールがあります。
ここで議論する脆弱性ですが、言葉の厳格な違いを意識してもらう必要はなく、CVE番号で管理された脆弱性と考えてください。

・CVEの数だけでみると、脆弱性は年々増えている。25083個（2022）→　29065個（2023年）
・以下、グラフにしてみたが、脆弱性は年々増えている。

（出典：https://nvd.nist.gov/vuln/search/statistics?form_type=Basic&results_type=statistics&search_type=all&isCpeNameSearch=false）
・【参考】以下は日単位で脆弱性の数の情報を見ることができる。
https://www.cvedetails.com/browse-by-date.php

1.2 脆弱性の指標

(1)脆弱性指標の全体像

CVE、CWE、CVSSを理解しましょう。

指標 意味
CVE（Common Vulnerabilities and Exposures） CVE-西暦年-4桁の通番で表される脆弱性の通番
CWE（Common Weakness Enumeration） 脆弱性の種類（脆弱性タイプ）
CVSS（Common Vulnerability Scoring System) 脆弱性の深刻度を0.0～10.0の範囲で表現
(2)CVE

・共通脆弱性識別子CVE概説
https://www.ipa.go.jp/security/vuln/scap/cve.html

(3)CWE

・共通脆弱性タイプ一覧CWE概説
https://www.ipa.go.jp/security/vuln/scap/cwe.html
・以下は、2021年から2024年のCWEのTOP10です。圧倒的にXSS（クロスサイトスクリプティング）が多いです。（Y君作成）

(4)CVSS

・共通脆弱性評価システムCVSS v3概説
https://www.ipa.go.jp/security/vuln/scap/cvssv3.html
・上記のサイトを元に、CVSSを評価する3つの基準の中身を見ましょう

項番 基準 基準の内容 備考
(1) 基本評価基準(Base Metrics) 脆弱性そのものの特性を評価する基準です。 時間の経過や利用環境の異なりによって変化しません。
(2) 現状評価基準(Temporal Metrics) 脆弱性の現在の深刻度を評価する基準です。 脆弱性への対応状況に応じ、時間が経過すると変化します。
(3) 環境評価基準(Environmental Metrics) ユーザの利用環境も含め、最終的な脆弱性の深刻度を評価する基準です。 ユーザ毎に変化します。

・CVSS のスコアと深刻度に関して、以下の資料がある。ただし、この後にも記載するが、これはあくまでも基本基準だけであるので、これでリスクは評価できない。

出典は、デジタル庁の資料
・CVSSの環境値は、「基本値 × 現状評価の指標による補正 × 環境評価の指標による補正」で計算されます。
・以下に、2023年6月14日に出されたIPAからの注意喚起があります。
https://www.ipa.go.jp/security/security-alert/2023/alert20230613.html
・このCVE-2023-27997を、JVNの脆弱性対策情報データベース（https://jvndb.jvn.jp/index.html）で調べてみましょう。
・基本評価基準を見ると、9.8(Critical)です。攻撃元区分が「ネットワーク」なので、インターネットから攻撃される可能性があり、非常に危険と言えます。
・じゃあ、それ以外の基準（現状評価基準、環境評価基準）はどうかというと、実際に見てもらえばわかりますが、「未評価」です。

1.3 CVSS基本値による評価の限界

・CVSSは指標の一つであり、また、先に述べたように、現状評価基準、環境評価基準はどうかというと、「未評価」です。つまり、CVSSだけでは、その組織において本当に危険かどうが判断できない。そこで、新たな指標が求められる。
IPAの資料の引用であるが、「各脆弱性のリスク評価を実施する際には、脅威・脆弱性・資産の3 要素全てを含んだ評価することが望ましい」とある。※当たり前であるが。

CVSSで環境評価基準を加えるのは現実的には難しい
・　「脆弱性対応におけるリスク評価手法のまとめ」（https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/risk-assessment-methods.html）にも、以下の記載があります。

CVSS基本値が脆弱性そのものの深刻度を評価する点では有用であるものの、脆弱性の悪用状況やユーザの環境情報を考慮していないため、脆弱性対応の優先度を決定するために、単体で使用するのは適切ではないと考えた。

1.4 SSVCやVPR

上記の課題があり、現実的には、脆弱性管理ツールなどを使い、SSVCなどの指標で管理をするのが望ましいであろう。

(1)SSVC

・カーネギーメロン大学が発案したSSVCという指標を入れている。偶然かは不明だが、CVSSの逆のスペルになっている。　
・SSVCでは、対応のレベル（優先度）を「immediate」「out-of-cycle」「scheduled」「defer」の4段階で分類する。
・SSVCを算出する項目は以下。

項番 内容 レベルの数 レベルの詳細 設定者 備考
1 攻撃コードの公開有無と悪用レベル 3 active、Poc、none FutureVuls 　
2 システムの露出レベル 3 open、controlled、small 利用者 　
3 攻撃コードの自動化（攻撃が自動で実行できるか） 2 yes、no FutureVuls ver2.1から。それより前は「攻撃者にとっての有用性」
4 攻撃された際の業務影響 4 very high、high、medium、low 利用者 　

１と３はFutureVulsが独自に算出するが、時系列で変化する。
・どうやって決定するかは、決定木になっていて、こういう条件だとどっちに分岐するなどと決められている。

（出典：https://speakerdeck.com/futurevuls/sbom-nihuo-wasareruna-ssvc-niyoruqi-ye-sisutemunoben-zhi-de-nacui-ruo-xing-risukuguan-li-noshi-jian?slide=11）
・決定木のロジックは変えることができるが、標準のものを使うことが多い。
（出典：https://certcc.github.io/SSVC/pdf/ssvc_2_deployer_SeEUMss.pdf）
・immediateに分類されるロジックは、以下の赤の3パターン。なので、4項目すべてが高い状態だと考えていいだろう。

（出典：同上）
・SSVCの場合、以下の資料に公開されている。ただし、システムを利用する環境によって、結果は大きく変わるであろう。

（出典：https://speakerdeck.com/futurevuls/sbom-nihuo-wasareruna-ssvc-niyoruqi-ye-sisutemunoben-zhi-de-nacui-ruo-xing-risukuguan-li-noshi-jian?slide=18)
・上の資料を補足すると、たとえば、4716件の脆弱性が存在したとする。
❶CVSSでの管理
たとえば、組織の基準で、CVSS7.0以上を周知するとすると2863件。8.0以上とすると990件が管理対象になる。これはかなりの数。
❷SSVCでの管理
たとえば、4段階ある中で、組織の基準ではimmediateだけを周知するとすると、16件しかない。仮にout-of-cycleまで増やしたとしても、たったの50件である。
なおかつ、CVSSは7.0未満であっても、攻撃されると被害に合うケースもあり、それらも抽出してくれる。

Q.疑問：でも、CVSSの現状値なら、現在のリスクを反映しているから、EPSSと同様では？

A.現状値 (Temporal Metrics) はほとんどの場合、公開されていません（先にも示した通りです）。評価が難しいので、JVNやNVDなどでは、基本値だけを示すケースがほとんどです。

(2)VPR

・Tenable社の場合、全ての資産に、VPR（脆弱性のリスクスコア） × ACR（ASSET CRITICALITY RATING:資産重要度） = AESというスコアが割り当てられる。
・組織全体のAESの平均値がCES。
・VPRは、EPSSに近い。VPRもCVSSもどちらも脆弱性のリスクスコアであるが、ChatGPTに答えさせた違いは以下である。

比較項目 VPR（Vulnerability Priority Rating） CVSS（Common Vulnerability Scoring System）
作成元 Tenable独自 オープン標準（FIRSTという国際団体が管理）
目的 「今、本当に優先して対応すべきか」を判断するため 「脆弱性そのものの危険度」を客観的に評価するため
更新頻度 毎日更新（リアルタイム性あり） 基本は一度決まると固定（CVSSv3など）
反映される情報 -攻撃が実際に行われているか（リアル攻撃情報）
-エクスプロイトコードが存在するか
-マルウェアで悪用されているか
-脆弱性そのものの内容		 -脆弱性の技術的な内容だけ
（例：認証不要、リモート実行可能、など）
スコア範囲 0.1～10 0.0～10.0
スコアの意味合い 「ビジネス上の対応優先度」 「脆弱性の理論上の重大さ」

・スコアに関してはここに説明があります。
・VPRが表示される。機械学習でSNSなどの結果も反映し、本当に危険であるかがわかりやすい。CVEに比べ、VPRだと場合によって、数%程度にまで絞れる

（出典：https://jp.tenable.com/blog/what-is-vpr-and-how-is-it-different-from-cvss）

(3)EPSS

EPSS（Exploit Prediction Scoring System）はFIRST（Forum of Incident Response and Security Teams）が作ってる脆弱性のスコアである。
今後30日以内に脆弱性が悪用される度合いを表し、CVSSは反映されていない。

(4)KEV（Known Exploited Vulnerabilities）

・実際にエクスプロイトが観測されたCVE（Common Vulnerabilities and Exposures）をまとめたデータベース
・CVSSスコアに関係なく、「現実に攻撃に使われているか」を重視
・目的は、すでに悪用が確認された脆弱性に対し、迅速な対応を促すため
・管理機関は、CISA（米国国土安全保障省・サイバーセキュリティ局）

(5)多くの企業で利用している指標

以下はWEST-SECでのアンケート結果です。

1.5 関連する用語

❶アタックサーフェイス（Attack Surface）
　攻撃者が侵入や攻撃を仕掛ける入口となるすべての要素（例：公開サーバ、API、開いているポート、ユーザアカウントなど）。
❷ コンテキスト（Context）
　対象資産の状況のこと。たとえば「どの部署が使っているか」「ビジネス上どれだけ重要か」「社内限定か外部公開か」など。
❸エクスポージャ管理（Exposure Management）
　攻撃される可能性のある要素（エクスポージャ）をコンテキストに基づいて可視化し、優先順位をつけて対処すること。

2. 脆弱性管理

2.1 脆弱性管理（広義）

本来、脆弱性管理といえば、たとえば、パッチをあてる以外に、設定ミスが無いかなども含まれるでしょう。
脆弱性の定義は多少曖昧ですが、脆弱性診断といえば、ポートが空いているなどもチェックします。
また、クラウドの場合はCSPM(Cloud Security Posture Management）としてポスチャマネジメントの内容も含みます。たとえば、設定ミスや、2要素認証が設定されていないことや、管理者権限にアクセスキーが設定されているなど。

2.2 脆弱性管理（狭義）

ここでは、狭義という言葉が適切かはわかりませんが、ソフトウェア資産のOS等のバージョンを管理し、それがリスクがあるかという点に絞った脆弱性管理について述べます。
CVE番号が付与された脆弱性の管理と考えてもらってもいいでしょう。
また、ここでいう脆弱性管理は、主にオンプレのサーバを中心に、加えて、クラウドのIaaS/PaaS上のサーバを意識したものです。

2.3 脆弱性管理（クラウド）

・オンプレだろうがクラウドだろうが、脆弱性管理は必要です。ではなぜクラウドになるとCSPMなどのセキュリティの対策が増えるのか。
・理由の一つは、インターネットに公開されていて、どこからでもアクセスできることがあります。
・クラウドの場合、脆弱性管理ももちろん大事ですが、それより、実際のセキュリティ事故を見ると、アカウントの設定が甘かったりといった、基本的なミスが圧倒的に多いです。よって、ポスチャマネジメント（CSPM）などが求められます。
・CSPMの利用状況に関して、WEST-SECのアンケート結果です。

・参考までに、オンプレとクラウドの割合をWEST-SECでのアンケートで聞いてみました。概ね、半々という感じでした。

2.4 脆弱性管理（狭義）の流れ

❶情報資産の管理
組織内で保有している情報資産の名称、ホスト名、IPアドレス、ソフトウェアのバージョン情報、設置場所、管理責任者、連絡先などを一元管理します。
一つのサーバに大量のソフトウェアがインストールされている場合があり、また、随時バージョンが変わるので、その管理は大変です。

❷脆弱性情報の収集
脆弱性対策情報ポータルサイトであるJVN（Japan Vulnerability Notes）や、情報処理推進機構（IPA）の「重要なセキュリティ情報」、ニュースサイト、セキュリティのコミュニティや取引ベンダなどを通じて、脆弱性情報を収集します。
ただ、これは難しいのでTenableなどのツールを使う場合もあります。

❸リスク評価
情報資産に対する脆弱性を特定し、その脆弱性のリスクを評価する。たとえば、管理用ポートに対する脆弱性があったとしても、その管理ポートを外部に公開していなければ、リスクは大きく下がります。

❹脆弱性情報の配信　
※組織によって有り無しがあります。また、❸のリスク評価と順番が前後する場合もあります。
・収集した情報を各組織（システム主管）に配信します。
・資産状況を把握していると、その資産に適合した脆弱性を配信できるのですが、正確な把握をしていないと、リスクがあるものは全て流すことになってしまいます。受け取る側も、「適合しない」脆弱性を大量に受け取ることになり、負荷が高くなります。
・場合によっては、配信したものに対して、適合するかや対処したかまでの報告を求める組織もあり、管理負荷が高くなる。

❺脆弱性への対処
・脆弱性が発見された場合、それが自社のシステムにどれくらいの影響があるかのリスク評価をします。
・対処すべきと判断された脆弱性に対して、システムの改修、ソフトウェアのアップデート、セキュリティ機器での対処などをします。

2.5 脆弱性診断

脆弱性管理のほかに「脆弱性診断」（またはもう少し広く「セキュリティ診断」）という言葉もあります。
こちらは、診断の軸として、プラットフォーム診断とWebアプリケーション診断があります。
最近では、ペネトレーションテストなどが、特に金融系のお客様で行われることがあります。

Q.脆弱性管理と脆弱性診断の違いは？
A.脆弱性診断（セキュリティ診断）は1年に1回などの単発。しかし、脆弱性は日々出るので、脆弱性管理では、日々実施する（＝サイクルを回す）という考え方。

観点 脆弱性診断 脆弱性管理
目的 脆弱性の「発見」が主目的 脆弱性の「継続的な可視化・対処」
対象範囲 おもにインターネットに公開されたサーバ 全社的なIT資産全体（※考え方による）
実施タイミング 単発 継続的
代表ツール -OWASPZAP
-BurpSuite
-Nessus
-OpenVAS		 -Tenable（Nessus/Tenable One）
-QualysVMDR
-Rapid7InsightVM
-FutureVuls

3. 脆弱性管理の悩み

3.1 脆弱性管理の難しさ

脆弱性管理は非常に難しいです。理由はいくつかあります。
・CVSSだけでみると、ほとんどが緊急度が高になってしまう。本当はそうではない。
・他社で重大な脆弱性が、自社でも重大とは限らない
・脆弱性は、時間であったり、組織の対策によって変わる
・リスク＝情報資産の価値×脆弱性×脅威であるので、同じ脆弱性であっても、情報資産の価値によってもリスクが変わる
・本当に攻撃が成立するかの判断には、セキュリティやシステムに関するかなりのスキルが必要
・脆弱性があれば、それを塞ぐのではあるが、そう簡単にシステムを止めることはできないし、ソフトウェアをアップデートするっていうのは、アプリケーション試験も必要で、かなり大変な作業になる場合がある

3.2 脆弱性管理の悩み

・WEST-SECにて、「脆弱性管理での悩みを教えて下さい」というアンケートを採りました（複数選択可能）。


悩みだらけですね。
1位：脆弱性が既存システムで露呈するか、およびそのリスクの判断　74（62.1%）
2位：知識・技術・経験不足　69（57%)
3位：運用しているシステムの正確な把握（OSやソフトウエアおよびそのバージョンなど）　67（55.4%)
3位：リソース不足（人員・予算）　67（55.4%)
5位：発見した脆弱性への対処　59（48.8%）
5位：脆弱性情報の正確な情報収集　59（48.8%）
7位：管理負荷（レポート作成・報告など）　45（37.2%)
8位：5位：脆弱性スキャン／診断の精度　43（35.5%)　

加えて、アンケート項目に入れませんでしたが、「脆弱性管理の管理コストが高い」「リアルタイムでの脆弱性情報の配信・対処」もあると思います。
・以下は、対処に関して「脆弱性の検知→修正完了までの平均リードタイム」を聞きました。「２，３日以内」は5%しかなく、対処に非常に時間がかかっていることがわかります。

・以下は悩みに関するアンケート結果です。

Q.その悩みを具体的に教えてください

・パッチなどの適用による影響範囲、調査が難しい。 一部のサーバで検証環境がないため事前検証ができない。 そもそもパッチ当てれないサーバが多い
・Nessusスキャナのクレデンシャルスキャンにより、システムが停止したり、ネットワークが輻輳したりするため、全サーバへの展開が非常に難しい。 従来通り、人手での管理が継続中。
・どこに何があるか全容がしれない。また脆弱性が実際の環境に刺さるのかどうか、判断がつかない
・アセットの特定ができておらず、ピンポイントでの通知が難しい
・データとしての管理が各Excelに散らばっていて不便
・manual work to mitigate discovered vulnerabilities
・実環境にどこまで影響があるかを調べるのに時間がかかる。その後対応に更に時間がかかる
・システム台帳の未整理(対象の網羅性の不安)、対処期間の妥当性の確認
・診断ツールが検出する脆弱性が、実際の攻撃として刺さるかどうかの判断が難しい
・基本的に自分が脆弱性管理回す形になっているので、複数人でできるようにしていきたい
・脆弱性があるライブラリを使用していることが判明したとき、実際に影響があるかどうかを判断するのが難しいこと（一般的な技術知識に加えてプロダクトの詳細を把握している必要があるため）
・部署内管理で全体として統制されてないと感じる
・CVSSスコアが高い危険な脆弱性を検知して開発チームに知らせても対処してくれない（忙しい、自分ごとになっていない様子がある）
・テスト自動化ができておらず、人力対応となるため、対応に時間がかかる
・人は必ず入れ替わるので、セキュリティを深く理解していない人が入ったときに、手順化できないノウハウ（特にトリアージ）、リスクの勘所の高度な部分をどう理解させるか。
・人材不足のため、セキュリティ担当者に任せきりになっていて心配である。
・vulsで検知された脆弱性の攻撃が、どのような攻撃かを知るのに知識がいる点。
・顧客影響を鑑みると、パッチ適用せず、wafでの防御に頼っている
・ベンダーによって、影響バージョンの記載が、統一されていないので、機械的に処理できない。
・数が多い、適用までの管理者へのフォロー
・知識が足りない
・脆弱性について知見がない
・スキルのある人員が非常に少ないため手が回らない
・対処・日程調整（保守ベンダー、セキュリティベンダー）
・情報やワーキングがあちこちにあって、情報収集の範囲が広がる一方
・対象とする脆弱性が、システム内で機能として使われているのかわからない場合がある。またどのような攻撃がされるのか詳細がなく対象とすべきかわからない場合がある。
・脆弱性検証に必要な知識、技術不足
・パッチをあてることができるかという部分でブレーキがかかります
・ツールでの検出件数が多く、その優先度付け
・台帳管理が不十分であり、対象の洗い出しに時間を要する
・人員が増えても、その人がセキュリティに精通してない場合、育成に時間と手間がかかりすぎる。
・優先順位付けのプロセスが属人化している，修正・軽減措置の実施が期限内に実施されない
・現在ツールを使わずに管理しているが、やはりサーバ/利用ソフトウェアなどの漏れが出る。またどの脆弱性情報を周知しどれをしないかの取捨選択にリソースが必要
・影響の範囲。影響の判断。更新時期の調整
・・脆弱性管理対象が不十分なこと（工数の面から対象をかなり絞って対応しています） ・対象を絞っても、検出される脆弱性が膨大なこと ・対処結果の管理工数（CVSSのスコアやそもそもの脆弱性管理対象を絞っても、かなりの脆弱性が毎日検出され、それに対して対処要/不要の判断を記録するだけでも工数がかかります）
・脆弱性管理に取り組めていないため取り組みにあたっての始め方、運用の仕方、人材確保等
・発見した後の脆弱性修正対応の進捗管理や担当部門への依頼。パッチが当てられない古いOSのサーバをどうするか。
・今まで塩漬け前提だったので、パッチ適用のコストが出ない（IT部門のコストカット要請によるもの）
・トリアージの方法、判断基準が統一されておらず、判断が俗人化している。
・ほぼ一人で管理を行っており、ほとんど運用が回せていない。
・脆弱性の有無をスキャンするツールが高額
・通常運用を最低限の人数で捌いており、緊急対応必要時の影響が大きい
・どうしても性質上後手に回り、判断から顧客説明、工数見積もりに日程調整 人的リソースを割りあてから作業実施となる。 他の案件が忙しい時に一連の割り込みが発生するのが悩みです。
・脆弱性管理のための資産一覧、資産の重要度が決められていないこと。知識・経験不足の社員が多いこと。
・脆弱性対応するのにもコストが発生するため、優先順位付けルールを定めているが思ったより脆弱性解消が進まない。また、脆弱性対応後のアプリリグレッションをどこまでやればよいか聞かれるが正確な解がない。ツールで構成管理ベースのスキャンを採用しているが脆弱性がかなり出てしまい解消してもまた脆弱性が出るの繰り返しになっていて疲弊している。
・どうしても目的が先になってしまい脆弱性に関しては後回しになる。
・完璧に対応しても評価されることがなく、何か起これば責任を負わされる損な役割であるため誰もやりたがらない。システムを導入することで従来よりも現実的に運用できるようになったと思うが、せっかく定量的な基準で対処する脆弱性を区分けする手順を構築しても、万が一対処しなかった低リスク脆弱性で被害が発生したらどうするつもりかとなじられたり、それではどのようなリスク受容基準にするかと聞いても一切回答しない（できない）無責任な管理職がおり、どれだけ真剣に取り組んでも有事の際にはトカゲのしっぽにされるに決まっていると皆が感じている。その結果、無理に脆弱性対応にアサインすると退職されてしまう。
・脆弱性があった場合、どのタイミングでどの機器にいつ適用するか、の判断がつかない

上記をChatGPTに整理してもらいました。

項番 カテゴリ 主な悩み・課題（要約） 件数（代表的意見の数）
1 パッチ・適用判断の困難 ・パッチの影響範囲調査が難しい／事前検証環境がない／当てられない
・パッチの適用可否で判断がブレーキになる
・古いOSでパッチが当てられない
・パッチ適用コストが出ない
・どのタイミングでどの機器に適用するか判断が困難		 5
2 資産・台帳管理の不備 ・資産の特定・全容把握ができていない
・台帳がExcel等に分散している
・台帳管理が不十分で対象洗い出しに時間がかかる
・資産一覧や重要度が決まっていない		 4
3 トリアージ・優先順位づけの困難 ・脆弱性の影響判断が困難（環境依存・プロダクト依存）
・CVSSスコア高くても開発が対応しない
・ツール検出件数が多く優先順位がつけられない
・トリアージ判断が属人化・標準化されていない		 4
4 組織・人材・体制の課題 ・対応が一人に集中していて属人化／体制がない
・セキュリティ人材が不足している／知識がない
・育成に時間がかかる
・担当に割り振っても対応してもらえない
・運用が回らない
・損な役割で誰もやりたがらない／担当すると辞める		 6
5 工数・時間・コストの負担 ・調査・対応に時間がかかる
・ツールや対応にコストが発生する
・日程調整や関係者の調整負担が大きい
・構成管理ツールで脆弱性が多く出て疲弊している		 4
6 情報・知識不足 ・脆弱性の攻撃内容を知るのに知識が必要
・判断・対応に必要な技術が足りない
・脆弱性について知見がない／理解できない
・どのような攻撃か詳細が得られない		 4
7 ツール・運用上の課題 ・ツールスキャンでネットワークやシステム影響が出る
・自動化されておらず人力対応
・検出された脆弱性の管理工数が膨大
・高額なスキャンツール
・運用が後回しにされる
・手順化されておらず引き継ぎ困難		 6
8 組織的コミュニケーション・統制不足 ・部署内で統制がとれていない
・情報があちこちに散らばっている
・脆弱性の発信や依頼のワークフローが煩雑
・組織全体で目的が明確でない		 4
9 経営・管理層の理解不足・責任回避 ・管理職がパッチ対応に協力しない
・定量的基準を無視してリスク責任を現場に押し付ける
・リスク受容のルールが決まらず対応が止まる
・有事の際に責任を押し付けられるという不安		 4
10 脆弱性管理の導入・初動の困難 ・取り組み自体が始められていない
・運用の仕方・人材確保の方法が不明		 2

3.3 脆弱性管理を誰がやるべきか

・脆弱性管理を誰がやるか、これが一つのポイントです。
・WEST-SECでアンケートを取得した結果が以下です。

1位：情シス部門など、システム全体を統括する部署　34.2%
2位：システム主管など、システムを運用している部署　25%
3位：セキュリティの専門部署　22.5%

・全社的なガバナンスを働かせる場合、上記の1位でもある情報システム部などが統括的にやることが増えてくるでしょう。ただ、どこまで関与するかも大事です。統括する部署は、経営層に報告するためであったり、自分たちの組織に責任が無いようにするためにという心理も少なからず働き、管理が厳しくなりがちです。

3.4 管理のためだけの負荷が高い

・システムを主管する人と、管理する情報システム部の両方において、脆弱性管理に莫大な時間がかかっている。そのリソースを減らしたい
・具体的な負荷は、「2.3 脆弱性管理（狭義）の流れ」で書いた、資産の管理、脆弱性情報の収集、リスク評価、脆弱性情報の配信、そして対処、また、それぞれの脆弱性に対して、該当するか、対処したかの報告まで求めると、その管理負荷は大きなものになります。
・脆弱性管理には専門的な知識が必要だが、そんな人材がいない。だから、ベンダに確認したり、わからないなりに調べたり、本当に大変。

3.5 どこまでを管理対象にするか

・脆弱性管理の管理対象を広げ過ぎると、さらに負荷がかかります。
・ただ、組織内で「どこまでやる？」という議論になったら、「全部が対象だよね」という結論に陥りがちです。組織内でリスクアセスメントをした上で本当に必要な管理なのかを判断したほうがいいでしょう。そうしないと、管理負荷がどんどん増えます。
・以下、WEST-SECでのアンケート結果です。

4.脆弱性情報の収集および配信

4.1 収集および配信に関する悩み

・どうやって収集するか
・それを各組織（システム主管）に配信をします。※組織によってやらない場合もあり。
・以下は配信に関するアンケート結果


青と赤の違いですが、青は「システムの状況を把握していない」、赤は「システムの状況を把握している」の違いです。青が圧倒的に多いということは、無駄な配信が多くなっている可能性があります

・それが自社にとって重大かどうかの判断はどうやってやるのか。判断をしないと配信できない。
・配信した結果、それが適合しているか、対処をしたのかの報告を求める場合もあり、その負荷は大きい。
・以下、WEST-SECでのアンケート結果です。

・検出される脆弱性情報が多く、適用が必要かどうか精査が必要なこと
・配信する側として、取捨選択やどこまで強く周知するかが難しい
・受け取り側のスキルレベル。脆弱性に関する知識理解がないと対応いただけないことがある。
・資産の把握、優先度の決定
・発信しても、理解する方がいない。
・level of confidence
・Teamsを用いて発信・依頼しており、都度対象のユーザー・サーバの抽出や依頼内容を作成する必要がある
・偉い人が配信を元に説明を求めた場合、説明資料を作る必要がある
・アセットの全てが特定できてない
・内容を読み解ける人が限られている
・費用対効果となって、問題が起きてからになってしまう。
・人員が不足していて属人化、かつ回しきれていない
・理解してもらえない
・配信範囲がグループ全体に及ぶので手段に困る
・情報配信の内容にはそんなに困っておらず、それを受けた後の判断、対処に困っている。どのような定量的基準で仕分けしても、万が一低レベル脆弱性で被害が出たらどう責任を取るのかと仮定の話により何もできなくなったり、パッチをあてるテストのためにシステムを落とすことを認めない管理職がおり、皆で責任を押し付け合う前提がある。
・必要性の認識不足
・配信しても忙しくてすぐ対処してもらえない
・必要に応じてスポットで行うことはあるものの、周囲がそもそも興味がなかったり、必要としていないので、定常的な業務としては残念なが弊社ではやる意味が薄い。
・具体的な情報が得にくいし、具体的に社内アナウンスができない。
・内容を理解できるスキルのある人員が限られている
・帯域の制約や、システム検証の工数などです
・トリアージができておらず、とりあえず投げるだけになっている。知見のあるメーカ製品などであればトリアージして投げてはいるが、全システムに対して実施はできていない。
・システムでは実施せず、担当者による運用で行っている
・正しい情報であるかどうかの判断が難しい
・読み手のレビューを収集出来ていない。一方的

これを、ChatGPTに整理してもらった結果です。

項番 概要 詳細
1 脆弱性情報の多さ・取捨選択の難しさ ・検出される脆弱性が多すぎて、対応が必要かの精査が負担
・取捨選択や周知の強さの判断が難しい
・トリアージができておらず、「とりあえず投げるだけ」になっている
・level of confidence（信頼度）の判断が難しい
・正しい情報かどうかの見極めが困難
2 配信方法・運用上の負担 ・Teamsで配信しているが、対象の選定・依頼文の作成が毎回大変
・配信範囲が広く、手段に悩む（全グループにまたがる等）
・資料を求められると、その都度説明資料を作る必要がある
・読み手のレビューを収集できておらず、一方通行
3 受け手のスキル・意識の不足 ・スキル不足により、脆弱性の内容が理解されず対応されない
・内容を読み解ける人が限られている
・「理解してもらえない」「興味がない」などの意識の壁
・必要性の認識不足
・情報を出しても忙しくて対応されない
4 対応体制・資産管理の課題 ・資産の全把握ができていないため、影響範囲の特定が困難
・対応が属人化しており、人手が足りない
・定常業務として組み込まれておらず、継続的運用が難しい
・システム検証やテストに工数・帯域制限がある
5 組織的・心理的なハードル ・「費用対効果」で後回しにされることが多い
・被害リスクが低い脆弱性でも責任回避のため放置できない空気
・管理職がシステム停止を認めないなど、組織的な障壁

4.2 脆弱性情報の収集先

(1)日本の機関・サイト
サイト名 概要 URL
IPA（独立行政法人 情報処理推進機構） 脆弱性対策情報データベース（JVN iPedia）を運営。 https://www.ipa.go.jp/security/vuln/index.html
JVN（Japan Vulnerability Notes） JPCERT/CCとIPAが共同運営。CVE情報を含む国内外の脆弱性情報を公開 https://jvn.jp/
JPCERT/CC（Japan Computer Emergency Response Team Coordination Center） 脆弱性関連の注意喚起や対応情報、JVNと連携 https://www.jpcert.or.jp/
(2)海外の機関・サイト
サイト名 概要 URL
NVD（National Vulnerability Database） アメリカNISTが運営する公式データベース。CVEとCVSSスコア、詳細分析を含む。 https://nvd.nist.gov/
MITRE CVE CVE番号の割り当て元。CVE一覧と簡易説明を掲載。 https://cve.mitre.org/
Exploit Database Offensive Securityが運営。CVEに関連するPoC（攻撃コード）も多数掲載。 https://www.exploit-db.com/
(3)脆弱性管理システム

TenableであったりFutureVulsを導入していると、そこで自動で収集できます。資産に応じた脆弱性が収集できます。

(4)その他

X（旧Twitter）、ベンダサイト、ニュース、Security NEXTなど

(5)アンケート結果

WEST-SECでのアンケート結果です。

項番 情報源 件数
1 jpcert 19
2 ベンダからの情報 16
3 ipa 16
4 jvn 15
5 SNS・ブログ等 12
6 ツール・スキャンサービス 9
7 ニュース・Webサイト 7
8 nvd 6
9 kev 6
10 isac 5
11 社内部門・専門部署 5
12 警察、監督官庁等、公的機関 5
13 その他 20件くらい

5.脆弱性管理のやり方

5.1 多くの企業で実施しているIT資産管理のやり方

❶台帳を作るって管理する　※場合によってはExcelでの管理
❷管理するシステムを利用する
❸脆弱性管理のシステムを入れる（TenableやFuture Vulsなど）
❹AWSなどのクラウドサービスのシステムの場合、クラウドサービスで管理する（たとえば、Amazon Inspector）
・WEST-SECでのアンケート結果です。
手動で台帳管理をするのは非常に大変だと思います。


1位：Excelなどを用いた手動の台帳管理　49.3%
2位：資産管理専用のソフトウェアやサービスを利用　22.4%
3位：資産台帳は作成・管理していない　10.4%
4位：自社開発の資産管理システムで管理　6%
5位：AWS等クラウドサービスの機能で管理　6%

・また、「サーバやネットワーク機器などのIPアドレスやOS情報は、どのように収集していますか？」という質問へのアンケート結果は以下です。40.9%が「自己申告・手動入力」であり、これでは運用が大変です。正直、運用は持たないと思います。

5.2 脆弱性管理のスキャナーなぜ入れないのか？

・TenableやFutureVulsなどの脆弱性管理のシステムがあったほうが、リアルタイム性や正確性で格段に優れる。でも、導入している企業は日本の企業で1割もいない気がする。
・以下はアンケート結果です。


ただし、Tenableに関しては、単に脆弱性スキャンのNessusだけを使っている結果が含まれているように感じます

・なぜ導入割合が少ないのか。その理由に関してアンケートを採りました。

・スキャンすらNG
・エージェントをインストールする障壁（テストに時間がかかる、問題ないことの確認に時間がかかる、エージェントが負荷を高める可能性）
※そう思うと、AWS上のインスタンスには、あらかじめスキャンできるツールが入っていたと思う。
・コストが高い（以下、WEST-SECの参加者へのアンケート結果でも、コストがダントツの理由です）

5.3 脆弱性管理のシステムはクラウド上のシステムを含めた統合管理に使える？

・もちろん利用できる。SaaSは対象外で、IaaSとPaaSのシステムが対象
・脆弱性管理のシステムを使うメリット
　1)AWSやAzureなどの個別の脆弱性管理（AWSのInspector）ではなく、Tenableなどはマルチクラウド環境で使える。AWSもAzureもオンプレもすべて一律の基準で管理できる。
　2)SSVCなどの管理しやすい基準が使える
　3)Inspectorなどは、スナップショットへのチェックであるため、やり方が違う。また、管理画面などはTenableやFutureVulsの方が各段に優れ、管理しやすい。管理が難しいと、運用が雑になる。
・ただし、クラウドの場合、脆弱性管理だけでなく、ポスチャマネジメントが必要であり、Tenableの場合は、CSPMの製品を活用する。FutureVulsにおいては、CSPMの部分は他の製品で代替する。
・それ以外には、権限管理（Cloud Infrastructure Entitlement Management：CIEM：ケームと呼ぶ）として、クラウドにおけるアクセス権限を管理するツールがあり、Tenableの場合は「クラウドセキュリティ」の製品になる。

6.脆弱性管理の在り方

6.1 脆弱性への向き合い方

・脆弱性は無限に存在する。ゼロにはならない。また、すべての脆弱性を完璧に対処することは不可能。
・脆弱性がある＝攻撃が成立する、ではない。脆弱性の有り無しで考えるのではなく、リスクベースで考える。※リスク＝情報資産の価値×脆弱性×脅威
・組織において、なにがリスクなのか、どこまでリスクを許容できるのかを決めておく。たとえば、TRACEメソッドの脆弱性を突いて、本来意図していない方法で悪用されることはリスクか。機密情報もない、ユーザ管理もしていないサーバであってもそれがリスクなのか。
・対策に時間がかかる恒久対策が必ずしも優先ではない。対処速度を優先した回避策（ワークアラウンド）も有効
・人間は間違えるし、無駄だと思えば適当に報告するし、忙しければ嘘もつく。人間こそが脆弱性　→ルールやチェックシートでは完璧には守れない。人間に頼らない対策が必要。
・そもそも脆弱性が露呈しないようにする。→脆弱性管理が不要なようにする（後述）。

6.2 そもそも脆弱性が露呈しないようにすべき

たとえば、SSL-VPNの脆弱性があったとして、その脆弱性を管理して適切にパッチをあてるのは大変です。
そもそも、脆弱性が顕在化しないようにしたいところです。
たとえば、
　・送信元IPアドレス制限をして、特定の人からのみしか接続できないようにする
　・（脆弱性は回避できませんが、リスクを減らすために）接続するときだけサーバに接続する
　・内部対策として、SSL-VPN装置が侵入されても、さらにその先のサーバへは接続できないようにする。具体的にはセグメントを分ける、サーバの認証強化など。加えて、ログなどの監視も強化しておくといいかと。

6.3 クラウドによるシステム構築

(1)SaaSサービスの利用

・そもそも、脆弱性管理の必要があるサーバを建てて、ソフトウェアを入れて、アプリケーションを開発するということを止める。SaaSサービスを活用する。

(2)ノーコード、ローコード開発

kintoneなどのクラウドサービスを活用し、ノーコード、またはローコードの開発をする。
以下に概要をまとめています。
https://west-sec.com/entry/lowcode

(3)クラウドサービスの活用

・EC2サーバやコンテナなど脆弱性管理が必要なコンポーネントをできるだけマネージドサービスの奥に配置する。例えばCloudfront、ELBの後ろにEC２やコンテナを配置する。
・レイヤ4までの脆弱性が仮に見つかっても、インターネットからの通信はCloudfrontやELBがいったん終端するので、その奥に配置されたEC2やコンテナへの影響は少ない。
・CloudfrontやELBはマネージドなサービスなので、利用者が何もしなくても勝手に脆弱性対応をしてくれる（本格対処までの時間が稼げる）。
・レイヤ７に関しては、とりあえずWAFをアタッチしておけば、メジャーな攻撃は防いでくれる（もちろん万能ではない）。

(4)サーバーレス

・セキュリティの観点では、ガバメントクラウドが提唱しているように、「可能な限りクラウドサービスをネイティブに利用」。EC2上にミドルウェアなどを入れるのではなく、LambdaやマネージドDBなど、クラウドサービスを活用する。
https://guide.gcas.cloud.go.jp/general/overview-explanation-chapter-03/
・LambdaやマネージドDBを使う
https://business.ntt-east.co.jp/content/cloudsolution/column-26.html
・参考までに、AWS Lambdaは、サーバーレスでプログラム実行環境を提供するサービス。開発言語は、Node.js、Java、C#、Pythonに対応している。

余談：CI/CD

・CI（Continuous Integration）、CD（Continuous Delivery）であり、AWSの場合、CodeBuild, CodeDeploy, CodePipelineなど
❶CI（Continuous Integration）
・継続的インテグレーション
・開発者が書いたコードを自動的に統合してテストする仕組み
・例：Gitにプッシュ → 自動でビルド → 単体テストが実行 → 成功したら本番に進める状態になる

❷CD
2つの意味があるが、一般的には両方を含むことが多い

用語 意味 概要
Continuous Delivery 継続的デリバリー 自動でリリース可能な状態にしておく（本番へのリリースは手動）
Continuous Deployment 継続的デプロイ 自動で本番環境までリリース（手動操作なし）

❸CI/CDの利点
何が便利かというと、CI/CDあり（自動化あり）の流れを見るとわかりやすい。
たとえば、開発者がコードを変更してプッシュすると、CI/CDツール（例：GitHub Actions, Jenkins, GitLab CIなど）が以下を自動でやってくれる。数分後に、最新のアプリが本番環境に反映されるので、とても便利
・自動ビルド
・自動テスト
・自動デプロイ

6.4 脆弱性管理をするのであれば人に頼らない運用にする

(1)クラウドを活用した脆弱性管理

農水省では、ガバクラを独自開発し、MAFFクラウドを運用しています。
仕組みについては以下に公開されています。
https://japan.zdnet.com/article/35203354/
参考：https://pages.awscloud.com/rs/112-TZM-766/images/CUS-16_AWS-Summit-2023_Digital-MAFF_FINAL_2.pdf

上記に記載がありますが、MAFFクラウドの場合、以下の4つを利用しているとあります。

機能 概要
1 AWS Direct Connect 専用線接続
2 Amazon GuardDuty 不正アクセスや悪意のある挙動を検出
3 AWS Config ルートユーザのMFAが無効になっている。ポートが全て空いているなどチェック、変更のログの取得
4 AWS Security HUB Configによる各リソースの診断結果をまとめ、全体として準拠性を満たしているかのチェック

この仕組みがなぜ有用なのか。それは、脆弱性管理の課題をかなり克服できるからです。

現状の問題点 クラウド活用の効果
・システムやセキュリティを全く理解していない現場（営業部、広報部など）の責任者がセキュリティの責任を担う
・最もセキュリティに詳しい情報セキュリティ部は責任を取らず、現場にセキュリティ対策を一任
・情報セキュリティ部が、チェックシートや毎月報告、監査など、厳しく現場を管理し、情報セキュリティ部と現場の双方で負担が多い。
・チェックシートや監査などでは、実態を正しく把握できない。特にチェックシートでは嘘が書かれる可能性がある。
・対策の実行性、リアルタイム性が無い。		 ・AWSの高度なセキュリティ機能を利用できる。
・一元的なセキュリティ管理が可能。
・セキュリティ不備や攻撃があれば、リアルタイムでアラートを受け取ることができる。
・現場にチェックシートなどを求めたり、脆弱性情報を配信して、対処報告を求めるなどは不要で、情報セキュリティ部が自らAWSの権限でチェック可能。
・セキュリティ機能が非常に低コストで実現できる。
(2)SSVCなどの管理指標を使った上で脆弱性管理システムの活用

・まず、CVSSだけで管理して、システムの状況や資産の状況（データの重要度）を管理していないようでは、管理が大変になる。SSVCなどの重要度などを含めた指標で管理すべき
・加えて、TenableやFutureVulsなどを活用し、手作業や人による報告ベースではなく、システム的な管理をしましょう。正確性の向上および稼働の削減になります。
・しかし、実際の導入は簡単ではなく、サーバの台数にもよるが数か月はかかることを覚悟した方がいいでしょう。たとえば、エージェントを入れてサーバに負荷をかけないか、正常に動作するかのテストも必要ですから。また、脆弱性管理のシステムを入れると運用は劇的に楽になります。ですが、脆弱性が露呈するかであったり、その緊急度や優先度の最終判断はエンジニアがする必要があります。すべてをツールに任せることができません。

7.SBOMについて

・SBOM（Software Bill of Materials：ソフトウェア部品表）は、フルスペルにあるように、システムや製品のソフトウェアの部品を一覧化したリストです。
現在のシステムというのは、オープンソースのソフトウェアも含め、複数のソフトウェアの部品で構成されています。そして、その中の一つの部品に脆弱性があっても、サーバが乗っ取られるなどの重大な被害につながることもあります。昨今、SBOMによる管理の重要性が高まっています。
しかし、どこまで運用ができるかというと、また別の話です。
・Tenableは、基本的にSBOMに未対応です。その他の脆弱性管理のシステムも、対応していると公言しているところがあるとはいえ、かなり限定的です。※正直、おまけだと思います。
・じゃあ、log4jなどの、モジュールに含まれる脆弱性が管理できないかというと、そうではない。たとえば、Tenableの脆弱性スキャンでも、log4jなどもモジュールもしっかりと見ている。

（出典：https://jp.tenable.com/plugins/search?q=log4j+AND+language_code%3A%28en_US+OR+ja_JP%29&sort=&page=1）
・なので、SBOMによる管理というのは必要性はあるかもしれないが、実際にやっているところは少なく、しかも、別にSBOMを切り出して管理しなくてもいいという考えもあるでしょう。

8.Nessusによる脆弱性診断

8.1 脆弱性スキャンとしてのNessus

・プラットフォーム診断ツールと考えればいい。
・可視化対象は、サーバ、クラウド上の資産、コンテナ、ネットワーク機器、IoT機器も
・日本語対応
・パッシブスキャナーへの対応（負荷をかけない）
・Vulnerability Priority Rating (VPR) による、リスク・深刻度ベースでの管理。
・VPRとTenableによる深刻度の対応

深刻度 VPR
重大 9.0 ~ 10.0
高 7.0 ~ 8.9
中 4.0 ~ 6.9
低 0.1 ~ 3.9

・対応OSは、Windows、Linux、MacOS

8.2 スキャンに関して

(1)概要

・スキャンあたりのIPアドレスが最大16ではあるが、無料で診断に利用できる。
https://jp.tenable.com/products/nessus/nessus-essentials
・NW機器の場合、クレデンシャルスキャン（SSHで接続）
・サーバで制約が無い場合、エージェントを入れたくないところは、クレデンシャル（SSH）になる。
・エージェントの場合は、変更があった場合、リアルタイムで管理サーバに通知できる（Linuxが2024年に実装、Windowsは今後予定）

(2)スキャン方式

それぞれメリットやデメリットがある。

スキャナ 名称 スキャン方式 設置場所 メリット等
NessusScanner ノンクレデンシャルスキャン ネットワーク越しに外部からスキャンを実施 ネットワーク上にスキャナーを設置 エージェントをインストールする必要が無い
　　〃　　　 クレデンシャルスキャン 　〃　 　〃　 詳細なスキャンができるが、SSHのアカウントをスキャナに入れるし、SSH接続を許可する必要があり、セキュリティ面の懸念あり
NessusAgent エージェントスキャン 対象端末にエージェントを入れてスキャン スキャン対象端末にインストール 詳細なスキャンができる。
スキャナからの通信を許可する必要が無い
NetworkMonitor スニファー ネットワークを流れるトラフィックを監視 監視対象のスイッチ 　

※Tenable社の場合、NonCredentialスキャンが一番多いであろう。一部、Credentialスキャンも使われています。

(3)実際の運用の想定

たとえば、50台のサーバがあって、システム管理者が10人いて、一人5台のサーバを運用しているとして、統合管理は管理コンソールを使う。結果を見れるのは、自分のサーバだけにする。情報システム部は全部見ることができるかもしれない。方法としては、たとえば以下になる。
❶50のサーバにそれぞれエージェントを入れて、管理コンソールで管理
❷10人の管理者のPC（またはどこかのサーバやVM上）にスキャナーを入れて、毎日１回チェックをして、その結果を管理コンソールで管理
※エージェントを入れる場合と、スキャナーでスキャンする場合の両方を混在させてもいい。
また、設定 > アクセス制御　において、タグ等を使って、自分のサーバの情報しか見えないような設定も可能。

8.3 実際の設定

(1)インストール

・上記にて、名前やメールアドレスを入力
・Nessusをインストールするが、Windows10のPC、Windows Server(x86_64)、MACやLinuxなどのOSを選ぶことができる。
・ダウンロードしたファイルを実行。基本的には「次へ」で進む。
・ブラウザの画面が開くので、SSLで接続。おそらく以下のURL
https://localhost:8834/#/
・「Registar for Nessus Essential」を選択してContinue。次の画面はSkipしてActivation Codeを入れる
・username とパスワードを作成してsubmit
・ここから少し時間がかかる（1時間～2時間は覚悟した方がいいかも）
　右上の円形の矢印がグルグル回っているとすると、そこにカーソルを合わせると、進捗がわかる

(2)テストスキャン

インストールが無事に終わると、最初のテストスキャンするサーバを入力する画面がでる。
ここでIPアドレスを入れる。このIPも16IP制限にカウントされる。
基本的にはプラットフォーム診断を実施してくれる。
→画面は非常に見やすい。

(3)Credential Scan

外部から診断をするのは、Webサーバのバナーであったり、レスポンスを見て、OSやミドルウェアの情報を取得する。それだと限界があったり、正確な情報がわかるとは限らない。それよりは、サーバにログインし、コマンドを打つことで、OSの正確なソフトウェアの状況がわかる。場合によっては、パッチの適用状況もわかる。
そのためには、Credential Scanとして、SSHでログインをさせる。そのために、NessusにログインID/Passwordを渡す。

9.脆弱性管理のシステム (1)Tenable

9.1 Tenableの製品概要

・製品としては、いくつかのラインナップがある。

・Tenable Oneのログイン後の画面は以下であり、メニューがたくさんあることがわかってもらえるであろう。

・この中で、脆弱性管理の製品としては、Tenable Vulnerability managementが該当する。
・サイバーエクスポージャー管理で、脆弱性管理だけでなく、ID管理なども1つのプラットフォームで統合管理

9.2 脆弱性管理としてのTenable Vulnerability management

・脆弱性管理の市場評価ではTenableがNo.1であろう。以下のIDCのレポートを見ると、WorldWideのシェアが、28.7%で1位である。次はRapid7
https://jp.tenable.com/blog/idc-ranks-tenable-no-1-in-worldwide-device-vulnerability-management-market-share-for-the-fifth
・Tenable社の人はVM（ブイエム）って呼ぶ
・以前はTenable.ioと呼ばれていた。
・Tenable Oneのメニューの一つで、クラウドでスキャン結果を管理したり、資産の管理をしたり、クラウドからインターネット越しにスキャンすることもできる。
・Nessusでスキャンした結果を管理することができる。
・評価版を利用できる。Nessusそのものはダウンロードして、それをクラウドの管理コンソールと連携もできる。
https://jp.tenable.com/try
・基本的には管理部分（コントロール部分）はクラウドだが、オンプレでも構築可能である。
・CSPMを実施するには、別製品を使う。ベンチマーク指標に即しているかなどはCSPMでやる必要がある。

9.3 構成

8.2(2)でも解説しましたが、ここにあるように、サーバをスキャンする方法は、❶Scannerを使ったスキャン（ローカルとクラウド）、❷（サーバに入れた）エージェントによるスキャン、❸スニファによるネットワークトラフィックのスキャンの3つがある。

9.4 クラウドスキャナー

・Tenable Vulnerability managementでは、クラウド上にスキャナーがあると思ってもらえばよく、クラウドから一斉にスキャンが可能
・クラウドスキャナは送信元IPアドレスを公開しているので、FW等でそのIPからの通信を許可する。Tenableのサイトに公開されている
・クラウドスキャンをするのは、インターネットに公開しているサーバに限定されるのが現実的。また、セキュリティの観点でクレデンシャルスキャンは推奨していない。
・設定に関して、管理コンソールで発行したアクセスキーをサーバにも入れる。これで、違う管理コンソールと通信しないようにする。

9.5 価格について

・ライセンス的には、スキャンの対象が何台であるか。※このあたりはNessusとは少しライセンスの考え方が異なる。
・VMで使う場合、どのスキャン方法を選ぼうが、仮にスキャナーを複数台導入しようが、料金的には関係ない。

9.6 運用について

発見した脆弱性をどう対処するか。
その脆弱性が危険かどうかの判断が難しいが、情報システム部門で判断する場合もあれば、実際の改修はシステムの構築ベンダなので、構築ベンダに確認してもらうことも多いだろう。

10.Vulnerability Managementの設定

10.1 ユーザ登録やログイン

・Tenableのクラウドのログイン
https://cloud.tenable.com/tio/app.html#/login

・ログイン後の画面
・ここで、Vulnerability managementを選択

・または、右上の9つのブロックのボタンからVulnerability managementを選択

10.2 メニューと初期設定

(1)メニュー画面

左上のハンバーガーボタンを押すと、全体のメニュー構成が見やすい

(2)言語設定

・ユーザインターフェースの日本語化

・出力結果の日本語化はこちら

(3)ダッシュボード


10.3 スキャン

(1)基本的なスキャン

❶スキャンのメニューから「スキャンの作成」

❷「基本的なネットワークスキャン」を選択
❸スキャンの設定画面
・スキャナーをどれを使うか。今回はクラウドを使い、しかもAP tokyo cloud Scannerを選ぶ。もちろん機能に差はなく、普通は場所が近いところを選ぶであろう。

・IPアドレスを入れる→IPアドレスレンジまたはホスト（ドメインでもOK）で入れるとサーバを探してくれる。
・スキャンの設定で「検出」で、検査するポートを選ぶことができる。

・スケジュールすることも可能。→毎日とか毎週とかも可能
・ここまでは、NoneCredentialの場合
❹実行。10分くらいはかかる。

(2)Credential Scan

・認証情報を入れると、Credential Scan
・やり方は同じ。最後に、認証情報のメニューから、「認証情報の追加」を押す。

・認証情報を入れる。AWSではec2-userでログインし、sudo -i　を実施していたので、sudoを選び、パスワードなどは空欄のままで実行した。

Q.認証が成功したかはわかる？
A.プラグインでわかる。認証が成功したかをチェックするプラグインがあり、スキャンの履歴で、以下のように表示される。

(3)エージェントスキャン

・エージェントスキャンをするときは、メニューもエージェントスキャンを選ぶ。具体的には、スキャンテンプレートの選択にて、「NessusAgent」のタブを選び、「基本的なエージェントスキャン」からスキャン

・ここで、ターゲットにエージェントグループを選ぶことができる。エージェント単体ではターゲットに選定できず、1台のホストでも必ずエージェントグループを作る必要がある。
・スキャナなどは以下からダウンロードは可能

ただし、ユーザー登録が必要です
https://www.tenable.com/downloads?loginAttempted=true
・ユーザ登録
https://connect.tenable.com/c/welcome/page

(4)スキャンテンプレート

・スキャン　>スキャン作成　を押すと、スキャンのテンプレートを選ぶことができる。

・どれを選んでも同じような内容に見えるが、微妙に違ったりする。たとえば、「高度なネットワークスキャン」の場合、一から自分で組み合わせて作ることができる。以下のように、メニューにプラグインやコンプライアンスが選べる。

・「ホスト検出」は、脆弱性の検査はせず、ホストの探索だけを実施する。

(5)Web App Scanning

Webアプリケーションのスキャンができるが、別途ライセンスが必要。

10.4 検出結果

(1)概要

・検出結果のメニューで表示される。

・出力結果は、CVEベースじゃなく、プラグインごとに結果を出す。一つのプラグインの脆弱性に複数のCVEが絡んでいる場合があるため。
・こちらは資産別

・脆弱性情報は、以下のようにVPRベースで表示される。もちろん、下の方にCVSSなどの情報もある。

(2)NonCredentialとCredentialの差

・同じサーバに対して、NonCredentialとCredentialでは結果が大きく違う。
❶NonCredential
外（＝攻撃者）から見ると、どれだけ脆弱性があるかがわかる。以下のように29件の脆弱性が発見された。

❷Credential Scan
こちらは、実際に乗っ取られ、資格情報を取られると、どれだけ脆弱性があるかがわかる。以下のように179件の脆弱性が発見された。

(3)レポート作成

脆弱性を選び、「レポートを生成」ボタンを押すと、右にメニューが出てくる。そこで、テンプレートを選んでレポートを作成する。

10.5 資産

・「資産」のメニューで、スキャンをした資産の情報を一覧で管理できる。

・資産の詳細情報や、使用しているソフトウエア、脆弱性情報も確認できる。

Q.自分で資産を登録することはできる？
A.スキャンが必須。※ホスト検出でもOK

Q.空いているポートがわかる？

A.はい。資産のメニューで、対象のサーバをダブルクリックで選択。右にある「すべての詳細の表示」をクリック。タブでオープンポートでわかる。これも、Credentialスキャンをした方が、見つけるポートが多い。ただ、netstatで動いているポートも見つけてくるだろうが、それが外から見えるかは別問題。

10.6 センサー

(1)センサーの一覧

・センサーの一覧が表示される。

(2)センサーの登録

・右上の「Nessus Scannerの追加」から、センサーを登録することができる。

・リンクキーをコピーして、それをスキャナーに登録する。スキャナー側では、「リンクして使う」を選び、リンクキーを入れる
これにより、センサーとスキャナーでの認証を行うことができる。認証していないセンサーに情報を送らないし、正しくないスキャナーを登録しない。

(3)エージェントグループ

・エージェントグループは、アカウントにリンクエージェントの整理と管理に使うもので、エージェントは複数のグループに属することができます。

・エージェントグループはスキャンのターゲットに設定できます。つまり、一つひとつにターゲット設定をする必要がなく、エージェントグループにまとめて設定ができる。スキャンテンプレートの選択にて、「NessusAgent」のタブを選び、「基本的なエージェントスキャン」からスキャンをすると、ターゲットにエージェントグループを選ぶことができる。

10.7 Vulnerability Intelligence

・メニューからVulnerability Intelligenceを選択する。

・一番上に「脆弱性データベースを検索する」とあり、CVE番号であったり、自由記述でも検索できる。
・真ん中あたりに脅威情報が掲載される。
・タブの切り替えで、「CVE」、「マイ検出結果」、「影響を受けるマイ資産」、を選べる。

・脆弱性をクリックすると、時系列で脆弱性を見たり、VPRやCVSSのスコア以外にEPSSのスコアも確認できる。

・「影響を受けるマイ資産」を選ぶと、今、管理している資産において影響を受ける脆弱性が表示されるので便利

10.8 エクスポージャ対応

日本ではあまり使われていないが、自分が注目している資産の対応状況などを把握する。

【参考】エクスポージャ管理
エクスポージャ（Exposure）は、「露出、さらされること」という意味です。つまり、「外部にさらされているリスク（＝エクスポージャ）を把握し、管理すること」がエクスポージャ管理と言えるでしょう
セキュリティベンダがこの言葉を使うときは、組織が保有するIT資産が、どんなリスクにさらされているかを可視化し、優先順位をつけて対処するプロセスを指すことでしょう。

10.9 調査

これは、検出結果と資産の次世代のUIで、両方を統合されたもの。

10.10 レポート

・レポートメニューは以下であり、非常に詳細なレポートが出せるが、検出結果であれば「検出結果」からレポートを作成するのがわかりやすい。

・右上の「新しいレポートを作成」ボタンを押すと、以下のようなレポートのテンプレートが選べる。

・レポートテンプレートが選べる。

10.11 設定

各種の設定が行える。

・大メニューは
　1)アカウントの管理
　2)ルール
　3)・スキャン
　4)統合
・たとえば、アカウントの管理では、以下が設定可能

メニュー 内容
一般 一般設定を表示および管理します。
SAML SAML セルフサービス
ライセンス Tenable Vulnerability Management のライセンスの詳細と統計を表示します。
アクセス制御 ホストのスキャン、およびスキャン結果と集計データの表示を行えるホストユーザーを表示および管理します
アクティビティログ 所属組織の Tenable Vulnerability Management アカウントで発生しているアクティビティログイベントを表示します
言語 言語設定を表示および管理します。
エクスポート エクスポートアクティビティを表示し、スケジュールされたエクスポートを管理します
ダッシュボード ダッシュボードを表示および管理し、ウィジェットをカスタマイズします

・アクセス制御は、ユーザの詳細な管理ができて、たとえば二要素認証の設定や、権限やグループの設定などができる。また、資産にタグを付けたり、アクセス管理でタグ単位で許可を与えるなどができる。たとえば、システム管理者が10人いて、それぞれ5台のシステムを主管している。統合管理はVMでする場合、他の管理者に自分のサーバが見えないようにしたいであろう。そういった管理は、ユーザ単位で対象サーバを限定できたり、タグ付けをしてタグで管理するなどができる。

11. FutureVuls

11.1 概要

・フューチャー株式会社という純粋な日本企業
https://www.future.co.jp/company_profile/corporate_profile/#tab-1
・費用は1サーバあたり、1か月4000円。１年で48,000円
https://vuls.biz/price/
・ASMの機能に関して、外部のスキャン結果を取り組む機能がある。FutureVuls自体は、CrowdStrikeのFalcon ASMみたいに、世界中の資産を集めているわけではない。
・国産企業なので、日本の機器（YAMAHA）などはFutureVulsが優れているであろう。
・CSPMの機能はないので、クラウドの機能やサードパーティーの製品と役割分担することになる。
・Vulsでも脆弱性に関する対処策として、コマンドまで提示してくれる。しかも日本語対応だからありがたい。

11.2 スキャン方法

(1)FutureVulsのスキャン方法

https://help.vuls.biz/manual/scan/

(2)スキャンの詳細

・エージェント（スキャナー）を入れるか、SSHログインでチェックをする。
・スキャナーが一番多い（アプリをインストールではなく、バイナリファイルをおいて、Cronなどで定期実行）。SSHスキャンは実際はないだろう。
・NW機器の場合は、スキャナーサーバ経由でSNMPで取得

(3)エージェントスキャンについて

・FutureVuls で構成情報を取得する主体（スキャナ）のことを「エージェント」と呼ぶが、インストールするタイプではありません。このスキャナの実態は Go 言語でビルドされた バイナリファイル です（サイズは200MB 程度）。常に起動してサーバに負荷を与えかねない常駐プロセスのようなものではなく、FutureVuls ではこのバイナリファイルを定期実行しているにすぎず、サーバ等への負荷もそれほど大きくなりません。
・詳細はこちらに記載があります。

Q.エージェントを入れることはハードルにならないのか？

A.FutureVulsさんや導入された企業さんの話だと、単にファイルを置いて実行するだけなので、ほとんどトラブらなかったとのこと。
それより、インターネットにUploadする必要があり、インターネットへリーチャブルである必要があるが、そちらの方が抵抗になることはあった。FutureVulsの場合、非同期でも可能ではあるが、一手間が必要。

11.3 管理コンソール

・データはクラウドで管理されるのでサーバは不要。
Q.資産重要度って何を入れる？
A.重要度を4段階（low, medium, high, very high)で設定できる。
個人情報が入っているものはhigh、個人情報が1万件以上はvery highとかにしてもいいだろう。
または、インベントリ情報の管理で、タグで顧客情報が入っているかを入れてもいい。
https://vuls.biz/blog/articles/20240409a/

11.5 閉域ネットワークの情報資産の管理

・閉域ネットワーク（=インターネットにつながっていない）での情報資産の脆弱性管理は難しい。
・FutureVulsでしかできないとのこと（要確認）。
・とはいえ、クラウドにある管理ツールに対して、直接情報を送ることはできない。手を介してつなぐ。
・具体的には、SSHでログインして、すでに作成されたシェルか何かを実行することでサーバの情報を取得して、その結果を、インターネットにつながる環境にてUPloadする。

11.7 SBOMに関してはできることが2つ

・SBOMを生成するツール（Vuls Trivy Syft SBOM Toolなど5つほど）あり、それをインポートする。
・エクスポート機能もある。
　※よくわかっていない。

11.8 電通総研さんのテックブログ

以下に、SSVCを使ったり、FutureVulsを活用した具体的な脆弱性管理について述べられている。実際に利用されている話であり、大変参考になります。
https://tech.dentsusoken.com/entry/ssvc-risk-assessment

まとめとして、以下の記載があります。

脆弱性対応において、IPAが提唱する0次評価・1次評価を導入することで運用負荷を削減し、FutureVulsのようなツールがある場合には2次評価のみで完結するため、より効率化できると言えます。

とはいえ、「IPAが提唱する0次評価・1次評価を導入」するのも運用負荷がかかるので、後半に記載がある通り、FutureVulsのようなツールを導入するのが、正確性、スピード、運用負荷軽減の観点からベストと言えるでしょう。

12.Future Vulsの設定

12.1 ログイン

ログインURL
https://console.vuls.biz

・所属情報　>　グループ　から該当のグループを押すと、そのグループの脆弱性管理の画面に遷移する

12.2 脆弱性タブ

・「脆弱性」タブを開いたところです。

・脆弱性タブでは、そのグループで見つかった脆弱性の一覧が表示される。
・「列一覧」ボタンで、表示する列を変更できる。

12.2 サーバ・製品タブ

(1)一覧

・こちらでは登録された資産（サーバ）が表示される。

・クリックすると詳細が確認できて、導入されたアプリケーションなどが一覧で確認できる。

(2)資産の追加とスキャン

・スキャナーのインストールの説明が記載されている。
・「＋サーバ追加」ボタンから追加可能。

・以下は、「サーバOSスキャン」を「追加」したところ。

この通りにコマンドを実行すると、結果がこの画面に上がってくる（と思う）

(3)NW機器の追加

NW機器に関しては、スキャナというかエージェントを入れられないので、CPE（Common Platform Enumeration）登録して、NW機器自動で特定して脆弱性管理ができる。

12.3 「タスク」タブ

・タスクで、自分が割り当てられたタスクとステータスなどを確認することができる。
・脆弱性情報のチケット管理もできる。誰がいつまでに対処するかなどのワークフローの管理もできる。

・ステータスの管理として、「関連するタスクを更新」から、誰が担当するかや期限などの管理もできそう。

12.4 「ロール」タブ


12.5 「AWS」タブ

AWSと連携することで、SSM（AWS Systems Manager ※スペルが一致しませんが）を使ったパッケージアップデートや脆弱性スキャンなどを画面上で行えるようになるようです。

13.WEST-SECイベント

13.1 イベント概要

900人ほど集まっていただきました。イベントランキングでも2位になりました。脆弱性管理に対する皆さんの関心の高さがうかがえます。

・640人というたくさんのご参加ありがとうございました。

13.2 アンケート

イベントおよびConnpassのメッセージにて、脆弱性管理に関する以下のアンケートを採りました。
・アンケート１
脆弱性管理に関するアンケート
・アンケート２
脆弱性管理に関するアンケート２
・アンケート結果については、本サイトの該当箇所で掲載しています。
・掲載できなかった内容を記載します。
1)脆弱性管理業務に携わっているか

2)あなたの立場、クラウドの利用状況

13.3 FutureVuls社のブログ

今回のイベントを紹介していただきました。FutureVulsさんの発表資料（前半部分）も掲載されています。
https://vuls.biz/blog/articles/20250522a/