Daftar risiko autentikasi email harus menjelaskan layanan bisnis mana yang dapat dirugikan dan keputusan apa yang mengurangi risiko tersebut. “DMARC hilang” adalah temuan teknis, bukan pernyataan risiko yang lengkap. Hubungkan kondisi tersebut dengan jalur ancaman atau kegagalan yang dapat dipercaya, proses yang terkena dampak, perlindungan yang ada, dan pemilik yang bertanggung jawab.
Jelaskan layanan dan skenarionya
Untuk setiap entri, catat layanan, domain, pemilik aplikasi, kondisi teknis, waktu bukti, dan kemungkinan konsekuensinya. Pertahankan ketidakpastian secara eksplisit. Pengirim yang tidak teramati merupakan kesenjangan bukti, sedangkan pengirim sah yang terverifikasi dan tidak selaras merupakan cacat autentikasi. Tidak ada yang secara otomatis membuktikan bahwa penyerang telah mengeksploitasi layanan tersebut.
RFC 9989 menentukan otentikasi domain dan penyelarasan perilaku. Perlindungannya tidak menetapkan bahwa setiap permintaan yang diautentikasi adalah sah. Daftar risiko harus membedakan peniruan langsung domain Anda dari akun resmi yang disusupi atau a domain yang mirip yang melewati otentikasi untuk dirinya sendiri.
Pisahkan risiko bawaan dan risiko yang tersisa
Jelaskan skenario sebelum pengendalian, lalu jelaskan perubahan apa yang terjadi pada setiap upaya perlindungan yang ada. Untuk petunjuk faktur, verifikasi panggilan balik pembayaran dapat mengatasi permintaan bisnis palsu yang tidak dapat diselesaikan hanya dengan autentikasi domain. Jangan menyiratkan bahwa adanya kebijakan callback tertulis membuktikan masyarakat secara konsisten mengikutinya.
Gunakan definisi kemungkinan dan dampak yang disepakati organisasi. Hindari menyajikan presisi yang diciptakan seperti kemungkinan penipuan tahunan sebesar 17,3% tanpa bukti. Jika data tidak mencukupi, gunakan peringkat kualitatif beserta alasan dan pemicu tinjauannya. Catat siapa yang memiliki wewenang untuk menerima risiko yang tersisa, daripada menganggap persetujuan teknis administrator email sebagai penerimaan bisnis.
Gunakan contoh tertaut
Misalkan entri hipotetis R-1 berkaitan dengan penggajian. Kondisi tersebut tidak adanya bukti pas yang selaras pada layanan kritis yang terdaftar. Konsekuensi potensialnya adalah hilangnya pemberitahuan gaji jika rute yang belum diuji gagal selama penegakan hukum. Ini adalah skenario bersyarat, bukan klaim bahwa karyawan melewatkan pesan. Keuangan memiliki layanan tersebut, tim surat memiliki penyelidikan dan penutupan memerlukan tes rute saat ini ditambah konfirmasi pemilik layanan.
R-2 mencakup peniruan identitas pembayaran faktur melalui domain serupa milik penyerang. Pengendalian yang diusulkan adalah verifikasi independen melalui jalur kontak yang sudah tepercaya. Menerbitkan kebijakan yang lebih kuat pada domain korban tidak memenuhi uji penutupan R-2. Untuk setiap entri, mintalah temuan, pemilik, keputusan, dan bukti penutupan yang jelas sebelum menganggap daftar yang diajukan sudah lengkap. Ini adalah aturan peninjauan yang direkomendasikan, bukan validasi yang dijalankan atau bukti bahwa suatu kontrol berfungsi.
Jaga agar register dapat ditindaklanjuti
Pilih pengobatan secara eksplisit: memulihkan, menghindari aktivitas berisiko, mentransfer paparan tertentu jika diperlukan, atau menerima risiko yang tersisa melalui proses pengambilan keputusan yang sah. Tetapkan tanggal jatuh tempo dan pemicu peninjauan. Rencana pengobatan bukanlah bukti penyelesaian; menyimpan catatan pengujian atau keputusan sebenarnya secara terpisah.
Entri hipotetis ini menggambarkan skenario yang berbeda, bukan serangan yang teramati atau risiko bisnis yang diterima. Tinjauan kelengkapan dapat mengidentifikasi bidang-bidang yang hilang, namun tidak dapat memvalidasi peringkat risiko atau menetapkan bahwa upaya perlindungan yang sebenarnya dapat dilakukan. Pisahkan bukti aktual dan keputusan penerimaan resmi dari pengobatan yang diusulkan.
Tinjau pendaftaran setelah migrasi, pengirim baru, insiden, dan perubahan bisnis. Tutup hanya skenario spesifik yang buktinya memenuhi pengujian yang disebutkan, dan pertahankan riwayat yang cukup untuk menjelaskan mengapa skenario tersebut ditutup.
NIST SP 800-30 Rev. 1 bagian 2.3 dan 3.2 menjelaskan faktor risiko, pendekatan penilaian dan mendokumentasikan temuan penilaian. Mereka mendukung pengungkapan kemungkinan, dampak dan ketidakpastian; bidang pendaftaran khusus email dan contoh di atas adalah permohonan yang diusulkan, bukan daftar periksa kepatuhan yang ditentukan. Panduan penilaian risiko.