トライコーダは、3つの対策の役割を健康管理になぞらえて説明する。ASM（Attack Surface Management）は、インターネット側から観測できる自社のIT資産を継続的に発見し、「外から見た自分たちの姿」を把握する取り組みだ。継続的な脆弱性管理は、把握した資産にどのような弱点があり、対処状況がどう変化しているかを追う「日々の健康管理」に当たる。そして脆弱性診断は、対象を絞って人の知見も加えながら詳しく調べる「人間ドック」に相当する。

　同社が推奨する順番は「ASM→継続的な脆弱性管理→脆弱性診断」だ。まず外から見える資産を洗い出し、日々の変化を追える状態をつくった上で、重要な対象を詳しく診断する。

　もちろん、脆弱性診断から着手すること自体が無意味なわけではない。ただし、あらかじめ指定した対象を特定の時点でのみ調べるだけでは、診断後に追加されたシステムや、管理部門が存在を知らない資産を捉え続けることは難しい。診断という「点」を、継続管理という「線」と、外部公開資産を捉える「面」の上に置くことで、診断対象を適切に選びやすくなる。

資産台帳の外にある資産を、攻撃者は見ている

　ASMが必要になる背景には、IT資産の増減を1つの資産台帳だけで追うことの難しさがある。事業部門が独自に立ち上げたWebサイトやクラウド環境は、利用を終えた後も外部公開されたまま残ることがある。M&Aで引き継いだネットワーク機器も、管理責任者や更新手順が曖昧なまま稼働し続ける可能性がある。

　社内から見れば「管理対象外」でも、攻撃者はドメイン名やIPアドレス、証明書など外部から得られる情報を手掛かりに資産を探す。忘れられた資産に既知の脆弱性や設定不備が残っていれば、そこが侵入口になる可能性がある。

　エンドポイントにEDR（Endpoint Detection and Response）を導入していても、エージェントを組み込めないVPN装置などのエッジ機器は別に確認する必要がある。MFA（多要素認証）も認証を強化する有効な対策だが、MFA疲労攻撃（利用者に何度も認証承認を求めてうっかり承認させる）やセッショントークンの窃取など、認証を突破または回避する攻撃への備えは残る。

　MFAやEDR／XDRは、脆弱性対策の代わりではない。侵入や不審な挙動を検知して対応する仕組みと、攻撃に利用できる入り口そのものを減らす取り組みを組み合わせる必要がある。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

資産台帳の外にあるシステムも、外部に公開されていれば攻撃者から観測され得る（トライコーダの回答を基に編集部で作成）

「全部高リスク」では優先順位にならない

　資産を把握した後に問題となるのが、増え続ける脆弱性情報をどう処理するかだ。情報システム担当者が他の業務を兼務する中堅・中小企業では、日々公開されるCVE（Common Vulnerabilities and Exposures）を追い、自社への影響を一件ずつ判断する時間を確保しにくい。自社の資産や重要度を正確に把握できていなければ、どの機器にパッチを優先して適用するかも決められない。

　判断材料としては、脆弱性の技術的な深刻度を数値で示すCVSS（Common Vulnerability Scoring System）が広く使われる。しかし、CVSSの基本値が高いという理由だけで、自社で直ちに悪用されるとは限らない。CVSSは脆弱性の深刻度を表す指標であり、自社におけるリスクを単独で示すものではない。

　トライコーダは、CVSSに加えてKEVとEPSSを見ることを挙げる。KEV（Known Exploited Vulnerabilities）は、実際に悪用されたことが確認された脆弱性を集めたカタログだ。EPSS（Exploit Prediction Scoring System）は、公開済みのCVEが今後30日間に実環境で悪用される確率を推定する。既に悪用されているか、近い将来に悪用される可能性がどの程度あるかを加えれば、技術的な深刻度だけで並べるよりも、現実の脅威に沿って対象を絞りやすい。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

KEVやEPSS、外部到達性、重要資産への経路を重ね、先に対処する脆弱性を絞り込む（トライコーダの回答を基に編集部で作成）

　ただし、KEVやEPSSだけでも十分ではない。インターネットから直接到達できるか、認証を回避できるか、遠隔からコードを実行できるか、特権アカウントや重要データへつながる経路上にあるかといった、自社環境の条件を重ねる必要がある。

　先に対処すべき典型例は、外部から直接到達でき、認証回避やリモートコード実行につながり、公開済みの攻撃コードが存在する脆弱性だ。VPN装置やファイル転送製品など、インターネットとの境界に置かれる機器では特に優先度が高くなる。

　一方、内部ネットワークからしか到達できず、悪用に利用者の操作が必要で、ネットワーク分離などの補完的な対策が機能している場合は、相対的に対応時期を後ろへずらせる可能性がある。後回しは放置ではない。判断根拠と対応期限を記録し、状況が変われば優先度を見直すことが前提だ。

「パッチを当てない理由」まで説明できるか

　脆弱性対策サービスの役割は、脆弱性を大量に見つけることだけではない。トライコーダは、脅威情報の洪水から自社環境で確認すべきものを数件に絞り込むことに価値があるとする。

　対応する項目を示すだけでなく、今はパッチを当てないと判断した項目についても、外部から到達できない、補完策が機能している、重要資産への経路がないといった理由を残せれば、判断を説明しやすくなる。現場は、全件に即時対応できないことを単なる人手不足としてではなく、リスクに基づく選択として経営層に示せる。

　経営層への報告も、検出した脆弱性の総数だけでは判断材料になりにくい。「外部から侵入可能だった経路を何件ふさいだか」「重要業務に直結する残課題は何か」「期限までに対応できない対象にはどのような緩和策を講じたか」と示す方が、何が守られ、どのリスクが残っているのかを理解しやすい。必要な予算や人員を求める際の根拠にもなる。

PoCの成績より「1年後も使えているか」を見る

　サービス選定では、検出できる脆弱性の数や価格だけに目を向けない方がよい。重要なのは、自社の人員と既存業務の中で使い続けられるかだ。

　PoC（概念実証）の期間中は、製品担当者の支援を受けながら集中的に結果を確認できる。しかし、本番導入後も同じ頻度で専門家が画面を確認できるとは限らない。大量のアラートを出すだけで、担当者がその意味を調べ直さなければならないサービスは、半年後には使われなくなる可能性がある。

　非専門家にも危険性と対応方法が伝わるレポートを出せるか、担当部門への依頼や進捗（しんちょく）確認を既存の業務フローに組み込めるかを確認したい。脆弱性対応だけを別系統の運用にすると、変更管理や月次のメンテナンス、資産台帳の更新と切り離され、担当者の追加作業になりやすい。

　継続運用には、脆弱性対応を一時的なタスクではなく、組織上の役割として定めることも欠かせない。誰が情報を確認し、誰が対応期限を決め、誰が例外を承認するのかを明確にする。

　全件に即時対応を求めるのではなく、リスクに応じたSLA（対応期限）を設ける方法もある。例えば、KEVに掲載された脆弱性は72時間以内、外部公開された機器のCriticalは1週間以内など、段階を分ける。ただし、これはトライコーダが示した設定例だ。実際の期限は、事業への影響やシステムを停止できる時間、補完策の有無などを踏まえて、各社が決める必要がある。

診断を受ける前に「自社の体」を見つける

　脆弱性診断は、対象を詳しく調べ、潜在的な弱点を見つける重要な取り組みだ。しかし、対象となる資産が抜けていたり、診断と診断の間に生じた変化を追えていなかったりすれば、診断結果だけで自社全体の状態を判断することはできない。

　まず、攻撃者と同じ外側の視点で自社の資産を見つける。次に、その資産の脆弱性と対応状況を継続的に管理する。その上で、重要な対象を人の目で詳しく診断する。この順番で「面」「線」「点」をつなぐことが、限られた人員で脆弱性対策を回す土台になる。

　毎年受けている「人間ドック」の対象から、自社が存在を忘れたシステムが漏れてはいないだろうか。診断結果を見る前に、まず攻撃者から見えている自社の姿を確かめたい。