Vendor membangun aplikasi, melakukan pengujian, memperbaiki bug, kemudian menyampaikan bahwa aplikasi tersebut sudah aman dan siap digunakan.

Alur seperti ini terlihat wajar. Bahkan, dalam banyak proyek pengembangan aplikasi, proses tersebut dianggap cukup untuk melanjutkan sistem ke tahap produksi.

Namun, ada pertanyaan yang sering terlewat: jika pihak yang membangun, menguji, memperbaiki, dan menyatakan aplikasi aman adalah pihak yang sama, siapa yang benar-benar mencoba membuktikan bahwa klaim tersebut salah?

Persoalannya bukan tentang meragukan kemampuan vendor pengembang. Developer tetap menjadi pihak yang paling memahami arsitektur, fungsi, dan logika aplikasi yang dibuatnya. Namun, memahami bagaimana aplikasi seharusnya bekerja tidak selalu sama dengan melihat bagaimana aplikasi dapat disalahgunakan.

Di sinilah pengujian keamanan aplikasi membutuhkan perspektif yang berbeda.

“Sudah Diuji Developer” Belum Menjadi Bukti Akhir Keamanan

Developer memang harus melakukan pengujian keamanan selama proses pengembangan. Secure coding, code review, automated security testing, dependency checking, hingga pengujian sebelum deployment merupakan bagian penting dari pengembangan aplikasi yang baik.

Masalah muncul ketika semua proses tersebut kemudian dianggap cukup untuk menyimpulkan bahwa aplikasi telah aman.

Pengujian dari tim pengembang biasanya memiliki konteks yang sangat kuat terhadap fungsi sistem. Mereka mengetahui bagaimana pengguna seharusnya melakukan login, menu mana yang tersedia untuk setiap role, bagaimana API digunakan, dan bagaimana proses bisnis seharusnya berjalan.

Dalam penetration testing, pertanyaannya berbeda.

Pentester tidak hanya ingin mengetahui apakah fungsi tersebut berjalan. Mereka mencoba mencari tahu apa yang terjadi ketika sistem digunakan dengan cara yang tidak direncanakan.

Developer mungkin menguji apakah seorang pengguna dapat melihat invoice miliknya.

Pentester akan bertanya: apakah pengguna tersebut dapat mengganti ID dan membaca invoice milik pengguna lain?

Developer memastikan menu administrator tidak muncul pada akun biasa.

Pentester akan mencoba mengetahui apakah endpoint administrator masih dapat dipanggil secara langsung tanpa melalui menu tersebut.

Perbedaannya terlihat sederhana, tetapi justru dari perbedaan sudut pandang tersebut banyak kelemahan keamanan ditemukan.

Masalahnya Bukan Kompetensi, tetapi Perspektif

Vendor pengembang memiliki satu keuntungan besar: mereka mengenal aplikasi dengan sangat baik.

Mereka memahami arsitektur, source code, database, integrasi, authentication, API, hingga keputusan teknis yang dibuat selama pengembangan.

Namun, pengetahuan tersebut juga membuat proses pengujian secara tidak sadar mengikuti asumsi yang sudah terbentuk sejak aplikasi dirancang.

Developer tahu bahwa sebuah endpoint dibuat untuk role tertentu. Karena itu, pengujian dapat berfokus pada apakah endpoint tersebut bekerja sebagaimana mestinya untuk role tersebut.

Seorang pentester justru dapat memulai dari pertanyaan sebaliknya: apa yang terjadi jika endpoint tersebut digunakan oleh role yang tidak seharusnya memiliki akses?

Developer mengetahui urutan normal suatu proses bisnis.

Pentester akan mencoba melompati tahap tertentu, mengulang transaksi, mengubah parameter, memanipulasi request, atau menggunakan fungsi dengan urutan berbeda.

Karena itu, keamanan aplikasi tidak hanya membutuhkan orang yang mengetahui bagaimana sistem bekerja. Organisasi juga membutuhkan pihak yang secara khusus mencoba menemukan bagaimana sistem tersebut dapat gagal.

Pengetahuan mendalam terhadap sistem adalah keuntungan ketika membangun aplikasi, tetapi perspektif independen tetap dibutuhkan ketika mencoba menyerangnya.

Aplikasi Dapat Berjalan dengan Baik dan Tetap Memiliki Celah

Functional testing dan security testing menjawab pertanyaan yang berbeda.

Aplikasi dapat berhasil melewati User Acceptance Test, seluruh fitur berjalan, integrasi berfungsi, dan pengguna dapat menyelesaikan proses bisnis tanpa kendala. Kondisi tersebut menunjukkan bahwa aplikasi bekerja sesuai kebutuhan.

Namun, semuanya belum otomatis membuktikan bahwa kontrol keamanannya tidak dapat dilewati.

Contohnya dapat ditemukan pada fitur yang sebenarnya terlihat sederhana.

Sebuah sistem dapat berhasil membatasi tampilan dokumen berdasarkan akun pengguna. Namun, kelemahan authorization pada API dapat memungkinkan dokumen tersebut tetap diakses dengan memanipulasi identifier.

Sebuah aplikasi dapat menggunakan login dan multi-factor authentication. Namun, session management yang kurang tepat masih dapat membuka peluang penyalahgunaan akun.

Fitur upload dokumen mungkin hanya mengizinkan PDF dari antarmuka aplikasi. Akan tetapi, validasi yang berbeda pada sisi server dapat memberikan hasil berbeda ketika request dimodifikasi secara langsung.

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

Kerentanan tidak selalu muncul karena fungsi utama gagal. Sebaliknya, banyak risiko keamanan muncul ketika sebuah fungsi yang bekerja dengan baik digunakan di luar skenario yang sebelumnya dibayangkan.

Semakin Kompleks Sistem, Semakin Sulit Mengandalkan Satu Perspektif

Aplikasi bisnis saat ini jarang berdiri sendiri.

Sebuah aplikasi dapat terhubung dengan API pihak ketiga, Single Sign-On, cloud infrastructure, layanan pembayaran, aplikasi mobile, database, microservices, hingga berbagai sistem internal perusahaan.

Di saat yang sama, satu aplikasi dapat memiliki banyak jenis pengguna dengan hak akses berbeda.

Admin pusat mungkin memiliki akses yang berbeda dengan admin cabang. Supervisor memiliki kewenangan berbeda dengan staf. Pengguna eksternal memiliki akses yang berbeda dengan tim internal.

Pada aplikasi multi-tenant, persoalannya semakin sensitif karena beberapa organisasi menggunakan platform yang sama tetapi data mereka harus tetap terisolasi.

Setiap hubungan tersebut menciptakan asumsi keamanan.

Apakah authorization tetap bekerja jika request dibuat langsung ke API?

Apakah pengguna cabang A benar-benar tidak dapat mengakses informasi cabang B?

Apakah token dari satu aplikasi dapat digunakan pada layanan lain?

Apakah integrasi pihak ketiga membuka akses yang lebih luas daripada yang dibutuhkan?

Apakah perubahan role langsung memutus hak akses lama?

Pertanyaan seperti ini sulit dijawab hanya dengan memastikan fitur berjalan sebagaimana dirancang.

Jangan Hanya Membuktikan Vendor Benar, Coba Buktikan Ia Salah

Ada perubahan sederhana dalam cara perusahaan dapat memandang pengujian keamanan.

Jangan hanya mencari bukti bahwa kontrol keamanan bekerja.

Minta pihak lain mencoba membuktikan bahwa kontrol tersebut dapat gagal.

Vendor mengatakan authorization sudah diterapkan.

Pentester mencoba melewatinya.

Vendor mengatakan setiap tenant sudah terisolasi.

Pentester mencoba mengakses object milik tenant lain.

Vendor mengatakan API hanya dapat digunakan setelah authentication.

Pentester mencoba mencari endpoint, metode, atau alur yang mungkin melewati kontrol tersebut.

Vendor mengatakan pengguna biasa tidak mempunyai akses administratif.

Pentester mencoba melakukan privilege escalation.

Pendekatan semacam ini bukan bentuk ketidakpercayaan terhadap developer. Ini adalah bagian dari proses verifikasi.

Semakin penting aplikasi terhadap operasional perusahaan, semakin berisiko apabila keamanan hanya didasarkan pada asumsi bahwa kontrol yang dibuat pasti bekerja seperti yang direncanakan.

Independent Security Testing Bukan Pengganti Secure Development

Menggunakan pihak independen bukan berarti tanggung jawab keamanan dipindahkan dari developer ke perusahaan penetration testing.

Developer tetap harus membangun aplikasi dengan prinsip keamanan sejak tahap awal.

Security requirement perlu ditentukan sebelum pengembangan. Authentication dan authorization harus dirancang dengan benar. Dependency perlu dikelola. Source code perlu direview. Pengujian internal tetap harus dilakukan.

Independent security assessment menjadi lapisan berikutnya untuk menguji hasil tersebut dari perspektif berbeda.

Model yang lebih sehat dapat berjalan seperti berikut:

Secure Development → Internal Security Testing → Independent Penetration Testing → Remediation → Retest → Release

Dengan pendekatan tersebut, penetration testing bukan menjadi proses yang datang pada akhir proyek untuk “mencari kesalahan developer”.

Sebaliknya, pentest menjadi mekanisme untuk memberikan assurance tambahan sebelum risiko tersebut berpindah kepada perusahaan sebagai pengguna aplikasi.

Kapan Pengujian Independen Menjadi Semakin Penting?

Tidak semua aplikasi memiliki tingkat risiko yang sama. Namun, kebutuhan terhadap pengujian independen semakin tinggi ketika sistem mulai memegang peranan penting dalam bisnis.

Hal tersebut terutama berlaku apabila aplikasi:

• menyimpan atau memproses data sensitif;
• digunakan oleh banyak pengguna dengan role berbeda;
• memiliki API yang terhubung dengan sistem lain;
• mempunyai integrasi dengan pihak ketiga;
• menggunakan arsitektur multi-tenant;
• menjadi bagian dari proses bisnis kritis;
• akan berpindah dari staging ke production;
• mengalami perubahan arsitektur atau fitur besar;
• dikembangkan oleh vendor eksternal;
• menjadi bagian dari kebutuhan audit atau compliance.

Dalam kondisi tersebut, pertanyaan “apakah aplikasi berjalan?” saja sudah tidak cukup.

Perusahaan juga perlu memperoleh jawaban atas pertanyaan: apa yang dapat dilakukan seseorang apabila ia sengaja mencoba melampaui batas yang telah dibuat aplikasi?

Jangan Puas dengan Pernyataan “Sudah Pentest”

Independent penetration testing juga tidak seharusnya berubah menjadi formalitas.

Kalimat “aplikasi sudah dilakukan penetration testing” belum memberikan banyak informasi apabila perusahaan tidak mengetahui apa yang sebenarnya diuji.

Hasil security testing yang dapat dipertanggungjawabkan seharusnya memberikan gambaran mengenai ruang lingkup pengujian, metode yang digunakan, kerentanan yang ditemukan, tingkat risiko, bukti teknis, kemungkinan dampak, hingga rekomendasi remediasi.

Setelah perbaikan dilakukan, retest juga penting untuk memastikan bahwa celah yang ditemukan memang telah ditutup.

Tujuannya bukan memperoleh sertifikat atau laporan semata.

Tujuannya adalah memiliki evidence bahwa sistem telah diuji dari perspektif yang berbeda sebelum perusahaan menempatkan data, proses bisnis, pengguna, dan reputasinya di dalam sistem tersebut.

Pisahkan Kepentingan, Bukan Tanggung Jawab

Vendor pengembang dan perusahaan keamanan sebenarnya tidak perlu ditempatkan dalam posisi yang berlawanan.

Keduanya mempunyai fungsi berbeda.

Developer membangun sistem yang aman dan memperbaiki kelemahan.

Tim internal perusahaan memastikan sistem memenuhi kebutuhan bisnis dan kebijakan organisasi.

Pihak independen menguji asumsi keamanan yang telah diterapkan.

Setelah temuan tersedia, developer kembali melakukan remediasi dan pihak penguji melakukan retest.

Pemisahan tersebut bukan dimaksudkan untuk mencari siapa yang salah. Tujuannya justru menciptakan mekanisme kontrol yang lebih sehat.

Sebab, ketika seluruh keyakinan terhadap keamanan berasal dari satu pihak, perusahaan memiliki lebih sedikit kesempatan untuk menemukan blind spot sebelum penyerang menemukannya lebih dahulu.

Keamanan Membutuhkan Bukti, Bukan Sekadar Pernyataan

Kepercayaan terhadap vendor tetap dibutuhkan dalam setiap proyek pengembangan aplikasi.

Namun, untuk aspek keamanan, kepercayaan sebaiknya diperkuat dengan pengujian.

Vendor pengembang tentu dapat menyatakan bahwa kontrol keamanan sudah diterapkan berdasarkan desain, source code, dan pengujian internal yang mereka lakukan. Akan tetapi, organisasi tetap membutuhkan perspektif lain untuk menguji apakah kontrol tersebut benar-benar mampu bertahan terhadap penyalahgunaan.

Karena itu, pertanyaan yang seharusnya diajukan perusahaan bukan hanya:

“Apakah vendor mengatakan aplikasi ini aman?”

Pertanyaan yang lebih penting adalah:

“Siapa yang telah mencoba membuktikan bahwa aplikasi ini tidak aman, dan apa hasilnya?”

Validasi Keamanan Aplikasi Bersama Fourtrezz

Fourtrezz membantu perusahaan melakukan pengujian keamanan secara independen melalui layanan Penetration Testing dan Vulnerability Assessment untuk mengidentifikasi kerentanan pada aplikasi maupun sistem sebelum kelemahan tersebut dimanfaatkan oleh pihak yang tidak berwenang.

Dengan pengujian dari perspektif keamanan yang terpisah dari proses pengembangan, perusahaan dapat memperoleh gambaran yang lebih objektif mengenai risiko, temuan teknis, dampak, serta langkah remediasi yang perlu dilakukan.

Jika perusahaan Anda sedang mengembangkan aplikasi bersama vendor, mempersiapkan sistem menuju production, atau membutuhkan validasi keamanan terhadap aplikasi yang sudah berjalan, Fourtrezz dapat menjadi mitra untuk melakukan pengujian tersebut.

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