Perusahaan tidak pernah kekurangan temuan keamanan.

Setiap pemindaian dapat menghasilkan daftar kerentanan baru. Audit menambahkan catatan perbaikan. Penetration testing mengungkap jalur serangan yang sebelumnya tidak terlihat. Berbagai perangkat keamanan terus mengirimkan peringatan ke dashboard tim teknologi informasi.

Namun, banyaknya temuan tidak selalu membuat perusahaan lebih aman.

Persoalan sesungguhnya baru dimulai setelah sebuah kerentanan diketahui. Perusahaan harus menentukan siapa yang bertanggung jawab, seberapa besar risikonya, kapan perbaikan dilakukan, dan bagaimana memastikan bahwa perubahan tersebut benar-benar menutup celah.

Pada titik inilah kualitas program keamanan diuji.

Perusahaan yang mampu menemukan kerentanan tetapi membutuhkan waktu berbulan-bulan untuk memperbaikinya sebenarnya hanya memiliki visibilitas, bukan ketahanan. Mereka mengetahui bahwa sebuah pintu terbuka, tetapi membiarkannya tetap terbuka karena proses internal tidak mampu mengambil tindakan dengan cukup cepat.

Karena itu, ukuran kematangan keamanan tidak semestinya hanya berpusat pada jumlah temuan, jumlah perangkat yang digunakan, atau frekuensi audit. Perusahaan juga perlu melihat Mean Time to Remediate, yaitu waktu rata-rata yang dibutuhkan untuk mengubah temuan keamanan menjadi pengurangan risiko yang nyata.

Banyak Temuan Tidak Sama dengan Banyak Risiko yang Diselesaikan

Program keamanan sering dinilai berdasarkan aktivitas.

Semakin sering perusahaan menjalankan vulnerability assessment, semakin aktif program tersebut terlihat. Semakin tebal laporan penetration testing, semakin serius pula pengujiannya dianggap. Semakin banyak tiket keamanan dibuat, semakin sibuk tim keamanan tampak bekerja.

Logika ini bermasalah karena aktivitas tidak selalu menghasilkan perubahan.

Sebuah laporan dapat memuat puluhan temuan berisiko tinggi, tetapi risiko tersebut tetap tersedia bagi penyerang selama perbaikannya belum dilakukan. Pemindaian yang dijalankan setiap minggu juga tidak memiliki nilai maksimal apabila hasilnya hanya menambah vulnerability backlog.

Perusahaan bahkan dapat mengalami situasi ketika jumlah temuan bertambah lebih cepat daripada kapasitas tim untuk menanganinya. Pada kondisi seperti ini, organisasi memperoleh semakin banyak informasi, tetapi tidak semakin mampu melindungi sistem.

Kerentanan yang sudah diketahui namun tidak diperbaiki juga memiliki karakter yang berbeda dari kelemahan yang belum ditemukan. Perusahaan tidak lagi dapat mengatakan bahwa masalah tersebut berada di luar pengetahuan mereka.

Risiko tersebut telah terlihat, didokumentasikan, dan disampaikan kepada pihak terkait. Ketika masih dibiarkan terbuka, persoalannya bukan lagi keterbatasan deteksi, melainkan keterlambatan pengambilan tindakan.

Ancaman Bergerak Lebih Cepat daripada Proses Internal Perusahaan

Laporan Verizon Data Breach Investigations Report 2025 menunjukkan bahwa eksploitasi kerentanan terus meningkat sebagai salah satu jalur awal terjadinya kebocoran data. Eksploitasi kerentanan tercatat terlibat dalam 20% kasus kebocoran yang dianalisis, meningkat 34% dibandingkan laporan sebelumnya.

Pertumbuhan tersebut menunjukkan bahwa penyerang semakin aktif memanfaatkan kelemahan yang tersedia pada perangkat, aplikasi, layanan edge, virtual private network, dan infrastruktur yang dapat diakses dari internet.

Masalahnya, tempo serangan tidak mengikuti jadwal rapat perusahaan.

Penyerang tidak menunggu perubahan mendapatkan persetujuan dari seluruh unit. Mereka tidak perlu menyesuaikan aktivitas dengan periode maintenance. Mereka juga tidak harus mempertimbangkan apakah tim pengembangan sedang mengejar target peluncuran fitur baru.

Begitu informasi teknis, kode eksploitasi, atau metode serangan tersedia, sebuah kerentanan dapat berubah menjadi risiko nyata dalam waktu singkat.

Sebaliknya, proses remediasi di dalam perusahaan sering berjalan melalui jalur yang panjang. Temuan harus dikonfirmasi, dimasukkan ke sistem tiket, disampaikan kepada pemilik aplikasi, dibahas dengan developer, dijadwalkan, diuji, disetujui, diterapkan, lalu diperiksa kembali.

Tidak semua tahapan tersebut perlu dihilangkan. Pengujian perubahan dan pengendalian operasional tetap penting. Namun, proses yang terlalu lambat dapat menciptakan jarak berbahaya antara kecepatan penyerang dan kecepatan organisasi.

Mean Time to Remediate membuat jarak tersebut terlihat.

MTTR Bukan Hanya Rumus, tetapi Cermin Cara Perusahaan Bekerja

Dalam konteks vulnerability management, Mean Time to Remediate atau MTTR menggambarkan rata-rata waktu yang dibutuhkan sejak suatu temuan keamanan dikonfirmasi hingga risiko tersebut diperbaiki atau dimitigasi secara memadai.

Secara sederhana, MTTR dapat dihitung dengan membagi total waktu penyelesaian seluruh temuan dengan jumlah temuan yang berhasil diselesaikan dalam periode tertentu.

Rumus tersebut terlihat mudah. Namun, angka yang dihasilkan dapat kehilangan makna apabila perusahaan tidak menetapkan definisi yang jelas.

Pertanyaan pertama adalah kapan waktu mulai dihitung.

Apakah sejak kerentanan pertama kali terdeteksi oleh alat pemindai? Sejak tim keamanan memvalidasinya? Sejak tiket dikirim kepada pemilik sistem? Atau sejak pihak teknis menyatakan menerima tugas perbaikan?

Pertanyaan berikutnya adalah kapan remediasi dianggap selesai.

Apakah ketika developer menyatakan kode telah diperbarui? Ketika patch dipasang? Ketika tiket ditutup? Atau setelah pengujian ulang membuktikan bahwa jalur serangan tidak lagi dapat digunakan?

Tanpa kesepakatan tersebut, perusahaan dapat memiliki angka MTTR yang tampak baik tetapi tidak mewakili kondisi sebenarnya.

Tiket dapat ditutup meskipun perbaikannya belum diuji. Mitigasi sementara dapat dicatat sebagai remediasi permanen. Temuan yang sulit ditangani dapat dikeluarkan dari perhitungan. Akibatnya, metrik terlihat membaik, sedangkan risiko yang sebenarnya masih tetap terbuka.

MTTR yang sehat harus mengukur pengurangan risiko, bukan sekadar kecepatan administrasi dalam menutup tiket.

Angka MTTR Mengungkap Masalah yang Tidak Terlihat pada Dashboard

Ketika waktu remediasi terlalu panjang, penyebabnya tidak selalu terletak pada kemampuan teknis.

Sebagian besar perusahaan sebenarnya mampu memahami rekomendasi perbaikan. Mereka mengetahui bahwa versi perangkat lunak perlu diperbarui, konfigurasi harus diperketat, autentikasi perlu diperbaiki, atau validasi input harus ditambahkan.

Keterlambatan biasanya muncul karena tanggung jawab dan prioritas tidak tersusun dengan jelas.

Tim keamanan menemukan kerentanan, tetapi tidak memiliki akses untuk memperbaiki aplikasi. Developer dapat memperbarui kode, tetapi sedang mengejar target bisnis yang dianggap lebih mendesak. Tim infrastruktur dapat memasang patch, tetapi khawatir perubahan menyebabkan gangguan. Pemilik bisnis memahami pentingnya sistem, tetapi tidak mengerti konsekuensi teknis dari temuan.

Akhirnya, setiap pihak mengetahui keberadaan masalah, tetapi tidak ada yang benar-benar memiliki kewenangan dan tanggung jawab penuh untuk menyelesaikannya.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Temuan tidak selalu tertunda karena perusahaan tidak peduli terhadap keamanan. Sering kali, hambatannya justru berasal dari struktur organisasi yang belum mampu menghubungkan hasil pengujian dengan proses pengambilan keputusan.

MTTR kemudian berubah menjadi indikator tata kelola.

Angka tersebut memperlihatkan apakah perusahaan memiliki pemilik risiko yang jelas, jalur eskalasi yang berjalan, proses perubahan yang proporsional, serta dukungan manajemen ketika perbaikan membutuhkan biaya atau waktu tambahan.

CVSS Tinggi Tidak Selalu Berarti Harus Menjadi Urutan Pertama

Salah satu kesalahan paling umum dalam remediation management adalah menggunakan skor CVSS sebagai satu-satunya dasar prioritas.

CVSS berguna untuk menggambarkan karakteristik dan tingkat keparahan teknis sebuah kerentanan. Namun, skor tersebut bukan pengukuran risiko bisnis secara lengkap.

Dua kerentanan dengan skor CVSS yang sama dapat membawa konsekuensi yang sangat berbeda.

Kerentanan pertama mungkin berada pada server pengujian yang tidak terhubung ke internet dan tidak menyimpan data sensitif. Kerentanan kedua dapat berada pada sistem produksi yang digunakan pelanggan, terekspos secara publik, dan memiliki akses ke informasi bisnis penting.

Menganggap keduanya memiliki prioritas identik justru dapat membuang kapasitas remediasi.

Penentuan urutan perbaikan perlu mempertimbangkan konteks yang lebih luas, seperti nilai aset, eksposur jaringan, ketersediaan eksploitasi, sensitivitas data, hak akses yang dapat diperoleh, dan kemungkinan kerentanan digunakan sebagai bagian dari attack path.

Perusahaan juga perlu memperhatikan apakah suatu kerentanan telah diketahui aktif dieksploitasi. CISA mengelola Known Exploited Vulnerabilities Catalog untuk membantu organisasi memusatkan perhatian pada kerentanan yang telah memiliki bukti eksploitasi di dunia nyata.

Pendekatan ini tidak berarti temuan dengan skor lebih rendah boleh diabaikan. Kerentanan berisiko menengah dapat menjadi penting apabila dapat dirangkai dengan kelemahan lain untuk menghasilkan dampak yang lebih besar.

Prioritas yang matang bukan sekadar memilih skor tertinggi. Prioritas berarti memahami kerentanan mana yang paling mungkin membawa perusahaan menuju insiden nyata.

MTTR Tidak Seharusnya Menjadi Satu Angka untuk Semua Temuan

Mencampurkan seluruh kerentanan ke dalam satu angka rata-rata dapat menghasilkan kesimpulan yang menyesatkan.

Perusahaan mungkin menutup puluhan temuan informasional dalam waktu satu hari, tetapi membiarkan satu kerentanan kritis terbuka selama tiga bulan. Secara statistik, rata-rata waktu remediasi masih dapat terlihat rendah.

Padahal, risiko terbesar justru berada pada temuan yang tidak terselesaikan.

Karena itu, MTTR perlu dikelompokkan berdasarkan karakteristik risiko, antara lain:

• Tingkat keparahan temuan
• Aset yang terdampak
• Sistem internal atau internet-facing
• Lingkungan produksi atau pengujian
• Aplikasi, API, jaringan, atau infrastruktur
• Ketersediaan kode eksploitasi
• Status eksploitasi aktif
• Unit atau pemilik sistem
• Jenis remediasi yang diperlukan

Perusahaan juga sebaiknya tidak hanya menggunakan rata-rata. Median waktu remediasi dapat memberikan gambaran yang lebih stabil ketika terdapat beberapa temuan yang membutuhkan waktu sangat lama.

Selain itu, metrik lain perlu dibaca bersama MTTR, seperti persentase temuan yang melewati remediation SLA, usia kerentanan tertua, jumlah temuan kritis yang masih terbuka, dan rasio temuan yang muncul kembali setelah dinyatakan selesai.

Pendekatan tersebut memberikan gambaran yang lebih jujur daripada satu angka yang dipaksakan untuk mewakili seluruh kondisi keamanan.

Remediasi Sering Terhambat oleh Masalah Organisasi

Perusahaan dapat memiliki tim keamanan yang baik dan tetap mengalami waktu remediasi yang panjang. Penyebabnya sering berada di luar ruang kerja tim security.

Inventaris aset tidak akurat

Perusahaan tidak dapat memperbaiki risiko dengan cepat apabila tidak mengetahui siapa pemilik sistem, versi perangkat lunak yang digunakan, hubungan antarserver, dan proses bisnis yang bergantung pada aset tersebut.

Ketidakjelasan ini membuat setiap temuan memerlukan investigasi tambahan sebelum perbaikan dapat dimulai.

Tidak tersedia kapasitas untuk security debt

Tim pengembangan sering dinilai berdasarkan kecepatan merilis fitur. Perbaikan keamanan kemudian dianggap sebagai pekerjaan tambahan yang tidak menghasilkan nilai bisnis secara langsung.

Ketika tidak ada kapasitas khusus untuk security debt, temuan pentest terus dipindahkan ke sprint berikutnya.

Change management tidak proporsional

Pengendalian perubahan dibutuhkan untuk mencegah gangguan. Namun, proses yang sama untuk setiap jenis perubahan dapat memperlambat penanganan kerentanan mendesak.

Perusahaan membutuhkan jalur perubahan darurat yang tetap terkontrol, tetapi cukup cepat untuk risiko kritis.

Ketergantungan terhadap vendor

Tidak semua aplikasi dikelola secara internal. Sebagian perusahaan bergantung pada vendor untuk mendapatkan patch, perubahan kode, atau pembaruan konfigurasi.

Tanpa ketentuan keamanan yang jelas dalam perjanjian layanan, waktu remediasi perusahaan ikut bergantung pada prioritas pihak ketiga.

Sistem legacy tidak mudah diubah

Aplikasi lama sering memiliki dependency yang rumit dan dokumentasi yang terbatas. Perubahan kecil dapat membawa konsekuensi terhadap operasional.

Dalam kondisi ini, perusahaan mungkin membutuhkan kontrol kompensasi, seperti pembatasan akses, segmentasi jaringan, web application firewall, atau peningkatan monitoring hingga perbaikan permanen dapat dilakukan.

Temuan tidak memiliki konteks yang memadai

Laporan yang hanya menyebut nama kerentanan dan skor teknis sering menyulitkan pemilik sistem untuk memahami urgensinya.

Tim teknis memerlukan bukti, lokasi masalah, skenario eksploitasi, dampak, serta rekomendasi yang dapat diterapkan. Tanpa informasi tersebut, waktu habis untuk mengulang validasi dari awal.

Penetration Testing Tidak Seharusnya Berakhir pada Penyerahan Laporan

Nilai penetration testing tidak terletak pada panjangnya daftar temuan.

Pengujian yang baik seharusnya membantu perusahaan memahami bagaimana kelemahan dapat dieksploitasi, aset apa yang terdampak, dan bagaimana risiko tersebut dapat ditutup.

Setelah laporan diterima, hasil pengujian perlu masuk ke dalam siklus yang jelas:

Validasi temuan, penentuan prioritas, penetapan pemilik, perencanaan perbaikan, implementasi, retest, dan penutupan risiko.

Setiap tahap memiliki peran terhadap MTTR.

Validasi yang baik mencegah waktu terbuang pada false positive. Penentuan prioritas membantu perusahaan memusatkan sumber daya pada risiko terbesar. Penetapan pemilik menghilangkan kebingungan tanggung jawab. Retest memberikan kepastian bahwa perubahan benar-benar efektif.

Tanpa siklus tersebut, penetration testing hanya menghasilkan informasi tambahan.

Perusahaan mengetahui lebih banyak kelemahan, tetapi tetap tidak memiliki mekanisme yang cukup kuat untuk mengubahnya menjadi peningkatan keamanan.

Pentest yang hanya menambah daftar masalah meningkatkan visibilitas. Pentest yang terhubung dengan remediasi meningkatkan ketahanan.

MTTR Rendah Juga Dapat Memberikan Rasa Aman yang Keliru

Mengejar angka MTTR serendah mungkin bukan tujuan akhir.

Metrik dapat menciptakan perilaku yang tidak diinginkan apabila digunakan tanpa pengawasan. Tim dapat menutup tiket sebelum validasi selesai, mengalihkan status temuan menjadi accepted risk, atau memprioritaskan masalah yang mudah diperbaiki hanya untuk memperbaiki angka laporan.

Perusahaan juga dapat mencatat mitigasi sementara sebagai penyelesaian permanen. Padahal, pemblokiran endpoint atau perubahan aturan firewall belum tentu memperbaiki akar masalah pada kode aplikasi.

Karena itu, waktu remediasi harus dibaca bersama kualitas perbaikannya.

Remediasi yang cepat tetapi tidak lengkap hanya memindahkan masalah. Perubahan terburu-buru juga dapat menciptakan regresi, gangguan operasional, atau kerentanan baru.

Kematangan terletak pada kemampuan menyeimbangkan kecepatan, ketepatan, dan validasi.

Membangun Proses Remediasi yang Lebih Terukur

Menurunkan MTTR bukan berarti menekan tim teknis agar bekerja lebih cepat tanpa dukungan tambahan. Perusahaan perlu memperbaiki sistem kerja yang menghubungkan deteksi dengan tindakan.

Satukan data temuan

Temuan dari vulnerability assessment, penetration testing, audit, code review, bug bounty, dan incident response sebaiknya masuk ke dalam satu sistem pengelolaan.

Duplikasi perlu dihapus agar perusahaan memiliki gambaran risiko yang konsisten.

Tetapkan pemilik teknis dan pemilik risiko

Pemilik teknis bertanggung jawab melaksanakan perbaikan. Pemilik risiko memastikan bahwa konsekuensi bisnis dipahami dan keputusan tidak berhenti karena konflik prioritas.

Setiap temuan perlu memiliki target penyelesaian, status, hambatan, dan bukti perbaikan.

Tentukan remediation SLA berdasarkan risiko

Target waktu tidak perlu sama untuk seluruh temuan.

Kerentanan kritis pada sistem internet-facing dengan eksploitasi aktif harus ditangani lebih cepat daripada kelemahan rendah pada lingkungan internal yang tersegmentasi.

SLA harus mempertimbangkan tingkat ancaman serta kemampuan operasional perusahaan.

Integrasikan keamanan dengan workflow tim

Remediasi akan berjalan lambat apabila proses security berdiri di luar aktivitas pengembangan dan operasional.

Temuan perlu terhubung dengan sistem ticketing, project management, change management, CI/CD, dan asset inventory yang digunakan sehari-hari.

Pisahkan mitigasi sementara dari perbaikan permanen

Kontrol kompensasi dapat menjadi langkah penting ketika patch belum tersedia. Namun, statusnya harus tetap dipantau sampai akar masalah benar-benar diselesaikan.

Wajibkan retest

Temuan tidak seharusnya ditutup hanya berdasarkan konfirmasi bahwa konfigurasi atau kode telah diubah.

Pengujian ulang memastikan bahwa perubahan telah diterapkan dengan benar dan tidak dapat dilewati menggunakan jalur lain.

Evaluasi penyebab keterlambatan

Perusahaan perlu mengetahui mengapa target remediasi tidak tercapai.

Apakah karena keterbatasan sumber daya, ketergantungan vendor, kekhawatiran downtime, tidak tersedianya patch, atau rendahnya prioritas dari pemilik bisnis?

Tanpa analisis penyebab, keterlambatan yang sama akan terus terulang.

Dari Security Metrics Menuju Akuntabilitas

MTTR semestinya tidak digunakan untuk mencari tim yang dapat disalahkan.

Metrik ini lebih bermanfaat ketika digunakan untuk menemukan titik lemah dalam cara perusahaan mengelola risiko.

Jika sebuah unit membutuhkan waktu lebih panjang, perusahaan perlu memahami konteksnya. Mungkin unit tersebut menangani sistem legacy. Mungkin terdapat dependency dengan vendor. Mungkin proses persetujuannya terlalu panjang. Bisa pula rekomendasi keamanan belum cukup praktis untuk diterapkan.

Data tersebut membantu manajemen menentukan investasi yang benar.

Perusahaan mungkin membutuhkan tambahan developer, perbaikan arsitektur, otomatisasi patch management, pembaruan kontrak vendor, atau penyederhanaan proses perubahan.

Dengan demikian, MTTR tidak berhenti sebagai indikator operasional. Ia menjadi alat untuk memperbaiki pengambilan keputusan.

Perusahaan Tidak Membutuhkan Lebih Banyak Temuan, tetapi Lebih Sedikit Risiko Terbuka

Tools keamanan akan terus menghasilkan data. Penetration testing akan terus menemukan jalur serangan. Audit akan terus memberikan rekomendasi.

Namun, nilai dari seluruh aktivitas tersebut baru terlihat ketika risiko benar-benar dikurangi.

Deteksi menciptakan pengetahuan. Remediasi menciptakan perubahan. Validasi memberikan kepastian.

Perusahaan yang matang bukan organisasi yang tidak memiliki temuan. Sistem yang kompleks akan selalu memiliki kemungkinan kelemahan baru.

Kematangan terlihat dari kemampuan perusahaan merespons pengetahuan tersebut secara proporsional, terukur, dan konsisten.

Pada akhirnya, keamanan tidak diuji ketika kerentanan ditemukan. Keamanan diuji ketika organisasi harus menentukan seberapa cepat dan seberapa serius kerentanan tersebut akan diperbaiki.

Mean Time to Remediate membuat kemampuan itu terlihat. Ia menunjukkan apakah perusahaan hanya pandai mengumpulkan laporan atau benar-benar mampu mengubah temuan menjadi ketahanan.

Percepat Remediasi Bersama Fourtrezz

Fourtrezz, yang beroperasi di bawah PT Tiga Pilar Keamanan, membantu perusahaan mengidentifikasi dan menangani kelemahan keamanan melalui layanan penetration testing dan vulnerability assessment.

Pengujian tidak hanya diarahkan untuk menemukan celah, tetapi juga untuk memberikan bukti teknis, analisis dampak, rekomendasi perbaikan, serta dukungan validasi melalui retest. Pendekatan ini membantu perusahaan membangun proses remediasi yang lebih terarah dan memastikan bahwa risiko tidak berhenti sebagai daftar temuan dalam laporan.

Fourtrezz juga menyediakan layanan pengujian keamanan aplikasi, API, serta infrastruktur jaringan untuk membantu organisasi memahami postur keamanan berdasarkan skenario serangan yang realistis.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]