Rancang respons sebelum mengumpulkan kandidat
Pemantauan domain serupa hanya berguna jika temuan dapat menghasilkan keputusan yang proporsional dan berbasis bukti. Domain yang menyerupai merek merupakan kandidat untuk ditinjau, bukan bukti penyalahgunaan. Proses pemantauan harus mendefinisikan apa yang diamatinya, bagaimana proses tersebut membedakan kecocokan leksikal dengan bukti operasional, siapa yang memiliki investigasi dan respons apa yang memerlukan persetujuan. Jika tidak, antrean peringatan yang besar dapat menyita perhatian tanpa meningkatkan kemampuan organisasi untuk menangani peniruan identitas yang sebenarnya.
RFC 9989, bagian 2.2, menjelaskan hal itu DMARC tidak membahas nama domain yang mirip secara visual atau penyalahgunaan nama tampilan. Domain lain mungkin mengautentikasi emailnya dengan benar. Oleh karena itu, pemantauan melengkapi autentikasi domain, bukan menggantikannya. Artikel ini mengusulkan alur kerja; ia tidak mendaftarkan domain, menanyakan daftar pantauan sebenarnya, mengirim pesan pengujian, mengunjungi situs mencurigakan, atau menghubungi pendaftar atau operator yang diduga.
Tentukan ruang lingkup yang dapat dipertahankan
Mulailah dengan domain organisasi yang terverifikasi, nama merek publik, dan hubungan bisnis yang penting bagi tujuan pemantauan. Catat siapa yang menyetujui cakupan tersebut dan mengapa setiap item disertakan. Hindari mengumpulkan nama pribadi atau data hubungan sensitif hanya karena alat mengizinkannya. Tentukan sumber observasi mana yang tersedia dan diizinkan, batas cakupannya, dan irama tinjauan yang diharapkan. Peringatan penyedia adalah bukti dari sumber tersebut pada saat itu, bukan bukti visibilitas lengkap di internet.
Pisahkan aturan perolehan kandidat dari aturan eskalasi. Aturan kandidat mungkin membandingkan kesamaan ejaan atau karakter; eskalasi memerlukan konteks tambahan seperti pesan menipu yang dilaporkan atau klaim bisnis menyesatkan yang diketahui. Usia pendaftaran, sertifikat atau catatan MX bisa menjadi konteks yang relevan, namun tidak satupun yang menunjukkan niat jahat. Demikian pula, tidak adanya data MX bukanlah jaminan lengkap bahwa suatu domain tidak dapat berpartisipasi dalam penipuan. Jangan mengubah indikator yang mudah digunakan menjadi keputusan universal.
Perlakukan kebingungan sebagai sinyal teknis
Standar Teknis Unicode 39 menjelaskan mekanisme untuk mendeteksi pengidentifikasi yang membingungkan dan memperingatkan bahwa perbandingan bisa menjadi terlalu inklusif. Kerangka atau hasil perbandingan terkait adalah hubungan teknis antar string, bukan temuan hukum, bukti kepemilikan bersama atau bukti bahwa penerima ditipu. Catat alat tersebut, versi data Unicode, dan metode perbandingan sehingga peninjau di masa mendatang dapat memahami alasan kandidat muncul.
Pisahkan string asli yang diamati dan representasi berorientasi DNS dari artefak perbandingan. Kerangka yang membingungkan bukanlah alamat untuk dikunjungi atau dipublikasikan di DNS . Jika suatu alat menormalkan atau menampilkan nama secara berbeda, pertahankan transformasi tersebut sebagai metadata. Tinjauan manusia harus mempertimbangkan audiens dan konteks yang dituju tanpa berasumsi bahwa nama-nama yang diinternasionalkan pada dasarnya mencurigakan. Organisasi yang sah menggunakan banyak skrip; proses pemantauan harus menghindari memperlakukan pilihan bahasa sebagai bukti pelanggaran.
Bangun tangga triase daripada tuduhan otomatis
Gunakan status seperti kandidat, ditinjau tanpa bukti pelecehan saat ini, diperlukan penyelidikan tambahan, bukti peniruan identitas yang terverifikasi, dan diselesaikan dengan hasil yang terdokumentasi. Tentukan bukti apa yang diperlukan untuk berpindah di antara keduanya. Peringatan dapat ditutup sebagai prioritas rendah tanpa menyatakan domain aman secara permanen. Insiden yang terverifikasi dapat tetap terbuka selama kepemilikan respons ditetapkan. Ini adalah label alur kerja internal yang diusulkan, bukan klasifikasi standar industri atau kemampuan vendor.
Untuk setiap kandidat, catat kesamaan yang diamati, sumber dan waktu, klaim afiliasi jika ada, proses bisnis yang terpengaruh, bukti pesan yang tersedia, dan pertanyaan yang belum terselesaikan. Jangan menyelidiki akun, mendaftarkan sumber daya, atau mengirimkan pesan untuk menguji apakah penyalahgunaan mungkin terjadi. Jika analisis lebih mendalam diperlukan, arahkan ke proses keamanan resmi. Setiap keluhan eksternal, permintaan penghapusan, atau komunikasi memerlukan persetujuan yang relevan dan bukti pendukung; pencocokan leksikal otomatis saja tidak akan menimbulkan tuduhan.
Hubungkan laporan pesan ke identitas tepercaya
Ketika pesan yang dilaporkan tersedia melalui saluran resmi, bandingkan domain Dari sebenarnya, nama tampilan, dan tindakan yang diminta dengan identitas bisnis yang diharapkan. Pertahankan hasil otentikasi penerima yang relevan dengan asalnya. RFC 8601 menjelaskan mengapa an Authentication-Results pernyataan membutuhkan batasan yang dapat dipercaya. Jangan perlakukan baris sandi yang disalin sebagai bukti yang cukup bahwa domain asing diautentikasi pada penerima penerima.
Pesan domain berbeda yang diautentikasi dengan benar masih dapat menipu, sedangkan pesan sah dari mitra bisnis baru mungkin tidak dikenal dan tidak berbahaya. Responsnya tergantung pada afiliasi dan permintaan spesifik. Verifikasi independen melalui kontak bisnis yang mapan dapat menyelesaikan pertanyaan tersebut secara lebih langsung daripada mengumpulkan varian ejaan tambahan. Itu Penasihat IC3 BEC, tertanggal 2020, mendukung kontrol verifikasi umum ini, bukan klaim tentang layanan pemantauan saat ini.
Lembar kerja proses respons
Buat lembar kerja dengan pengidentifikasi kandidat, ejaan asli, representasi DNS yang dinormalisasi saat divalidasi, metode perbandingan, sumber observasi, stempel waktu, pemilik cakupan, dan status saat ini. Tambahkan bukti penggunaan aktual, pengguna atau alur kerja yang terpengaruh, dasar keyakinan, respons yang diusulkan, otorisasi yang diperlukan, dan tanggal tindak lanjut. Simpan bidang terpisah untuk hal-hal yang tidak dapat dibuat oleh sumber. Hal ini mencegah munculnya presisi dari skor alat untuk menutupi kesimpulan yang tidak pasti.
Tentukan bukti penutupan untuk setiap respons. Peringatan internal harus mengidentifikasi audiens dan basisnya tanpa mengulangi konten sensitif. Sebuah blok harus memiliki pemilik resmi dan rencana peninjauan untuk positif palsu. Laporan eksternal harus didukung dan disetujui secara faktual. Ini hanyalah pertimbangan desain proses saja; tidak ada blok, peringatan atau laporan yang dibuat di sini. Tinjau beban kerja dan kasus berdampak tinggi yang belum terselesaikan serta jumlah peringatan mentah saat mengevaluasi apakah proses tersebut bermanfaat.
Diagnosis fiktif: kandidat dengan nilai tinggi
Alat pemantau merek fiktif menandai domain yang menyerupai nama pemasok. Skor kemiripannya tinggi, namun peringatan tersebut tidak berisi pesan, konten situs web, atau klaim afiliasi. Analis mencatatnya sebagai kandidat, bukannya menyebut operatornya jahat. Kemudian, pengguna bisnis memberikan laporan pesan resmi yang menggunakan domain kandidat dan meminta perubahan catatan pemasok yang tidak biasa. Bukti pesan mengubah prioritas penyelidikan, bukan skor leksikal.
Tim akan membandingkan hasil penerima tepercaya dan memverifikasi perubahan yang diminta dengan pemasok menggunakan rute kontak yang ada. Jika pemasok menolak permintaan tersebut, kasus tersebut dapat mendokumentasikan fakta yang telah diverifikasi tersebut dan meminta persetujuan untuk memberikan tanggapan yang sesuai. Tim hipotetis tidak mendaftarkan domain, menguji login atau mengirim a phishing pesan untuk membuktikan suatu hal. Ini adalah proses yang dibuat-buat, bukan domain yang diamati, keluhan nyata, atau tindakan penegakan hukum yang telah selesai.
Jaga agar prosesnya tetap akuntabel dan berdasarkan bukti
Tinjau hasil positif palsu, kandidat yang belum terselesaikan, penundaan respons, dan dampak bisnis dari kasus yang dikonfirmasi. Jangan mengklaim bahwa peningkatan jumlah peringatan berarti serangan meningkat tanpa memeriksa cakupan sumber dan perubahan aturan. Jangan mengklaim bahwa antrian yang sepi membuktikan tidak adanya peniruan identitas. Simpan informasi versi yang cukup untuk menjelaskan mengapa domain yang sama mungkin menerima skor berbeda setelah alat atau pembaruan data Unicode.
Skenario penyalahgunaan yang diperlukan dengan bukti identitas, batas kendali, dan verifikasi bisnis independen masih belum ada. Latihan fiksi tidak dapat memenuhi persyaratan tersebut. Semua gerbang pelepasan tetap terbuka, dan tidak ada pengamatan pemantauan asli yang dinyatakan sebagai pekerjaan yang telah selesai. Sebelum dipublikasikan, dapatkan bukti resmi, mintalah spesialis meninjau kriteria respons, memverifikasi penerapan sumber dan rute produksi, menyelesaikan pemeriksaan aksesibilitas, dan mengamankan pelepasan pemilik. Tujuannya adalah proses pengambilan keputusan praktis, bukan janji untuk menemukan atau menghilangkan semuanya domain yang mirip.