セキュリティインシデントで最も難しい部分は、通常、インシデント自体が終わった後に訪れます。ビジネスが、何が起こったのか、いつ発見されたのか、どのデータが関与していたのか、誰が影響を受けたのか、なぜ特定の決定がなされたのかを説明しなければならなくなる時です。
多くの中小企業では、これらの記録は完全な形では存在しません。詳細は、チャットメッセージ、受信トレイ、ヘルプデスクのチケット、スクリーンショット、そしてチームメンバーの記憶の中に散らばっている可能性があります。ビジネスはインシデント中、こうした継ぎ接ぎの記録で何とか持ちこたえますが、監督当局、保険会社、顧客、あるいは役員が明確なタイムラインを求めた時点で問題になります。
あらゆる規模のビジネスに、徹底したセキュリティインシデントログが必要です。何が起こったのか、インシデントがどのように対応されたのか、そして途中でなされた決定を裏付ける証拠は何かを記録する、信頼できる唯一の情報源となるべきです。
インシデントを報告する必要がない場合でも、記録は価値があります。セキュリティインシデントログがビジネスにどのように役立つのか、そして独自のログを作成する方法を説明します。
セキュリティインシデントログが重要な理由
セキュリティインシデントログは、ビジネスが詳細を見失う可能性が最も高い時に説明責任を生み出します。インシデントの間、行動は迅速に起こります。パスワードがリセットされ、アカウントが無効化され、ITプロバイダーに連絡が取られ、顧客データが確認され、経営陣に概要が説明されます。これらのステップは、その瞬間にビジネスが必要とするものかもしれませんが、各行動がいつ起こったのか、誰が承認したのか、どの証拠が決定を裏付けたのかを誰も記録しなければ、後で説明するのがずっと難しくなります。
ヨーロッパに拠点を置くビジネスにとって、これは単なる優れた慣行ではありません。英国とEUの両方で、一般データ保護規則（GDPR）に基づき、個人データ侵害を評価する必要があり、一部は対応する監督当局に報告しなければなりません。
英国では、ICOの侵害の報告(新しいウィンドウ)に関するガイダンスが、組織は人々の権利と自由に対する起こり得るリスクを評価し、そのリスクが高い場合にはICOに通知しなければならないと説明しています。第33条はまた、管理者に対し、侵害の事実、その影響、講じられた是正措置を含む個人データ侵害を文書化することを求めています。同じ要件がEU GDPRの下でも適用されます。
たとえば、ICOはすべての中小企業がエンタープライズ級のシステムを持つことを期待しているわけではありませんが、適切な記録は期待しています。ICOの侵害対応と監視のフレームワークでは、組織は個人データのインシデントや侵害が検知され、管理され、適切に記録されることを確実にするための手順を備えるべきだと述べています。つまり、インシデントログは重大な侵害がすでに発生した場合にのみ作成されるべきではありません。通常の対応プロセスの一部であるべきです。
適切な記録は保険金請求もサポートします。サイバー保険会社は、インシデントがいつ発見されたか、どのような封じ込め措置が取られたか、どのアカウントが影響を受けたか、ビジネスがインシデント対応プロセスに従ったかどうかの証拠を求めることがあります。適切に維持されたログは、ビジネスが迅速かつ一貫して行動したことを示すことができます。
また、会社が学ぶのにも役立ちます。記憶や口頭の記録は信頼できませんが、インシデントがパスワードの再利用、多要素認証（MFA）の欠如、ベンダーアクセス、または遅延したオフボーディングから始まったことを示す記録は、ビジネスに修正すべき具体的なものと、時間をかけてセキュリティを強化するためのより明確な方向性を与えます。
インシデントログとインシデント対応計画
セキュリティインシデントログとインシデント対応計画は関連していますが、同じ文書ではありません。
インシデント対応計画は、何か問題が発生したときにビジネスが何をすべきかを説明します。役割、エスカレーション経路、封じ込め手順、コミュニケーションの責任、復旧手順を割り当てます。インシデントログは、実際に何が起こったかを記録します。特定のインシデントに関するタイムライン、証拠の記録、決定の記録、フォローアップファイルです。
この区別は重要です。なぜなら、優れた計画であっても文書化がなければ失敗する可能性があるからです。ビジネスが正しい手順を踏んでも、後でそれを証明するのに苦労することがあります。ログは、実用的な質問に答えることを可能にするべきです。いつ知ったのか、誰が行動したのか、何を封じ込めたのか、どのデータが危険にさらされたのか、何を決定したのか、その後何が変わったのか。
| インシデント対応計画：ビジネスが取るべき行動 | セキュリティインシデントログ：実際に起きたこと |
| 誰が対応を主導するか 誰がIT、法務、保険会社、規制当局に連絡するか 封じ込め、復旧、コミュニケーションの方法 | インシデントがいつ発見されたか どのシステムとデータが影響を受けたか どのような行動が、誰によって、いつ取られたか |
セキュリティインシデントログに含めるべき内容
有用なインシデントログは、ビジネスが後でインシデントを再構築し、対応中になされた決定を説明できる程度に一貫している必要があります。
発見日時
ビジネスがインシデントを最初に認識した時期、誰が気づいたか、どのように発見されたかを記録します。時刻がおおよその場合は、おおよそであるとマークします。発見時刻は重要です。なぜなら、GDPRの報告期限や保険要件は、ビジネスが問題を認識した時期に依存することが多いからです。
インシデントの性質
何が起こったかを平易な言葉で説明します。”セキュリティ問題”や”侵害の可能性”といった曖昧なラベルを、文脈なしで使用することは避けてください。ログは、どのシステムが影響を受けたか、インシデントに認証情報、メール、ファイル、顧客データ、決済システム、エンドポイント、サードパーティアクセスが関係していたかを説明するべきです。
関与したデータ
個人データが影響を受けた可能性がある場合は、どのような種類のデータが関与したかを記録します。氏名、メールアドレス、電話番号、住所、アカウント詳細、財務情報、従業員記録、顧客との通信、ログイン認証情報、その他の関連カテゴリです。影響を受ける可能性のある個人の数を推定し、その数が確認済みか、まだ調査中かを明確にします。
考えられる原因
調査がまだ進行中であっても、既知または疑わしい原因を記録します。新しい詳細が明らかになるにつれて、ログは”原因不明”から”フィッシングメールが認証情報の侵害につながった”または”元請負業者のアカウントがアクティブなままだった”に更新できます。ログは、ビジネスの理解が時間とともにどのように変化したかを示すべきです。
即時の封じ込め措置
被害を限定するために何が行われたかを文書化します。これには、パスワードのリセット、セッションの失効、MFAの強制、アカウントの停止、メールボックスルールの削除、デバイスの隔離、ベンダーアクセスの削除、ファイアウォールの変更、一時的なサービス停止などが含まれます。可能な場合は、各アクションの担当者とタイムスタンプを含めます。
通知の決定
ビジネスが関連する監督当局（英国ではICO、EUの他の国では国内のデータ保護機関）、影響を受けた個人、顧客、サプライヤー、保険会社、法律顧問、法執行機関に通知したかどうかを記録します。通知しない決定だった場合は、その理由を文書化します。その説明は、通知自体と同じくらい重要なことがよくあります。
是正措置とタイムライン
封じ込めは目の前のインシデントに対処します。是正措置は、同じ問題が再発する可能性を減らします。MFAの強制、共有認証情報の削除、アクセスポリシーの更新、オフボーディングの改善、設定ミスの修正、バックアップの保護方法の変更などのフォローアップアクションを記録します。
得られた教訓
ビジネスが学んだことと、何が変わるかで締めくくります。これは非難として書かれるべきではありません。弱点、必要な改善、フォローアップの責任者を特定するべきです。
中小企業向けのシンプルなインシデントログテンプレート
インシデントを文書化するのに専門的なソフトウェアは必要ありません。スプレッドシート、安全な社内フォーム、チケットシステム、共有レジスターは、アクセスが制御され、記録が一貫して維持されていれば機能します。
効果的なインシデントログには、以下のフィールドを含めるべきです：
- インシデントID：一意の参照番号。
- 発見日時：ビジネスがインシデントを認識した時期。
- 報告元: 従業員、プロバイダー、顧客、ベンダー、監視アラート、外部関係者。
- インシデントの種類: フィッシング、マルウェア、認証情報の侵害、データ損失、不正アクセス、ランサムウェア、サプライヤーインシデント、デバイス損失、誤送信メール、その他。
- 概要: 何が起きたかを平易な言葉で記載します。
- 影響を受けたシステム: 関与したアプリ、アカウント、デバイス、データベース、受信トレイ、サードパーティサービス。
- 関与したデータ: 個人データが影響を受けたかどうか、その種類、影響を受ける可能性のある人数。
- 推定原因: 判明済み、疑いあり、調査中。
- 封じ込め措置: 直ちに実施したこと。
- 通知の判断: 監督機関、個人、顧客、保険会社、または通知しない場合はその理由。
- 証拠リンク: スクリーンショット、チケット、ログ、メール、アクセス記録、エクスポートファイル、プロバイダー報告書。
- 修復措置: 封じ込め後に実施した手順。
- 担当者: フォローアップの責任者。
- ステータス: 未対応、監視中、封じ込め済み、解決済み、クローズ。
- 教訓: 変更すべき点。
通知の判断を記録する方法
通知の判断は、インシデント後に見直されることが多いため、セキュリティインシデントログに専用の項目を設けるべきです。
英国とEUのGDPRでは、個人データ侵害が発生した場合、組織は人々の権利と自由に対する起こり得るリスクを評価する必要があります。リスクが生じる可能性が高い場合は、監督機関、つまり英国ではICO(新しいウィンドウ)、各EU加盟国では各国のデータ保護機関に、可能な限り速やかに、実行可能な場合は72時間以内に通知する必要があります。リスクが高い場合は、影響を受ける個人にも不当な遅延なく通知する必要があります。基準と期限は英国とEUで同じで、異なるのは通知先の機関だけです。
優れたインシデントログは、事業者がこの評価を行ったことを示す必要があります。個人データが関与したかどうか、どのような危害が生じ得るか、どのような保護策が講じられていたか、そして報告するか報告しないかを事業者がなぜ判断したかを記録すべきです。
たとえば、管理者パスワードが露出したインシデントでは、個人データにアクセスされたかどうかがすぐに判明するとは限りません。ログには、その不確実性を反映させる必要があります。初期の懸念、調査手順、アカウントアクティビティの確認、証拠が揃った時点での最終結論を記録できます。
プロセスのこの段階では、多くの事業者が技術的な修正の整理に集中し、コンプライアンス上の判断理由を記録するのを忘れてしまいます。パスワードはリセットされ、アカウントは保護され、業務は続行されます。数週間後、その事業者は、なぜそのインシデントを報告不要と判断したのか説明できなくなります。
監督機関が記録に求めるもの
監督機関は、侵害が報告されたかどうかだけを見ているわけではありません。また、事業者が次の点をどのように行ったかを尋ねることもあります。
- インシデントを特定した
- リスクを評価した
- 通知が必要かどうかを判断した
- 実施した措置を文書化した
優れた記録は、インシデントの経緯を最初から最後まで明確に示す必要があります。何が起きたか、どの個人データが関与したか、どのような危害が生じ得るか、問題を封じ込めるために事業者が何を行ったか、そしてなぜ侵害を報告したか、または報告しなかったかを示すべきです。
詳細のレベルは、インシデントの深刻さに見合ったものであるべきです。誤送信メールには、ランサムウェア攻撃と同じ記録は必要ありませんが、事業者が適切に評価したことを示すために、依然として文書化する必要があります。
これらの記録は安全に保管する必要もあります。インシデントログには、影響を受けた個人、露出したシステム、従業員の行動、スクリーンショット、アクセスログ、修復手順に関する機密性の高い詳細が含まれる場合があります。アクセスは必要な人だけに限定し、保持期間は会社のより広範なデータ保持ポリシーに合わせる必要があります。
認証情報アクセスログ
多くのインシデントには認証情報が関与します。きっかけは、パスワードの使い回し、共有アカウント、侵害された受信トレイ、露出した管理者ログイン、不審なMFAプロンプト、または適切に退職処理されなかった従業員などです。
そのため、認証情報アクセス記録は、サイバーセキュリティインシデントの文書化に直接的な入力情報となり得ます。インシデントに共有ログインや機密性の高いアカウントが関与する場合、事業者は、誰がアクセスできたか、どのようにアクセスが共有されたか、権限が変更されたか、インシデント後に認証情報がローテーションされたかどうかを把握する必要があります。
Proton Pass for Businessのようなビジネス向けパスワードマネージャーは、チームが暗号化された保管庫で認証情報を管理し、一意のパスワードを生成し、自動入力を使用し、認証情報を安全に共有し、パスキーを管理し、組み込みの2要素認証を使用するのに役立ちます。インシデントの文書化において最も価値が高いのは、認証情報に関するアクセス履歴です。誰が共有保管庫やアカウントにアクセスできたか、アクセスがどのように管理され、誰が使用したか、インシデント後に何が変更されたかです。
ITチーム向けパスワードマネージャーは、ポリシー、レポート、ログ、役割ベースのアクセス制御、SCIMプロビジョニング、SSO連携などの管理者機能を追加します。これらの機能は、事業者が認証情報へのアクセスがどのように制御されているかを示し、認証情報関連のインシデントが調査される際の証拠を提供するのに役立ちます。
パスワードマネージャーは、インシデントログ、法的評価、規制上の通知プロセス、インシデント対応計画の代わりにはなりません。ただし、それらのプロセスに活用できる認証情報の証拠を提供します。
ビジネス向けパスワードマネージャーで、認証情報へのアクセスの完全な監査証跡を保持しましょう。
