Perancangan Buku Panduan

Buku pedoman adalah alur kerja respons yang dirumuskan dalam kode: serangkaian langkah berurutan dan bercabang yang dijalankan oleh platform SOAR saat dipicu. Buku pedoman merupakan versi yang dapat dijalankan dari buku prosedur yang dahulu disimpan di wiki.

Jika buku prosedur hanya mengatakan periksa reputasi the IP, buku pedoman benar-benar memanggil API reputasi, mengurai hasilnya, lalu membuat percabangan berdasarkan skornya. Merancang buku pedoman dengan baik adalah keterampilan inti dalam rekayasa otomatisasi di SOC.

Jangan pernah merancang buku pedoman secara abstrak. Mulailah dengan mendokumentasikan cara analis benar-benar menangani the alert saat ini, langkah demi langkah, termasuk keputusan yang mereka buat dan data yang mereka periksa.

Petakan setiap langkah ke dalam salah satu dari tiga kategori:

• Tindakan deterministik — masukan yang sama selalu menghasilkan keluaran yang sama (aman untuk diotomatiskan).
• Pengayaan — mengumpulkan data tanpa efek samping (aman untuk diotomatiskan).
• Penilaian — memerlukan konteks atau akuntabilitas (pertahankan keterlibatan manusia dalam alur).

Setiap buku pedoman memerlukan pemicu yang tepat. Jika terlalu luas, pemicu akan aktif karena derau; jika terlalu sempit, pemicu akan melewatkan kasus nyata.

Pemicu biasanya dikaitkan dengan aturan korelasi SIEM, kategori deteksi EDR, atau keputusan gerbang email. Tentukan kondisi masuk secara eksplisit.

Buku pedoman bekerja dengan artefak: indikator yang diekstrak dari the triggering event, seperti IP, hash berkas, akun pengguna, URL, dan nama host.

Rancangan yang baik menormalkan semua artefak tersebut menjadi objek konteks yang konsisten sejak awal, sehingga setiap langkah berikutnya merujuk pada nama bidang yang sama, terlepas dari alat mana yang menghasilkan the event.

• Ekstrak artefak sekali, di bagian paling awal.
• Validasi jenisnya (apakah ini benar-benar IPv4 yang valid?).
• Bawa konteks bersama melalui seluruh alur.

Alur kerja nyata memiliki percabangan. Setelah pengayaan, Anda menentukan jalur berdasarkan the evidence. Buat percabangan secara eksplisit dan menyeluruh agar tidak ada peristiwa yang terlewat tanpa penanganan.

Sisipkan gerbang persetujuan manusia sebelum tindakan apa pun yang bersifat destruktif, tidak dapat dibatalkan, atau berdampak luas. Buku pedoman mengumpulkan the evidence, menyajikannya, lalu berhenti sampai keputusan diterima.

Rancang gerbang agar ketika batas waktu tercapai, tersedia bawaan yang aman. Untuk penahanan, batas waktu tanpa respons dapat mengeskalasi kasus kepada teknisi siaga, alih-alih melanjutkan secara diam-diam atau membuang the case secara diam-diam.

• Menonaktifkan akun: gunakan gerbang.
• Memblokir subnet besar: gunakan gerbang.
• Memperkaya indikator: tidak memerlukan gerbang.

Integrasi dapat gagal. API dapat membatasi laju, mengalami waktu habis, dan mengembalikan data yang formatnya salah. Buku pedoman yang mengasumsikan setiap panggilan berhasil akan membuat insiden hanya diproses sebagian.

Bangun hal-hal berikut ke dalamnya:

• Percobaan ulang dengan jeda bertahap untuk kesalahan sementara (HTTP 429, 503).
• Nilai bawaan yang aman — jika pengayaan gagal, pilih eskalasi kepada manusia, bukan penutupan otomatis.
• Penanganan pesan gagal — arahkan kejadian yang tidak dapat diproses ke antrean yang ditinjau analis.

Buku pedoman dapat dijalankan dua kali untuk kejadian yang sama karena peringatan duplikat atau percobaan ulang. Tindakan harus bersifat idempoten: menjalankannya dua kali tidak boleh menimbulkan kerugian ganda.

Mengisolasi perangkat yang sudah diisolasi seharusnya tidak melakukan apa pun, bukan menghasilkan kesalahan. Saat membuka tiket, periksa terlebih dahulu apakah sudah ada tiket dengan kunci deduplikasi yang sama.

Jangan membuat satu buku pedoman raksasa untuk setiap jenis insiden. Pecah menjadi modul pedoman yang dapat digunakan kembali: modul pengayaan, modul penahanan, dan modul notifikasi.

Ini mencerminkan desain perangkat lunak yang baik. Blok pengayaan IP yang dapat digunakan kembali dan dipanggil dari pedoman pengelabuan, serangan tebak-paksa, dan C2 berarti ada satu tempat untuk memperbaikinya ketika API intelijen ancaman berubah.

Jalankan buku pedoman baru dalam mode uji coba / simulasi terlebih dahulu: jalankan pengayaan dan pencatatan, tetapi nonaktifkan sementara tindakan yang merusak. Bandingkan tindakan yang diusulkan buku pedoman dengan tindakan yang akan diambil analis pada kasus-kasus sebelumnya.

Hanya setelah logika keputusan terbukti benar pada insiden nyata yang telah berlalu, aktifkan tindakan langsung, dan bahkan saat itu mulailah dengan gerbang persetujuan untuk setiap tindakan.

Buku pedoman adalah kode dan layak mendapatkan disiplin yang sama. Simpan di bawah kendali versi agar setiap perubahan ditinjau, dapat dilacak, dan dapat dibatalkan.

• Catatan perubahan menjawab pertanyaan mengapa perilaku buku pedoman ini berbeda bulan lalu?
• Tinjauan sejawat menemukan logika berbahaya sebelum mencapai lingkungan produksi.
• Mendokumentasikan pemicu, keputusan, dan penanggung jawab yang dimaksud membuat buku pedoman tetap mudah dipelihara saat staf berganti.

Buku pedoman tanpa dokumentasi yang tidak dipahami siapa pun menjadi beban begitu salah menjalankan tindakan.

Terapkan prinsip desain buku pedoman pada skenario kegagalan.

Hal-hal penting dalam desain buku pedoman:

• Buku pedoman adalah alur kerja respons bercabang yang dapat dijalankan; rancang berdasarkan proses manual yang nyata.
• Klasifikasikan langkah sebagai tindakan deterministik, pengayaan, atau penilaian; beri gerbang persetujuan manusia pada penilaian.
• Tentukan pemicu yang tepat, normalkan artefak ke dalam konteks bersama, dan pastikan semua cabang tercakup.
• Tangani kesalahan dengan percobaan ulang dan nilai bawaan yang aman; pengayaan yang gagal harus dieskalasikan, bukan ditutup otomatis.
• Jadikan tindakan idempoten, pertahankan modularitas buku pedoman dengan modul yang dapat digunakan kembali, dan uji dalam mode uji coba terhadap insiden sebelumnya sebelum diterapkan secara langsung.