Sebuah perusahaan menerima laporan penetration testing dengan hasil yang cukup menggembirakan. Tidak ditemukan kerentanan kritis, sementara sejumlah temuan lainnya berada pada tingkat risiko menengah dan rendah. Hasil tersebut kemudian disampaikan kepada manajemen sebagai indikasi bahwa sistem perusahaan telah memiliki keamanan yang baik.

Namun, ada informasi penting yang belum tentu mendapat perhatian. Pengujian ternyata hanya mencakup sebagian modul aplikasi, beberapa peran pengguna tidak tersedia, dan sejumlah integrasi sistem berada di luar ruang lingkup pemeriksaan.

Tidak adanya temuan kritis tetap merupakan hasil yang sah. Akan tetapi, apakah hasil tersebut cukup untuk menyimpulkan bahwa seluruh sistem telah aman?

Persoalan ini memperlihatkan pentingnya memahami laporan pentest secara menyeluruh. Jumlah kerentanan yang ditemukan memang menjadi informasi utama, tetapi kesimpulannya tidak dapat dipisahkan dari ruang lingkup, metode, akses, serta keterbatasan selama pengujian.

Laporan pentest yang baik bukan hanya menjelaskan kerentanan yang ditemukan, tetapi juga memberikan kejelasan mengenai bagian sistem yang benar-benar telah diperiksa.

Tidak Ada Temuan Kritis Bukan Berarti Seluruh Sistem Bebas dari Risiko

Dalam laporan penetration testing, kerentanan biasanya dikelompokkan berdasarkan tingkat keparahan untuk membantu perusahaan menentukan prioritas penanganan.

Temuan dengan kategori kritis dan tinggi umumnya mendapat perhatian lebih besar karena berpotensi menimbulkan dampak keamanan yang serius.

Karena itu, laporan tanpa temuan kritis sering dianggap sebagai hasil yang menunjukkan kondisi keamanan cukup baik.

Penilaian tersebut tidak sepenuhnya keliru. Tidak ditemukannya kerentanan kritis merupakan informasi positif bagi aset dan skenario yang berhasil diuji. Namun, hasil tersebut tidak dapat diperluas menjadi pernyataan bahwa seluruh sistem bebas dari risiko.

Penetration testing dilakukan berdasarkan ruang lingkup dan kondisi tertentu. Pengujian memiliki batas waktu, pendekatan, serta akses yang disepakati sebelum pekerjaan dimulai.

Kondisi sistem juga dapat berubah setelah pemeriksaan selesai. Pembaruan aplikasi, perubahan konfigurasi, penambahan integrasi, atau munculnya kerentanan baru dapat memengaruhi keamanan sistem.

Oleh sebab itu, laporan pentest menggambarkan hasil evaluasi pada periode pengujian, bukan jaminan keamanan yang berlaku tanpa batas waktu.

OWASP Web Security Testing Guide menempatkan hasil pengujian sebagai informasi yang perlu dipahami bersama konteks teknis dan batas pemeriksaannya. Pelaporan tidak hanya berfungsi untuk mencatat kerentanan, tetapi juga membantu pihak teknis dan manajemen memahami kondisi yang telah dievaluasi.

Dengan demikian, kesimpulan keamanan tidak seharusnya hanya mengandalkan angka pada ringkasan temuan.

Scope Pentest Menentukan Seberapa Jauh Kesimpulan Laporan Berlaku

Ruang lingkup atau scope pentest merupakan batas yang menentukan aset, fitur, serta kondisi pengujian yang telah disepakati.

Penetapan ruang lingkup penting untuk memastikan kegiatan pengujian sesuai dengan tujuan perusahaan dan tidak mengganggu sistem yang berada di luar otorisasi.

Namun, ruang lingkup juga menentukan seberapa jauh hasil pengujian dapat digunakan untuk menarik kesimpulan.

Ketika perusahaan hanya menguji sebagian aplikasi, laporan tersebut tidak dapat dianggap mewakili keamanan seluruh ekosistem sistem informasi.

Aset di Luar Scope Tidak Ikut Mendapat Kesimpulan Pengujian

Sebuah aplikasi perusahaan mungkin terhubung dengan beberapa komponen, seperti API, database, layanan autentikasi, dan sistem pihak ketiga.

Dalam pelaksanaan penetration testing, tidak semua komponen tersebut selalu termasuk dalam pengujian.

Misalnya, perusahaan meminta pengujian terhadap aplikasi web utama, sementara server database dan API integrasi dikecualikan dari ruang lingkup.

Hasil pentest dapat memberikan informasi mengenai keamanan aplikasi yang diuji. Namun, laporan tersebut tidak otomatis membuktikan bahwa seluruh sistem pendukung memiliki tingkat keamanan yang sama.

Komponen yang tidak diuji dapat memiliki karakteristik risiko berbeda, terutama apabila menggunakan mekanisme autentikasi, konfigurasi, atau teknologi tersendiri.

Karena itu, pembaca laporan perlu membedakan aset yang termasuk pengujian dan aset yang hanya menjadi bagian dari arsitektur sistem.

User Role yang Terbatas Dapat Meninggalkan Skenario Belum Teruji

Aplikasi internal perusahaan sering memiliki beberapa peran pengguna dengan tingkat kewenangan berbeda.

Administrator dapat mengelola konfigurasi sistem, supervisor memiliki kewenangan persetujuan, sementara operator hanya diperbolehkan menjalankan fungsi tertentu.

Perbedaan hak akses tersebut menciptakan kebutuhan pengujian authorization dan business logic.

Apabila pengujian hanya menggunakan akun dengan dua peran, sementara aplikasi memiliki lebih banyak kategori pengguna, tidak semua kemungkinan interaksi antarperan dapat dievaluasi.

Sebagai contoh, kelemahan kontrol akses mungkin baru terlihat ketika pengguna dengan kewenangan rendah mencoba menjalankan fungsi yang seharusnya hanya tersedia bagi supervisor.

Jika akun atau skenario tersebut tidak tersedia selama pengujian, pemeriksa memiliki keterbatasan untuk mengevaluasi seluruh aturan otorisasi aplikasi.

Hal ini tidak otomatis menunjukkan bahwa aplikasi memiliki kerentanan. Namun, terdapat bagian dari mekanisme keamanan yang belum memperoleh pembuktian melalui pengujian.

Staging dan Production Tidak Selalu Memiliki Kondisi yang Sama

Pengujian keamanan terkadang dilakukan pada lingkungan staging untuk mengurangi risiko gangguan terhadap sistem produksi.

Pendekatan tersebut dapat menjadi pilihan yang tepat, terutama ketika pengujian membutuhkan aktivitas yang berpotensi memengaruhi kestabilan layanan.

Namun, lingkungan staging tidak selalu memiliki konfigurasi yang sepenuhnya sama dengan production.

Perbedaan dapat terjadi pada pengaturan autentikasi, firewall, integrasi API, konfigurasi server, dan komponen infrastruktur lainnya.

Apabila perbedaan tersebut memengaruhi jalur serangan atau kontrol keamanan, hasil pengujian staging belum tentu mencerminkan seluruh kondisi pada production.

Karena itu, laporan perlu menjelaskan lingkungan yang digunakan dan batas kesimpulan yang dapat diberikan berdasarkan konfigurasi tersebut.

Metode Pengujian dan Akses Memengaruhi Kedalaman Pemeriksaan

Selain ruang lingkup, metode penetration testing juga memengaruhi informasi yang tersedia selama pengujian.

Dalam praktiknya, pengujian dapat menggunakan pendekatan black box, grey box, maupun white box berdasarkan tujuan dan kebutuhan perusahaan.

Black box umumnya dilakukan dengan informasi awal yang terbatas. Pendekatan ini dapat membantu mengevaluasi keamanan sistem dari perspektif pihak yang tidak memiliki pengetahuan internal secara mendalam.

Grey box memberikan sebagian informasi atau akses tertentu untuk membantu pemeriksa mengevaluasi fungsi yang membutuhkan autentikasi maupun pemahaman tambahan mengenai sistem.

Sementara itu, white box dapat melibatkan informasi yang lebih lengkap, termasuk desain arsitektur atau akses terhadap kode sumber sesuai kesepakatan.

Tidak ada satu metode yang secara otomatis menjamin seluruh kerentanan dapat ditemukan.

Masing-masing memiliki karakteristik dan keterbatasan yang perlu disesuaikan dengan tujuan pengujian.

Misalnya, pengujian black box terhadap aplikasi yang kompleks mungkin tidak dapat menjangkau seluruh fungsi yang membutuhkan hak akses khusus.

Sebaliknya, pengujian dengan akses lebih luas dapat membantu mengevaluasi bagian internal tertentu, tetapi tetap membutuhkan skenario yang tepat untuk menilai potensi kelemahan keamanan.

Ketersediaan kredensial, dokumentasi, dan informasi mengenai alur bisnis juga dapat memengaruhi kedalaman pemeriksaan.

Karena itu, jumlah temuan dari dua pengujian dengan metode dan akses berbeda tidak seharusnya dibandingkan secara langsung tanpa memahami konteksnya.

Keberhasilan penetration testing tidak ditentukan semata-mata oleh banyaknya kerentanan yang ditemukan, tetapi juga oleh kesesuaian metode dan cakupan dengan tujuan evaluasi keamanan.

Batas Waktu dan Kondisi Sistem Dapat Membuat Sebagian Skenario Belum Teruji

Ruang lingkup yang telah disepakati belum tentu seluruhnya berhasil diperiksa dalam kondisi yang sama.

Selama pelaksanaan pentest, terdapat kemungkinan muncul kendala teknis maupun operasional yang memengaruhi proses pengujian.

Sebagai contoh, sebuah modul aplikasi tidak dapat digunakan karena sedang mengalami gangguan. Akun pengujian dengan kewenangan tertentu belum tersedia, atau integrasi pihak ketiga tidak dapat diaktifkan pada lingkungan pengujian.

Kondisi tersebut dapat membatasi pemeriksa dalam menjalankan skenario yang sudah direncanakan.

Selain itu, beberapa bentuk pengujian mungkin dibatasi untuk menghindari risiko gangguan layanan, terutama ketika target berada pada sistem produksi.

Pembatasan seperti ini merupakan bagian dari pengelolaan risiko pengujian. Perusahaan tidak selalu perlu mengizinkan setiap tindakan eksploitasi apabila potensi dampaknya terhadap operasional terlalu besar.

Namun, konsekuensinya harus dipahami.

Ketika sebuah skenario tidak dapat dijalankan, tingkat keyakinan terhadap bagian tersebut berbeda dari skenario yang berhasil diperiksa.

OWASP Web Security Testing Guide menjelaskan pentingnya mencantumkan limitations dalam laporan. Keterbatasan dapat berasal dari fungsi yang tidak berjalan, kurangnya akses, pembatasan waktu, maupun area yang tidak dapat diperiksa.

Keterbukaan terhadap kondisi tersebut tidak mengurangi kredibilitas pengujian. Sebaliknya, informasi tersebut membantu perusahaan memahami hasil secara lebih proporsional.

Temuan Menengah dan Rendah Tidak Selalu Berarti Dampak Bisnisnya Kecil

Perhatian terhadap kerentanan kritis memang penting. Namun, keputusan keamanan tidak seharusnya berhenti pada kategori tingkat keparahan.

Sebuah kerentanan dengan tingkat keparahan menengah dapat memiliki dampak berbeda bergantung pada fungsi sistem, jenis data, dan posisi aset dalam proses bisnis perusahaan.

Misalnya, kelemahan kontrol akses pada aplikasi yang mengelola data pelanggan perlu dievaluasi berdasarkan informasi yang berpotensi terdampak.

Begitu pula dengan kesalahan konfigurasi pada layanan internal yang mungkin tampak memiliki tingkat risiko rendah, tetapi dapat menjadi bagian dari rangkaian serangan apabila dikombinasikan dengan kelemahan lain.

Tidak semua kerentanan dapat dikombinasikan menjadi serangan yang lebih besar. Namun, kemungkinan tersebut perlu dipertimbangkan ketika terdapat hubungan teknis yang relevan.

Common Vulnerability Scoring System (CVSS) membantu memberikan penilaian tingkat keparahan berdasarkan karakteristik kerentanan.

Meski demikian, skor teknis tidak selalu menggambarkan seluruh konsekuensi bisnis yang mungkin dialami organisasi.

NIST SP 800-30 menempatkan penilaian risiko dalam konteks ancaman, kerentanan, kemungkinan terjadinya dampak, dan konsekuensi terhadap organisasi.

Artinya, perusahaan tetap perlu menilai apakah temuan yang tercatat berpengaruh terhadap proses operasional, kerahasiaan informasi, atau ketersediaan layanan penting.

Laporan tanpa kerentanan kritis tidak berarti seluruh temuan lain dapat diabaikan.

Bagian Limitations Sama Pentingnya dengan Findings

Dalam praktik pengelolaan keamanan, perhatian pembaca laporan sering tertuju pada ringkasan jumlah kerentanan dan rekomendasi perbaikan.

Padahal, terdapat bagian lain yang sama penting untuk dipahami, yaitu informasi mengenai batas pengujian.

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

Sebuah laporan dapat terlihat baik dari sisi jumlah temuan. Namun, apabila terdapat fungsi yang belum diperiksa atau akses yang tidak tersedia, kondisi tersebut perlu menjadi bagian dari pertimbangan perusahaan.

Bagian findings menjelaskan kelemahan yang berhasil diidentifikasi selama pengujian. Sementara itu, bagian limitations membantu menjelaskan kondisi yang membatasi pemeriksaan dan dapat memengaruhi interpretasi hasil.

Keduanya memiliki fungsi berbeda, tetapi saling melengkapi.

Laporan penetration testing yang informatif sebaiknya memberikan kejelasan mengenai beberapa aspek berikut:

• Aset, aplikasi, dan layanan yang termasuk serta tidak termasuk ruang lingkup pengujian.
• Metode pengujian dan tingkat informasi yang diberikan kepada pemeriksa.
• Peran pengguna serta kredensial yang tersedia selama pengujian.
• Lingkungan sistem yang digunakan, termasuk staging atau production.
• Skenario yang tidak dapat dijalankan karena kendala teknis atau pembatasan operasional.
• Periode pelaksanaan pengujian dan kondisi penting yang memengaruhi pemeriksaan.
• Temuan, tingkat risiko, bukti teknis, serta rekomendasi perbaikan.

Informasi tersebut membantu perusahaan memahami apakah hasil pengujian sudah sesuai dengan tujuan awal.

Misalnya, apabila tujuan perusahaan adalah mengevaluasi keamanan seluruh proses bisnis aplikasi, tetapi sebagian peran pengguna belum diuji, maka terdapat kebutuhan evaluasi lanjutan yang perlu dipertimbangkan.

Sebaliknya, jika ruang lingkup memang hanya mencakup satu layanan tertentu dan seluruh pengujian terlaksana sesuai rencana, kesimpulan dapat diarahkan secara jelas pada layanan tersebut.

Transparansi mengenai batas pemeriksaan membantu mencegah perbedaan pemahaman antara tim penguji, pengelola sistem, dan manajemen.

Manajemen Perlu Membaca Laporan Pentest sebagai Dasar Keputusan, Bukan Sertifikat Aman

Laporan penetration testing sering digunakan untuk mendukung evaluasi keamanan, kebutuhan audit, dan proses tata kelola teknologi informasi.

Dokumen tersebut memberikan informasi teknis yang dapat membantu organisasi memahami kelemahan pada sistem yang diuji.

Namun, laporan pentest bukan sertifikat yang menjamin suatu sistem bebas dari seluruh kemungkinan serangan.

Keamanan sistem dipengaruhi oleh banyak faktor yang dapat berubah seiring waktu, termasuk konfigurasi, pembaruan perangkat lunak, integrasi baru, dan perubahan pola ancaman.

Karena itu, executive summary dalam laporan perlu membantu manajemen memahami lebih dari sekadar jumlah temuan.

Pembaca perlu mengetahui tujuan pemeriksaan, cakupan sistem, kondisi hasil pengujian, serta risiko yang masih perlu mendapatkan perhatian.

Informasi tersebut dapat digunakan untuk menentukan prioritas perbaikan dan kebutuhan investasi keamanan.

Sebagai contoh, laporan tanpa temuan kritis mungkin menunjukkan bahwa pengendalian pada bagian yang diuji bekerja cukup baik terhadap skenario yang diperiksa.

Namun, jika sejumlah API penting belum termasuk dalam cakupan, perusahaan dapat mempertimbangkan pengujian tambahan berdasarkan tingkat sensitivitas layanan tersebut.

Pendekatan ini lebih bermanfaat daripada langsung menyimpulkan bahwa seluruh sistem sudah aman atau justru menganggap laporan tidak memiliki nilai karena tidak menemukan kerentanan kritis.

Hasil penetration testing seharusnya menjadi salah satu masukan dalam proses risk management, bersama informasi mengenai nilai aset, ancaman, konfigurasi, dan kebutuhan operasional perusahaan.

Pengujian Lanjutan Perlu Ditentukan Berdasarkan Risiko yang Belum Tercakup

Setelah menerima laporan pentest, perusahaan perlu menentukan langkah berikutnya berdasarkan temuan dan keterbatasan yang telah dijelaskan.

Tidak semua laporan tanpa temuan kritis memerlukan pengujian ulang secara menyeluruh.

Apabila seluruh ruang lingkup telah diuji sesuai tujuan dan tidak terdapat keterbatasan material, perusahaan dapat menggunakan hasil tersebut untuk melanjutkan pemantauan serta pengelolaan keamanan berkala.

Namun, kondisi berbeda berlaku ketika terdapat aset atau skenario penting yang belum berhasil diperiksa.

Perusahaan perlu mempertimbangkan tingkat risiko dari bagian yang belum tercakup sebelum menentukan apakah pengujian tambahan diperlukan.

Dalam proses ini, terdapat perbedaan penting antara retesting dan additional testing.

Retesting dilakukan untuk memverifikasi apakah kerentanan yang sebelumnya ditemukan telah berhasil diperbaiki.

Sementara itu, additional testing bertujuan memperluas pemeriksaan terhadap aset, fitur, atau skenario yang sebelumnya belum termasuk atau belum berhasil diuji.

Keduanya tidak dapat diperlakukan sebagai kegiatan yang sama.

Perusahaan juga perlu memastikan bahwa perubahan aplikasi setelah pengujian tidak memperkenalkan kelemahan baru. Integrasi proses keamanan ke dalam Secure Software Development Life Cycle (Secure SDLC) dapat membantu menjaga konsistensi pemeriksaan sepanjang pengembangan sistem.

Dengan demikian, tindak lanjut pentest tidak hanya berfokus pada penyelesaian laporan, tetapi juga pada pengelolaan risiko yang berkelanjutan.

Hasil Pentest yang Baik Harus Dipahami Bersama Apa yang Belum Diuji

Laporan penetration testing tanpa temuan kritis merupakan hasil positif yang patut diapresiasi. Namun, hasil tersebut tidak seharusnya dianggap sebagai jaminan bahwa seluruh sistem perusahaan telah bebas dari kerentanan.

Kesimpulan pengujian selalu memiliki hubungan dengan ruang lingkup, metode, akses, kondisi sistem, dan periode pemeriksaan.

Jika terdapat aset atau skenario yang belum diuji, perusahaan perlu memahami bahwa risiko pada bagian tersebut belum sepenuhnya dievaluasi melalui kegiatan pentest yang dilakukan.

Sebaliknya, laporan yang menjelaskan batas pengujian secara terbuka memberikan dasar yang lebih baik bagi manajemen untuk mengambil keputusan.

Keandalan laporan pentest tidak hanya terletak pada jumlah kerentanan yang ditemukan, tetapi juga pada kejelasan mengenai bagian sistem yang telah diperiksa dan keterbatasan yang masih perlu ditindaklanjuti.

Dengan pemahaman tersebut, perusahaan dapat menggunakan hasil pengujian secara lebih tepat untuk menentukan prioritas keamanan, mengevaluasi risiko, dan merencanakan pemeriksaan berikutnya.

Evaluasi Keamanan Sistem Perusahaan Bersama Fourtrezz

Laporan penetration testing yang bermanfaat perlu didukung oleh perencanaan ruang lingkup yang jelas, metode pengujian yang sesuai, serta analisis hasil yang dapat dipahami oleh tim teknis maupun manajemen.

Fourtrezz, bagian dari PT Tiga Pilar Keamanan, menyediakan layanan Vulnerability Assessment dan Penetration Testing untuk membantu perusahaan mengidentifikasi dan mengevaluasi kelemahan keamanan pada aset digital.

Layanan Fourtrezz mencakup pengujian aplikasi web, aplikasi mobile Android dan iOS, API, aplikasi desktop, serta jaringan dan server sesuai kebutuhan dan ruang lingkup yang disepakati.

Fourtrezz juga menyediakan pendekatan Penetration Testing Black Box dan Grey Box, disertai laporan hasil pengujian, rekomendasi perbaikan, serta layanan pengujian ulang sesuai ketentuan kerja sama.

Melalui evaluasi yang terstruktur, perusahaan dapat memperoleh pemahaman mengenai temuan keamanan dan menentukan tindak lanjut yang relevan terhadap risiko sistem.

Bagi perusahaan yang ingin merencanakan penetration testing, mengevaluasi kebutuhan pengujian, atau memastikan ruang lingkup pemeriksaan sesuai dengan kondisi infrastruktur, Fourtrezz terbuka untuk diskusi dan kerja sama.

Hubungi Fourtrezz:

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