CFO は、電子メール ドメインが認証に合格するかどうかだけでなく、組織が送金リクエストをどのように検証するかを尋ねる必要があります。ドメイン認証は、受信者がドメインの使用を評価するのに役立ちます。サプライヤーの請求書を証明したり、銀行口座の変更を確認したり、正規のアカウントを使用している人間がリクエストを行う権限を持っていることを証明したりするものではありません。
3 つの詐欺経路を区別する
直接ドメイン偽装では、必要な連携認証を行わずにドメインを使用します。類似攻撃では、信頼できるドメインに似た別のドメインが使用されます。侵害されたアカウント攻撃は、正規の認証されたサービスを通じて発生する可能性があります。これらのパスにはさまざまな証拠が必要であり、ドメインでより厳格なポリシーを公開してもすべてを閉じることはできません。
RFC 9989 認証について説明します アライメント 著者ドメインを使用します。攻撃者が制御するbilling-supplier.exampleの合格結果は、それが実際のサプライヤーに属していることを証明するものではありません。表示名と返信先も読者を誤解させる可能性があります。によって評価されたドメインとは別にそれらを記録します。 DMARC.
意思決定パスを検査する
不審な要求の前に確立された連絡先情報を使用して、支払いの変更がどのように検証されるかを財務業務に問い合わせてください。同じ電子メールで提供された電話番号またはリンクは、独立した検証ルートではありません。特に銀行詳細の変更や緊急の支払い例外については、組織の承認されたワークフローと職務の分離を使用してください。
以下に書かれた架空のシナリオでは、「サプライヤー アカウント」を表示するメッセージが説明されていますが、表示されている From ドメインは攻撃者が制御する類似のものです。そのレシーバーの結果は、そのための合成整列パスです。 類似ドメイン。要求されたアクションは、口座番号を省略した銀行詳細の変更です。実際の顧客インシデントや実際の支払い指示は表現されていません。
制御境界をテストする
この例の正規のサプライヤー ドメインは、 supplier.example .test です。監視された送信者は、 supplier-payments.example .test を使用します。財務部門は変更を一時停止し、サプライヤーのマスター レコードから以前に確認された連絡先に電話します。架空の連絡先はリクエストを拒否します。このビジネス検証はシナリオの一部であり、このチェックポイントで行われる実際の会話ではありません。
規定されている 2 つの検証ルートを比較します。ケース A では、不審な要求の前に個別に検証されたと想定される、既存のサプライヤーのマスターレコード連絡先を使用します。架空の否定によって変化が保留されます。ケース B では、不審な電子メールによって提供された番号のみが使用されます。検証が不十分なため、変更は保留されたままになります。どちらの場合も、実際のディレクトリに対して計算、呼び出し、検証は行われませんでした。これは編集管理の例であり、義務付けられた財務手続きではありません。
日常業務の証拠を求める
コールバックや二重承認が発生していること、例外がエスカレートしていること、送信者ドメインの異常が財務担当者に到達していることを理解できる言葉でサンプリングした証拠を要求します。保護されていないドメインの修復の所有者は誰なのか、支払いプロセスの失敗の所有者は誰なのかを尋ねてください。比例的なレポートを維持します。失敗したDMARCメッセージの数は、防止された不正な支払いの数ではありません。
実際に不審な支払い要求が届いた場合は、メッセージと関連する受信者の記録を保存し、組織のインシデント プロセスに従い、行動する前に独自に要求を確認してください。認証は貴重な証拠ですが、資金移動の決定は承認されたビジネスプロセスに基づいて行われなければなりません。素晴らしい合格率をそのプロセスに置き換えないようにしてください。
境界付きコントロールのスコアカードを要求する
サンプリングされた支払い変更の数、文書化された独立した検証の数、未解決の例外とその所有者を要求します。これをDMARCメッセージ数とは別にしてください。証拠の欠如は調査の余地であり、詐欺が発生したことや、記載されている経済的損失が防止されたことを証明するものではありません。