Remediasi setelah pentest: dari temuan ke retest

Remediasi pentest adalah serangkaian tindakan yang dilakukan tim Anda setelah laporan penetration testing diserahkan: membaca temuan, menetapkan urutan penanganan, memperbaiki, mendokumentasikan bukti, dan meminta retest. Laporan tidak memperbaiki apa pun sendiri, dan jarak antara temuan yang dikonfirmasi dengan sistem yang benar-benar lebih aman bergantung sepenuhnya pada seberapa sistematis proses yang dijalankan.

Triase temuan sebelum perbaikan dimulai

Tidak semua temuan perlu ditangani dalam minggu yang sama. Triase adalah langkah pertama: mengurutkan temuan berdasarkan tingkat keparahannya, lalu menetapkan tenggat per kelompok. Pemeringkatan yang umum digunakan mengikuti Common Vulnerability Scoring System (CVSS) v3.1 dari Forum of Incident Response and Security Teams (FIRST), dengan skor 0 sampai 10.

Pembagian tingkat keparahannya berasal dari CVSS, tetapi tenggatnya tidak. Dokumen CVSS dari FIRST mendefinisikan skala 0 sampai 10 beserta rentangnya tanpa menetapkan tenggat remediasi, dan tidak ada regulasi Indonesia yang menetapkannya, jadi target di kolom kanan adalah saran kami untuk klien, bukan standar yang bisa dikutip.

FIRST juga menegaskan bahwa skor CVSS mengukur tingkat keparahan, bukan risiko, dan perlu dilengkapi dengan konteks lingkungan dan ancaman Anda sendiri. Di situlah target perlu digeser. Majukan sebuah temuan bila sistemnya menghadap internet, bila kerentanannya sedang dieksploitasi di dunia nyata (katalog Known Exploited Vulnerabilities dari CISA bisa jadi cek cepat), bila asetnya menyimpan data nasabah atau data pribadi, atau bila asetnya menopang layanan kritis. Mundurkan hanya bila ada kontrol kompensasi yang nyata, misalnya sistemnya tidak bisa dijangkau dari jaringan yang tidak tepercaya, dan tuliskan alasannya. Temuan High pada API pembayaran yang menghadap internet dan sudah dieksploitasi layak diperlakukan sebagai Critical, sedangkan temuan Critical pada server uji yang terisolasi dan tanpa data mungkin tidak.

Satu hal yang perlu diperhatikan: temuan Low yang berdiri sendiri memang risikonya kecil. Tetapi jika ada beberapa temuan Low pada sistem yang sama dan bisa dirantaikan, nilai kumulatifnya naik jauh. Laporan yang baik akan menandai kombinasi seperti ini.

Siapa yang memperbaiki apa

Penetration testing menyentuh berbagai lapisan sistem, dan setiap lapisan biasanya dimiliki oleh tim yang berbeda.

Kerentanan pada kode aplikasi, misalnya SQL injection, broken access control, atau logika bisnis yang cacat, diserahkan ke tim pengembang. Kerentanan pada konfigurasi server, firewall, atau jaringan ditangani oleh tim infrastruktur atau operasi. Masalah pada kebijakan akses, manajemen hak istimewa, atau pemisahan tugas membutuhkan keterlibatan IT governance atau kepala divisi, karena perubahan kebijakan melewati proses persetujuan yang berbeda. Temuan yang membutuhkan perubahan arsitektur besar biasanya harus diputuskan oleh manajemen atau CTO, bukan hanya tim teknis.

Laporan yang disusun dengan baik mencantumkan pemilik yang disarankan untuk setiap temuan. Jika laporan tidak mencantumkannya, langkah pertama diskusi remediasi adalah memetakan setiap temuan ke tim yang tepat sebelum menetapkan tenggat apa pun.

Tenggat perbaikan yang masuk akal per tingkat keparahan

Critical tidak harus berarti "perbaiki dalam satu jam." Artinya ada dua tenggat yang terpisah. Karantina lebih dulu, dalam 24 jam: isolasi sistem yang terpapar, nonaktifkan endpoint yang rentan, atau cabut token yang bocor. Perbaikan akar masalah menyusul, dengan target sekitar satu minggu. Karantina memberi waktu, tetapi bukan perbaikan. Kalau perbaikan sebenarnya memang butuh waktu lebih lama, misalnya karena menyangkut perubahan arsitektur, catat sebagai penerimaan risiko yang berbatas waktu dengan karantina yang terdokumentasi, jangan biarkan tenggatnya mundur diam-diam.

High lebih fleksibel: umumnya bisa diselesaikan dalam sprint dua mingguan tanpa menekan jadwal terlalu keras. Medium cocok untuk sprint normal, tidak perlu dipercepat. Low dan Informational bisa dibundel ke dalam pembaruan berkala, karena energi yang dikeluarkan untuk memperbaiki semuanya sekaligus tidak sebanding dengan risiko yang dihindari.

Alur remediasi dari temuan ke penutupan

Diagram berikut menunjukkan alur khas dari laporan yang diserahkan hingga temuan ditutup atau risikonya diterima secara formal. Panah kembali dari langkah Retest ke Perbaikan menggambarkan situasi di mana bukti yang dikirimkan belum cukup atau perbaikan yang dilakukan tidak sepenuhnya menjawab temuan.

Bukti perbaikan yang diterima penguji

Retest tidak bisa berjalan tanpa bukti yang bisa diverifikasi. Penguji perlu melihat bahwa perubahan yang diklaim memang diterapkan dan bahwa perubahan itu menjawab temuan secara tepat, bukan hanya menyembunyikan gejalanya.

Proof-of-concept yang semula berhasil lalu gagal setelah perbaikan adalah bukti yang berguna, tetapi belum cukup. Eksploit awal bisa gagal karena hal yang tidak ada hubungannya dengan kerentanannya: filter yang hanya memblokir payload itu, kredensial yang sudah diganti, atau endpoint yang kebetulan mati saat retest. Jadi penguji mencari keduanya: bukti bahwa akar masalahnya diperbaiki, seperti commit, perubahan konfigurasi, atau patch, dan jalur eksploitasi yang tetap tertutup ketika serangannya divariasikan.

Bagaimana retest berjalan

Retest bukan pengujian ulang penuh, tetapi juga bukan sekadar mengulang satu permintaan. Penguji memastikan perbaikan diterapkan pada akar masalahnya, menjalankan proof-of-concept dari laporan awal terhadap sistem yang sudah diperbaiki, lalu mencoba variasi yang wajar: encoding payload yang berbeda, parameter atau endpoint di sebelahnya, peran pengguna lain. Kalau salah satunya masih berhasil, temuan tetap terbuka. Kalau eksploit awal sekarang gagal hanya karena aturan WAF atau filter input memblokir payload itu, temuan dicatat sebagai termitigasi, bukan ditutup, dan perbaikan akar masalahnya tetap dalam daftar. Temuan ditutup bila akar masalahnya sudah diperbaiki dan variasinya juga gagal, lalu hasilnya dicatat.

Hasil retest diterbitkan sebagai adendum laporan awal, bukan sebagai laporan baru. Ini penting karena manajemen, auditor, dan mitra yang memegang laporan asli bisa melihat progres tanpa meminta dokumen terpisah. Adendum menunjukkan temuan mana yang tertutup, temuan mana yang masih terbuka, dan untuk yang terbuka, apakah statusnya masih dalam perbaikan atau sudah diputuskan sebagai risiko yang diterima secara formal.

Waktu antara pengiriman bukti perbaikan dan jadwal retest biasanya disepakati di awal keterlibatan. Hubungi tim kami lebih awal jika perbaikan selesai lebih cepat dari jadwal, karena slot retest yang kosong tidak selalu langsung tersedia.

Temuan yang tidak bisa diperbaiki saat ini

Beberapa temuan tidak bisa diselesaikan dalam waktu normal: sistem lama yang tidak lagi didukung vendor, arsitektur yang membutuhkan perancangan ulang besar, atau dependensi pihak ketiga yang pembaruannya belum tersedia. Dalam kasus ini, pilihan yang tersedia adalah menerima risiko secara formal dan mendokumentasikan kontrol kompensasi.

Kontrol kompensasi adalah tindakan yang mengurangi kemungkinan atau dampak eksploitasi tanpa memperbaiki kerentanan: membatasi akses jaringan ke sistem yang rentan, memperketat pemantauan log, atau memisahkan sistem dari segmen yang lebih kritis. Kontrol ini perlu terdokumentasi secara tertulis dengan mencakup siapa yang mengambil keputusan, mengapa perbaikan tidak bisa dilakukan sekarang, apa yang diterapkan sebagai penggantinya, dan kapan situasinya akan ditinjau ulang.

Penerimaan risiko bukan keputusan yang bisa diambil secara diam-diam. Dalam lingkungan yang diawasi regulator, keputusan ini biasanya perlu masuk ke dokumentasi manajemen risiko TI dan diketahui oleh pengambil keputusan di level yang sesuai.

Remediasi dan kewajiban pelaporan di Indonesia

Bagi bank umum, aturan pelaporannya bergantung pada jenis pengujiannya. Penetration test termasuk pengujian berdasarkan analisis kerentanan, dan hasilnya disampaikan ke OJK secara kompilasi dalam laporan kondisi terkini penyelenggaraan TI, paling lambat 15 hari kerja setelah akhir tahun pelaporan (SEOJK 29/2022 romawi VII.4.b.1). Pengujian berbasis skenario dilaporkan dalam 10 hari kerja, dan pengujian dianggap selesai saat laporan hasilnya selesai disusun, bukan saat pengujian berhenti (romawi VII.4.b.2). Format laporan pengujian skenario di Lampiran VI punya kolom untuk perbaikan yang sudah dilakukan dan kolom rencana tindak lanjut untuk temuan yang masih terbuka, dan isi keduanya persis yang dihasilkan adendum retest.

ISO/IEC 27001:2022 mengaturnya di kontrol Annex A 8.8, manajemen kerentanan teknis (A.12.6.1 pada edisi 2013), yang meminta kerentanan diidentifikasi, dinilai, dan ditangani. Auditor sertifikasi lazim meminta bukti bahwa temuan benar-benar ditutup, dan adendum retest adalah bukti yang paling rapi untuk itu.

UU PDP tidak menyebut jenis pengujian tertentu. Pasal 35 mewajibkan pengendali melindungi dan memastikan keamanan data pribadi melalui langkah teknis operasional, dengan tingkat keamanan yang disesuaikan dengan sifat dan risiko datanya. Rekam jejak remediasi dari temuan sampai perbaikan terverifikasi adalah bukti bahwa langkah itu benar-benar berjalan.

Untuk langkah-langkah pengujian lebih lanjut, termasuk cakupan dan durasi, lihat pentest website dan aplikasi dan berapa lama penetration testing berlangsung.