Pendahuluan

Di era digital saat ini, ancaman siber semakin sering terjadi dan bentuknya semakin beragam. Mulai dari phishing, malware, brute force login, ransomware, sampai pencurian data, semua itu bisa menyerang organisasi kapan saja. Karena itu, organisasi tidak cukup hanya memasang firewall atau antivirus. Mereka juga membutuhkan proses yang jelas untuk mendeteksi dan menangani insiden keamanan.

Salah satu tim yang memiliki peran penting dalam proses ini adalah SOC (Security Operations Center). Banyak orang mengenal SOC hanya sebagai tim yang memantau alert keamanan. Padahal, peran SOC jauh lebih besar dari itu. SOC adalah pihak yang menjadi garda terdepan dalam melihat, menganalisis, dan menentukan apakah suatu aktivitas mencurigakan benar-benar merupakan ancaman.

Namun, proses penanganan insiden tidak berhenti di SOC. Setelah alert diterima dan dianalisis, ada tahap penting berikutnya yaitu eskalasi ke tim incident handler agar ancaman tersebut dapat ditangani lebih dalam dan lebih teknis.

Artikel ini akan membahas secara sederhana alur penanganan insiden, mulai dari saat SOC menerima alert, melakukan triage, investigasi awal, menentukan severity, hingga akhirnya melakukan eskalasi ke tim incident handler.

Apa Itu SOC dan Mengapa Perannya Penting?

Apa itu SOC?

SOC (Security Operations Center) adalah tim atau fungsi keamanan yang bertugas untuk memantau, mendeteksi, menganalisis, dan merespons aktivitas keamanan di dalam lingkungan organisasi.

SOC biasanya bekerja menggunakan berbagai tools seperti:

• SIEM
• EDR
• IDS/IPS
• Firewall monitoring
• Email security
• Threat intelligence
• SOAR

Kalau disederhanakan, SOC bisa dianggap sebagai pusat pemantauan keamanan digital.

Kalau ada aktivitas yang mencurigakan, SOC adalah pihak yang pertama kali melihat dan menilai apakah itu ancaman atau bukan.

Tugas utama SOC

Beberapa tugas utama SOC antara lain:

• memantau alert keamanan,
• melakukan triage terhadap event yang masuk,
• menganalisis indikasi ancaman,
• menginvestigasi insiden awal,
• menentukan tingkat keparahan,
• dan melakukan eskalasi jika diperlukan.

Jadi, SOC bukan hanya “melihat dashboard”, tetapi juga mengambil keputusan awal yang sangat penting dalam proses penanganan insiden.

Apa Itu Alert dan Mengapa Tidak Semua Alert Adalah Insiden

Sebelum memahami alurnya, kita perlu paham dulu satu hal penting:

Tidak semua alert adalah insiden.

Apa itu alert?

Dalam konteks keamanan, alert adalah notifikasi atau peringatan yang muncul ketika sistem keamanan mendeteksi aktivitas yang dianggap tidak biasa, berisiko, atau melanggar aturan tertentu.

Contoh alert

Misalnya:

• login gagal berulang kali,
• file mencurigakan terdeteksi di endpoint,
• koneksi ke IP berbahaya,
• akun admin login di jam tidak biasa,
• banyak request dari satu alamat IP,
• akses ke file sensitif secara tidak normal.

Alert bisa berasal dari banyak sumber, seperti:

• SIEM
• EDR
• Firewall
• IDS/IPS
• Email gateway
• Cloud security tools
• Application logs

Mengapa tidak semua alert berbahaya?

Karena sistem keamanan sering kali dibuat sensitif agar tidak melewatkan ancaman. Akibatnya, banyak alert yang muncul belum tentu benar-benar berbahaya.

Beberapa kemungkinan dari sebuah alert adalah:

1. False Positive

Alert muncul, tetapi ternyata bukan ancaman nyata.

2. Benign Activity

Aktivitasnya tidak berbahaya, hanya terlihat aneh karena pola tertentu.

3. Suspicious Activity

Aktivitas mencurigakan dan perlu diperiksa lebih lanjut.

4. Confirmed Incident

Aktivitas terbukti merupakan insiden keamanan yang perlu ditangani.

Karena itulah, SOC tidak bisa langsung panik setiap ada alert. Mereka harus menilai dan memvalidasi dulu.

Tahap Pertama: SOC Menerima dan Memantau Alert

Alur penanganan insiden dimulai ketika alert masuk ke sistem pemantauan SOC.

Biasanya, alert akan muncul di dashboard monitoring dan terlihat berdasarkan:

• waktu kejadian,
• sumber alert,
• aset yang terdampak,
• tingkat severity,
• jenis ancaman.

Apa yang dilakukan SOC di tahap ini?

SOC analyst biasanya akan melihat beberapa hal dasar seperti:

• Alert berasal dari tool apa
• Severity awal dari sistem
• Aset mana yang terkena
• User atau akun mana yang terlibat
• Apakah alert ini pernah muncul sebelumnya
• Apakah ada pola yang sama dengan insiden sebelumnya

Contoh

Misalnya ada alert seperti:

• “Multiple failed login attempts detected”
• “Malicious file execution detected”
• “Suspicious PowerShell command executed”
• “Connection to known malicious domain”

Pada tahap ini, SOC belum langsung menyatakan “ini insiden”, tetapi mulai memberi perhatian awal.

Tahap Kedua: Triage Alert oleh SOC Analyst

Setelah alert diterima, langkah berikutnya adalah triage.

Apa itu triage?

Triage adalah proses awal untuk menilai apakah sebuah alert benar-benar perlu ditindaklanjuti lebih jauh atau tidak.

Kalau disederhanakan:

Triage adalah proses memilah alert mana yang penting dan mana yang tidak.

Triage sangat penting karena dalam lingkungan SOC, alert yang masuk bisa sangat banyak. Tanpa triage, tim bisa kewalahan dan justru kehilangan fokus terhadap ancaman yang benar-benar berbahaya.

Apa yang dilakukan saat triage?

SOC analyst biasanya akan melakukan hal-hal seperti:

• memeriksa detail alert,
• melihat log tambahan,
• mengecek IOC (Indicator of Compromise),
• melihat histori user atau host,
• melakukan korelasi dengan event lain,
• membandingkan dengan baseline aktivitas normal.

Contoh pertanyaan saat triage

SOC biasanya akan bertanya:

• Apakah alert ini masuk akal?
• Apakah ini aktivitas normal user?
• Apakah file atau IP yang terdeteksi memang berbahaya?
• Apakah ini hanya noise dari tool?
• Apakah ada indikasi aktivitas lanjutan?

Hasil triage biasanya berupa:

1. False Positive

Alert ditutup karena tidak relevan atau tidak berbahaya.

2. Benign / Normal Activity

Aktivitas dinilai normal dalam konteks tertentu.

3. Suspicious Event

Aktivitas mencurigakan dan perlu investigasi lebih lanjut.

4. Potential Incident

Alert cukup serius dan mengarah ke kemungkinan insiden nyata.

Di tahap ini, SOC mulai memutuskan apakah alert tersebut perlu masuk ke investigasi awal.

Tahap Ketiga: Investigasi Awal oleh Tim SOC

Kalau hasil triage menunjukkan bahwa alert itu valid atau mencurigakan, maka SOC akan masuk ke tahap investigasi awal.

Tujuan investigasi awal

Investigasi awal dilakukan untuk:

• memahami apa yang sedang terjadi,
• mengetahui konteks insiden,
• mengumpulkan bukti awal,
• dan menilai potensi dampaknya.

Kalau triage adalah “menyaring”, maka investigasi awal adalah “memahami”.

Apa yang biasanya diperiksa SOC?

1. Aktivitas endpoint

SOC bisa melihat:

• proses yang berjalan,
• file yang dibuat atau dijalankan,
• command line,
• persistence,
• perubahan registry (jika Windows),
• script mencurigakan.

2. Aktivitas login

SOC akan memeriksa:

• siapa yang login,
• dari mana asal login,
• kapan login terjadi,
• apakah ada login aneh,
• apakah ada brute force atau login sukses yang tidak biasa.

3. Koneksi jaringan

SOC juga bisa melihat:

• koneksi ke IP asing,
• komunikasi ke domain mencurigakan,
• transfer data yang tidak biasa,
• beaconing activity.

4. IOC

Indicator of Compromise seperti:

• IP address,
• domain,
• hash file,
• nama file,
• command,
• username,
• persistence artifact.

5. Hubungan antar event

Kadang satu alert tidak berdiri sendiri. SOC akan melihat apakah ada event lain yang berhubungan, misalnya:

• login mencurigakan,
• lalu file dijalankan,
• lalu koneksi keluar ke IP berbahaya.

Kalau pola ini terlihat, maka ancamannya menjadi lebih jelas.

Tahap Keempat: Klasifikasi dan Penentuan Severity

Setelah investigasi awal dilakukan, SOC perlu menentukan seberapa serius kejadian tersebut.

Mengapa severity penting?

Karena severity akan menentukan:

• seberapa cepat respons harus dilakukan,
• siapa yang harus dilibatkan,
• apakah perlu eskalasi segera,
• dan bagaimana prioritas penanganannya.

Kategori severity umum

Setiap organisasi bisa punya istilah berbeda, tetapi umumnya severity dibagi menjadi:

• Informational
• Low
• Medium
• High
• Critical

Faktor yang memengaruhi severity

SOC biasanya menilai severity berdasarkan:

1. Jenis ancaman

Contoh:

• malware aktif,
• credential theft,
• lateral movement,
• ransomware,
• data exfiltration.

2. Aset yang terdampak

Insiden pada:

• laptop user biasa
  akan berbeda dampaknya dengan insiden pada:
• domain controller,
• database pelanggan,
• server produksi,
• email admin.

3. User yang terdampak

Akun biasa tentu berbeda dengan:

• akun admin,
• akun service,
• akun privileged user.

4. Potensi dampak bisnis

Apakah insiden ini bisa:

• menghentikan layanan?
• membocorkan data?
• merusak reputasi?
• memengaruhi operasional bisnis?

Severity sangat penting karena akan menentukan apakah alert cukup ditangani di level SOC, atau harus segera di-escalate.

Kapan Alert Berubah Menjadi Insiden?

Ini adalah salah satu titik keputusan paling penting dalam alur SOC.

Karena sekali lagi:

tidak semua alert adalah insiden.

Lalu kapan sebuah alert dianggap sebagai insiden?

Sebuah alert biasanya berubah menjadi insiden jika:

• ada bukti kompromi,
• ada akses tidak sah,
• ada malware aktif,
• ada aktivitas command and control,
• ada penyalahgunaan akun,
• ada indikasi pergerakan lateral,
• ada dampak terhadap sistem atau data.

Contoh

Misalnya:

• ada login aneh saja → belum tentu insiden
• tapi jika login aneh itu diikuti:
  • eksekusi tool admin,
  • akses ke file sensitif,
  • koneksi ke IP jahat,

maka ini lebih kuat mengarah ke insiden keamanan nyata.

Pada tahap ini, SOC akan membuat keputusan penting:

Apakah alert ini ditutup, dimonitor, atau di-escalate sebagai insiden resmi?

Kalau hasilnya adalah insiden, maka proses akan masuk ke tahap dokumentasi dan eskalasi.

Tahap Kelima: Dokumentasi dan Pembuatan Ticket Insiden

Setelah sebuah alert dipastikan sebagai insiden, SOC harus mendokumentasikan hasil analisis awal.

Ini adalah tahap yang sangat penting karena hasil kerja SOC perlu diteruskan dengan jelas ke tim berikutnya.

Dan di sinilah system ticketing atau incident case management mulai berperan.

Mengapa perlu ticket?

Karena penanganan insiden harus:

• formal,
• terdokumentasi,
• punya owner,
• punya SLA,
• dan bisa ditelusuri kembali.

Tanpa ticket, proses penanganan akan sangat bergantung pada:

• chat,
• email,
• telepon,
• komunikasi informal,

yang rawan membuat informasi hilang atau tindak lanjut terlewat.

Isi ticket insiden yang ideal

Ticket yang dibuat SOC sebaiknya berisi informasi seperti:

• Incident ID
• Waktu deteksi
• Sumber alert
• Severity
• Affected asset
• Affected user/account
• Deskripsi singkat insiden
• IOC yang ditemukan
• Timeline singkat
• Analisis awal SOC
• Tindakan awal yang sudah dilakukan
• Rekomendasi eskalasi
• Tim tujuan eskalasi

Kalau ticket dibuat dengan baik, maka tim incident handler akan lebih cepat memahami situasi dan langsung bergerak.

Tahap Keenam: Eskalasi ke Tim Incident Handler

Setelah insiden tervalidasi dan ticket dibuat, langkah berikutnya adalah:

SOC melakukan eskalasi ke tim incident handler.

Ini adalah tahap inti yang menjembatani deteksi dan penanganan teknis.

Siapa itu incident handler?

Tim incident handler bisa berupa:

• Incident Response Team
• CSIRT / CIRT
• Blue Team
• Tim IR internal
• atau tim teknis tertentu seperti:
  • sysadmin,
  • network team,
  • endpoint team,
  • cloud team,
  • IAM team.

Tergantung struktur organisasi, eskalasi bisa dilakukan ke satu tim khusus atau ke beberapa tim sekaligus.

Kapan SOC harus melakukan eskalasi?

Biasanya eskalasi dilakukan ketika:

• ancaman sudah tervalidasi,
• perlu containment cepat,
• butuh tindakan teknis yang lebih dalam,
• butuh koordinasi lintas tim,
• atau dampaknya cukup serius.

Contoh

• akun admin dicurigai compromised → eskalasi ke IAM/IR
• malware aktif di endpoint → eskalasi ke endpoint/IR
• trafik command and control → eskalasi ke network security
• aktivitas aneh di cloud → eskalasi ke cloud security team

Di titik ini, SOC menyerahkan proses ke tim yang lebih fokus pada incident handling teknis.

Peran Tim Incident Handler Setelah Eskalasi

Setelah menerima ticket dan eskalasi dari SOC, tim incident handler mulai melakukan penanganan lebih mendalam.

Tugas utama incident handler

Secara umum, mereka akan fokus pada tiga hal utama:

1. Containment

Menghentikan atau membatasi dampak insiden agar tidak menyebar.

Contoh:

• mengisolasi endpoint,
• menonaktifkan akun,
• memblokir IP/domain,
• memutus koneksi sistem terdampak.

2. Eradication

Menghapus sumber ancaman dari lingkungan.

Contoh:

• menghapus malware,
• membersihkan persistence,
• menutup celah,
• menghapus akun atau artefak berbahaya.

3. Recovery

Mengembalikan sistem agar bisa beroperasi normal dengan aman.

Contoh:

• restore service,
• restore backup,
• re-enable access,
• validasi sistem aman kembali.

Dalam beberapa kasus, incident handler juga melakukan:

• forensic collection,
• root cause analysis,
• post-incident review.

Hubungan SOC dan Incident Handler: Bukan Lempar Kerja, Tapi Kolaborasi

Banyak orang mengira setelah insiden di-escalate, maka tugas SOC selesai.

Padahal, dalam praktik yang baik:

SOC dan incident handler harus tetap bekerja bersama.

SOC tetap memiliki peran penting setelah eskalasi, misalnya:

• memonitor apakah ada alert lanjutan,
• memberikan IOC tambahan,
• membantu korelasi event,
• memvalidasi apakah ancaman masih aktif,
• memberi enrichment tambahan ke tim incident handler.

Jadi, hubungan keduanya bukan “lempar kerjaan”, tetapi rantai kerja yang saling mendukung.

Kalimat sederhananya

• SOC = mendeteksi dan memahami ancaman awal
• Incident Handler = menangani ancaman secara teknis dan operasional

Kalau dua tim ini tidak sinkron, maka penanganan insiden bisa lambat atau tidak efektif.

Pentingnya Ticketing dan Dokumentasi dalam Alur Ini

Dalam alur penanganan insiden, salah satu elemen yang sangat penting tetapi sering diremehkan adalah dokumentasi.

Kenapa dokumentasi penting?

Karena setelah insiden terjadi, organisasi sering perlu menjawab pertanyaan seperti:

• kapan insiden terdeteksi?
• siapa yang pertama kali melihat?
• apa tindakan awal yang dilakukan?
• kapan eskalasi dilakukan?
• siapa yang menangani?
• apa remediation yang dilakukan?
• apakah SLA terpenuhi?

Kalau tidak ada ticketing yang baik, semua pertanyaan ini akan sulit dijawab.

Manfaat system ticketing dalam incident handling

Ticketing system membantu organisasi dalam hal:

• ownership jelas
• status penanganan bisa dipantau
• SLA bisa diukur
• audit trail lengkap
• mudah untuk RCA dan lesson learned
• lebih mudah untuk pelaporan dan compliance

Karena itu, ticketing bukan hanya alat administrasi, tetapi bagian penting dari governance incident response.

Tantangan yang Sering Dihadapi Tim SOC dalam Alur Ini

Meskipun alurnya terlihat rapi di atas kertas, dalam praktiknya banyak tantangan yang dihadapi tim SOC.

1. Alert Fatigue

Terlalu banyak alert bisa membuat analyst kelelahan dan kehilangan fokus.

2. False Positive Terlalu Banyak

Kalau tool terlalu sensitif, analyst bisa menghabiskan banyak waktu pada alert yang tidak berbahaya.

3. Kurangnya Konteks

Kadang alert muncul tanpa informasi yang cukup, sehingga investigasi jadi lambat.

4. Severity Tidak Konsisten

Kalau tidak ada standar yang jelas, satu analyst bisa menilai insiden sebagai medium, sementara analyst lain menilai high.

5. Keterlambatan Eskalasi

Kalau proses triage terlalu lama atau komunikasi buruk, insiden bisa terlambat ditangani.

6. Dokumentasi Lemah

Kalau analyst tidak disiplin mencatat hasil analisis, tim incident handler bisa kesulitan memahami konteks.

7. Koordinasi Antar Tim Kurang Baik

Kadang insiden membutuhkan banyak tim, dan tanpa workflow yang jelas, proses bisa tersendat.

Semua tantangan ini menunjukkan bahwa penanganan insiden bukan hanya soal tool, tetapi juga soal proses, kedisiplinan, dan koordinasi.

Praktik Baik agar Alur Penanganan Insiden Berjalan Efektif

Agar proses dari SOC ke incident handler berjalan baik, organisasi perlu menerapkan beberapa praktik yang sehat.

1. Miliki SOP Triage dan Eskalasi yang Jelas

SOC harus tahu:

• alert seperti apa yang cukup ditutup,
• alert seperti apa yang harus diinvestigasi,
• kapan harus di-escalate.

2. Gunakan Severity Matrix

Tentukan kriteria severity dengan jelas agar semua analyst menilai secara konsisten.

3. Integrasikan SOC dengan Ticketing System

Kalau memungkinkan, integrasikan alert prioritas tinggi dengan ticketing agar proses lebih cepat dan terdokumentasi.

4. Buat Playbook untuk Insiden Umum

Contohnya untuk:

• phishing,
• malware,
• brute force,
• suspicious login,
• ransomware.

Playbook membantu analyst bekerja lebih cepat dan seragam.

5. Tentukan Ownership

Setiap jenis insiden harus jelas siapa tim yang menerima eskalasi dan siapa yang bertanggung jawab.

6. Lakukan Review Berkala

Tinjau kembali insiden yang pernah terjadi untuk melihat:

• apa yang berjalan baik,
• apa yang lambat,
• apa yang perlu diperbaiki.

Dengan begitu, proses penanganan insiden bisa terus berkembang dan menjadi lebih matang.

Kesimpulan

Penanganan insiden keamanan tidak dimulai saat malware dihapus atau akun diblokir. Proses itu sebenarnya dimulai jauh lebih awal, yaitu saat SOC menerima alert.

Dari sana, SOC memiliki peran yang sangat penting dalam:

• memantau alert,
• melakukan triage,
• melakukan investigasi awal,
• menentukan severity,
• memvalidasi apakah suatu event benar-benar insiden,
• lalu mendokumentasikan dan mengeskalasinya ke tim incident handler.

Sementara itu, tim incident handler melanjutkan proses dengan:

• containment,
• eradication,
• recovery,
• dan analisis teknis yang lebih mendalam.

Karena itu, alur dari SOC → triage → investigasi → ticketing → incident handler adalah fondasi penting dalam keamanan organisasi.

Tanpa alur yang jelas, ancaman bisa terlambat ditangani, miskomunikasi bisa terjadi, dan insiden bisa berakhir tanpa pembelajaran yang berarti.

Sebaliknya, dengan proses yang rapi, organisasi akan lebih cepat, lebih terukur, dan lebih siap menghadapi ancaman siber yang terus berkembang.

Penutup

Memahami alur penanganan insiden bukan hanya penting bagi SOC analyst atau incident responder, tetapi juga penting bagi organisasi secara keseluruhan. Karena keamanan yang baik bukan hanya soal punya tool yang canggih, tetapi juga soal siapa yang melakukan apa, kapan harus bergerak, dan bagaimana semuanya terdokumentasi dengan baik. Dan di sinilah SOC serta incident handler memainkan peran yang saling melengkapi untuk menjaga keamanan organisasi.