意外と理解されていない「脆弱性管理」どのように実施するべき？

企業にとって、サイバー攻撃から如何に自社システムを守るかは避けて通れない課題となっています。多くのサイバー攻撃は脆弱性を狙って行われるため、企業は自社システムに存在する脆弱性をいち早く認識し、パッチあてなど必要な対処を行っていく必要があります。

この取り組みを迅速に行うために必要なのが脆弱性管理です。今回は脆弱性管理の基本から、その具体的な実施方法までを詳しくご紹介します。

脆弱性管理とは？

脆弱性管理とは、システムやネットワークに存在するセキュリティ上の弱点や欠陥を特定し、修正するプロセスを指します。企業や組織がサイバー攻撃から自らを守るためには、いち早く脆弱性を検知し、修正を行わなければなりません。脆弱性を放置すると、悪意のある攻撃者により機密データの漏洩や業務停止といった重大な被害を招く恐れがあります。

立場ごとの脆弱性管理

脆弱性管理と一口に言っても、その取り組み内容は立場ごとに異なります。

以下では、脆弱性管理の解像度を高めるために、それぞれの立場による脆弱性への対応方法の違いをまとめます。

ユーザー企業のシステム管理者

ユーザー企業のシステム管理者は自社のシステムを安定的に稼働させ、ビジネスを継続し続けることをミッションとします。

よって、自組織のITシステムやネットワークにおいて設計・設定の不備が無いかや、利用しているサービス・ソフトウェアに脆弱性が無いかが関心ごととなります。

ITサービス・製品提供企業

ITサービスや製品を提供する企業は、自社のサービス・製品の品質に対して責任を持ちます。ユーザー企業に提供しているサービスや製品に脆弱性があれば、ユーザー企業はサイバー被害を受ける可能性にさらされ、もし被害が起きれば最終的にユーザー企業から訴訟される可能性もあります。

よって、ITサービス・製品提供企業は自社が開発したITサービスや製品のソースコード、およびITサービスや製品に組み込まれたソフトウェアやOSSなどの脆弱性を管理する必要があります。

SIer

SIerはユーザーの要望に従ってシステムを構築することをミッションとします。自社が選定し提供したITサービスや製品に脆弱性があれば、契約不適合となる可能性もあります。また、自社が提案したセキュリティ対策に不備があれば、契約上の問題はなくとも自社の信頼失墜につながります。

よって、要件定義時点で十分にセキュリティ対策を提案できているか、また要件定義にそって適切な実装を行えているかが脆弱性管理における関心ごととなります。

このように、同じ脆弱性管理といっても立場によって異なる観点を持っているのです。

脆弱性管理のプロセス

今回は、特にユーザー企業のシステム管理者の方の視点で、脆弱性管理の流れをご紹介します。脆弱性管理を行う際に参考になるのが、一般社団法人である日本シーサート協議会（NCA）が公開している「脆弱性管理の手引書システム管理者編^※1」です。本手引は2024年10月に公開されたものであり、最新の脆弱性管理の動向を含むものです。

この手引書の内容も参考にしつつ、具体的な脆弱性管理プロセスを見ていきましょう。

※1：一般社団法人日本シーサート協議会「脆弱性管理の手引書システム管理者編1.0版」

脆弱性管理対象の識別

まずは、自社システムで利用しているソフトウェアや各種製品などについて、情報を整理します。「脆弱性管理の手引書システム管理者編」では、以下の観点を押さえることを推奨しています。これらの情報を踏まえ、脆弱性管理の対象を識別します。

把握事項	目的	例
ソフトウェア名/製品名	脆弱性情報を収集する際のキーワードとして利用	○○ソフトウェア
バージョン情報	脆弱性に該当するかの確認に利用	1.2.3
機能カテゴリ/保持情報	リスク評価の判断材料となる	VPN接続用
構成	リスク評価の判断材料となる	社内NWへの接続インターネットからのアクセス可
設置場所	リスク評価の判断材料となる	××ビル
管理者/責任範囲	対処を行う主体の判断材料となる	○○部門

これらの情報を集めるためには、以下のような手段を利用します。

・仕様書・設計書による確認

・担当者へのヒアリング

・構成確認ツールなどを利用した外部スキャンによる管理対象の情報収集

・運用管理ソフトウェアなどを利用したエージェントによる管理対象の情報収集

・GUI/CLI操作による手動での管理対象の情報収集

このうち、基本的には仕様書、設計書による確認と担当者へのヒアリングが優先的な候補となります。一方で、システムによってはこれらの情報が存在しないケースもあります。その場合、外部スキャンやエージェントを利用する、もしくは手動で情報を収集するといった手段をとることとなります。

脆弱性情報の収集

次に、脆弱性に関する公開情報の収集を行います。

把握すべき脆弱性情報は「ソフトウェア・製品の脆弱性」と「設定・設計の脆弱性」に大別できます。それぞれ、脆弱性情報を収集・把握するための方法は異なります。

〇ソフトウェア・製品の脆弱性

ソフトウェアや製品の開発の過程で、さまざまな要因により発生してしまう脆弱性です。ユーザー企業側では検知することができないものであり、ソフトウェア・製品の提供者をはじめとした外部組織から情報を収集する必要があります。

「脆弱性管理の手引書システム管理者編」では、以下のような情報源を紹介しています。

情報源	具体例
セキュリティ関連の団体/組織	JPCERT/CC
	IPA
	IPA/ JPCERT/CC （JVN）
	CISA（KEVC）
	NIST（NVD）
ソフトウェア/製品の開発ベンダ	Micr osoft
ソフトウェア/製品の開発ベンダ	Red Hat

※一部抜粋

〇設定・設計の脆弱性

ユーザー企業側での設定・設計ミスを起因とします。よって、ユーザー企業自身での確認が必要となります。

ソフトウェア・製品の脆弱性情報の把握

ソフトウェアベンダーやセキュリティ関連の団体などから収集したソフトウェア・製品の脆弱性情報の内容を把握します。「脆弱性管理の手引書システム管理者編」では、以下の観点で脆弱性情報を整理することを推奨しています。

把握事項	例
CVE・脆弱性の名称	CVE-2023-xxxxx
対象ソフトウェア・製品	○○ソフトウェア
対象バージョン	ver 2.x.x～ver 3.y.y
脆弱性発露の条件	ローカルNWへの接続
影響	アクセス制御の不備による特権昇格
対応策・対応手順	パッチの適用
緩和策・回避策	設定変更・××機能の停止

設定・設計の脆弱性の把握

設定・設計の脆弱性については自社での把握が必要です。把握方法は多岐にわたりますが、ここではいくつか具体例をご紹介します。

〇適切な権限

権限は最小化されているか
IDの棚卸は定期的に行われているか

〇ソフトウェアの設定

要件定義通りに適切な設定が行われているか
設定変更のログは収集されているか
設定権限は最小のユーザーのみに与えられているか

〇設置場所

サーバーや端末などに対して、カードキーなどにより物理的なアクセス制限がかけられているか
アクセス権は最小限となっているか

組織におけるリスク評価

日々、大量の脆弱性が検知され、公表されています。この中には、自社に深刻な被害を与えるものも含まれていますし、あまり影響のないものもあります。よって、脆弱性に対して組織としてリスク評価を行い、ハイリスクのものを優先的に対処していく取り組みが必要です。

絞り込みを行う際には「発生可能性」と「想定被害」の2軸で評価を行います。発生可能性が高く、想定被害も大きい脆弱性は優先度を上げて対処する必要があります。

対処

リスク評価を行った上で、優先度の高い脆弱性から順に対処を進めていきます。このとき、取りうる対処方法について洗い出したうえで、その対処を行うことでどのようにリスクを低減できるのかを評価することで、対処の有効性を確認します。

たとえば、対処Aとしてパッチ適用を行うことで、脆弱性を完全に解消できるとします。ただし、この方法は検証などのために一定の期間が必要です。もう一つの選択肢として、脆弱性のある機能を停止する対処Bも考えられます。こちらはすぐに実施できますが、一方で被害の発生確率が下がるのみで、完全な解決は難しいものです。

このように、それぞれの対処方法にはよしあしがあることもあります。複数の対処方法から脆弱性が持つリスクを踏まえ、適切な選択肢を選んでいきます。

押さえておきたい脆弱性管理に関するキーワード

以下では、脆弱性管理に関連する重要キーワードをご紹介します。脆弱性管理を実施する上では必須ともいえる知識ですので、ぜひご覧ください。

CVE

セキュリティ関連業務を担当されている方はご存じかもしれませんが、脆弱性管理を行う際に、基本的な要素として押さえておくべきなのがCVEです。

CVE（Common Vulnerabilities and Exposures）は、脆弱性情報を一元的に識別するための番号です。発見された各脆弱性には一意のCVE番号が付与されます。CVEごとにその脆弱性に関する詳細情報や対処方法がまとめられていきます。

CVEは、セキュリティ専門家やシステム管理者が迅速かつ確実に脆弱性情報を共有し、適切な対応を行うために不可欠なものとなっています。脆弱性管理の基盤として国際的に広く利用されており、サイバーセキュリティにおける標準的な手法といえるものです。

SBOM

SBOM（Software Bill of Materials）は、ソフトウェア製品やシステムに含まれる全てのコンポーネントやその関係性をリスト化した文書のことです。SBOMを作成することで、自社システム内で利用されているソフトウェアやそのバージョン、ソフトウェア同士の依存関係などが明確になります。

SBOMを作成することで、自社の脆弱性管理における可視性を高め、自社で利用しているソフトウェアに脆弱性が発見された場合、速やかな対処が可能となります。

SBOMを作成する企業は増加傾向にあります。経済産業省でも、2023年よりSBOMの導入に関する手引を公開しており、2024年には最新版である2.0版を作成しています。^※2

※2：経済産業省「サイバー攻撃への備えを！「SBOM」（ソフトウェア部品構成表）を活用してソフトウェアの脆弱性を管理する具体的手法についての改訂手引を策定しました」

ASM

ASM（Attack Surface Management）は、企業におけるサーバー攻撃の対象領域を特定し、そのリスクを評価しつつ継続的に監視するための活動のことです。

ASMではツールも活用して外部公開されているIT資産を把握しつつ、利用しているテクノロジーの脆弱性を検出し、リスクの評価までを実施します。

IT資産の管理において、各システムが個別に台帳を作成すると、整理漏れや誤認などのリスクが存在します。ASMを導入することにより、攻撃者視点での実態に基づいたIT資産の探索・発見が可能となります。ASMを既存のIT資産管理手法と併用することで、精度の向上およびリスク管理の高度化が図れます。

CSPM

CSPM（Cloud Security Posture Management）はクラウド環境におけるセキュリティの状態を管理し、リスクを軽減するためのプロセスです。CSPMでは自社が利用するクラウド資産を自動検出し、各クラウドサービスのセキュリティポリシーが適切なものとなっているか監視を行います。

CSPMによりクラウド環境のセキュリティ設定の問題点を迅速に発見し、修正することができます。クラウドサービス提供事業者が提供するサービスを利用してCSPMを行うほか、サードパーティ製のソリューションを利用することも可能です。

CVSS

CVSS（Common Vulnerability Scoring System）は共通脆弱性評価システムと呼ばれ、脆弱性に対する汎用的な指標を指します。従来、脆弱性のリスクに対する表現はベンダーごとに異なっていましたが、CVSSの導入により標準化が行われました。CVSSは国際的に広く採用されており、世界共通の指標として活用できます。

CVSSを使用することで、脆弱性の優先順位を容易に判断することができます。これにより、限られた自社のリソースを最も影響の大きい脆弱性対策に集中可能です。