サイバー攻撃後に問われるのは、完全に防げたかだけではありません。予見可能なリスクに対し、合理的な体制を作り、優先順位、期限、例外、証跡を管理していたかが重要になります。
サイバー攻撃後に問われるのは、完全に防げたかだけではありません。
技術部門だけでなく、経営・法務・個人情報保護・委託先管理が共同で扱う統制として整理します。
脆弱性管理とは、情報システム、ソフトウェア、クラウドサービス、ネットワーク機器、委託先環境、OSS、ファームウェア、IoT・OT機器などにある弱点を把握し、優先順位を付け、修正、緩和、隔離、例外承認、証跡化、再評価を続ける管理活動です。パッチ適用ルールは、修正プログラム、アップデート、設定変更、バージョンアップ、代替策を、いつ、誰が、どの基準で、どの証拠を残して実施するかを定める社内規範です。
重要なのは、すべての脆弱性を同じ期限で処理する発想から離れることです。事業影響、攻撃可能性、既知悪用、外部公開、個人情報・営業秘密・重要インフラへの影響、契約上・規制上の義務を組み合わせ、リスクに応じて期限と手続を変えます。
次の重要ポイントは、脆弱性管理とパッチ適用ルールが影響する領域を示しています。読者にとって重要なのは、IT保守だけでなく、契約責任、当局報告、証拠保全、経営判断まで連動する点を読み取ることです。
取締役会・経営会議は、方針、SLA、重大例外、レガシー刷新投資、委託先管理方針を監督します。
法務部門は、契約条項、通知義務、当局報告、対外公表、訴訟対応、証拠保全を支援します。
CVE、CVSS、EPSS、KEV、SSVC、資産台帳、再スキャン結果を組み合わせて期限管理を行います。
CVE、CVSS、EPSS、KEV、SSVC、SLA、例外承認を、法務・経営にも説明できる形で整理します。
脆弱性管理では、技術用語を法務・経営の判断材料へ翻訳することが重要です。次の比較表は、主要用語が何を意味し、事故後の説明責任や契約実務でどのように使われるかを示しています。列ごとの違いを読むことで、点数だけでなく悪用状況や業務影響まで確認する必要が分かります。
| 用語 | 意味 | 法務・経営での使い方 |
|---|---|---|
| CVE | 公表された脆弱性を一意に識別する番号体系です。 | 通知、委託先照会、保険会社説明、訴訟で対象脆弱性を特定します。 |
| CVSS | 脆弱性の技術的深刻度を0.0から10.0で示す共通指標です。 | 出発点として使いますが、これだけで優先順位を決めないことが重要です。 |
| EPSS | 公開済みCVEが短期間に悪用される可能性を推定する仕組みです。 | 悪用されやすさを補助的に確認し、緊急度の説明に使います。 |
| KEV | 既に悪用が確認されている脆弱性の情報です。 | 予見可能性や回避可能性を問われやすいため、優先対応の強い根拠になります。 |
| SSVC | 悪用状況、技術的影響、業務影響などを組み合わせる判断方法です。 | なぜ先に直すか、なぜ一時的に受容するかを説明しやすくします。 |
| SLA | 重要度に応じた初動期限・是正期限です。 | 社内規程、委託契約、監査、当局対応の統制基準になります。 |
| 例外承認 | 期限内に是正できない場合の理由、代替策、残存リスク、期限を承認する手続です。 | 放置ではなく、期限付きのリスク受容として経営・監査に説明します。 |
パッチをすぐ適用できない場合でも、機能停止、ネットワーク隔離、WAFルール、アクセス制限、多要素認証、ログ保存延長、監視強化などにより、残存リスクを下げる選択肢があります。
取締役会、CISO、システムオーナー、法務、個人情報保護、内部監査、委託先の役割を明確にします。
脆弱性管理は、作業担当者だけでは完結しません。次の一覧は、組織内外の関係者が何を担うかを整理したものです。読者にとって重要なのは、期限超過や重大例外を誰が所有し、どの段階で経営や法務へ上げるかを読み取ることです。
方針、パッチ適用SLA、重大例外、レガシー更新、投資、委託先方針、対外公表方針を監督します。
監督評価基準、ツール、KPI、KRI、例外管理、重大報告を統括し、IT・法務・事業部門をつなぎます。
統括業務影響、停止可能性、利用データ、委託先、保守契約を把握し、期限内是正の実務責任を持ちます。
所有契約条項、通知義務、本人通知、当局報告、証拠保全、取引先説明、サイバー保険を確認します。
法的評価委託先やSaaS事業者が管理する領域でも、自社の顧客情報、自社サービス、自社契約に影響する場合、自社の説明責任は残ります。契約時だけでなく、運用中の通知、証跡提出、再委託先管理まで確認することが重要です。
存在を知らない資産は修正できないため、外部公開資産、重要データ、保守期限を優先して台帳化します。
資産台帳は、脆弱性情報と自社環境を結び付ける基礎です。次の表は、最低限台帳に含めたい項目と、その項目を使う理由を示しています。列を横に読むと、単なる機器一覧ではなく、リスク評価、契約確認、ログ保全、復旧計画につながる情報であることが分かります。
| 項目 | 内容 | 確認する理由 |
|---|---|---|
| 資産ID・システム名 | 一意の管理番号と業務上の名称です。 | CVE、チケット、契約、監査資料を同じ対象に結び付けます。 |
| 所有部門・技術管理者 | 事業部門、IT部門、ベンダー担当者です。 | 期限内是正と例外承認の責任者を明確にします。 |
| 外部公開有無 | インターネットから到達可能かを示します。 | 既知悪用時の優先度を大きく左右します。 |
| 処理データ・重要度 | 個人情報、営業秘密、決済情報、医療情報、停止許容時間です。 | 報告要否、顧客影響、事業影響を判断します。 |
| ソフトウェア構成・SBOM | OS、ミドルウェア、アプリ、ライブラリ、ファームウェア、部品表です。 | 脆弱性情報と対象製品を照合します。 |
| 保守期限・委託先 | EOL、EOS、サポート契約、運用・保守・開発・SaaS提供者です。 | パッチ提供可否と委託先照会の要否を確認します。 |
外部公開資産は、攻撃者から見える入口です。次の時系列は、全資産の完全把握を待たずに、どの順番で管理精度を上げるかを表しています。上から下へ進むほど、緊急把握から継続監視、SBOM・VEXを使った影響確認へ深まる点を読み取ってください。
VPN、リモートアクセス、管理画面、メールゲートウェイ、Webアプリケーション、API、クラウドストレージを優先します。
DNS、証明書透明性ログ、ASM、ペネトレーションテスト、クラウド棚卸し、委託先確認を併用します。
含まれる部品だけでなく、実際に悪用可能か、修正済みか、影響しないかを確認します。
CVSSだけに依存せず、既知悪用、外部公開、EPSS、事業影響、契約義務を合わせて判断します。
優先順位付けでは、点数だけではなく、実際の攻撃可能性と業務影響を組み合わせます。次の比較表は、判断要素を一覧化したものです。各行を読むと、同じCVSSでも外部公開、既知悪用、データ重要度、補完統制の有無で対応順が変わることが分かります。
| 要素 | 見るポイント | 優先度への影響 |
|---|---|---|
| 既知悪用・KEV | 実際に攻撃されているか、CISA KEVやベンダー情報にあるかを確認します。 | 最優先のシグナルになります。 |
| 外部公開・認証要否 | インターネットから到達可能か、認証なしで悪用可能かを確認します。 | 入口として使われやすい場合、期限を短くします。 |
| PoC・攻撃自動化 | 攻撃コード公開や自動スキャンの容易性を確認します。 | 短期間で攻撃が広がる可能性を見ます。 |
| データ・事業重要度 | 個人情報、営業秘密、決済、医療情報、停止時売上、社会的影響を確認します。 | 法務・個人情報保護・経営報告の要否に直結します。 |
| 法規制・契約義務 | 個人情報保護、金融、医療、重要インフラ、顧客SLA、通知期限を確認します。 | 技術判断から法的判断へ切り替わります。 |
次の分類は、法務・経営に説明しやすいP0からP4までの区分です。上にある区分ほど期限が短く、経営・法務・個人情報保護担当の関与が強くなります。P0やP1は、単なる技術分類ではなく報告と例外承認のトリガーとして読み取ることが重要です。
P0は24時間以内の初動と原則72時間以内の是正・緩和を目安に、P1以降も期限と必須措置を明文化します。
SLAは、単なる努力目標ではなく、社内規程、委託契約、監査、当局対応で参照される統制基準です。次の表は、初動期限、是正期限、必須措置を並べた標準モデルです。数値の短さだけでなく、各区分で誰に報告し、どの証跡を残すかを読み取ってください。
| 区分 | 条件例 | 初動期限 | 是正期限 | 必須措置 |
|---|---|---|---|---|
| P0 緊急 | KEV掲載、既知悪用、外部公開、認証不要RCE、重要認証基盤、攻撃自動化 | 検知後24時間以内 | 原則72時間以内 | 経営・法務・CISO報告、暫定緩和、ログ保全、再スキャン |
| P1 重大 | CVSS 9.0以上、EPSS高、PoC公開、重要データ到達可能 | 48時間以内 | 7日以内 | パッチ計画、例外承認、委託先確認 |
| P2 高 | CVSS 7.0から8.9、重要内部システム、権限昇格 | 5営業日以内 | 30日以内 | 通常変更管理、適用証跡、期限管理 |
| P3 中 | 影響限定、外部非公開、補完統制あり | 10営業日以内 | 60から90日以内 | 定期メンテナンスで是正 |
| P4 低 | 影響軽微、悪用困難、到達不能 | 次回棚卸し | 180日以内または次回更新 | リスク受容または更新計画 |
次の比較グラフは、各区分の是正期限の違いを視覚化したものです。棒が短いほど急いで対応し、棒が長いほど計画的な管理に寄せる意味があります。P0とP1だけが突出して短い点を読み取ると、緊急変更手続を別に用意する理由が分かります。
P0の72時間ルールは、必ず完全パッチを終えるという意味だけではありません。少なくとも、パッチ適用、機能停止、外部公開停止、ネットワーク隔離、WAF・IPS・EDRによる緩和、アクセス制限、多要素認証、アカウント無効化、ベンダー回避策、経営承認された一時例外のいずれかを完了し、証跡を残す考え方です。
標準プロセス、緊急プロセス、OT・IoT・クラウドの例外的な考慮を一つの運用に接続します。
実行手順は、検出から証跡保管までを一本につなげる必要があります。次の判断の流れは、標準的なパッチ適用をどの順番で進めるかを示しています。上から下へ進む順番に意味があり、影響判定とリスク分類を飛ばすと、期限や証跡が不明確になる点を読み取ってください。
ベンダー、NVD、CISA KEV、EPSS、診断結果、委託先報告を確認します。
対象製品、バージョン、外部公開、処理データ、委託先を確認します。
P0からP4に分類し、初動期限と是正期限を設定します。
ログ保全、最低限の検証、バックアップ、監視、事後報告を行います。
テスト、承認、本番適用、稼働確認、再スキャン、証跡保管を行います。
本番適用時は、影響範囲、バックアップ、復旧可能性、ロールバック手順、変更日時と責任者、運用監視、適用後確認、再スキャン、チケット添付を確認します。侵害が疑われる場合は、パッチ適用で証拠が消えることがあるため、ログ保全、ディスクイメージ、メモリ取得、スナップショット、ネットワークログ保全を検討します。
次の一覧は、通常のOS更新だけではない現代的な対象を示しています。読者にとって重要なのは、クラウド、コンテナ、IaC、CI/CD、OT・IoT・医療機器では、パッチ以外の統制や責任共有モデルまで確認する必要がある点です。
基盤は事業者、設定・権限・ログ・API連携は利用企業が担う領域があります。契約と責任共有モデルを確認します。
ベースイメージ、Kubernetesノード、IaCモジュール、ランタイム、依存ライブラリ、秘密情報管理を更新対象に含めます。
停止できない場合は、ネットワーク分離、一方向通信、許可リスト、MFA、ジャンプサーバー、保守更新計画を組み合わせます。
委託契約、SaaS契約、漏えい等報告、証拠保全、再発防止を同じ台帳で追える状態にします。
脆弱性が悪用されると、個人情報漏えい、営業秘密漏えい、契約違反、サービス停止、当局報告、本人通知、対外公表、訴訟対応が同時に問題になります。次の重要ポイントは、法務・個人情報保護担当が特に確認する領域をまとめたものです。項目同士の関係を読むことで、技術チケットだけでは足りないことが分かります。
個人情報漏えい等の速報は発覚日から概ね3から5日以内、確報は原則30日以内、不正目的によるおそれがある場合などは60日以内と整理されています。パッチ状況、既知悪用情報、アクセスログ、影響範囲、再発防止策を同じ説明資料で追える状態が重要です。
次の比較表は、契約・個人情報・インシデント対応で集めるべき情報を並べたものです。各列を読むと、同じ脆弱性でも、委託先への照会、本人通知、フォレンジック、再発防止の観点で必要情報が異なることが分かります。
| 領域 | 確認する情報 | 実務上の意味 |
|---|---|---|
| 委託契約 | 通知期限、パッチ義務、証跡提出、再委託先管理、監査権です。 | 委託先が管理している場合でも自社の説明責任を支えます。 |
| SaaS契約 | 脆弱性管理方針、重大脆弱性通知、監査報告、ログ提供、サブプロセッサーです。 | 利用企業が直接パッチできない領域の責任分担を明確にします。 |
| 個人情報保護 | 個人データ到達可能性、アクセスログ、影響人数、再発防止策です。 | 漏えい等報告・本人通知の要否と期限を判断します。 |
| インシデント対応 | Webシェル、未知アカウント、権限昇格、ランサムウェア、情報窃取の兆候です。 | パッチだけで終わらせず侵害調査へ進むか判断します。 |
証跡は、実施した作業だけでなく、判断した理由を残すものです。次の表は、監査や訴訟で説明に使いやすい証跡を整理しています。確認資料の列を読むことで、脆弱性台帳、変更管理、委託先連絡、個人情報評価が一体で必要になることが分かります。
| 確認項目 | 残す証跡 | 説明できること |
|---|---|---|
| 検出と評価 | 検出日時、情報源、CVE、CVSS、EPSS、KEV該当性、影響資産です。 | いつ知り得たか、何を対象にしたかを説明します。 |
| 判断過程 | 影響有無、リスク分類、対応期限、補完統制、例外承認です。 | 合理的期間内に対応したか、延長理由があるかを説明します。 |
| 実施結果 | 変更承認、適用日時、担当者、バージョン確認、再スキャン、ロールバック記録です。 | 是正完了と失敗時対応を説明します。 |
| 外部連携 | 委託先とのやり取り、経営報告、個人情報保護・法務評価です。 | 契約・規制・経営判断が連動していたことを説明します。 |
M&Aでは、対象会社の脆弱性管理成熟度が、価格、表明保証、補償、PMI、統合コストに影響します。次の一覧は、デューデリジェンスとPMIで優先して確認する事項を示しています。左右の項目を比べると、買収前はリスク把握、買収後は外部公開資産と認証基盤の短期是正が中心になることが分かります。
資産台帳、外部公開資産、EOL・EOS、重大脆弱性未対応、KEV該当、診断結果、過去インシデント、委託先管理、パッチSLA、例外台帳、ログ、復旧テスト、サイバー保険を確認します。
重大な既知脆弱性の把握と是正、保守切れシステムの重大リスク、重大インシデント認識、未報告事案の有無、委託先義務を限定条件付きで整理します。
外部公開資産の棚卸し、KEV確認、管理者アカウント・VPN・SSO統合、ログ取得、EDR導入、EOL隔離、重大脆弱性の短期是正、契約見直しを進めます。
目的、適用範囲、定義、役割、資産管理、優先度、期限、例外、証跡、委託先、監査を条文化します。
社内規程に落とし込む際は、抽象的なセキュリティ方針で終わらせず、誰が何をいつまでに行うかを明記します。次の一覧は、規程に置くべき条項の構成を示しています。順番を読むと、目的と範囲を定めた後、役割、資産管理、収集、分類、期限、例外、証跡、委託先、個人情報、監査へ進む設計が分かります。
情報資産、クラウド、OSS、OT・IoT、委託先環境を対象にし、取締役会、CISO、システムオーナー、IT、法務、個人情報保護、内部監査、委託先管理の責任を分けます。
重要資産、外部公開資産、個人情報取扱資産、EOL資産を台帳化し、CVSS、EPSS、KEV、既知悪用、事業影響、契約義務でP0からP4へ分類します。
P0の緊急変更、期限延長時の理由・残存リスク・再評価日、証跡保存、委託先義務、漏えい等対応、定期監査と改善を明文化します。
業種別には、金融・証券・保険ではシステムリスクと顧客保護、医療・ヘルスケアでは機微情報と可用性、製造・OTでは工場停止と営業秘密、SaaS・ITサービスでは多数顧客への影響、EC・決済ではカード情報とPCI DSSを意識します。海外取引では、SECのサイバー開示、EU NIS2、DORAなどが契約上または実務上影響する場合があります。
CVSS偏重、パッチ停止リスク、委託先任せ、例外承認の誤解を一般情報として整理します。
一般的には、CVSSは重要な出発点ですが、それだけで優先順位を決める運用は不十分とされています。既知悪用、外部公開、攻撃自動化、重要データ、補完統制、事業影響、契約義務を組み合わせて判断する必要があります。
一般的には、停止リスクと侵害リスクを比較し、パッチ、緩和、隔離、監視、保守契約、更新計画を文書化することが重要とされています。パッチが難しい場合も、リスクを放置せず、期限付きの例外承認と代替策を記録する必要があります。
一般的には、委託先が管理していても、自社の顧客、自社の個人データ、自社サービスが影響を受ける場合、自社の説明責任は残ると考えられます。契約上の義務、通知期限、証跡提出、再委託先管理を事前に整えることが重要です。
一般的には、既知悪用脆弱性が存在していた場合、既に侵害されている可能性を確認する必要があります。ログ調査、認証情報変更、バックドア確認、影響範囲調査、個人情報漏えい等の評価が必要になる可能性があります。
一般的には、例外承認はリスクを見える化し、期限付きで管理する手段であり、責任を消すものではありません。重大脆弱性を長期間例外扱いにする場合は、経営判断として記録し、代替策と更新計画を持つ必要があります。