Memiliki firewall, sistem autentikasi, dan prosedur keamanan tidak otomatis membuktikan bahwa sebuah lingkungan IT aman. Kontrol dapat salah konfigurasi, proses dapat dijalankan tidak konsisten, dan celah teknis dapat terlewat ketika sistem berubah. Karena itu, organisasi biasanya membutuhkan dua sudut pandang: pengujian langsung terhadap kemungkinan serangan dan pemeriksaan terhadap tata kelola serta kontrol yang seharusnya berjalan.
Di sinilah penetration testing dan audit IT sering dibandingkan. Keduanya sama-sama menghasilkan temuan keamanan, tetapi pertanyaan yang dijawab berbeda. Penetration testing berusaha menunjukkan apa yang dapat dilakukan penyerang terhadap target dalam ruang lingkup yang disepakati. Audit IT menilai apakah kontrol, kebijakan, proses, dan bukti pelaksanaannya sesuai dengan kriteria yang digunakan.
Menggabungkan keduanya dapat memberikan gambaran yang lebih utuh. Namun, menganggap penetration testing sebagai pengganti audit, atau audit sebagai bukti bahwa tidak ada celah teknis, dapat menghasilkan rasa aman yang keliru.
Penetration testing menguji kemungkinan serangan
Penetration testing adalah pengujian terotorisasi untuk menemukan dan memvalidasi kelemahan keamanan dengan pendekatan yang menyerupai tindakan penyerang. Penguji dapat memeriksa permukaan serangan, menguji autentikasi, menelusuri validasi input, atau mengevaluasi apakah suatu kelemahan dapat digunakan untuk memperoleh akses yang tidak semestinya.
Tujuan pengujian bukan sekadar menghasilkan daftar kerentanan dari alat pemindai. Temuan perlu dipahami dalam konteks: aset apa yang terdampak, prasyarat eksploitasi, jenis akses yang mungkin diperoleh, data atau fungsi yang dapat diakses, serta bagaimana organisasi dapat memperbaikinya. Validasi manual sering diperlukan agar temuan tidak berhenti pada indikasi teknis yang belum terbukti.
Ruang lingkup penetration testing harus ditentukan sebelum pengujian dimulai. Dokumen scope biasanya menjelaskan target yang boleh diuji, periode pengujian, metode yang diizinkan, akun atau data uji, batasan terhadap teknik tertentu, serta jalur komunikasi jika ditemukan kondisi kritis. Tanpa batasan ini, aktivitas pengujian dapat mengganggu layanan atau menyentuh sistem yang tidak termasuk dalam otorisasi.
Jenis pengujian mengikuti permukaan serangan
Pengujian eksternal berfokus pada aset yang dapat dijangkau dari internet, seperti aplikasi web, API, layanan jaringan, atau konfigurasi akses publik. Pengujian internal menilai apa yang dapat dilakukan pihak yang sudah berada di jaringan internal, misalnya akibat kredensial yang bocor atau perangkat pengguna yang terkompromi.
Pengujian aplikasi web dan API biasanya menilai kontrol autentikasi, otorisasi, manajemen sesi, validasi input, penanganan kesalahan, dan perlindungan terhadap akses data yang tidak semestinya. Pengujian mobile, cloud, jaringan nirkabel, atau perangkat tertentu membutuhkan pendekatan dan ruang lingkup yang berbeda. Tidak semua teknik cocok diterapkan pada setiap target.
Pengujian dengan pengetahuan internal yang lebih lengkap dapat membantu mengevaluasi logika aplikasi atau arsitektur secara mendalam. Sebaliknya, pengujian dengan informasi terbatas dapat lebih mendekati kondisi penyerang eksternal. Istilah yang digunakan untuk membedakan pendekatan tersebut bukanlah ukuran kualitas dengan sendirinya; yang lebih penting adalah kesesuaian metode dengan tujuan dan risiko yang ingin dinilai.
Penetration testing menjawab pertanyaan “sejauh mana serangan dapat berjalan”, sedangkan audit IT menjawab “apakah kontrol yang seharusnya mencegah atau mendeteksi serangan benar-benar dirancang dan dijalankan”.
Audit IT memeriksa kontrol, proses, dan bukti
Audit IT menilai apakah pengelolaan teknologi informasi berjalan berdasarkan kriteria tertentu. Kriteria tersebut dapat berasal dari kebijakan internal, prosedur organisasi, kontrak, persyaratan pelanggan, kerangka kerja, atau kebutuhan tata kelola yang disepakati. Karena kriteria audit dapat berbeda, hasil audit harus dibaca bersama tujuan, ruang lingkup, dan dasar penilaiannya.
Dalam audit keamanan, pemeriksaan dapat mencakup pengelolaan akses, proses perubahan sistem, pencadangan, pemantauan log, pengelolaan insiden, keamanan pemasok, inventaris aset, dan tinjauan berkala terhadap risiko. Auditor tidak hanya menanyakan apakah sebuah kebijakan tersedia. Ia juga perlu melihat apakah kebijakan itu diterapkan, siapa yang bertanggung jawab, kapan aktivitas dilakukan, dan bukti apa yang menunjukkan bahwa kontrol berjalan.
Contoh ilustratif: sebuah organisasi memiliki prosedur untuk meninjau akun pengguna secara berkala. Audit dapat memeriksa dokumen prosedur, daftar akun, catatan persetujuan, hasil peninjauan, serta bukti tindak lanjut terhadap akun yang tidak lagi diperlukan. Jika prosedurnya ada tetapi tidak dijalankan atau tidak meninggalkan bukti yang memadai, kontrol tersebut tetap memiliki kelemahan dari perspektif audit.
Audit tidak membuktikan bahwa sistem bebas kerentanan
Audit bekerja berdasarkan ruang lingkup, kriteria, periode, dan bukti yang tersedia. Pemeriksaan yang menyatakan kontrol telah dirancang atau diterapkan tidak sama dengan pernyataan bahwa setiap kelemahan teknis telah ditemukan. Sebuah sistem dapat memenuhi prosedur manajemen akses, tetapi masih memiliki celah pada logika aplikasi. Sebaliknya, aplikasi dapat memiliki konfigurasi yang baik pada saat pengujian, sementara proses perubahan dan pemantauannya tidak terdokumentasi.
Temuan audit biasanya berkaitan dengan kesenjangan terhadap kriteria, kelemahan desain kontrol, ketidakkonsistenan pelaksanaan, atau kurangnya bukti. Penilaian dampak dan prioritas tindak lanjut sebaiknya mempertimbangkan konteks bisnis, aset yang terpengaruh, kemungkinan terjadinya masalah, serta kemampuan kontrol lain untuk mengurangi dampaknya.
Perbedaan utama antara penetration testing dan audit IT
Perbedaan pertama terletak pada objek pengujian. Penetration testing menguji target teknis dan jalur serangan. Audit IT menilai sistem pengendalian yang lebih luas, termasuk manusia, proses, dokumentasi, dan mekanisme pengawasan.
Perbedaan kedua adalah bentuk bukti. Penetration testing mengandalkan observasi teknis, permintaan terhadap sistem, respons aplikasi, konfigurasi yang terlihat, serta validasi eksploitasi dalam batas yang diizinkan. Audit mengandalkan wawancara, inspeksi dokumen, pengamatan proses, pengambilan sampel, dan bukti bahwa aktivitas kontrol dilakukan.
Perbedaan ketiga adalah risiko operasional selama pelaksanaan. Penetration testing dapat mengirimkan permintaan yang tidak biasa, menguji input berbahaya, atau mengevaluasi skenario yang berpotensi mengganggu layanan. Aktivitas ini memerlukan koordinasi, pemantauan, dan rencana penghentian. Audit dokumentasi umumnya memiliki risiko gangguan layanan yang lebih rendah, walaupun permintaan data dan wawancara tetap dapat membebani tim jika tidak direncanakan.
Perbedaan berikutnya adalah keluaran. Laporan penetration testing biasanya memuat temuan teknis, bukti, jalur serangan, tingkat risiko, dan rekomendasi perbaikan. Laporan audit biasanya memuat kriteria, kondisi yang ditemukan, bukti pendukung, dampak atau risiko, serta tanggapan dan rencana tindakan dari pihak yang diaudit. Format detailnya bergantung pada metode dan kebutuhan organisasi.
Menentukan pendekatan berdasarkan tujuan
Organisasi yang akan meluncurkan aplikasi baru mungkin membutuhkan penetration testing untuk memeriksa permukaan serangan sebelum sistem digunakan. Organisasi yang sedang mengevaluasi proses pengelolaan akses membutuhkan audit untuk melihat apakah pembuatan, perubahan, dan pencabutan akses dikendalikan secara konsisten.
Jika tujuan utamanya adalah memahami apakah data sensitif dapat diakses melalui kelemahan aplikasi, pengujian teknis lebih relevan. Jika tujuan utamanya adalah menilai kepatuhan terhadap kebijakan internal atau kriteria yang telah ditetapkan, audit lebih sesuai. Ketika keduanya dibutuhkan, urutan pelaksanaan dapat disusun berdasarkan risiko dan kesiapan data, bukan berdasarkan anggapan bahwa salah satu metode selalu harus didahulukan.
Penetration testing juga tidak perlu dibatasi pada aplikasi produksi. Dalam beberapa situasi, pengujian pada lingkungan yang menyerupai produksi dapat mengurangi risiko gangguan. Namun, lingkungan uji yang berbeda terlalu jauh dari produksi dapat menyembunyikan masalah konfigurasi atau integrasi. Keputusan ini perlu didasarkan pada tujuan pengujian, kematangan lingkungan, dan toleransi risiko organisasi.
Merancang penetration testing yang dapat dipertanggungjawabkan
Mulai dari aturan pelaksanaan
Otorisasi tertulis adalah fondasi pengujian. Dokumen tersebut sebaiknya menyebutkan pemilik aset, target, rentang waktu, sumber alamat atau akun penguji, batasan teknik, prosedur pelaporan insiden, dan kontak yang dapat dihubungi. Untuk pengujian yang melibatkan pemasok atau layanan pihak ketiga, izin dari pihak yang berwenang perlu dipastikan sebelum aktivitas dimulai.
Tim juga perlu menyepakati definisi keberhasilan. Apakah pengujian bertujuan menemukan kerentanan pada fungsi tertentu, memvalidasi jalur akses, menilai segmentasi, atau menguji kemampuan deteksi? Tanpa tujuan yang jelas, pengujian mudah melebar dan menghasilkan temuan yang sulit diprioritaskan.
Bedakan temuan terindikasi dan temuan tervalidasi
Hasil pemindaian otomatis dapat membantu menemukan kandidat kerentanan, tetapi tidak selalu menunjukkan dampak yang nyata. Temuan perlu divalidasi dengan langkah yang aman dan proporsional. Penguji harus menghindari pengambilan data produksi yang tidak diperlukan, perubahan permanen pada sistem, atau tindakan yang dapat mengganggu ketersediaan layanan.
Laporan yang baik menjelaskan kondisi sebelum pengujian, langkah validasi pada tingkat yang aman, bukti yang relevan, aset yang terdampak, prasyarat serangan, dan batasan pengujian. Bukti sebaiknya disanitasi agar tidak menyebarkan rahasia seperti token, kata sandi, atau data pribadi. Tim pemilik sistem perlu dapat memahami temuan tanpa menerima salinan data sensitif yang berlebihan.
Jadikan perbaikan dapat ditindaklanjuti
Rekomendasi seperti “tingkatkan keamanan” tidak cukup membantu. Rekomendasi perlu mengarah pada perubahan yang dapat dikerjakan, misalnya memperbaiki pemeriksaan otorisasi pada sisi server, membatasi hak akun layanan, mengubah konfigurasi yang membuka akses publik, atau menambahkan pengujian regresi pada fungsi yang diperbaiki.
Setelah perbaikan dilakukan, lakukan pengujian ulang pada temuan yang relevan. Pengujian ulang bukan pemeriksaan menyeluruh yang otomatis membuktikan seluruh sistem aman. Fokusnya adalah memastikan kondisi yang dilaporkan telah ditangani dan perubahan tersebut tidak menghilangkan kontrol lain yang diperlukan.
Merancang audit IT yang tidak berhenti pada dokumen
Audit dimulai dengan penetapan tujuan dan kriteria. Tim harus mengetahui unit, sistem, proses, periode, dan kontrol yang termasuk dalam pemeriksaan. Jika ruang lingkup terlalu luas, kedalaman pemeriksaan dapat menurun. Jika terlalu sempit, risiko yang saling terkait mungkin tidak terlihat.
Permintaan bukti sebaiknya disusun berdasarkan kontrol, bukan sekadar daftar dokumen. Untuk kontrol perubahan sistem, misalnya, auditor dapat meminta kebijakan, contoh tiket perubahan, persetujuan, hasil pengujian, dan bukti penerapan pada sistem. Untuk kontrol akses, auditor dapat memeriksa aturan pemberian akses, tinjauan berkala, pemisahan tugas, dan bukti pencabutan akses.
Pengambilan sampel perlu dijelaskan secara jujur. Sampel tidak berarti seluruh transaksi atau seluruh akun telah diperiksa. Hasilnya harus dibaca sesuai periode, populasi, metode pemilihan, dan keterbatasan bukti. Jika bukti tidak tersedia, kondisi tersebut sebaiknya dicatat sebagai keterbatasan atau temuan yang sesuai dengan kriteria, bukan ditutup dengan asumsi bahwa kontrol pasti berjalan.
Tanggapan manajemen juga perlu memiliki pemilik, tindakan, dan target penyelesaian yang jelas. Rencana perbaikan yang hanya menyebut “akan ditinjau” sulit dipantau. Sebaliknya, tindakan yang menghubungkan masalah dengan perubahan proses, konfigurasi, pelatihan, atau pemantauan akan lebih mudah diverifikasi.
Menghubungkan hasil teknis dengan risiko bisnis
Temuan keamanan tidak seharusnya diprioritaskan hanya berdasarkan tingkat keparahan dari alat atau label yang digunakan. Prioritas perlu mempertimbangkan apakah aset dapat diakses dari luar, nilai dan sensitivitas data, hak akses yang mungkin diperoleh, kemungkinan eksploitasi, ketergantungan terhadap sistem lain, serta efektivitas kontrol deteksi dan respons.
Contoh ilustratif: kelemahan pada sistem uji yang tidak terhubung ke data sensitif tidak memiliki konteks yang sama dengan kelemahan serupa pada sistem produksi. Namun, sistem uji tetap dapat berisiko jika menyimpan kredensial yang dapat digunakan untuk mengakses lingkungan lain. Analisis harus melihat jalur ketergantungan, bukan hanya nama lingkungan.
Audit dapat membantu menjawab mengapa masalah berulang. Jika temuan teknis terus muncul setelah perbaikan, penyebabnya mungkin bukan hanya konfigurasi yang salah. Bisa jadi tidak ada proses tinjauan perubahan, kepemilikan aset tidak jelas, inventaris tidak diperbarui, atau tidak ada mekanisme untuk memverifikasi perbaikan. Di titik ini, hasil penetration testing dan audit dapat saling memperkuat.
Kesalahan yang sering terjadi
Salah satu kesalahan adalah menjadwalkan penetration testing tanpa inventaris target yang memadai. Target yang tidak diketahui tidak akan masuk ruang lingkup, sementara perubahan DNS, endpoint, atau arsitektur dapat membuat hasil pengujian cepat kehilangan relevansi.
Kesalahan lain adalah memilih penguji berdasarkan kemampuan menghasilkan banyak temuan. Jumlah temuan bukan ukuran tunggal kualitas. Validasi, kejelasan bukti, pemahaman terhadap batasan, dan kemampuan menjelaskan perbaikan sama pentingnya untuk keputusan keamanan.
Pada audit, kesalahan umum adalah mengumpulkan dokumen tanpa memeriksa pelaksanaan. Kebijakan yang rapi dapat menyembunyikan praktik operasional yang berbeda. Audit juga dapat kehilangan konteks jika hanya mencatat ada atau tidaknya dokumen tanpa menilai apakah kontrol tersebut mengurangi risiko yang menjadi tujuannya.
Kedua kegiatan dapat gagal ketika pemilik sistem dilibatkan terlalu terlambat. Tim aplikasi, infrastruktur, operasi, legal, manajemen risiko, dan pemilik data mungkin memiliki tanggung jawab yang berbeda. Koordinasi sejak tahap perencanaan membantu mencegah salah tafsir ruang lingkup dan mempercepat respons terhadap temuan.
Alur kerja yang dapat digunakan organisasi
Tentukan tujuan. Jelaskan apakah kegiatan ditujukan untuk menemukan jalur serangan, memeriksa kontrol, memenuhi kebutuhan pihak tertentu, atau memvalidasi perbaikan.
Petakan aset dan pemiliknya. Catat sistem, lingkungan, data, dependensi, serta pihak yang memberi otorisasi dan menerima hasil.
Tetapkan kriteria dan ruang lingkup. Untuk penetration testing, definisikan target serta aturan pelaksanaan. Untuk audit, definisikan kontrol, periode, dan bukti yang diperlukan.
Nilai risiko pelaksanaan. Siapkan jadwal, kontak darurat, mekanisme pemantauan, dan keputusan tentang data uji atau lingkungan pengujian.
Laksanakan dengan pencatatan yang rapi. Simpan catatan aktivitas, bukti, asumsi, keterbatasan, dan perubahan ruang lingkup yang telah disetujui.
Bahas temuan bersama pemilik sistem. Klarifikasi fakta teknis dan operasional sebelum laporan final diterbitkan, tanpa menghapus temuan hanya karena perbaikannya belum dilakukan.
Prioritaskan tindakan. Hubungkan setiap tindakan dengan pemilik, tenggat, dependensi, dan cara verifikasi.
Verifikasi perbaikan. Gunakan pengujian ulang, pemeriksaan bukti, atau kombinasi keduanya sesuai jenis temuan.
Menjaga kualitas informasi dalam laporan
Laporan keamanan berisi informasi sensitif dan perlu diperlakukan sebagai aset yang memiliki risiko. Akses terhadap laporan, bukti teknis, kredensial uji, dan data yang dikumpulkan harus dibatasi sesuai kebutuhan kerja. Salinan yang tidak lagi diperlukan sebaiknya dikelola berdasarkan kebijakan retensi organisasi.
Bahasa laporan juga perlu membedakan fakta, interpretasi, dan rekomendasi. “Endpoint menerima permintaan tanpa pemeriksaan otorisasi yang memadai” adalah pernyataan kondisi teknis yang harus didukung bukti. “Hal ini dapat memungkinkan akses ke data milik pengguna lain” adalah analisis dampak yang perlu dijelaskan berdasarkan hasil validasi. “Tambahkan pemeriksaan otorisasi pada sisi server dan lakukan pengujian regresi” adalah rekomendasi.
Jika pengujian tidak mencakup area tertentu, batasan itu harus ditulis secara eksplisit. Tidak menguji konfigurasi cloud, kode sumber, perangkat pihak ketiga, atau skenario rekayasa sosial dapat memengaruhi cara pembaca menafsirkan hasil. Transparansi mengenai keterbatasan membuat laporan lebih berguna daripada klaim yang terlalu luas.
Gunakan penetration testing ketika organisasi perlu memahami jalur eksploitasi yang realistis dan dampak teknisnya. Gunakan audit IT ketika organisasi perlu menilai rancangan, pelaksanaan, dan bukti kontrol. Untuk program keamanan yang matang, gabungkan hasil keduanya dalam daftar risiko yang memiliki pemilik dan cara verifikasi. Sebelum menjadwalkan kegiatan, pastikan otorisasi tertulis, ruang lingkup, kriteria penilaian, perlindungan bukti, dan rencana tindak lanjut sudah disepakati.
