Pentest untuk bisnis: tujuan, proses, dan hasilnya
Pentest membantu memeriksa apakah celah keamanan dapat dimanfaatkan dalam lingkup yang disepakati. Mulai dari tujuan dan izin pengujian, lalu siapkan tim untuk memperbaiki temuan.
Di halaman ini
Apa itu pentest?
Pentest atau uji penetrasi adalah pengujian keamanan berizin untuk memeriksa apakah kelemahan sistem dapat dimanfaatkan dan apa dampaknya. Penguji bekerja pada aset, waktu, dan batas tindakan yang telah disepakati. Hasilnya menjadi bahan perbaikan bagi tim.
Misalnya, sebuah aplikasi memiliki akun pelanggan dan admin. Pertanyaan bisnisnya: apakah pelanggan hanya bisa melihat pesanan miliknya, dan apakah tindakan admin benar-benar dibatasi? Pengujian perlu mencakup peran tersebut. Memeriksa halaman depan saja tidak menjawab pertanyaan ini.
Pemindaian otomatis dapat membantu menemukan dugaan celah. Pentest juga memerlukan pemeriksaan dan pembuktian yang sesuai tujuan pengujian. Baca perbedaan audit, pemindaian, pentest, dan sertifikasi sebelum membeli layanan.
Kapan pentest berguna?
Pertimbangkan pentest saat tim perlu memeriksa risiko sebelum meluncurkan layanan, setelah mengubah fitur penting, atau untuk menjawab permintaan bukti keamanan dari pelanggan. Ini contoh pertimbangan kerja, bukan jadwal wajib yang sama untuk semua bisnis.
Tuliskan keputusan yang ingin didukung hasilnya. Contoh: “Fitur ekspor data pelanggan akan dibuka bulan depan. Kami perlu memeriksa pembatasan akses sebelum fitur digunakan.” Tujuan ini lebih jelas daripada sekadar meminta “sertifikat aman”.
Jika pelanggan meminta laporan pentest, tanyakan lingkup, usia laporan yang diterima, dan bukti perbaikan yang mereka perlukan. Jangan menganggap satu laporan selalu memenuhi semua permintaan. Untuk kewajiban berdasarkan aturan Indonesia, periksa panduan kewajiban keamanan dan ketentuan sektor yang sesuai.
Apa yang harus masuk lingkup?
Buat daftar website, API, fitur, peran pengguna, serta lingkungan yang akan diuji. API adalah antarmuka yang dipakai aplikasi untuk bertukar data. Catat juga bagian yang dikecualikan, misalnya sistem pembayaran milik pihak lain.
Satu nama domain bisa memuat beberapa aplikasi. Sebaliknya, satu aplikasi dapat bergantung pada beberapa API. Karena itu, jumlah domain saja belum menjelaskan luas pekerjaan.
Istilah berikut biasanya menjelaskan informasi awal yang diberikan kepada penguji:
- Black-box: informasi internal terbatas; pemeriksaan dimulai dari bagian yang dapat diakses dalam lingkup izin.
- Grey-box: penguji menerima sebagian informasi atau akses, misalnya akun pelanggan dan dokumentasi API.
- White-box: penguji mendapat informasi internal lebih luas, yang dapat mencakup kode sumber dan rancangan sistem.
Nama paket belum cukup. Tulis akses dan bahan yang benar-benar diberikan, serta apakah pemeriksaan kode termasuk pekerjaan. Tidak ada satu pendekatan yang otomatis paling tepat untuk semua tujuan.
Bagaimana prosesnya?
- Sepakati tujuan dan izin. Tetapkan aset, jadwal, tindakan yang boleh dilakukan, pengecualian, dan pihak yang berwenang menyetujui. Periksa izin atau ketentuan penyedia untuk infrastruktur pihak ketiga.
- Siapkan pengujian. Sediakan akun uji, data fiktif, kontak yang dapat dihubungi, serta rencana jika layanan terganggu. Tentukan kapan pengujian harus berhenti.
- Jalankan dan komunikasikan hasil penting. Penguji mencatat pekerjaan dan menyampaikan temuan mendesak kepada kontak yang disepakati, tanpa menunggu laporan akhir.
- Bahas laporan dan perbaikan. Tim menentukan pemilik setiap pekerjaan, prioritas, dan target penyelesaian.
- Periksa kembali perbaikannya. Pengujian ulang atau retest memeriksa temuan yang diperbaiki dalam lingkup yang disepakati. Catat bagian yang belum diuji ulang.
Rinciannya dapat berbeda sesuai layanan. Gunakan checklist persiapan pentest untuk membagi pekerjaan sebelum penguji mendapat akses.
Hasil apa yang perlu diterima?
Sepakati laporan yang menjelaskan lingkup, batas pemeriksaan, temuan beserta bukti dan dampaknya, serta saran perbaikan. Untuk retest, minta status temuan yang diperiksa kembali. Batasi penerima laporan karena isinya dapat mengungkap kelemahan sistem.
Hasil pentest berlaku pada lingkup dan kondisi saat diuji. Tidak ditemukannya celah bukan jaminan bahwa aplikasi bebas kelemahan. Fitur, konfigurasi, atau dependensi yang berubah setelah pengujian dapat memerlukan pemeriksaan tambahan.
Pentest juga tidak menggantikan pengamanan sehari-hari, pengujian selama pengembangan, atau sertifikasi sistem manajemen. NIST dan OWASP pada halaman ini digunakan sebagai rujukan teknis, bukan hukum Indonesia atau bukti bahwa Kompli telah menguji sistem pembaca.
Jika memakai pihak luar, lanjutkan ke cara memilih vendor pentest.
Untuk melanjutkan, susun lingkup website dan API, bandingkan biaya dan jadwal pekerjaan, lalu pelajari cara membaca laporan dan retest.
Tentukan informasi yang diberikan kepada penguji
Untuk membandingkan akun, dokumentasi, dan akses kode yang perlu disiapkan, baca black box, white box, dan grey box. Setelah memilih pendekatan, rincikan izin serta objek dalam lingkup pentest, lalu sepakati bentuk hasil memakai contoh laporan.
Sumber rujukan
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (2008) ↗National Institute of Standards and Technology; panduan pengujian, bukan hukum Indonesia · Bagian 5.2, 6.5–6.6, 7.3–7.4, 8, dan Lampiran B; perencanaan serta tindak lanjut pengujian
- OWASP Web Security Testing Guide v4.2 — Introduction ↗OWASP Foundation; panduan teknis, bukan hukum Indonesia · A Balanced Approach; Security Tests Integrated in Development and Testing Workflows
- OWASP Web Security Testing Guide v4.2 — Reporting ↗OWASP Foundation; panduan pelaporan pengujian · Bagian 1.4–1.7 dan 3; lingkup, batas, temuan, dan re-test
Baca naskah lengkap untuk melihat syarat dan pengecualiannya. Sesuaikan dengan layanan dan bidang usaha Anda.
Perlu membahas kebutuhan tim Anda?
Ceritakan sistem yang ingin diuji, tujuan pengujian, dan rencana waktunya.
Konsultasikan kebutuhan Anda