Seluruh temuan telah berstatus closed. Tim pengembang sudah mengirimkan bukti perbaikan, pengujian ulang telah dilakukan, dan laporan terbaru menunjukkan bahwa celah sebelumnya tidak lagi dapat dieksploitasi dengan cara yang sama.

Secara administratif, proses remediasi terlihat selesai.

Namun, penyerang tidak menilai keamanan berdasarkan status tiket. Mereka tidak peduli apakah sebuah temuan telah ditandai selesai, melewati tenggat remediasi, atau berhasil ditutup dalam laporan retest. Perhatian mereka hanya tertuju pada satu hal: apakah masih ada jalan lain untuk mencapai tujuan yang sama.

Di sinilah organisasi perlu membedakan antara menutup temuan pentest dan memutus jalur serangan. Keduanya berkaitan, tetapi tidak selalu menghasilkan kesimpulan keamanan yang sama.

Sebuah kerentanan dapat berhasil diperbaiki secara teknis. Meski demikian, hak akses berlebih, konfigurasi yang lemah, integrasi antar sistem, atau fungsi alternatif mungkin masih memungkinkan penyerang mencapai aset yang sebelumnya menjadi target.

Artinya, bukti eksploitasi lama memang sudah hilang, tetapi risiko yang ingin dihentikan belum tentu ikut menghilang.

Organisasi Sering Menutup Temuan, Bukan Menghilangkan Kemampuan Penyerang

Sebagian besar proses remediasi dibangun berdasarkan daftar temuan. Setiap kelemahan memiliki nomor, tingkat risiko, penanggung jawab, rekomendasi, tenggat waktu, dan status penyelesaian.

Pendekatan tersebut diperlukan agar proses perbaikan dapat dikelola dengan tertib. Tim keamanan dapat mengetahui temuan mana yang belum ditangani, sementara manajemen dapat memantau kemajuan remediasi.

Masalahnya muncul ketika struktur administratif tersebut menjadi satu-satunya cara organisasi memahami risiko.

Serangan nyata tidak selalu mengikuti pembagian temuan dalam laporan pentest. Penyerang dapat menggabungkan beberapa kelemahan yang terlihat terpisah menjadi satu rangkaian tindakan. Informasi pengguna yang terekspos dapat digunakan untuk mengenali akun internal. Kesalahan konfigurasi autentikasi kemudian membuka peluang akses. Setelah masuk, hak akses berlebih dapat dimanfaatkan untuk menjangkau fungsi sensitif.

Setiap kelemahan mungkin memiliki pemilik dan tiket perbaikan yang berbeda. Akan tetapi, bagi penyerang, semuanya merupakan bagian dari satu jalur serangan.

Karena itu, menutup satu temuan belum tentu memutus keseluruhan rangkaian. Jalur tersebut dapat tetap hidup melalui fungsi lain, akun berbeda, API lama, konfigurasi alternatif, atau sistem yang terhubung.

Status Closed Hanya Menjawab Sebagian Pertanyaan

Ketika sebuah temuan dinyatakan selesai, organisasi biasanya telah menjawab pertanyaan berikut:

“Apakah kelemahan yang dilaporkan sudah diperbaiki?”

Pertanyaan tersebut penting, tetapi belum cukup. Masih ada pertanyaan lain yang lebih menentukan:

“Apakah penyerang masih dapat mencapai dampak bisnis yang sama?”

Perbedaan ini terlihat sederhana, tetapi membawa konsekuensi besar terhadap cara retest penetration testing dilakukan.

Sebagai contoh, sebuah endpoint yang sebelumnya dapat digunakan untuk mengakses data pengguna tanpa izin telah diperbaiki. Pengujian ulang menunjukkan bahwa permintaan lama kini ditolak oleh sistem.

Temuan tersebut layak dinyatakan tidak lagi dapat direproduksi.

Namun, apabila fungsi ekspor data pada modul lain masih menggunakan pemeriksaan hak akses yang lemah, tujuan serangan belum benar-benar terhalang. Penyerang hanya perlu berpindah rute.

Dalam situasi tersebut, perbaikan teknis memang berhasil menghentikan satu metode eksploitasi. Akan tetapi, kemampuan penyerang untuk memperoleh data sensitif masih tersedia.

Status closed tidak salah. Kesimpulannya hanya terlalu sempit apabila digunakan sebagai bukti bahwa seluruh risiko telah berakhir.

Retest yang Berhasil Belum Tentu Membuktikan Jalur Serangan Terputus

Retest merupakan tahap penting setelah remediasi temuan pentest. Pengujian ini memastikan bahwa tindakan perbaikan benar-benar diterapkan dan teknik eksploitasi sebelumnya tidak lagi berhasil.

Tanpa retest, organisasi hanya mengandalkan keyakinan bahwa perubahan kode, konfigurasi, atau kontrol keamanan telah bekerja sesuai rencana.

Meskipun demikian, kualitas kesimpulan retest sangat bergantung pada ruang lingkup pengujiannya.

Retest yang terlalu terbatas biasanya berfokus pada langkah-langkah berikut:

• menjalankan kembali permintaan yang sebelumnya digunakan;
• menggunakan payload atau parameter yang sama;
• memeriksa perubahan respons aplikasi;
• memastikan bukti eksploitasi lama tidak lagi muncul;
• memverifikasi konfigurasi yang secara langsung berkaitan dengan temuan.

Pendekatan tersebut dapat membuktikan bahwa metode lama telah dihentikan. Namun, ia belum selalu menjawab apakah terdapat variasi eksploitasi, bypass, atau jalur alternatif.

Penguji perlu membedakan dua kesimpulan:

“Teknik eksploitasi sebelumnya sudah tidak berhasil.”

dan

“Tujuan serangan sudah tidak dapat dicapai melalui lingkungan tersebut.”

Kesimpulan pertama dapat diperoleh dari retest yang spesifik. Kesimpulan kedua membutuhkan pemahaman lebih luas terhadap arsitektur, hubungan antarsistem, model hak akses, dan aset yang ingin dilindungi.

Penyerang Tidak Bergantung pada Satu Kerentanan

Salah satu kesalahan umum dalam vulnerability remediation adalah menganggap setiap temuan berdiri sendiri. Padahal, banyak serangan serius terjadi karena penyerang mampu menghubungkan kelemahan-kelemahan yang secara individual tidak selalu terlihat kritis.

Bayangkan sebuah skenario ketika aplikasi memiliki beberapa kelemahan berikut:

• informasi akun dapat diperkirakan melalui respons aplikasi;
• pembatasan percobaan login tidak diterapkan secara konsisten;
• akun operasional memiliki hak akses lebih luas daripada yang dibutuhkan;
• layanan internal dapat diakses menggunakan kredensial akun tersebut;
• segmentasi antara aplikasi dan penyimpanan data belum memadai.

Tidak semua temuan itu harus memiliki tingkat keparahan kritis. Beberapa mungkin hanya dinilai rendah atau sedang ketika diperiksa secara terpisah.

Namun, ketika digabungkan, kelemahan tersebut membentuk jalur dari pengumpulan informasi, pengambilalihan akun, peningkatan kemampuan akses, hingga pencapaian aset penting.

Inilah alasan mengapa organisasi tidak seharusnya menilai keberhasilan remediasi hanya dari jumlah temuan yang telah ditutup. Penilaian juga perlu mempertimbangkan apakah hubungan antarkelemahan telah berubah.

Penutupan satu kelemahan akan bernilai tinggi apabila benar-benar memutus rangkaian serangan. Sebaliknya, penutupan banyak temuan dapat memberikan pengurangan risiko yang terbatas apabila jalur menuju aset kritis tetap tersedia.

Jalur Serangan Dapat Berpindah tanpa Mengubah Tujuannya

Ketika satu akses dihentikan, penyerang tidak harus menyerah. Mereka dapat mencari fungsi lain yang memberikan kemampuan serupa.

Pada aplikasi yang memiliki banyak modul dan integrasi, satu tujuan sering kali dapat dicapai melalui beberapa jalur.

Akses terhadap data pelanggan, misalnya, mungkin tersedia melalui:

• halaman administrasi;
• endpoint API;
• fungsi ekspor laporan;
• integrasi dengan aplikasi pihak ketiga;
• salinan data pada lingkungan pengujian;
• layanan pencadangan;
• akun layanan yang memiliki hak akses ke basis data.

Apabila organisasi hanya memperbaiki jalur yang ditemukan saat pentest pertama, rute alternatif mungkin tetap terbuka.

Kondisi serupa dapat terjadi pada infrastruktur. Akses langsung ke sebuah server mungkin telah dibatasi, tetapi penyerang masih dapat mencapainya melalui server lain yang berada dalam segmen jaringan yang sama. Kredensial administrator mungkin telah diganti, tetapi service account dengan hak setara belum ikut diperiksa.

Dalam konteks ini, jalur serangan tidak benar-benar hilang. Jalur tersebut hanya berubah bentuk.

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

Perusahaan umumnya telah menunjukkan komitmen untuk memperbaiki temuan. Namun, proses remediasi terkadang masih berfokus pada bukti eksploitasi yang tertulis di laporan, bukan pada keseluruhan kemampuan yang ingin diperoleh penyerang.

Perbaikan Lokal Dapat Menyisakan Risiko yang Bersifat Sistemik

Tidak semua remediasi menyentuh akar masalah. Sebagian perbaikan hanya menghentikan contoh eksploitasi tertentu tanpa mengubah pola kelemahan yang melatarbelakanginya.

Sebagai contoh, tim pengembang dapat memblokir satu parameter yang digunakan untuk mengeksploitasi input. Perbaikan tersebut mungkin berhasil menghentikan payload yang dilaporkan. Akan tetapi, apabila metode validasi input yang sama digunakan di banyak modul, kelemahan serupa dapat tetap muncul pada bagian lain.

Hal yang sama terjadi pada masalah otorisasi. Menambahkan pemeriksaan akses pada satu endpoint tidak akan menyelesaikan masalah apabila aplikasi belum memiliki mekanisme otorisasi yang konsisten pada seluruh fungsi sensitif.

Beberapa bentuk perbaikan lokal yang perlu diperiksa kembali antara lain:

• menutup satu endpoint tanpa mengevaluasi endpoint lain dengan fungsi serupa;
• mengganti kredensial tanpa memperbaiki tata kelola penyimpanan rahasia;
• memblokir satu alamat IP tanpa memperbaiki kontrol autentikasi;
• menonaktifkan satu akun tanpa meninjau proses pemberian hak akses;
• menghapus satu dependency tanpa memperbaiki pengelolaan komponen;
• menutup satu port tanpa mengevaluasi segmentasi jaringan;
• menyaring satu payload tanpa memperbaiki metode validasi dan encoding.

Perbaikan tersebut tidak selalu keliru. Dalam kondisi tertentu, tindakan cepat memang dibutuhkan untuk mengurangi eksposur.

Namun, organisasi perlu menyadari bahwa mitigasi sementara berbeda dari penyelesaian akar masalah. Keduanya perlu dicatat secara berbeda agar status closed tidak menciptakan persepsi keamanan yang terlalu optimistis.

Technical Closure dan Risk Closure Perlu Dibedakan

Agar proses remediasi lebih akurat, organisasi dapat membedakan dua tingkat penutupan temuan.

Technical closure

Technical closure menunjukkan bahwa kelemahan yang diuji sudah tidak dapat dieksploitasi menggunakan metode yang sebelumnya berhasil.

Pada tahap ini, penguji memastikan bahwa:

• perubahan telah diterapkan;
• payload lama tidak lagi berhasil;
• respons sistem sudah sesuai;
• bukti eksploitasi sebelumnya tidak dapat dihasilkan kembali;
• konfigurasi yang terdampak telah diperbarui.

Technical closure memberikan kepastian bahwa tim telah menangani temuan yang dilaporkan.

Risk closure

Risk closure memiliki cakupan lebih luas. Penilaian tidak berhenti pada bukti teknis, tetapi melihat apakah kemungkinan dampak bisnis telah dikurangi sampai tingkat yang dapat diterima.

Pada tahap ini, organisasi perlu mempertimbangkan:

• apakah kemampuan serupa tersedia melalui fungsi lain;
• apakah jalur alternatif menuju aset kritis masih terbuka;
• apakah akar masalah telah diperbaiki;
• apakah perubahan menciptakan kelemahan baru;
• apakah hak akses telah dikurangi secara konsisten;
• apakah kontrol pencegahan dan deteksi bekerja;
• apakah tingkat risiko residual telah diterima oleh pihak yang berwenang.

Technical closure dapat menjadi prasyarat bagi risk closure, tetapi keduanya tidak selalu terjadi pada waktu yang sama.

Sebuah temuan dapat selesai secara teknis, sementara risiko yang lebih luas masih memerlukan perubahan arsitektur, penyesuaian proses, atau penguatan kontrol pada sistem lain.

Severity Tidak Selalu Menunjukkan Posisi Temuan dalam Jalur Serangan

Prioritas remediasi sering ditentukan berdasarkan tingkat keparahan. Temuan kritis dan tinggi ditangani lebih dahulu, sedangkan temuan sedang atau rendah ditempatkan pada antrean berikutnya.

Pendekatan tersebut membantu organisasi mengelola sumber daya. Namun, severity tidak boleh menjadi satu-satunya dasar.

Sebuah temuan dengan tingkat risiko sedang dapat memiliki posisi penting apabila menjadi penghubung menuju aset bernilai tinggi. Sebaliknya, kelemahan teknis dengan skor tinggi mungkin memiliki dampak aktual yang lebih terbatas karena berada pada sistem terisolasi dan dilindungi kontrol tambahan.

Temuan perlu dinilai berdasarkan konteks, antara lain:

• posisi aset dalam proses bisnis;
• tingkat eksposur sistem;
• hak akses yang dapat diperoleh;
• hubungan dengan identitas atau kredensial;
• kemungkinan lateral movement;
• ketersediaan kontrol pengamanan lain;
• keterhubungan dengan aset kritis;
• potensi penggabungan dengan kelemahan lain.

Pendekatan ini membantu tim melihat temuan bukan hanya sebagai daftar masalah, tetapi sebagai bagian dari peta serangan.

Satu Titik Perbaikan Dapat Memutus Beberapa Jalur Sekaligus

Dalam jalur serangan, terdapat titik tertentu yang menjadi penghubung bagi beberapa rute. Titik tersebut dapat berupa akun dengan hak akses tinggi, server perantara, mekanisme autentikasi, konfigurasi jaringan, atau layanan internal.

Memperkuat titik semacam ini dapat menghasilkan pengurangan risiko yang jauh lebih besar daripada menutup banyak temuan secara terpisah.

Sebagai contoh, beberapa jalur serangan mungkin bergantung pada satu service account yang memiliki izin terlalu luas. Dengan membatasi hak akses akun tersebut, menerapkan rotasi kredensial, serta meningkatkan pemantauan, organisasi dapat memutus beberapa rangkaian serangan sekaligus.

Pendekatan ini bukan berarti temuan lain dapat diabaikan. Setiap kelemahan tetap perlu dikelola berdasarkan risikonya.

Namun, organisasi perlu memahami bahwa efektivitas remediasi tidak selalu sebanding dengan jumlah tiket yang ditutup. Satu perubahan strategis pada titik penghubung dapat lebih bermakna daripada puluhan perbaikan yang tidak mengubah akses menuju aset kritis.

Perubahan Setelah Pentest Dapat Menciptakan Jalur Baru

Remediasi sendiri merupakan perubahan terhadap sistem. Perubahan kode, konfigurasi, hak akses, atau arsitektur dapat menghasilkan konsekuensi yang tidak direncanakan.

Sebagai contoh, tim mungkin menambahkan kontrol autentikasi baru untuk menutup akses tidak sah. Namun, agar tidak mengganggu integrasi, dibuat jalur pengecualian bagi layanan tertentu. Apabila pengecualian tersebut tidak dibatasi dengan benar, jalur baru dapat muncul.

Risiko serupa dapat terjadi ketika organisasi:

• menambahkan proxy atau gateway baru;
• mengubah mekanisme single sign-on;
• memindahkan layanan ke cloud;
• membuat role baru;
• mengubah alur persetujuan;
• menambahkan API untuk kebutuhan integrasi;
• mengaktifkan mekanisme fallback;
• memindahkan data ke penyimpanan baru;
• menyesuaikan konfigurasi firewall.

Karena itu, retest tidak seharusnya hanya mengulang eksploitasi lama. Pengujian juga perlu melihat bagian sistem yang ikut berubah akibat proses remediasi.

Tujuannya bukan memperluas ruang lingkup tanpa batas, tetapi memastikan bahwa perbaikan tidak memindahkan risiko dari satu tempat ke tempat lain.

Lima Pertanyaan Sebelum Temuan Dinyatakan Benar-Benar Selesai

Sebelum menutup proses remediasi, organisasi dapat menggunakan lima pertanyaan berikut sebagai pemeriksaan tambahan.

1. Apakah akar masalah telah diperbaiki?

Pastikan perubahan tidak hanya memblokir payload, parameter, akun, atau endpoint yang tertulis pada laporan. Evaluasi pola kelemahan yang memungkinkan eksploitasi terjadi.

2. Apakah kemampuan yang sama tersedia melalui fungsi lain?

Periksa modul, API, role, integrasi, versi lama, dan proses alternatif yang dapat menghasilkan dampak serupa.

3. Apakah perbaikan memengaruhi komponen lain?

Identifikasi perubahan pada autentikasi, otorisasi, koneksi antarlayanan, konfigurasi jaringan, dan penyimpanan data.

4. Apakah penyerang masih dapat mencapai aset yang sama?

Mulailah evaluasi dari tujuan serangan. Apabila aset kritis masih dapat dicapai melalui jalur lain, risiko belum sepenuhnya terputus.

5. Apakah kontrol dapat bertahan setelah perubahan berikutnya?

Periksa apakah perbaikan telah masuk ke standar pengembangan, konfigurasi dasar, pengujian otomatis, dan proses deployment. Tanpa kontrol yang berkelanjutan, kelemahan dapat muncul kembali.

Kapan Retest Terbatas Sudah Memadai?

Retest dengan ruang lingkup spesifik tetap tepat digunakan ketika perubahan benar-benar lokal dan tidak memiliki keterkaitan luas.

Pendekatan ini dapat dipertimbangkan apabila:

• temuan hanya memengaruhi satu komponen;
• tidak ada perubahan arsitektur;
• perbaikan tidak mengubah autentikasi atau otorisasi;
• tidak ada integrasi lain yang terdampak;
• temuan tidak menjadi bagian dari exploit chain;
• lingkungan tidak mengalami perubahan signifikan;
• fungsi yang diperbaiki tidak berhubungan dengan aset kritis.

Dalam kondisi tersebut, retest dapat difokuskan pada validasi perbaikan, variasi payload, dan kemungkinan bypass yang masih berkaitan langsung dengan temuan.

Kapan Pengujian yang Lebih Luas Diperlukan?

Pentest ulang atau pengujian lanjutan perlu dipertimbangkan ketika perubahan berpotensi memengaruhi banyak komponen atau jalur akses.

Kondisi tersebut antara lain:

• terdapat perubahan besar pada aplikasi;
• mekanisme autentikasi diperbarui;
• model role dan permission diubah;
• API atau integrasi baru ditambahkan;
• arsitektur deployment berubah;
• temuan sebelumnya membentuk exploit chain;
• perbaikan menyentuh alur transaksi bisnis;
• aset yang terdampak memiliki nilai kritis;
• terdapat jeda panjang antara pentest dan retest;
• sistem terus mengalami pengembangan selama remediasi;
• ditemukan jalur alternatif pada proses pengujian ulang.

Pengujian yang lebih luas tidak berarti seluruh proses pentest harus selalu diulang dari awal. Ruang lingkup dapat ditentukan berdasarkan area perubahan, keterhubungan sistem, serta potensi dampaknya terhadap jalur serangan.

Retest yang Lebih Bernilai Harus Menguji Perubahan Kemampuan Penyerang

Retest yang baik tidak hanya mengonfirmasi bahwa kode telah berubah. Pengujian perlu melihat apakah perubahan tersebut benar-benar mengurangi kemampuan penyerang.

Prosesnya dapat mencakup beberapa lapisan.

Pertama, penguji menjalankan kembali metode eksploitasi awal untuk memastikan kelemahan tidak lagi dapat direproduksi.

Kedua, penguji mencoba variasi, bypass, role berbeda, endpoint alternatif, atau perubahan urutan proses.

Ketiga, komponen yang berhubungan dengan perbaikan ikut diperiksa. Hal ini penting terutama apabila temuan melibatkan autentikasi, otorisasi, API, jaringan, layanan cloud, atau integrasi.

Keempat, penguji menilai apakah tujuan serangan masih dapat dicapai melalui jalur lain yang realistis.

Kelima, organisasi memeriksa kemampuan deteksi. Upaya eksploitasi yang gagal seharusnya dapat dicatat dan, untuk aktivitas berisiko tinggi, menghasilkan informasi yang dapat ditindaklanjuti oleh tim keamanan.

Dengan pendekatan tersebut, retest bukan hanya menjadi proses pemberian status, tetapi menjadi validasi terhadap perubahan risiko.

Ukuran Keberhasilan Remediasi Perlu Melampaui Jumlah Temuan Closed

Jumlah temuan yang telah ditutup tetap merupakan metrik penting. Organisasi perlu mengetahui kecepatan tim dalam menangani kelemahan dan memastikan tidak ada temuan kritis yang dibiarkan terlalu lama.

Namun, metrik administratif perlu dilengkapi dengan ukuran yang mencerminkan perubahan postur keamanan.

Beberapa indikator yang dapat dipertimbangkan meliputi:

• berkurangnya jalur menuju aset kritis;
• menurunnya jumlah akun dengan hak akses berlebih;
• berkurangnya aset yang terekspos ke internet;
• meningkatnya efektivitas segmentasi jaringan;
• hilangnya jalur lateral movement;
• berkurangnya ketergantungan pada satu kontrol;
• terselesaikannya akar masalah secara sistemik;
• meningkatnya kemampuan mendeteksi percobaan eksploitasi;
• berkurangnya risiko residual setelah perubahan;
• tidak munculnya kembali kelemahan pada deployment berikutnya.

Ukuran tersebut membantu organisasi menilai apakah remediation pentest menghasilkan perubahan keamanan yang nyata, bukan sekadar perubahan status pada laporan.

Pentest Seharusnya Berakhir pada Perubahan Risiko

Laporan pentest memberi organisasi pandangan mengenai kelemahan yang dapat dimanfaatkan pada suatu periode pengujian. Remediasi kemudian mengubah sistem berdasarkan temuan tersebut, sedangkan retest memvalidasi apakah tindakan perbaikan telah bekerja.

Ketiga proses ini perlu terhubung oleh tujuan yang sama: mengurangi kemampuan penyerang untuk menghasilkan dampak terhadap bisnis.

Karena itu, status closed sebaiknya tidak dipahami sebagai akhir mutlak. Status tersebut merupakan bukti bahwa satu masalah telah ditangani sesuai ruang lingkup pengujian. Organisasi masih perlu memastikan bahwa jalur alternatif, akar masalah, dan hubungan antarsistem tidak meninggalkan risiko yang setara.

Temuan yang tidak lagi dapat direproduksi merupakan hasil positif. Namun, hasil yang lebih penting adalah ketika penyerang tidak lagi memiliki rute yang realistis untuk mencapai aset dan dampak yang sama.

Pada akhirnya, keberhasilan pentest tidak ditentukan oleh seberapa cepat seluruh tiket berubah menjadi hijau. Keberhasilannya ditentukan oleh seberapa besar proses tersebut mengubah peluang serangan, memperkuat kontrol, dan mengurangi risiko bisnis secara nyata.

Validasi Remediasi dan Keamanan Sistem Bersama Fourtrezz

Fourtrezz membantu perusahaan mengevaluasi keamanan aplikasi, API, jaringan, dan infrastruktur melalui layanan penetration testing dan vulnerability assessment. Pengujian dilakukan untuk menemukan kelemahan teknis, memvalidasi kemungkinan eksploitasi, serta memberikan rekomendasi perbaikan yang dapat disesuaikan dengan kondisi sistem dan kebutuhan bisnis.

Bagi perusahaan yang telah menyelesaikan remediasi, Fourtrezz juga dapat membantu melakukan retest untuk memastikan temuan telah ditangani dengan tepat. Pengujian dapat diarahkan tidak hanya pada bukti eksploitasi sebelumnya, tetapi juga pada kemungkinan bypass dan hubungan kelemahan dengan komponen lain sesuai ruang lingkup yang disepakati.

Selain layanan keamanan siber, Fourtrezz menyediakan layanan IT development dengan pendekatan yang mempertimbangkan keamanan sejak tahap perancangan. Pendekatan ini membantu perusahaan membangun atau mengembangkan sistem digital yang tidak hanya memenuhi kebutuhan operasional, tetapi juga memiliki fondasi keamanan yang lebih terukur.

Diskusikan kebutuhan penetration testing, vulnerability assessment, retest, atau pengembangan sistem perusahaan Anda bersama Fourtrezz.

Hubungi Fourtrezz

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