Layanan yang sah dapat menyampaikan permintaan yang tidak sah. Pengguna dapat menyalahgunakan fitur berbagi atau pemberitahuan normal suatu platform, akun dapat disusupi, atau pengirim resmi dapat membuat permintaan bisnis yang tidak sah. Otentikasi domain dapat mengidentifikasi layanan atau pengirim yang dikonfigurasi dengan benar tanpa mengatasi risiko tersebut. Investigasi harus menjelaskan kedua fakta tersebut tanpa menyebut setiap pesan jahat yang lewat sebagai kegagalan otentikasi.
Bedakan layanan dari permintaan
Catat domain Dari yang sebenarnya, domain penandatanganan, identitas amplop, dan tautan dalam pesan. Tentukan identitas mana yang termasuk dalam layanan dan mana yang termasuk dalam domain yang dikontrol pelanggan. Jangan berasumsi bahwa logo yang familier atau nama tampilan yang terlihat berarti pesan tersebut berasal dari organisasi yang ditiru. DKIM mengaitkan domain penandatanganan dengan pesan; itu tidak menyatakan kebenaran pernyataan pesan tersebut. RFC 6376.
Tanyakan platform apa yang sebenarnya diautentikasi. Ini mungkin telah mengautentikasi sesi akun, domain yang dikonfigurasi, atau alur kerja notifikasi. Tidak ada satupun yang menetapkan bahwa pemilik akun bermaksud melakukan perubahan pembayaran atau bahwa dokumen bersama aman. Biarkan pertanyaan tersebut tetap terbuka sampai ada bukti dari pemilik layanan dan penerima bisnis.
Membangun matriks persyaratan dan bukti
Gunakan baris terpisah untuk autentikasi domain, kontrol akun, tinjauan konten, dan persetujuan bisnis. Setiap baris memerlukan persyaratan, bukti, keyakinan, pemilik, dan tindakan selanjutnya. Tanda tangan yang selaras dapat memenuhi baris autentikasi domain yang sempit tanpa memuaskan baris lainnya. RFC 9989 menjelaskan DMARCcakupan berbasis domain daripada jaminan umum tentang konten. spesifikasi DMARC.
Untuk permintaan keuangan, verifikasi independen sangatlah penting. Gunakan rute kontak yang diketahui, bukan nomor telepon atau alamat balasan yang baru diberikan dalam pesan. FBI merekomendasikan untuk memeriksa secara mandiri permintaan pembayaran dan perubahan pada detail rekening. bimbingan FBI.
Baca contoh beban kerja transparan
Contoh tertulis mengasumsikan pesan perubahan pembayaran dengan autentikasi yang selaras, tidak ada persetujuan bisnis, dan kontak vendor yang diketahui menolak perubahan tersebut. Oleh karena itu, matriksnya mempertahankan kartu otentikasi sambil menahan perubahan pembayaran. Ini tidak menyimpulkan apakah suatu akun telah disusupi, fitur layanan disalahgunakan, atau tersangka pengirim ikut serta.
Model hipotetis yang sama menggunakan ilustrasi beban kerja bulanan sebanyak 10.000 pesan, tingkat pemilihan ulasan 1%, dan empat menit per pesan yang dipilih. Aritmatika menghasilkan 100 ulasan dan sekitar 6,67 jam analis. Itu hanyalah asumsi perencanaan, bukan pengukuran tingkat penyalahgunaan platform, tolok ukur kepegawaian, atau harga vendor. Perkiraan tersebut tidak mencakup eskalasi investigasi, akhir pekan, penanganan positif palsu, dan koordinasi insiden, sehingga perkiraan tersebut bukan merupakan perkiraan biaya operasional yang lengkap.
Selidiki tanpa memblokir secara berlebihan
Pertahankan pengidentifikasi pesan dan referensi objek khusus penyedia jika tersedia, namun hindari menyebarkan konten dokumen sensitif jika tidak perlu. Minta pemilik layanan resmi untuk menyelidiki aktivitas akun, pengaturan berbagi, dan log audit. Setiap tindakan pembendungan harus mencakup ancaman yang terverifikasi dan diizinkan oleh proses respons organisasi.
Memblokir seluruh layanan populer dapat mengganggu alur kerja yang sah tanpa menyelesaikan penyusupan akun di tempat lain. Pertimbangkan apakah tindakan pengirim, objek, URL, atau akun yang lebih sempit didukung dan sesuai. Ini adalah kriteria keputusan, bukan instruksi untuk melakukan penghapusan atau mengubah akun orang lain tanpa izin.
Dekat dengan fakta identitas yang terbukti, penjelasan sebab akibat yang belum terverifikasi, hasil bisnis, dan pemilik respons. Jika layanan tetap dapat digunakan, pertahankan konfigurasi autentikasinya sambil mengatasi jalur penyalahgunaan. Menghapus DKIM untuk menghindari kesan saling percaya akan melemahkan sinyal yang berguna tanpa membuat konten menjadi aman. Tujuannya adalah untuk menafsirkan sinyal tersebut dengan benar dan menambahkan pemeriksaan independen yang diperlukan oleh permintaan.
Pertahankan empat baris bukti yang berbeda
Untuk kasus yang ditemukan ini, otentikasi domain ditetapkan lulus; administrator surat memiliki bukti penerimaan yang nyata. Kontrol akun tidak diketahui; pemilik layanan resmi harus memeriksa aktivitas akun sebenarnya. Keamanan konten belum terselesaikan; keamanan memiliki tinjauan konten terbatas. Persetujuan usaha tidak ada dan vendor yang diketahui telah ditetapkan menolak permintaan tersebut; keuangan mempertahankan penangguhan pembayaran. Tidak ada vendor sebenarnya yang dihubungi, tidak ada akun yang diselidiki dan tidak ada pembayaran yang diubah. Contoh ini memberikan struktur keputusan, bukan bukti yang mengidentifikasi pelaku.
Batas sumber dan eksekusi
RFC 9989 Bagian 4.4, 5.3.5 dan 5.4 membedakan otentikasi, penyelarasan dan penanganan; pass tidak mendukung konten pesan. Keputusan operasional di sini adalah rekomendasi yang tercakup dan contoh hipotetis yang eksplisit, bukan pengujian baru terhadap pelanggan, penyedia, atau perlengkapan historis. Setiap perubahan nyata memerlukan cakupan resminya sendiri, bukti yang disimpan, dan keputusan yang dapat dipertanggungjawabkan.