実証された制御改善に基づいてケースを構築する
A DMARC ビジネス ケースでは、どの程度の不正行為が防止されたかを考え出すことなく、可視性、送信者のガバナンス、および特定の不正なドメイン使用に対する保護を説明できます。最も強力なケースは、観察された問題を提案された制御変更に結び付け、影響を受ける可能性のある正当な送信ワークフローを特定し、結果を検証する方法を定義します。拒否されたすべてのメッセージを経済的損失の防止に変換したり、認証によるメッセージの排除を約束したりするものではありません。 ビジネスメールの侵害.
RFC 9989 DMARC特定の形式の正確なドメインに対処すると述べています スプーフィング、視覚的に類似したドメイン、表示名攻撃、またはコンテンツ分析ではありません。これらの制限は、技術的な付録だけでなく、ビジネス ケースにも当てはまります。この記事では、証拠に基づいた計画方法を提案します。ポリシーは変更されず、送信者のテストも行われず、損失の見積もりも財務上の約束も行われませんでした。
ベースラインの問題とその適用範囲の制限について説明する
組織が知っているドメインと正当な送信ワークフローから始めます。どのサービスが所有されているか、どのサービスが未解決であるか、どの認証パスに証拠があるかを記録します。設定されたインテントを、観測された受信者の結果とは別にしてください。のリスト SPF そして DKIM レコードは、すべてのワークフローがレコードを正しく使用していることを証明するものではなく、合格したサンプルはすべてのメールと受信者を完全にカバーしているわけではありません。
RFC 9990 認証に関する観察に貢献できる集計レポートを定義します。これらの報告は貴重な証拠ですが、その情報源と期間の範囲を明記する必要があります。レポートが存在しないことは、トラフィックがないことを証明するものではありません。不明な送信者には、不正なアクティビティ、忘れられた正規システム、または不完全な解釈が含まれる可能性があります。ビジネス上の正当化でカウントを使用する前に、証拠を使用してそれらを分類します。
目的を財務上の請求から切り離す
有用な目的には、正当な送信者への所有者の割り当て、未解決の認証失敗の削減、レビューされたポリシーの確立、変更検証の再現性の向上などが含まれます。それぞれに、定義された測定値、ベースライン期間、および証拠ソースが必要です。目的は、金額を伴わない運用またはセキュリティ関連の場合があります。予防損失の捏造を拒否したからといって、ビジネスケースが弱くなるわけではありません。
財務モデルが必要な場合は、承認された組織の入力情報を使用し、仮定を開示します。スタッフの時間、サブスクリプションのコスト、および導入の労力は、適切な記録があれば測定できる可能性がありますが、ここでは測定されませんでした。仮定の損失と拒否されたメッセージの数を掛け合わせても、節約できると判断できる見積もりにはなりません。提案された政策がなかったとしても、メッセージは人に届かず、行動を引き起こしたり、損失を引き起こしたりすることはなかったかもしれません。反事実には証拠が必要であり、修辞的な確実性は必要ない。
送信者ごとの準備マトリックスを作成する
ビジネス目的、所有者、表示される From ドメイン、予想されるエンベロープと署名 ID、現在の証拠、未解決のエラー、および変更の依存関係を含む正当なワークフローごとに行を作成します。目的の調整された認証パスを以下に記録します。 RFC 9989。機能が有効であるという供給者の主張は、信頼できる受領者の実際の認可されたサンプルの観察に基づいて区別されます。このドラフトではサンプルは収集されませんでした。
このマトリックスでは、提案されたポリシーに対応できるワークフローと、修正または文書化された例外が必要なワークフローを特定する必要があります。高い合計合格率を、小規模だが重要なワークフローが安全である証拠として扱うことは避けてください。少量の請求または回収プロセスは、たとえ分母にほとんど寄与しないとしても、商業的に重要になる可能性があります。したがって、準備は全体の割合だけでなく、ビジネスへの影響と対象範囲を考慮する必要があります。
ポリシーの差分と認可を指定する
提案された変更を、影響を受けるドメイン、意図された動作、前提条件、ロールアウトの決定との正確なポリシーの違いとして記述します。ポリシーは、従来の前提条件をコピーするのではなく、現在の標準および実際の受信機の適用性を反映する必要があります。 DNSパブリケーションの所有者、ビジネス リスクを承認する者、結果を検証する者を特定します。技術的な推奨事項自体は、生産の変更を許可するものではありません。
実行前に停止基準とロールバック基準を文書化します。ポリシーの調整は、準備の前提が間違っている場合に正規のメールに影響を与える可能性がありますが、 DNS値を復元しても、キャッシュされた監視結果が即座に置き換えられたり、すでに処理されたメールが元に戻されたりするわけではありません。リスクのない展開を約束するものではありません。以前の構成と依存サービスの情報を保存して、実際の証拠が正当であれば、権限のあるオペレーターが合理的な回復の決定を下せるようにします。
変更後の証拠を正しい境界で定義する
信頼できる出版物の証拠、代表的なワークフローに関する信頼できる受信メッセージの観察を収集し、適切に定義された期間にわたる傾向を集約する計画を立てます。 RFC 8601 その理由を説明する Authentication-Results 証拠は信頼できる受信者の境界から取得される必要があります。出所のないパス ラインをコピーしただけでは、意図したパスが変更後に機能したことを証明するには不十分です。
利用可能な場合はプロバイダー配信診断も確認しますが、その意味は保持されます。 SendGridのイベント参照 受信箱への配置や人による読み取りではなく、受信サーバーへの正常な配信として配信を定義します。このような証拠は、ビジネス成果の因果関係を証明することなく、認証の変更と他の配信の問題を区別するのに役立ちます。観察された傾向を説明できる他の同時変化を記録します。
ビジネスケースのワークシート
観察されたベースライン、適用範囲の制限、運用上の問題、提案されたポリシーの差分、送信者の準備状況、所有者、承認、期待される利点、実装の取り組み、リスク、および検証計画に関するセクションを作成します。測定値、仮定、測定されていない結果を目に見える形で分離してください。未解決の重要な送信者の決定フィールドと、続行または一時停止の特定の基準を含めます。ワークシートは、不確実性を隠すのではなく、対処可能なものにする必要があります。
主張されているすべての利益について、どのような証拠がそれを裏付け、どのような証拠がそれと矛盾するかを尋ねてください。完了したインベントリと承認を通じて、送信者の所有権をより適切に示すことができます。改善されました アライメント 対象範囲には、比較可能な観察と安定した定義が必要です。詐欺や金銭的損失を防ぐには、より強力な因果関係が必要であり、プロトコルの数だけから推測すべきではありません。この提案されたフレームワークには、実際の ROI 計算や捏造されたパフォーマンス統計は含まれていません。
架空の診断: 魅力的な紛失防止番号
架空のプロジェクト チームは、不正であると思われるレポート カテゴリに多数のメッセージを確認し、その数に平均不正金額を乗算することを提案します。データセットでは、配信、読まれ、信じられ、または行動されたであろうメッセージの数が確立されていないため、レビュー担当者は計算を拒否しました。また、カテゴリ内のすべてのソースが無許可であるかどうかもまだ解決されていません。
改訂案は、送信者の所有権の完了、正当な障害の解決、ポリシー変更の承認、変更後の証拠の保持など、検証可能な結果に焦点を当てています。組織が後にインシデントと財務データを独自にサポートした場合、資格のある所有者は、追加の請求が正当化されるかどうかを評価できます。このシナリオは架空のものです。報告数、不正行為の金額、損失の防止、またはプロジェクトの節約は観察または計算されませんでした。
DMARCで置き換えられないものについて説明する
の IC3 クラウド電子メール BEC アドバイザリーは 2020 年に公開され、異常なビジネス要求とアカウント保護の独立した検証をサポートしています。これらの制御は、侵害された承認済みアカウントが認証されたメールを送信でき、別のドメインが独自の認証に失敗することなく企業になりすますことができるため、引き続き関連性を維持します。 DMARCビジネスケースでは、制御を置き換えると主張するのではなく、補完的な制御を認識する必要があります。
カタログには、送信者ごとの準備マトリックス、ポリシーの差分、承認レコード、および変更後の結果が必要です。これらのオリジナルのアーティファクトはオープンなままです。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。この草案は証拠の枠組みと架空の演習を提供するものであり、完全な展開や財政的保証を提供するものではありません。出版には、認可された運用上の証拠と、その証拠が実際に示す内容に限定された主張が必要です。