A スプーフィング 苦情は手がかりであり、完全な技術的発見ではありません。報告者は、誤解を招く表示名、類似したアドレス、転送されたメッセージ、または侵害された正規アカウントを目撃した可能性があります。観察した内容を保存し、不足している証拠を特定し、影響を受けるビジネス活動を保護することで対応します。スクリーンショットに会社名が含まれているという理由だけでドメイン ポリシーを変更しないでください。
最小限の有用な証拠セットを収集する
可能であれば、承認された安全なチャネルを使用して、元のメッセージと、おおよその受信時刻、影響を受けるメールボックス、要求されたアクションの説明を要求します。編集前のオリジナルを保存してください。誰が提供したのか、いつ取得したのか、受信者から直接受け取ったのか仲介経由で受け取ったのかを記録します。転送された本文では、調査に不可欠なヘッダーが省略される場合があります。
元の証拠を適切なアクセス制御の下に保管します。関連する ID フィールドを保持しながら、不要な受信者の詳細、個人コンテンツ、または無関係な添付ファイルを削除する別の共有コピーを作成します。両方のファイルをハッシュし、編集内容を文書化して、レビュー担当者がバイトが異なる理由を理解できるようにします。ハッシュバインド 記録 バイトへ。コンテンツが本物であること、または送信者が正しく特定されたことを証明するものではありません。
信頼できる認証証拠を特定する
受信時にメッセージを評価したシステムを見つけます。アン Authentication-Results RFC 8601で説明されているように、フィールドは、確立された信頼境界内でのみ意味を持ちます。 認証結果。生成されたヘッダーまたは信頼できないヘッダーは、有効な形式を使用しているという理由だけで、受信側の監視に昇格されるべきではありません。
From、エンベロープ、および DKIM 合格の署名とビジネスの承認を混同することなくアイデンティティを実現します。 DMARC あらゆる形式の偽装ではなく、調整されたドメイン認証に対処します。 RFC 9989。元のメッセージまたは信頼できるログが利用できない場合は、結果を未解決のままにし、追加の証拠によって結果が変わることを説明します。
架空のインシデント台帳を作成する
教育ケース DEMO-COMPLAINT-01 では、申立人が From billing@brand-pay.testが表示される支払い変更リクエストを報告すると仮定します。実際のメッセージ バイト、受信者のタイムスタンプ、信頼できる認証結果、顧客の詳細は提供されません。元のハッシュを、作成されたダイジェストとしてではなく、使用できないものとして記録します。関連する証拠が得られるまで、分類は暫定的なものとなります。
提案された次のアクションを個別に割り当てます。メール操作では、承認された元のエクスポートと信頼できる受信コンテキストを取得します。財務部門は既知のチャネルを通じてリクエストを検証します。インシデントリーダーは、必要な共有または封じ込めを許可します。これらは役割を説明するためのものであり、割り当てを受け入れた実際の人物ではありません。
後の実際の共有コピーのために、元の参照、編集された各フィールド、目的、受信者、承認、および結果のファイル ハッシュを記録します。オリジナルを不変のままにしておきます。変更されたハッシュは変更されたバイトを識別できますが、メッセージの作成者や記録されなかった保管過程を特定することはできません。この書かれた例では、元のファイル、編集された標本、ハッシュ計算、または外部インシデント アクションは実行されませんでした。
限定された結果で応答する
有用な謝辞には、何を受け取ったのか、何が不明のままなのか、誰が調査しているのかが記載されています。身元やルートの証拠がその結論を裏付ける前に、サプライヤーを非難したり、問題が解決されると約束したりすることは避けてください。金銭や資格情報が危険にさらされている可能性がある場合は、証拠の収集が続く間、組織のインシデント プロセスに速やかに従ってください。 FBI は、支払い要求とアカウント変更を独立して検証することを推奨しています。 FBIの指導.
欠落している各アイテムに所有者と次のアクションを与えます。メール チームは受信者のログを取得し、ビジネス チームはリクエストを検証し、セキュリティ リーダーは封じ込めを調整できます。特にオリジナルに機密情報が含まれている場合は、外部共有を承認された範囲内に保ちます。
証拠によって裏付けられた結論のみを閉じてください。確認された類似リクエストは、プロバイダーの帰属が未解決のまま分類される可能性があります。正当な送信ルートが修復されると、ビジネス上の損害が解決されずに認証の欠陥が解消される可能性があります。次のレビュー担当者が部分的な発見を完全な解決策と間違えないように、最終的なインシデント パッケージでこれらの区別を保持してください。
調査結果を証拠の範囲内に留める
これらの例は防御的な意思決定を支援するものであり、実際の人物や現在のプロバイダーに対する観察された申し立てではありません。認証証拠、ビジネス検証、および帰属を個別に保持します。現在のプロトコル ソースには、ドメインの検証と信頼できる結果の境界が記述されています。彼らは、不足しているアカウントの証拠を提供したり、告発の公表を許可したりしません。