Perlakukan otoritas pembayaran sebagai pertanyaan terpisah
Email pemasok dapat diautentikasi dengan benar dan masih berisi permintaan perubahan pembayaran yang tidak sah. Kotak surat atau aplikasi yang disusupi mungkin menggunakan infrastruktur pengiriman sah milik pemasok, sementara peniru identitas mungkin menggunakan domain berbeda dengan nama tampilan yang familiar. Pertanyaan bisnis yang mendesak adalah apakah perubahan yang diminta diizinkan, bukan apakah pesan tersebut berisi kata pass. Pisahkan keputusan keuangan dari penyelidikan teknis sehingga tidak ada yang bisa menggantikan yang lain.
RFC 9989 batas DMARC untuk hubungan autentikasi domain dan secara eksplisit mengecualikan analisis konten dan autentikasi entitas selain domain. Perusahaan tidak dapat menyetujui perubahan rekening bank atau menetapkan niat karyawan pemasok. Hasil kelulusan merupakan bukti berguna tentang penggunaan domain, namun bukan merupakan instruksi pembayaran yang harus diikuti oleh organisasi. Naskah ini mengusulkan proses defensif; tidak ada pembayaran, pembaruan akun, atau kontak eksternal yang dilakukan.
Pertahankan permintaan tanpa menjalankannya
Menunda perubahan yang diminta melalui proses pembelian atau keuangan yang ada. Catat apa yang diminta oleh pesan untuk diubah, catatan pemasok mana yang terpengaruh, kapan perubahan seharusnya diterapkan, dan siapa yang menerimanya. Hindari menyalin rincian keuangan lengkap ke dalam tiket insiden yang dapat diakses secara luas. Catatan terbatas yang disetujui dapat mempertahankan aslinya sementara ringkasan kerja menjelaskan perubahan menggunakan pengidentifikasi referensi dan konteks minimum yang diperlukan.
Pertahankan pesan asli dan asal usulnya. Salinan atau tangkapan layar yang diteruskan dapat membantu menunjukkan bagaimana permintaan muncul, namun tidak dapat dipertukarkan dengan pesan asli atau log penerima. Catat waktu pengumpulan dan zona waktu. Jika seseorang telah mengambil tindakan, lakukan eskalasi melalui prosedur insiden keuangan yang telah ditetapkan organisasi daripada berasumsi bahwa perubahan tersebut dapat dibatalkan secara diam-diam. Artikel ini tidak mengizinkan transfer, penarikan, atau komunikasi dengan bank.
Tetapkan identitas mana yang digunakan
Bandingkan domain Dari yang sebenarnya dengan domain pemasok di catatan vendor tepercaya. Simpan nama tampilan, alamat Balas Ke, identitas amplop dan DKIM penandatanganan domain terpisah. Pesan dengan domain berbeda dapat mengautentikasi domainnya sendiri sekaligus menyesatkan pembaca tentang afiliasi. Pesan domain pemasok yang tepat dengan autentikasi yang selaras masih dapat berasal dari akun atau layanan yang disalahgunakan. Jangan memilih hipotesis kompromi hanya karena permintaannya tidak biasa.
Gunakan bukti penerima yang tepercaya saat menafsirkan autentikasi. RFC 8601 menjelaskan alasannya Authentication-Results bidang memerlukan batas kepercayaan. Baris yang diberikan pengirim, tangkapan layar, atau kutipan header yang diteruskan mungkin tidak menentukan evaluasi penerima yang relevan. Catat penerima mana yang memberikan hasil dan jalur sejajar mana yang diamati. Ketika bukti tidak lengkap, katakan demikian daripada memaksakan kesimpulan lulus atau gagal dalam keputusan keuangan.
Verifikasi melalui jalur independen yang telah ditetapkan
Itu Penasihat BEC cloud-email IC3, yang diterbitkan pada 6 April 2020, merekomendasikan verifikasi independen atas permintaan bisnis yang mencurigakan. Gunakan rute kontak pemasok yang dibuat sebelum permintaan yang meragukan, seperti catatan vendor terverifikasi yang ada di organisasi. Nomor telepon baru, alamat email alternatif, atau tautan verifikasi yang hanya diberikan dalam pesan tersebut bukan merupakan sumber independen. Nasihat yang dikutip mendukung prinsip umum ini, bukan klaim kejadian saat ini.
Mintalah verifikator bisnis resmi untuk mengonfirmasi perubahan spesifik yang diusulkan melalui proses yang telah ditetapkan. Mengonfirmasi bahwa seseorang mengenali nama pengirim lebih lemah daripada mengonfirmasi bahwa perubahan itu sendiri telah diminta dan disetujui. Jika kebijakan memerlukan pemberi persetujuan terpisah, pertahankan pemisahan tersebut. Jangan biarkan urgensi dalam pesan menggantikan persyaratan persetujuan organisasi. Analis teknis dapat memberikan bukti identitas tetapi tidak boleh diam-diam menjadi pemberi persetujuan keuangan.
Koordinasikan penyelidikan teknis dengan hati-hati
Jika bukti mengarah pada penyalahgunaan akun pemasok, komunikasikan melalui kontak terverifikasi yang disetujui dan hanya bagikan bukti relevan yang telah disunting setelah otorisasi. Responden resmi pemasok memiliki penyelidikan atas sistem mereka. Organisasi penerima tidak boleh menyatakan bahwa mereka telah membuktikan pengambilalihan pemasok hanya karena pesan diautentikasi dan pemasok menolak permintaan pembayaran. Integrasi, pengirim yang didelegasikan, atau mekanisme lainnya mungkin memerlukan penyelidikan.
Panduan akun Microsoft yang disusupi mencantumkan aturan kotak masuk yang mencurigakan, penerusan dan pesan yang hilang di antara indikator yang mungkin, dan menjelaskan respons akun untuk Microsoft 365 . Ini adalah referensi untuk responden pemasok resmi di lingkungan tersebut, bukan izin untuk memeriksa akun organisasi lain. Tidak ada akses akun, pencabutan sesi, penghapusan aturan, atau pengumpulan kredensial yang merupakan bagian dari karya naskah ini.
Lembar kerja bukti perubahan pembayaran
Buat lembar kerja dengan empat bagian yang terhubung. Bagian permintaan mencatat referensi pemasok, jenis perubahan, tanggal permintaan dan pemilik bisnis. Bagian identitas mencatat domain aktual, pengamatan otentikasi tepercaya, dan sumber bukti. Bagian verifikasi mencatat rute kontak yang ditetapkan secara independen, verifikator resmi, pertanyaan dan respons yang tepat. Bagian keputusan mencatat persetujuan atau penolakan, pemberi persetujuan yang diperlukan, jalur penerapan yang diizinkan, dan penyelidikan apa pun yang belum terselesaikan.
Jauhkan pengidentifikasi rekening keuangan dari salinan tujuan umum. Gunakan placeholder yang konsisten jika perbandingan penting, dan simpan dokumen asli yang lengkap hanya di lokasi terbatas yang disetujui. Tambahkan kolom yang membedakan fakta yang diamati dari hipotesis. “ DKIM yang selaras dengan domain pemasok yang diamati pada penerima kami” adalah fakta hanya jika bukti mendukungnya; “pegawai pemasok menyetujui perubahan” memerlukan konfirmasi bisnis terpisah. Lembar kerja tidak boleh mempromosikan yang pertama ke yang terakhir secara otomatis.
Diagnosis fiktif: rangkaian pemasok yang familiar
Tim fasilitas fiktif menerima permintaan dalam percakapan pemasok yang sudah ada yang meminta untuk mengubah rincian pembayaran di masa depan. Pesan tersebut menggunakan domain asli pemasok dan secara hipotetis meneruskan DMARC ke penerima. Penerima menganggap thread yang ada dan hasil autentikasi membuat perubahan aman. Peninjau kedua malah menghentikan sementara pembaruan dan memeriksa catatan pemasok yang disetujui untuk rute verifikasi yang ditetapkan.
Dalam praktiknya, kontak pemasok menolak memberikan otorisasi terhadap perubahan tersebut. Respons tersebut mendukung penolakan permintaan dalam proses bisnis, namun mekanismenya masih belum terselesaikan hingga bukti teknis resmi tersedia. Investigasi akan mempertahankan pesan tersebut dan membagikan ringkasan minimal yang disetujui daripada meneruskan rincian pembayaran penuh secara luas. Ini adalah skenario fiksi, bukan penolakan nyata, penemuan kompromi, panggilan verifikasi, atau pencegahan kerugian. Ini menggambarkan mengapa verifikasi bisnis dan autentikasi domain menjawab pertanyaan yang berbeda.
Tutup jalur finansial dan teknis secara terpisah
Catat disposisi perubahan yang diminta meskipun penyelidikan teknis terus berlanjut. Sebaliknya, jangan menyatakan masalah bisnis terselesaikan hanya karena akun telah diamankan: seseorang mungkin telah mengubah catatan pemasok atau bertindak berdasarkan permintaan tersebut. Rekonsiliasi catatan bisnis aktual dengan keputusan resmi dan dokumen yang memverifikasi hasilnya. Tindakan semacam itu memerlukan wewenang normal organisasi; tidak ada yang dilakukan di sini.
Katalog tersebut memerlukan skenario penyalahgunaan yang telah disunting dengan bukti identitas, batas kendali, dan verifikasi bisnis independen. Bukti asli itu masih terbuka. Lembar kerja yang diusulkan dan latihan fiktif tidak memuaskan. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Versi yang dapat dipublikasikan memerlukan paket bukti resmi yang menunjukkan proses verifikasi tanpa mengungkap pengidentifikasi keuangan atau membuat tuduhan yang tidak didukung tentang pemasok.