Insiden Keamanan Cloudflare pada Thanksgiving 2023

 (blog.cloudflare.com)
1 poin oleh GN⁺ 2024-02-02 | 1 komentar | Bagikan ke WhatsApp
  • Cloudflare mengumumkan bahwa pada 23 November 2023 mereka mendeteksi pelaku ancaman di server Atlassian yang di-hosting sendiri, tetapi data pelanggan, sistem pelanggan, serta sistem dan konfigurasi jaringan global tidak terdampak
  • Jalur intrusinya adalah 1 token akses dan 3 kredensial akun layanan yang tidak dirotasi setelah pelanggaran Okta pada Oktober 2023, dan akses berfokus pada lingkungan Atlassian seperti Jira, Confluence, dan Bitbucket
  • Pelaku ancaman melakukan pengintaian dan mengakses dokumen internal pada 14–17 November, lalu pada 22 November memasang Sliver melalui ScriptRunner for Jira untuk memperoleh akses persisten
  • Dalam respons “Code Red”, Cloudflare merotasi lebih dari 5.000 kredensial produksi, melakukan penyaringan forensik pada 4.893 sistem, serta melakukan re-imaging dan reboot pada semua mesin di jaringan global dan produk Atlassian
  • Investigasi independen CrowdStrike juga tidak menemukan aktivitas yang terlewat, dan bukti aktivitas ancaman terakhir dikonfirmasi pada 24 November 2023 pukul 10:44 UTC

Ringkasan insiden dan cakupan dampak

  • Cloudflare mendeteksi pelaku ancaman di server Atlassian yang di-hosting sendiri pada 23 November 2023
    • Tim keamanan segera memulai investigasi dan memblokir akses
    • Pada 26 November, tim forensik CrowdStrike dipanggil untuk melakukan analisis independen
  • Data pelanggan maupun sistem pelanggan tidak terdampak oleh insiden ini
    • Layanan tidak terlibat
    • Tidak ada perubahan pada sistem jaringan global atau konfigurasi
    • Kontrol akses, aturan firewall, dan kunci keamanan perangkat keras yang diwajibkan oleh alat Zero Trust internal membatasi pergerakan lateral
  • Cakupan akses pelaku ancaman terbatas pada Atlassian Confluence, wiki internal; Jira, basis data bug; Bitbucket, sistem manajemen kode sumber; serta server tempat Atlassian berjalan

Kredensial yang digunakan untuk intrusi

  • Intrusi bermula dari 1 token layanan dan 3 akun layanan yang bocor tetapi tidak dirotasi setelah pelanggaran Okta pada Oktober 2023
    • Token layanan Moveworks: digunakan untuk akses jarak jauh ke sistem Atlassian
    • Akun layanan Smartsheet: memiliki hak administrator pada instans Atlassian Jira
    • Akun layanan Bitbucket: digunakan untuk mengakses sistem manajemen kode sumber
    • Akun lingkungan AWS: tidak memiliki izin akses ke jaringan global, data pelanggan, atau data sensitif
  • Token dan akun tersebut keliru dianggap tidak digunakan, sehingga tidak masuk dalam target rotasi
  • Cloudflare menegaskan bahwa masalah ini bukan kesalahan Atlassian, AWS, Moveworks, atau Smartsheet, melainkan akibat Cloudflare gagal merotasi kredensial

Linimasa serangan

  • Mulai 14 November pukul 09:22:49, pelaku ancaman mulai menjelajahi sistem dan melakukan pengintaian
    • Upaya login ke instans Okta ditolak
    • Akses ke Cloudflare Dashboard juga diblokir
    • Mereka mengakses lingkungan AWS yang menjalankan marketplace Cloudflare Apps, tetapi lingkungan ini terpisah dari jaringan global dan data pelanggan
  • Pada 15 November pukul 16:28:38, mereka berhasil mengakses Atlassian Jira dan Confluence
    • Mereka melewati gateway menggunakan token layanan Moveworks dan mengakses rangkaian produk Atlassian dengan akun layanan Smartsheet
    • Di wiki, mereka mencari istilah seperti remote access, secret, client-secret, openconnect, cloudflared, token
    • Mereka mengakses 36 dari 2.059.357 tiket Jira dan 202 dari 194.100 halaman wiki
    • Tiket Jira yang diakses mencakup item terkait manajemen kerentanan, rotasi secret, bypass MFA, akses jaringan, dan respons insiden Okta
  • Pada 16 November pukul 14:36:37, dengan kredensial Smartsheet mereka membuat akun Atlassian yang tampak seperti pengguna Cloudflare biasa dan menambahkannya ke beberapa grup
    • Ini adalah langkah agar tetap dapat mengakses lingkungan Atlassian meskipun akun layanan Smartsheet dihapus
  • Dari 17 November pukul 14:33:52 hingga 20 November pukul 09:26:53, akses ke sistem Cloudflare berhenti kecuali beberapa uji akses singkat
  • Pada 22 November pukul 14:18:22, dengan hak administrator Jira milik akun layanan Smartsheet, mereka memasang Sliver Adversary Emulation Framework melalui plugin ScriptRunner for Jira
    • Sliver adalah alat dan framework yang digunakan tim merah dan penyerang untuk C2, konektivitas, serta akses yang persisten dan tersembunyi
    • Melalui ini, mereka memperoleh akses persisten ke server Atlassian dan mencoba melakukan pergerakan lateral
    • Upaya mengakses server konsol non-produksi di pusat data di São Paulo, Brasil, yang belum masuk produksi, gagal

Akses ke kode sumber dan dokumen

  • Setelah 22 November, dalam satu hari pelaku ancaman melihat 120 repositori kode dari total 11.904 repositori
    • Dari jumlah tersebut, 76 repositori diunduh ke server Atlassian menggunakan fitur git archive Atlassian Bitbucket
    • Cloudflare tidak dapat memastikan apakah terjadi eksfiltrasi eksternal, tetapi menanganinya dengan asumsi data tersebut telah bocor
  • Ke-76 repositori tersebut sebagian besar terkait area berikut
    • Cara kerja backup
    • Konfigurasi dan pengelolaan jaringan global
    • Sistem identitas Cloudflare
    • Akses jarak jauh
    • Penggunaan Terraform dan Kubernetes
  • Beberapa repositori berisi secret terenkripsi, dan Cloudflare segera merotasinya meskipun secret tersebut terenkripsi kuat
  • Cloudflare memfokuskan investigasi bukan pada kode sumber itu sendiri, melainkan pada secret tertanam dalam kode, kerentanan, dan jalur yang dapat dimanfaatkan untuk serangan berikutnya
    • Cloudflare menjelaskan bahwa mereka telah merilis banyak kode sumber sebagai open source dan secara terbuka membahas algoritme serta teknik yang mereka gunakan melalui blog

Deteksi dan pemblokiran

  • Pada 23 November pukul 16:00, tim keamanan menerima peringatan tentang keberadaan pelaku ancaman
    • 15:58: pelaku ancaman menambahkan akun layanan Smartsheet ke grup administrator
    • 16:00: peringatan otomatis atas perubahan tersebut dikirim ke tim keamanan
    • 16:12: Cloudflare SOC memulai investigasi
    • 16:35: akun layanan Smartsheet dinonaktifkan
    • 17:23: akun pengguna Atlassian yang dibuat pelaku ancaman ditemukan dan dinonaktifkan
    • 17:43: insiden internal Cloudflare dideklarasikan
    • 21:31: aturan firewall untuk memblokir alamat IP pelaku ancaman yang diketahui diterapkan
  • Pada 24 November, aktivitas terakhir dan penghapusan Sliver dikonfirmasi
    • 10:44: aktivitas pelaku ancaman terakhir yang diketahui
    • 11:59: Sliver dihapus
  • Pelaku ancaman mencoba mengakses berbagai sistem seperti metrik internal, konfigurasi jaringan, sistem build, sistem peringatan, dan sistem manajemen rilis, tetapi tidak berhasil
  • Tidak ditemukan bukti akses ke jaringan global, pusat data, kunci SSL, basis data pelanggan atau informasi konfigurasi, Cloudflare Workers, model AI, infrastruktur jaringan, maupun penyimpanan data seperti Workers KV, R2, dan Quicksilver

Respons “Code Red” dan upaya pengerasan

  • Setelah mengeluarkan pelaku ancaman dari lingkungan pada 24 November, Cloudflare mengerahkan personel dari seluruh perusahaan untuk menyelidiki intrusi dan memastikan cakupan akses
  • Mulai 27 November, banyak tenaga teknis dari dalam dan luar tim keamanan berfokus pada proyek Code Red
    • Memperkuat, memverifikasi, dan memperbaiki kontrol lingkungan untuk mengantisipasi intrusi di masa depan
    • Memverifikasi bahwa pelaku ancaman tidak dapat terus mengakses
    • Menyelidiki semua sistem, akun, dan log untuk memastikan apakah ada akses persisten serta target akses atau percobaan akses
  • Langkah-langkah utamanya adalah sebagai berikut
    • Merotasi lebih dari 5.000 kredensial produksi
    • Memisahkan sistem pengujian dan staging secara fisik
    • Melakukan penyaringan forensik pada 4.893 sistem
    • Melakukan re-imaging dan reboot pada semua mesin di jaringan global
    • Melakukan re-imaging dan reboot pada semua produk Atlassian seperti Jira, Confluence, dan Bitbucket
  • Peralatan pusat data São Paulo dikembalikan ke produsen
    • Tim forensik produsen menyelidiki apakah ada akses atau persistensi yang diperoleh
    • Tidak ada temuan, tetapi Cloudflare mengganti perangkat keras tersebut
  • Selain itu, Cloudflare menyelidiki paket perangkat lunak yang belum diperbarui, akun pengguna yang mungkin dibuat, akun karyawan aktif yang tidak digunakan, secret yang mungkin tersisa di tiket Jira atau kode sumber, serta file HAR yang diunggah ke wiki
    • File HAR dihapus untuk mengantisipasi kemungkinan berisi token
  • Pekerjaan Code Red yang bersifat segera berakhir pada 5 Januari 2024, tetapi pekerjaan pengelolaan kredensial, pengerasan perangkat lunak, manajemen kerentanan, dan peningkatan peringatan tambahan terus berlanjut

Investigasi CrowdStrike dan IOC

  • CrowdStrike secara independen menilai cakupan aktivitas pelaku ancaman dan bukti persistensi
    • Tidak ditemukan aktivitas yang terlewat dalam investigasi Cloudflare
    • Bukti aktivitas ancaman terakhir disimpulkan terjadi pada 24 November 2023 pukul 10:44 UTC
  • Berdasarkan kerja sama dengan rekan-rekan di industri dan pemerintah, Cloudflare menilai bahwa serangan ini dilakukan oleh aktor yang didukung negara yang berupaya mendapatkan akses persisten dan luas ke jaringan global Cloudflare
  • Cloudflare memublikasikan indikator kompromi agar organisasi lain yang mungkin terdampak pelanggaran Okta dapat memeriksa log mereka
    • 193.142.58[.]126: infrastruktur utama pelaku ancaman, dimiliki oleh M247 Europe SRL
    • 198.244.174[.]214: server Sliver C2, dimiliki oleh OVH SAS
    • idowall[.]com: infrastruktur penyedia payload Sliver
    • jvm-agent: nama file payload Sliver, SHA256 bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf

Bacaan terkait

1 komentar

 
GN⁺ 2024-02-02
Pendapat di Hacker News

  • Karena analisis terbuka dan respons seperti ini dari Cloudflare, saya merasa bisa mempercayakan data dan bisnis saya kepada mereka
    Mereka tidak sempurna dan ada hal-hal yang tidak saya setujui, tetapi mindset engineering yang dibagikan di seluruh perusahaan serta sikap mereka yang menangani hal seperti ini dengan serius membuat saya merasa mereka layak dipercaya

    • Kalau begitu iklannya berhasil
      Caranya adalah menekankan bahwa mereka memiliki integritas yang lebih tinggi daripada pesaing, dan membagikan beberapa investigasi operasional setelah insiden keamanan terbaru
      Namun Cloudflare tidak menyediakan analisis risiko SOC sebagai pemroses kartu pembayaran PCI/DSS, dan tidak menjelaskan mengapa akun dengan hak yang ditingkatkan itu terlewat, atau bagaimana akun-akun tersebut pertama kali diretas. Mereka hanya menjelaskan remediation, bukan akuntabilitas
      Mereka menyebut audit pihak ketiga, tetapi itu bukan demi pengguna, melainkan karena PCI/DSS mewajibkan organisasi yang informasi kartu pembayarannya dibobol untuk menjalani audit onsite setiap tahun. Kalau tidak, penerbit kartu besar akan menghentikan pemrosesan pembayaran
    • Tidak ada perusahaan yang sempurna, tetapi Cloudflare jelas memberi rasa percaya. Saya terutama menyukai contoh ketika mereka tidak menyembunyikan masalah dan proses penyelesaiannya, dan menurut saya penjelasan seperti inilah yang menunjukkan kemampuan untuk melewati tantangan apa pun
    • Kami adalah pelanggan enterprise Cloudflare yang cukup besar, dan respons seperti ini membuat persetujuan perpanjangan lebih mudah didapat. Terus memasukkan para engineer sebagai pihak yang ikut menerima informasi sangat membantu meyakinkan pihak internal
    • Penyusup mengakses KB dan tiket, lalu benar-benar tidak mendapat informasi bernilai? Anda percaya itu? Kalau tahu Jira dipakai untuk apa, dan sampai mengoperasikannya on-premise, berarti ada sesuatu yang bernilai untuk disimpan di sana
      Sulit percaya bahwa tidak ada yang hilang, dan kebanyakan Jira/Confluence yang pernah saya lihat penuh dengan informasi rahasia
    • Jangan mengatakan hal yang akan dibenci CEO Cloudflare, dan berharap saja tetap berada di sisi baik mereka

  • Melihat bagian “setelah menganalisis halaman wiki, isu database bug, dan repositori source code yang diakses, tampaknya mereka mencari informasi tentang arsitektur, keamanan, dan pengelolaan jaringan global”, cara termudah bagi aktor negara adalah memasukkan warga negara yang loyal sebagai karyawan di perusahaan target, lalu meminta orang itu mengirimkan informasi tersebut
    Ada cerita menarik, meski kebenarannya tidak pasti, bahwa lebih dari 10 tahun lalu di sebuah acara sosial SRE Google, beberapa orang pernah mengaku menerima gaji dari badan intelijen negaranya

    • Apakah orang-orang itu menjalankan pekerjaan kerja sama pemerintah dengan persetujuan Google, dan relasi itu boleh mereka ungkapkan satu sama lain?
      Kalau tidak, saya penasaran obat sekeras apa yang beredar di pertemuan itu sampai terjadi kegagalan keamanan operasi separah itu
    • Dibayar? Kalian juga dapat uang?
      Orang Australia mendapat “kesempatan” untuk ikut dalam jenis kegiatan mata-mata seperti itu seolah itu syarat dasar kewarganegaraan https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
      Sisi baiknya, mungkin itu bisa membantu memaksa praktik yang baik dalam pengembangan prosedur dan sistem zero trust
    • Tepat. Terutama kalau perusahaan AS. Kalau sudah punya kunci dan izin, untuk apa membobol gembok?
    • Tidak kalau warga itu terkena sanksi. Code Red. Itu petunjuknya

  • Dari bagian “kami menjadi korban kedua dari pelanggaran sistem Okta”, saya penasaran apakah Cloudflare sedang meninjau ulang penggunaan Okta

    • Kasus ini lebih dekat ke insiden di mana Cloudflare gagal merotasi kredensial yang bocor saat pelanggaran Okta awal, bukan kegagalan tambahan dari Okta
      Okta memang layak dikritik, tetapi ini terasa seperti Cloudflare mengalihkan tanggung jawab ke bawah untuk menutupi kesalahannya sendiri
    • Perusahaan kami hanya memberikan laptop baru yang sudah dipasangi sistem manajemen Okta
      Saya masih memakai MacBook lama yang saya terima pada “masa awal”, jadi tidak ada perangkat lunak manajemen sama sekali. Saat itu belum ada IT dan saya hanya menerima laptop baru yang belum diutak-atik
      Perusahaan menawarkan upgrade ke M1/M2 Pro, tetapi saya menolak karena tidak ingin memakai sistem login Okta jika ada satu pun kata sandi atau key pribadi di komputer kerja
      Jadi saya tidak bisa upgrade sampai pekerjaan benar-benar terganggu. Mungkin insiden seperti ini bisa saya pakai sebagai dasar untuk membenarkan pandangan saya kepada departemen IT
    • Masalahnya adalah siapa alternatif yang bisa memenuhi kebutuhan Cloudflare. Langkah berikutnya adalah membangun sendiri, dan itu jelas pilihan yang sulit ditelan

  • Pernyataan “satu token layanan dan tiga akun tidak dirotasi karena secara keliru diyakini tidak digunakan” terasa aneh. Kalau memang tidak digunakan, kenapa tidak dicabut saja sepenuhnya?
    Mungkin ada sesuatu yang terlewat atau hilang dalam penyampaiannya, tetapi jika dibaca apa adanya, kalimat itu sulit dipahami

    • Di sini, ungkapan “diyakini” mungkin lebih merujuk pada status konfigurasi daripada penilaian aktif seseorang
      Misalnya, di suatu database akun layanan tersebut ditandai sebagai status nonaktif seperti “dicabut” atau “dibersihkan”, tetapi penanda itu ternyata salah. Jadi mereka merotasi semua password akun aktif, tetapi melewati akun nonaktif
      Kalau hanya melihat konteks infrastruktur kunci publik dan pencabutan sertifikat yang saya kenal baik, membiarkan sertifikat kedaluwarsa, menandainya sebagai “tidak lagi digunakan”, dan mencabutnya sepenuhnya adalah hal yang cukup berbeda. Certificate authority tidak perlu melakukan apa pun pada kasus pertama; pada kasus kedua bisa tidak melakukan apa pun atau mencabutnya; pada kasus ketiga harus secara aktif memelihara dan mendistribusikan daftar pencabutan. Kalau seseorang berkata “saya tidak sengaja menimpa private key, tolong beri sertifikat untuk key baru”, biasanya sertifikat lama tidak dimasukkan ke daftar pencabutan
    • Kemungkinan besar ini adalah postmortem tanpa menyalahkan
      Pernyataan yang jelas bahwa “ini sama sekali bukan kesalahan AWS, Moveworks, dan Smartsheet, melainkan kredensial yang gagal kami rotasi” adalah poin yang bagus
    • Mungkin proses rotasinya manual dan penanggung jawabnya berusaha menghemat waktu. Stres juga bisa berpengaruh
    • Sepertinya sekarang ada item baru di runbook respons insiden mereka :-)

  • Cloudflare meyakini akses penyerang terbatas dan kemudian mengonfirmasinya, tetapi tetap merotasi lebih dari 5.000 kredensial produksi, memisahkan sistem testing dan staging secara fisik, melakukan pemeriksaan forensik terhadap 4.893 sistem, serta melakukan reimage dan reboot semua mesin di jaringan globalnya
    Upaya mengakses console server di data center São Paulo yang belum masuk produksi juga gagal, tetapi mereka tetap mengirim peralatan data center Brasil kembali ke produsen untuk diforensik, dan meskipun tidak ditemukan apa pun, hardware-nya tetap diganti
    Mereka sebenarnya tidak perlu sampai sejauh ini dan akan mudah untuk tidak melakukannya, tetapi fakta bahwa mereka benar-benar melakukannya patut dipuji

    • Justru menurut saya memang harus sampai sejauh itu
      Menyusup pada tahap awal pembangunan data center baru itu hampir seperti exploit pamungkas. Bayangkan masuk ke tengah Meet-Me room baru (https://en.wikipedia.org/wiki/Meet-me_room) dan memperoleh akses persisten ke switch inti
      Data center Cloudflare sering kali menjadi hub lalu lintas data dalam jumlah sangat besar. Fakta bahwa penyerang memahami nilai data center “pra-produksi” mungkin berarti Cloudflare juga sadar bahwa jika ada pijakan di sana sebelum kerangka keamanan reguler terpasang, itu 100% game over. Jika seseorang berhasil bercokol di dalam data center yang sedang dibangun dan dinyalakan, itu bisa menjadi insiden yang mengakhiri perusahaan
      Perlu diingat juga bahwa pada awal pembangunan data center, semua switch dan perangkat memakai nilai default atau password root kosong (admin/admin), dan firmware-nya juga tua sehingga punya banyak celah. Jika serangan seperti ini terjadi sebelum automasi menambal seluruh firmware, ini sudah setara dengan “kembalikan semua perangkat dan minta produsen mengirim perangkat baru”
    • “Tim forensik produsen memeriksa semua sistem dan memastikan tidak ada akses atau persistensi. Tidak ditemukan apa pun, tetapi kami tetap mengganti hardware”-nya, ya trik lama penggantian hardware tepercaya
    • Jumlah presentasi DEFCON yang pernah saya tonton memang tidak banyak, tetapi rasanya mereka tentu sudah melakukan sampai tingkat itu
    • Respons tingkat nuklir terhadap kompromi seharusnya menjadi praktik kerja standar, dan penyimpangan darinya yang harus menjadi pengecualian
      Jika Anda berasumsi penyerang hanya mengakses cakupan yang dapat dibuktikan, Anda meninggalkan celah agar penyerang tetap bertahan. Untuk mengatakan bahwa ini tidak perlu dilakukan, seharusnya diperlukan persetujuan kuorum dari beberapa orang
      Tentu saja ini bicara dunia ideal. Saya sendiri merasa beruntung jika tim kami diberi waktu untuk mengimplementasikan fitur yang tidak memberikan manfaat finansial atau pengguna secara langsung
    • Karena itulah para penanggung jawab operasi keamanan lama dan keamanan perusahaan begitu terobsesi pada tabletop exercise, dan BadThingsDaily† di Twitter itu bagus
      Untuk siap menjalankan rotasi kredensial semacam ini dibutuhkan disiplin dan persiapan, dan terus terang sebagian besar tim tidak melakukan investasi itu. Bahkan tim yang pintar dan punya banyak sumber daya pun demikian
      Jika tim keamanan Cloudflare bisa memutuskan untuk merotasi semua secret dan melakukan reimage semua mesin, lalu hal itu benar-benar terjadi dalam waktu yang wajar, itu cukup mengesankan
      † https://twitter.com/badthingsdaily?lang=en

  • Bagian yang paling mengejutkan di sini adalah Cloudflare memakai Bitbucket

    • Saya tidak tahu kenapa itu mengejutkan. Integrasinya bagus dengan produk Atlassian lain yang sudah mereka pakai
    • Terintegrasi dengan Jira dan tool Atlassian lainnya, dan pada akhirnya itu cuma satu lagi server Git
    • Bisa jadi, bisa juga tidak. Saya tidak suka Bitbucket, tetapi cukup banyak perusahaan besar yang khawatir memakai layanan milik pesaing di salah satu poros bisnis mereka
    • Saya penasaran seberapa kuat Scriptrunner for Jira. Memang punya sertifikasi keamanan, tetapi saya tidak tahu seberapa jauh ia di-sandbox
    • Banyak perusahaan sangat besar memakai Bitbucket. Karena jauh lebih hemat biaya dibanding GitLab/GitHub

  • Begitu data bocor ke luar, dalam kasus ini source code berarti berada di luar secara permanen, dan Anda sama sekali tidak bisa mengontrol siapa yang mengambilnya
    Anda bisa melakukan hardening pascainsiden semau Anda dan membicarakannya sebanyak apa pun, tetapi hal yang ingin dicegah sudah terjadi. Telur yang sudah dipecahkan tidak bisa dikembalikan lagi

    • Setuju. Menurut saya ini insiden yang cukup besar bagi Cloudflare. Apalagi jika digabung dengan dokumen Confluence, kemungkinan besar ada rencana dan desain masa depan, bagan organisasi, serta notulen rapat
      Di kode lama juga bisa ditemukan easter egg lain. Hampir semua perusahaan punya backdoor yang tidak terdokumentasi
      Kebocoran data pelanggan memang lebih buruk, tetapi ini juga benar-benar tidak baik
    • Jadi intinya apa?
    • Source code tahun depan tidak sama dengan source code tahun ini
      Data pelanggan tahun depan juga tidak sama dengan data pelanggan tahun ini

  • Di Confluence milik Atlassian, bahkan mesin pencari Apache Lucene bawaan saja bisa membocorkan informasi sensitif, dan akses seperti ini bisa sangat sulit dilacak dan diidentifikasi
    Jika informasi sensitif sudah tampil di halaman hasil pencarian, penyerang bahkan tidak perlu membuka halaman Confluence

  • Bagian “satu service token dan tiga akun tidak dirotasi karena keliru diyakini tidak digunakan” terasa aneh. Kredensial yang tidak digunakan kemungkinan besar seharusnya dihapus, bukan dirotasi

    • Ini terasa mencurigakan. Saya mungkin akan menyelidiki siapa yang memutuskan untuk tidak merotasi kredensial spesifik itu
      Apakah situasinya seperti, “Akun-akun ini apa?” “Oh, itu tidak dipakai. Tidak muncul di log juga” “Tetap harus dirotasi” “Tidak, biarkan saja akun-akun arbitrer dengan kredensial lama yang mungkin sudah dikompromikan… alasannya ya kira-kira ada”?
    • Setuju. Seluruh tulisan ini terbaca seperti “saya korban”, tetapi tidak mengakui satu kesalahan yang membesar seperti bola salju

  • Kalau kredensial yang bocor setelah insiden Okta sudah dirotasi, menurut saya seharusnya mereka memasang honeypot di atasnya dan menunggu untuk melihat apa yang dilakukan para penyerang
    Honeypot juga punya efek membuat penyerang tidak berani melanjutkan karena takut ketahuan