Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Proses
Mengembangkan proses respons insiden yang menyeluruh dan jelas adalah kunci untuk program respons insiden yang sukses dan terukur. Ketika peristiwa keamanan terjadi, langkah dan alur kerja yang jelas akan membantu Anda merespons secara tepat waktu. Anda mungkin sudah memiliki proses respons insiden yang ada. Terlepas dari keadaan saat ini, penting untuk memperbarui, mengulangi, dan menguji proses respons insiden Anda secara teratur.
# Mengembangkan dan menguji rencana respons insiden
Dokumen pertama yang dikembangkan untuk respons insiden adalah *rencana respons insiden*. Rencana respons insiden dirancang untuk menjadi dasar bagi program dan strategi respons insiden Anda. Rencana respons insiden adalah dokumen komprehensif yang biasanya mencakup bagian-bagian ini:
+ **ikhtisar tim respons insiden** – Menguraikan tujuan dan fungsi tim respons insiden
+ **Peran dan tanggung jawab** – Membuat daftar pemangku kepentingan respons insiden dan menjabarkan peran mereka ketika insiden terjadi
+ **Rencana komunikasi** – Detail informasi kontak dan bagaimana mekanisme komunikasi selama insiden
Ini adalah praktik terbaik untuk memiliki out-of-band komunikasi sebagai cadangan untuk komunikasi insiden. Contoh aplikasi yang menyediakan saluran out-of-band komunikasi aman adalah [AWS Wickr](https://aws.amazon.com/wickr/).
+ **Fase respons insiden dan tindakan yang harus diambil** - Menghitung fase respons insiden - misalnya, mendeteksi, menganalisis, memberantas, menahan, dan memulihkan - termasuk tindakan tingkat tinggi yang harus diambil dalam fase-fase tersebut
+ **Definisi keparahan insiden dan prioritas** – Memerinci cara mengklasifikasikan tingkat keparahan suatu insiden, bagaimana memprioritaskan insiden, lalu bagaimana definisi keparahan mempengaruhi prosedur eskalasi
Meskipun bagian-bagian ini umumnya ada di perusahaan dalam berbagai ukuran dan industri yang berbeda, rencana respons insiden akan berbeda-beda di setiap organisasi. Anda perlu membuat rencana respons insiden yang paling sesuai untuk organisasi Anda.
# Mendokumentasikan dan memusatkan diagram arsitektur
Untuk merespons peristiwa keamanan dengan cepat dan akurat, Anda perlu memahami bagaimana sistem dan jaringan Anda dirancang. Memahami pola internal ini tidak hanya penting untuk respons insiden, tetapi juga untuk memverifikasi konsistensi di seluruh aplikasi yang dirancang dengan pola tersebut, sesuai dengan praktik terbaik. Anda juga harus memverifikasi bahwa dokumentasi ini aktual dan diperbarui secara berkala sesuai pola arsitektur baru. Anda sebaiknya mengembangkan dokumentasi dan repositori internal yang menjabarkan item-item seperti:
+ **AWS struktur akun** - Anda perlu tahu:
+ Berapa banyak AWS akun yang Anda miliki?
+ Bagaimana AWS akun-akun itu diatur?
+ Siapa pemilik bisnis AWS akun tersebut?
+ Apakah Anda menggunakan Kebijakan Kontrol Layanan (SCPs)? Jika demikian, pagar pembatas organisasi apa yang diterapkan dengan menggunakan? SCPs
+ Apakah Anda membatasi Wilayah dan layanan yang dapat digunakan?
+ Apa perbedaan antara unit bisnis dan lingkungan (dev/test/prod)?
+ **AWS pola layanan**
+ AWS Layanan apa yang Anda gunakan?
+ Apa AWS layanan yang paling banyak digunakan?
+ **Pola arsitektur**
+ Arsitektur cloud apa yang Anda gunakan?
+ **AWS pola otentikasi**
+ Bagaimana developer Anda biasanya mengautentikasi ke AWS?
+ Apakah Anda menggunakan pengguna atau peran IAM (atau keduanya)? Apakah otentikasi Anda AWS terhubung ke penyedia identitas (iDP)?
+ Bagaimana Anda memetakan pengguna atau peran IAM ke karyawan atau sistem?
+ Bagaimana cara akses dicabut ketika seseorang tidak lagi diotorisasi?
+ **AWS pola otorisasi**
+ Kebijakan IAM apa yang digunakan developer Anda?
+ Apakah Anda menggunakan kebijakan berbasis sumber daya?
+ **Pencatatan dan pemantauan**
+ Sumber pencatatan apa yang Anda gunakan dan di mana sumber tersebut disimpan?
+ Apakah Anda mengumpulkan AWS CloudTrail log? Jika iya, di mana log tersebut disimpan?
+ Bagaimana Anda menanyakan CloudTrail log?
+ Apakah Anda GuardDuty mengaktifkan Amazon?
+ Bagaimana Anda mengakses GuardDuty temuan (misalnya, konsol, sistem tiket, SIEM)?
+ Apakah temuan atau peristiwa dikumpulkan dalam SIEM?
+ Apakah tiket dibuat secara otomatis?
+ Alat apa yang ada untuk menganalisis log dalam sebuah penyelidikan?
+ **Topologi jaringan**
+ Bagaimana perangkat, titik akhir, dan koneksi di jaringan Anda diatur secara fisik atau logis?
+ Bagaimana jaringan Anda terhubung AWS?
+ Bagaimana lalu lintas jaringan disaring antarlingkungan?
+ **Infrastruktur eksternal**
+ Bagaimana aplikasi yang menghadap ke luar digunakan?
+ AWS Sumber daya apa yang dapat diakses publik?
+ AWS Akun apa yang mengandung infrastruktur yang dihadapi secara eksternal?
+ Apa DDo S atau penyaringan eksternal yang ada?
Mendokumentasikan diagram dan proses teknis internal memudahkan pekerjaan analis respons insiden, membantu mereka dengan cepat memperoleh pengetahuan kelembagaan untuk merespons peristiwa keamanan. Dokumentasi proses teknis internal secara menyeluruh tidak hanya menyederhanakan investigasi keamanan, tetapi juga menyesuaikan rasionalisasi dan evaluasi proses.
# Mengembangkan playbook respons insiden
Bagian penting dari mempersiapkan proses respons insiden Anda adalah mengembangkan playbook. Playbook respons insiden memberikan serangkaian panduan preskriptif dan langkah-langkah yang harus diikuti ketika terjadi peristiwa keamanan. Struktur dan langkah yang jelas akan menyederhanakan respons dan mengurangi kemungkinan kesalahan manusia.
# Untuk apa saja playbook dibuat
Playbook sebaiknya dibuat untuk skenario insiden seperti:
+ **Insiden yang diantisipasi** – Playbook harus dibuat untuk insiden yang Anda antisipasi. Hal ini termasuk ancaman seperti denial of service (DoS), ransomware, dan pembobolan kredensial.
+ **Temuan atau peringatan keamanan yang diketahui** — Buku pedoman harus dibuat untuk temuan dan peringatan keamanan Anda yang diketahui, seperti temuan. GuardDuty Anda mungkin menerima GuardDuty temuan dan berpikir, “Sekarang apa?” Untuk mencegah kesalahan penanganan GuardDuty temuan atau mengabaikan temuan, buat buku pedoman untuk setiap temuan potensial. GuardDuty Beberapa rincian remediasi dan panduan dapat ditemukan dalam [GuardDutydokumentasi](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). Perlu dicatat bahwa tidak GuardDuty diaktifkan secara default dan menimbulkan biaya. Detail lebih lanjut tentang GuardDuty dapat ditemukan di Lampiran A: Definisi kemampuan cloud -. [Visibilitas dan peringatan](visibility-and-alerting.md)
# Apa saja yang perlu dimasukkan dalam playbook
Playbook harus berisi langkah-langkah teknis yang akan dijalankan oleh analis keamanan untuk menyelidiki dan merespons insiden keamanan potensial secara memadai.
Item yang akan disertakan dalam playbook meliputi:
+ **Gambaran umum playbook** – Skenario risiko atau insiden apa yang ditangani oleh playbook ini? Apa tujuan dari playbook ini?
+ **Prasyarat** – Log dan mekanisme deteksi apa yang diperlukan untuk skenario insiden ini? Apa notifikasi yang diharapkan?
+ **Informasi pemangku kepentingan** – Siapa yang terlibat dan apa informasi kontak mereka? Apa saja tanggung jawab setiap pemangku kepentingan?
+ **Langkah respons** – Di seluruh fase respons insiden, langkah taktis apa yang perlu diambil? Kueri apa yang perlu dijalankan analis? Kode apa yang perlu dijalankan untuk mencapai hasil yang diinginkan?
+ ** Deteksi **– Bagaimana insiden tersebut akan terdeteksi?
+ ** Analisis** – Bagaimana cakupan dampak akan ditentukan?
+ ** Tahan** – Bagaimana insiden akan diisolasi untuk membatasi cakupan?
+ ** Berantas** – Bagaimana ancaman akan dihilangkan dari lingkungan?
+ ** Pulihkan** – Bagaimana sistem atau sumber daya yang terpengaruh akan dibawa kembali ke produksi?
+ ** Hasil yang diharapkan** – Setelah kueri dan kode dijalankan, apa hasil yang diharapkan dari playbook tersebut?
Untuk memverifikasi informasi yang konsisten di setiap playbook, sebaiknya buat templat playbook yang dapat digunakan di seluruh playbook keamanan Anda yang lainnya. Beberapa item yang sudah terdaftar, seperti informasi pemangku kepentingan, dapat digunakan di beberapa playbook. Jika demikian, Anda dapat membuat dokumentasi terpusat untuk informasi tersebut dan merujuknya di dalam playbook, lalu menyebutkan perbedaan eksplisitnya di dalam playbook. Dengan begitu, Anda tidak perlu memperbarui informasi yang sama di setiap playbook Anda. Dengan membuat templat dan mengidentifikasi informasi umum atau bersama di playbook, Anda dapat menyederhanakan dan mempercepat pengembangan playbook. Terakhir, playbook Anda kemungkinan akan berkembang seiring waktu; setelah Anda memastikan bahwa langkah-langkahnya konsisten, hal ini membentuk persyaratan untuk otomatisasi.
# Contoh playbook
Sejumlah contoh playbook dapat ditemukan di Lampiran B di [Sumber daya playbook](appendix-b-incident-response-resources.md#playbook-resources). Contoh-contoh di sini dapat digunakan sebagai referensi Anda untuk playbook apa yang perlu dibuat dan apa yang perlu disertakan dalam playbook Anda. Namun, penting bagi Anda untuk membuat playbook yang menggabungkan risiko yang paling relevan dengan bisnis Anda. Anda perlu memverifikasi bahwa langkah-langkah dan alur kerja dalam playbook Anda mencakup teknologi dan proses Anda.
# Menjalankan simulasi reguler
Organisasi tumbuh dan berkembang dari waktu ke waktu, begitu pun halnya dengan ancaman. Karena itu, penting bagi Anda untuk terus meninjau kemampuan respons insiden Anda. Simulasi adalah salah satu metode yang dapat digunakan untuk melakukan penilaian ini. Simulasi menggunakan skenario peristiwa keamanan dunia nyata yang dirancang untuk meniru taktik, teknik, dan prosedur aktor ancaman (TTPs) dan memungkinkan organisasi untuk melatih dan mengevaluasi kemampuan respons insiden mereka dengan menanggapi peristiwa cyber tiruan ini karena mungkin terjadi dalam kenyataan.
Simulasi memiliki berbagai manfaat, termasuk:
+ Memvalidasi kesiapan siber dan mengembangkan kepercayaan diri responden insiden Anda.
+ Menguji akurasi dan efisiensi alat serta alur kerja.
+ Menyempurnakan metode komunikasi dan eskalasi yang selaras dengan rencana respons insiden Anda.
+ Memberikan kesempatan untuk merespons vektor yang kurang umum.
# Jenis simulasi
Ada tiga jenis simulasi utama:
+ **Latihan meja** – Pendekatan latihan meja dalam simulasi adalah sesi berbasis diskusi yang melibatkan berbagai pemangku kepentingan respons insiden untuk mempraktikkan peran dan tanggung jawab serta menggunakan alat komunikasi dan playbook yang telah ditetapkan. Fasilitasi latihan biasanya dapat dilakukan dalam sehari penuh di tempat virtual, tempat fisik, atau kombinasi. Karena sifatnya yang berbasis diskusi, latihan meja berfokus pada proses, orang, dan kolaborasi. Teknologi adalah bagian integral dari diskusi; tetapi, latihan meja umumnya tidak menggunakan alat atau skrip respons insiden yang sebenarnya.
+ **Latihan Tim Ungu** – Latihan Tim Ungu meningkatkan level kolaborasi antara tim responden insiden (*Tim Biru*) dan tim aktor ancaman simulasi (*Tim Merah*). Tim Biru umumnya terdiri dari anggota Security Operations Center (SOC), tetapi juga dapat mencakup pemangku kepentingan lain yang akan terlibat dalam peristiwa siber yang sebenarnya. Tim Merah umumnya terdiri dari tim uji penetrasi atau pemangku kepentingan utama yang dilatih dalam keamanan ofensif. Tim Merah bekerja secara kolaboratif dengan fasilitator latihan dalam merancang skenario yang akurat dan memungkinkan. Selama latihan Tim Ungu, fokus utamanya adalah pada mekanisme deteksi, alat, dan prosedur operasi standar (SOPs) yang mendukung upaya respons insiden.
+ **Latihan Tim Merah** – Dalam latihan Tim Merah, penyerang (*Tim Merah*) melakukan simulasi untuk mencapai tujuan tertentu atau serangkaian tujuan dari cakupan yang telah ditentukan sebelumnya. Pembela (*Tim Biru*) belum tentu mengetahui ruang lingkup dan durasi latihan, yang memberikan penilaian yang lebih realistis tentang bagaimana mereka akan menanggapi insiden yang sebenarnya. Karena latihan Tim Merah dapat menjadi uji invasif, Anda harus berhati-hati dan menerapkan kontrol untuk memverifikasi bahwa latihan tersebut tidak menyebabkan kerusakan nyata pada lingkungan Anda.
**catatan**
AWS mengharuskan pelanggan untuk meninjau kebijakan pengujian penetrasi yang tersedia di [situs web Pengujian Penetrasi](https://aws.amazon.com/security/penetration-testing/) sebelum mereka melakukan latihan Tim Ungu atau Tim Merah.
Tabel 1 merangkum beberapa perbedaan utama dalam jenis simulasi ini. Penting untuk dicatat bahwa definisinya secara umum dianggap lentur dan dapat disesuaikan dengan kebutuhan organisasi Anda.
*Tabel 1 — Jenis simulasi*
| | Latihan meja | Latihan Tim Ungu | Latihan Tim Merah |
| --- | --- | --- | --- |
| Ringkasan | Latihan berbasis kertas yang berfokus pada satu skenario insiden keamanan tertentu. Latihan ini dapat berupa latihan tingkat tinggi atau teknis, dan dijalankan dengan serangkaian skenario tertulis. | Penawaran yang lebih realistis dibandingkan dengan latihan meja. Selama latihan Tim Ungu, fasilitator bekerja secara kolaboratif dengan para peserta untuk meningkatkan keterlibatan latihan dan menawarkan pelatihan jika diperlukan. | Penawaran simulasi yang umumnya lebih canggih. Biasanya ada informasi yang disamarkan, sehingga para peserta mungkin tidak mengetahui semua detail latihan. |
| Sumber daya yang diperlukan | Diperlukan sumber daya teknis terbatas | Diperlukan berbagai pemangku kepentingan dan sumber daya teknis tingkat tinggi | Diperlukan berbagai pemangku kepentingan dan sumber daya teknis tingkat tinggi |
| Kompleksitas | Rendah | Sedang | Tinggi |
Pertimbangkan untuk memfasilitasi simulasi siber secara reguler. Setiap jenis latihan dapat memberikan manfaat tersendiri bagi peserta dan organisasi secara keseluruhan, sehingga Anda dapat memilih untuk memulai dengan jenis simulasi yang kurang kompleks (seperti latihan meja) lalu beralih ke jenis simulasi yang lebih kompleks (latihan Tim Merah). Anda sebaiknya memilih jenis simulasi berdasarkan kematangan keamanan, sumber daya, dan hasil yang Anda inginkan. Beberapa pelanggan mungkin tidak memilih untuk melakukan latihan Tim Merah karena kompleksitas dan biayanya.
# Siklus hidup latihan
Apa pun jenis simulasi yang Anda pilih, simulasi umumnya mengikuti langkah-langkah berikut:
1. **Menentukan elemen latihan inti** – Tentukan skenario simulasi dan tujuan simulasi. Dua hal ini harus disetujui oleh kepemimpinan.
1. **Mengidentifikasi pemangku kepentingan utama** – Latihan setidaknya membutuhkan fasilitator dan peserta latihan. Tergantung skenarionya, pemangku kepentingan tambahan seperti pimpinan dari departemen hukum, komunikasi, atau eksekutif dapat dilibatkan.
1. **Membangun dan menguji skenario** – Skenario mungkin perlu disesuaikan jika elemen tertentu tidak memungkinkan dalam pengembangannya. Tahap ini diharapkan menghasilkan skenario final.
1. **Memfasilitasi simulasi** – Jenis simulasi menentukan fasilitas yang digunakan (skenario tertulis atau skenario simulasi yang sangat teknis). Fasilitator harus menyelaraskan taktik fasilitasi mereka dengan objek latihan dan harus sebisa mungkin melibatkan semua peserta latihan agar hasilnya bisa optimal.
1. **Mengembangkan laporan setelah tindakan (AAR)** – Identifikasi area yang berjalan dengan baik, area yang dapat ditingkatkan lagi, dan potensi kesenjangan. AAR harus mengukur efektivitas simulasi serta respons tim terhadap peristiwa simulasi agar kemajuan dapat dilacak dari waktu ke waktu dengan simulasi mendatang.