セキュリティインシデント対応計画の作り方：初動・連絡・記録の確認票

セキュリティインシデント対応計画は、検知と連絡から、被害拡大の防止、調査と記録、復旧、振り返りまでの役割と手順を定めるものです。この記事では、そのうち異常に気付いた直後の判断・連絡・記録と、専門家や復旧の担当へ引き継ぐための準備を扱います。

監視ツールの通知や従業員からの申告は、調査の入口です。その時点では攻撃や情報漏えいが確定したわけではなく、誤検知の場合もあります。ただし、断定できないことを連絡しない理由にはしません。何が分かっていて何が未確認かを添えて、決めておいた責任者へ伝えます。

通常のシステム障害と、セキュリティ侵害の疑いがある事象では、初動の進め方が異なります。例えば、身に覚えのないサインインや権限の変更、大量のデータの持ち出し、ファイルの暗号化が見られる場合は、障害の復旧作業だけを進めず、責任者と専門家へつなぎます。そのための基準をあらかじめ決めておきます。

初動は、確認がすべて終わってから次へ進む一本道ではありません。JPCERT/CCのマニュアルも、対応の計画・実施と並行して、必要に応じて報告や情報公開を検討する流れを示しています（インシデントハンドリングマニュアル）。原因の特定を待たずに、連絡、影響の確認、被害拡大の防止、記録、法務との調整を並行して進められるよう、担当と判断の範囲を決めておきます。

まず、初動で誰が何を判断し、誰が作業するかを決めます。役割の数と人数は別で、少人数なら兼務しても構いません。CSIRTという名前の専任部署がなくても、次の役割の担当と代理を決めておけば始められます。

表は横にスクロールできます →

主担当が不在のときに、代理がどこまで判断できるか、誰に判断を上げるかを決めておきます。保守先や専門事業者が、時間外でも対応できるとは限りません。契約で受け付けている時間と範囲、作業に必要な社内の許可、作業の記録の受け取り方を確認し、契約外のときにどう依頼するかも決めておきます。

普段使っているメールやチャットが使えない場合や、アカウントが乗っ取られている可能性がある場合も想定します。電話など別の経路で本人に確認する方法と、社内のシステムに入れなくても見られる連絡先の控えを決めておきます。社内の連絡先は、公開されるページや外部のフォームには書き込まないようにします。

異常に気付いたときに確認する場面を、6つに整理します。これは順番に完了を待つ手順ではなく、場面ごとに事前に決めておく判断の例です。担当の権限と業務への影響を確かめながら、必要な連絡や被害拡大の防止を並行して進めます。

表は横にスクロールできます →

人の安全や、止められない重要な業務も判断に含めます。NISTのSP800-61 Rev.3も、報告を受けた事象をまず確認して優先度を判断し、必要に応じて判断を上げることを、対応の管理として扱っています（NIST SP800-61 Rev.3 RS.MA）。

被害拡大を防ぐ操作は、影響と権限を確かめてから判断します。すべての端末の電源を切る、再起動や初期化をする、全アカウントを止める、全員のパスワードを一律に変える、といった操作を無条件に行うと、調査に必要な記録が失われたり、業務が必要以上に止まったりする場合があります。IPAの手引きも、電源を切るなどの不用意な操作で記録を消さないよう注意を促しています（中小企業のためのセキュリティインシデント対応の手引き）。どこまで操作するかは、保守先や専門家と相談して決めます。

侵入口や被害が広がる要因の捉え方は情報漏洩の原因と侵入経路で、アカウントを止めたり権限を見直したりする平時の運用はSaaSアカウント管理の実務で扱っています。

次の表は、初動対応の記録の8項目と記入例です。例は「INC-001：共有SaaSで異常なサインインと大量ダウンロードの通知を受けた」場面で、状態は「確認・連絡中」です。時刻は説明のための仮の経過です。

表は横にスクロールできます →

この例では、通知が届いたことと、アカウントが侵害されたこと・情報が漏えいしたことを区別して書いています。1つのアカウントで通知を確認できたことは、影響の範囲が確定したことや、被害の拡大を止められたことを意味しません。セッションの無効化も、実施して結果を確かめるまでは「予定」として残し、後から事実と異なる時刻や承認を書き足しません。

記録には、調査で分かった弱点や関係者の行動など、慎重に扱う情報が含まれます。様式をそろえるだけでは記録は守られないため、読める人を限り、保管の方法と取得の経緯を残します。NISTのSP800-61 Rev.3も、対応中の記録とインシデントのデータについて、完全性と来歴を保ち、権限のある人だけが参照できるようにすることを示しています（NIST SP800-61 Rev.3 RS.AN-06・RS.AN-07）。

社外とのやり取りには、性質の異なるものがあります。技術的な支援の相談、法令や契約にもとづく報告と本人への通知、一般への公表です。判断する人と時期が異なるため、担当を分けておきます。NISTのSP800-61 Rev.3も、社内外の関係者との連携を、法令・規制・方針に沿って行う対応の一部として扱っています（RS.CO）。

• 技術的な相談：保守先や専門事業者、JPCERT/CCなどへの相談です。JPCERT/CCは、被害を受けた組織に加えて、調査を支援するベンダーやシステムの運用会社からの相談も受け付けています。一方で、暗号化されたファイルの復号やシステムの復旧作業の支援までは行っていないと案内しています（インシデント相談・情報提供）。相談したことで、法令上の報告や本人への通知が終わるわけではありません。
• 法令・契約上の報告と通知：個人情報の漏えい等には、報告が必要となる要件と期限が定められています（個人情報保護委員会：漏えい等の対応とお役立ち資料）。すべての不審な通知で報告が必要になるわけではありませんが、原因がすべて分かるまで検討を待つのではなく、本人への通知の要否も含めて、担当者や法務が早い段階で要件に当たるかを確かめます。取引先との契約に報告の定めがある場合も確認します。
• 一般への公表：影響を受ける人に個別に知らせることが難しい場合などに検討します。公表の時期や内容によって被害が広がらないよう、責任者・法務・対外説明の担当で判断します（IPAの手引き）。

外部に渡す情報は、確認済みの事実、影響と未確認の点、実施した対応、担当者と折り返し先、保護した記録の所在などです。ログや個人情報は、そのまま送らずに、相手、経路、必要な範囲、取り扱いの条件を確かめてから渡します。

バックアップから復元できたことと、安全に業務を再開できることは別の判断です。再開の前に、次の点を誰が確かめるかを決めておきます。

• 影響の範囲が分かっているか、未確認の点は何か
• 侵入に使われた経路や認証情報への対応が済んでいるか
• 復元に使うバックアップと、復旧先の環境が信頼できるか
• 再開に必要な権限があり、主要な業務が正しく動くか
• 再接続した後の監視と、再発したときに誰が判断するか

NISTのSP800-61 Rev.3も、復元に使う前に、バックアップなどの資産の健全性を確かめることや、復元したシステムで業務の正常な状態を確認することを示しています（NIST SP800-61 Rev.3 RC.RP）。バックアップがあるからといって、すぐに戻せばよいわけではありません。

すべてのシステムを一度に元へ戻すことを目標にせず、重要な業務に絞って再開する、代替の手段で続ける、再開を保留する、といった判断も含めます。バックアップから必要な状態に戻せるかを平時に確かめる方法はバックアップ復元テストの進め方で、どの業務をどの水準で続け、いつ再開するかはBCPとDRの違い・策定の進め方で扱っています。

計画に書いてあることと、実際にできることは違う場合があります。机上訓練では、想定の場面を順に示し、参加者が誰に連絡し、何を判断し、何を記録するかを話し合います。実際のアカウントの制限や社外への連絡は行いません。

次は、INC-001に状況を3つ順に加える訓練の例です。

訓練の後は、計画の記載と、実際に連絡・判断できたことの違いを確かめます。代理の権限が決まっていない、連絡先の控えが古い、保守先の契約に時間外の受付がない、といった不足が見つかれば、計画を直す担当と期限を決めます。予防と運用の対策の見直しは中小企業のランサムウェア対策で扱っています。

計画を見直すときに、次の項目を確認します。