みなさんこんにちは、ServiceNow担当のきりんです。

ITシステムにおける「脆弱性」とは、ソフトウェアやOS、ミドルウェアなどに存在するセキュリティ上の弱点のことを指します。
これらの弱点が悪用されると、不正アクセスや情報漏えい、サービス停止といった重大なインシデントにつながる可能性があります。

脆弱性そのものは、日々公開されるCVE情報やセキュリティベンダーの診断結果などから発見されます。
しかし、企業にとっての本当の課題は「脆弱性があること」ではなく、それを 誰が・いつまでに・どのように対応するのかを管理することにあります。

ServiceNow単体で脆弱性スキャンを実行するわけではありませんが、
Vulnerability Response（以下、VR）が各種スキャナーと連携することで、検出から対応完了までを一貫して管理できます。

VRを学び始めた段階では、
「どのレコードが起点になるのか」
「脆弱性一致アイテムと修復タスクの役割の違いは何か」
「どこまでが自動で、どこからが設計対象なのか」
といった点が分かりづらいと感じることも多いのではないでしょうか。

本記事では、VRに関する主要な用語や構成要素を整理しながら、導入検討や学習の土台となる全体像を解説します。

VRの概要

VRは、脆弱性情報の可視化から対応状況の管理までを一元化できる仕組みです。

このアプリケーションは、システムがビジネスに影響を及ぼす脅威にさらされているかどうかを判断し、脆弱性のある資産に優先順位を付けるという重要な役割を担います。
攻撃対象領域アプリケーション群の一つとして、組織全体のセキュリティ体制の改善と資産の保護に貢献し、①識別、②評価、③対処 という一連のプロセスをシステム上で管理を行い、迅速かつ的確な対応を実現できるアプリケーションです。

VRを使用するにあたっての役割分担

VR機能を使用するにあたって登場する役割は主に3つです。
以下の3つの役割を用いて運用します。

・脆弱性管理者：
VR機能に関する構成を設定変更できます。

・脆弱性アナリスト：
すべての脆弱性の検出結果 (^※脆弱性一致アイテム、修復タスク) を表示して更新し、経時的なリスク対応態勢を監視し、必要に応じて修復オーナーを支援します。

・修復オーナー：
自分のチームに割り当てられた脆弱性の検出結果 (^※脆弱性一致アイテム、修復タスク) の対応に従事します。自分のチームに割り当てられていない修復タスクは、修復オーナーに表示されません。

^※脆弱性一致アイテム、修復タスク：
詳細は「VRを使用した修復対応の流れ」をご確認ください。

VRの大まかな全体像

VRに登場する役割が運用上どの状況で登場するのか、VRの大まかな全体像を説明しながら解説します。

全体像は以下の通りです。

1. 1. 1. Qualys・Tenable・Rapid7・Microsoftなど脆弱性検出に特化したスキャナーから、脆弱性が確認された機器情報とその脆弱性をServiceNowに連携します。
         (脆弱性の“検出”を専門スキャナーが担い、ServiceNow VRは“対応の最適化”を担います。両者を組み合わせることで、実効性のある脆弱性管理を実現します。)
      2. 連携された脆弱性と機器情報を元に、ServiceNowのVRで^※脆弱性一致アイテムを自動的に作成します。
      3. 作成された※脆弱性一致アイテムをグルーピングして、^※修復タスクを作成します。
      4. グルーピングで作成された^※修復タスクを元に修復対応を行います。

①～②では脆弱性管理者がVRの設定変更を行い、③の設定は脆弱性アナリストが対応し、④は主に修復オーナーが実施します。

^※脆弱性一致アイテム、修復タスク：
詳細は「VRを使用した修復対応の流れ」をご確認ください。

VRを使用した修復対応の流れ

VRの役割と大まかな全体像を確認いただいた上で、次にスキャナーから脆弱性情報等をVRに連携した後の修復方法 (①識別、②評価、③対処) の流れをご説明します。

①識別

構成アイテム(対象の機器)に脆弱性があるかどうかスキャナーで判断し、
脆弱性があると判断されたものは、VRで構成アイテムと脆弱性をまとめた
脆弱性一致アイテムを作ります。

②評価

作成された脆弱性一致アイテムの詳細を効率よく調べるために、
脆弱性一致アイテムをグループ化させて修復タスクを作成します。
(グループ化の例として、構成アイテム単位でグループ化などがあります)

※グループ化は修復タスクルールを使用して自動で行うのが最も簡単ですが、手動でも可能です。

③対処

修復タスクのステータスに沿って脆弱性一致アイテムを対処します。

修復タスクの主なステータスは以下の通りです。

オープン：
修復タスクが新規作成された際の最初のステータスです。
修復タスクに含まれる脆弱性一致アイテムの詳細確認を行うことで、
修復作業を行うかどうかの判断をします。

調査中：
修復対象と判断された場合、具体的にどのように修復作業を行うかの調査を実施します。

実装待ち：
調査結果を元に、修復作業(アプリケーションの設定変更、パッチ当てなど)を行います。

解決済み：
修復作業が完了した場合、この[解決済み]のステータスに遷移します。

クローズ済み：
定期的にスキャナーと連携を行い、スキャナーが[解決済み]のステータスである
修復タスクを確認し、問題ない場合[クローズ済み]にステータスを遷移します。

VRを使用した修復対応の詳細

以下の表を用いて、今までご説明したVRの役割、VRの大まかな全体像、VRを使用した修復対応の流れをまとめながら、全体の流れをより詳細にご説明します。

1. 1. 1. 脆弱性検知に特化したスキャナーで脆弱性を検知します。
      2. 検知した脆弱性とそれに関する構成情報を定期的にServiceNowへ連携します。
      3. ServiceNowで脆弱性一致アイテムを自動作成します。
      4. グループ単位の基準やアサイン先の有無などを元に修復タスクルールを使用して脆弱性アイテムのグループ化を行います。
      5. アサインされた修復オーナーが修復タスクを使用して調査を実施します。
      6. 修復タスクの進捗状況を更新し、実機での修復作業(パッチ当て、アプリケーションの設定変更等)を開始します。
      7. 実機での修復作業完了後、修復タスクの進捗状況を更新します。
      8. 再度スキャナーで脆弱性スキャンを行い、脆弱性が解消されたことを確認します。
      9. スキャナーによる脆弱性一致アイテムクローズ後、ServiceNowへ連携を行い脆弱性一致アイテム、修復タスクをクローズします。

②～⑨では、脆弱性アナリストはダッシュボード等で経時的な脆弱性の状態を監視します。

おわりに

本記事では、ServiceNowのVulnerability Responseについて、学習中の方や導入を担う方向けに、主要な用語と全体構造を整理しました。

VRは、脆弱性情報を単に取り込むための機能ではなく、
脆弱性一致アイテムを起点に、修復タスクへとつながる一連のレコード構造によって、脆弱性対応を業務プロセスとして管理する仕組みです。

各レコードの役割や関係性を理解しておくことで、
実装時に「どこが自動で、どこを設計すべきか」を判断しやすくなります。

今後、より詳細な設定や運用設計に進む際には、
本記事で整理した用語や構造を前提知識として活用していただければ幸いです。