セキュリティインシデントの最初の数時間では、何が起きたのか技術的な全体像を把握することはできません。チームはまだ、どのアカウントが侵害されたのか、どのデータがアクセスされたのか、攻撃者がどこまで到達したのか、インシデントがまだ続いているのかを理解しようとしているかもしれません。
調査と並行して、行動を起こすプレッシャーはすぐに始まります。従業員は断片的な情報を聞き、何をすべきかを知る必要があります。一方、顧客はサービス停止、不審なアクティビティ、異常なパスワードリセット要求に気づくかもしれません。ビジネスパートナーは、自社のシステムやデータが関係しているかどうかを尋ねるかもしれません。経営陣は、誰が話すのか、何が確認できるのか、そして沈黙がそれ自体でリスクとなるのはいつなのかを決定する必要があります。
セキュリティインシデントのコミュニケーションが難しいのは、企業がすべての答えを得る前に透明性を保ちつつ、推測しない程度に情報を持っている必要があるからです。早すぎるコミュニケーションは混乱を招く可能性がありますが、遅すぎると信頼を損ない、保護措置を遅らせ、規制上の問題を引き起こす可能性があります。
中小企業がインシデント対応プランを作成したりリハーサルしたりしている可能性は低く、これがさらなる混乱を引き起こす可能性があります。プランを持つ大企業であっても、技術的な手順は文書化されているかもしれません：インシデントの封じ込め、アクセスのリセット、証拠の保全、システムの復元。コミュニケーションは後回しにされ、突然インシデントがエスカレートしたり変化したりするまで放置されるかもしれません。
インシデントに備えることの一部は、誰があなたからの連絡を必要としているのか、彼らが何を知る必要があるのか、誰がメッセージを承認するのか、そして調査が進行中に事実を明確に伝える方法を知ることです。
Proton Pass for Businessがどのように役立つか
コミュニケーション計画はインシデント対応の一部であるべき
インシデント対応はしばしば技術的なプロセスとして説明されますが、実際のインシデントはすぐに部門横断的になります。ITチームが脅威を封じ込めるかもしれませんが、経営陣、法務、カスタマーサポート、人事、広報、運用のすべてが、何が起きているのか、何を言うことが許されているのかを知る必要があります。
NCSCのサイバーインシデントにおける効果的なコミュニケーション(新しいウィンドウ)に関するガイダンス — 英国以外にも広く適用できる一般的なベストプラクティス — は、この点を明確にしています：組織はしばしば技術的な対応を優先し、コミュニケーションを後回しにしますが、コミュニケーションは危機の際にスタッフ、顧客、利害関係者、メディアが組織をどのように認識するかを形作るのです。
すべてのインシデントが公開声明を必要とするわけではありません。しかし、企業は事前に、誰が何を伝えるかを決定し、誰が外部メッセージを承認し、誰が顧客と話し、誰が規制報告を処理するかを知っておく必要があります。
強固なデータ侵害対応プランには、コミュニケーション層を含める必要があります。これには実用的な詳細を含めるべきです：
- 連絡先リスト
- 下書きテンプレート
- 承認ルート
- 法務レビュー
- カスタマーサポートのトーキングポイント
- 規制当局への通知責任
- 何が、いつ、誰に送信されたかの記録。
対応のための2トラック構造
インシデント対応には2つのトラックが必要です：技術的対応とコミュニケーション対応。これらは並行して実行され、インシデントリード/対応責任者が両者を接続します。
| 左トラック：技術的対応 | 右トラック：コミュニケーション対応 |
| インシデントを封じ込める | 社内チームを更新する |
| 影響を受けたアカウントを保護する | 影響を受けた顧客またはパートナーに通知する |
| 証拠を保全する | 規制当局への通知を評価する |
| システムを復元する | 事実が変わってもメッセージの一貫性を保つ |
これにより、対応を構造化し、チームメンバーが異なるタスクを引き受ける中でコラボレーションが継続されることを確実にできます。
発表ではなく、対象者から始める
セキュリティインシデントのコミュニケーションは、1つのメッセージで全員に応えようとすると失敗します。従業員、顧客、パートナー、規制当局は、それぞれ異なる決定を下す必要があるため、異なるレベルの詳細を必要とします。
社内チームにはまず明確さが必要です
彼らはすべての詳細を必要としているわけではありません。特に調査が進行中はなおさらです。しかし、何が確認され、今すぐ何をすべきか、誰が対応を主導しているかについての明確さは必要です。つまり、どのシステムやアカウントを避けるべきか、すぐに取るべき行動は何か、どの質問がまだ未解決かを知る必要があります。
従業員は、してはいけないことも知る必要があります。例えば：
- インシデントについて公に議論しない
- 承認されたプロセス以外で認証情報をリセットしない
- 即席の説明で顧客に連絡しない
- 指示なしに不審なメッセージを転送しない。
顧客とパートナーは、自分たちがどのような影響を受けるかを知る必要があります
彼らは、自分のデータ、アクセス、支払い、サービス、運用が影響を受けているかどうかを知りたがっています。優れた顧客通知は、次のことを説明するべきです：
- 何が知られているか
- どのような種類のデータが関係する可能性があるか
- 企業が何を行っているか
- 顧客が今取るべき行動があるとすれば何か
- どこで更新情報を入手できるか
トーンは平易かつ直接的であるべきです。また、顧客は詳細な技術情報を必要とせず、自分自身を守るのに十分な情報だけを必要としています。
規制当局は事実に基づく記録を必要とする
関連する監督機関（英国ではICO(新しいウィンドウ)、各EU加盟国では国内のデータ保護機関）へのGDPR侵害通知は、マーケティングメッセージや顧客への安心を促すメモではありません。代わりに、何が起こったか、誰が影響を受けたか、それに対して何が行われているかという事実に基づく記録である必要があります。規制当局への通知に関する以下のセクションで、何を含めるべきかを正確に説明します。
社内で何を伝えるか
従業員はインシデント対応チームに所属していなくても、対応の一部です。混乱したチームは、誤ってノイズを増やしたり、不正確な情報を共有したり、封じ込めを遅らせたりする可能性があります。一方、十分な情報を得たチームは、アカウントの保護、顧客を適切なチャンネルに誘導すること、憶測が広がるのを防ぐことに役立ちます。
内部セキュリティインシデントの告知には、以下を含める必要があります ：
- 平易な言葉による、これまでに確認されたことのクリアな要約
- どのシステム、アカウント、チーム、またはデータが影響を受ける可能性があるか
- 企業が現在行っていること
- 従業員が直ちに行うべきこと
- 外部とコミュニケーションを取ることが許可されているのは誰か
- 更新情報がどこに投稿されるか
- 関連する不審な活動を報告する方法
含めるべきではない側面もあります ：攻撃ベクトル、根本原因分析、特定の脆弱性は、インシデントが進行中の間は一般的に社内で共有されず、その後も共有されないことがよくあります。なぜなら、それらの詳細は他の攻撃者を助け、法的なリスクを生み、まだ閉じられていないギャップを露呈する可能性があるからです。
最初の社内メッセージは、すべての質問に答える必要はなく、秩序を生み出す必要があります。たとえば、従業員は承認されたプロセスを通じてのみパスワードをリセットしたり、特定のシステムの使用を避けたり、不審なメールを保存したり、対応チームがレビューを終えるまで共有の認証情報の使用を停止したりする必要があるかもしれません。
既存のアクセス制御をパスワード管理のベストプラクティスに対して評価することも不可欠です。インシデント中、時代遅れまたは非公式な認証情報の共有は、何が露出したかを理解するのを難しくする可能性があります。
Protonのデータ侵害保護 および企業向けデータ侵害防止に関するガイドでは、侵害が発生する前に多層的な制御がどのように露出を減らすかを説明しています。安全な認証情報管理は、どのアカウントが存在し、誰がそれらにアクセスでき、何を迅速に変更する必要があるかを企業が把握するのに役立つため、そのような層の1つです。
顧客に侵害を通知する方法
顧客へのデータ侵害通知は、風評的および法的な重みがあるため、より困難です。人々は、ユーザー情報の盗難、アカウントの乗っ取り、金融詐欺、またはプライベート情報の露出を心配するかもしれません。また、企業がインシデントを防がなかったことに不満を感じるかもしれません。
良い顧客向けメッセージは、警告的になることなく誠実であるべきです。技術的な専門用語を避けつつ、クリアである必要があります。顧客は、どのようなデータが関係していたか、それがどのようなリスクを生むか、次に何をすべきかを理解する必要があります。
役立つ構成は次のとおりです ：
- 何が起こったか、顧客に適した詳細レベルで
- 企業がいつ認識したか
- どの情報またはサービスが影響を受ける可能性があるか
- 企業がどのような措置を講じたか
- 顧客が現在行うべきこと
- 企業がどのように更新情報を提供するか
- 顧客が質問できる連絡先は誰か
調査がまだ進行中の場合は、それを開示する必要があります。正確さと透明性は信頼の回復に役立ちます。影響について率直であることは、誰かが攻撃を繰り返すのに役立つ技術的詳細を開示する必要はありません。
深刻なインシデントの場合、顧客は実用的な指示を必要とするかもしれません ：パスワードを変更する、MFAを有効にする、フィッシングメールに注意する、銀行に連絡する、公式チャンネルを通じて届かない限り企業からと称するメッセージを無視する、などです。通知は、これらの手順を理解しやすくする必要があります。
規制機関にいつ、どのように通知するか
すべてのセキュリティインシデントが監督機関に報告される必要があるわけではありません。英国およびEUのGDPRに基づく報告義務のある侵害は、個人データの侵害が人々の権利と自由に対するリスクをもたらす可能性があるかどうかによって決まります。
ICOの個人データ侵害ガイダンス(新しいウィンドウ)は、英国とEUの両方のGDPRに共通する要件を反映しています ：組織は、通知可能な侵害を不当な遅延なく、かつ認識してから72時間以内に報告する必要があります。遅延報告には、遅延の理由が必要です。
その72時間の枠は、特に調査がまだ不完全な場合にプレッシャーを生む可能性があります。GDPRは、組織が最初の72時間以内にすべての詳細を把握しているわけではないことを認識しているため、さらなる更新が不当な遅延なく提供される限り、情報は段階的に提供できます。
関連する監督機関（英国ではICO、EUでは国内のデータ保護機関）への通知には、通常、以下を含める必要があります ：
- 個人データ侵害の性質
- 影響を受ける個人のカテゴリとおおよその数
- 影響を受ける個人データ記録のカテゴリとおおよその数
- DPOまたは別の連絡窓口の名前と連絡先の詳細
- 侵害の起こりうる結果
- それに対処するために講じられた、または提案された措置
ICOはまた、侵害を報告(新しいウィンドウ)し、組織を適切な報告プロセスにルーティングするための中央ページを提供しています。
影響を受ける個人にとって、基準は異なります。個人データの侵害が人々の権利と自由に対する高いリスクをもたらす可能性がある場合、彼らは不当な遅延なく通知されなければなりません。これは、小規模企業であっても、法務、プライバシー、およびリーダーシップチームが早い段階で関与すべき状況です。
必要になる前にメッセージを準備する
コミュニケーションプロセスを設計するのに最悪のタイミングは、インシデント中です。更新や変更が必要な声明やガイダンスを発行することは役に立ちません。
そのため、必要になる前にメッセージの構造を準備することが役立ちます。最終的な文言ではなく、インシデントごとに異なるため、構造です ：誰がメッセージを承認する必要があるか、どの詳細を含める必要があるか、どこに更新が記録されるか、誰が各オーディエンスに責任を持つか。
シンプルなコミュニケーションキットがあれば、最初の1時間の混乱を軽減できます。含めることができるもの ：
- 社内インシデント告知テンプレート
- 顧客向け通知テンプレート
- パートナーまたはベンダー向け更新テンプレート
- カスタマーサポートのトーキングポイント
- 監督当局への通知チェックリスト
- 承認済み広報担当者リスト
- 法務、IT、プライバシー、経営陣、コミュニケーションのエスカレーション連絡先
- すべての更新と決定事項を記録する場所
準備は、スピードと正確さの両方が重要な場合に、チームに安全な出発点を与えます。準備されたテンプレートがあれば、インシデントの事実にさらに注意を向けることができます ：何が起こったか、誰が影響を受けたか、何がすでに行われたか、人々が次に何をする必要があるか。
Proton Pass for Businessがどのように役立つか
セキュリティインシデントのコミュニケーションは事実に依存します。企業がインシデント前にアクセスをより明確に管理するほど、何が起こったか、何が影響を受ける可能性があるか、何が変更されたかを説明するのが容易になります。
Proton Pass for Businessのようなビジネスパスワードマネージャーは、チームが認証情報に関連するリスクを軽減するのに役立ちます。従業員は強力なパスワードを生成し、暗号化されたパスワード保管庫に保存し、自動入力を使用し、認証情報を安全に共有し、パスキーを管理し、組み込みの2要素認証を使用できます。管理者はパスワードポリシーを適用し、アクティビティログを確認し、ロールベースの制御でアクセスを管理し、SCIMおよびSSO統合によるプロビジョニングをサポートできます。
インシデント発生時、これらの機能は企業がより自信を持って行動するのに役立ちます。従業員アカウントが侵害された場合、管理者はアクセスを確認し、ローテーションが必要な可能性のある共有認証情報を特定し、より強力な認証を適用し、チャットやスプレッドシートを通じてコピーされたパスワードへの依存を減らすことができます。
ビジネスパスワードマネージャーで、侵害が発生する前に応答する準備をしましょう。
