Author: hadi s

Di dunia DevOps dan kontainerisasi saat ini, alat seperti Docker Compose menjadi sangat populer: mereka memungkinkan pengembang dan tim operasional untuk men­deskripsikan aplikasi multi-kontainer dalam sebuah file YAML, lalu mem-ulai semuanya dengan satu perintah. Namun, sebuah kerentanan baru-baru ini menunjukkan bahwa alat yang dianggap “aman” untuk penggunaan sehari-hari bisa berubah menjadi pintu masuk serius bagi peretas. Kerentanan tersebut adalah CVE-2025-62725, yang memungkinkan eskalasi hingga kompromi sistem hanya dengan menjalankan perintah sederhana seperti docker compose ps atau docker compose config. Latar Belakang Docker Compose baru-baru ini memperluas dukungannya untuk artefak OCI (Open Container Initiative) — artinya file Compose bisa disimpan di registry sebagai artefak, lalu diload secara remote melalui direktif include: dalam YAML. Menurut analisis Imperva: “The flaw allowed attackers to escape Compose’s cache directory and write arbitrary files on the host system, simply by tricking a user into referencing a malicious remote artifact.” Singkatnya: saat Docker Compose mengunduh dan mengekstrak artefak remote, ia mempercayai meta-data internal artefak (annotations) yang menentukan lokasi penulisan file seperti com.docker.compose.file atau com.docker.compose.envfile. Proses tersebut tidak memvalidasi bahwa path yang dihasilkan tetap di dalam cache lokal—sehingga path traversal menjadi memungkinkan. Mekanisme Eksploitasi Berikut alur bagaimana kerentanan ini dieksploitasi: Penyerang menghosting sebuah artefak OCI di registry yang dikendalikan, dengan layer yang menyertakan annotations berbahaya (misalnya ../../.ssh/authorized_keys). Korban menjalankan perintah Compose apa saja yang memicu fetch artefak remote (termasuk perintah yang tampak “read-only” seperti docker compose ps atau docker compose config). Compose mengunduh layer, kemudian menulis file ke lokasi yang di-annotate oleh penyerang—karena tidak ada normalisasi path, file seperti ~/.ssh/authorized_keys dapat di-inject. Dengan file public key yang tersisip, penyerang bisa mendapatkan akses SSH ke host, lalu melakukan eskalasi atau pivoting ke sistem internal. Yang mengkhawatirkan: tidak perlu meng-up kontainer aktif. Hanya “compose ps” saja sudah cukup untuk memicu exploit. Dampak dan Skor Kerentanan Kerentanan ini diberi skor menurut sumber pihak ketiga, sebagai berikut: CVSS v4.0: 8.9 (High) Tipe kelemahan: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) Platform terpengaruh: hampir semua lingkungan yang menjalankan Docker Compose sebelum versi v2.40.2 — termasuk Docker Desktop, CI/CD runners, cloud dev environments. Mitigasi & Rekomendasi Imperva dan penyedia lainnya menyarankan langkah-langkah berikut: Segera upgrade ke Docker Compose versi v2.40.2 atau yang lebih baru. Lakukan audit terhadap file Compose yang menggunakan artefak remote atau include: directive dari registry eksternal. Terapkan kebijakan pembatasan: hanya pull artefak dari sumber tepercaya, batasi permissions cache directory, aktifkan monitoring file system untuk perubahan tak terduga. Segmentasikan host yang menjalankan Docker Compose agar tidak langsung expose ke jaringan luas, dan batasi akses SSH/key injection. Tingkatkan monitoring terhadap aktivitas mencurigakan seperti update file authorized_keys, proses yang menjalankan ssh di host yang tidak biasa, atau perubahan pada direktori kontainer/cache. Pelajaran bagi Industri Beberapa poin penting yang dapat dipetik dari kejadian ini: Alat DevOps yang populer dan dianggap “aman” tetap bisa mengandung risiko besar — keamanan tidak boleh dilupakan dalam pipeline pengembangan. Fungsi yang tampak “read-only” pun bisa jadi vektor serangan, seperti kasus ini: perintah “docker compose ps” saja cukup memicu exploit. Artefak remote harus ditangani sebagai potensi ancaman: memasukkan file eksternal ke sistem lokal selalu membawa risiko path traversal atau injeksi. Patch cepat adalah kunci: setelah kerentanan dipublikasikan, level eksploitasi sangat cepat meningkat — membuat mitigasi segera menjadi sangat penting. Kesimpulan Kerentanan CVE-2025-62725 di Docker Compose adalah contoh konkret bagaimana fitur baru (remote artefak OCI) dapat membuka celah serius jika tidak dilengkapi kontrol yang tepat. Meskipun alat tersebut sangat berguna bagi workflow DevOps, organisasi harus tetap waspada dan memastikan bahwa lingkungan pengembangan/kontainerisasi mereka mendapat perlindungan yang memadai. Bagi tim keamanan dan DevOps, hal ini juga menegaskan pentingnya integrasi DevSecOps: keamanan harus hadir sejak desain pipeline, bukan hanya setelah operasi berjalan. Dengan tutorial mitigasi, update versi, dan kontrol registry artefak yang tepercaya, organisasi dapat mengurangi risiko secara signifikan. Namun yang terpenting adalah kesadaran bahwa ancaman bisa datang dari tempat paling tak terduga — seperti perintah baris sederhana yang dianggap aman oleh banyak orang. Tabel Pendukung Aspek Detail Implikasi Operasional Versi Terpengaruh Docker Compose versi < v2.40.2 Organisasi harus segera upgrade sebelum menjadi target exploit CVSS Score 8.9 (High) Menunjukkan risiko sangat serius — prioritas mitigasi tinggi Tipe Kerentanan Path Traversal / Arbitrary File Write (CWE-22) Menandakan file system host bisa diretas melalui artefak kontainer Proses Eksploitasi Perintah “docker compose ps/config” → pengunduhan artefak remote → write file arbitrary Menunjukkan titik masuk yang tak seharusnya dianggap aman Area Terpengaruh Docker Desktop, Standalone Compose, CI/CD runners, cloud dev environments Lingkup sangat luas — baik laptop dev maupun sistem produksi bisa rentan Mitigasi Utama Upgrade ke v2.40.2+, audit registry artefak, batasi akses cache host file Prosedur yang harus segera diterapkan untuk mengamankan lingkungan Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut !

Di awal Oktober 2025, dunia keamanan siber kembali dihadapkan pada sebuah kerentanan kritis yang mengejutkan banyak pihak: CVE‑2025‑61882 — sebuah zero-day remote code execution (RCE) unggulan yang menargetkan modul Concurrent Processing / BI Publisher Integration dari Oracle E-Business Suite (EBS) versi 12.2.3 hingga 12.2.14.  Masalahnya bukan hanya teknis: kerentanan ini telah dieksploitasi di alam liar oleh aktor ancaman seperti Cl0p dan kelompok terkait dalam kampanye pemerasan dan pencurian data. Namun, bersama dengan berita mengkhawatirkan tersebut muncul kabar baik untuk pelanggan Imperva: Imperva menyatakan bahwa pelanggan mereka — baik yang menggunakan Cloud WAF ataupun On-Premises WAF — telah mendapatkan perlindungan “out-of-the-box” terhadap eksploitasi ini.  Artikel ini akan membahas detail kerentanan, bagaimana mekanisme eksploitasi bekerja, bagaimana Imperva menanggapi dan melindungi, serta implikasi bagi organisasi yang menggunakan Oracle EBS atau sistem legacy lainnya. Bagaimana Kerentanan CVE-2025-61882 Bekerja Menurut analisis yang diterbitkan oleh Imperva dan pihak lain, kerentanan ini bukan hanya satu bug sederhana — melainkan sebuah rantai eksploitasi multi-tahap.  Tahapan utamanya adalah sebagai berikut: Penyerang mengirimkan HTTP POST yang tak diautentikasi ke endpoint seperti /OA_HTML/configurator/UiServlet, dengan payload XML yang menyertakan return_url yang dikontrol penyerang. Parameter return_url dipakai untuk memicu SSRF (Server Side Request Forgery) di mana sistem Oracle EBS melakukan outbound HTTP request ke server yang dikendalikan penyerang. Penyerang kemudian menggunakan injeksi header CRLF, reuse koneksi HTTP, dan manipulasi layanan HTTP lokal yang kurang terbatas. Akhirnya, sebuah XSL stylesheet yang di-host oleh penyerang diproses oleh EBS, yang memanfaatkan mekanisme XSLT dan engine Java Script untuk menjalankan kode Java, misalnya Runtime.exec(…), sehingga menghasilkan eksekusi kode arbitrer di server. Setelah masuk, penyerang bisa menjalankan shell reverse, drop web-shell, exfiltrate data, atau berpindah lateral di lingkungan korporasi. Dengan CVSS v3.1 yang dicantumkan oleh Oracle sebagai 9.8 (Critical) untuk kerentanan ini, dan fakta bahwa eksploitasi aktif sudah berlangsung sejak Agustus 2025 oleh aktor seperti Cl0p, maka urgensi mitigasi menjadi sangat tinggi. Respon Imperva & Perlindungan Pelanggan Imperva menyatakan bahwa tim Threat Research Group mereka telah memantau dan mengidentifikasi rantai eksploitasi ini dan bahwa pelanggan Imperva yang menggunakan solusi WAF mereka telah “dilindungi” secara otomatis.  Beberapa poin penting dari tindakan yang dilakukan Imperva: Imperva menerapkan aturan WAF khusus yang menangkal pola serangan terkait CVE-2025-61882, termasuk payload SSRF, XSLT berbahaya, dan koneksi outbound abnormal. Untuk pelanggan Cloud WAF atau On-Prem WAF Imperva, proteksi ini sudah aktif tanpa perlu tuning manual tambahan — artinya out-of-the-box. Imperva juga mempublikasikan nilai pengamatan awal: lebih dari 557.000 upaya serangan terhadap kerentanan ini dalam satu hari, yang menyasar lebih dari 25 negara, dengan target utama di AS, Inggris, dan Prancis. Dengan demikian, organisasi yang memakai solusi Imperva bisa mendapatkan “lapisan pertahanan ekstra” sambil menunggu patch vendor (Oracle) diimplementasikan secara lengkap. Tindakan yang Harus Dilakukan Organisasi Meskipun memakai WAF yang baik adalah langkah penting, Imperva dan pihak lain seperti Rapid7 serta Oracle sendiri menekankan bahwa tidak ada pengganti dari patch resmi. Berikut adalah langkah-langkah yang sangat dianjurkan: Segera patch Oracle EBS versi 12.2.3-12.2.14 dengan update yang dirilis pada Security Alert Oracle. Lakukan threat hunting dengan indikator kompromi (IOC) yang sudah dipublikasikan oleh Oracle dan badan keamanan lainnya: IP seperti 200.107.207.26, 185.181.60.11; file seperti exp.py, server.py, oracle_ebs_nday_exploit *.zip. Reduksi paparan sistem EBS ke internet: pastikan tidak tersedia endpoint EBS yang terbuka publik jika bisa dihindari, segmentasi jaringan dan kontrol akses. Aktifkan monitoring runtime aplikasi untuk deteksi aktivitas abnormal seperti proses Java yang menjalankan shell, koneksi outbound tak biasa, XSLT yang ter-download secara anomali. Jika menggunakan WAF atau Web Application Protection (seperti Imperva), pastikan aturan dan signature terbaru diterapkan secara real-time. Implikasi & Pesan untuk Industri Kerentanan ini menggarisbawahi beberapa tren penting dalam keamanan aplikasi enterprise: Aplikasi ERP legacy tetap menjadi sasaran utama: Produk seperti Oracle EBS masih banyak digunakan di entitas besar dan menengah, dan kerentanan di dalamnya bisa memberikan akses ke data keuangan, HR, procurement — sehingga sangat bernilai bagi pelaku kejahatan. Serangan aplikasi lapisan atas (application-layer) bergerak cepat: Eksploitasi mulai dari tahap aplikasi, bukan hanya dari endpoint atau network — ini menuntut pengamanan yang berbasis konteks aplikasi dan runtime. Zero-day yang dieksploitasi sebelum patch dipublikasikan: Dalam kasus ini, eksploitasi sudah dilaporkan aktif sebelum patch tersedia secara luas. Tingginya kecepatan eksploitasi menuntut organisasi punya kesiapan yang tinggi. Peran WAF dan solusi proteksi aplikasi menjadi krusial: Meski bukan pengganti patch, solusi seperti Imperva menunjukkan bahwa proteksi tambahan bisa memberi “jaring pengaman” tambahan saat patch belum diterapkan sepenuhnya. Ringkasan & Kesimpulan Kerentanan CVE-2025-61882 di Oracle EBS adalah ancaman nyata dengan potensi dampak besar. Namun, dengan adanya proteksi yang sudah aktif melalui Imperva WAF, organisasi yang telah menggunakan platform tersebut memiliki keunggulan dalam mitigasi risiko — meskipun tetap wajib untuk segera melakukan patching dan hardening sistem mereka sendiri. Organisasi harus memandang proteksi sebagai kombinasi dari patch cepat, monitoring aktif, dan solusi proteksi yang tepat — bukan hanya bergantung kepada satu langkah saja. Kerentanan seperti ini juga menjadi pengingat bahwa aspek aplikasi — bukan hanya infrastruktur jaringan — adalah medan tempur utama saat ini. Tabel Pendukung Aspek Detail Implikasi Untuk Organisasi Versi Terpengaruh Oracle EBS versi 12.2.3 s.d. 12.2.14 Organisasi harus cek versi EBS yang mereka gunakan, dan segera patch jika termasuk rentan. Skor CVSS 9.8 (Critical) Menunjukkan kerentanan ini sangat tinggi risikonya — prioritas mitigasi maksimal. Eksploitasi Aktif Lebih dari 557.000 upaya serangan dalam satu hari, lebih dari 25 negara Paparan besar; jangan menunggu — risiko tinggi bahwa sistem publik akan diserang cepat. Mekanisme Eksploitasi SSRF → CRLF/header injection → XSLT dengan Java Runtime.exec → RCE Menekankan bahwa rantai ini kompleks dan sulit dideteksi — perlu proteksi context‐aware. Proteksi Imperva WAF Imperva mengaktifkan aturan proteksi otomatis untuk pelanggan Cloud WAF/On-Prem Organisasi yang sudah memakai Imperva punya keunggulan mitigasi cepat. Rekomendasi Tindakan Patch segera, monitoring runtime, segmentasi akses, threat-hunting IOC Organisasi harus memiliki strategi tindakan multi-lapis, tidak hanya satu solusi. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut !

Dalam lingkungan aplikasi modern yang semakin kompleks—mikroservis, API, cloud-native, dan DevOps—arsitektur sistem keamanan tidak lagi bisa diperlakukan seperti “lapisan firewall tunggal”. Baru-baru ini, dalam artikel berjudul “Imperva Elastic WAF – Why Separating Control and Data Planes Matters in Application Security”, Imperva menguraikan mengapa memisahkan antara control plane dan data plane adalah elemen krusial dalam melindungi aplikasi secara efektif. Artikel ini akan membahas secara mendalam: apa itu control plane dan data plane, mengapa pemisahan keduanya penting dalam konteks keamanan aplikasi, keuntungan yang bisa diperoleh, tantangan dalam implementasinya, serta langkah-praktis yang bisa diambil organisasi. Apa Itu Control Plane dan Data Plane? Istilah ini awalnya digunakan dalam jaringan dan infrastruktur cloud: Control Plane adalah bagian dari sistem yang menangani konfigurasi, kebijakan, manajemen, pengaturan, dan kontrol logika. Data Plane adalah bagian yang bertugas menjalankan trafik data, memproses, meneruskan, atau menegakkan aturan yang telah ditetapkan oleh control plane—dengan kecepatan tinggi dan latensi rendah. Dalam konteks aplikasi dan keamanan (misalnya WAF, WAAP, mikroservis), membagi dua fungsi ini memungkinkan sistem untuk tetap tangguh sekaligus agile—karena tiap bagian dapat dioptimalkan secara terpisah. Mengapa Pemisahan Ini Penting dalam Keamanan Aplikasi? Imperva menyoroti beberapa alasan utama mengapa arsitektur yang memisahkan control plane dan data plane menjadi sangat relevan dalam keamanan aplikasi saat ini: 1. Ketersediaan Selama Gangguan Control Plane Jika central control plane mengalami down-time atau gangguan—mungkin karena pembaruan, bug, atau serangan—data plane yang terpisah bisa tetap menjalankan inspeksi trafik berdasarkan konfigurasi terakhir. Artikel Imperva menyebutkan: “When the control plane … experiences downtime, traditional security models may halt enforcement or introduce blind spots.” Artinya: pemisahan menciptakan batas kegagalan (fault boundary) — suatu hal penting untuk aplikasi yang harus terus-menerus tersedia. 2. Optimisasi Performa Data plane diposisikan untuk menangani trafik volume besar dengan latensi sangat rendah, sementara control plane mengurus logika lebih kompleks. Dengan memisahkan keduanya, organisasi bisa memastikan inspeksi keamanan tidak memperlambat aplikasi. Imperva mencatat bahwa solusi mereka “adds less than 10 ms* of latency per request”. Ini menjadi penting untuk aplikasi modern yang menuntut performa tinggi. 3. Skalabilitas yang Independen Traffic aplikasi bisa naik drastis (data plane ter-load), sementara perubahan kebijakan mungkin lambat (control plane). Dengan arsitektur terpisah, data plane dapat diskalakan sesuai trafik tanpa harus menunggu perubahan kontrol. Imperva: “You don’t over-provision to maintain protection.” 4. Isolasi Kegagalan dan Ketahanan (Fault Isolation) Jika control plane mengalami masalah, data plane tetap bisa menjalankan tugasnya—sebuah fitur penting dalam menjaga keamanan operasional. 5. Pemerintahan & Ketangkasan (Governance & Agility) Banyak organisasi terdiri dari tim DevOps, tim keamanan, banyak layanan multi-lokasi. Dengan memisahkan kontrol kebijakan (control plane) dan pelaksanaan lokal (data plane), organisasi bisa menjaga standar keamanan sambil tetap memberi kebebasan inovasi. Impresifnya, Imperva menyebut: “Your security team sets the standards while DevOps teams deploy services at their own pace.” Bagaimana Implementasi Pemisahan Ini dalam Solusi Imperva Dalam artikel tersebut, Imperva menjelaskan bagaimana produk mereka (Elastic WAF) menerapkan pemisahan tersebut secara konkret: Control Plane berada di Imperva Security Console, tempat tim keamanan mendefinisikan kebijakan, memantau event, mengatur paket kontrol (Controller Package) yang kemudian didistribusikan ke data plane instans. Data Plane terdiri dari instans Elastic WAF yang ditempatkan di lingkungan aplikasinya (cloud, on-premises, Kubernetes) yang menerima kebijakan dan menjalankan inspeksi trafik. Dengan demikian organisasi mendapatkan: definisi kebijakan yang terpusat inspeksi trafik yang sangat dekat dengan aplikasi (edge) visibilitas log dan event yang kembali ke control plane skalabilitas, performa, dan fleksibilitas deployment Tantangan & Hal-Yang Perlu Diperhatikan Meskipun banyak keuntungan, ada beberapa tantangan dalam adopsi arsitektur ini: Integrasi dengan Infrastruktur Eksisting: Banyak organisasi masih punya solusi keamanan monolitik atau titik-titik kontrol yang terpusat tanpa pemisahan—migrasi mungkin butuh investasi. Pengelolaan Kebijakan: Memisahkan control plane berarti tim keamanan harus lebih disiplin dalam manajemen kebijakan, distribusi, dan audit agar data plane tidak menjalankan kebijakan usang. Orkestrasi dan Monitoring: Data plane tersebar (cloud, edge, container), memerlukan monitoring terpusat agar bisa terdeteksi bila ada anomaly. Skema Keamanan Baru: Isolasi fault dan skalabilitas bagus sekali, tapi juga memunculkan kebutuhan untuk memverifikasi bahwa data plane benar-benar menjalankan kebijakan (“compliance at runtime”). Budaya Organisasi & Proses: Perubahan arsitektur memerlukan perubahan kultur DevOps-SecOps dan proses internal agar tim keamanan dan tim pengembangan tetap sinkron. Tabel Pendukung – Ringkasan Elemen & Implikasi Elemen Arsitektur Penjelasan Implikasi Praktis bagi Organisasi Control Plane Tempat kebijakan, konfigurasi dan manajemen pusat Kebijakan terpusat → konsistensi keamanan antar-tim Data Plane Inspeksi trafik secara langsung, berkecepatan tinggi Latensi rendah, scalable, deployment dekat aplikasi Ketersediaan saat Control Plane Gangguan Data plane tetap aktif meskipun manajemen pusat bermasalah Minimalkan waktu ‘blind-spot’ keamanan Skalabilitas Independen Data plane naik sesuai trafik, control plane naik sesuai kebijakan/pengguna Efisiensi biaya dan kapasitas Governance & Ketangkasan Kebijakan tetap terpusat, implementasi lokal fleksibel Mendorong DevOps & inovasi tanpa mengorbankan keamanan Tantangan Integrasi & Proses Migrasi, monitoring, kebijakan, kultur diperlukan Butuh perencanaan dan investasi sebelum implementasi Kesimpulan Pemisahan antara control plane dan data plane bukan hanya konsep teknis abstrak—ini adalah arsitektur yang memungkinkan keamanan aplikasi modern berjalan dengan performa, skalabilitas, dan ketahanan tinggi. Dengan semakin banyak aplikasi yang berjalan di cloud, container, edge, dan mikroservis, solusi keamanan yang masih mengandalkan checkpoint tunggal atau model pusat-terbatas akan mengalami kendala: bottleneck performa, risk-zone saat kontrol pusat down, atau kurang fleksibel untuk tim DevOps yang bergerak cepat. Solusi seperti Elastic WAF dari Imperva menunjukkan bahwa model pemisahan ini sudah siap diterapkan—dan manfaatnya nyata: keamanan yang tidak menghambat kecepatan inovasi, kontrol yang tetap terpusat, dan proteksi yang tetap aktif bahkan ketika subsistem manajemen bermasalah. Jika organisasi Anda sedang mempertimbangkan cara memperkuat keamanan aplikasi tanpa menghambat pengembangan dan operasional, maka mempertimbangkan arsitektur control/data plane ini adalah langkah yang layak dan strategis. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut!

Ketika berbicara tentang aplikasi enterprise yang banyak digunakan di seluruh dunia, sedikit yang sebesar Oracle E‑Business Suite (EBS). Namun, baru-baru ini terungkap bahwa sebuah kerentanan zero-day sangat serius, yaitu CVE-2025-61882, menarget sistem EBS versi 12.2.3 hingga 12.2.14, dan memungkinkan eksekusi kode jarak jauh tanpa autentikasi. Dalam artikel ini, kita akan membahas secara mendalam: apa kerentanannya, bagaimana pelaku memanfaatkannya, implikasi bagi organisasi, serta langkah-keamanan yang dapat dilakukan untuk memitigasi risiko. Latar Belakang Pada awal Oktober 2025, tim riset ancaman dari Imperva mencatat bahwa CVE-2025-61882 telah digunakan dalam serangan massal di dunia nyata. (Imperva) Kerentanan ini berada di modul Concurrent Processing / BI Publisher Integration dari Oracle EBS. Vendor telah mengeluarkan Security Alert mendesak untuk patch segera. (Oracle) Skor CVSS 3.1 dari kerentanan ini tercatat 9.8 — menandakan tingkat kritikal. Bagaimana Kerentanannya Bekerja Analisis Imperva menyebut bahwa exploit ini bukan satu bug tunggal, melainkan rantai multi-tahap: Penyerang mengirim HTTP POST tanpa autentikasi ke endpoint seperti /OA_HTML/configurator/UiServlet dengan payload XML yang mengandung parameter return_url yang diarahkan ke server kontrol penyerang. Terjadi SSRF atau mis-routing: EBS akan melakukan panggilan keluar ke server penyerang untuk mengambil XSLT yang berisi kode Java tersembunyi. Then CRLF/HTTP header injection dan reuse connection dipakai untuk mem-pivot ke layanan lokal yang kurang aman. Dari situ, XSLT dijalankan dan akhirnya Java Script Engine (atau eval-like flow) dieksekusi untuk menjalankan perintah sistem secara bebas. Dengan demikian, penyerang bisa memperoleh shell atau akses sistem penuh, drop web-shell, eskalasi hak, eksfiltrasi data, atau persiapan ransomware. Kenapa Ini Sangat Berbahaya Beberapa faktor memperparah dampak dari kerentanan ini: Tanpa autentikasi: Penyerang tidak perlu memiliki kredensial valid. Hanya akses HTTP yang diperlukan. Blast-radius besar: Versi 12.2.3 hingga 12.2.14 terdampak — banyak instalasi EBS perusahaan besar. Eksploitasi aktif di dunia nyata: Laporan dari Google GTIG/Mandiant dan lainnya menunjukkan kampanye terhadap EBS sejak Agustus/September 2025, terutama oleh kelompok seperti Cl0p. Kontrol tradisional mungkin gagal: Karena akses melalui aplikasi dan eksekusi kode dalam Java/servlet, sistem EDR endpoint mungkin tidak mendeteksi tahap awalnya. Implikasi bagi Organisasi Organisasi yang menggunakan Oracle EBS — terutama dengan versi yang terdampak — harus menganggap ini sebagai insiden kelas atas. Pertimbangkan implikasi berikut: Sistem keuangan, HR, supply-chain yang berjalan di EBS bisa ditarget secara langsung. Jika eksfiltrasi data terjadi sebelum patch, organisasi dapat menghadapi kebocoran data besar, tuntutan hukum atau reputasi rusak. Karena exploit ini memungkinkan kode eksekusi penuh, bisa dijadikan pintu masuk ransomware atau alat lateral movement ke sistem kritikal lainnya. Pemilik instansi EBS mungkin harus menerapkan forensics, threat-hunting, karena patch mungkin terlambat dibanding aktivitas eksploitasi. Tabel Pendukung – Ringkasan Kerentanan & Rekomendasi Aspek Rincian Tindakan Utama Produk terdampak Oracle EBS versi 12.2.3 hingga 12.2.14, modul Concurrent Processing / BI Publisher Integration Verifikasi versi, identifikasi instalasi EBS terdampak Skor kerentanan CVSS 3.1 = 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) Klasifikasikan sebagai prioritas patch tertinggi Teknik exploit SSRF → CRLF/HTTP injection → XSLT payload → Java runtime exec Monitor aktivitas jaringan & HTTP-outbound suspicious Eksploitasi aktif Kampanye sejak Agustus 2025, target banyak negara, kelompok Cl0p dan lainnya Threat-hunting, review log, verifikasi IOC Mitigasi utama Patch segera, segmentasi jaringan, monitoring runtime, hunt server legacy Terapkan patch, batasi akses internet ke EBS, audit layanannya Rekomendasi Praktis Untuk memasang pengamanan sebaik mungkin terhadap kerentanan ini, berikut langkah-praktis yang dapat diambil: Patch Darurat – Terapkan update Oracle yang dirilis segera setelah advisori CVE-2025-61882 dikeluarkan. Identifikasi instalasi EBS – Buat daftar semua instansi EBS yang tersedia, versinya, dan apakah terdampak ataupun tidak. Segmentasi & Kontrol Akses – Pastikan EBS yang terdampak tidak langsung menghadapi Internet tanpa perlindungan perimeter atau layer tambahan. Monitoring Runtime & Forensik – Pantau aktivitas aplikasi: proses Java tak wajar, HTTP POST/GET ke endpoint suspect seperti /OA_HTML/configurator/UiServlet, atau XSLT yang dieksekusi. Threat Hunting – Cari IOC seperti file exploit (exp.py, server.py), IP luar yang melakukan request massal, pola reverse-shell dari Java process. Latihan Respons Insiden – Siapkan prosedur ketika EBS ditemukan sudah dikompromi: isolasi, backup, rollback, investigasi, serta mitigasi lanjutan. Review Governance & Risiko – Karena EBS banyak menangani data kritikal (finance, HR, supply chain), pertimbangkan audit keamanan dan compliance tambahan. Kesimpulan Kerentanan CVE-2025-61882 di Oracle EBS tidak hanya representasi dari bug teknis—ini adalah pengingat bahwa aplikasi enterprise, yang sering di-deploy dalam mode produksi dan jarang di-update secara cepat, dapat menjadi target primer aktor ancaman tingkat tinggi. Organisasi yang beroperasi dengan EBS harus segera memprioritaskan tindakan—patching, monitoring, dan evaluasi risiko. Dengan protokol keamanan yang tepat dan respons cepat, dampak dari kerentanan ini dapat diminimalkan. Namun, kelambanan dalam penanganan bisa menyebabkan konsekuensi yang sangat besar — baik dari perspektif keamanan, operasional, maupun reputasi. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut!

Dalam dunia DevOps dan container orchestration, Docker Compose telah lama menjadi alat vital yang memudahkan para pengembang membangun, menjalankan, dan mengelola aplikasi multi-container hanya dengan beberapa baris YAML. Namun, penelitian keamanan terbaru dari Imperva mengungkap bahwa kemudahan itu juga menyimpan risiko besar: kerentanan path-traversal bernomor CVE‑2025‑62725 yang memungkinkan attacker melakukan penulisan berkas arbitrer ke sistem host—bahkan hanya dengan menjalankan perintah yang terlihat “aman” seperti docker compose ps. Artikel ini akan membahas detail temuan, bagaimana eksploitasi bisa berjalan, apa dampaknya bagi organisasi, serta langkah-strategi mitigasi yang harus segera diambil. Latar Belakang: Fitur Baru dan Permukaan Serangan Docker Compose baru-baru ini menambahkan dukungan untuk artefak OCI (“OCI-based Compose artifacts”) yang memungkinkan pengguna menyertakan proyek Compose yang telah diterbitkan di registry OCI melalui direktif include: dalam YAML mereka. Prosesnya: Compose akan mengambil manifest OCI dari registry, mengunduh layer-layer, lalu menyusun kembali struktur di cache lokal melalui fungsi seperti pullComposeFiles, writeComposeFile, dan writeEnvFile. Namun ternyata, kode tersebut mempercayai annotation seperti com.docker.compose.file dan com.docker.compose.envfile yang ditetapkan oleh layer OCI—tanpa normalisasi atau pemeriksaan path. Hasilnya: attacker bisa menyetel path traversal (../../…) pada annotation untuk membuat Compose menulis file ke luar direktori cache. Yang membuat kasus ini sangat berbahaya adalah bahwa exploit bisa dipicu hanya dengan menjalankan perintah read-only seperti docker compose config atau docker compose ps. Artinya meskipun pengguna tidak memulai container, sistem tetap bisa diserang. Bagaimana Eksploitasi Terjadi Penyerang membuat registry OCI yang menampung artefak Compose dengan layer yang mengandung annotation pengarah path traversal. Korban menjalankan docker compose ps atau docker compose config di direktori yang memuat docker-compose.yaml yang berisi include: yang merujuk ke registry attacker. Compose mengunduh artefak, kemudian karena path dari annotation tidak tervalidasi, berkas seperti ~/.ssh/authorized_keys bisa ditulisi dengan kunci publik attacker—memberikan akses SSH langsung ke host. Dengan akses ini, attacker bisa eskalasi hak, menanam malware, mengakses data, atau mengambil kontrol penuh atas sistem. Mengapa Risiko Ini Besar Versi sebelum v2.40.2 rentan. Lingkup luas: alat ini digunakan di lokal, CI/CD, cloud dev, Docker Desktop—artinya banyak target potensial. Eksekusi minimal: hanya perlu menjalankan suatu perintah yang dianggap aman oleh pengguna, menjadikan aturan “hindari menjalankan container dari sumber tak terpercaya” saja tidak cukup. Penulisannya bisa ke lokasi kaki root atau sistem bila Compose berjalan dengan hak istimewa—berpotensi kompromi penuh sistem. Implikasi bagi Organisasi Keamanan DevOps terancam: Pipeline CI/CD yang secara rutin menggunakan Docker Compose bisa jadi vektor masuk tanpa disadari. Perubahan paradigma proteksi: Bukan hanya container-runtime, tapi alat developer “ringan” juga harus diperhatikan. Kebutuhan patch & audit mendesak: Organisasi yang belum memperbarui Compose berisiko besar; audit penggunaan include remote artefak juga dibutuhkan. Ketenangan palsu “perintah aman” berbahaya: Pengguna yang menjalankan perintah “non-destructive” masih bisa menyebabkan kompromi. Langkah Mitigasi dan Praktik Terbaik Upgrade Compose ke versi v2.40.2 atau lebih baru sesegera mungkin. Batasi penggunaan hanya artefak dari repository yang sah serta hindari penggunaan include: dari sumber tak diverifikasi. Jalankan Compose di lingkungan dengan hak minimal—hindari hak root bila memungkinkan. Audit YAML project Anda: cari include: remote, anotasi OCI, dan hapus atau ganti dari sumber yang terpercaya. Monitor aktivitas sistem host: perubahan file sensitif (misalnya authorized_keys), operasi penulisan di path luar cache. Terapkan prinsip least privilege, segmentasi jaringan dan isolasi lingkungan build/dev dari sistem produksi. Lakukan pelatihan untuk dev/ops agar sadar fitur baru Compose berpotensi risiko jika tak ditangani dengan baik. Tabel Pendukung – Ringkasan Kerentanan & Tindakan Aspek Kerentanan Detil Tindakan Mitigasi Komponen Terdampak Docker Compose versi < v2.40.2 Upgrade ke v2.40.2+ Jenis Kerentanan Path traversal via OCI artefact annotations (CWE-22) Validasi path, hindari artefak dari sumber tak dipercaya Dampak Utama Write arbitrary file, potensi system compromise Audit sistem, monitoring file sensitif, isolasi lingkungan Vektor Serangan Remote artefak + perintah “ps”/“config” Verifikasi source artefak, kontrol akses include: Skala Risiko Lokal dev, CI/CD, cloud dev, Docker Desktop Kebijakan keamanan DevOps, patch rutin Kesimpulan Kejadian CVE-2025-62725 memberikan pelajaran penting: bahkan alat yang dianggap “ringan” atau hanya untuk pengembang, seperti Docker Compose, bisa menjadi titik masuk kritis ke sistem produksi apabila fitur baru disertakan tanpa pengamanan. Karena fitur include: artefak remote membuka permukaan serangan dan path traversal memungkinkan kompromi penuh—organisasi harus mengambil langkah cepat. Jika Anda menggunakan Docker Compose, segera tinjau versi Anda, disable penggunaan artefak remote tak diverifikasi, audit pipeline CI/CD Anda, dan pastikan monitoring serta pembatasan hak istimewa diterapkan. Kecepatan Anda dalam merespon bisa menjadi pembeda antara keamanan yang terjaga atau sistem yang terkompromi. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut!

Dalam dunia keamanan siber yang terus berkembang, seringkali ancaman paling efektif bukanlah yang paling rumit secara teknis—melainkan yang paling opportunistik. Salah satu kampanye terbaru yang menggarisbawahi hal ini adalah kampanye yang dianalisis oleh tim Riset Ancaman dari Imperva, berjudul “Imperva Detects and Mitigates Rejetto HFS Spray-and-Pray Ransomware/Trojan Campaign”. Artikel ini akan membahas secara mendalam bagaimana kampanye tersebut bekerja, mengapa sangat berbahaya, implikasi terhadap organisasi, dan langkah-strategis mitigasi yang bisa diambil. Latar Belakang: Sistem Tua yang Masih Digunakan Meski sudah ada teknologi yang jauh lebih modern, banyak organisasi masih menggunakan server file lama atau open-source file server seperti Rejetto HFS (HTTP File Server) versi 2.x yang tidak lagi mendapatkan update keamanan. Imperva mencatat bahwa pada 19 Juli 2025, tim mereka mendeteksi lonjakan pemeriksaan HTTP (HTTP probes) yang menargetkan instans HFS 2.x yang terekspos ke internet. Server-server tersebut ternyata menjadi sasaran kampanye “spray-and-pray”—istilah yang merujuk pada strategi di mana penyerang melakukan pemindaian massal dan eksploitasi terhadap banyak target secara serentak, berharap sejumlah besar akan rentan. Dalam hal ini, server HFS 2.x yang terekspos ke publik dan belum dipatch menjadi sasaran empuk. Modus Operandi Kampanye Berikut beberapa aspek teknis dari kampanye tersebut: Kerentanan utama yang dieksploitasi adalah CVE-2024-23692, sebuah server-side template injection (SSTI) di HFS 2.x dengan CVSS 9.8 yang memungkinkan eksekusi kode jarak jauh tanpa autentikasi. Penyerang memulai dengan pemindaian massal (“spray”) terhadap instans HFS yang terekspos; begitu target ditemukan, injeksi dilakukan yang kemudian mengeksekusi payload malware, termasuk trojan unduh-lanjur dan ransomware. Payload yang dilaporkan meliputi trojan seperti Farfli, Zenpak, dan ransomware jqvtd yang diturunkan melalui server yang dieksploitasi. Infrastruktur C2 (Command & Control) dan host peluncuran tersebar di banyak blok kelas C, menunjukkan bahwa kampanye ini berskala global dan otomatis. Kenapa Kampanye Ini Berbahaya? Ada beberapa faktor yang menyebabkan kampanye ini sangat signifikan bagi organisasi: Rentan karena sistem tua: Banyak instans HFS 2.x yang “dimaintain” secara minim atau sudah tidak up-to-date, tapi masih online dan dapat diakses publik. Strategi massal: Teknik “spray-and-pray” memungkinkan penyerang memiliki banyak target dengan upaya minimal per target. Eksploitasi layanan yang sah: Server file sharing umum seperti HFS kadang dipakai untuk sharing internal/non-prod—tapi bila terekspos, bisa menjadi pintu masuk besar. Deteksi sulit: Karena proses awal adalah injeksi kode dan eksekusi tanpa interaksi pengguna, banyak kontrol standar endpoint atau gateway mungkin tidak mendeteksi. Dampak produksi: Ransomware atau trojan yang diunduh bisa mengenkripsi data, mencuri, atau mengganggu operasi secara langsung. Implikasi bagi Organisasi Organisasi yang mengabaikan server lama atau layanan file sharing publik bisa menghadapi beberapa risiko besar: Kebocoran data jika trojan mencuri informasi dari server yang terekspose. Penyebaran ransomware dari instans yang dieksploitasi, yang kemudian menjangkau ke sistem lain. Reputasi dan regulasi: bila data pelanggan atau mitra bocor akibat server rentan, organisasi bisa terkena denda atau litigasi. Biaya pemulihan besar: penghapusan malware / ransomware, forensik, penggantian sistem, audit keamanan. Langkah Mitigasi & Praktik Terbaik Berdasarkan panduan dari Imperva dan riset lainnya, berikut langkah yang harus dipertimbangkan organisasi: Inventarisasi semua instans file sharing publik dan server lama yang masih terhubung ke Internet. Segera patch atau decommission HFS 2.x: naik ke HFS 3.x atau layanan yang disupport. Imperva mengingatkan bahwa HFS 2.x adalah end-of life. Terapkan segmentasi jaringan: jangan letakkan instans file sharing langsung publik tanpa firewall atau akses terbatas. Monitor trafik HTTP/HTTPS untuk pola seperti search=.*%url%.*}{\.exec| yang disebut sebagai indikator injeksi SSTI di HFS. Batasi akses outbound ke IP atau domain yang tidak dikenal—karena host exploit mungkin mencoba download payload atau menghubungi C2. Aktifkan logging dan deteksi anomali di host, seperti eksekusi proses tidak wajar, download file eksekusi, koneksi ke IP asing. Lakukan latihan incident-response untuk skenario server tereksploitasi: pengecekan backup, pemulihan, isolasi cepat. Tabel Pendukung – Rangkuman Temuan & Rekomendasi Aspek Temuan Utama Rekomendasi Utama Kerentanan CVE-2024-23692 SSTI di HFS 2.x memungkinkan RCE tanpa autentikasi. Segera patch atau hapus instans HFS 2.x Strategi Penyerang Pemindaian massal (“spray-and-pray”) banyak instans rentan. Audit instans publik dan segmentasi jaringan Payload & Dampak Trojan (Farfli, Zenpak) dan ransomware (jqvtd) dikerahkan setelah exploit. Monitoring aktivitas download/eksekusi dan backup reguler Skala Kampanye Infrastruktur global host C2 & banyak blok kelas C digunakan. Batasi outbound, blok domain/IP asing, logging jaringan Deteksi & Monitoring Pola HTTP injeksi template ada di trafik – perlu pemantauan khusus. Gunakan IDS/IPS untuk HTTP anomaly, log HTTP evaluate Kesimpulan Kampanye ransomware/trojan menargetkan layanan file sharing usang seperti Rejetto HFS 2.x dengan metode “spray-and-pray” menegaskan bahwa kelemahan lama (legacy systems) masih merupakan pintu masuk utama bagi pelaku siber. Riset dari Imperva menunjukkan bahwa server yang sangat rentan dan sering diabaikan bisa menjadi basis operasi untuk serangan skala besar. Organisasi yang ingin melindungi diri harus mengambil langkah proaktif: inventory dan patch sistem, segmentasi jaringan, monitoring trafik dan perilaku, serta latihan respons insiden. Tidak cukup hanya menaruh firewall atau antivirus—kebutuhan sekarang adalah kontrol akses, visibilitas dan respons cepat terhadap pola yang mungkin kecil namun memiliki potensi besar untuk eskalasi. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut!

Pendahuluan Di era di mana kecerdasan buatan (AI) dan agen-otomasi menjadi bagian dari alur kerja pengembangan perangkat lunak, alat untuk menghubungkan agen-AI dengan data dan layanan eksternal – seperti server berbasis protokol Model Context Protocol (MCP) – semakin banyak digunakan. Namun demikian, dengan adopsi yang cepat datang pula risiko yang serius. Imperva Threat Research baru-baru ini mengungkap kerentanan kritis berupa eksekusi kode jarak jauh (RCE) dalam sebuah server MCP terbuka yang sangat populer. Artikel ini akan menguraikan temuan tersebut—mulai dari bagaimana kerentanannya muncul, bagaimana cara kerjanya, dampaknya terhadap organisasi dan pengembang, serta langkah-langkah mitigasi yang bisa diambil. Apa yang Terjadi: Kerentanan di MCP Server Populer Kerentanan tersebut berlabel CVE‑2025‑53967 dan mempengaruhi salah satu implementasi server MCP yang sangat banyak diunduh (lebih dari 100.000 unduhan per bulan) bernama Framelink Figma MCP Server versi sebelum v0.6.3. Inti masalahnya adalah pada mekanisme “fallback” ketika permintaan HTTP ke API gagal: server mencoba menggunakan perintah curl melalui child_process.exec dengan parameter URL atau header yang diambil secara langsung dari klien tanpa sanitasi cukup. Hal ini membuka jalur injeksi perintah shell yang kemudian memungkinkan pelaku untuk melakukan eksekusi kode secara remote dengan hak istimewa dari proses MCP. Lebih konkret: alur eksploitasi berjalan dengan langkah seperti berikut: Klien menginisialisasi sesi ke server MCP, memperoleh sebuah session-id. Kemudian, klien atau agen AI mengirim permintaan JSON-RPC untuk memanggil tool seperti get_figma_data atau download_figma_images. Jika permintaan fetch gagal, kode fetchWithRetry memanggil curl dengan interpolasi parameter yang dapat diubah oleh pelaku. Dari sana, injeksi shell terjadi dan dapat menjalankan perintah arbitrer. Lokasi bind default 0.0.0.0 membuat server dapat diakses dari seluruh antarmuka jaringan, bukan hanya localhost, memperluas attack surface. Kenapa Ini Serius RCE (Remote Code Execution) adalah salah satu tipe kerentanan paling berbahaya — pelaku bisa menjalankan perintah sistem, mencuri data, meng-install malware atau ransomware. Server MCP sering digunakan di lingkungan pengembangan atau integrasi AI yang memiliki akses ke kode sumber, API-key atau data sensitif — artinya kerugian potensial sangat besar. Implementasi lokal atau workstation dari tool ini sering dianggap “aman” karena berada di lingkungan dev, sehingga sering pengamanan jaringan standar kurang diterapkan — hal ini memperbesar peluang eksploitasi. Dampak tak hanya pencurian data, tetapi juga potensi “pivoting” atau bergerak ke sistem internal, karena akses berada pada jaringan perusahaan atau workstation yang terhubung. Tabel Pendukung: Ringkasan Kerentanan & Dampak Aspek Penjelasan Singkat Dampak Potensial Produk yang terdampak Framelink Figma MCP Server versi < 0.6.3 Banyak instansi/developer menggunakan produk ini Jenis kerentanan Command injection dalam fallback curl via child_process.exec Eksekusi kode jarak jauh (RCE) Vektor eksploitasi HTTP POST dengan URL/header yang dikontrol pelaku Pelaku dapat mengirim payload injeksi shell Lingkup akses Server bind ke 0.0.0.0 atau :: — semua antarmuka jaringan Akses bukan hanya lokal tapi juga jaringan luas Versi perbaikan Patch tersedia pada versi 0.6.3 Pengguna harus segera update Area mitigasi tambahan Pembatasan jaringan, containerisasi, validasi input, audit & monitoring Mengurangi kemungkinan eksploitasi dan meminimalkan damage Langkah-Mitigasi & Rekomendasi Segera update ke versi ≥ 0.6.3 pada semua instance Framelink Figma MCP Server. Validasi dan sanitasi input: hindari interpolasi parameter user langsung ke perintah shell, gunakan execFile atau API tanpa shell. Batasi akses jaringan: bind server pada localhost atau antarmuka terbatas, jangan expose ke internet publik. Jalankan dalam container atau sandbox dengan hak minimal agar jika kompromi terjadi, blast radius terbatas. Monitoring, logging & deteksi anomali: pantau aktivitas POST yang tak biasa, statements shell dalam log, dan alerting terkait. Review alat-AI / pipeline dev: Karena server MCP sering menjadi bagian workflow AI, tim devops harus menyadari risiko ini dan mengevaluasi keamanan toolchain AI-agent mereka. Kesimpulan Temuan Imperva ini menjadi pengingat keras bahwa di dunia AI dan integrasi alat modern, “alat yang dianggap bantu” bisa menjadi “vektor serangan” jika keamanan tidak dipertimbangkan sejak awal. Server MCP — meskipun sering dianggap lokal atau dev-only — dapat membawa risiko yang besar ketika mengandung bug RCE dan diekspos ke jaringan yang lebih luas. Bagi organisasi dan tim pengembang: gunakan momen ini untuk mengevaluasi seluruh pipeline AI, server-lokal, dan toolchain dev Anda — bukan hanya dari sisi fungsionalitas, tetapi juga dari sisi keamanan. Ketika alat dev Anda sendiri menjadi pintu masuk, maka Anda tidak hanya mempertaruhkan satu workstation, tetapi potensi seluruh jaringan dan data kritis Anda. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut!

Pendahuluan Industri pariwisata kini telah berubah secara drastis oleh digitalisasi—pengguna melakukan pemesanan tiket, mengatur akomodasi, menggunakan aplikasi mobile hingga berbagi lokasi secara real-time. Namun transformasi ini membawa konsekuensi serius: area digital yang semakin besar juga berarti permukaan serangan (attack surface) yang lebih luas. Artikel “Securing the Journey: Cybersecurity Challenges in the Tourism Industry” dari Imperva menggarisbawahi bahwa sektor pariwisata menjadi target utama pelaku kejahatan siber karena data yang mereka kelola—dari detail identitas pribadi hingga data pembayaran—dan karena proses bisnis yang sangat bergantung pada sistem digital. Dalam tulisan ini, kita akan menguraikan tantangan utama keamanan siber dalam industri pariwisata, dampaknya terhadap bisnis dan traveller, serta strategi mitigasi yang perlu diadopsi oleh pelaku industri. 1. Tantangan Utama di Industri Pariwisata Data Breach (Pencurian Data) Sektor pariwisata mengumpulkan dan menyimpan data yang sangat sensitif: nomor paspor, data kartu kredit, rute perjalanan, prefensi pelanggan. Ketika data tersebut bocor, dampaknya bisa sangat besar. Imperva mencontohkan beberapa insiden besar: misalnya pencurian 6 juta catatan pelanggan dalam satu pelanggaran di maskapai besar. Data leakage atau kebocoran data kini menyumbang sekitar 10 % dari semua serangan di situs perjalanan. Semua tipe pelaku industri—agen perjalanan, maskapai, hotel, rental mobil—berpotensi menjadi korban. Sistem manapun yang menyimpan atau memproses data pelanggan berisiko. Serangan Ransomware dan Disrupsi Operasional Lebih dari sekadar pencurian data, industri pariwisata kini menghadapi ancaman besar yakni ransomware dan serangan yang menargetkan operasional. Contoh: serangan terhadap sistem avionic dan rantai suplai di industri penerbangan yang menyebabkan bandara lumpuh. Menurut artikel tersebut, sektor penerbangan misalnya mengalami peningkatan serangan hingga 600 % YoY dalam beberapa kasus. Ketika sistem check-in, tampilan informasi bandara, atau portal pemesanan tidak dapat diakses, kerugian tidak hanya finansial — tetapi juga reputasi, kepercayaan pelanggan, dan beban hukum. Business Logic Attacks & Bot Otomatisasi Sektor perjalanan sangat rentan terhadap serangan yang mengeksploitasi logika bisnis aplikasi — misalnya otomasi pemesanan tanpa pembayaran (“seat spinning”), penyalahgunaan sistem loyalitas, scraping harga, atau login otomatis massal. Imperva mencatat bahwa business logic attacks menyumbang hampir 70 % dari semua serangan yang dilihat di situs perjalanan dan lebih dari 50 % di maskapai. Misalnya, 44 % dari seluruh traffic ke situs perjalanan berasal dari bot jahat, yang melakukan scraping, takeover akun, dan manipulasi platform loyalitas. Ancaman AI dan Teknologi Baru Dengan integrasi AI dalam aplikasi perjalanan—untuk rekomendasi, chatbot, routing penerbangan—muncul pula risiko baru seperti prompt-injection, data poisoning, atau manipula­si AI yang menghasilkan output palsu (misalnya tiket palsu) atau phishing lebih meyakinkan. Imperva menunjukkan bahwa rata-rata lebih dari 420 000 serangan tiap hari pada 2025 ditujukan ke situs perjalanan dan bersumber dari alat berbasis AI atau crawler otomatis. Artinya, pelaku industri harus siap dengan tipe ancaman yang tidak hanya tradisional, namun juga bersifat otomatis dan berbasis kecerdasan buatan. 2. Dampak terhadap Bisnis Pariwisata Kerugian yang ditimbulkan meliputi: Kehilangan pendapatan akibat downtime atau pemesanan yang dibatalkan atau dipermasalahkan saat sistem terganggu. Biaya remediansi dan denda regulasi (misalnya pelanggaran GDPR) yang bisa mencapai jutaan dolar. Kerusakan reputasi yang mengurangi kepercayaan pelanggan dan akhirnya mengurangi pemesanan di masa depan. Gangguan pengalaman pelanggan, yang dalam industri perjalanan berarti gangguan besar terhadap layanan inti. 3. Tabel Pendukung: Tantangan vs Strategi Mitigasi Tantangan Utama Contoh konkret Strategi Mitigasi yang Disarankan Kebocoran data (data breach) Data kartu kredit dan paspor pekerja diretas Enkripsi data, segmentasi basis data, audit rutin Ransomware / Gangguan operasional Bandara tak bisa check-in, portal tiket down Backup offline, isolasi sistem kritis, simulasi incident Business logic & bot otomatisasi Bot mengambil kursi penerbangan tanpa bayar Bot-management, autentikasi kuat, deteksi anomali trafik Ancaman AI / teknologi canggih AI chatbot tertipu menyampaikan informasi palsu Validasi AI, implementasi kontrol prompt/injeksi, monitoring Rantai pasokan & third-party risk Vendor hotel membawa vektor serangan ke OTA Manajemen vendor, penilaian risiko supply chain, SLA keamanan Kurangnya standar keamanan industri Perusahaan kecil tidak memiliki proteksi memadai Edukasi, standar minimal (ISO 27001/PCI DSS), kolaborasi 4. Rekomendasi & Strategi Praktis Untuk pelaku industri — baik maskapai, hotel, agen perjalanan dan platform online — beberapa strategi kunci yang harus diimplementasikan adalah sebagai berikut: Pendekatan pertahanan berlapis (defence-in-depth): bukan hanya firewall dan antivirus, tetapi sistem deteksi anomali, kontrol akses, segmentasi jaringan, proteksi bot, dan alat analitik perilaku. Manajemen identitas & akses (IAM): Implementasi autentikasi multi-faktor (MFA), autentikasi perangkat, reputasi perangkat, dan log aktivitas pengguna — khususnya untuk sistem pemesanan/loyalitas. Proteksi terhadap bot dan logic abuse: Bot management yang solid — memblokir scraping, automate seat hoarding, akun palsu. Karena jenis serangan ini sangat sering terjadi. Kesiapan insiden & kontinuitas bisnis: Rencana respons insiden (incident response plan) yang diuji secara berkala, backup yang disimpan offline, dan pelatihan krisis untuk memastikan minimal downtime. Pengaruh rantai pasokan & third-party: Karena sistem sering saling terhubung (OTAs, hotel, rental kendaraan), keamanan vendor harus dipastikan—termasuk audit, pengawasan, dan pesyaratan keamanan dalam kontrak. Penerapan teknologi cerdas dengan aman: Ketika AI dan integrasi IoT meningkat, perlu ada kontrol tambahan terhadap model AI, pengujian terhadap manipulasi, dan monitoring aktif terhadap anomali. Kolaborasi antar pemangku kepentingan: Industri pariwisata harus bekerja sama — maskapai, hotel, OTA, regulator — untuk berbagi intelijen ancaman, praktik terbaik, dan memperkuat ekosistem secara kolektif. 5. Kesimpulan Transformasi digital di industri pariwisata membuka banyak peluang — pengalaman pelanggan yang richer, efisiensi operasional, jangkauan global yang lebih luas. Namun bersama peluang itu datang pula tantangan keamanan yang sangat serius. Artikel Imperva mengingatkan bahwa ancaman seperti data breach, ransomware, bot streaming, dan AI-bantu otomatisasi tidak lagi “mungkin terjadi” tapi sudah menjadi kenyataan setiap hari. Oleh sebab itu, keamanan siber di sektor perjalanan bukan hanya isu teknologi—tetapi isu bisnis inti yang membutuhkan perhatian strategis, investasi, dan kolaborasi. Karena ketika perjalanan digital tidak aman, kepercayaan pelanggan hancur, dan akhirnya bisnis pariwisata terancam. Dengan memahami lanskap ancaman dan menerapkan strategi mitigasi yang tepat, industri pariwisata dapat mengamankan perjalanan digital bagi pelanggan, meminimalkan kerugian, dan menjaga kepercayaan — karena perjalanan yang lancar juga harus aman. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut!

Pendahuluan: Bagaimana Serangan ‘Valid’ Bisa Menjadi Senjata Mematikan Dalam dunia keamanan siber, kita sering fokus pada serangan eksploitasi buffer overflow, injeksi SQL, atau ransomware — yang mudah dikenali sebagai aktivitas mencurigakan. Tapi ada serangan lain yang jauh lebih halus dan berbahaya: serangan menggunakan jalur yang “terlihat valid” dan memanfaatkan data bocor lama serta elemen desain antarmuka yang tampaknya innocuous. Imperva dalam artikelnya menjelaskan bagaimana kombinasi kebocoran data masa lalu, kerentanan desain UI (contoh: iframe Google Pay), dan praktik verifikasi lemah di operator selular bisa dipakai untuk melakukan SIM swap attack — sebuah metode perampasan identitas yang sering menjadi pintu masuk fraud finansial dan pencurian akun. Artikel ini akan mengurai bagaimana serangan tersebut bekerja, contoh nyata kasusnya, mitigasi teknis yang bisa diterapkan, serta implikasi khusus untuk organisasi dan pengguna di Indonesia. Bagian 1: Teknik Serangan – Dari Iframe Google Pay hingga SIM Swap Iframe & Pembocoran 4 Digit Kartu Salah satu elemen revolusioner dalam serangan ini adalah penggunaan iframe yang memuat Google Pay. Jika pengguna sudah login dan memiliki kartu tersimpan, tombol Google Pay akan menampilkan empat digit terakhir kartu di dalam iframe tersebut. (Imperva) Penyerang bisa mendesain halaman sedemikian rupa sehingga hanya bagian dari iframe itu saja yang terlihat, atau disamarkan sebagai CAPTCHA, meminta pengguna untuk “membaca angka” dan membiarkan mereka mengungkap 4 digit tersebut. Dengan CSS, cropping, dan styling yang kreatif, angka tersebut bisa disembunyikan dalam elemen UI yang tampak sah. Bot Obat & Infrastruktur Kecil yang Terbuka Imperva menjelaskan bahwa di beberapa kota (contohnya Tel Aviv), iklan obat gelap berisi QR code diarahkan ke kanal Telegram, di mana bot otomatis menangani transaksi, verifikasi, bahkan “screening” untuk memastikan klien bukan polisi. Bot seperti ini menjadi infrastruktur tersebar, membuka akses ke siapa saja yang memiliki kredensial, identitas yang bocor, atau cara manipulasi. Karena sebagian besar identitas (nama, nomor ID, kebocoran data) sudah tersedia di publik dari kebocoran lama, para penjahat dapat mencocokkan data ini dengan empat digit yang didapat dari iframe Google Pay dan kemudian menggunakannya sebagai bukti ke operator seluler ketika melakukan permintaan SIM swap. SIM Swap dan Verifikasi Lemah SIM swap adalah teknik di mana pelaku meminta operator seluler mengganti kartu SIM korban ke SIM baru yang mereka kendalikan. Jika operator menerima permintaan berdasarkan identitas dasar (nama, nomor ID, 4 digit kartu) tanpa verifikasi kuat tambahan, maka pelaku bisa mengambil alih nomor telepon korban. Setelah berhasil, mereka dapat menerima SMS OTP, reset akun, atau otorisasi keuangan. Imperva mencatat bahwa kasus nyata di Israel menggunakan metode ini dengan “verifikasi” yang sangat lemah. Bagian 2: Dampak, Risiko & Skala Serangan Aspek Dampak / Risiko Pengambilalihan Akun Akses ke akun perbankan, dompet digital, layanan keuangan Penipuan Finansial Transfer tanpa izin, pembelian, pengurasan dana Identitas & Reputasi Penggunaan data pribadi dan peniruan identitas Risiko Sistemik Jika praktik serupa digunakan skala besar, user trust menurun bagi layanan digital Regulasi & Kepatuhan Pelanggaran perlindungan data dan keharusan mitigasi insiden Karena teknik ini memadukan kebocoran lama + UI trickery + kelemahan operasional, seringkali korban tidak sadar telah diserang sampai sudah terlambat. Hal ini menjadikannya salah satu ancaman paling licik dalam lanskap keamanan siber. Bagian 3: Mitigasi & Rekomendasi Teknikal Berikut daftar langkah yang dapat diterapkan oleh penyedia layanan digital, operator keuangan, maupun institusi telekomunikasi untuk mencegah serangan sejenis: Mitigasi / Fokus Langkah Praktis Penjelasan Redesign UI / Iframe Handling Jangan tampilkan data sensitif (4 digit) langsung di iframe; jika memang diperlukan, hanya tampilkan di lingkungan aman atau setelah otentikasi kuat Menghilangkan bahan mentah yang bisa disalahgunakan melalui trik UI Verifikasi Multifaktor & Strong Identity Checks Gunakan verifikasi tambahan (MFA, biometrik, video, challenge-response unik) saat melakukan perubahan SIM atau profil penting Memastikan bahwa permintaan perubahan benar-benar sah Ratifikasi Proses Operator Seluler Operator harus menolak permintaan berdasarkan data dasar saja; tambahkan validasi tambahan internal Meminimalkan kemungkinan SIM swap berdasarkan data bocor saja Pemantauan & Deteksi Anomali Identifikasi pola: permintaan SIM swap tiba-tiba, perubahan profil, akses dari IP asing Respons cepat jika pola mencurigakan muncul Peninjauan Kebocoran Lama & Pencocokan Data Internal Gunakan sistem threat intelligence untuk mendeteksi apakah pelanggan ada di daftar bocor Jika data bocor, lakukan mitigasi ekstra (notifikasi, reset, verifikasi ulang) Edukasi Pengguna Ingatkan pengguna agar tidak mengungkap 4 digit kartu, waspadai “CAPTCHA” aneh, dan selalu memperketat keamanan akun Kesadaran adalah lapis pertahanan paling dasar Imperva juga menyebut bahwa mereka sudah melaporkan kerentanan ini ke Google, dan Google merespons dengan segera menghapus tampilan 4 digit dari tombol Google Pay sebagai mitigasi awal. Namun, solusi jangka panjang memerlukan perubahan praktek verifikasi di operator, bank, dan layanan keuangan yang sering masih mengandalkan data statis (4 digit kartu) sebagai “verifikasi tambahan”. Bagian 4: Relevansi & Implikasi untuk Indonesia / Asia Tenggara Beberapa poin khusus yang perlu diperhatikan di konteks Indonesia: Praktik Verifikasi Lama Masih Digunakan Di banyak institusi keuangan dan operator seluler, verifikasi menggunakan data kartu (termasuk 4 digit) dan data pribadi pengguna masih umum — membuka peluang risiko. Kebocoran Data Lokal & Basis Data Publik Indonesia sudah mengalami beberapa kebocoran data besar (misalnya data e-KTP, sistem internal perusahaan) — yang menciptakan “database pencocokan” untuk penjahat. Regulasi Perlindungan Data & Otoritas Telekomunikasi OJK, Bank Indonesia, dan Kementerian Kominfo perlu mengevaluasi regulasi agar menuntut verifikasi lebih kuat sebelum perubahan nomor / akses telepon. Peningkatan Literasi & Kesadaran Pengguna Pengguna harus dibekali pengetahuan agar tidak mudah mengikuti permintaan “CAPTCHA” yang tidak biasa, dan hati-hati pada tombol pembayaran yang tampak aneh. Kolaborasi Keamanan Lintas Industri Bank, operator telekomunikasi, dan penyedia dompet digital perlu berbagi intelijen ancaman untuk mendeteksi pola SIM swap, bot, dan aktivitas tersangka. Investasi Teknologi Deteksi Anomali & Threat Intelligence Perusahaan keamanan lokal bisa mengembangkan sistem yang memonitor aktivitas SIM swap, hubungan data bocor, dan anomali transaksi. Kesimpulan & Arah ke Depan Serangan yang menggabungkan kebocoran data lama, trik UI tersembunyi, bot otomasi, dan kelemahan proses operator menunjukkan evolusi kompleksitas dalam dunia keamanan digital. Teknik yang tampak sederhana — seperti menampilkan 4 digit kartu — bisa menjadi bahan baku untuk serangan besar seperti SIM swap. Imperva telah menunjukkan bahwa penggunaan data bocor lama + elemen desain antarmuka + verifikasi lemah bisa menciptakan rantai serangan. Respons cepat Google untuk…

Pendahuluan: API — Dulu “Backstage”, Kini Sasaran Utama Serangan API (Application Programming Interface) pada awalnya lebih sering dianggap sebagai “punggung” aplikasi — lapisan internal yang menjalankan pertukaran data antar modul dan layanan. Namun kini, API justru menjadi salah satu front paling penting dalam keamanan aplikasi modern. Seiring aplikasi makin terdistribusi, layanan mikro (microservices), integrasi pihak ketiga, dan arsitektur berbasis API-first, para penyerang pun beralih taktik. Mereka kini menyerang lewat alur bisnis yang valid, bukan melalui celah teknis sederhana. Dalam enam bulan pertama 2025, Imperva mencatat lebih dari 40.000 insiden API di lebih dari 4.000 lingkungan terpantau. Bahkan satu serangan DDoS di lapisan aplikasi (API) pernah memuncak pada 15 juta requests per second terhadap sebuah API finansial. Yang menakutkan: sebagian besar serangan ini bukan berasal dari permintaan yang mencurigakan secara teknis — melainkan dari permintaan yang “valid” tetapi disalahgunakan (business logic abuse). Misalnya, kampanye looping promosi yang menguras diskon, scraping data yang halus, atau pembajakan akun yang tersembunyi di balik token yang sah. Artikel ini akan membahas: bagaimana pola serangan terbaru di API, insight dari laporan Imperva, playbook pertahanan yang praktis, serta rekomendasi khusus agar organisasi di Indonesia/Asia Tenggara bisa menangkal serangan API efektif. Evolusi Serangan API: Taktik & Tren 1. Scale + Stealth Para penyerang menggunakan jaringan bot, proxy, dan otomatisasi murah untuk menjalankan permintaan yang tampak wajar dalam volume tinggi, dengan cara yang tersembunyi sehingga tidak memicu alarm tradisional. 2. Business Logic Abuse Serangan kini fokus mengeksploitasi “lubang logika bisnis” — misalnya, penggunaan promo beberapa kali, manipulasi parameter untuk mengubah harga, memanfaatkan kelemahan autentikasi internal. Karena bentuknya valid (memenuhi kontrak API), firewall tradisional atau deteksi signature sering gagal mendeteksinya. 3. Blind Spot Operasional Banyak organisasi memiliki “endpoint bayangan” (shadow endpoints) — API yang tak terdokumentasi, integrasi mitra, atau endpoint lama yang terlupakan. Juga, validasi token atau otorisasi yang tidak konsisten membuka celah. Menurut Imperva, bagian terbesar dari serangan terjadi di domain: akses data (~ 37 %), checkout / pembayaran (~ 32 %), dan autentikasi (~ 16 %). Empat Kebenaran Besar (Truths) dari Laporan Imperva Imperva merangkum lima “kebenaran” penting yang harus dipahami oleh para eksekutif & praktisi keamanan: API adalah permukaan serangan utama sekarang — endpoint API yang mengakses data atau alur bisnis penting harus jadi prioritas pertahanan. Valid ≠ aman — permintaan valid bisa disalahgunakan secara logika, jadi perlu perlindungan berbasis konteks & aturan runtime. Penemuan (discovery) adalah kewajiban — banyak endpoint tersembunyi yang tidak terinventaris, yang menjadi pintu masuk serangan. Serangan otomatis & kampanye scraping / looping merusak pendapatan secara diam‑diam — bahkan operasi read (baca data) pun bisa jadi ancaman. Pertahanan gabungan lebih efektif — signature saja tidak cukup; diperlukan enforcement runtime, analitik perilaku, adaptive throttling, token pendek yang terbatas. Playbook Pertahanan: Checklist yang Bisa Dilaksanakan Seketika Berikut rangkuman taktik yang bisa mulai diterapkan oleh tim keamanan / pengembang, baik jangka pendek maupun menengah: Lapisan / Fokus Langkah Praktis Tujuan / Manfaat Discovery & Inventory Kombinasikan metode aktif dan pasif untuk menemukan endpoint tersembunyi Menutup celah shadow APIs segera Enforce Schema & Kontrak Terapkan validasi OpenAPI / GraphQL runtime — reject field tak terduga Mencegah injeksi parameter atau manipulasi data Otorisasi Objektif Tidak semua “read” setara — terapkan kontrol per objek / field berdasarkan pengguna Membatasi data yang boleh diakses tiap entitas Analitik & Deteksi Terkait KPI Bisnis Monitor metrik seperti redemptions promo, lonjakan refund, kecepatan reservasi Mengaitkan serangan dengan dampak bisnis & memicu respons otomatis Throttle Adaptif & Bot Management Batasi permintaan berdasarkan konteks (lokasi, perilaku, risiko) Memblokir bot sementara menjaga UX pengguna nyata Token Scoped & Short-Lived Gunakan token terbatas cakupan dan masa berlaku pendek + step-up MFA Mengurangi risiko replay / pencurian token Kebersihan Rantai Pasokan & Patching Evaluasi dependensi API, patch cepat untuk kerentanan (misalnya logic leak) Mencegah eksploitasi elemen mitra / pihak ketiga Beberapa “quick wins” yang bisa langsung memberi ROI: Tutup endpoint shadow berisiko tinggi yang ditemukan segera. Terapkan otorisasi objek & validasi runtime untuk endpoint kritis. Gunakan throttling adaptif di endpoint promosi atau yang sensitif. (Impor­tan: langkah-langkah ini bisa menunjukkan hasil dalam minggu pertama) Implikasi & Strategi untuk Organisasi di Indonesia / Asia Tenggara Dalam konteks Indonesia atau kawasan Asia Tenggara, beberapa faktor tambahan harus diperhatikan agar strategi keamanan API bisa efektif: Adopsi API & Teknologi Modern Banyak organisasi (bank, e-commerce, fintech) sudah menempatkan API sebagai bagian integral dari arsitektur digital mereka. Keamanan API bukan lagi opsional. Keterbatasan Anggaran & Sumber Daya Beberapa organisasi skala menengah mungkin belum punya tim keamanan API khusus. Playbook sederhana (discovery, validasi runtime) dapat menjadi starting point yang realistis. Regulasi Data & Kepatuhan Pastikan perlindungan data (PII), audit log, dan kontrol akses mematuhi regulasi lokal (misalnya UU PDP Indonesia). Token yang expired, validasi lapisan bisnis, dan audit trail sangat penting. Kolaborasi Pengembang & Keamanan (DevSecOps) Keamanan API harus terintegrasi dalam siklus pengembangan — bukan tambahan di belakang. Training tim dev agar memahami pola abuse API penting. Infrastruktur & Latensi Jaringan Di kawasan dengan konektivitas variatif, perlindungan API harus mempertimbangkan kebutuhan latensi & pengalaman pengguna. Strategi throttling / proteksi tidak boleh mengorbankan performa. Ancaman Lokal & Modus Khusus Serangan scraping harga, manipulasi promo, bot lokal (melalui proxy lokal) bisa menjadi concern spesifik. Tak jarang serangan lokal lebih sulit dibedakan dari trafik asli. Penutup: API sebagai Gerbang & Tanggung Jawab Era di mana API adalah “bagian tersembunyi aplikasi” sudah usai. Kini, API adalah gerbang utama — ke data, ke transaksi, ke identitas pengguna. Para penyerang telah menyesuaikan diri untuk menyerang dari dalam aliran kita sendiri: “valid requests but malicious intent”. Pertahanan yang efektif bukan soal “memblokir sebanyak mungkin” tapi soal “mengamankan apa yang penting” — dengan pemahaman konteks bisnis, otorisasi objek, throttle adaptif, dan analitik terhubung ke KPI organisasi. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan Imperva Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi imperva.ilogoindonesia.id untuk informasi lebih lanjut!