Bangun kasus berdasarkan peningkatan pengendalian yang ditunjukkan
A DMARC kasus bisnis dapat menjelaskan visibilitas, tata kelola pengirim, dan perlindungan terhadap penggunaan domain tertentu yang tidak sah tanpa mengetahui seberapa besar penipuan dapat dicegah. Kasus terkuat menghubungkan masalah yang diamati dengan usulan perubahan kontrol, mengidentifikasi alur kerja pengiriman sah yang dapat terpengaruh, dan menentukan bagaimana hasilnya akan diverifikasi. Itu tidak mengubah setiap pesan yang ditolak menjadi kerugian finansial yang dapat dicegah atau janji yang dihilangkan oleh otentikasi kompromi email bisnis.
RFC 9989 menyatakan bahwa DMARC menangani bentuk domain eksak tertentu spoofing, bukan domain yang serupa secara visual, serangan nama tampilan, atau analisis konten. Batasan tersebut termasuk dalam kasus bisnis, tidak hanya dalam lampiran teknis. Artikel ini mengusulkan metode perencanaan berbasis bukti. Tidak ada kebijakan yang diubah, pengirim diuji, perkiraan kerugian atau komitmen keuangan dibuat.
Jelaskan masalah dasar beserta batas cakupannya
Mulailah dengan domain dan alur kerja pengiriman sah yang diketahui organisasi. Catat layanan mana yang dimiliki, layanan mana yang belum terselesaikan, dan jalur autentikasi mana yang memiliki bukti. Pisahkan niat yang dikonfigurasi dari hasil penerima yang diamati. Daftar SPF Dan DKIM catatan bukanlah bukti bahwa setiap alur kerja menggunakannya dengan benar, sementara sampel yang lewat tidak memberikan cakupan yang lengkap di seluruh email dan penerima.
RFC 9990 mendefinisikan pelaporan agregat yang dapat menyumbangkan observasi tentang autentikasi. Laporan-laporan tersebut merupakan bukti berharga, namun sumber dan periode liputannya harus disebutkan. Laporan yang hilang tidak membuktikan tidak adanya lalu lintas. Pengirim yang tidak diketahui mungkin mencakup aktivitas yang tidak sah, sistem sah yang terlupakan, atau interpretasi yang tidak lengkap. Klasifikasikan mereka dengan bukti sebelum menggunakan hitungan mereka dalam pembenaran bisnis.
Pisahkan tujuan dari klaim keuangan
Tujuan yang berguna dapat mencakup menugaskan pemilik ke pengirim yang sah, mengurangi kegagalan otentikasi yang belum terselesaikan, menetapkan kebijakan yang ditinjau, dan meningkatkan kemampuan pengulangan verifikasi perubahan. Masing-masing harus mempunyai ukuran yang jelas, periode dasar dan sumber bukti. Tujuannya mungkin bersifat operasional atau terkait keamanan tanpa angka moneter. Sebuah kasus bisnis tidak menjadi lemah hanya karena kasus tersebut menolak mengarang kerugian yang dapat dicegah.
Jika model keuangan diperlukan, gunakan masukan organisasi yang disetujui dan ungkapkan asumsinya. Waktu staf, biaya berlangganan dan upaya implementasi mungkin dapat diukur dengan catatan yang sesuai, namun hal tersebut tidak diukur di sini. Kerugian hipotetis dikalikan dengan jumlah pesan yang ditolak bukanlah perkiraan penghematan yang dapat dipertahankan. Pesan tersebut mungkin tidak akan sampai kepada seseorang, mendorong tindakan atau menyebabkan kerugian bahkan tanpa adanya kebijakan yang diusulkan. Kontrafaktual memerlukan bukti, bukan kepastian retoris.
Membangun matriks kesiapan pengirim demi pengirim
Buat baris untuk setiap alur kerja yang sah dengan tujuan bisnis, pemilik, domain Dari yang terlihat, amplop yang diharapkan dan identitas penandatanganan, bukti terkini, kegagalan yang belum terselesaikan, dan ketergantungan perubahan. Catat jalur autentikasi selaras yang dimaksud di bawah RFC 9989. Bedakan klaim pemasok bahwa suatu fitur diaktifkan dari pengamatan penerima tepercaya terhadap sampel resmi yang sebenarnya. Tidak ada sampel yang dikumpulkan untuk draf ini.
Matriks tersebut harus mengidentifikasi alur kerja mana yang siap untuk kebijakan yang diusulkan dan mana yang memerlukan perbaikan atau pengecualian yang terdokumentasi. Hindari memperlakukan tingkat kelulusan agregat yang tinggi sebagai bukti bahwa alur kerja yang kecil namun penting itu aman. Proses penagihan atau pemulihan bervolume rendah dapat menjadi penting secara komersial meskipun kontribusinya kecil terhadap penyebut. Oleh karena itu, kesiapan harus mempertimbangkan dampak dan cakupan bisnis, bukan hanya persentase keseluruhan.
Tentukan perbedaan kebijakan dan otorisasi
Tulis perubahan yang diusulkan sebagai perbedaan kebijakan yang tepat dengan domain yang terpengaruh, perilaku yang diinginkan, prasyarat, dan keputusan peluncuran. Kebijakan tersebut harus mencerminkan standar yang berlaku saat ini dan penerapan aktual penerima manfaat, bukan meniru asumsi-asumsi lama. Identifikasi siapa yang memiliki publikasi DNS , siapa yang menyetujui risiko bisnis, dan siapa yang memverifikasi hasilnya. Rekomendasi teknis bukanlah otorisasi untuk mengubah produksi.
Dokumentasikan kriteria stop dan rollback sebelum eksekusi. Penyesuaian kebijakan dapat memengaruhi email yang sah jika asumsi kesiapan salah, sedangkan memulihkan nilai DNS mungkin tidak langsung menggantikan pengamatan yang di-cache atau membatalkan email yang sudah ditangani. Jangan menjanjikan peluncuran yang bebas risiko. Pertahankan konfigurasi sebelumnya dan informasi layanan yang bergantung sehingga operator resmi dapat membuat keputusan pemulihan yang masuk akal jika bukti nyata menjaminnya.
Tentukan bukti pasca perubahan pada batas yang tepat
Rencanakan untuk mengumpulkan bukti publikasi resmi, pengamatan pesan yang diterima secara tepercaya untuk alur kerja yang representatif, dan tren agregat selama periode tertentu yang sesuai. RFC 8601 menjelaskan alasannya Authentication-Results bukti harus datang dari batas penerima yang tepercaya. Jalur yang disalin tanpa asal tidak cukup untuk membuktikan bahwa jalur yang dimaksudkan berhasil setelah perubahan.
Tinjau juga diagnostik pengiriman penyedia jika tersedia, namun pertahankan maknanya. Referensi acara SendGrid mendefinisikan terkirim sebagai pengiriman yang berhasil ke server penerima, bukan penempatan kotak masuk atau pembacaan manusia. Bukti tersebut dapat membantu membedakan perubahan autentikasi dari masalah pengiriman lainnya tanpa membuktikan peningkatan hasil bisnis secara kausal. Catat perubahan bersamaan lainnya yang dapat menjelaskan tren yang diamati.
Lembar kerja kasus bisnis
Buat bagian untuk data dasar yang diamati, batasan cakupan, masalah operasional, perbedaan kebijakan yang diusulkan, kesiapan pengirim, pemilik, persetujuan, manfaat yang diharapkan, upaya implementasi, risiko dan rencana verifikasi. Jagalah agar nilai-nilai terukur, asumsi-asumsi, dan hasil-hasil yang tidak terukur tetap terlihat terpisah. Sertakan bidang keputusan untuk pengirim penting yang belum terselesaikan dan kriteria khusus untuk melanjutkan atau menjeda. Lembar kerja harus membuat ketidakpastian dapat ditindaklanjuti dan bukan menyembunyikannya.
Untuk setiap manfaat yang diklaim, tanyakan bukti apa yang mendukungnya dan bukti apa yang bertentangan. Kepemilikan pengirim yang lebih baik dapat ditunjukkan melalui inventarisasi dan persetujuan yang lengkap. Ditingkatkan penyelarasan cakupannya memerlukan pengamatan yang sebanding dan definisi yang stabil. Pencegahan penipuan atau kerugian moneter memerlukan dasar sebab akibat yang lebih kuat dan tidak boleh disimpulkan hanya dari penghitungan protokol saja. Kerangka kerja yang diusulkan ini tidak berisi penghitungan ROI aktual atau statistik kinerja palsu.
Diagnosis fiktif: angka pencegahan kerugian yang menggiurkan
Tim proyek fiktif melihat banyak pesan dalam kategori laporan yang diyakini tidak sah dan mengusulkan untuk mengalikan jumlah tersebut dengan jumlah rata-rata penipuan. Peninjau menolak penghitungan tersebut karena kumpulan data tidak menentukan berapa banyak pesan yang akan disampaikan, dibaca, diyakini, atau ditindaklanjuti. Hal ini juga belum menentukan apakah setiap sumber dalam kategori tersebut tidak sah.
Revisi yang diusulkan berfokus pada hasil yang dapat diverifikasi: menyelesaikan kepemilikan pengirim, menyelesaikan kegagalan yang sah, menyetujui perubahan kebijakan, dan menyimpan bukti pasca perubahan. Jika organisasi kemudian memiliki data insiden dan keuangan yang didukung secara independen, pemilik yang memenuhi syarat dapat menilai apakah klaim tambahan dapat dibenarkan. Skenario ini fiktif; tidak ada penghitungan laporan, jumlah penipuan, pencegahan kerugian atau penghematan proyek yang diamati atau dihitung.
Nyatakan apa yang tidak digantikan oleh DMARC
Itu Penasihat BEC cloud-email IC3, yang diterbitkan pada tahun 2020, mendukung verifikasi independen atas permintaan bisnis yang tidak biasa dan perlindungan akun. Kontrol tersebut tetap relevan karena akun resmi yang disusupi dapat mengirim email yang diautentikasi, dan domain lain dapat meniru identitas bisnis tanpa gagal melakukan autentikasinya sendiri. Kasus bisnis DMARC harus mengakui pengendalian yang saling melengkapi dan bukan mengklaim menggantikannya.
Katalog ini memerlukan matriks kesiapan pengirim per pengirim, perbedaan kebijakan, catatan persetujuan, dan hasil pasca perubahan. Artefak asli tersebut tetap terbuka. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Draf ini memberikan kerangka bukti dan pelaksanaan fiktif, bukan peluncuran yang telah selesai atau jaminan keuangan. Publikasi memerlukan bukti operasional resmi dan klaim yang terikat pada apa yang sebenarnya ditunjukkan oleh bukti tersebut.