セキュリティインシデントの初動対応｜最初の1時間で情シスが動く順序

セキュリティインシデントは、発生そのものよりも、発生直後の数十分から数時間の対応で被害の大きさと復旧までの時間が決まります。独立行政法人情報処理推進機構(IPA)が示す対応の枠組みでも、検知・報告から体制構築、そして隔離や停止といった初動対応実行までの流れが重視されています。本記事では、情シス担当者が異常を検知した瞬間に何を、どの順序で行うべきかを整理し、判断を誤りやすいポイントとセルフチェックリストを解説します。結論を先に述べると、初動対応の要は「隔離」「証拠保全」「報告ライン」の3つを同時に崩さず進めることにあります。

セキュリティインシデントの対応は、大きく「検知と連絡受付」「対応体制の構築」「初動対応の実行」という3段階で進みます。この最初の段階でつまずくと、原因調査に使えるはずの記録が失われたり、対応方針が定まらないまま被害が拡大したりします。

IPAの手引きでも、対応時の最大の課題として「不用意な操作でシステム上に残された記録を消さないようにすること」が挙げられています。これは、慌てて端末を再起動したり、ログをローテーションさせてしまったりすることで、後の調査に必要な痕跡そのものが消えてしまう問題を指します。

BFTが金融・公共分野で20年以上にわたりシステム運用を担ってきた現場感覚で見ても、深刻化する事案の多くは、発生直後の数十分で「誰が判断し、何から着手するか」が決まらないまま時間が過ぎてしまうケースです。技術的な対応力よりも先に、意思決定の順序を型として持っているかどうかが被害の分かれ目になります。

異常を検知したら、まず「業務影響がどこまで及びうるか」を仮判定し、情報セキュリティ責任者への報告ラインを起動します。この時点では原因の完全な特定を待つ必要はありません。判断基準を事前に決めておき、疑わしい時点で体制を立ち上げることが重要です。

対象端末のネットワークからの切り離し、影響範囲のシステムやサービスの一時停止など、被害の拡大を止める処置を行います。例えば、深夜にランサムウェアへの感染が疑われる端末を検知した場合、まず当該端末をネットワークから物理的に切り離し、同一セグメント内の他端末への感染有無を確認する、という順序になります。この段階で電源を落とすかどうかは調査方針によって判断が分かれるため、後述する証拠保全の観点も踏まえて対応します。

対応した時刻・実施者・操作内容を時系列で記録します。可能であれば画面キャプチャやログの複製を取り、原本を上書きしない形で保全します。この記録は、後の原因調査だけでなく、取引先や監督官庁への説明が必要になった際の根拠にもなります。

• 感染端末を安易に再起動・シャットダウンする: メモリ上に残る攻撃の痕跡(揮発性データ)が失われ、原因調査が困難になります。
• ログを削除・上書きしてしまう: 定期ローテーションの設定によって、対応中に重要なログが自動的に消えるケースがあります。検知後は該当ログの保全設定を確認します。
• 個人の判断で外部への公表や取引先連絡を先行させる: 事実関係が固まる前の発信は、後の訂正対応や信用回復のコストを増やします。窓口と発信内容は事前に決めておくことがおすすめです。

次の5項目のうち3つ以上当てはまる場合、初動対応の体制には見直しの余地があります。

1. インシデント発生時に「誰が第一報を受け、誰が対応方針を決めるか」が文書化されていない。
2. ログの保存期間・保全手順が、インシデント対応の観点で定義されていない。
3. 深夜・休日に異常を検知した場合の連絡フローが決まっていない。
4. 自社だけで対応が難しい場合の外部相談先(専門ベンダー・当局窓口等)が事前に確保されていない。
5. 過去の訓練・演習で、初動対応の手順を実際に動かして検証したことがない。

初動対応は、発生した個々の事案に対する「点」の対応です。しかし、IPAの手引きが指摘するとおり、対応方針と役割分担をあらかじめ定めていない組織は少なくありません。点としての対応力を高めるだけでは、次に別の種類のインシデントが起きたときに同じ課題を繰り返すことになります。

図のように、検知・隔離・報告という初動対応の型を整えることは出発点にすぎません。役割分担の明文化、ログ保全設定の定期点検、訓練による手順の検証といった継続的な取り組みがあって初めて、次のインシデントでも同じ質の初動対応を再現できます。単発の見直しで終わらせず、運用として点検し続ける発想が欠かせません。

[関連記事: クラウドの設定不備を自分で確認する7つのチェック項目と診断の使い分け]

• セキュリティインシデントの被害の大きさは、検知直後の初動対応の巧拙で大きく変わる。
• 初動対応の要は「隔離」「証拠保全」「報告ライン」の3つを同時に崩さず進めることにある。
• 安易な再起動やログの上書きは、原因調査に必要な痕跡を失わせるため避ける。
• セルフチェックで5項目のうち3つ以上当てはまる場合は、体制の見直しが必要なサインである。
• 初動対応は「点」の対応であり、役割分担やログ保全設定の点検を継続する「線」の運用があって初めて機能する。

Q. セキュリティインシデントを検知したら、まず何をすればよいですか。
A. 原因の完全な特定を待たず、影響範囲を仮判定したうえで報告ラインを起動し、対象端末やシステムの隔離・停止に着手します。並行して対応内容を時系列で記録することが重要です。

Q. 感染が疑われる端末は、すぐに電源を切ってよいですか。
A. 揮発性データが失われ原因調査が困難になる場合があるため、安易な再起動・シャットダウンは避け、まずネットワークからの切り離しを優先します。電源操作の要否は調査方針に応じて判断します。

Q. 初動対応の体制は自社だけで整備できますか。
A. 報告ラインや隔離手順の整備は自社で対応できますが、原因調査や高度な対応が必要な場合に備え、外部の専門ベンダーや相談窓口を平時から確保しておくことが望まれます。

初動対応の型を整えたら、次に取り組むべきは自社の設定・体制に潜むリスクを洗い出すことです。まずは自社の課題を整理したい方はSTEADYで全体像を確認し、より詳しくクラウド環境のリスクを点検したい場合はセキュリティ診断、手早く現状を把握したい場合は無料セルフチェックから始めることができます。