Pada tanggal 15 Maret 2022, Badan Keamanan Siber & Infrastruktur AS (CISA) merilis laporan waspada merinci sebuah Serangan siber Rusia terhadap sebuah lembaga swadaya masyarakat (LSM). Aktor ancaman merantai kata sandi yang lemah, akun pengguna yang tidak aktif, pengaturan default yang mengutamakan kenyamanan daripada keamanan, dan kerentanan sebelumnya di Windows. Hal ini memungkinkan mereka dengan "akses ke akun cloud dan email untuk exfiltrasi dokumen"Saya akan memberikan informasi yang benar."
Dalam Bagian 1 Pada seri ini, Arsitek Identitas Cloud Global RSA, Ingo Schubert, mengulas beberapa praktik terbaik yang telah dibagikan RSA kepada para pelanggan setelah serangan ini, membahas tujuan otentikasi multi-faktor (MFA), mendaftarkan pengguna ke dalam MFA, dan cara meminimalkan penggunaan kata sandi. Di bagian kedua dari seri ini, Ingo mengulas tentang pengaturan ulang autentikasi, pengamanan gagal, dan skenario lain yang dapat menyebabkan insiden keamanan.
Katakanlah Anda telah menyelesaikan pendaftaran. Selain itu, Anda telah mengikuti praktik terbaik kami dan membuat pendaftaran yang menghasilkan batas atas kepercayaan yang tinggi, sehingga pengguna dapat mengautentikasi dengan tingkat kepercayaan yang tinggi selama mereka menggunakan metode autentikasi tersebut.
Apakah pekerjaan kita sudah selesai? Jauh dari itu. Bagaimana dengan pengguna yang kehilangan atau salah meletakkan autentikator mereka? Bagaimana dengan pengguna yang mendapatkan ponsel pintar baru dan harus menginstal ulang aplikasinya?
Skenario ini akan terjadi, dan organisasi Anda harus siap menghadapinya dengan cara yang aman dan ramah pengguna.
Apakah itu terdengar familiar? Seharusnya. Organisasi Anda mungkin akan mengganti autentikator dengan cara yang menyerupai pendaftaran awal mereka. Pada setiap tahap, organisasi harus memastikan bahwa mereka tidak membuka diri terhadap serangan.
Jangan merusak kepercayaan yang telah Anda bangun selama pendaftaran saat mengganti autentikator. Ingat: mendaftarkan perangkat baru, mengganti perangkat yang sudah terdaftar, dan mengatur ulang autentikasi adalah beberapa momen favorit peretas dalam siklus identitas. Hal-hal tersebut menimbulkan tingkat perubahan yang lebih tinggi dari biasanya, dan akibatnya, merupakan beberapa contoh yang paling mungkin bagi penyerang untuk mendapatkan akses yang tidak sah.
Jangan biarkan mereka. Carilah yang modern otentikasi multi-faktor (MFA) yang dapat mengamankan momen-momen ini, menawarkan integrasi API ke dalam manajemen identitas dan akses (IAM) Anda, serta mengintegrasikan operasi helpdesk Anda di satu tempat.
Meskipun Anda melakukan segalanya dengan benar selama tahap pendaftaran dan jika Anda mengamankan penggantian autentikasi dan akses darurat, tanyakan pada diri Anda sendiri: apa gunanya semua itu jika Anda tidak menggunakan MFA di mana-mana atau jika penyerang dapat dengan mudah mematikannya dan melewatinya?
Menyelesaikan skenario pertama mudah: gunakan MFA di mana saja (setidaknya untuk pengguna yang tepat).
Agar berhasil melakukannya, solusi MFA Anda harus menyediakan berbagai metode dan antarmuka untuk memungkinkan pengguna melakukan autentikasi kapanpun dan bagaimanapun yang mereka sukai. Anda juga mungkin perlu memeriksa beberapa aplikasi lama dan dapat menyediakan antarmuka yang tepat dan memastikan bahwa aplikasi tersebut dapat menggunakan metode autentikasi baru, seperti tanpa kata sandi berbasis FIDO atau jika Anda terjebak dengan RADIUS yang lama.
Anggap saja Anda telah mengamankan semua aplikasi Anda dengan MFA. Anda juga perlu memastikan bahwa penyerang tidak dapat mematikan MFA. Dalam kasus yang baru-baru ini terjadi Peringatan CISA, LSM ini menggunakan solusi MFA yang memungkinkan pengguna untuk masuk tanpa MFA jika pengguna tidak dapat terhubung ke internet. Aktor ancaman mengeksploitasi hal tersebut - memungkinkan mereka untuk menonaktifkan MFA secara efektif hanya dengan mematikan koneksi ke internet.
Oleh karena itu, solusi MFA organisasi Anda harus aman dari kegagalan dan/atau memiliki mode failover-gagal offline yang memastikan MFA diberlakukan meskipun backend MFA (cloud atau lokal) tidak dapat dijangkau.
Saya memahami pemikiran tentang gagal buka: untuk menjaga bisnis tetap berjalan, lebih baik mengizinkan login hanya dengan kata sandi daripada mengunci semua orang.
Meskipun pilihan tersebut bisa dimengerti, namun hal ini membangun kerentanan yang signifikan pada postur keamanan Anda. Pendekatan yang lebih baik - dan lebih aman - adalah memastikan bahwa autentikasi yang kuat tetap berfungsi meskipun backend MFA tidak tersedia. Apakah backend MFA Anda berbasis cloud atau lokal tidak menjadi masalah: penyedia otentikasi harus menyediakan solusi offline yang dapat digunakan untuk keduanya.
Mengamankan autentikasi MFA offline adalah sesuatu yang sering kami temui. Biasanya, kami menyarankan bisnis untuk menyediakan berbagai metode autentikasi yang berbeda, tergantung pada apakah pengguna dalam keadaan online atau offline. Misalnya, jika notebook sedang online, maka login ke Microsoft Windows diamankan dengan menggunakan pemberitahuan push atau biometrik. Jika notebook sedang offline, Kata Sandi Sekali Pakai (OTP) diberlakukan.
Karena OTP tidak begitu ramah pengguna, dalam skenario ini kami mengorbankan beberapa kenyamanan untuk keamanan yang lebih baik. Dengan melakukan hal tersebut, memastikan bahwa tidak ada gagal buka dan penyerang tidak dapat mematikan MFA.
Perilaku aman dari kegagalan tidak hanya penting untuk PC Windows pengguna individu: perilaku ini juga harus diterapkan pada semua aplikasi di tempat Anda.
Bagaimana jika layanan cloud MFA yang Anda gunakan sedang offline? Itu bisa dan akan terjadi. Mungkin penyedia MFA mengalami pemadaman, mungkin koneksi internet Anda terputus. Mungkin penyerang memanipulasi layanan DNS Anda sedemikian rupa sehingga membuat layanan cloud MFA tampak offline: apa pun situasinya, merencanakan perilaku fail-safe/failover dapat membantu organisasi Anda mempertahankan kelangsungan bisnis dan keamanan bahkan ketika pengguna Anda tidak dapat terhubung ke internet.
A pengaturan MFA hibrida ketersediaan tinggi di tempat/cloud akan menghemat waktu. Biasanya aplikasi Anda akan berbicara dengan komponen MFA lokal, yang pada gilirannya akan meneruskan permintaan ke layanan cloud MFA. Jika cloud MFA tidak tersedia, maka semua aplikasi yang berbicara dengan komponen failover layanan MFA di lokasi akan tetap dapat mengautentikasi pengguna dengan kuat.
Seperti halnya skenario PC Windows, dalam kasus penggunaan ini, otentikasi offline akan dilakukan melalui OTP saja karena notifikasi push ke ponsel pintar pengguna tidak akan tersedia jika terjadi pemadaman internet. Jika ada pilihan untuk memberlakukan OTP jika terjadi pemadaman awan MFA atau default untuk gagal buka, maka saya akan memilih OTP 10 dari 10 kali.
Mengkonfigurasi MFA dengan benar sejak awal, memikirkan pendaftaran dan mengeliminasi MFA yang gagal terbuka adalah beberapa cara terbaik untuk mempersiapkan semua skenario ini.
Komponen penting lainnya adalah mengembangkan praktik tata kelola yang membantu tim keamanan Anda mendapatkan visibilitas ke dalam identitas di sepanjang siklus hidup mereka.
Tata Kelola & Siklus Hidup SecurID memastikan bahwa akun dan hak pengguna selalu diperbarui. Karena keputusan otorisasi-termasuk pendaftaran MFA-akan didasarkan pada data identitas, maka sangat penting untuk memastikan bahwa data ini dapat diandalkan.
Sesuatu yang belum saya singgung adalah Penilaian Kepercayaan Identitas: SecurID dapat mengevaluasi kepercayaan dalam transaksi MFA pengguna saat ini berdasarkan konteks saat ini dan perilaku mereka di masa lalu. Penilaian Kepercayaan Identitas adalah sesuatu yang telah kami lakukan selama hampir dua dekade. Hal ini menjadi bagian dari mesin risiko SecurID dan analisis berbasis risiko.
SecurID mendukung semua praktik terbaik ini: mulai dari mengamankan pendaftaran awal hingga mengatur ulang otentikasi hingga menerapkan otentikasi hibrida untuk mengelola tata kelola identitas, kami telah membangun pengalaman kami selama puluhan tahun dalam merancang solusi yang cerdas, sederhana, dan aman.
Baik saat Anda online maupun offline, baik saat Anda berada di prem maupun di cloud, ada cara agar Anda dan tim Anda tetap aman. Izinkan kami menunjukkan kepada Anda bagaimana.
