セキュリティ

緊急の脆弱性が公表されたとき、最初の48時間に何をするか

重大な脆弱性が公表されたとき、対応の速さを決めるのは技術力よりも事前の準備です。どこで何が動いているか即答できるか、誰がサービス停止を判断するか、この2つが決まっていない組織は、最初の数時間を調整に使ってしまいます。この記事では、公表から収束までの初動を時系列で整理します。

なぜ初動で差がつくのか

脆弱性そのものは、利用者側では防げません。使っているソフトウェアに問題が見つかれば、どれだけ丁寧に作っていても影響を受けます。差がつくのは、公表されてから動き出すまでの時間です。

重大な脆弱性では、修正版が公開された直後から攻撃が本格化します。修正の内容が公開されれば、そこから攻撃手法を組み立てられるためです。パッチ公開の前から攻撃が始まることも珍しくありません。

つまり、猶予は「修正版が出てから」ではなく「公表が予告されてから」始まっています。この数時間から数十時間をどう使うかで、結果が変わります。

平時にやっておくこと

初動を速くする準備は、インシデントが起きてからでは間に合いません。次の3つを平時に揃えます。

• 資産の一覧／公開しているサーバー、使っているミドルウェアとそのバージョン、SaaS、レンタルサーバーの契約。「どこで何のバージョンが動いているか」を見れば分かる状態にしておく
• 判断の権限と基準／サービスを止める判断を誰が下すか。どの条件なら止めるか。当日に決めようとすると、関係者を集めるだけで半日を使う
• 連絡と作業の経路／夜間・休日に誰へ連絡し、誰が作業できるか。外部ベンダーに依頼している場合は、緊急時の連絡先と対応時間を確認しておく

一覧は完璧である必要はありません。「対象かどうかを30分で判断できる」程度の粒度があれば十分に機能します。

公表直後：影響があるかを確定させる

最初にやるのは対策ではなく、影響範囲の確定です。ここを飛ばすと、必要のない停止をしたり、逆に対象を見落としたりします。

1. 何が対象かを一次情報で確認する。対象の製品、バージョンの範囲、影響する構成を、開発元の発表とIPA・JPCERT/CCの注意喚起で押さえる。SNSの情報は精度が安定しない
2. 自社の該当資産を洗い出す。一覧と突き合わせ、対象・非対象・不明の3つに分ける
3. 「不明」を優先して潰す。対象と分かっているものより、分からないものが危ない
4. 攻撃の難易度を確認する。認証が必要か、特定の設定でのみ成立するか。ここで優先順位が決まる

並行して、経営層への第一報を入れます。この時点で分かっていることと分かっていないことを分けて伝えれば十分です。全容が見えてから報告しようとすると、判断が必要な場面で経営層が状況を知らない状態になります。

パッチが出るまでの暫定対応

修正版がまだない、あるいはすぐには当てられない場合、取りうる手段は限られます。いずれも時間稼ぎであり、恒久対策ではないことを前提に選びます。

• 該当機能の停止／脆弱性が特定の機能に依存している場合、その機能だけ止める。影響が小さく効果が確実
• 設定による回避／開発元が回避策を示していれば適用する。ただし「この設定で防げる」と明示されたものに限る。推測での設定変更は、別の問題を生む
• WAFによる遮断／攻撃パターンが分かっていれば有効。ただしDNSをWAF経由にしているか、検知のみでなく遮断の設定になっているかの確認が必要
• サービスの一時停止／最後の手段。影響が大きいが、判断としては正しい場面がある。攻撃が本格化する前に止めるのは「過剰反応」ではない

暫定対応を入れたら、いつ外すかをその場で決めます。恒久対策が終わったあとも暫定設定が残り、数年後に原因不明の不具合として現れることがあります。

適用後：侵害されていないかを確認する

パッチを当てて終わりではありません。当てる前に侵入されていた可能性が残ります。最低限、次の3点を見ます。

• ログ／公表前後の期間で、不自然なリクエストが集中していないか。該当の脆弱性が使う経路に絞って見ると判断しやすい
• ファイル／身に覚えのないファイルが置かれていないか。更新日時が不自然なものも含めて見る
• アカウントと権限／作った覚えのない管理者アカウント、権限が変わっているアカウントがないか

侵入の痕跡が見つかった場合、その場で消さないことが重要です。証拠が消えると、どこまで影響したかを後から追えなくなります。切り離して保全し、専門の支援を受ける判断に切り替えます。

※ ログに何も出ていない、エラー画面が出ていない、という状態は「安全である」ことの証明にはなりません。

社外への説明

顧客や取引先への説明は、技術的な正確さよりも何が決まっていて何が未定かが伝わることが大事です。

• サービスを止める場合／止める範囲、開始と終了の見込み、再開時に追って連絡すること。理由は「セキュリティ上の予防措置」で足りる場面が多い
• 影響が確認できていない段階／調査中であることと、次にいつ知らせるかを明示する。「調査中」だけで続報の予定がないと、問い合わせが増える
• 影響が確認された場合／何が漏れた可能性があるか、利用者側で必要な対応があるか。法令上の報告義務が発生する場合もあるため、法務と並行で動く

告知の文面は平時に型を作っておくと、当日の負荷が大きく下がります。

次に備える

対応が終わったら、記憶が新しいうちに3つだけ記録します。

1. 何に時間がかかったか。影響判断か、承認か、作業そのものか
2. どの情報が足りなかったか。資産一覧の粒度、連絡先、権限
3. 次に同じことが起きたら、どこを変えるか。1つか2つに絞る

完璧な体制を一度に作る必要はありません。毎回ひとつずつ短くしていけば、数回で初動は実用的な速さになります。