Insiden keamanan Thanksgiving 2023

Insiden keamanan Thanksgiving 2023

• Pada 23 November 2023, saat Thanksgiving, Cloudflare mendeteksi pelaku ancaman di server Atlassian yang di-host sendiri.
• Tim keamanan segera memulai penyelidikan dan memblokir akses pelaku ancaman.
• Pada 26 November, tim forensik CrowdStrike dipanggil untuk melakukan analisis independen.
• CrowdStrike menyelesaikan penyelidikan, dan Cloudflare membagikan detail insiden keamanan melalui posting blog ini.
• Ditekankan bahwa data maupun sistem pelanggan Cloudflare tidak terdampak oleh insiden ini.
• Kemampuan pelaku ancaman untuk bergerak secara lateral dibatasi berkat penerapan paksa hard security key menggunakan kontrol akses, aturan firewall, dan alat Zero Trust.

Pekerjaan pemulihan dan penguatan “Code Red”

• Setelah pelaku ancaman disingkirkan dari lingkungan, tim keamanan mengerahkan semua pihak yang diperlukan di seluruh perusahaan untuk menuntaskan penyelidikan intrusi dan pemblokiran akses.
• Mulai 27 November, personel teknis dikerahkan untuk berfokus pada proyek bernama "Code Red".
• Tujuan proyek ini adalah memperkuat dan memverifikasi semua kontrol di dalam lingkungan untuk bersiap menghadapi intrusi di masa depan serta mencegah pelaku ancaman memperoleh kembali akses ke lingkungan.
• CrowdStrike melakukan penilaian independen terhadap cakupan dan tingkat aktivitas pelaku ancaman.

Linimasa serangan

• Serangan bermula dari pelanggaran keamanan Okta pada Oktober, dan sejak pertengahan November pelaku ancaman menargetkan sistem Cloudflare menggunakan kredensial yang diperoleh dari pelanggaran Okta.
• Pada 18 Oktober, pelanggaran Okta menyebabkan pelaku ancaman memperoleh akses ke kredensial.
• Sejak 14 November, pelaku ancaman mulai mencoba menjelajahi sistem dan memperoleh akses.
• Pada 15 November, mereka berhasil mengakses Atlassian Jira dan Confluence.
• Pada 16 November, mereka membuat akun pengguna Atlassian.
• Dari 17 hingga 20 November, mereka tidak mengakses sistem Cloudflare.
• Pada 22 November, mereka memasang Sliver Adversary Emulation Framework untuk mempertahankan akses secara berkelanjutan.
• Pada 23 November, tim keamanan mendeteksi keberadaan pelaku ancaman dan mulai memblokir akses.

Kesimpulan

• Insiden ini diperkirakan dilakukan oleh penyerang yang didukung negara, dan Cloudflare mengerahkan banyak upaya untuk membatasi dampaknya serta bersiap menghadapi serangan di masa depan.
• Tim engineering Cloudflare melindungi sistem, memahami akses pelaku ancaman, menangani prioritas yang mendesak, dan menyusun rencana untuk meningkatkan keamanan secara keseluruhan.
• CrowdStrike melakukan penilaian independen, dan setelah laporan akhir selesai, Cloudflare menerbitkan posting blog ini dengan keyakinan atas analisis internal dan tindakan yang diambil terhadap intrusi tersebut.

Pendapat GN⁺:

1. Insiden ini menekankan pentingnya arsitektur Zero Trust Cloudflare. Pendekatan ini bekerja dengan membatasi penyebaran ancaman ke seluruh organisasi melalui isolasi antar sistem.
2. Respons cepat Cloudflare dan upaya penguatan keamanan melalui proyek "Code Red" memberikan wawasan tentang bagaimana perusahaan merespons ancaman keamanan siber.
3. Tulisan ini menjadi contoh yang bermanfaat untuk memahami bagaimana organisasi harus merespons saat insiden keamanan siber terjadi dan tindakan apa yang perlu diambil.

[GN⁺]

Komentar Hacker News

• Alasan tindakan seperti posting blog Cloudflare membangun kepercayaan

  • Cloudflare memang tidak sempurna, tetapi tetap layak dipercaya karena pola pikir rekayasanya dan cara menangani masalah serius.
  • Ungkapan terima kasih atas posting blog tersebut.

• Masalah kebocoran data

  • Setelah data bocor satu kali, data itu tidak lagi bisa dikendalikan secara permanen.
  • Penguatan dan diskusi setelah insiden memang penting, tetapi tidak bisa mencegah apa yang sudah terjadi.

• Masalah keamanan pada sistem Okta

  • Kekhawatiran karena sistem Okta kembali terkena pukulan untuk kedua kalinya.

• Token layanan dan akun yang tidak dirotasi

  • Tidak dirotasi karena ada keyakinan keliru bahwa kredensial tersebut tidak digunakan.
  • Muncul pertanyaan mengapa tidak dicabut sepenuhnya.

• Akses penyerang yang terbatas dan langkah respons

  • Meski diyakini akses penyerang terbatas, tetap diambil langkah luas seperti merotasi semua kredensial produksi, melakukan analisis forensik pada sistem, serta re-imaging dan reboot.
  • Upaya akses ke sistem baru di data center Brasil gagal, dan peralatan dikembalikan ke produsen untuk diperiksa dan diganti.

• Analisis tujuan penyerang

  • Dari analisis halaman wiki, basis data bug, dan repositori source code, tampaknya mereka berusaha mencari informasi tentang arsitektur jaringan global, keamanan, dan pengelolaan Cloudflare.

• Keterkejutan atas penggunaan BitBucket oleh Cloudflare

  • Ada ungkapan terkejut bahwa Cloudflare menggunakan BitBucket.

• Penanganan kredensial yang tidak digunakan

  • Untuk kredensial yang dianggap tidak digunakan, penghapusan mungkin lebih tepat daripada rotasi.

• Usulan rotasi kredensial dan honeypot setelah insiden Okta

  • Setelah kredensial yang bocor dirotasi, ada usulan untuk menggunakan honeypot guna mengamati perilaku penyerang.

• Keraguan tentang Zero Trust (ZT)

  • Ditunjukkan bahwa kemampuan mengakses aplikasi dengan satu bearer token tidak sesuai dengan definisi Zero Trust.

Pengetahuan latar: Cloudflare adalah perusahaan yang menyediakan layanan keamanan internet dan layanan distributed domain name server, sedangkan Okta adalah perusahaan yang menyediakan layanan identity and access management. Zero Trust adalah salah satu model keamanan jaringan yang pada dasarnya memverifikasi semua pengguna dan perangkat tanpa mempercayai siapa pun secara default.