Kami sekarang secara teratur melihat hasil yang mengejutkan dari keberhasilan bom dorong karena taktik ini menjadi metode serangan yang umum. Saat ini, organisasi menghadapi lebih banyak serangan push bombing otentikasi multi-faktor (MFA), di mana penyerang umumnya telah memiliki salah satu faktor otentikasi, seperti nama pengguna/kata sandi. Penyerang kemudian dapat meminta notifikasi push yang akan masuk ke ponsel pengguna.
Serangan bom yang cepat bergantung pada Kelelahan MFA. Meskipun mendapatkan notifikasi push yang tidak terduga bukanlah kejadian yang normal, pengguna dapat menyetujui permintaan tersebut. Bahkan jika pengguna membuat pilihan yang tepat dan menolak permintaan tersebut untuk pertama kalinya, mereka mungkin akan merasa lelah atau bingung dengan pesan-pesan tersebut. Hanya satu 'allow' yang dibutuhkan dan penyerang kemudian diautentikasi. Tergantung pada struktur lingkungan dan kontrol keamanan lain yang ada, hal itu dapat memberikan akses kepada pelaku ancaman ke aplikasi, jaringan, atau file perusahaan. Kami baru-baru ini merinci spesifikasi yang ID Plus digunakan untuk mendeteksi dan melindungi dari serangan ini dalam sebuah blog bernama Melindungi dari Serangan Bom yang Dilakukan oleh MFA.
Menghadapi kelelahan MFA merupakan tantangan keamanan yang menarik bagi sebagian besar organisasi. Meskipun jenis serangan ini seharusnya tidak menjadi kejadian sehari-hari, namun jika terjadi, tim keamanan Anda perlu mengetahuinya dan menanggapinya. Bukan hanya berarti Anda sedang diserang, tetapi juga kemungkinan besar berarti beberapa kredensial telah dikompromikan. Pengeboman yang cepat masuk ke dalam kategori kejadian rendah dan berisiko tinggi. Artikel ini menguraikan beberapa metode dasar untuk menangani jenis serangan ini dari sudut pandang tim operasi keamanan.
Untuk bersiap menghadapi Bom Dorong dan memerangi Kelelahan MFA, Anda harus mulai dengan elemen manusia.
- Kesadaran pengguna. Pengguna perlu lebih dari sekadar sadar: mereka perlu mendapat informasi, waspada, dan peduli. Namun, di saat yang sama, menumbuhkan kesadaran keamanan siber haruslah mudah bagi mereka atau mereka akan gagal. Mengikuti pelatihan kesadaran keamanan setahun sekali mungkin dapat memenuhi kebutuhan kepatuhan, dan memang memberikan beberapa manfaat, tetapi tidak cukup untuk melawan serangan yang canggih. Pengguna harus diberitahu bahwa jika mereka tidak memulai komunikasi, maka mereka harus menganggapnya sebagai sesuatu yang mencurigakan. Jika pengguna memiliki alat dan pelatihan yang tepat, mereka mungkin memiliki kesempatan.
- Pendidikan pengguna. Pastikan bahwa pengguna akhir Anda mengetahui bahwa ada kemungkinan mereka mendapatkan permintaan push-to-auth yang buruk, dan bahwa mereka tidak boleh secara otomatis mengklik 'ok' pada dialog yang sama yang telah mereka lihat 100 kali. Agar pesan ini sampai ke sebagian atau sebagian besar pengguna, program keamanan Anda harus memiliki beberapa jenis komunikasi reguler kepada pengguna bersama dengan cara untuk mempertahankan komunikasi tersebut - pertimbangkan untuk mengirimkan peringatan melalui email, memposting peringatan tersebut ke halaman blog tetap yang dapat diakses oleh semua pengguna, dan menambahkan tautan ke peringatan tersebut di dokumentasi perusahaan lainnya, halaman arahan keamanan Anda, atau menjadikannya sebagai tema Bulan Kesadaran Keamanan Siber.
- Sumber daya pengguna. Ingatlah bahwa untuk berhasil mengeksekusi serangan MFA Fatigue dan Prompt Bombing, penyerang kemungkinan besar sudah memiliki kredensial pengguna. Penyerang yang lebih mahir akan memulai spear phishing dan dapat mengirimkan SMS, peringatan WhatsApp, panggilan telepon, atau email kepada pengguna untuk menambah kebingungan pada MFA Fatigue. Agar pengguna dapat menangkal upaya ini, mereka harus percaya diri tentang cara melaporkan masalah, dan benar-benar memahami bagaimana Help Desk, Service Desk, dan tim Keamanan berkomunikasi dengan mereka. Sekali lagi, di sini kesadaran bukan tentang pelatihan tahunan, tetapi ketekunan komunikasi kepada pengguna dan pemahaman umum tentang cara menemukan sumber daya yang dibutuhkan dan bagaimana segala sesuatunya harus bekerja. Jika setiap pengguna tahu untuk segera menghubungi ServiceDesk dan ServiceDesk memiliki dokumentasi terbaru, atau bahkan jika seseorang dalam tim hanya mengingat bahwa sumber daya ini ada dan dapat menemukannya, maka organisasi Anda berada dalam posisi yang baik.
- Tindakan pengguna. Pengguna tanpa sumber daya yang tidak terlatih adalah target yang baik. Apakah pengguna tahu untuk selalu meminta menghubungi Service Desk melalui alat bantu yang sesuai (Teams, Slack, dll.) dan tidak menerima panggilan telepon apa pun tanpa adanya komunikasi yang terverifikasi terlebih dahulu? Tetapkan ekspektasi dan berikan cara untuk memverifikasi jika pengguna tidak yakin.
Sebagai rangkuman, Anda sebaiknya mengajukan pertanyaan-pertanyaan ini tentang program keamanan Anda dan menggunakan jawabannya untuk meningkatkan proses Anda sesuai kebutuhan:
- Apakah pengguna mengetahui apa yang harus dilakukan jika mereka mendapatkan permintaan autentikasi push yang tidak terduga?
- Dapatkah pengguna melaporkan masalah keamanan dengan cepat?
- Apakah semua pengguna tahu cara menghubungi Service Desk Anda?
- Apakah Service Desk Anda tahu cara merespons masalah keamanan?
- Apakah pengguna memiliki sarana untuk menghubungi Tim Keamanan secara langsung?
- Apakah pengguna mengetahui bagaimana Service Desk akan menghubungi mereka secara sah, dan bahwa kontak di luar mekanisme tersebut tidak boleh dipercaya?
- Apakah pengguna mengetahui cara memvalidasi bahwa kontak tersebut sah?
Cara pertama untuk mencegah kelelahan MFA adalah dengan tidak membiarkannya terjadi. Tidak menggunakan kata sandi akan menghilangkan vektor serangan utama: pasangan nama pengguna dan kata sandi yang dapat bertahan selama berbulan-bulan. Pertimbangkan untuk menggunakan FIDO sebagai faktor utama Anda. Tetapi FIDO mungkin belum praktis untuk semua orang - dan jika itu masalahnya, lalu apa yang harus Anda lakukan?
Seperti yang sering terjadi pada keamanan, pencegahan teknis terbaik adalah pertahanan berlapis. Berikut ini beberapa hal yang perlu dipertimbangkan. Pilihlah yang paling sesuai dengan lingkungan Anda:
- Jika Anda masih mengandalkan nama pengguna dan kata sandi, pastikan Anda memiliki setidaknya brankas kata sandi atau, lebih baik lagi, solusi Manajemen Otentikasi Khusus (PAM) yang lengkap untuk akses Anda yang paling sensitif. Pastikan juga bahwa itu digunakan dengan benar; mungkin sudah waktunya untuk pemeriksaan kesehatan
- Jika ada kecurigaan adanya kredensial yang disusupi, lakukan pengaturan ulang kata sandi. Melakukan pengaturan ulang akan mencegah serangan bom dorong di masa mendatang.
- Meskipun bukan praktik terbaik untuk mengubah kata sandi secara sembarangan (karena beberapa alasan), memaksa perubahan kata sandi memang membatasi waktu di mana kredensial yang dikompromikan dapat dengan mudah digunakan untuk melakukan push bombing.
- Tinjau konfigurasi MFA Anda untuk memastikan bahwa pola akses masuk akal. Solusi MFA terbaik sekalipun bisa saja mengonfigurasi untuk mengizinkan terlalu banyak akses dengan verifikasi terbatas.
- Praktik terbaik kata sandi yang masuk akal juga berlaku. Mendidik pengguna untuk menjelaskan mengapa mereka tidak boleh berbagi kata sandi antar layanan. Dengan begitu jika terjadi penyusupan, maka akan membatasi permukaan serangan untuk melakukan push bombing.
- Jika Anda terlalu mengandalkan otentikasi push atau untuk melindungi data yang terlalu sensitif, pertimbangkan untuk meningkatkan frekuensi permintaan kata sandi sekali pakai (OTP) menggunakan token lunak atau keras. Permintaan OTP akan terlihat oleh penyerang dalam skenario serangan dan tidak akan pernah sampai ke pengguna.
Untuk mendeteksi permintaan autentikasi push palsu secara terprogram, Anda mungkin memerlukan banyak hal agar berhasil. Log dari sistem autentikasi Anda harus diatur pada level yang tepat, dikirim ke pengumpul log yang tepat, diurai dengan benar, dan konten harus tersedia untuk menghasilkan peringatan yang sesuai. Dari sana, Pusat Operasi Keamanan (SOC) yang siaga 24/7 harus menerima dan mengenali peringatan ini dengan buku catatan terbaru tentang apa yang harus dilakukan selanjutnya. Ini tidak terdengar mudah, dan sebenarnya tidak. Berbagai alat dan mekanisme dapat mengurangi upaya yang diperlukan, tetapi poin utamanya adalah Anda perlu mengidentifikasi peristiwa log yang Anda pedulikan, mempertimbangkan ambang batas yang penting bagi Anda, dan mencari tahu tindakan apa yang perlu Anda lakukan saat mendapatkan peringatan dan memvalidasi seluruh proses.
Anda mungkin ingin mempertimbangkan untuk memiliki peringatan yang berarti untuk satu penolakan otorisasi push dan meredamnya jika hal itu menimbulkan terlalu banyak suara. Ingat, jika pengguna Anda terlatih dengan baik, mereka dapat memberi tahu Anda tentang suatu masalah dengan sangat cepat. Mereka bahkan mungkin lebih cepat daripada SIEM yang dapat mengurai log, mengeluarkan peringatan, dan SOC dapat mendeteksi serta meresponsnya. Selalu baik untuk memiliki rencana cadangan dan beberapa lapisan keamanan dan pemantauan.
Tinjau peristiwa log dan skenario bagaimana-jika berdasarkan serangan. Anda perlu memastikan bahwa Anda mengidentifikasi dan menerima data yang tepat. Periksa peristiwa log khusus untuk pengguna yang menolak permintaan push sebagai hal yang paling menarik. Hal lain yang menarik adalah permintaan autorisasi push yang diabaikan.
Ingatlah bahwa mendeteksi permintaan push yang buruk berarti Anda mungkin juga telah mendeteksi kompromi kredensial. Jadi, meskipun pengguna mengatakan "Tidak" pada permintaan push, Anda mungkin sudah memiliki risiko jika ada tempat di jaringan perusahaan Anda yang dapat diakses oleh kombinasi nama pengguna/kata sandi. Jika Anda memiliki deteksi untuk permintaan autentikasi push yang buruk, ini dapat berfungsi sebagai mekanisme deteksi untuk kredensial yang disusupi.
Pengguna RSA dapat melihat bagaimana ID Plus menggunakan autentikasi berbasis risiko dan fitur lainnya untuk mendeteksi dan bertahan dari serangan bom yang cepat.
Tanggapan yang tepat terhadap serangan bom-push bergantung pada ambang batas yang Anda rasa nyaman. Namun, bahkan dengan satu Push to Authenticate yang tidak terduga, seorang pengguna akan kehilangan sesi dan dipaksa untuk mengubah kata sandi mereka. Ingat, ini seharusnya merupakan kejadian yang jarang terjadi. Agar aman, jangan sampai menyesal. Mengubah kata sandi juga akan mencegah potensi serangan di masa depan dengan kredensial pengguna tertentu.
Meskipun kata sandi menunjukkan usianya, jika kata sandi merupakan bagian dari MFA di organisasi Anda, kembangkan dan dokumentasikan proses tepercaya untuk memaksa pengaturan ulang kata sandi dan dapatkan dukungan pimpinan untuk melakukan perubahan kata sandi dan pencabutan sesi pada setiap dugaan kompromi. Semakin lama penyerang memiliki akses di jaringan Anda, semakin banyak kerusakan yang dapat mereka lakukan. Pertimbangkan waktu respons. Dengan cepat dan proaktif menghubungi pengguna atau manajer mereka di saluran tepercaya jika Anda menerima peringatan dan menentukan mekanisme kontak yang tepat untuk organisasi Anda, seperti surat elektronik, untuk memberi tahu pengguna dan manajer mereka tentang apa yang terjadi dan membuat mereka waspada. Komunikasi sangat membantu dalam membangun kepercayaan yang akan memberikan keuntungan untuk masalah keamanan di masa depan.
Ingatlah bahwa push-bombing adalah salah satu jenis serangan, dan Anda harus memprioritaskan respons apa pun terhadapnya dalam keseluruhan program Anda yang terkait dengan kemungkinan dan risiko terhadap lingkungan Anda. Jika penyerang berhasil, Anda harus mengandalkan kontrol keamanan Anda yang lain untuk membatasi kerusakan dan memastikan bahwa Anda bisa cepat pulih.
