2．資産把握－IT環境の変化に伴う把握すべき資産の拡大

脆弱性管理の出発点は、資産把握です。どのようなIT資産がどこに存在し、どのような形で利用されているのかを把握できなければ、脆弱性の有無を判断することも、対処の優先度を決めることもできません。

近年、ITシステムを取り巻く環境の変化に伴い、管理すべき対象領域そのものが広がっています。

• クラウド活用、外部サービスの利用拡大
  脆弱性管理の対象は、もはや社内に存在するサーバや端末だけではありません。クラウドや、外部サービスの利用が拡大したことで、クラウド環境に展開されたリソースなど、組織外に存在する資産についても管理対象とする必要があります。管理が行き届かない場合、クラウド環境の設定不備により、ストレージが公開状態になってしまったり、過去のプロジェクトで残存したシステムが放置されたり、シャドーITがまん延するリスクがあります。
• 基盤レイヤーのみならずアプリケーション内部も対象に
  従来の脆弱性管理は、OSやミドルウェア、ネットワーク機器といった基盤レイヤーを中心に行われてきました。しかし、現在ではアプリケーション内部で利用されているOSSライブラリや、その依存関係まで含めて考慮する必要があります。近年発生したLog4jの問題は、その象徴的な事例です。多くの組織では、アプリケーションが利用しているライブラリの深い依存関係まで把握できておらず、既存の資産台帳やスキャン対象から漏れていたコンポーネントが侵入経路となる恐れがあります。

図2：IT環境の変化に伴う把握すべき資産の拡大

そのため、対象領域ごとに異なるアプローチを組み合わせることが必要です。基盤レイヤーに対する脆弱性スキャンツールを活用する企業は多いですが、それに加えて、以下の例のような製品カテゴリを目的に応じて選択し、役割分担させることが重要です。

表1：製品カテゴリの例

3．脆弱性検知・評価－優先順位を決めるための考え方

資産把握が一定程度行われている企業において、次に問題になるのが、脆弱性をどのように検知・評価するかです。必要な製品・ツールを導入することで、脆弱性自体は検知できるものの、どの脆弱性を優先して対応すべきか判断できないといった状態は少なくありません。脆弱性の件数が増え続ける中で、検知されたすべての脆弱性を人手で精査し、個別に対応可否を判断していく運用では回しきれない状況になってしまいます。

従来はCVSS（Common Vulnerability Scoring System）に代表される深刻度スコアを用いた評価が主流でしたが、脆弱性件数の増加に伴い、CVSSの数値のみで対応優先度を判断することが難しくなっています。そこで、近年はCVSSを補完する考え方として、脆弱性の悪用状況や、自組織の業務・社会的影響といった要素を評価に取り込み、対応方針の意思決定を支援するSSVC（Stakeholder-Specific Vulnerability Categorization）という手法が提案されています。

SSVCを適用するには、表2に示すように、SSVCで定義されている4つの判断軸に沿って、脆弱性対応の優先度を整理する必要があります。重要なのは、判断軸そのものを理解するだけでなく、それぞれの軸について「現場では何を確認し、どのように判断するのか」をあらかじめ定めておくことです。

表2：SSVCで定義されている判断軸と判断観点

このように、SSVCの考え方に基づき、実効性のある判断基準を設けることで、検知された大量の脆弱性の中から、真に優先して対応すべきものを選び出すことが可能になります。

4．脆弱性対処－判断を止めないための設計

脆弱性検知・評価を経た後、多くの組織が立ち止まってしまうのが、パッチ適用をはじめとする脆弱性対処のフェーズです。脆弱性の存在や深刻度は把握できているものの、実際の対処に踏み切れず、結果として未対応の脆弱性が残り続けるケースは少なくありません。脆弱性対処が進まない主な理由として、プロセスが十分に定義されていないことが挙げられます。その結果、脆弱性対処を実施した場合と実施しなかった場合の業務影響を、その都度個別に判断することになります。

業務影響を懸念する姿勢そのものは、決して誤りではありません。しかし、昨今のサイバー攻撃の状況を踏まえると、パッチ適用は突発的な対応ではなく、必要な予防対処として組織があらかじめプロセスとして定義する必要があります。

こうした問題に対して有効なのが、パッチ適用を組織的に実施するためのガイドラインである「NIST SP 800-40 Rev.4」を参照し、意思決定を事前に定義することです。重要なのは、個々の脆弱性ごとに場当たり的な判断を行うのではなく、あらかじめ「どのような特性を持つ資産に対して、どのような条件のもとで、どの対応を取るのか」を決めておくことです。これにより、想定される業務影響や対応方針が明確になり、脆弱性対処に対する見通しを持って判断できるようになります。NIST SP 800-40 Rev.4では、脆弱性対処の計画を策定するにあたり、脆弱性リスクに対する対応シナリオをあらかじめ定義し、それぞれのシナリオごとに具体的な対応計画を定めておくという手法を提案しています。

表3：脆弱性リスクに対する対応シナリオの例

また、すべての資産を同一視するのではなく、類似した特性を持つ資産を論理的にグルーピングする「メンテナンスグループ」を定義し、グループごとにシナリオを計画することが推奨されています。これは、リスク特性・運用条件・可用性要件が近い資産は、各リスク対応シナリオにおいても、概ね同様の対処要件（パッチ適用のタイミング、検証の要否、停止許容時間など）を持つという考え方に基づいています。メンテナンスグループを活用することで、脆弱性発見のたびに個別判断を繰り返す必要がなくなり、判断の迅速化と運用の標準化が可能になります。

このように、脆弱性対処を「技術作業」としてではなく、意思決定プロセスとして設計することによって、判断が止まる状態を避け、組織として継続的に前に進めるようになるのです。

5．おわりに

脆弱性管理の目的は、脆弱性を「ゼロ」にすることではありません。変化し続けるIT環境の中で、状況に応じて適切に判断し、対処できる状態を維持することにあります。セキュリティ対策は、一度整えたら終わりではありません。環境や脅威の変化に合わせて、管理のあり方そのものを見直し続ける必要があります。すべてのベストプラクティスを、そのまま受け入れる必要はありません。重要なのは、自組織の環境や制約を踏まえたうえで、継続可能な形で脆弱性管理を設計することです。それこそが、「脆弱性を減らす」ための、現実的で確かな第一歩となります。