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. 

Read More

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. 

Read More

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.

Read More

Catatan Kecil untuk Debian Kecil

Catatan kecil aplikasi khusus yang ada di Debian dalam pekerjaan pengujian walaupun bisa saja setiap orang berbeda-beda. Berikut ini agar mudah diingat dan bisa dikembangkan kembali sesuai kebutuhan masing-masing:

$ sudo apt update 

$ sudo apt install snapd

$ sudo snap install core 

$ sudo snap install nmap 

$ sudo snap install sqlmap 

$ sudo snap install metasploit-framework 

$ sudo snap install crackmapexec 

$ sudo apt install python3

$ sudo snap install john-the-ripper

$ sudo apt-get -y install dirb

$ sudo snap install dnslookup

$ sudo apt install dnsenum 

$ sudo apt install dnsrecon  

$ sudo snap install sliver

$ sudo apt-get -y install fierce 

$ git clone https://github.com/m4ll0k/Atlas.git 

$ sudo apt-get -y install humanfriendly 

$ sudo snap install amass

Read More

Sedikit Membahas ISO/IEC 27001:2022 dan 27002:2022

Akhirnya ada keinginan untuk menulis kembali walau sebenarnya sedikit malas gerak. Jadi sebenarnya tulisan ini akan sedikit membahas tentang ISO/IEC 27001 dan 27002 versi 2022, walaupun saat ini sudah 2023 dan sedikit terlambat. Tidak ada salahnya tetap membahas secara umum karena melihat perkembangan di dunia Cybersecurity khususnya bidang ISO banyak beberapa yang masih melihat bahwa itu hanya sekedar Sistem Manajemen belaka saja.

Sebenarnya dari versi terdahulu saya juga kurang menyukai jika ada segelintir pihak yang memandang Standar tersebut hanya memfokuskan ke aspek Manajemen. Ini pemikiran keliru bahwa mungkin ada beberapa Auditor Badan Sertifikasi serta teman-teman lainnya yang dahulu melihat "Kriptografi" ya sebatas itu dan melihat dari sisi aliran data yang harus di kripto atau enkrip. Memang hal itu tidak salah, tapi menurut saya pribadi masih ada yang kurang.

Dari situlah saya sempat berdiskusi dengan beberapa teman bahwa kenapa penerapan Kriptografi itu diperluas. Misalkan pada data Password yang disimpan di database, itu juga perlu dilihat penerapannya seperti apa. Jika hanya sebatas "Hash", maka sangat tidak dianjurkan dan lebih direkomendasikan menggunakan model Kriptografi secara baik atau memakai Enkripsi.

Kemudian ada juga terkait file di aplikasi seperti "Config, Configuration dan sejenisnya" yang mana biasanya file tersebut menghubungkan antara aplikasi ke database engine. Banyak yang kurang peduli terhadap hal tersebut, padahal ada risiko yang melekat jika server aplikasi telah diambil alih oleh Attacker dan Attacker dapat membaca informasi yang ada di file tersebut untuk loncat ke server database. Apalagi celakanya banyak database yang jalan dengan tingkatan "root, sa, administrator" atau high privilege. Andaikata informasi yang ada di file tersebut, seperti username dan password tidak bersifat plaintext atau menerapkan Kriptografi, maka saya pikir akan sedikit menurunkan risiko atau membuat Attacker bekerja lebih maksimal lagi untuk mengambil alih server database, walau banyak proses yang harus dilakukan penjagaan secara baik.

Memang jadinya jika diperketat, beberapa pihak akan merasa dibebankan dan menjadi tidak nyaman. Ini yang saya dan teman-teman selalu memberikan edukasi kepada semua pihak, jika berbicara Cybersecurity dan sejenisnya, jangan mempunyai tingkat toleransi yang rendah. Mungkin banyak "Oknum" yang hanya sekedar ingin mendapatkan Sertifikasi dan jika berpikir seperti itu, maka saya dapat katakan sama saja menjadi orang bodoh yang mana sebenarnya sudah ada arahan secara jelas dari Standar ISO dan kurang membedah lebih dalam. (Maaf jika menggunakan kata bodoh).

Jadi ketika ruang lingkupnya adalah sebuah layanan yang didukung oleh sebuah sistem, mau tidak mau harus dipaksa menerapkan seperti Firewall (internal & eksternal), Web Application Firewall (jika aplikasi berbasiskan web), Privilege Access Management, Endpoint Detection and Response (EDR) atau AntiVirus yang sedikit pintar bahkan jika ingin menonaktifkan harus menggunakan credentials, menerapkan segmentasi yang berbeda antara workstation dengan server, pembatasan Teleworking (SSH, Remote Desktop, dll), bahkan port yang dibuka harus dibatasi dan tidak ditoleransi port seperti Telnet, FTP, http dan sejenisnya bersifat aktif atau open.

Ada beberapa hal yang patut diperhitungkan lainnya seperti File Sharing dan ini sering kali menjadi ajang penyebaran Ransomware, Malware dan sejenisnya. Jika tidak mau terdampak dari insiden Cybersecurity maka setidaknya fitur tersebut tidak digunakan. Jika mau dipaksa digunakan, pertimbangkan dari sisi risiko yang mungkin terjadi di kemudian harinya.

Tulisan di atas masih pembuka dan intinya saya mencoba mengatakan bahwa dari versi sebelumnya juga sudah membahas detil terkait "Teknologi", tapi dari beberapa pihak untuk menangkap hal tersebut yang masih lemah. Pada akhirnya sekarang terbukti di versi 2022 terdapat kategori khusus "Teknologi" walau dibeberapa kalimat menurut saya masih kurang tegas dan masih ada beberapa Annex yang saya masih kurang sreg masuk ke dalam sebuah kategori Teknologi. Sebagai contoh Threat Intelligence yang masuk ke kategori kontrol "Organizational", walau saya berpikir lebih cocok masuk ke "Teknologi" karena sangat sulit melakukan hal itu tanpa bantuan Teknologi. Memang ini bahasa yang halus dari ISO bahwa bisa jadi "Organziational" itu mirip maknanya dengan "Process". Jadi disiapkan mekanismenya melalui sebuah proses dan tidak memaksa ke arah Teknologi. Jika seperti itu, saya sangat merasa tidak akan efektif penerapan dari Threat Intelligence. Bisa saja saya membantah bahwa seperti "Annex 8.3 Information Access Restriction" jangan masuk ke kategori Teknologi tapi ke Organziational. Akan tetapi kita ikuti saja versi yang sudah terbit ini dan saya mulai menangkap pola pikir para perumus ISO tersebut.

Saya disini tidak akan membahas perubahan Clause, karena bagi saya arahnya sudah ketebak. Jika pembaca melihat ISO/IEC 20000-1:2018 dan ISO 22301:2019, akan terlihat pola dan strukturnya yang sekarang mulai menyeragamkan. Tujuan utama selain menyeragamkan adalah untuk memudahkan ketika ingin melakukan integrasi dengan standar ISO lainnya. Di ISO/IEC 27001 versi 2022 juga akan ada sudut pandang yang sedikit berubah terkait pengelolaan risiko (risk management), walaupun di awal saya katakan tidak tertulis secara jelas. Hal apa itu? Jadi sekarang diusahakan ketika identifikasi risiko, tidak perlu lagi menuliskan risiko positif ke dalam daftar risiko (risk register). Ketika berbicara Cybersecurity, cobalah memfokuskan ke Risiko yang negatif dan jangan membuang tenaga untuk mendaftarkan risiko positif. Saat ini dari tiket insiden Cybersecurity juga bisa naik level menjadi sebuah risiko, tapi perlu dikaji lebih dalam lagi. Ini yang saya senang sebenarnya dan apalagi dari hasil Vulnerability Assessment (VA), Penetration Test (Pentest), itu bisa diintegrasikan ke dalam proses pengelolaan risiko (Risk Management). Mungkin dari dahulu ketika saya berbicara bahwa hasil VA atau Pentest bisa masuk ke Risk Register, beberapa pihak bingung atau berkata dalam hati "ah masa begitu". Sekarang alhamdulillah terbukti bahwa itu hal yang benar. Jadi temuan dari VA atau Pentest itu tidak bisa langsung dikatakan sebuah Risiko tapi perlu dikaji lagi dan saya lebih senang bahwa temuan tersebut hanya baru terlihat dari sisi "dampak (impact)", dan jika tidak percaya coba bedah CVSS. Mereka hanya melihat ke Confidentiality, Integrity dan Availability yang notabennya adalah sebuah Impact. Oh ya apalagi jika hasil temuan masih menggunakan Likelihood X Impact, ini juga masih menjadi ambigu bagi saya pribadi. Namun saya membebaskan pihak lain dalam menerapkan sebuah ilmu itu seperti apa dan wajar jika mempunyai beberapa pemikiran yang berbeda. Saya sangat senang jika alurnya seperti ini: "Vulnerability --> Threat --> Risk".

Wah sudah terlalu panjang basa basinya dan coba kita lihat Annex 8.28 Secure coding:

Control:
Secure coding principles should be applied to software development.

Purpose:
To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.

Other information:

...

Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality.

Dari contoh di atas, Annex tersebut masuk ke kategori Teknologi walaupun sebenarnya bisa saja untuk memitigasi tidak memerlukan sebuah Teknologi. Bisa di awali dengan secure coding yang baik, tapi disini saya sudah senang bahwa ISO sekarang lebih melek dan mau terbuka ke standar di luar ISO lainnya (bisa dilihat di bab "Bibliography"). Mungkin bahasa Teknologi dimaksud tidak melekat kesebuah Produk tertentu walau masih bingung saya.

Duh ternyata kejauhan langsung loncat, mungkin karena terlalu semangat. Coba kita balik lagi ke awal ISO/IEC 27002:2022:

Information security, cybersecurity and privacy protection — Information security controls

1 Scope:
This document provides a reference set of generic information security controls including implementation guidance.

^Jadi sekarang menyebutnya "this document" bukan seperti yg lalu "this internasional standard". Kemudian dokumen ini ada kontrol keamanan informasi secara generik termasuk petunjuk implementasi walau sifatnya umum. Ini memang saya acungkan jempol terkait penggunaan tata bahasa yang sangat berhati-hati. Kemudian adalagi seperti:

b) for implementing information security controls based on internationally recognized best practices.

^Jadi ketika menerapkan kontrol keamanan informasi yang ada di Annex, itu bisa berdasarkan best practice di luar sana secara internasional. ISO tidak memberikan best practice -nya seperti apa. Duh bisa banget bahasa mereka yang tidak mau menjadi boomerang di kemudian hari.

Sebenarnya masih banyak yang bisa diulas, namun saya malas menuangkan semuanya. Lebih asik kita kopdar dan membahas secara santai.

Mohon maaf jika ada kesalahan dalam penulisan di atas.

Read More

Cara install Kali Linux di M1

Pada postingan ini akan membahas bagaimana kita install Kali Linux di M1 dengan menggunakan aplikasi UTM (dapat diunduh di https://github.com/utmapp/UTM/releases/latest/download/UTM.dmg). Aplikasi UTM ini sebagai alternatif yang tidak perlu mengeluarkan uang ^_^

Di aplikasi tersebut juga jika melihat menu gallery maka terdapat beberapa contoh sistem operasi yang dapat digunakan. Berikut ini contohnya:

Kemudian jika aplikasi UTM telah diinstal di M1 anda, maka langkah selanjutnya adalah membaca keterangan isu di url https://github.com/utmapp/UTM/issues/2607. Dari situ ada yang menjelaskan solusinya, yaitu dengan cara mengunduh file QEMU Efi (https://github.com/utmapp/UTM/files/6668347/QEMU.EFI.for.AARCH64.zip). Berikut ini kutipan dari link tersebut:

EFI_Code-AARCH64.img contains the same UEFI BIOS that is included with UTM, but in an uncompressed image. This is required for the EFI size to match what QEMU expects. EFI_VARS.img is the same size (64k x 1024) and contains zeroes (nothing).

Langkah berikutnya, pastikan anda telah download file untuk installer Kali Linux tersebut (bebas mau installer atau yang langsung live). Kemudian ekstrak file QEMU.EFI.for.AARCH64.zip dan nanti import kedua file tersebut dan jadikan interface: PC System Flash. Berikut ini langkah cepat yang sudah di screenshot walau tidak semua ditampilkan pada saat install kali linux nya:

 

 

Harap pilih yang "Install" untuk gambar di atas.

Sesuaikan dengan keinginan anda. Jika saya seperti biasa ada ext4 dan swap, kemudian lanjutkan seperti biasa.

Oh ya untuk Architecture saya menggunakan ARM64 dan QEMU 7.0 ARM Virtual Machine. Sekian tulisan yang tidak berbobot ini dan sangat tergesa-gesa karena memang tidak niat untuk menulis ^_^

 

Sumber:

https://github.com/utmapp/UTM/issues/2607

http://mirror.labkom.id/kali-images/current/

https://cdimage.kali.org/kali-images/kali-weekly/

 

Read More