Sebuah perusahaan dapat menyelesaikan penetration testing hari ini, memperbaiki seluruh temuan penting, kemudian mendapatkan kondisi keamanan yang jauh berbeda hanya beberapa bulan kemudian.

Penyebabnya tidak selalu karena muncul kerentanan baru pada aplikasi yang sama.

Sistemnya sendiri mungkin sudah berubah.

Perusahaan menambahkan Single Sign-On (SSO), membuka API untuk mitra, menghubungkan aplikasi dengan payment gateway, menambahkan layanan cloud, mengganti mekanisme autentikasi, atau membuat integrasi dengan sistem internal lainnya.

Setiap perubahan tersebut membawa fungsi baru. Pada saat yang sama, perubahan tersebut juga dapat menghadirkan jalur komunikasi, hak akses, dependency, dan titik masuk baru yang belum ada ketika penetration testing terakhir dilakukan.

Di sinilah asumsi bahwa satu kali pentest cukup untuk memberikan keyakinan keamanan dalam jangka panjang mulai kehilangan relevansinya.

Pentest dapat memberikan gambaran penting mengenai kondisi keamanan suatu sistem. Namun sistem digital tidak berhenti berubah setelah laporan pentest diterbitkan.

Pentest Menguji Sistem yang Ada pada Saat Pengujian Dilakukan

Hasil penetration testing sangat bergantung pada scope dan kondisi sistem ketika pengujian berlangsung.

Tester mungkin menguji sejumlah aplikasi, domain, alamat IP, API, akun pengguna, role, atau komponen infrastruktur tertentu.

Pengujian kemudian menemukan kemungkinan kelemahan pada authentication, authorization, session management, konfigurasi, input validation, business logic, maupun area keamanan lainnya.

Masalahnya, kondisi tersebut tidak permanen.

Ketika developer melakukan major release, menambahkan API baru atau mengubah mekanisme permission, sebagian asumsi yang digunakan pada pengujian sebelumnya dapat ikut berubah.

Karena itu, laporan penetration testing lebih tepat dipandang sebagai gambaran keamanan pada suatu periode tertentu, bukan jaminan bahwa sistem akan mempertahankan kondisi yang sama tanpa batas waktu.

Pertanyaan yang seharusnya muncul setelah pentest bukan hanya:

“Apakah seluruh temuan sudah diperbaiki?”

Namun juga:

“Apa saja yang berubah sejak pengujian tersebut dilakukan?”

Satu Integrasi Baru Dapat Membawa Lebih Banyak Perubahan daripada yang Terlihat

Integrasi sering terlihat sederhana dari perspektif pengguna.

Tim pengembangan mungkin hanya menambahkan tombol login menggunakan identitas perusahaan atau menghubungkan aplikasi dengan payment gateway.

Di belakangnya, perubahan tersebut dapat menciptakan mekanisme komunikasi baru antara beberapa komponen.

Ada token yang harus dipertukarkan.

Ada API yang harus dibuka.

Ada data yang berpindah dari satu sistem ke sistem lainnya.

Ada service account yang memperoleh permission.

Ada credential yang harus disimpan.

Ada endpoint baru yang harus menerima request.

Ada pula keputusan mengenai sistem mana yang dipercaya untuk melakukan tindakan tertentu.

Dengan kata lain, integrasi bukan hanya menambah fitur.

Integrasi juga mengubah attack surface.

NIST dalam panduan keamanan untuk arsitektur berbasis microservices menyoroti bahwa bertambahnya komponen dan komunikasi antarlayanan dapat memperluas attack surface. Kondisi ini semakin relevan pada aplikasi modern yang beroperasi melalui banyak API dan layanan terdistribusi.

Semakin banyak komponen yang harus berkomunikasi, semakin banyak pula hubungan keamanan yang perlu dipastikan tetap berjalan sebagaimana mestinya.

Masalah Keamanan Dapat Berada di Antara Dua Sistem yang Sama-Sama Aman

Salah satu kekeliruan dalam melihat keamanan integrasi adalah menilai setiap sistem secara terpisah.

Sistem A mungkin memiliki kontrol keamanan yang baik.

Sistem B juga dapat memiliki kontrol yang sama baiknya.

Namun hal tersebut belum membuktikan bahwa hubungan antara Sistem A dan Sistem B aman.

Sebagai contoh, aplikasi internal mengirim token kepada layanan lain dengan permission yang terlalu luas.

Atau sebuah API mempercayai request karena berasal dari aplikasi tertentu tanpa melakukan validasi authorization yang memadai.

Pada kasus lain, sebuah layanan menerima identifier pengguna dari sistem lain dan menganggap identifier tersebut selalu valid.

Kerentanan seperti ini tidak selalu berada di dalam satu aplikasi.

Masalah justru muncul pada asumsi kepercayaan di antara dua sistem.

OWASP menempatkan authorization sebagai area penting dalam pengujian API karena aplikasi harus memastikan bahwa pengguna atau sistem yang meminta suatu objek memang memiliki hak terhadap objek tersebut.

Ketika jumlah integrasi meningkat, hubungan kepercayaan seperti ini ikut bertambah.

Artinya, keamanan tidak lagi cukup dinilai hanya berdasarkan kondisi setiap aplikasi secara individual.

API Membuat Attack Surface Bergerak Lebih Cepat

Perkembangan API merupakan salah satu faktor yang membuat keamanan aplikasi semakin dinamis.

Dahulu sebuah aplikasi mungkin memiliki sejumlah halaman yang relatif mudah dipetakan.

Saat ini, satu aplikasi dapat bergantung pada puluhan bahkan lebih banyak endpoint untuk menjalankan berbagai fungsi.

Endpoint tersebut dapat digunakan untuk mengambil data pelanggan, membuat transaksi, mengubah profil, melakukan approval, mengunggah dokumen, menjalankan autentikasi, hingga berkomunikasi dengan sistem pihak ketiga.

Setiap endpoint membawa pertanyaan keamanan sendiri.

Apakah authentication diterapkan dengan benar?

Apakah authorization diperiksa pada setiap request?

Apakah token memiliki permission yang sesuai?

Apakah data yang dikirim memang diperlukan?

Apakah request dapat dimanipulasi?

Apakah terdapat endpoint lama yang masih aktif tetapi tidak lagi digunakan?

NIST melalui panduan perlindungan API untuk sistem cloud-native juga menekankan pentingnya mengidentifikasi risiko sepanjang siklus hidup API, baik sebelum maupun ketika API telah berjalan.

Hal tersebut menunjukkan bahwa keamanan API bukan aktivitas satu kali.

API berkembang bersama sistem yang dilayaninya.

Ketika API berubah, risiko yang perlu diuji juga dapat berubah.

Update Kecil Tidak Selalu Menghasilkan Perubahan Risiko yang Kecil

Salah satu alasan organisasi dapat terlalu percaya pada hasil pentest sebelumnya adalah persepsi bahwa perubahan setelah pengujian tidak terlalu besar.

“Yang berubah hanya satu endpoint.”

“Yang ditambahkan hanya satu role.”

“Kami hanya mengganti SSO.”

“Ini hanya integrasi payment gateway.”

Dalam konteks keamanan, ukuran perubahan kode tidak selalu sebanding dengan perubahan risiko.

Satu endpoint baru yang memiliki authorization lemah dapat memberikan akses terhadap data penting.

Satu role baru dengan permission berlebihan dapat menciptakan privilege escalation.

Satu perubahan pada konfigurasi cloud dapat membuat resource yang sebelumnya private menjadi lebih terekspos.

Satu integration token dengan privilege terlalu tinggi dapat membuka akses yang jauh lebih luas dibanding fungsi yang sebenarnya dibutuhkan.

Karena itu, menentukan kebutuhan security testing hanya berdasarkan besarnya perubahan development dapat menghasilkan gambaran yang menyesatkan.

Pertanyaan yang lebih relevan adalah:

Apakah perubahan tersebut mengubah cara sistem memberikan akses, memproses data, atau berkomunikasi dengan komponen lain?

Jika jawabannya ya, perubahan tersebut layak mendapatkan perhatian keamanan.

Third-Party Integration Membawa Faktor yang Tidak Sepenuhnya Dapat Dikendalikan

Kompleksitas menjadi semakin tinggi ketika perusahaan menggunakan layanan pihak ketiga.

Hampir tidak mungkin seluruh fungsi digital modern dibangun sendiri.

Perusahaan dapat menggunakan payment gateway, layanan email, cloud storage, analytics, marketplace API, SaaS, identity provider, layanan komunikasi, hingga berbagai platform eksternal lainnya.

Keuntungan bisnisnya jelas. Integrasi mempercepat pengembangan dan mengurangi kebutuhan membangun seluruh fungsi dari awal.

Namun terdapat konsekuensi keamanan.

Sebagian perilaku sistem sekarang bergantung pada komponen yang berada di luar kendali langsung perusahaan.

API dapat berubah.

Model permission dapat diperbarui.

Library atau SDK dapat memperoleh versi baru.

Credential dapat memiliki lifecycle tersendiri.

Konfigurasi integrasi juga dapat berubah ketika ada kebutuhan operasional baru.

Hal tersebut bukan alasan untuk menghindari third-party integration.

Namun organisasi perlu menyadari bahwa setiap ketergantungan baru menambah variabel yang perlu dipertimbangkan dalam pengelolaan risiko keamanan.

Temuan Lama Dapat Ditutup, tetapi Attack Path Baru Tetap Bisa Muncul

Menyelesaikan remediasi merupakan bagian penting setelah penetration testing.

Jika ditemukan authorization issue, perusahaan memperbaikinya.

Jika terdapat konfigurasi yang berisiko, konfigurasi diperketat.

Jika terdapat endpoint yang seharusnya tidak dapat diakses, kontrol tambahan diterapkan.

Attack path yang ditemukan pada saat itu mungkin benar-benar sudah ditutup.

Namun beberapa bulan kemudian perusahaan menambahkan API baru.

API tersebut mengambil data dari sistem lama melalui mekanisme authorization yang berbeda.

Hasilnya, data yang sebelumnya sudah berhasil diamankan kembali dapat diakses melalui jalur yang tidak tersedia pada saat pentest sebelumnya.

Ini menggambarkan salah satu karakter penting keamanan aplikasi modern:

Remediasi menutup jalur serangan yang telah ditemukan, tetapi perubahan sistem dapat menciptakan jalur serangan yang baru.

Karena itu, status “seluruh temuan pentest sudah closed” memang penting, tetapi tidak dapat digunakan sebagai satu-satunya indikator keamanan untuk waktu yang tidak terbatas.

Semakin Dinamis Sistem, Semakin Cepat Hasil Pengujian Perlu Dievaluasi Kembali

Tidak semua sistem memiliki tingkat perubahan yang sama.

Ada aplikasi internal yang relatif stabil dan hanya mengalami beberapa perubahan dalam satu tahun.

Di sisi lain, ada aplikasi yang melakukan deployment hampir setiap minggu.

Ada pula platform dengan banyak microservices, integrasi API, aplikasi mobile, layanan cloud, serta sistem pihak ketiga yang terus berkembang.

Kedua kondisi tersebut tidak seharusnya menggunakan asumsi keamanan yang sama.

Semakin tinggi frekuensi perubahan, semakin banyak integrasi, dan semakin luas exposure suatu sistem, semakin cepat relevansi hasil pengujian sebelumnya perlu dievaluasi.

Hal ini sejalan dengan pendekatan Secure Software Development Framework dari NIST, yang menempatkan praktik keamanan sebagai bagian dari siklus pengembangan perangkat lunak, bukan sekadar aktivitas terpisah setelah aplikasi selesai dibuat.

Penelitian di ranah DevSecOps juga terus mengarah pada pendekatan yang mengintegrasikan security testing ke dalam proses Continuous Integration dan Continuous Delivery. Alasannya bukan karena penetration testing kehilangan peran, tetapi karena perubahan perangkat lunak sekarang dapat berlangsung jauh lebih cepat daripada siklus audit keamanan tradisional.

Pentest Berkala Tidak Berarti Selalu Menguji Seluruh Sistem dari Awal

Kebutuhan pengujian yang lebih rutin sering disalah artikan sebagai keharusan melakukan full penetration testing setelah setiap perubahan kecil.

Pendekatan tersebut tentu tidak selalu diperlukan.

Security testing dapat dirancang berdasarkan tingkat risiko dan perubahan yang terjadi.

Jika perubahan hanya terjadi pada API tertentu, pengujian dapat memprioritaskan area tersebut beserta hubungan yang terdampak.

Jika perusahaan mengganti identity provider, perhatian dapat diarahkan pada authentication, session, token, SSO flow, dan authorization.

Jika terdapat integrasi marketplace baru, pengujian dapat difokuskan pada API, credential, data flow, permission, webhook, serta hubungan aplikasi internal dengan layanan eksternal.

Jika terdapat major release, scope pengujian dapat diperluas karena perubahan menyentuh lebih banyak bagian aplikasi.

Pendekatan seperti ini memungkinkan perusahaan menyesuaikan security testing dengan perubahan yang benar-benar terjadi, bukan sekadar menjalankan pengujian berdasarkan kebiasaan.

Kalender Bukan Satu-satunya Trigger untuk Melakukan Pentest

Banyak organisasi memiliki kebijakan penetration testing tahunan.

Pendekatan tersebut masih berguna sebagai baseline.

Namun tanggal pada kalender tidak mengetahui bahwa minggu lalu perusahaan baru saja membuka sepuluh endpoint API.

Kalender juga tidak mengetahui bahwa perusahaan baru memigrasikan infrastruktur ke cloud, mengganti sistem autentikasi, atau menghubungkan aplikasi dengan platform pihak ketiga.

Karena itu, jadwal periodik idealnya dilengkapi dengan trigger berbasis perubahan.

Evaluasi keamanan dapat dipertimbangkan kembali ketika terjadi:

• major release pada aplikasi;
• penambahan API yang signifikan;
• perubahan authentication atau authorization;
• implementasi SSO;
• integrasi dengan pihak ketiga;
• perubahan arsitektur;
• migrasi cloud;
• perubahan pada komponen yang terekspos internet;
• perubahan besar pada role dan permission;
• atau penambahan sistem yang memproses data sensitif.

Pendekatan seperti ini membuat security testing lebih dekat dengan kondisi risiko yang sebenarnya.

Bukan sekadar mengikuti tanggal.

Pertanyaan yang Lebih Penting Bukan “Kapan Terakhir Pentest?”

Ada sebuah pertanyaan yang sering terdengar sederhana dalam evaluasi keamanan:

“Kapan terakhir kali aplikasi ini melakukan pentest?”

Pertanyaan tersebut penting, tetapi belum lengkap.

Pertanyaan berikutnya justru dapat memberikan informasi yang lebih berharga:

“Apa saja yang berubah sejak pentest terakhir?”

Apakah ada endpoint baru?

Apakah terdapat role baru?

Apakah permission berubah?

Apakah ada vendor baru yang memperoleh akses?

Apakah aplikasi mulai terhubung dengan sistem lain?

Apakah terdapat perubahan cloud?

Apakah mekanisme authentication berubah?

Apakah ada data baru yang sekarang diproses?

Apakah terdapat service account atau API key baru?

Jika perubahan tersebut cukup banyak, perusahaan sebenarnya tidak lagi memiliki sistem yang sama dengan sistem yang dahulu diuji.

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

Dalam praktiknya, sistem digital dapat berkembang jauh lebih cepat dibanding jadwal security assessment. Karena itu, memahami perubahan sejak pengujian terakhir menjadi sama pentingnya dengan membaca daftar temuan pada laporan pentest sebelumnya.

Keamanan Tidak Berhenti ketika Laporan Pentest Diterbitkan

Penetration testing tetap memiliki posisi penting dalam strategi keamanan.

Pengujian membantu organisasi melihat sistem dari perspektif serangan, mengidentifikasi vulnerability, mengevaluasi kontrol keamanan, dan memahami kemungkinan dampak apabila sebuah kelemahan dapat dieksploitasi.

Namun nilai penetration testing tidak terletak pada anggapan bahwa satu pengujian dapat memberikan label “aman” secara permanen.

Nilainya berada pada kemampuan memberikan gambaran keamanan terhadap sistem yang diuji, sehingga organisasi dapat melakukan perbaikan berdasarkan risiko yang ditemukan.

Setelah itu, sistem akan terus berkembang.

Developer menambahkan fitur.

Tim bisnis meminta integrasi.

Arsitektur berubah.

API bertambah.

Vendor baru masuk.

Permission diperbarui.

Attack surface ikut bergerak bersama seluruh perubahan tersebut.

Karena itu, semakin banyak sistem saling terhubung, semakin sulit mempertahankan asumsi bahwa hasil satu kali pentest akan selalu mewakili kondisi keamanan di masa mendatang.

Sistem berubah. Attack surface berubah. Strategi pengujian keamanan seharusnya mengikuti perubahan keduanya.

Evaluasi Keamanan Sistem Bersama Fourtrezz

Jika perusahaan Anda memiliki aplikasi dengan banyak integrasi API, SSO, layanan cloud, sistem internal, atau koneksi dengan platform pihak ketiga, evaluasi keamanan perlu mempertimbangkan keseluruhan hubungan tersebut.

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk membantu perusahaan mengidentifikasi kerentanan pada aplikasi maupun infrastruktur. Fourtrezz juga memiliki layanan cybersecurity dan IT development yang dapat mendukung perusahaan dalam membangun serta mengevaluasi sistem dengan mempertimbangkan aspek keamanan sejak proses pengembangan.

Scope pengujian dapat disesuaikan dengan karakteristik sistem, termasuk aplikasi web, API, infrastruktur, perubahan arsitektur, maupun integrasi yang menjadi bagian penting dari proses bisnis perusahaan.

Jika perusahaan Anda sedang merencanakan pentest, melakukan evaluasi setelah major release, atau ingin memastikan integrasi baru tidak membuka jalur serangan yang sebelumnya tidak tersedia, Fourtrezz dapat menjadi mitra dalam proses tersebut.

Hubungi Fourtrezz:

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