Sebuah kompromi DKIM kunci pribadi dapat membiarkan penyerang membuat tanda tangan yang memverifikasi di bawah domain penandatanganan yang terpengaruh. Perlakukan peristiwa tersebut sebagai insiden otoritas penandatanganan. Mengganti data DNS hanyalah salah satu bagian dari penahanan, dan verifikasi DKIM saja tidak dapat membedakan penandatangan resmi dari penyerang yang memegang kunci yang sama.
Tetapkan otoritas yang terkena dampak
Identifikasi domain penandatanganan, penyeleksi, penjaga kunci, dan setiap layanan menggunakan kunci pribadi. Pertahankan log audit yang relevan, konfigurasi, dan perwakilan pesan mencurigakan tanpa menyalin rahasia ke dalam tiket atau obrolan. Catat waktu penemuan, kemungkinan jangka waktu paparan, dan apa yang diketahui versus apa yang diduga.
Pisahkan pencurian kunci pribadi dari akses tidak sah ke layanan penandatanganan. Penyerang dengan akses akun dapat terus menandatangani setelah rotasi kunci kecuali akses tersebut terdapat. Kompromi administrasi DNS adalah ketergantungan lain yang memerlukan responsnya sendiri. Koordinasikan investigasi ini di bawah pemilik insiden.
Hentikan penyalahgunaan baru dan cabut jalur verifikasi lama
Tangguhkan rute penandatanganan atau kredensial yang terpengaruh melalui proses insiden yang disetujui. RFC 6376 mengizinkan pencabutan dengan menerbitkan nilai p kosong. Menghapus kunci juga mencegah pengambilan yang berhasil setelah ketidakhadiran terlihat. Pilih respons yang didukung oleh platform dan verifikasi persisnya pemilih dan domain sebelum mengubahnya.
Pencabutan tidak terjadi secara instan pada setiap penerima. Data dan pesan DNS yang di-cache yang sudah dievaluasi membuat batas yang bergantung pada waktu. Jangan menjanjikan bahwa perubahan DNS akan membatalkan tanda tangan dalam email yang dikirimkan atau membuktikan bahwa tidak ada pesan kasar yang diterima.
Rotasi normal yang tumpang tindih mempertahankan verifikasi untuk pesan sah yang diantrekan. Selama kompromi, menjaga agar kunci yang terekspos dapat diverifikasi juga dapat menjaga kemampuan penyerang. Pemilik insiden harus mempertimbangkan pengendalian terhadap kegagalan surat yang tertunda daripada menerapkan jadwal rutin yang tumpang tindih secara otomatis.
Pulihkan penandatanganan melalui jalur yang bersih
Hasilkan material kunci pengganti melalui proses pendukung yang tepercaya setelah mengatasi penyebab paparan. Lebih memilih pemilih baru yang didukung sehingga bukti lama dan baru dapat dibedakan. Terapkan persyaratan kriptografi saat ini. Untuk penandatanganan RSA, RFC 8301 memerlukan rsa-sha256 daripada rsa-sha1 dan merekomendasikan setidaknya 2048-bit kunci.
Tanggapan ilustratif: penjualan pemilih1 diekspos dan akun penandatanganannya terdapat. Penanda tangan yang bersih menggunakan sales2 sementara sales1 dicabut. Email terkontrol baru diverifikasi dengan sales2 dan disejajarkan dengan Dari; surat tertunda yang ditandatangani dengan sales1 mungkin gagal. Contoh ini menggambarkan trade-off yang eksplisit, bukan insiden yang sudah selesai atau jaminan perilaku penerima secara universal.
Verifikasi pemulihan dan pertahankan ketidakpastian
Uji setiap rute yang terpengaruh, bukan hanya satu kotak surat. Simpan pesan mentah dan hasil tepercaya, periksa pemilih baru, konfirmasi penyelarasan dan verifikasi bahwa kredensial yang disusupi tidak lagi mengizinkan penandatanganan. Tinjau log penyedia dan laporan penerima untuk periode paparan, dengan memperhatikan bahwa laporan tidak mencakup setiap penerima atau membuktikan siapa yang mengirim setiap pesan.
Pertahankan garis waktu penahanan, observasi DNS , penerapan penggantian, dan penilaian dampak pelanggan. Jaga akses salinan forensik tetap terkendali. Tutup insiden hanya dengan pemilik yang teridentifikasi untuk penyelidikan selanjutnya dan perbaikan hak asuh kunci atau kegagalan akses. Tanda tangan baru yang berhasil membuktikan bahwa jalur pemulihan berhasil; hal ini tidak dengan sendirinya menetapkan cakupan penuh dari penyalahgunaan yang terjadi sebelumnya.
Latih meja sebelum keadaan darurat
Dalam garis waktu sintetis ini, akun layanan A menampung penjualan1 dan akun bersih B menampung penjualan2. Pada menit ke nol, berisi A. Pada menit pertama, publikasikan pencabutan sales1. Pada menit kedua, penyelesai fiksi masih memiliki kunci cache lama, sehingga tanda tangan lama mungkin tetap dapat diverifikasi di sana. Pada menit ketiga, mulailah rute penjualan2 bersih. Pada menit ke tiga puluh, kumpulkan hasil yang diterima per rute dan akses bukti daripada mendeklarasikan pemulihan dari DNS saja. Pengaturan waktu ini menggambarkan pengurutan, bukan interval propagasi yang dijanjikan.
Bagian atas meja tertulis ini mengusulkan lima observasi pemulihan yang diperlukan: akses lama dinonaktifkan, penyebab paparan termuat, kunci baru dipublikasikan, tanda tangan baru diverifikasi, dan tanda tangan baru diselaraskan. Skenario dengan email baru yang lewat tetapi akses lama masih aktif gagal dalam gerbang pemulihan. Skenario yang memuaskan kelimanya melewati gerbang yang dimodelkan. Kedua rangkaian observasi tersebut bersifat sintetik; tidak ada program meja, penyewa, atau pengujian pesan yang dijalankan. Penahanan aktual, pengamatan cache, persetujuan, dan pengujian pesan tetap diperlukan selama insiden nyata.
Tetapkan pemilik untuk setiap gerbang pemulihan yang belum terselesaikan
Kasus tertulis KEY-01 mengasumsikan pemilih pengganti sales2 menghasilkan tanda tangan yang selaras untuk Dari sales@example.org dengan d=example.org, namun akun layanan lama tetap aktif. Pemilik insiden harus menjaga pemulihan tetap terbuka dan mengatasi pembatasan akses; pengujian tanda tangan administrator email yang berhasil tidak dapat menutup kesenjangan tersebut. Cache penyelesai lama dan cakupan penyalahgunaan di masa lalu masih belum diketahui. Identitas dan hasil ditetapkan sebagai asumsi pengajaran, bukan kejadian yang dilaksanakan.