Bug Oracle PeopleSoft Mengingatkan Bisnis Bahwa Sistem HR Juga Pintu Risiko

Oracle memperingatkan pelanggan korporatnya tentang celah keamanan kritikal di PeopleSoft, software yang banyak dipakai organisasi besar untuk mengelola payroll dan human resources.

Celah ini menjadi serius bukan hanya karena rating-nya kritikal, tetapi karena menurut laporan, bug tersebut sudah disalahgunakan sebelum patch tersedia. Kelompok cybercrime ShinyHunters mengklaim telah membobol lebih dari 100 organisasi yang menggunakan server PeopleSoft.

Mandiant, unit keamanan milik Google, juga menyebut bahwa celah yang sama sedang dipakai dalam kampanye serangan terhadap pelanggan PeopleSoft. Sebagian besar organisasi yang diberi notifikasi berada di Amerika Serikat, dan sekitar dua pertiganya berasal dari sektor pendidikan.

Oracle menyebut bug ini bisa dieksploitasi lewat internet tanpa autentikasi. Artinya, penyerang tidak perlu password untuk mencoba masuk ke sistem yang rentan.

Di beberapa kasus, organisasi berhasil memblokir aktivitas atau melakukan mitigasi. Tetapi sebagian lain mengalami kompromi, dan data yang dicuri mulai dipublikasikan di situs kebocoran data milik penyerang.

The Core Update

Berita ini terlihat seperti isu vendor besar: Oracle punya celah, hacker mengeksploitasi, pelanggan diminta menerapkan mitigasi.

Tetapi bagi bisnis, inti masalahnya lebih luas.

PeopleSoft bukan aplikasi eksperimen. Ini software enterprise yang biasanya berada di lingkungan yang dianggap penting, formal, dan dikelola oleh tim IT yang cukup matang. Ia dipakai untuk data karyawan, payroll, pendidikan, identitas mahasiswa, status enrollment, dan informasi sensitif lain.

Justru karena itu, insiden seperti ini penting dibaca dengan tenang.

Bukan untuk menyimpulkan bahwa semua software enterprise tidak aman. Bukan juga untuk menyalahkan perusahaan yang menjadi korban. Zero-day memang sulit, karena celah sudah dieksploitasi sebelum vendor punya waktu cukup untuk merilis perbaikan.

Namun ada pelajaran yang lebih praktis: sistem internal yang menyimpan data penting tetap bisa menjadi pintu serangan besar jika terekspos, lambat dimitigasi, atau tidak jelas siapa yang bertanggung jawab saat advisory muncul.

Dalam kasus ini, Oracle belum merilis patch pada saat laporan ditulis, tetapi merekomendasikan mitigasi. Itu berarti organisasi tidak bisa menunggu update final dengan pasif. Mereka harus tahu server mana yang terdampak, apakah akses internet terbuka, data apa yang ada di dalamnya, dan langkah sementara apa yang harus diambil.

Masalahnya, banyak bisnis tidak punya jawaban cepat untuk pertanyaan sederhana itu.

The Reality Check

Banyak organisasi merasa aman karena memakai software besar, vendor besar, atau sistem yang sudah lama berjalan. Anggapannya, kalau sistemnya enterprise, risikonya pasti sudah terkendali.

Kadang benar. Vendor besar biasanya punya proses keamanan, dokumentasi, advisory, dan tim respons yang lebih rapi.

Tetapi vendor besar tidak menghapus tanggung jawab operasional di sisi pelanggan.

Celah seperti ini menunjukkan bahwa risiko tidak hanya datang dari aplikasi kecil yang dibuat terburu-buru. Risiko juga bisa datang dari software inti yang sudah bertahun-tahun dipakai, terhubung ke internet, dan menyimpan data bernilai tinggi.

Ada beberapa pertanyaan yang seharusnya muncul di banyak organisasi setelah membaca insiden ini:

• software apa saja yang menyimpan data sensitif?
• sistem mana yang bisa diakses dari internet?
• siapa yang menerima security advisory dari vendor?
• siapa yang memutuskan mitigasi saat patch belum tersedia?
• berapa cepat tim bisa membatasi akses jika ada celah kritikal?
• data apa yang paling mungkin bocor jika sistem tertentu ditembus?

Pertanyaan ini terdengar dasar. Tetapi dalam praktiknya, sering tidak mudah dijawab.

Sistem HR mungkin dikelola tim berbeda dengan website. Sistem payroll mungkin dipegang vendor implementasi. Portal pendidikan mungkin punya integrasi ke sistem lain. Akses server mungkin dibuat bertahun-tahun lalu dan tidak pernah ditinjau ulang.

Ketika serangan terjadi, organisasi baru sadar bahwa dokumentasi aset, akses, dan pemilik sistem tidak sejelas yang dibayangkan.

Di sinilah pendekatan yang terlalu fokus pada tool menjadi kurang cukup.

Firewall penting. Patch management penting. Monitoring penting. Tetapi semuanya membutuhkan struktur kerja yang jelas. Jika tidak ada daftar aset yang sehat, tidak ada pemilik sistem yang jelas, dan tidak ada alur respons saat advisory kritikal muncul, maka tool keamanan hanya bekerja sebagian.

Serangan ShinyHunters juga memperlihatkan pola yang makin umum: penyerang mencari software yang dipakai banyak organisasi, lalu mengeksploitasi kelemahan yang sama secara massal.

Ini pernah terlihat pada kampanye lain yang menyasar ekosistem software populer seperti Salesforce, Gainsight, dan Instructure. Logikanya sederhana: jika satu software dipakai banyak institusi, satu celah bisa membuka banyak target.

Bagi bisnis, ini berarti keamanan tidak bisa hanya dipikirkan sebagai perlindungan satu aplikasi. Keamanan harus dibaca sebagai rantai: vendor, konfigurasi, akses internet, integrasi, data, proses mitigasi, dan komunikasi internal.

Kalau satu bagian kabur, respons menjadi lambat.

The Havedev Way

Dari sudut pandang Havedev, insiden seperti ini bukan sekadar berita cybersecurity. Ini pengingat bahwa bisnis perlu punya peta sistem yang bisa dibaca saat risiko muncul.

Banyak organisasi baru serius membuat daftar sistem ketika audit dimulai, insiden terjadi, atau vendor mengirim peringatan kritikal. Padahal daftar itu seharusnya menjadi bagian dari operasi normal.

Minimal, bisnis perlu tahu beberapa hal dasar:

• aplikasi apa saja yang digunakan untuk data penting
• siapa pemilik bisnis dan teknis dari setiap aplikasi
• apakah aplikasi tersebut terbuka ke internet
• data apa yang disimpan dan dikirim lewat aplikasi itu
• vendor mana yang harus dipantau advisory-nya
• langkah darurat apa yang bisa dilakukan sebelum patch tersedia

Ini tidak harus langsung menjadi program security yang besar dan mahal. Untuk banyak bisnis, langkah awal yang sehat adalah membuat inventory sederhana dan menandai sistem berdasarkan risiko.

Misalnya, sistem yang menyimpan payroll, data pelanggan, data mahasiswa, invoice, akses admin, atau dokumen legal harus masuk kategori prioritas tinggi. Sistem yang terbuka ke internet juga perlu perhatian lebih cepat dibanding sistem internal yang benar-benar terisolasi.

Setelah itu, buat alur respons yang jelas.

Ketika ada advisory kritikal, siapa yang membaca? Siapa yang mengecek apakah sistem terdampak? Siapa yang boleh memutuskan pembatasan akses sementara? Siapa yang menghubungi vendor? Siapa yang memberi update ke manajemen?

Tanpa alur ini, organisasi sering kehilangan waktu di fase paling penting: jam-jam awal setelah risiko diketahui.

Untuk bisnis yang belum punya tim security khusus, pendekatannya bisa dibuat lebih praktis. Mulai dari sistem yang paling dekat dengan data sensitif dan operasional utama. Jangan mencoba merapikan semuanya sekaligus.

Pilih satu area:

• sistem HR dan payroll
• CRM dan lead management
• website dan form kontak
• dashboard internal
• sistem invoice dan pembayaran
• portal pelanggan atau anggota

Lalu tanyakan: jika sistem ini bocor atau tidak bisa diakses besok pagi, apa dampaknya?

Jawaban dari pertanyaan itu biasanya lebih jujur daripada checklist keamanan yang terlalu umum.

Insiden Oracle PeopleSoft juga mengingatkan bahwa mitigasi tidak selalu menunggu patch. Kadang langkah paling penting adalah membatasi akses, memeriksa indikator kompromi, meninjau log, menonaktifkan endpoint tertentu, atau memastikan hanya jaringan tertentu yang bisa menjangkau sistem.

Tetapi semua itu sulit dilakukan jika sejak awal bisnis tidak tahu arsitekturnya.

Keamanan yang baik bukan berarti tidak pernah ada celah. Itu tidak realistis.

Keamanan yang lebih sehat berarti bisnis bisa menjawab dengan cepat: sistem mana yang terdampak, siapa yang bertanggung jawab, data apa yang berisiko, dan tindakan apa yang harus dilakukan hari ini.

Penutupnya sederhana: software besar tetap membutuhkan operasi yang disiplin.

Vendor bisa merilis advisory. Konsultan keamanan bisa memberi peringatan. Media bisa memberitakan serangan. Tetapi bisnis tetap perlu punya struktur internal untuk membaca risiko dan bergerak cepat.

Sebelum menambah tool keamanan baru, cek dulu apakah organisasi Anda punya peta sistem, pemilik akses, dan alur respons yang jelas.

Kalau belum, mulai dari sana.

Dapatkan Audit Teknis Gratis untuk meninjau website, sistem internal, integrasi, dan alur data yang mungkin belum cukup terlihat sebelum menjadi risiko operasional.

---

Sumber referensi berita: TechCrunch