2025.11.07
脆弱性を識別・評価・管理する仕組み
目次
中小企業の経営者や情報システム担当者の皆さん、日々のセキュリティ対策、お疲れ様です。
サイバー攻撃により被害を受けるリスクを最小化するためには、組織や情報システム等のどこに、どのような脆弱性が存在するのか、それによってどのようなリスクを顕在化させることになるのかを認識し、適切に対処する必要があります。
今回は、組織で利用するIT製品等の脆弱性を認識してその影響度等を評価し、管理する上で知っておいていただきたい基準や仕組み等について解説します。
●組織における脆弱性の例
「セキュリティ対策における基本的な考え方」の回で解説したように、脆弱性は組織や情報システム等に内在する様々な弱点や欠陥ですが、自助努力によって取り除いたり、低減させたりすることが可能です。
一般的に、組織における脆弱性には次のようなものがあります。
組織における脆弱性の種類とその具体例
| 脆弱性の種類 | 具体例 |
|---|---|
| 設備面の脆弱性 |
|
| 技術面の脆弱性 |
|
| 管理面・制度面の脆弱性 |
|
OSやソフトウェアのリリース後に設計ミスやプログラミングミスなどによる欠陥(バグ)が発見されることがありますが、それらの多くが脆弱性となります。市販されているソフトウェア等であれば、脆弱性の影響度や緊急度に応じて開発元が脆弱性を修正するためのプログラム(パッチ)を提供しますが、利用している側の組織がパッチを適用しなければ脆弱性は存在したままとなります。
これ以降は組織で利用するIT製品における脆弱性管理において、有用な基準や手法等について取り上げます。
●SCAPを構成する6つの標準仕様
OSやミドルウェア、ネットワーク機器等の脆弱性については、自社のIT環境に関係のある情報をいち早く収集し、その緊急度や影響度等を考慮しながら適切に対処することが求められます。
米国の国立標準技術研究所(NIST:National Institute of Standards and Technology)では、情報セキュリティ対策の自動化と標準化を目指して、脆弱性の管理、測定、評価等を自動化するための基準として、セキュリティ設定共通化手順(SCAP:Security Content Automation Protocol)を策定しています。
SCAPは、次の6つの標準仕様から構成されています。
SCAPの6つの標準仕様
| 略称 | 名称 | 主な用途 |
|---|---|---|
| CVE |
Common Vulnerabilities and Exposures (共通脆弱性識別子) |
脆弱性を識別する |
| CCE |
Common Configuration Enumeration (共通セキュリティ設定一覧) |
セキュリティ設定を識別する |
| CPE |
Common Platform Enumeration (共通プラットフォーム一覧) |
製品を識別する |
| CVSS |
Common Vulnerability Scoring System (共通脆弱性評価システム) |
脆弱性の深刻度を評価する |
| XCCDF |
eXtensible Configuration Checklist Description Format (セキュリティ設定チェックリスト記述形式) |
チェックリストを記述する |
| OVAL |
Open Vulnerability and Assessment Language (セキュリティ検査言語) |
脆弱性やセキュリティ設定をチェックする |
●JVNの概要
日本では、組織の脆弱性管理を支援するポータルサイトとしてJVN(Japan Vulnerability Notes)があります。
JVNは、国内で使用されている各種製品等の脆弱性関連情報とその対策情報を提供するポータルサイトであり、独立行政法人 情報処理推進機構 (IPA)とJPCERT コーディネーションセンター(JPCERT/CC)とが共同で運営・管理しています。
JVN では、脆弱性関連情報だけでなく、製品開発者との調整を通じ、対策方法や対応状況等の情報も提供しているのが特徴です。
JVNでは、脆弱性を識別するための識別子として前述のCVEを採用しています。CVEは個別の製品に含まれる脆弱性を対象としており、米国政府の支援を受けた非営利団体のMITRE社が採番し管理しています。なお、MITRE社は「サイバーキルチェーンとMITRE ATT&CK」の回でもご紹介しています。
●CVSSの概要
SCAPの一つであるCVSSは、IT製品の脆弱性に対する製品ベンダー等に依存しないオープンで汎用的な評価手法です。現状ではCVSSのバージョン3が広く普及していますが、最新版は2023年11月にリリースされたバージョン4です。
CVSSバージョン3では、脆弱性を評価するために次の三つの基準を用いています。
①基本評価基準(Base Metrics)
基本評価基準は、脆弱性そのものの特性を評価します。IT製品の機密性、完全性、可用性に対する影響を、どこから攻撃が可能かといった攻撃元区分や,攻撃する際に必要な特権レベルなどの基準で評価し、CVSS基本値(Base Score)を算出します。
②現状評価基準(Temporal Metrics)
現状評価基準は、脆弱性の現状の深刻度を評価します。当該脆弱性に対する攻撃コードの出現有無や、対策情報が利用可能であるかといった基準で評価し、CVSS現状値(Temporal Score)を算出します。
③環境評価基準(Environmental Metrics)
環境評価基準は、IT製品の実際の利用環境も加味した上で、最終的な脆弱性の深刻度を評価します。当該脆弱性を突いた攻撃による被害の大きさや、対象製品の組織における使用状況といった基準で評価し、CVSS環境値(Environmental Score)を算出します。
●EPSSとKEVの概要
CVSSとは異なる脆弱性評価の仕組みとして、EPSS(Exploit Prediction Scoring System)やKEV(Known Exploited Vulnerabilities catalog)があり、近年CVSSに加え、脆弱性管理に活用する組織が増えてきています。
EPSSは、機械学習によって当該脆弱性が今後30日以内に悪用される可能性を予測した指標であり、EPSSを開発・運営するFIRST (Forum of Incident Response and Security Teams)のサイトで公開されています。なお、FIRSTは、世界中の CSIRT (Computer Security Incident Response Team) コミュニティが情報交換やインシデント対応における協力関係を構築する目的で 1990年に設立された国際的なフォーラムであり、CVSSの管理も行っています。
KEVは、既知の悪用された脆弱性のリストであり、実際に悪用されたことが確認された脆弱性を米国のCISA(Cybersecurity and Infrastructure Security Agency)が公開しています。
その他、ソフトウェアの脆弱性管理等に活用できるツールとしてSBOM(Software Bill Of Materials)があります。SBOMはソフトウェアを構成する各部品(コンポーネント)の名称,ビルド情報,ライセンス情報,互いの依存関係,どのような構成となっているか等を示すリストです。SBOMにより,ソフトウェアの構成情報を詳細に把握することができるため,脆弱性情報の即時の特定等が可能となります。
