毎年、脆弱性報告件数が増加して、かつ脆弱性公表から攻撃発生までの時間が短くなってきています。米国NISTの脆弱性情報データベースNational Vulnerability Database（NVD）の集計情報によると、2017年から脆弱性件数が急激に増加しており、2020年には18,000件以上に達しています（図1）（※1）。また米情報機関NSAのDave Hogue氏によると、「国家主導の攻撃者は、脆弱性情報の公開後、一日足らずで脆弱性を悪用できる状態になる」と述べています。（※2）
現場担当者の脆弱性情報の入手が遅れると、パッチ適用などの対策が間に合わず、攻撃されて被害が発生するリスクが高まります。現場が対策を適時に実施できるためには、CSIRT要員が限られたリソースで、できるだけ効率的に脆弱性対応を行い、迅速に脆弱性情報を現場に届ける必要があります。

図1：NVDへ登録された脆弱性件数

増え続ける脆弱性への対応を、どのようにすれば迅速化できるでしょうか。脆弱性対応をいかに自動化、省力化できるかがカギとなります。NTTDATA-CERTは、主要な製品の脆弱性情報を日々収集して危険度を判断し、その結果に応じて、NTTデータ全社とグループ会社へ脆弱性情報の周知や対応指示を行っています。しかしこれらの作業を手動で行うのは限界があります。例えば、監視対象の製品や一度に公開される脆弱性情報の数が多く、収集や危険度の判断に時間が掛かります。また脆弱性の危険度を表現するスコア「CVSS（※3）Base値」だけでは、脆弱性の危険度を正確に判断できません。値が大きい脆弱性が、必ずしも自社の環境で悪用しやすいとは限りません。その逆も然りです。
そこでNTTDATA-CERTは、情報収集と危険度判断の前処理の自動化と独自の危険度判断ロジックを導入して、これらの課題を解決しました。ただし危険度判断を完全に自動化することは、現時点では不可能です。危険度判断のうちの前半の処理を自動化しました。複雑な推論や危険度判断は、脆弱性対応専門のNTTDATA-CERTメンバが行います。
以下の方法を用いて図2に示すVulnerability Handling System（VHS）を構築しました。

1. 脆弱性情報の自動収集

有料の脆弱性情報提供データベースと製品ベンダのRSSから提供される最新の脆弱性情報を24時間365日、収集します。有料の脆弱性情報提供データベースの情報配信は、製品ベンダの情報配信よりも遅延するため、重要な製品の脆弱性情報は製品ベンダの公式サイトのRSSから収集します。収集した情報は、ログ分析プラットフォームSplunkへ集約します。

2. 独自の危険度判断ロジックによる自動処理と自動通知

CVSS Base値だけでなく、CVSSのパラメータの一部も使って、危険度の高い脆弱性だけを自動的に抽出します。抽出した危険な脆弱性は、SplunkからWebhookを用いてMicrosoft Teamsへ自動的に通知します。この自動処理の結果、NTTDATA-CERTメンバが危険度判断する脆弱性の数を5分の1へ削減できます。

3. クラウドを用いた安定稼働

脆弱性情報は日本国外の地域で公開されます。時差を考慮して、AWS上へ24時間365日安定稼働するシステムを構築しました。

図2：Vulnerability Handling System（VHS）

脆弱性対応専門のNTTDATA-CERTメンバによる危険度判断では、攻撃転用可能な脆弱性実証用コード（PoC：Proof of Concept）の有無、攻撃発生の有無、脆弱性が悪用された場合の当社環境への攻撃の有効性などを中心に評価しています。この危険度判断の結果に応じて、社内Webサイトへ必読周知、全社員へ周知や対応依頼、チケット管理システムを使った期限付きの対応指示を使い分けて実施します。
VHSの導入で、NTTDATA-CERTは脆弱性の情報収集、判定に必要な作業時間を約95％削減し、周知までの迅速化に成功しました。脆弱性周知を迅速に行えるようになると、被害が拡大、顕在化してからインシデント対応がはじまるのではなく、まだ被害が顕在化していない侵害初期で早期発見、早期対応できるようになります。次章は当社でこうした対応に成功した実例を紹介します。

当社の脆弱性対応がきっかけとなって攻撃を発見して被害を最小化できた実例を紹介します。
2020年7月1日にF5社はBIG-IP製品の脆弱性CVE-2020-5902（以下、「本脆弱性」とする）を公表しました。インターネットからBIG-IPの管理ページTraffic Management User Interface（TMUI）にアクセスできる場合、攻撃者は、本脆弱性を悪用して任意のコードを実行できます。その結果、攻撃者がバックドアを作成して継続的に不正アクセスを行ったり、BIG-IPを内部ネットワークへの侵入の踏み台に悪用したりするなどの攻撃の影響が想定されます。

1. 脆弱性情報の周知、対応指示

本脆弱性の当社対応のタイムラインを表に示します。正確な日付は伏せますが、表の7月x日、NTTDATA-CERTは本脆弱性の情報を入手し、対応を開始しました。本脆弱性のCVSS Base値は9.8（AV：N、AC：L、PR：N、UI：N、C：H、I：H、A：H）ですが、TMUIの管理画面をインターネット公開していない場合、本脆弱性の影響は受けません。脆弱性対応専門のNTTDATA-CERTメンバの危険度判断の結果、通常の環境では管理画面をインターネット公開しているケースは稀であると判断して、全社/グループ会社向けの社内サイトへ必読の注意喚起記事を掲載しました。
同月x+3日9：32、周知を確認した当社のグループ会社A社から、当該脆弱性の影響を受けるBIG-IPがあるとの通報がありました。同日11：40、NTTDATA-CERTはA社のBIG-IPのTMUIを遮断するよう指示し、12：32にA社担当者がTMUIを遮断しました。

2. BIG IPへの侵入

しかし、攻撃者はTMUI遮断2日前のx＋1日23：08、当該脆弱性を悪用してTMUI経由でBIG-IPに侵入（図3：A）、不審なユーザ「systems」を作成していました。またA社管理者がx+3日 12：32にTMUIを遮断しましたが、TMUIが使えなくなったことに気づいた攻撃者が、遮断直後の12：33にインターネットからBIG-IPへ侵入するためにTMUIの代わりのバックドア（1）を設置しています（図3：B）。
攻撃者がTMUIの遮断前にBIG IPに侵入し、BIG-IPと攻撃者のネットワーク接続が確立され続けている場合、TMUIを遮断するだけでは攻撃者を完全に追い出すことはできません。またいったんバックドアを設置されてしまうと、TMUIの脆弱性を解消してもBIG IPに侵入されてしまいます（図3：C）。この場合、完全な対策にはTMUIの遮断に加えてBIG IPのネットワーク接続をリセットして攻撃者を追い出した上で、攻撃者が設置したバックドアを除去してTMUI以外の侵入経路も封じるか、またはBIG IPの全通信を物理的に遮断する必要があります。
攻撃者はBIG-IPの管理者が脆弱性対応を開始したことに気づき、以前に作成した不正なユーザ2つが発見されて無効化される場合に備えて、同日12：45に新たに不審なユーザ「f5admin」を作成しました。そこから12：57までの30分間にわたって、/usr/bin/diskmonitorの改ざん、追加のバックドア（2）の作成、などの不正なコマンドを実行しています。

図3：A社への攻撃の流れ

3. インシデントレスポンスの実施

攻撃者の不正なコマンド実行と同時間帯のx+3日14：00、NTTDATA-CERTはA社からBIG-IPのログを受領し、調査を実施しました。その結果、同日16：18に侵害の痕跡を発見し、18：00にA社へBIG-IPの全通信の物理遮断を指示、20：00にA社担当者がBIG-IPからすべての通信ケーブルを抜線しました。翌日x＋4日から、NTTDATA-CERTはBIG-IP本体を受領して詳細なフォレンジック調査を開始しました。x＋7日には攻撃者の侵害がBIG-IP内で留まっており、内部ネットワークへは広がっていなかったことが判明しました（図3：D）。
本脆弱性の対応が成功したポイントは、必読の注意喚起記事を迅速に掲載して現場がすぐに対応を開始できたこと、情報連携や対応をスムーズに行うことができて侵害システムを早期に特定、遮断を指示できたことです。ただし、NTTDATA-CERTの周知から現場の対応開始までの間に攻撃者がBIG-IPへ侵入してしまいました。もっと早くチケット管理システムを使った期限付きの対応指示を行っていれば、侵入を防げた可能性がありました。現場での製品の利用環境を正確に推測して脆弱性の危険度を判断することは難しく、事前に現場からシステム情報やインベントリ情報を収集し、確実に利用環境を把握して正確な判断ができる仕組みをつくることが理想的です。

表：CVE-2020-5902の当社対応タイムライン

本稿はNTTDATA-CERTの脆弱性対応の迅速化の取り組み、また脆弱性対応がきっかけとなってインシデントレスポンスを実施した例を紹介しました。公開された脆弱性を悪用した攻撃発生までの時間は短く、またゼロディ攻撃も増えていることから、CSIRT要員は迅速に周知、対応指示を行い、現場も周知、指示内容に沿ってしっかりと対策を実施しましょう。