支払い権限を別の質問として扱う
サプライヤーの電子メールは正しく認証されていても、未承認の支払い変更リクエストが含まれている可能性があります。侵害されたメールボックスまたはアプリケーションはサプライヤーの正規の送信インフラストラクチャを使用する可能性がありますが、なりすまし者は見慣れた表示名を持つ別のドメインを使用する可能性があります。当面のビジネス上の問題は、メッセージにワードパスが含まれているかどうかではなく、要求された変更が承認されるかどうかです。財務上の決定は技術的な調査とは切り離して、どちらも他方の代わりにならないようにしてください。
RFC 9989 限界 DMARC ドメイン認証関係との関連付けを行い、ドメイン以外のエンティティのコンテンツ分析と認証を明示的に除外します。銀行口座の変更を承認したり、サプライヤーの従業員の意向を確認したりすることはできません。合格結果はドメイン使用に関する有用な証拠ですが、組織が従わなければならない支払い指示ではありません。この原稿は防御プロセスを提案しています。支払い、アカウント更新、外部連絡は行われませんでした。
リクエストを実行せずに保存する
既存の購入または財務プロセスを通じて、要求された変更を保留します。メッセージが何を変更するよう求めているか、どのサプライヤーのレコードに影響するか、いつ変更が有効になるか、誰が変更を受信したかを記録します。完全な財務詳細を、広くアクセス可能なインシデント チケットにコピーすることは避けてください。承認された制限付きレコードはオリジナルを保存できますが、作業概要は参照識別子と必要最小限のコンテキストを使用して変更を記述します。
元のメッセージとその出所を保持します。転送されたコピーまたはスクリーンショットは、リクエストがどのように表示されたかを示すのに役立ちますが、元のメッセージや受信者のログと互換性はありません。収集時間とタイムゾーンを記録します。誰かがすでに行動を起こしている場合は、変更を黙って元に戻せると考えるのではなく、組織が確立した財務インシデント手順に従ってエスカレーションしてください。この記事は、銀行への譲渡、リコール、または連絡を許可するものではありません。
どの ID が使用されたかを確認する
実際の From ドメインと信頼できるベンダー レコードのサプライヤー ドメインを比較します。表示名、返信先アドレス、エンベロープ ID および DKIM 署名ドメインは別です。異なるドメインのメッセージは、読者に所属について誤解を与えながら、独自のドメインを認証する可能性があります。認証が調整された正確なサプライヤー ドメインのメッセージは、悪用されたアカウントまたはサービスを通じて発信される可能性があります。リクエストが異常であるという理由だけで妥協仮説を選択しないでください。
認証を解釈する際には、信頼できる受信者の証拠を使用します。 RFC 8601 その理由を説明する Authentication-Results フィールドには信頼境界が必要です。送信者が提供した行、スクリーンショット、または転送されたヘッダーの抜粋では、関連する受信者の評価が確立されない場合があります。どの受信機が結果を生成し、どの調整されたパスが観察されたかを記録します。証拠が不完全な場合は、財務上の決定に合否の結論を押し付けるのではなく、そのように主張してください。
確立された独自ルートで検証
の IC3 クラウド電子メール BEC アドバイザリーは、2020 年 4 月 6 日に公開され、不審なビジネス要求を独立して検証することを推奨しています。組織の既存の検証済みベンダー記録など、疑わしいリクエストの前に確立されたサプライヤー連絡ルートを使用します。そのメッセージ内でのみ提供される新しい電話番号、代替電子メール アドレス、または確認リンクは、独立した情報源ではありません。引用された勧告はこの一般原則を支持するものであり、現在の事件の主張を支持するものではありません。
承認されたビジネス検証者に、確立されたプロセスを通じて提案された特定の変更を確認するよう依頼します。人が送信者名を認識していることを確認することは、変更自体が要求され承認されたことを確認することよりも弱いです。ポリシーで個別の承認者が必要な場合は、その分離を維持してください。メッセージの緊急性を組織の承認要件に置き換えないでください。テクニカル アナリストは身元証拠を提供できますが、黙って財務承認者になるべきではありません。
技術調査を慎重に調整する
証拠がサプライヤーアカウントの悪用を示している場合は、承認された検証済みの連絡先を通じて連絡し、承認後に関連する編集された証拠のみを共有します。サプライヤーの認定対応者がシステムの調査を担当します。受信組織は、単にメッセージが認証され、サプライヤーが支払い要求を拒否したという理由だけで、サプライヤーの乗っ取りを証明したと主張すべきではありません。統合、代理送信者、またはその他のメカニズムについては調査が必要な場合があります。
Microsoft の侵害されたアカウントに関するガイダンス では、疑わしい受信トレイ ルール、考えられる指標の転送およびメッセージの欠落をリストし、 Microsoft 365のアカウントの対応について説明します。これは、その環境における認定サプライヤーの対応者への参照であり、別の組織のアカウントを検査する許可ではありません。この原稿の作業には、アカウントへのアクセス、セッションの取り消し、ルールの削除、資格情報の収集は含まれません。
支払い変更証拠ワークシート
リンクされた 4 つのセクションを含むワークシートを作成します。要求セクションには、サプライヤー参照、変更タイプ、要求日、ビジネス所有者が記録されます。 ID セクションには、実際のドメイン、信頼できる認証の観察、および証拠ソースが記録されます。検証セクションには、独自に確立された連絡ルート、権限のある検証者、正確な質問と回答が記録されます。決定セクションには、承認または拒否、必要な承認者、許可された実装パス、および未解決の調査が記録されます。
金融口座識別子を汎用コピーに保管しないでください。比較が重要な場合は一貫したプレースホルダーを使用し、完全なオリジナルは承認された制限された場所にのみ保管してください。観察された事実と仮説を区別する列を追加します。 「当社の受信機で観察されたサプライヤー・ドメインに合わせたDKIM 」は、証拠がそれを裏付ける場合にのみ事実となります。 「サプライヤー従業員が変更を承認」には別途業務上の確認が必要です。ワークシートは、前者を後者に自動的に昇格させてはなりません。
架空の診断: おなじみのサプライヤーのスレッド
架空の施設チームは、確立されたサプライヤーとの会話で、将来の支払いの詳細を変更するよう求めるリクエストを受け取ります。メッセージはサプライヤーの実際のドメインを使用し、受信側で仮想的にDMARCを渡します。受信者は、既存のスレッドと認証結果により変更が安全であると想定します。代わりに、2 人目のレビュー担当者が更新を一時停止し、確立された検証ルートの承認済みサプライヤー レコードをチェックします。
演習では、サプライヤーの連絡先は変更の承認を拒否します。この応答はビジネス プロセスに基づく要求の拒否をサポートしますが、承認された技術的証拠が入手できるまでメカニズムは未解決のままです。調査では、完全な支払い詳細を広範囲に転送するのではなく、メッセージを保存し、承認された最小限の概要を共有します。これは架空のシナリオであり、実際の拒否、侵害の発見、確認の呼び出し、または損失の防止ではありません。これは、ビジネス検証とドメイン認証が異なる質問に答える理由を示しています。
財務トラックと技術トラックを別々にクローズする
技術調査が継続する場合でも、要求された変更の処理を記録します。逆に、アカウントが保護されたという理由だけでビジネス上の問題が解決したと宣言しないでください。誰かがすでにサプライヤーの記録を変更しているか、要求に応じて行動している可能性があります。実際の業務記録と承認された決定および結果を検証した文書を照合します。そのような行為には組織の通常の権限が必要です。ここでは何も実行されていません。
カタログには、身元証拠、管理境界、および独立したビジネス検証を含む、編集された悪用シナリオが必要です。その元の証拠は未解決のままです。提案されたワークシートと架空の演習はそれを満たしていません。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。公開可能なバージョンには、財務識別情報を公開したり、サプライヤーに関する裏付けのない申し立てをしたりすることなく、検証プロセスを実証する承認された証拠パッケージが必要です。