Bagaimana Cara Saya Menjelaskan Temuan Saya dalam Briefing SOC?

Keterampilan teknis memberikan Anda analisisnya. Komunikasi membuat Anda dipercaya, didanai, dan dipekerjakan. Analis yang bisa menjelaskan apa yang terjadi, mengapa hal itu penting, dan apa yang harus dilakukan selanjutnya secara konsisten mengungguli rekan kerja yang memiliki pengetahuan alat yang lebih dalam tetapi tidak bisa menyampaikan pesannya.

Menyusun briefing insiden

Gunakan piramida terbalik: mulai dengan kesimpulannya, kemudian dukung dengan bukti. Manager atau on-call lead yang datang ke briefing Anda membutuhkan jawaban untuk "apakah kami dikompromikan dan apakah saya perlu bertindak" dalam sepuluh detik pertama, bukan tersembunyi dalam detail packet capture di menit keenam.

Struktur yang dapat digunakan:

1. Apa yang terjadi — satu kalimat. "Sebuah workstation di keuangan menjalankan macro berbahaya dan beacon ke IP eksternal."
2. Dampak sejauh ini — ruang lingkup, sistem yang terpengaruh, data yang disentuh atau tidak disentuh.
3. Apa yang telah kami lakukan — isolasi, pemblokiran, langkah containment yang sudah diambil.
4. Apa yang kami butuhkan — keputusan, sumber daya, atau persetujuan dari ruangan.
5. Timeline — daftar kronologis singkat untuk siapa saja yang menginginkan detail, dipisahkan dari headline.

Hindari menceritakan proses investigasi Anda ("pertama saya memeriksa konsol EDR, kemudian saya pivot ke DNS logs") kecuali seseorang secara khusus bertanya bagaimana Anda sampai ke sana. Itu metode Anda, bukan masalah mereka. Simpan untuk laporan tertulis atau follow-up SME.

Menulis handover yang tidak kehilangan konteks

Shift handover gagal karena satu alasan lebih dari yang lain: analis yang keluar menganggap yang masuk ingat konteks yang hanya ada di kepala mereka. Tulis handover seolah-olah pembaca tidak punya memori tentang shift tersebut.

Nota handover yang baik mencakup:

• ID tiket/kasus dan status saat ini (terbuka, monitoring, menunggu respons)
• Apa yang memicu investigasi
• Apa yang telah dikonfirmasi vs. masih hipotesis
• Tindakan spesifik berikutnya dan siapa yang memilikinya
• Pemblokir apa pun (menunggu perubahan firewall, menunggu panggilan balik pengguna)

Contoh baris handover yang lemah: "Melihat alert di HOST-2231, tampaknya mencurigakan, akan diperiksa besok."

Contoh yang kuat: "HOST-2231 memicu Sigma rule untuk akses LSASS oleh binary yang tidak ditandatangani (proc: update.exe, hash: 3f2c...). Dikonfirmasi dengan EDR bahwa tidak ada memory dump yang terjadi. Pengguna keluar sampai jam 9 pagi — belum ada interview. Langkah berikutnya: tarik prefetch dan sched task artifacts, eskalasi ke IR jika binary cocok dengan varian Mimikatz yang dikenal."

Versi kedua memungkinkan analis berikutnya untuk bertindak segera tanpa mengulang pekerjaan Anda.

Pertanyaan skenario interview: apa yang sebenarnya mereka uji

Ketika pewawancara mengatakan "jelaskan bagaimana Anda akan menyelidiki alert phishing," mereka tidak menilai apakah Anda tahu nama alat yang benar. Mereka memeriksa apakah Anda memiliki proses yang dapat diulang dan apakah Anda dapat menceritakan alasan Anda dengan keras di bawah tekanan ringan — yang persis apa yang diperlukan shift nyata.

Struktur jawaban Anda dengan cara Anda akan menyusun insiden itu sendiri:

• Nyatakan prioritas triage Anda terlebih dahulu (apakah ini terisolasi, apakah ini menyebar, apakah ini kandidat false positive)
• Sebutkan artifact spesifik yang akan Anda tarik (email headers, sender reputation, URL sandbox detonation, mailbox rules changes)
• Katakan apa yang akan mengubah langkah berikutnya ("jika sandbox detonation menunjukkan halaman credential harvesting, saya akan segera memeriksa berhasil auth dari pengguna itu dalam 24 jam terakhir")
• Tutup dengan kriteria eskalasi — apa yang membuat Anda menyebut ini insiden yang dikonfirmasi versus menutupnya sebagai benign

Pewawancara memperhatikan ketika kandidat berbicara dalam absolut tanpa logika branching. Investigasi nyata bersyarat: "jika X, maka Y; jika tidak, maka Z." Menunjukkan branching itu lebih berharga daripada menyebutkan setiap sumber log yang pernah Anda dengar.

Menerjemahkan untuk stakeholder non-teknis

CFO tidak perlu mendengar "lateral movement via pass-the-hash targeting domain controller." Mereka membutuhkan "penyerang menggunakan kredensial yang dicuri untuk mencoba menjangkau sistem yang mengontrol akses untuk seluruh perusahaan; kami memblokir sebelum berhasil." Simpan versi teknis tersedia dalam appendix atau follow-up doc untuk orang yang bertanya, tetapi pimpin percakapan dengan business impact bahasa biasa: uang, downtime, data exposure, regulatory exposure.

Satu kebiasaan yang membantu di ketiga konteks — briefing, handover, dan interview — adalah menulis ringkasan satu kalimat sebelum menulis apa pun. Jika Anda tidak bisa mengompresi situasi menjadi satu kalimat, Anda belum memahaminya dengan cukup baik untuk menjelaskannya kepada orang lain.

Untuk lebih lanjut tentang menyusun incident writeup dan interview prep khusus untuk peran blue team, periksa segmen Korra Studio terkait pada penulisan laporan dan praktik interview analis SOC.