本稿は、情報セキュリティを推進する責任者や実務担当者を対象とし、ServiceNowを活用した脆弱性管理基盤設計及び運用設計のポイントを提示する。

ServiceNowに関する具体的な技術的実装手順や、製品バージョンに依存する設定値は含まれない。

PoC（Proof of Concept、概念実証）を通じて導入課題を解決した上で、スモールスタートによる段階的導入を推奨する。PoC実施にあたっては、以下を明確化し、実現可能性を定量的に評価する。

• ・脆弱性管理が必要なIT資産やそのIT資産を管理する関係者の特定
• ・CMDB（Configuration Management Database、構成管理データベース（システムを構成するハードウェア、ソフトウェア、ネットワーク機器などのIT資産情報と、それらの関係性を体系的に管理するデータベース））の整備
• ・現行の脆弱性スキャナ、CMDB及びIT資産管理ツールとの連携可否
• ・脆弱性検出から修正完了までの目標復旧日数やリスクベースでの優先度判断基準

2.1サイバー攻撃の高度化と多様化

近年、サイバー攻撃は高度化・多様化しており、表1に示すとおり脆弱性の公開から悪用までの期間は数日程度にまで短縮されている。対応頻度の増加に伴い、手作業による脆弱性管理ではリソースが不足し、処理能力が限界に達しており、優先度付けや証跡管理及び迅速な対応が困難となっている。対応の遅延は、攻撃の被害拡大や対応コストの増大を招くリスクが高まる。

特に表2に示すような、脆弱性が公開される前から悪用が始まるゼロデイ攻撃や、公開済みの脆弱性が標的となり、公開から数日以内に悪用されるNデイ攻撃が多い。

2.2規制・監査要件の強化

表3に示すとおり、国内外でセキュリティ関連の規制や監査要件が強化されており、脆弱性の検出・評価・対応における一貫性と証跡管理、リスクベースでの優先度付け、対応状況の可視化、マネジメント層や経営層への報告体制の整備が求められている。これらはシステム設計や運用に直結する技術課題であると同時に、法令遵守や取引要件、信用評価にも関わる重要な経営課題でもある。

3.1脆弱性管理プロセスとは

標準的な脆弱性管理プロセスを表4に整理する。脆弱性管理は、まずIT資産を網羅的かつ正確に把握し、その重要性やリスクを評価することから始まる。

外部情報源となるCVE（Common Vulnerabilities and Exposures、共通脆弱性識別子）やメーカーが公開する脆弱性情報や脆弱性スキャナで検出された脆弱性を確認し、脆弱性の深刻度や攻撃可能性を踏まえてリスクを算定する。その上で、対応の優先度を決定し、パッチ適用や設定変更、代替策による修正・緩和を実施する。その後、再スキャンや継続的なモニタリングで対策の有効性を検証する。進捗や残存リスクはIT資産の関係者や情報セキュリティ部門に報告され、確実な対応が徹底される。

さらに、脆弱性対応の遅延や、セキュリティポリシー・基準に基づく対応困難な場合に、期限延長やリスク受容を申請・承認する例外申請プロセスを適切に運用する。例外申請の要因を分析し、継続的な業務改善を行うことで、脆弱性管理プロセスの成熟度を向上させる。また、IT統制の観点では、脆弱性管理プロセスを明確に定義し属人化を排除すること、対応責任を明確化すること、並びに一貫性のある評価基準に基づき合理的な対応判断が求められる。

3.2脆弱性管理の課題

脆弱性管理には、「2.サイバー攻撃時代の脅威」に示したとおり、サイバー攻撃の高度化や対応頻度の増加に対して仕組みや処理能力が限界に達しており、優先度付けや証跡管理が滞り、対応の遅れが発生するという構造的な課題が存在する。情報セキュリティやIT統制の関連部門は、監視、エスカレーション、報告支援を担うべきだが、脆弱性対応状況の情報連携が不十分な場合、対応状況の把握が困難となり、是正措置の実効性が著しく低下する。結果として、以下の表5や表6に示すリスクを招いている。これらの課題は、情報・責任・判断が業務部門ごとに分断された非効率な業務構造に起因している。

(1)セキュリティ管理・IT統制の課題

表5に、セキュリティ管理やIT統制の主要な課題を整理する。

(2)脆弱性対応の課題

表6に、脆弱性対応の主要な課題を整理する。

「3.脆弱性管理プロセスとその課題」で示した課題を解決するために、ServiceNowを活用する。ここでは、ServiceNowの概要について説明する。

4.1ServiceNowとは

ServiceNowは、デジタルワークフローで「ヒト・プロセス・システム」をつなぎ、企業全体の生産性と品質を向上させる統合的なプラットフォームである。 ServiceNowは、IT資産情報、脆弱性情報、対応状況、責任及び証跡を一元的に統合して管理するプラットフォームとして機能する。この一元管理機能が、企業におけるガバナンスと迅速な対応を支える基盤となる。表7に、ServiceNowの主な特長を整理する。

(1)デジタルワークフローの役割

デジタルワークフローとは、業務プロセスをデジタル化して一元管理し、システム間の連携を通じた自動処理を可能にする仕組みである。 この仕組みは、従来人手により処理されていた申請、承認、問い合わせ対応、セキュリティ対応といった部門やシステムをまたぐ業務を統合管理し、業務を自動化する。

(2)CMDBとデータ構造標準化の役割

ServiceNowは、CMDBとCSDM（Common Service Data Model、共通サービスデータモデル）を提供する。CMDBはIT資産の情報とその関係性を可視化し、脆弱性の影響範囲の特定に利用可能である。CSDMは様々な業務で利用されるデータ構造を標準化する。情報が業務間で分断されずシームレスなデータ連携が可能であるため、業務を横断した自動化を実現できる。

4.2ServiceNow Vulnerability Response とは

ServiceNow Vulnerability Response(VR)は、脆弱性管理業務を統合的かつ効率的に運用するための専用アプリケーションである。VRはCMDBと脆弱性スキャナを連携させ、脆弱性検出から修復、例外管理、報告、そして改善に至るプロセス全体を自動化・可視化する。これにより、セキュリティ対応の確実性とスピードを向上させる。

(1)主要なセキュリティ基準とVRの対応領域

VRは主要なセキュリティ管理基準に準拠した設計思想に基づいて構築されており、企業の脆弱性管理プロセスを体系的及び技術的に支える統制可能な仕組みを備えている。主要なセキュリティ管理基準とVRの対応領域を表8に整理する。

(2)主な機能

VRの主な機能を表9に整理する。CMDBと脆弱性スキャナを連携させることで、脆弱性情報をIT資産に自動的に紐づけし、リスクスコアを算出したうえで対応期限や優先度及び責任者を自動設定する。

加えて、例外管理による残存リスクの統制、ダッシュボードやレポート機能による進捗・対応率の可視化、遅延要因や例外傾向の分析による継続的な業務改善といった仕組みを備えている。

(3)VRの活用ポイント

脆弱性管理プロセスは、表4で示すとおり、IT資産の把握からリスク評価、脆弱性情報の収集、修復・検証、報告、改善まで一連の流れで構成される。VRはこれら脆弱性管理プロセスに適合しており、効率的かつ確実な対応を可能にする。脆弱性管理プロセスと、各ステップにおけるVRの活用ポイントを表10に整理する。

ServiceNowは、IT資産、脆弱性、対応状況、責任、証跡を一元管理し、体系的なセキュリティ運用とIT統制の実効性を向上させる。 VRは、脆弱性スキャナとの連携による自動検出、CMDBとの統合による影響範囲の可視化、リスクベースの優先度付け、対応状況の追跡、証跡管理までを包括的に支援し、属人化や対応のばらつきを防止するとともに、説明責任と報告体制を強化する。 ServiceNowとVRは、セキュリティ管理・IT統制・脆弱性管理における複数の課題に横断的に対応する役割を担う。

5.1 節では、ServiceNowとVRの導入による脆弱性管理の課題解決と期待される効果を示す。5.2 節と5.3 節では、設計時に考慮すべき脆弱性管理基盤設計及び運用設計時の2つのポイントを解説する。

5.1脆弱性管理における課題解決

セキュリティ管理・IT統制上の課題や、脆弱性対応における課題について、課題解決と期待される効果を示す。

(1)セキュリティ管理・IT統制上の課題解決

表11に、セキュリティ管理・IT統制上の主要な課題に対するServiceNowの役割と期待する効果を整理する。

(2)脆弱性対応における課題解決

表12に脆弱性対応における主要な課題に対するServiceNowの役割と期待する効果を整理する。

5.2脆弱性管理基盤設計のポイント

脆弱性管理基盤には、CMDBの整備が重要である。IT資産情報や依存関係、業務重要度、担当者情報などをCMDBで一元管理することで、影響範囲の特定や対応の優先度付けが可能となる。

CMDB はCIの属性情報や他のCIとの関係性を体系的に管理する。

図1に脆弱性管理基盤イメージを示す。

図1に示されたCIについて、表13に具体例を示す。

(1)CMDBの設計指針

CMDBは、脆弱性発生時に影響を受けるITサービス、関連サーバ及び業務を体系的に把握できる構造とする。また、対応の優先度と責任の所在を明確化するための情報を定義し、組み込むことが重要となる。CMDBは、変更管理や監査対応にも活用でき、継続的なセキュリティ強化を支える基盤となる。

①CMDB設計のポイント

脆弱性対応の優先度と責任の所在を判断し、リスクベースの優先度付けを可能にするため、CMDBには、表14に示される要素が必要である。表14にリスクベースで脆弱性管理を実現するためのCMDB設計のポイントを整理する。

②CMDB運用のポイント

脆弱性対応の実効性を確保するには、CMDBの最新化が重要である。ゼロデイ攻撃やNデイ攻撃が発生した際には、影響を受ける可能性のあるIT資産を迅速かつ正確に特定することが求められる。しかし、CMDBが不完全又は更新されていない場合、IT資産の把握に遅延が生じ、結果として対応の優先度付けや修復計画の策定が困難となる。対応の遅延は、攻撃の被害拡大や対応コストの増大を招くリスクが高まる。こうしたリスクを回避し、CMDBの鮮度と正確性を担保する運用設計のポイントを表15に整理する。

(2)脆弱性スキャナ連携における設計指針

VRと脆弱性スキャナ連携は、脆弱性情報の自動取り込みに加え、CMDBとの統合、修復プロセスの自動化、証跡管理までを支える基盤機能である。設計にあたっては、単にAPI連携の可否を確認するだけでなく、取得データの正確性・整合性、並びに運用面での実効性が担保されているかを検証することが重要である。表16にVRと脆弱性スキャナ連携のポイントを整理する。

(3)脆弱性情報とCMDBの統合における設計指針

脆弱性情報とCMDBを統合するためには、脆弱性情報とCIをマッチングする識別子の整合性とデータ構造の対応関係が重要である。その精度が低い場合、脆弱性対応の漏れや誤配信が発生し、後続の運用プロセスや制度対応に悪影響を及ぼす可能性がある。表17に脆弱性情報とCMDBとのマッチングにおける設計のポイントを整理する。

(4)リスクスコアと対応期限の設計指針

脆弱性対応の優先度を合理的に判断するには、リスクスコアの算出ロジックが業務実態と整合していることが重要である。VRでは、CVSSや攻撃可能性及びCMDBの業務重要度を考慮した動的なリスクスコアを算出し、対応期限を自動的に設定する。「業務影響 × 脆弱性の深刻度 × 攻撃可能性」という観点からスコアを導出し、対応優先度を自動的に決定する。表18にリスクスコアの構成要素と算出ロジック（例）を示す。

対応期限は、CIの業務重要度や例外申請の有無に応じて動的に調整される必要があり、セキュリティ統制と柔軟性の両立が求められる。表19に対応期限の自動設定ロジック（例）を示す。

(5)脆弱性対応の担当者・責任者アサインにおける設計指針

対応漏れの防止、責任所在の明確化、期限管理の自動化を実現するため、脆弱性対応作業の担当者へのアサインや責任者へのエスカレーションが重要である。表20に脆弱性対応に責任を持つ担当者や責任者へのアサイン設計のポイントを整理する。

(6)リスク受容プロセスの設計指針

脆弱性対応では、業務上の都合や技術的制約により期限内対応が困難となるケースが必ず発生する。例外申請承認のワークフロー化が妥当であり、かつ脆弱性対応の現場で運用可能か検証することが重要である。この仕組みが不十分だと、対応漏れが放置されるか、あるいは例外申請が乱発されて統制が形骸化するリスクが生じる。例外申請においては、「セキュリティ統制と柔軟性のバランスが取れているか」、「制度対応に耐えうるか」、「現場で運用定着可能か」を見極めることが重要である。表21に例外申請ワークフロー設計のポイントを整理する。

5.3脆弱性管理運用設計のポイント

脆弱性管理の実効性を高めるためには、情報セキュリティ部門が対応状況を継続的に把握し、適切な統制やエスカレーションや報告支援を行う運用設計が重要である。特に、マネジメント層や経営層への説明責任を果たすための可視化と報告基盤の提供が、対応漏れの防止と制度対応力の向上に直結する。以下では、これらの要請に応えるために必要となる可視化・監視・フォローアップを支える運用設計の主要構成要素を示す。

(1)ダッシュボードの設計指針

ダッシュボードは、現場担当者が自分の担当範囲における未対応や対応期限、重大度、責任所在、例外申請状況を即時に把握できる基盤である。これにより、対応漏れの防止、優先度付けの効率化、統制部門やマネジメント層や経営層との円滑な情報共有が可能となる。さらに、進捗率や期限超過件数を可視化することで、説明責任の履行にも寄与する。正確なデータ同期、更新頻度の担保、適切なアクセス権限設計が運用上の要点となる。表22にダッシュボード設計のポイントを整理する。

定期的な報告業務を標準化と、対応履歴や例外申請の証跡を含むレポートにより、マネジメント層や経営層への報告や監査への対応を可能にする。表23に定期レポート設計の設計ポイントを整理する。

(2)対応状況のモニタリングにおける設計指針

対応の遅延や責任者不在といった運用リスクを防ぐため、期限超過や未対応であるCIの自動抽出及びこれらの理由における傾向分析を含む継続的なモニタリングが必要である。表24に統制部門が現場の状況を正確に把握し、是正支援へとつなげるモニタリング設計のポイントを整理する。

(3)フォローアップやエスカレーションの設計指針

脆弱性や対応遅延を放置せず、組織的な是正行動につなげるには、フォローアップやエスカレーションの仕組みが重要である。これらのプロセスを自動化することで、統制部門が適切なタイミングで介入し、対応力の強化と説明責任の履行を両立することが可能となる。表25にフォローアップやエスカレーション設計のポイントを整理する。

6.1脆弱性管理の改善効果

本稿に示した設計ポイントがもたらした脆弱性対応の改善効果を示す。

(1)対応責任の明確化

CMDBに登録された責任者・担当者情報で脆弱性対応を自動的にアサインし、対応責任が明確化され対応漏れが解消された。

(2)優先度付けの確立と対応遅延の抑制

IT資産の重要度や脆弱性の深刻度に基づき、自動的に脆弱性対応の優先度や対応期限を設定した。優先度や対応期限が明確化されたことで対応遅延が抑制された。

(3)判断精度の向上と初動対応の迅速化

脆弱性情報とCMDBが統合され脆弱性の影響を受けるIT資産の特定が迅速化した。

(4)リアルタイム可視化と全体状況の把握

未対応状況を示すダッシュボードやフォローアップを通じて脆弱性対応の対応状況の把握でき、対応漏れの解消と期限内完了が促進された。

(5)報告・監査対応の容易化

マネジメント層・経営層向け報告資料の作成がダッシュボードにより効率化された。また、監査時の証跡提出も効率化され、報告・監査対応が容易になった。

6.2脆弱性管理の今後の課題

一方で、運用定着に向けた顕在的な課題として、例外申請ワークフローの運用プロセスにさらなる改善が必要である。具体的には、対応期限超過後の例外申請が散見されたこと、脆弱性情報やリスク評価に対する承認者の理解不足による形式的な承認がアンケート調査から確認された。

このような例外申請の形骸化は、制度の信頼性と運用の有効性を損なうため、今後、実効性を確保するため、以下の施策を講じることが必要となる。

(1)段階的なリマインド

対応期限の1か月前、2週間前など、段階的な自動リマインドを行い、事後申請を予防する。

(2)申請フォーマットの標準化

記載内容の深度を統一し、承認者側の理解促進と審査時間の短縮を促し、形式的承認を防止する。

(3)承認者向けの支援策

審査用チェックシートやガイドラインを整備し、申請内容の理解促進と、適切な判断のための確認ポイントを明確化する。

• [1]How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends
  https://cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2023?e=48754805&hl=en