Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Persiapan
Persiapan untuk menghadapi insiden merupakan hal yang sangat penting agar respons insiden bisa dilakukan dengan cepat dan efektif. Persiapan dilakukan di tiga domain:
+ **Orang** – Dalam mempersiapkan orang-orang Anda untuk menghadapi insiden keamanan, pemangku kepentingan yang relevan perlu diidentifikasi untuk respons insiden, dan dilatih tentang respons insiden dan teknologi cloud.
+ **Proses** – Dalam mempersiapkan proses Anda untuk menghadapi insiden keamanan, perlu adanya pendokumentasian arsitektur, pengembangan rencana respons insiden menyeluruh, dan pembuatan playbook agar respons terhadap peristiwa keamanan bisa dilakukan secara konsisten.
+ **Teknologi** – Dalam mempersiapkan teknologi Anda untuk menghadapi insiden keamanan, perlu adanya pengaturan akses, agregasi dan pemantauan log yang diperlukan, penerapan mekanisme peringatan yang efektif, dan pengembangan respons serta kemampuan penyelidikan.
Setiap domain ini sama pentingnya agar respons insiden berjalan efektif. Tanpa ketiga domain ini, program respons insiden tidak akan lengkap atau efektif. Anda perlu mempersiapkan orang, proses, dan teknologi dengan integrasi yang erat agar siap menghadapi suatu insiden.
# Orang
Untuk merespons peristiwa keamanan, Anda perlu mengidentifikasi pemangku kepentingan yang akan mendukung respons terhadap peristiwa keamanan. Selain itu, agar respons bisa efektif, sangat penting agar mereka dilatih tentang teknologi AWS dan lingkungan AWS Anda.
# Menentukan peran dan tanggung jawab
Menangani peristiwa keamanan membutuhkan disiplin lintas organisasi dan komitmen untuk bertindak. Dalam struktur organisasi Anda, harus ada banyak orang yang bertanggung jawab, akuntabel, dimintai pendapat, atau diinformasikan saat terjadi insiden, seperti perwakilan dari sumber daya manusia (SDM), tim eksekutif, dan hukum. Pertimbangkan peran dan tanggung jawab ini, dan apakah ada pihak ketiga yang harus dilibatkan. Perhatikan bahwa di banyak geografi, ada hukum setempat yang mengatur apa yang harus dan tidak boleh dilakukan. Meskipun upaya untuk membangun bagan yang bertanggung jawab, akuntabel, berdasarkan konsultasi, dan terinformasi (RACI) untuk rencana respons keamanan Anda terasa birokratis, hal itu memungkinkan komunikasi yang cepat dan langsung serta dengan jelas menguraikan kepemimpinan di berbagai tahap peristiwa.
Selama insiden, menyertakan pemilik/developer aplikasi dan sumber daya yang terkena dampak adalah hal utama karena mereka merupakan ahli materi (subject matter experts/SME) yang dapat memberikan informasi dan konteks untuk membantu mengukur dampak. Pastikan untuk mempraktikkan dan membangun hubungan dengan developer serta pemilik aplikasi sebelum Anda mengandalkan keahlian mereka untuk respons insiden. Pemilik aplikasi atau SME, seperti administrator atau rekayasawan cloud Anda, mungkin perlu bertindak dalam situasi ketika lingkungan tidak dikenal atau memiliki kompleksitas, atau ketika responden tidak memiliki akses.
Terakhir, partner tepercaya mungkin terlibat dalam penyelidikan atau respons karena mereka dapat memberikan keahlian tambahan dan pengawasan yang berharga. Ketika tidak ada orang yang memiliki keterampilan ini dalam tim Anda sendiri, ada baiknya Anda menyewa pihak eksternal untuk bantuan.
# Melatih staf respons insiden
Melatih staf respons insiden Anda tentang teknologi yang digunakan organisasi mereka akan sangat penting agar mereka mampu merespons peristiwa keamanan secara memadai. Respons mungkin akan berlarut-larut jika anggota staf Anda tidak memahami teknologi yang mendasarinya. Selain konsep respons insiden tradisional, penting juga bagi mereka untuk memahami layanan AWS dan lingkungan AWS mereka. Ada sejumlah mekanisme tradisional untuk melatih staf insiden Anda, seperti pelatihan online dan pelatihan di ruang kelas. Anda juga dapat mempertimbangkan untuk menjalankan simulasi atau gameday sebagai mekanisme untuk pelatihan. Untuk detail tentang cara menjalankan simulasi, lihat bagian [Menjalankan simulasi reguler](run-regular-simulations.md) di dokumen ini.
# Memahami teknologi AWS Cloud
Untuk mengurangi ketergantungan dan memangkas waktu respons, pastikan tim keamanan dan responden Anda diedukasi tentang layanan cloud dan memiliki kesempatan untuk praktik langsung dengan lingkungan cloud spesifik yang digunakan organisasi Anda. Agar responden insiden berjalan efektif, penting untuk memahami fondasi AWS, IAM, AWS Organizations, layanan log dan pemantauan AWS, serta layanan keamanan AWS.
AWS menyediakan lokakarya keamanan online (lihat [Lokakarya Keamanan AWS](https://workshops.aws/categories/Security)) yang memberikan Anda pengalaman untuk praktik langsung dengan layanan keamanan dan pemantauan AWS. AWS juga menyediakan sejumlah opsi pelatihan dan jalur pembelajaran melalui pelatihan digital, pelatihan di ruang kelas, partner APN, dan sertifikasi. Untuk mempelajari lebih lanjut, lihat [AWS Training and Certification](https://aws.amazon.com/training/).
# Memahami lingkungan AWS Anda
Selain memahami layanan AWS, kasus penggunaannya, dan bagaimana layanan tersebut berintegrasi satu sama lain, sama pentingnya untuk memahami seperti apa arsitektur lingkungan AWS organisasi Anda dan proses operasional apa saja yang ada. Sering kali, pengetahuan internal seperti ini tidak didokumentasikan dan hanya dipahami oleh beberapa pakar domain, yang dapat menciptakan ketergantungan, menghambat inovasi, dan memperlambat waktu respons.
Untuk menghindari ketergantungan ini dan mempercepat waktu respons, pengetahuan internal tentang lingkungan AWS Anda harus didokumentasikan, dapat diakses, dan dipahami oleh analis keamanan Anda. Memahami cakupan cloud Anda secara menyeluruh akan membutuhkan kolaborasi antara pemangku kepentingan keamanan yang relevan dan administrator cloud. Bagian dari mempersiapkan proses Anda untuk respons insiden mencakup mendokumentasikan dan memusatkan diagram arsitektur, yang [Mendokumentasikan dan memusatkan diagram arsitektur](document-and-centralize-architecture-diagrams.md) nantinya dalam laporan resmi ini. Namun, dari perspektif orang, penting agar analis Anda dapat mengakses dan memahami diagram serta proses operasional yang terkait dengan lingkungan AWS Anda.
# Memahami tim respons dan dukungan AWS
## Dukungan
[Dukungan](https://aws.amazon.com/premiumsupport/) menawarkan berbagai rencana yang menyediakan akses ke alat dan keahlian yang mendukung keberhasilan dan kesehatan operasional solusi AWS. Jika Anda memerlukan dukungan teknis dan sumber daya lainnya untuk membantu merencanakan, melakukan deployment, dan mengoptimalkan lingkungan AWS, Anda dapat memilih paket dukungan yang paling sesuai dengan kasus penggunaan AWS Anda.
Pertimbangkan [Pusat Dukungan](https://console.aws.amazon.com/support) di Konsol Manajemen AWS (perlu masuk ke akun) sebagai titik kontak utama guna mendapatkan dukungan untuk masalah yang memengaruhi sumber daya AWS Anda. Akses ke Dukungan dikendalikan oleh IAM. Untuk informasi selengkapnya tentang mendapatkan akses ke fitur-fitur Dukungan AWS, lihat [Memulai dengan Dukungan](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
Selain itu, jika Anda perlu melaporkan penyalahgunaan, hubungi [tim penyalahgunaan AWS](https://aws.amazon.com/forms/report-abuse).
## Tim Respons Insiden Pelanggan (CIRT) AWS
Tim Respons Insiden Pelanggan (CIRT) AWS adalah tim AWS global khusus yang selalu siap memberikan dukungan kepada pelanggan selama terjadinya peristiwa keamanan aktif di sisi pelanggan dalam [Model Tanggung Jawab Bersama AWS](https://aws.amazon.com/compliance/shared-responsibility-model/).
Bantuan yang diberikan CIRT AWS kepada Anda dilengkapi dengan triase dan pemulihan untuk peristiwa keamanan aktif di AWS. Mereka akan membantu analisis penyebab masalah melalui penggunaan log layanan AWS dan memberi Anda rekomendasi untuk pemulihan. Mereka juga akan memberikan rekomendasi keamanan dan praktik terbaik untuk membantu Anda menghindari peristiwa keamanan ke depannya.
Pelanggan AWS dapat menggunakan CIRT AWS melalui [kasus dukungan AWS](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
## Dukungan respons DDoS
AWS menawarkan [AWS Shield](https://aws.amazon.com/shield/), yang menyediakan layanan perlindungan distributed denial of service (DDoS) terkelola yang melindungi aplikasi web yang berjalan di AWS. AWS Shield menyediakan deteksi selalu aktif dan mitigasi inline otomatis yang dapat meminimalkan waktu henti serta latensi aplikasi, sehingga tidak perlu melibatkan Dukungan untuk mendapatkan manfaat dari perlindungan DDoS. AWS Shield memiliki dua tingkatan: Shield Standard dan Shield Advanced. Untuk mengetahui perbedaan antara kedua tingkatan ini, lihat [Dokumentasi fitur Shield](https://aws.amazon.com/shield/features/).
## AWS Managed Services (AMS)
[AWS Managed Services](https://aws.amazon.com/managed-services/) (AMS) menyediakan pengelolaan infrastruktur AWS yang berkelanjutan, sehingga Anda dapat fokus pada aplikasi Anda. Dengan menerapkan praktik terbaik untuk memelihara infrastruktur Anda, AMS membantu mengurangi biaya operasional dan risiko Anda. AMS mengotomatiskan aktivitas umum seperti permintaan perubahan, pemantauan, manajemen patch, keamanan, dan layanan pencadangan, serta menyediakan layanan siklus hidup penuh untuk menyediakan, menjalankan, dan mendukung infrastruktur Anda.
AMS bertanggung jawab untuk deployment serangkaian kontrol detektif keamanan dan memberikan respons baris pertama 24/7 terhadap peringatan. Saat peringatan dimulai, AMS mengikuti seperangkat standar playbook otomatis dan manual untuk memverifikasi respons yang konsisten. Playbook ini dibagikan kepada pelanggan AMS saat orientasi agar mereka dapat mengembangkan dan mengoordinasikan respons dengan AMS.
# 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 sendiri. 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 perlu diambil** – Mengenumerasi 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:
+ **Struktur akun AWS** - Anda perlu mengetahui:
+ Berapa banyak akun AWS yang Anda miliki?
+ Bagaimana akun-akun AWS tersebut diatur?
+ Siapa pemilik bisnis akun AWS tersebut?
+ Apakah Anda menggunakan Kebijakan Kontrol Layanan (SCP)? Jika iya, pagar pembatas organisasi apa yang diterapkan dengan menggunakan SCP?
+ Apakah Anda membatasi wilayah dan layanan yang dapat digunakan?
+ Apa perbedaan antara unit bisnis dan lingkungan (dev/tes/prod)?
+ **Pola layanan AWS**
+ Layanan AWS apa yang Anda gunakan?
+ Apa layanan AWS yang paling banyak digunakan?
+ **Pola arsitektur**
+ Arsitektur cloud apa yang Anda gunakan?
+ **Pola autentikasi AWS**
+ Bagaimana developer Anda biasanya mengautentikasi ke AWS?
+ Apakah Anda menggunakan pengguna atau peran IAM (atau keduanya)? Apakah autentikasi ke 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?
+ **Pola otorisasi AWS**
+ 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 menggabungkan log AWS CloudTrail? 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 dengan AWS?
+ Bagaimana lalu lintas jaringan disaring antarlingkungan?
+ **Infrastruktur eksternal**
+ Bagaimana deployment untuk aplikasi yang digunakan secara eksternal?
+ Apa sumber daya AWS yang dapat diakses publik?
+ Apa akun AWS yang berisi infrastruktur yang digunakan secara eksternal?
+ Apa penyaringan eksternal atau DDoS 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 (TTP) aktor ancaman dan memungkinkan organisasi untuk melatih dan mengevaluasi kemampuan respons insiden mereka dengan merespons peristiwa siber tiruan ini yang mungkin saja akan benar-benar terjadi.
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. Penyelenggaraan latihan biasanya dapat dilakukan dalam sehari penuh di tempat virtual, bangunan fisik, atau kombinasi keduanya. 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. Fokus utama dalam latihan Tim Ungu adalah pada mekanisme deteksi, alat, dan prosedur operasi standar (SOP) 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. Tim pertahanan (*Tim Biru*) tidak harus memiliki pengetahuan tentang cakupan dan durasi latihan, sehingga memberikan penilaian yang lebih realistis tentang bagaimana mereka akan merespons insiden aktual. 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 uji penetrasi yang tersedia di [situs web Uji 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.
# Teknologi
Jika Anda mengembangkan dan menerapkan teknologi yang tepat sebelum insiden keamanan terjadi, staf respons insiden Anda akan dapat menyelidiki, memahami cakupan, dan mengambil tindakan dengan cepat.
# Mengembangkan struktur akun AWS
[AWS Organizations](https://aws.amazon.com/organizations/) membantu mengelola dan mengatur lingkungan AWS secara terpusat seiring pertumbuhan Anda dan peningkatan skala sumber daya AWS. Organisasi AWS mengonsolidasikan akun AWS Anda agar Anda dapat mengelolanya sebagai satu unit. Anda dapat menggunakan unit organisasi (OU) untuk mengelompokkan akun agar dapat mengelolanya sebagai satu unit.
Untuk respons insiden, akan sangat berguna jika Anda memiliki struktur akun AWS yang mendukung fungsi respons insiden, yang mencakup *unit organisasi keamanan* dan *unit organisasi forensik*. Dalam unit organisasi keamanan, Anda harus memiliki akun untuk:
+ **Pengarsipan log **– Menggabungkan log dalam akun AWS pengarsipan.
+ **Alat keamanan** – Memusatkan layanan keamanan di akun AWS alat keamanan. Akun ini beroperasi sebagai administrator yang didelegasikan untuk layanan keamanan.
Dalam forensik unit organisasi, Anda memiliki opsi untuk menerapkan satu akun forensik atau akun-akun untuk setiap Wilayah tempat Anda beroperasi, bergantung pada mana yang paling sesuai untuk model bisnis dan operasional Anda. Untuk contoh pendekatan akun per Wilayah, jika Anda hanya beroperasi di AS Timur (Virginia Utara) (us-east-1) dan AS Barat (Oregon) (us-west-2), Anda akan memiliki dua akun di forensik unit organisasi: satu untuk us-east-1 dan satu untuk us-west-2. Karena penyediaan akun baru membutuhkan waktu, akun forensik harus dibuat dan digunakan jauh sebelum insiden, sehingga bisa siap digunakan oleh responden secara efektif ketika merespons insiden.
Diagram berikut menampilkan struktur akun sampel, termasuk unit organisasi forensik dengan akun forensik per Wilayah:
![\[Diagram struktur akun per wilayah untuk respons insiden\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/images/incident-response-account-structure.png)
# Mengembangkan dan menerapkan strategi pemberian tag
Memperoleh informasi kontekstual tentang kasus penggunaan bisnis dan pemangku kepentingan internal yang relevan di sekitar sumber daya AWS bisa menjadi hal yang sulit. Salah satu cara untuk melakukannya adalah dalam bentuk tag, yang menetapkan metadata ke sumber daya AWS Anda dan terdiri dari kunci dan nilai yang ditentukan pengguna. Anda dapat menggunakan tag untuk mengelompokkan sumber daya berdasarkan tujuan, pemilik, lingkungan, jenis data yang diproses, dan kriteria lainnya yang Anda pilih.
Strategi pemberian tag yang konsisten dapat memangkas waktu respons dengan memudahkan Anda untuk mengidentifikasi dan membedakan informasi kontekstual tentang sumber daya AWS dengan cepat. Tag juga dapat berfungsi sebagai mekanisme untuk memulai otomatisasi respons. Untuk informasi lebih lanjut tentang apa yang harus diberi tag, lihat [dokumentasi tentang pemberian tag pada sumber daya AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). Anda harus terlebih dahulu menentukan tag yang ingin Anda terapkan di organisasi Anda. Setelah itu, Anda akan menerapkan dan menegakkan strategi pemberian tag ini. Detail tentang implementasi dan penegakan dapat ditemukan di blog AWS [Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/).
# Memperbarui informasi kontak akun AWS
Untuk setiap AWS akun Anda, penting untuk memiliki informasi up-to-date kontak yang akurat sehingga pemangku kepentingan yang benar menerima pemberitahuan penting dari AWS topik seperti keamanan, penagihan, dan operasi. Untuk setiap akun AWS, Anda memiliki kontak utama dan kontak alternatif untuk keamanan, penagihan, dan operasi. Perbedaan antara kontak ini dijelaskan di [Panduan Referensi Manajemen Akun AWS](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate).
Untuk detail tentang mengelola kontak alternatif, lihat [dokumentasi AWS tentang menambahkan, mengubah, atau menghapus kontak alternatif](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html#manage-account-payment-alternate-contacts). Jika tim Anda mengelola penagihan, operasi, dan masalah terkait keamanan, penggunaan daftar distribusi email merupakan praktik terbaik. Dengan daftar distribusi email, ketergantungan pada satu orang bisa dihindari, karena hal ini dapat menyulitkan apabila orang tersebut sedang tidak di kantor atau sudah keluar dari perusahaan. Anda juga harus memverifikasi bahwa informasi kontak email dan akun, termasuk nomor telepon, terlindungi dengan baik untuk berjaga-jaga jika terjadi pengaturan ulang kata sandi akun root dan pengaturan ulang autentikasi multi-faktor (MFA).
Untuk pelanggan yang menggunakan AWS Organizations, administrator organisasi dapat secara terpusat mengelola kontak alternatif untuk akun anggota menggunakan akun manajemen atau akun administrator yang didelegasikan tanpa memerlukan kredensial untuk setiap akun AWS. Anda juga perlu memverifikasi bahwa akun yang baru dibuat memiliki informasi kontak yang akurat. Lihat posting blog [Automatically update alternate contacts for newly created Akun AWS](https://aws.amazon.com/blogs/mt/automatically-update-alternate-contacts-for-newly-created-aws-accounts/).
# Menyiapkan akses ke Akun AWS
Selama insiden, tim respons insiden Anda harus memiliki akses ke lingkungan dan sumber daya yang terlibat dalam insiden tersebut. Pastikan tim Anda memiliki akses yang tepat untuk melakukan tugas mereka sebelum suatu peristiwa terjadi. Untuk melakukan itu, Anda harus tahu tingkat akses apa yang dibutuhkan anggota tim Anda (misalnya, jenis tindakan apa yang mungkin mereka ambil) dan harus menyediakan hak akses paling rendah terlebih dahulu.
Untuk menerapkan dan menyediakan akses ini, Anda harus mengidentifikasi dan mendiskusikan strategi akun AWS dan strategi identitas cloud dengan arsitek cloud organisasi Anda untuk memahami metode autentikasi dan otorisasi yang dikonfigurasi. Karena kredensial ini bersifat istimewa, Anda sebaiknya mempertimbangkan untuk menggunakan alur persetujuan atau mengambil kredensial dari brankas sebagai bagian dari implementasi Anda. Setelah implementasi, Anda perlu mendokumentasikan dan menguji akses anggota tim dengan baik sebelum peristiwa terjadi untuk memastikan mereka dapat merespons tanpa penundaan.
Terakhir, pengguna yang dibuat khusus untuk merespons insiden keamanan sering kali diberi hak istimewa agar dapat memiliki akses yang memadai. Oleh karena itu, penggunaan kredensial ini harus dibatasi, dipantau, dan tidak digunakan untuk kegiatan sehari-hari.
# Memahami lanskap ancaman
## Mengembangkan model ancaman
Dengan mengembangkan model ancaman, organisasi dapat mengidentifikasi ancaman dan mitigasi sebelum pengguna yang tidak sah dapat melakukannya. Ada sejumlah strategi dan pendekatan untuk pemodelan ancaman; lihat posting blog [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/). Untuk respons insiden, model ancaman dapat membantu mengidentifikasi vektor serangan yang mungkin digunakan aktor ancaman dalam insiden. Memahami apa yang Anda pertahankan akan sangat penting agar dapat merespons dengan segera. Anda juga dapat menggunakan AWS Partner untuk pemodelan ancaman. Untuk mencari partner AWS, gunakan [AWS Partner Network](https://partners.amazonaws.com/).
## Mengintegrasikan dan menggunakan intelijen ancaman siber
Intelijen ancaman siber adalah data dan analisis intensi, peluang, dan kemampuan aktor ancaman. Memperoleh dan menggunakan intelijen ancaman sangat membantu untuk mendeteksi insiden sejak dini dan memahami perilaku aktor ancaman dengan lebih baik. Intelijen ancaman siber mencakup indikator statis seperti alamat IP atau hash file malware. Hal ini juga mencakup informasi tingkat tinggi, seperti pola perilaku dan intensi. Anda dapat mengumpulkan intelijen ancaman dari sejumlah vendor keamanan siber dan dari repositori sumber terbuka.
Untuk mengintegrasikan dan memaksimalkan kecerdasan ancaman untuk AWS lingkungan Anda, Anda dapat menggunakan beberapa out-of-the-box kemampuan dan mengintegrasikan daftar intelijen ancaman Anda sendiri. Amazon GuardDuty menggunakan sumber intelijen ancaman AWS internal dan pihak ketiga. Layanan AWS lainnya, seperti firewall DNS dan aturan AWS WAF, juga mengambil masukan dari kelompok intelijen ancaman canggih AWS. Beberapa GuardDuty temuan dipetakan ke [MITRE ATT&CK Framework](https://attack.mitre.org/), yang memberikan informasi tentang pengamatan dunia nyata tentang taktik dan teknik musuh.
# Memilih dan mengatur log untuk analisis dan peringatan
Selama penyelidikan keamanan, Anda harus dapat meninjau log yang relevan untuk mencatat dan memahami cakupan serta garis waktu lengkap insiden tersebut. Log juga diperlukan untuk pembuatan peringatan, yang menunjukkan terjadinya tindakan tertentu yang menarik. Sangat penting untuk memilih, mengaktifkan, menyimpan, serta mengatur mekanisme kueri dan pengambilan, serta mengatur peringatan. Setiap tindakan ini ditinjau di bagian ini. Untuk detail selengkapnya, lihat posting blog AWS [Logging strategies for security incident response](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/).
# Memilih dan mengaktifkan sumber log
Menjelang penyelidikan keamanan, Anda perlu menangkap log yang relevan untuk merekonstruksi aktivitas secara surut di akun AWS. Pilih dan aktifkan sumber log yang relevan dengan beban kerja akun AWS-nya.
AWS CloudTrail adalah layanan pencatatan log yang melacak panggilan API yang dilakukan terhadap akun AWS yang menangkap aktivitas layanan AWS. Ini diaktifkan secara default dengan retensi 90 hari peristiwa manajemen yang dapat [diambil melalui CloudTrail fasilitas Riwayat Acara](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) menggunakanKonsol Manajemen AWS,AWS CLI, atau SDK. AWS Untuk retensi dan visibilitas peristiwa data yang lebih lama, Anda perlu [membuat CloudTrail Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) dan dikaitkan dengan bucket Amazon S3, dan secara opsional, dengan CloudWatch grup log. Atau, Anda dapat membuat [CloudTrail Danau](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html), yang menyimpan CloudTrail log hingga tujuh tahun dan menyediakan fasilitas kueri berbasis SQL.
AWSmerekomendasikan agar pelanggan yang menggunakan VPC mengaktifkan lalu lintas jaringan dan log DNS masing-masing menggunakan Log [Aliran VPC dan log](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) [kueri penyelesai Amazon Route 53, mengalirkannya ke bucket Amazon S3 atau grup log](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html). CloudWatch Anda dapat membuat log alur VPC untuk VPC, subnet, atau antarmuka jaringan. Untuk Log Alur VPC, Anda dapat bersikap selektif tentang bagaimana dan di mana Anda mengaktifkan Log Alur untuk mengurangi biaya.
Log AWS CloudTrail, Log Alur VPC, dan log kueri Route 53 resolver adalah *trifecta pencatatan log dasar* untuk mendukung investigasi keamanan di AWS.
AWSlayanan dapat menghasilkan log yang tidak ditangkap oleh trifecta logging dasar, seperti log Elastic Load BalancingAWS WAF, log, log perekam, temuan AmazonAWS Config, log audit GuardDuty Amazon Elastic Kubernetes Service (Amazon EKS), dan sistem operasi instans Amazon EC2 dan log aplikasi. Lihat daftar lengkap opsi pencatatan log dan pemantauan di [Lampiran A: Definisi kemampuan cloud](appendix-a-cloud-capability-definitions.md).
# Memilih penyimpanan log
Pilihan penyimpanan log umumnya terkait dengan alat kueri yang Anda gunakan, kemampuan retensi, pemahaman, dan biaya. Saat Anda mengaktifkan log AWS layanan, sediakan fasilitas penyimpanan; biasanya bucket atau grup CloudWatch log Amazon S3.
Bucket Amazon S3 menyediakan penyimpanan tahan lama yang hemat biaya dengan kebijakan siklus hidup opsional. Log yang disimpan di bucket Amazon S3 dapat dikueri secara native menggunakan layanan seperti Amazon Athena. Grup CloudWatch log menyediakan penyimpanan yang tahan lama dan fasilitas kueri bawaan melalui Wawasan CloudWatch Log.
# Mengidentifikasi retensi log yang sesuai
Saat Anda menggunakan bucket S3 atau grup CloudWatch log untuk menyimpan log, Anda harus menetapkan siklus hidup yang memadai untuk setiap sumber log guna mengoptimalkan biaya penyimpanan dan pengambilan. Pelanggan umumnya memiliki antara 3 dan 12 bulan log yang tersedia untuk kueri, dengan retensi hingga tujuh tahun. Pilihan ketersediaan dan retensi harus selaras dengan persyaratan keamanan Anda serta gabungan mandat hukum, peraturan, dan bisnis.
# Memilih dan menerapkan mekanisme kueri untuk log
Di AWS, layanan utama yang dapat Anda gunakan untuk menanyakan [CloudWatch log adalah Wawasan Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) untuk data yang disimpan dalam grup CloudWatch log, serta [Amazon Athena dan Amazon](https://aws.amazon.com/athena/) [Service untuk data yang disimpan di OpenSearch Amazon](https://aws.amazon.com/opensearch-service/) S3. Anda juga dapat menggunakan alat kueri pihak ketiga seperti informasi keamanan dan manajemen peristiwa (SIEM).
Proses untuk memilih alat kueri log harus mempertimbangkan aspek orang, proses, dan teknologi dalam operasi keamanan Anda. Pilih alat yang memenuhi persyaratan operasional, bisnis, dan keamanan, serta dapat diakses dan dipelihara dalam jangka panjang. Perlu diingat bahwa alat kueri log bekerja secara optimal ketika jumlah log yang akan dipindai tidak melebihi batas alat. Tidak jarang pelanggan memiliki beberapa alat kueri karena kendala biaya atau teknis. Misalnya, pelanggan mungkin menggunakan SIEM pihak ketiga untuk melakukan kueri data selama 90 hari terakhir, dan menggunakan Athena untuk melakukan kueri melebihi 90 hari karena biaya penyerapan log SIEM. Apa pun implementasinya, verifikasi bahwa pendekatan Anda meminimalkan jumlah alat yang diperlukan untuk memaksimalkan efisiensi operasional, terutama selama penyelidikan peristiwa keamanan.
# Menggunakan log untuk peringatan
AWSsecara native memberikan peringatan melalui layanan keamanan, seperti Amazon, GuardDuty [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), dan. AWS Config Anda juga dapat menggunakan mesin pembuat peringatan kustom untuk peringatan keamanan yang tidak tercakup oleh layanan ini atau untuk peringatan spesifik yang relevan dengan lingkungan Anda. Membangun peringatan dan deteksi ini tercakup dalam bagian bernama [Deteksi](detection.md) dalam dokumen ini.
# Mengembangkan kemampuan forensik
Menjelang insiden keamanan, pertimbangkan untuk mengembangkan kemampuan forensik guna mendukung investigasi peristiwa keamanan. [Guide to Integrating Forensic Techniques into Incident Response](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf) dari NIST menyediakan panduan tersebut.
# Forensik di AWS
Konsep dari forensik on-premise tradisional berlaku untuk AWS. Posting blog [Forensic investigation environment strategies in the AWS Cloud](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/) memberi Anda informasi penting untuk mulai memigrasikan keahlian forensiknya ke AWS.
Setelah lingkungan dan struktur akun AWS Anda disiapkan untuk forensik, Anda sebaiknya menentukan teknologi yang diperlukan agar dapat melakukan metodologi forensik yang sehat secara efektif dalam empat fase:
+ ** Pengumpulan** – Mengumpulkan log AWS yang relevan, seperti AWS CloudTrail, AWS Config, Log Alur VPC, dan log tingkat host. Kumpulkan snapshot, cadangan, dan dump memori dari sumber daya AWS yang terkena dampak.
+ ** Pemeriksaan** – Memeriksa data yang dikumpulkan dengan mengekstraksi dan menilai informasi yang relevan.
+ ** Analisis** – Menganalisis data yang dikumpulkan untuk memahami insiden dan menarik kesimpulan dari insiden tersebut.
+ ** Pelaporan** – Menyajikan informasi yang dihasilkan dari fase analisis.
# Menangkap cadangan dan snapshot
Menyiapkan cadangan sistem kunci dan basis data sangat penting untuk pemulihan dari insiden keamanan dan untuk tujuan forensik. Dengan memiliki cadangan, Anda dapat memulihkan sistem Anda ke keadaan aman sebelumnya. Di AWS, Anda dapat mengambil snapshot dari berbagai sumber daya. Snapshot memberi Anda point-in-time cadangan sumber daya tersebut. Ada banyak layanan AWS yang dapat mendukung Anda dalam hal pencadangan dan pemulihan. Lihat [Panduan Preskriptif Pencadangan dan Pemulihan](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) untuk detail tentang layanan ini dan pendekatan untuk pencadangan dan pemulihan. Untuk detail selengkapnya, lihat posting blog [Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/).
Terutama ketika berhubungan dengan situasi seperti ransomware, sangat penting agar cadangan Anda dilindungi dengan baik. Lihat posting blog [ 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/) untuk panduan tentang mengamankan cadangan Anda. Selain mengamankan cadangan, Anda juga sebaiknya menguji proses pencadangan dan pemulihan Anda secara teratur untuk memverifikasi bahwa teknologi dan proses yang Anda miliki berfungsi sesuai harapan.
# Otomatisasi forensik di AWS
Ketika terjadi peristiwa keamanan, tim respons insiden Anda harus dapat mengumpulkan dan menganalisis bukti dengan cepat sambil mempertahankan akurasi untuk periode waktu yang mengitari peristiwa tersebut. Mengumpulkan bukti yang relevan di lingkungan cloud, terutama di sejumlah besar contoh dan akun secara manual merupakan hal yang menyulitkan sekaligus memakan waktu bagi tim respons insiden. Selain itu, kesalahan manusia rentan terjadi dalam pengumpulan secara manual. Untuk alasan ini, pelanggan harus mengembangkan dan menerapkan otomatisasi untuk forensik.
AWS menawarkan sejumlah sumber daya otomatisasi untuk forensik, yang dikonsolidasikan dalam Lampiran di bagian [Sumber daya forensik](appendix-b-incident-response-resources.md#forensic-resources). Sumber daya ini adalah contoh pola forensik yang telah kami kembangkan dan telah diterapkan pelanggan. Meskipun sumber daya ini mungkin merupakan arsitektur referensi yang berguna untuk memulai, pertimbangkan untuk memodifikasinya atau membuat pola otomatisasi forensik baru berdasarkan lingkungan, persyaratan, alat, dan proses forensik Anda.
# Ringkasan item persiapan
Persiapan menyeluruh untuk merespons peristiwa keamanan sangat penting agar respons insiden bisa dilakukan tepat waktu dan efektif. Persiapan respons insiden melibatkan orang, proses, dan teknologi. Ketiga domain ini sama pentingnya dalam persiapan. Anda harus mempersiapkan dan mengembangkan program respons insiden Anda di ketiga domain tersebut.
Tabel 2 merangkum item persiapan yang dijabarkan dalam bagian ini.
* Tabel 2 – Item persiapan respons insiden*
| Domain | Item persiapan | Item tindakan |
| --- | --- | --- |
| Orang | Menentukan peran dan tanggung jawab. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Orang | Melatih staf respons insiden tentang AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Orang | Memahami opsi dukungan AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Proses | Mengembangkan rencana respons insiden. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Proses | Mendokumentasikan dan memusatkan diagram arsitektur. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Proses | Mengembangkan playbook respons insiden. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Proses | Menjalankan simulasi reguler. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Teknologi | Mengembangkan struktur akun AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Teknologi | Mengembangkan dan menerapkan strategi pemberian tag yang membantu responden untuk mengidentifikasi kepemilikan dan konteks temuan. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Teknologi | Memperbarui informasi kontak akun AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Teknologi | Menyiapkan akses ke akun AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Teknologi | Memahami lanskap ancaman. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Teknologi | Memilih dan mengatur log. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
| Teknologi | Mengembangkan kemampuan forensik. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-security-incident-response-guide/preparation-summary.html) |
Pendekatan berulang direkomendasikan untuk persiapan respons insiden. Semua item persiapan ini tidak dapat dilakukan dalam waktu singkat; Anda harus membuat rencana untuk memulai dari yang kecil dan terus meningkatkan kemampuan respons insiden Anda dari waktu ke waktu.