認証されたメッセージには依然として不正なリクエストが含まれる可能性があります。その発言は成り立たない SPF, DKIM または DMARC 重要ではない。それはそれらの境界を定義します。
電子メール認証は、ドメイン ID とメッセージ処理に関する証拠を提供します。ビジネスの承認は、別の質問に答えます。つまり、この人またはシステムにはこのリクエストを行う権利があったのか、組織はそれに応じて行動する必要があるのかということです。安全なプロセスには両方が必要です。
パスが実際に何を証明するかを尋ねる
下 RFC 9989 §5.3.5 そして RFC 9989 §5.4、メッセージ レベルのDMARCパスとは、受信者が、認証されたドメインが From のドメインと一致する、通過するSPFまたはDKIMパスを少なくとも 1 つ見つけたことを意味します。それは証明されません:
- どの個人がアカウントを管理していたか。
- アカウントが侵害されていないこと。
- 請求書または銀行変更が正当であること。
- リンクや添付ファイルは無害であること。
- ドメインが受信者が念頭に置いていたブランドであることを意味します。
正確なステートメントは役に立ちます。メッセージは From ドメインを提示し、そのドメインに関連する適格な認証証拠を生成しました。それを、送信者またはメッセージが安全であるという広範な主張に変換することは避けてください。
対応を選択する前に個人情報の不正使用を分類する
受信トレイ内ではさまざまな攻撃が似ているように見えますが、認証境界の異なる側に存在する場合があります。
- パターン: 正確なドメインの偽造。認証で示される内容: 調整されたパス パスがありません。受信者の証拠と処理に依存します。制御と応答の焦点: DMARCポリシー、送信者のカバレッジ、受信者の制御と調査
- パターン： 類似ドメイン;認証で示される内容: 類似ドメインは、自身のドメインを正常に認証する可能性があります。制御と対応の焦点: ドメインの監視、ユーザーの合図、フィルタリング、レポート、および適切な不正行為アクション
- パターン: 表示名の欺瞞。認証で示される内容: 関連のないドメインでも、よく知られた名前を提示しながら認証を行うことができます。制御と応答の焦点: 表示名の分析、コンテキスト、ユーザーレポート、および独立した検証
- パターン: 認証されたアカウントが侵害される。認証で示される内容: 実際のドメインは認証に合格できます。制御と対応の焦点: アカウントのセキュリティ、セッションとサインインの調査、封じ込めとビジネスの検証
- パターン: 侵害されたサプライヤー。認証で示される内容: サプライヤーの実際のドメインは通過可能です。制御と対応の焦点: サプライヤーのインシデント調整、取引管理、代替チャネルの確認
DMARC 、対象となるドメイン ID の不正使用に対して最も強力です。視覚的に類似したドメインの所有権を作成したり、表示名が真実であることを検証したり、実際のアカウントが適切な権限で使用されたかどうかを判断したりすることはありません。
架空の支払い変更事件を追跡する
次のシナリオは合成です。これは、顧客のインシデントを示唆することなく、証拠の連鎖を示すように設計されています。
財務担当者が次からのリクエストを受け取ります。 accounts@supplier.example 銀行口座情報の変更を求められます。適用可能なポリシーを想定すると、信頼できる受信者の結果は、次の場合に調整されたDKIMパスを示します。 supplier.exampleしたがって、メッセージはDMARCを通過します。スレッドの歴史や文体にも見覚えがある。
従業員は、これらのシグナルに基づいて変更を承認しません。彼らは、以前に確認されたサプライヤーの番号に電話し、メールボックスが侵害されたことを知りました。組織は、要求された変更を凍結し、元のメッセージを保存し、タイムスタンプと関連ヘッダーをサプライヤーに提供します。
認証は設計どおりに機能し、メッセージがサプライヤーの認証済みドメインを使用していることがわかりました。独立した検証制御により、ドメイン認証では判断できなかった不正なトランザクションが停止されました。
プロトコルの証拠とビジネスの証拠を保存する
重大なインシデントの場合は、編集されたコピーを作成する前に、アクセス制御された元のメッセージを保持してください。 RFC 8601 §7.1 信頼できる結果の境界を定義します。署名されたマテリアルを編集すると、次の再検証に影響を与える可能性があります。 RFC 6376 §3.7。有用な技術的証拠には、信頼できる技術的証拠が含まれます。 Authentication-Results、関連する受信フィールド、差出人、返信先、 Return-Path、 DKIM署名、メッセージ識別子、タイムスタンプ、受信ログ。
ビジネス上の有用な証拠には、要求、意図されたアクション、確立された承認ルール、検証に使用された連絡方法、および結果が含まれます。事実を推論から切り離してください。生のパスは侵害の証拠ではなく、 DMARC失敗は損害が発生したことの証拠ではありません。
下 RFC 9990 §3.1、集約されたDMARCレポートは、ドメイン所有者が観察された認証と処理パターンを理解するのに役立ちます。これらは個々のメッセージの完全な記録ではなく、通常、特定のリクエストが承認されたかどうかを判断するために必要なコンテンツを提供しません。下 RFC 9989 §5.3.9, 失敗レポートが生成される場合は、プライバシーとアクセスの慎重な処理が必要であり、普遍的に利用できるわけではありません。
機密性の高いワークフローに独立した検証を組み込む
影響の大きいアクションでは、受信メッセージのみに依存しないコントロールを使用する必要があります。例としては次のものが挙げられます。
- 事前に承認されたチャネルを通じて銀行詳細の変更を確認する。
- 定義されたしきい値を超える支払いには二重の承認が必要です。
- 電子メール スレッドがリクエストと確認連絡先の両方を提供できないようにします。
- 機密データの交換には認証されたポータルを使用します。
- 緊急の秘密、異常なタイミング、または制御のバイパスをリスク信号として扱います。
これらはビジネス管理であり、認証の代替品ではありません。認証によりドメインの使用に関する曖昧さが軽減され、トランザクション制御により、認証されたものの未承認のリクエストによる影響が軽減されます。
プログラムを弱めることなく境界を伝える
DMARCすべてを停止するわけではないと言う フィッシング 技術は正確です。したがって効果がないかと言えばそうではありません。ポリシーを強制すると、保護されたドメインの不正使用が減少し、受信者の証拠が改善され、正当な送信パスの所有権が明確になります。
適切なメッセージは階層化されており、ドメインの保護、アカウントの保護、類似品や欺瞞的なプレゼンテーションの検出、機密性の高いアクションの個別検証が行われます。を使用します。 DMARC ID ガイド ドメインレベルの結果については、 送信者の在庫 認可されたサービスの所有権のために。
結論は証拠の範囲内に留めておく
架空の支払い変更ケースでは、ドメイン認証に合格したという 2 つの独立した結果が維持されます。提案された取引は個別の検証の後、承認されませんでした。パスだけでの妥協を報告しないでください。承認されたインシデントの開示のみを保持し、受信リクエストの外部に信頼できる検証連絡先を残しておきます。サプライヤーには連絡がなく、取引や事件への対応も行われませんでした。