Memahami Brute Force: Password Guessing vs Password Spraying

Kita lanjut lagi iseng buat tulisan dari pada puyeng dipendam di kepala sendiri. Kalau berbicara mengenai serangan Brute Force, sebagian besar orang mungkin menganggap semua bentuk serangan tersebut sama saja, yaitu mencoba login berulang kali sampai berhasil. Padahal jika mengacu pada framework MITRE ATT&CK, Brute Force memiliki beberapa sub-teknik dengan karakteristik yang berbeda.

 

Dua teknik yang paling sering ditemui adalah:

• Password Guessing (T1110.001)
• Password Spraying (T1110.003)

Sekilas memang terlihat mirip karena sama-sama mencoba menebak kata sandi. Namun, jika diperhatikan lebih dalam, pola serangannya justru berlawanan.

Password Guessing (T1110.001)

Password Guessing merupakan teknik di mana penyerang mencoba banyak kombinasi password terhadap satu atau beberapa akun tertentu.

Misalnya seorang attacker menargetkan akun admin, kemudian mencoba berbagai kemungkinan password seperti berikut:

admin
admin123
admin1234
password
administrator

Seluruh password tersebut dicoba ke akun yang sama sampai ada yang berhasil.

Karena satu akun menerima banyak percobaan login gagal dalam waktu singkat, teknik ini biasanya akan memicu mekanisme Account Lockout apabila sistem telah menerapkan kebijakan keamanan yang baik.

Teknik ini sering disebut sebagai serangan vertikal, karena fokusnya hanya pada satu akun tetapi dengan banyak variasi password.

Password Spraying (T1110.003)

Berbeda dengan Password Guessing, Password Spraying menggunakan pendekatan yang berkebalikan.

Pada teknik ini, penyerang hanya menggunakan satu password yang dianggap umum, kemudian mencobanya ke banyak akun yang berbeda.

Sebagai contoh, attacker menggunakan password:

Password123

Kemudian password tersebut dicoba ke banyak akun seperti:

andi
budi
rina
bedul

Mengapa cara ini dilakukan?

Karena sebagian besar sistem keamanan akan mengunci akun apabila terdapat banyak kegagalan login pada akun yang sama. Dengan mencoba satu password ke banyak akun, attacker berusaha menghindari mekanisme Account Lockout sehingga serangan dapat berlangsung lebih lama tanpa menimbulkan kecurigaan. Teknik ini dikenal sebagai serangan horizontal, karena satu password "disebarkan" ke banyak akun.

Apakah Firewall Bisa Membedakan Keduanya?

Inilah yang sering menjadi kesalahpahaman, terutama bagi analyst yang baru belajar SIEM.

Banyak orang mengira firewall atau IPS mampu menentukan apakah suatu serangan termasuk Password Guessing atau Password Spraying.

Padahal kenyataannya tidak demikian.

Firewall biasanya hanya mendeteksi bahwa telah terjadi aktivitas Brute Force atau Multiple Login Failure. Informasi tersebut memang sangat berguna sebagai indikator awal, tetapi belum cukup untuk menentukan sub-teknik MITRE ATT&CK yang digunakan oleh attacker.

Yang menentukan apakah serangan tersebut merupakan Password Guessing atau Password Spraying adalah analyst, berdasarkan pola aktivitas yang terlihat.

Sebagai contoh:

• Jika satu akun menerima ratusan percobaan password yang berbeda, maka besar kemungkinan itu adalah Password Guessing.
• Sebaliknya, jika satu password digunakan untuk mencoba login ke puluhan atau bahkan ratusan akun yang berbeda, maka pola tersebut lebih mengarah ke Password Spraying.

Dengan kata lain, firewall hanya memberikan petunjuk bahwa terjadi aktivitas Brute Force. Proses analisis tetap harus dilakukan oleh manusia.

Mengapa Label SIEM Tidak Selalu Benar?

Hal berikutnya yang sering membuat bingung analyst adalah ketika hasil korelasi dari SIEM ternyata tidak selalu sesuai dengan teknik MITRE ATT&CK yang sebenarnya.

Sebagai contoh, saya pernah menemukan kasus ketika FortiGate menghasilkan log IPS dengan signature:

Spring.Boot.Actuator.Unauthorized.Access

Namun setelah log tersebut diproses oleh FortiSIEM, incident yang muncul justru diberi label:

Privilege Escalation
T1548.004

Sekilas mungkin terlihat benar karena berasal dari sistem otomatis. Akan tetapi setelah dilakukan validasi menggunakan referensi MITRE ATT&CK, teknik yang lebih tepat sebenarnya adalah:

T1190
Exploit Public-Facing Application

Mengapa bisa berbeda? Karena label yang diberikan oleh SIEM hanyalah hasil korelasi berdasarkan rule yang telah dibuat sebelumnya. Rule tersebut memang membantu mempercepat proses deteksi, tetapi bukan berarti selalu benar dalam semua kondisi.

Oleh karena itu, seorang analyst tidak boleh langsung menerima hasil korelasi begitu saja. Raw log dari perangkat keamanan, signature vendor, konteks serangan, serta referensi MITRE ATT&CK tetap harus diperiksa sebelum menentukan klasifikasi akhir sebuah incident.

Anggap saja label dari SIEM adalah hipotesis awal, sedangkan keputusan akhirnya tetap berada di tangan analyst.

Cara Memberikan Nama Tiket yang Baik

Setelah mengetahui jenis serangan yang sebenarnya, langkah berikutnya adalah memberikan nama tiket secara konsisten.

Kesalahan yang cukup sering terjadi adalah menggunakan nama signature dari vendor sebagai judul tiket. Padahal setiap vendor memiliki format penamaan yang berbeda-beda.

Agar lebih mudah dipahami dan tetap konsisten, saya lebih menyarankan menggunakan taksonomi MITRE ATT&CK sebagai judul utama tiket, sedangkan informasi spesifik dari vendor disimpan sebagai informasi pendukung.

Sebagai contoh, apabila firewall berhasil memblokir exploit terhadap aplikasi web, maka tiket dapat diberi nama seperti berikut.

EVT | Initial Access: Exploit Public-Facing Application (T1190)
Source : 213.209.159.175
Target : 10.101.64.32
Outcome : Dropped

Sementara informasi seperti berikut cukup disimpan pada field tambahan di sistem ticketing:

• Vendor Signature
• SIEM Event Type
• Reporting Device
• FortiSIEM Incident ID

Dengan cara ini, judul tiket akan tetap konsisten meskipun log berasal dari FortiGate, Palo Alto, Cisco, Check Point, ataupun vendor lainnya.

Apabila kemudian diketahui bahwa exploit tersebut berhasil masuk ke server dan terdapat indikasi kompromi, maka statusnya berubah menjadi Incident.

Sebagai contoh:

INC | Initial Access: Exploit Public-Facing Application (T1190)

Host : 10.101.64.32
Status : Suspected Exposure

Selanjutnya, apabila analyst meminta administrator untuk memblokir alamat IP penyerang, maka aktivitas tersebut dapat dibuat sebagai Service Request, misalnya:

SR | Block Source IP

Object : 213.209.159.175
Reference : INC-65287

Dengan pendekatan seperti ini, judul tiket menjadi lebih rapi, mudah dipahami, serta tetap konsisten walaupun berasal dari berbagai jenis perangkat keamanan yang berbeda.

Yauda segitu dulu sharing singkatnya dan contoh IP yang ada itu fiktif belaka yah. 

Memahami Perbedaan Event, Incident, dan Service Request di Cyber Security

Menyambung tulisan terdahulu di https://rungga.blogspot.com/2015/03/whats-incident-problem-information.html

Jadi sekarang niatnya ingin lebih memperluas tulisan itu agar saya ga lupa dan siapa tahu bisa berguna suatu saat. Tulisan ini juga dibantu sama AI untuk dapat mempersingkat agar saya tidak terlalu panjang sampai berhalaman ^_^

Oke langsung mulai. Salah satu kesalahan yang paling sering saya temui ketika membangun Security Operation Center (SOC) adalah masih banyak yang menganggap semua alert dari SIEM harus dibuat menjadi tiket Incident.

Padahal kenyataannya tidak demikian. Kalau setiap alert langsung dijadikan Incident, jumlah tiket akan membengkak, analyst akan mengalami alert fatigue, dan tim justru akan kesulitan menemukan ancaman yang benar-benar berbahaya.

Nah, pada artikel ini kita akan membahas bagaimana cara membedakan Security Event, Security Incident, dan Service Request berdasarkan praktik terbaik IT Service Management (ITSM) serta implementasinya pada SOC menggunakan SIEM seperti FortiSIEM.

Di dunia IT Service Management (ITSM) atau lebih dikenal melalui framework ITIL dan ISO/IEC 20000, terdapat tiga proses yang sering kali terdengar mirip, padahal memiliki tujuan yang berbeda. Ketiga proses tersebut adalah Event Managemen, Incident Management dan Request Fulfillment.

Memahami perbedaannya merupakan fondasi utama sebelum membangun proses SOC yang baik. 

Jadi Event adalah setiap aktivitas atau kejadian yang berhasil dideteksi oleh suatu sistem dan memiliki arti bagi operasional layanan. Namun perlu dipahami bahwa tidak semua event berarti ada masalah.

Banyak event hanya bersifat informasional atau bahkan sudah berhasil ditangani secara otomatis oleh perangkat keamanan. Karena itulah mayoritas Event tidak perlu dibuat tiket. Event cukup dicatat, dipantau, atau digunakan sebagai data analisis.

Event baru akan naik status apabila membutuhkan tindakan lebih lanjut. Sebagai contoh:

• Disk server mencapai utilisasi 80% tetapi layanan masih berjalan normal.
• Firewall berhasil menolak satu percobaan brute force.
• IPS mendeteksi exploit kemudian langsung melakukan action Dropped.
• Backup sempat gagal sekali tetapi retry berikutnya berhasil.

Semua contoh tersebut masih termasuk Event, bukan Incident.

Oke sudah mulai terbayang dan puyeng? Janganlah mari kita lanjut lagi (ini gaya saya bukan AI loh). Berbeda dengan Event, Incident adalah kondisi ketika terjadi gangguan terhadap layanan atau terdapat indikasi kompromi yang harus segera ditangani.

Fokus utama Incident Management adalah memulihkan kondisi secepat mungkin serta melakukan investigasi penyebabnya.

Contohnya antara lain:

• Database server mati sehingga aplikasi tidak dapat diakses.
• Akun administrator berhasil diambil alih oleh attacker.
• Malware berhasil masuk ke endpoint.
• Firewall gagal memblokir exploit dan terdapat indikasi host telah terkompromi.

Pada kondisi inilah SOC akan membuat Security Incident Ticket agar proses investigasi dan penanganan dapat dilakukan secara terstruktur.

Kita lanjut lagi ke penjelasan yang terakhir. Berbeda lagi dengan Incident, Service Request merupakan permintaan layanan yang bersifat rutin, standar, dan memiliki risiko rendah.

Service Request bukan muncul karena adanya gangguan, melainkan karena pengguna atau administrator membutuhkan tindakan tertentu.

Contohnya:

• Membuat akun email untuk karyawan baru.
• Menambah kapasitas storage sebesar 100 GB.
• Membuka port firewall sesuai prosedur.
• Melakukan whitelist aplikasi tertentu.
• Memblokir IP Address yang telah dipastikan berbahaya.

Semua aktivitas tersebut merupakan pekerjaan operasional yang telah memiliki prosedur baku.

Oke di bawah ini saya kasih contoh nyata biar tambah lieur yah (hahahaaa):

Situasi	Kategori	Alasan
Disk server mencapai 80%	Event	Baru berupa peringatan, layanan masih normal
Database server mati	Incident	Layanan terganggu
Membuat akun email	Service Request	Permintaan standar
Backup gagal namun retry berhasil	Event	Sudah pulih otomatis
Menambah kapasitas storage	Service Request	Permintaan terencana

 

Ini dia yang menarik bahwa di SOC, perbedaan ketiga istilah ini jauh lebih penting. Misalnya terdapat satu percobaan brute force ke server. Firewall langsung mendeteksi aktivitas tersebut kemudian melakukan aksi Deny.

Apakah ini Incident?

Jawabannya belum tentu.

Selama firewall berhasil menghentikan serangan dan tidak ada dampak terhadap sistem, maka kondisi tersebut masih dikategorikan sebagai Security Event.

Contoh lain nih ye biar makin paham, IPS mendeteksi exploit terhadap aplikasi web kemudian melakukan action Dropped. Artinya exploit memang terjadi, tetapi berhasil dihentikan sebelum mencapai server.

Kondisi ini juga masih termasuk Security Event.

Sebaliknya, apabila brute force berhasil memperoleh akses ke akun administrator, atau exploit berhasil dijalankan sehingga server mengalami kompromi, maka statusnya berubah menjadi Security Incident.

Di sinilah analyst harus melakukan investigasi lebih lanjut sampai dia puyeng dah dan nenggak espresso sampai berapa shot dah, hahahaa.

 

Lanjut dlu deh dan biasanya nemuin pertanyaan begini "Pak/Mas gimana nih dengan serangan yang masif????". Misalnya terdapat ribuan serangan dari satu alamat IP.

Apakah otomatis menjadi Incident?

Jawabannya tidak selalu.

Serangan masif sebenarnya hanyalah kumpulan dari banyak Security Event. Selama seluruh serangan berhasil diblokir oleh Firewall atau IPS, maka belum tentu menjadi Incident.

Namun apabila terdapat indikasi bahwa sebagian serangan berhasil menembus pertahanan atau menyebabkan dampak terhadap layanan, maka statusnya berubah menjadi Security Incident.

Perbedaan utamanya selalu sama:

Apakah sudah ada dampak atau indikasi kompromi?

Jika jawabannya belum, maka masih berupa Event.

Jika jawabannya ya, maka menjadi Incident.

 

Gimana mulai cerah atau gelap? Kalau gelap kabur aja dlu tapi itu mah kata politikus yang nyinyir dan nye nye nye. Padahal itu hak setiap orang mau pergi atau tetap tinggal dan yang terpenting mah tetap cinta tanah air. Wuuuussshhh fokus jangan nyerempet nanti dicubit bapak itu.

 

Lalu Bagaimana dengan Permintaan Memblokir IP?

Misalnya si analyst menemukan satu IP Address yang terus melakukan scanning dan brute force. Administrator kemudian meminta agar IP tersebut diblokir permanen pada firewall.

Apakah ini Incident?

Jawabannya bukan.

Aktivitas tersebut merupakan Service Request, karena yang diminta hanyalah tindakan operasional standar berupa pemblokiran IP. Namun apabila pemblokiran dilakukan sebagai bagian dari proses containment sebuah Incident yang sedang berlangsung, maka aktivitas tersebut menjadi task di dalam Incident, bukan Service Request yang berdiri sendiri.

Begini agar lebih mudah diingat, berikut aturan sederhana yang banyak digunakan pada SOC modern.

Security Event:

• Aktivitas berhasil dideteksi.
• Firewall atau IPS berhasil melakukan deny, drop, atau block.
• Tidak ada dampak terhadap sistem.
• Tidak membutuhkan investigasi lanjutan.

Biasanya hanya disimpan di SIEM dan tidak dibuat tiket.

Security Incident

• Ada indikasi kompromi.
• Ada dampak terhadap layanan.
• Mitigasi belum pasti berhasil.
• Membutuhkan investigasi analyst.

Pada kondisi ini dibuat Incident Ticket.

Service Request

• Aktivitas operasional rutin.
• Telah memiliki prosedur baku.
• Risiko rendah.
• Memerlukan tindakan administrator.

Contohnya:

• Block IP
• Whitelist
• Membuka port firewall
• Onboarding log source
• SIEM Rule Tuning

 

Segitu dulu ya bray tulisan ini dan jika banyak kesalahan, dimaklumin saja karena seorang Newbie kaya saya yah masih butuh belajar lebih lanjut.

Terima kasih kepada para pengunjung baik yang membaca atau cuman numpang lewat. Semoga bisa jadi amal jariyah saya. 

Apa yang harus dilakukan negara ketika datanya sudah bocor dimana-mana?

Mungkin bagi semua orang data negara yang bocor belakangan ini membuat panik sebagian orang, tapi kita harus menyikapi dengan santai. Saya pribadi sangat santai menyikapi karena semua itu sudah terjadi dan siapa yang berani menuntut sebuah negara disitu?

Data apa yang belum bocor? Jangan bingung untuk mencarinya karena nanti sulit ketemu.

Dari pemberitaan yang sudah heboh hampir beberapa tahun, pada intinya tidak ada "root cause" dari insiden keamanan informasi yang dipaparkan ke masyarakat. Lantas buat apa kita pusing dan panik? Pengolah datanya saja seperti kurang belajar dari hal yang pernah terjadi di tempat lain dan akhirnya terjadi lagi.

Solusinya harus seperti apa jika semua sudah terjadi? Coba masyarakat mulai peduli terhadap datanya sendiri baik dari sisi logic maupun physical.

Memang sebagian masyarakat menilai kurang seriusnya melakukan pengamanan dan hanya sebatas ceremony dan gagahan jika sudah dicap dapat ini itu.

Ide gila saya adalah merubah semua data (sampai metadata) itu meskipun akan memakan waktu panjang dan migrasi model data dari yang sudah bocor menjadi sebuah data baru. Jika sulit, anggap saja data yang telah bocor menjadi sebuah data/informasi publik dan bukan rahasia. Jangan terlalu dipaksakan membuat data yang bocor tetap menjadi sebuah rahasia karena itu percuma menurut sudut pandang saya pribadi.

Lantas negara itu harus melakukan apa? Rombak sumber daya (people, products, dan partners) serta proses semua harus dibenahi. Siapkan rumah yang mumpuni yang dimana nanti ada pengelolaan data dan informasi di dalam rumah tersebut. Buat bentuk desain, tata kelola dan standar untuk masuk ke rumah tersebut akan seperti apa. Ingat tidak bisa langsung loncat langsung mengamankan isi data di rumahnya.

Ingat harus ada pondasi desain, tata kelola dan standar terkait keamanan informasi (mencakup siber dan privasi). Coba perhatikan negara berkembang bagaimana mereka menerbitkan semua itu dan pahami pola rilis masing-masing dokumen tersebut.

Terkadang pola pikir Threat Actor lebih maju karena mereka harus "out of the box thinking" sedangkan pengelola data hanya berpikir sesuai proses bisnis dan terlalu keseringan menggunakan konsep yang ada di User Acceptance Test (UAT).

Kemudian langkah apalagi yang harus dilakukan? Ada rahasia yang harus dibuka biar Threat Actor baca, yaitu seperti konsep memberikan tanda pada uang atau emas. Tanda itu bisa digunakan untuk sistem yang ada di negara tersebut. Bahkan menggunakan konsep Blockchain sepertinya menarik untuk pengelolaan data. Jangan cuman dibuat National Data Centers, tapi coba terapkan semacam Blockchain Hybrid atau Blockchain Konsorsium. Metode itu bisa dikombinasikan dengan "Zero Trust for Next Generation". Bisa saja bekerjasama dengan Multi Region dan dampaknya adalah tingkatan data tidak lagi bisa dianggap rahasia dan tinggal menyepakati dengan negara lain akan seperti apa.

Ide gila "Blockchain for Multi Region + Zero Trust for Next Generation" semoga bisa terjadi disuatu saat untuk negara itu.