Jumat, 17 Juli 2026

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):

SituasiKategoriAlasan
Disk server mencapai 80%EventBaru berupa peringatan, layanan masih normal
Database server matiIncidentLayanan terganggu
Membuat akun emailService RequestPermintaan standar
Backup gagal namun retry berhasilEventSudah pulih otomatis
Menambah kapasitas storageService RequestPermintaan 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. 

Jumat, 16 Agustus 2024

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.

Jumat, 03 November 2023

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