# 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.
**Topics**
+ [SEC10-BP01 Identifikasikan sumber daya eksternal dan personel penting](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Membuat rencana manajemen insiden](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Menyiapkan kemampuan forensik](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Mengembangkan dan menguji playbook respons insiden keamanan](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Menyediakan akses di awal](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Melakukan deployment alat di awal](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Menjalankan simulasi](sec_incident_response_run_game_days.md)
# SEC10-BP01 Identifikasikan sumber daya eksternal dan personel penting
Identifikasikan personel, sumber daya, dan kewajiban hukum internal serta eksternal untuk membantu organisasi Anda merespons insiden.
**Hasil yang diinginkan:** Anda memiliki daftar personel kunci, informasi kontak mereka, dan peran yang mereka mainkan saat menanggapi peristiwa keamanan yang terjadi. Anda meninjau informasi ini secara rutin dan memperbaruinya untuk menyesuaikan dengan perubahan personel dari perspektif alat internal dan eksternal. Anda mempertimbangkan semua penyedia dan vendor layanan pihak ketiga saat mendokumentasikan informasi ini, termasuk partner keamanan, penyedia cloud, dan aplikasi perangkat lunak sebagai layanan (SaaS). Saat peristiwa keamanan berlangsung, tersedia personel dengan tingkat tanggung jawab, konteks, dan akses yang sesuai untuk melakukan respons dan pemulihan.
**Anti-pola umum:**
+ Tidak memelihara daftar terbaru personel penting dengan informasi kontak, peran mereka, dan tanggung jawab mereka saat merespons peristiwa keamanan.
+ Mengasumsikan bahwa setiap orang mengetahui staf yang bertanggung jawab, dependensi, infrastruktur, dan solusi ketika melakukan respons dan pemulihan dari suatu peristiwa.
+ Tidak memiliki repositori dokumen atau pengetahuan yang merepresentasikan desain infrastruktur atau aplikasi utama.
+ Tidak memiliki proses onboarding yang tepat bagi karyawan baru untuk berkontribusi secara efektif terhadap respons peristiwa keamanan, seperti melakukan simulasi peristiwa.
+ Tidak memiliki jalur eskalasi ketika personel penting tidak tersedia untuk sementara waktu atau tidak merespons saat terjadi peristiwa keamanan.
**Manfaat menjalankan praktik terbaik ini:** Praktik ini akan mengurangi triase dan waktu respons yang dihabiskan untuk mengidentifikasi personel yang tepat dan peran mereka selama suatu peristiwa. Minimalkan waktu yang terbuang saat terjadi sebuah peristiwa dengan memelihara daftar terbaru personel penting dan peran mereka sehingga Anda dapat mendatangkan orang-orang yang tepat untuk melakukan triase dan pemulihan dari sebuah peristiwa.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
**Identifikasikan personel kunci dalam organisasi Anda:** Kelola daftar kontak personel di dalam organisasi Anda yang perlu Anda libatkan. Tinjau dan perbarui informasi ini secara rutin jika terjadi perpindahan personel, seperti perubahan organisasi, promosi, dan perubahan tim. Hal ini penting terutama untuk peran penting seperti manajer insiden, responden insiden, dan kepala komunikasi.
+ **Manajer insiden:** Manajer insiden memiliki otoritas keseluruhan selama merespons peristiwa.
+ **Responden insiden:** Responden insiden bertanggung jawab atas kegiatan investigasi dan remediasi. Orang-orang ini dapat berbeda berdasarkan jenis peristiwanya, tetapi biasanya adalah developer dan tim operasi yang bertanggung jawab atas aplikasi yang terkena dampak.
+ **Pimpinan komunikasi:** Pimpinan komunikasi bertanggung jawab atas komunikasi internal dan eksternal, terutama komunikasi dengan lembaga publik, regulator, dan pelanggan.
+ **Proses orientasi:** Secara teratur melakukan pelatihan dan orientasi karyawan baru untuk membekali mereka dengan keterampilan dan pengetahuan yang diperlukan guna berkontribusi secara efektif dalam upaya respons insiden. Terapkan simulasi dan latihan praktik langsung sebagai bagian dari proses orientasi untuk memfasilitasi kesiapan mereka
+ **Ahli bidang studi (SME):** Dalam kasus tim terdistribusi dan otonom, kami sarankan Anda mengidentifikasi SME untuk beban kerja kritis misi. Mereka memberikan wawasan tentang operasi dan klasifikasi data pada beban kerja krusial yang terpengaruh dalam peristiwa.
Contoh format tabel:
```
| Role | Name | Contact Information | Responsibilities |
1 | ——– | ——- | ——- | ——- |
2 | Incident Manager | Jane Doe| jane.doe@example.com | Overall authority during response |
3 | Incident Responder | John Smith | john.smith@example.com | Investigation and remediation |
4 | Communications Lead | Emily Johnson | emily.johnson@example.com | Internal and external communications |
5 | Communications Lead | Michael Brown | michael.brown@example.com | Insights on critical workloads |
```
Pertimbangkan untuk menggunakan fitur [Manajer Insiden AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) untuk merekam kontak utama, menentukan rencana respons, mengotomatiskan jadwal panggilan, dan membuat rencana eskalasi. Lakukan otomatisasi dan rotasi semua staf melalui jadwal jaga, sehingga tanggung jawab atas beban kerja dibagi di antara pemiliknya. Hal ini mendukung praktik-praktik yang baik, seperti menghasilkan metrik dan log yang relevan serta menentukan ambang batas alarm yang penting untuk beban kerja.
**Identifikasi mitra eksternal:** Perusahaan menggunakan alat yang dibangun oleh vendor perangkat lunak independen (ISV), mitra, dan subkontraktor untuk membangun solusi yang memiliki diferensiasi bagi pelanggan mereka. Libatkan personel penting dari pihak-pihak ini yang dapat membantu merespons dan melakukan pemulihan dari suatu insiden. Sebaiknya Anda mendaftar untuk tingkat Dukungan yang sesuai untuk mendapatkan akses cepat ke ahli bidang studi AWS melalui kasus dukungan. Pertimbangkan untuk melakukan hal yang serupa dengan semua penyedia solusi yang krusial untuk beban kerja. Beberapa peristiwa keamanan tertentu mengharuskan bisnis yang terdaftar di bursa saham memberi tahu lembaga publik dan badan pengatur yang relevan tentang peristiwa yang terjadi dan dampaknya. Pelihara dan perbarui informasi kontak untuk departemen yang relevan dan orang-orang yang bertanggung jawab.
## Langkah-langkah implementasi
1. Siapkan sebuah solusi manajemen insiden.
1. Pertimbangkan untuk melakukan deployment Manajer Insiden di akun Security Tooling Anda.
1. Tentukan kontak dalam solusi manajemen insiden Anda.
1. Tentukan minimal dua jenis saluran kontak untuk setiap kontak (seperti SMS, telepon, atau email) guna memastikan kontak tersebut dapat dihubungi saat insiden berlangsung.
1. Tentukan rencana respons.
1. Identifikasi kontak yang paling tepat untuk digunakan selama insiden. Tentukan rencana eskalasi yang selaras dengan peran yang dimiliki oleh personel yang akan dilibatkan, bukan kontak individu. Pertimbangkan untuk memasukkan kontak yang mungkin bertanggung jawab untuk memberi tahu entitas eksternal, meskipun mereka tidak terlibat langsung untuk menyelesaikan insiden.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [OPS02-BP03 Aktivitas operasi memiliki pemilik teridentifikasi yang bertanggung jawab atas kinerjanya](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_ops_model_def_activity_owners.html)
**Dokumen terkait:**
+ [AWS Panduan Respons Insiden Keamanan](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Contoh terkait:**
+ [AWS Kerangka kerja playbook pelanggan](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Bersiap dan merespons insiden keamanan di lingkungan AWS Anda](https://youtu.be/8uiO0Z5meCs)
**Alat terkait:**
+ [Peluncuran Manajer Insiden AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
**Video terkait:**
+ [Pendekatan Amazon terhadap keamanan selama pengembangan](https:/www.youtube.com/watch?v=NeR7FhHqDGQ)
# SEC10-BP02 Membuat rencana manajemen 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.
**Manfaat menjalankan praktik terbaik ini:** Mengembangkan proses respons insiden yang menyeluruh dan jelas adalah kunci untuk program respons insiden yang sukses dan terukur. Ketika sebuah peristiwa keamanan terjadi, langkah dan alur kerja yang jelas dapat 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.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Rencana manajemen insiden sangat penting untuk merespons, memitigasi, dan pulih dari potensi dampak yang ditimbulkan insiden keamanan. Rencana manajemen insiden adalah sebuah proses terstruktur untuk mengidentifikasi, memperbaiki, dan merespons insiden keamanan secara tepat waktu.
Cloud memiliki banyak peran dan persyaratan operasional yang sama yang juga ditemukan di lingkungan on-premise. Saat Anda membuat sebuah rencana manajemen insiden, Anda harus mempertimbangkan strategi respons dan pemulihan yang paling selaras dengan hasil bisnis dan persyaratan kepatuhan Anda. Sebagai contoh, jika Anda mengoperasikan beban kerja di AWS yang mematuhi FedRAMP di Amerika Serikat, ikuti rekomendasi dalam [NIST SP 800-61 Panduan Penanganan Keamanan Komputer](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Demikian pula, ketika Anda mengoperasikan beban kerja yang menyimpan informasi pengenal pribadi (PII), pertimbangkan cara melindungi dan merespons masalah yang terkait dengan residensi dan penggunaan data.
Saat membuat rencana manajemen insiden untuk beban kerja Anda di AWS, mulailah dengan [Model Tanggung Jawab Bersama AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) untuk membangun pendekatan pertahanan mendalam terhadap respons insiden. Dalam model ini, AWS mengelola keamanan cloud, dan Anda bertanggung jawab atas keamanan di cloud tersebut. Ini artinya Anda mempertahankan kontrol dan bertanggung jawab atas kontrol keamanan yang ingin Anda implementasikan. [Panduan Respons Insiden Keamanan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) menguraikan konsep utama dan panduan mendasar untuk membangun rencana manajemen insiden yang berorientasi cloud.
Rencana manajemen insiden yang efektif harus diulang-ulang (iterasi) secara berkelanjutan, dan harus tetap mutakhir sesuai tujuan-tujuan operasi cloud Anda. Pertimbangkan untuk menggunakan rencana implementasi yang diuraikan di bawah ini saat Anda membuat dan mengembangkan rencana manajemen insiden Anda.
### Langkah-langkah implementasi
1. Tentukan peran dan tanggung jawab dalam organisasi Anda untuk menangani peristiwa keamanan. Hal ini harus melibatkan perwakilan dari berbagai departemen, termasuk:
+ Sumber daya manusia (SDM)
+ Tim eksekutif
+ Departemen hukum
+ Pemilik dan developer aplikasi (ahli bidang studi, atau SME)
1. Uraikan dengan jelas siapa yang mengemban tanggung jawab, memegang akuntabilitas, dimintai pertimbangan, dan diberi informasi atau Responsible, Accountable, Consulted, and Informed (RACI) selama suatu insiden. Buat bagan RACI untuk memfasilitasi komunikasi yang cepat dan langsung, serta menguraikan kepemimpinan di berbagai tahap peristiwa dengan jelas.
1. Libatkan pemilik aplikasi dan developer (SME) selama insiden, karena mereka dapat memberikan informasi dan konteks yang berharga untuk membantu mengukur dampaknya. Bangun hubungan dengan SME ini, dan lakukan latihan skenario respons insiden dengan mereka sebelum insiden sebenarnya terjadi.
1. Libatkan mitra tepercaya atau ahli eksternal dalam proses investigasi atau respons karena mereka dapat memberikan keahlian dan perspektif tambahan.
1. Selaraskan rencana dan peran manajemen insiden Anda dengan peraturan setempat atau persyaratan kepatuhan yang mengatur organisasi Anda.
1. Latih dan uji rencana respons insiden Anda secara teratur, dan libatkan semua peran dan tanggung jawab yang ditentukan. Tindakan ini membantu merampingkan proses dan memverifikasi bahwa Anda memiliki respons yang terkoordinasi dan efisien terhadap insiden keamanan.
1. Tinjau serta perbarui peran, tanggung jawab, dan bagan RACI secara berkala, atau ketika struktur atau persyaratan organisasi Anda berubah.
**Memahami tim respons dan dukungan AWS**
+ **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-masalah yang memengaruhi sumber daya AWS Anda. Akses ke Dukungan dikontrol oleh AWS Identity and Access Management. Untuk informasi selengkapnya tentang mendapatkan akses ke fitur-fitur dukungan Dukungan, silakan lihat [Memulai dengan Dukungan](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
+ **AWS Tim Respons Insiden Pelanggan (CIRT)**
+ Tim Respons Insiden Pelanggan (CIRT) AWS adalah tim AWS global khusus yang selalu siap untuk, 24 jam sehari, 7 hari seminggu, 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/).
+ Ketika CIRT AWS mendukung Anda, mereka memberikan bantuan dengan melakukan evaluasi awal (triase) dan pemulihan untuk peristiwa keamanan aktif di AWS. Mereka dapat membantu menganalisis akar masalah melalui penggunaan log layanan AWS dan memberi Anda saran-saran pemulihan. Mereka juga dapat memberikan rekomendasi dan praktik terbaik keamanan untuk membantu Anda menghindari peristiwa keamanan di masa depan.
+ Pelanggan AWS dapat melibatkan CIRT AWS melalui [kasus Dukungan](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
+ [https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)
+ Diumumkan di re:Invent 2024, Respons Insiden Keamanan AWS adalah layanan respons insiden keamanan terkelola yang menggunakan teknologi triase modern serta melibatkan manusia dalam prosesnya (HITL). Layanan ini menyerap semua temuan GuardDuty dan temuan pihak ketiga yang dikirim ke AWS Security Hub CSPM untuk proses triase, dan hanya memberi notifikasi kepada pelanggan atas temuan yang membutuhkan penyelidikan. Layanan ini juga menyediakan sebuah portal untuk mengajukan kasus reaktif apabila pelanggan menemukan adanya insiden keamanan, serta untuk menerima dukungan dari tim respons insiden lanjutan AWS.
+ **Dukungan respons DDoS**
+ AWS menawarkan [AWS Shield](https://aws.amazon.com/shield/), yang menyediakan layanan perlindungan penolakan layanan terdistribusi terkelola (DDoS) yang akan melindungi aplikasi web yang berjalan di AWS. Shield menyediakan deteksi yang selalu aktif dan mitigasi integral otomatis yang dapat meminimalkan waktu henti dan latensi aplikasi, sehingga tidak perlu melibatkan Dukungan untuk mendapatkan manfaat dari perlindungan DDoS. Terdapat dua tingkatan Shield: AWS Shield Standard dan AWS Shield Advanced. Untuk mengetahui perbedaan antara kedua tingkatan ini, silakan lihat [Dokumentasi fitur Shield](https://aws.amazon.com/shield/features/).
+ **AWS Managed Services (AMS)**
+ [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) 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.
**Kembangkan rencana respons insiden**
Rencana respons insiden dirancang untuk menjadi dasar bagi program dan strategi respons insiden Anda. Rencana respons insiden harus dalam bentuk dokumen resmi. Rencana respons insiden biasanya menyertakan 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.
+ **Buat pencadangan metode komunikasi:** Memiliki komunikasi alternatif terpisah sebagai cadangan untuk komunikasi insiden merupakan praktik terbaik. Contoh aplikasi yang menyediakan saluran komunikasi out-of-band yang aman adalah AWS 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 di setiap organisasi. Anda perlu membangun rencana respons insiden yang paling cocok untuk organisasi Anda.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [SEC04 Deteksi](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Dokumen terkait:**
+ [Panduan Respons Insiden Keamanan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [ NIST: Panduan Penanganan Insiden Keamanan Komputer ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)
# SEC10-BP03 Menyiapkan kemampuan forensik
Menjelang insiden keamanan, pertimbangkan untuk mengembangkan kemampuan forensik guna mendukung investigasi peristiwa keamanan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
Konsep dari forensik on-premise tradisional berlaku untuk AWS. Untuk informasi kunci untuk mulai membangun kemampuan forensik di AWS Cloud, lihat [Strategi lingkungan investigasi forensik](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/) di AWS Cloud.
Setelah Anda menyiapkan lingkungan dan struktur Akun AWS Anda untuk forensik, tentukan teknologi-teknologi yang diperlukan untuk secara efektif melakukan metodologi yang baik secara forensik di 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 terdampak jika tersedia.
+ **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.
## Langkah-langkah implementasi
**Persiapkan lingkungan forensik Anda**
[AWS Organizations](https://aws.amazon.com/organizations/) membantu Anda mengelola dan mengatur lingkungan AWS secara terpusat seiring pertumbuhan Anda dan peningkatan skala sumber daya AWS. Sebuah organisasi AWS menggabungkan Akun AWS Anda sehingga Anda dapat mengelolanya sebagai satu unit tunggal. 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:** Log Agregasikan log dalam Akun AWS pengarsipan log dengan izin terbatas.
+ **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. Jika Anda membuat akun forensik per Wilayah, Anda dapat memblokir pembuatan sumber daya AWS di luar Wilayah tersebut dan mengurangi risiko sumber daya disalin ke wilayah yang tidak diinginkan. Misalnya, jika Anda hanya beroperasi di Wilayah AS Timur (Virginia Utara) (`us-east-1`) dan AS Barat (Oregon) (`us-west-2`), maka Anda akan memiliki dua akun yang ada di forensik OU: satu untuk `us-east-1` dan satu untuk `us-west-2`.
Anda dapat membuat Akun AWS forensik untuk beberapa Wilayah. Anda harus berhati-hati dalam menyalin sumber daya AWS ke akun tersebut untuk memastikan keselarasan dengan persyaratan-persyaratan kedaulatan data Anda. 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 alur yang menunjukkan struktur akun per Wilayah untuk respons insiden, bercabang ke OU keamanan dan forensik.\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/security-pillar/images/region-account-structure.png)
**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. Pada AWS, Anda dapat membuat snapshot berbagai sumber daya. Snapshot memberi Anda cadangan dari sumber daya berdasarkan titik waktu. Ada banyak layanan AWS yang dapat mendukung Anda dalam pencadangan dan pemulihan. Untuk membaca detail tentang layanan dan pendekatan pencadangan dan pemulihan ini, lihat [Panduan Preskriptif Pencadangan dan Pemulihan](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) dan [Gunakan cadangan untuk memulihkan dari insiden keamanan](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. Untuk membaca panduan tentang cara mengamankan cadangan Anda, silakan lihat [10 teratas praktik terbaik untuk mengamankan cadangan di AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/) . 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.
**Mengotomatiskan forensik**
Selama event keamanan, tim respons insiden Anda harus dapat mengumpulkan dan menganalisis bukti dengan cepat sambil mempertahankan akurasi selama jangka waktu sebelum dan sesudah event (seperti menangkap log yang berkaitan dengan event atau sumber daya tertentu atau mengumpulkan dump memori suatu instans Amazon EC2). Ini adalah hal yang menantang dan memakan waktu bagi tim respons insiden untuk mengumpulkan bukti yang relevan secara manual, terutama di sejumlah besar instans dan akun. Selain itu, kesalahan manusia rentan terjadi dalam pengumpulan secara manual. Untuk alasan-alasan ini, Anda harus mengembangkan dan mengimplementasikan otomatisasi untuk forensik sebisa mungkin.
AWS menawarkan sejumlah sumber daya otomatisasi untuk forensik, yang tercantum di bagian Sumber Daya berikut ini. 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.
## Sumber daya
**Dokumen terkait:**
+ [Panduan Respons Insiden Keamanan AWS - Mengembangkan Kemampuan Forensik ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [Panduan Respons Insiden Keamanan AWS - Sumber Daya Forensik ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Strategi lingkungan investigasi forensik di AWS Cloud](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+ [Cara mengotomatiskan pengumpulan disk forensik di AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
+ [Panduan Preskriptif AWS - Mengotomatiskan respons insiden dan forensik ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)
**Video terkait:**
+ [ Mengotomatiskan Respons Insiden dan Forensik ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
**Contoh terkait:**
+ [ Respons Insiden Otomatis dan Kerangka Forensik ](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [ Orkestrator Forensik Otomatis untuk Amazon EC2 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)
# SEC10-BP04 Mengembangkan dan menguji playbook respons insiden keamanan
Bagian penting dari mempersiapkan proses respons insiden Anda adalah mengembangkan playbook. Playbook respons insiden memberikan 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.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
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:** Playbook harus dibuat untuk menangani temuan dan peringatan keamanan Anda yang diketahui, seperti temuan Amazon GuardDuty. Saat Anda menerima temuan GuardDuty, playbook harus memberikan langkah-langkah yang jelas untuk mencegah kesalahan penanganan atau mengabaikan peringatan. Untuk detail dan panduan remediasi selengkapnya, lihat [Melakukan remediasi masalah keamanan yang ditemukan oleh GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html).
Playbook harus berisi langkah-langkah teknis yang akan dijalankan oleh analis keamanan untuk menyelidiki dan merespons insiden keamanan potensial secara memadai.
Tim Respons Insiden Pelanggan (CIRT) AWS telah menerbitkan [repositori GitHub yang berisi playbook respons insiden](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main/docs), yang diatur berdasarkan skenario ancaman, jenis, dan sumber daya. Playbook ini dapat disesuaikan agar selaras dengan prosedur respons insiden yang sudah ada atau berfungsi sebagai landasan untuk mengembangkan prosedur respons insiden baru.
### Langkah-langkah implementasi
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?
+ **Persyaratan**: Log, mekanisme deteksi, dan alat otomatis apa yang diperlukan untuk skenario insiden ini? Apa notifikasi yang diharapkan?
+ **Informasi komunikasi dan eskalasi**: Siapa saja 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?
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [SEC10-BP02 - Membuat rencana manajemen insiden](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
**Dokumen terkait:**
+ [Kerangka Kerja untuk Playbook Respons Insiden](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Mengembangkan Playbook Respons Insiden Anda sendiri](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)
+ [Contoh Playbook Respons Insiden](https://github.com/aws-samples/aws-incident-response-playbooks)
+ [Membangun runbook respons insiden AWS menggunakan playbook Jupyter dan CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)
# SEC10-BP05 Menyediakan akses di awal
Verifikasi staf respons insiden memiliki akses yang benar yang telah disediakan sebelumnya di AWS untuk mengurangi waktu yang diperlukan untuk penyelidikan hingga pemulihan.
**Anti-pola umum:**
+ Menggunakan akun root untuk merespons insiden.
+ Mengubah akun-akun yang ada.
+ Memanipulasi izin IAM secara langsung saat menyediakan peningkatan hak akses yang sedang dibutuhkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
AWS menyarankan Anda untuk sebisa mungkin mengurangi atau menghilangkan kebergantungan pada kredensial berumur panjang, dan memilih kredensial sementara dan mekanisme eskalasi hak akses *just-in-time*. Kredensial berumur panjang rentang terkena risiko keamanan dan meningkatkan biaya overhead operasional. Untuk sebagian besar tugas manajemen, serta tugas respons insiden, kami sarankan Anda untuk menerapkan [federasi identitas](https://aws.amazon.com/identity/federation/) bersama [eskalasi sementara untuk akses administratif](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). Di model ini, seorang pengguna meminta peningkatan ke tingkat hak akses yang lebih tinggi (seperti peran respons insiden) dan, apabila pengguna tersebut memenuhi syarat peningkatan hak, permintaan tersebut dikirimkan ke seorang pemberi persetujuan. Jika permintaan disetujui, pengguna akan menerima satu set [kredensial AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) sementara yang dapat digunakan untuk menyelesaikan tugas mereka. Setelah kredensial ini kedaluwarsa, pengguna harus mengirimkan permintaan peningkatan baru.
Kami menyarankan penggunaan peningkatan hak akses sementara di sebagian besar skenario respons insiden. Cara yang benar untuk melakukan hal itu adalah dengan menggunakan [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) dan [kebijakan sesi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) untuk mencakup akses.
Terdapat skenario di mana identitas terfederasi tidak tersedia, seperti:
+ Pemadaman yang berkaitan dengan penyedia identitas (IdP) yang terganggu.
+ Kesalahan konfigurasi atau kesalahan manusiawi yang menyebabkan rusaknya sistem manajemen akses terfederasi.
+ Aktivitas berbahaya seperti peristiwa distributed denial of service (DDoS) atau yang menyebabkan sistem tidak tersedia.
Dalam kasus sebelumnya, harus ada akses *kaca pecah* darurat yang dikonfigurasi untuk memungkinkan penyelidikan dan perbaikan insiden dilakukan secara tepat waktu. Sebaiknya Anda menggunakan [pengguna, grup, atau peran dengan izin yang sesuai](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) untuk melakukan tugas dan mengakses sumber daya AWS. Gunakan pengguna root hanya untuk [tugas yang memerlukan kredensial pengguna root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Untuk memverifikasi bahwa tim respons insiden memiliki tingkat akses yang tepat ke AWS dan sistem yang relevan lainnya, sebaiknya sediakan akun-akun khusus sejak awal. Akun-akun tersebut memerlukan akses istimewa, dan harus dikontrol dan dipantau secara ketat. Akun-akun tersebut harus dibuat dengan hak akses paling rendah yang diperlukan untuk menjalankan tugas yang diperlukan, dan tingkat akses harus didasarkan pada playbook yang dibuat sebagai bagian dari rencana manajemen insiden.
Gunakan pengguna dan peran yang dibuat khusus sebagai praktik terbaik. Peningkatan akses pengguna atau peran sementara melalui penambahan kebijakan IAM menjadikannya tidak jelas terkait akses apa yang dimiliki pengguna selama insiden, dan terdapat risiko tidak dicabutnya peningkatan hak akses tersebut.
Penting untuk menghapus dependensi sebanyak mungkin untuk memastikan akses dapat diperoleh dalam sebanyak mungkin skenario kegagalan. Untuk mendukung hal ini, buatlah sebuah playbook untuk memastikan pengguna respons insiden dibuat sebagai pengguna di dalam akun keamanan khusus, dan bukan dikelola melalui solusi Federasi atau masuk tunggal (SSO) yang ada. Tiap-tiap perespons harus memiliki akun dengan nama mereka sendiri. Konfigurasi akun harus menerapkan [kebijakan kata sandi yang kuat](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) dan autentikasi multi-faktor (MFA). Jika playbook respons insiden hanya memerlukan akses ke Konsol Manajemen AWS, pengguna tidak boleh memiliki kunci akses yang dikonfigurasi dan harus dilarang secara tegas untuk membuat kunci akses. Hal ini dapat dikonfigurasi dengan kebijakan IAM atau kebijakan kontrol layanan (SCP) sebagaimana disebutkan dalam Praktik Terbaik Keamanan AWS untuk [SPC AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Pengguna tidak boleh memiliki hak ases selain kemampuan untuk mengambil peran respons insiden di akun-akun lainnya.
Selama insiden, mungkin diperlukan pemberian akses ke individu internal atau eksternal untuk mendukung aktivitas penyelidikan, perbaikan, atau pemulihan. Pada kasus ini, gunakan mekanisme playbook yang disebutkan sebelumnya, dan harus ada proses untuk memverifikasi bahwa akses tambahan apa pun segera dicabut setelah insiden selesai.
Untuk memastikan bahwa penggunaan peran respons insiden dapat dipantau dan diaudit dengan layak, Anda tidak boleh membagikan akun IAM yang dibuat untuk tujuan ini kepada individu lain, serta tidak menggunakan Pengguna root akun AWS kecuali [diperlukan untuk tugas tertentu](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Jika pengguna root diperlukan (sebagai contoh, akses IAM ke akun tertentu tidak tersedia), gunakan proses terpisah dengan playbook yang tersedia untuk memverifikasi ketersediaan kredensial masuk dan dan token MFA pengguna root.
Untuk mengonfigurasi kebijakan IAM untuk peran respons insiden, pertimbangkan untuk menggunakan [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) untuk membuat kebijakan berdasarkan log AWS CloudTrail. Untuk melakukannya, berikan akses administrator ke peran respons insiden di akun non-produksi dan jalankan playbook Anda. Setelah selesai, kebijakan dapat dibuat yang hanya mengizinkan tindakan yang diambil. Kebijakan ini kemudian dapat diterapkan ke semua peran respons insiden di semua akun. Anda mungkin ingin membuat kebijakan IAM terpisah untuk setiap playbook untuk mempermudah manajemen dan audit. Contoh playbook dapat mencakup rencana respons untuk ransomware, pembobolan data, hilangnya akses produksi, dan skenario lain.
Gunakan akun respons insiden untuk mengambil [peran IAM respons insiden khusus di Akun AWS lainnya](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Peran-peran ini harus dikonfigurasi hanya agar dapat diambil oleh pengguna di akun keamanan, dan hubungan kepercayaan harus mewajibkan bahwa pengguna utama yang melakukan pemanggilan telah mengautentikasi dengan menggunakan MFA. Peran-peran tersebut harus menggunakan kebijakan IAM dengan cakupan yang ketat untuk mengontrol akses. Pastikan bahwa semua permintaan `AssumeRole` untuk peran-peran ini dicatat dalam log di CloudTrail dan dibuatkan peringatan, dan bahwa tindakan apa pun yang diambil menggunakan peran-peran ini dicatat dalam log.
Sangat disarankan bahwa akun IAM dan peran IAM disebutkan secara jelas agar dapat ditemukan dengan mudah di log CloudTrail. Contohnya adalah dengan menamai akun IAM dengan `-BREAK-GLASS` dan peran IAM dengan `BREAK-GLASS-ROLE`.
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) digunakan untuk mencatat log aktivitas API di akun AWS Anda dan harus digunakan untuk [mengonfigurasi peringatan tentang penggunaan peran respons insiden](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Lihat postingan blog tentang konfigurasi perintanan saat kunci root digunakan. Instruksinya dapat dimodifikasi untuk mengonfigurasi metrik [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) filter-to-filter pada peristiwa `AssumeRole` yang terkait dengan peran IAM respons insiden:
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```
Karena peran respons insiden kemungkinan memiliki tingkat akses yang tinggi, peringatan-peringatan ini harus menjangkau grup yang luas dan ditindaklanjuti segera.
Selama insiden, terdapat kemungkinan bahwa perespons mungkin memerlukan akses ke sistem yang tidak diamankan secara langsung oleh IAM. Ini dapat mencakup instans Amazon Elastic Compute Cloud, basis data Amazon Relational Database Service, atau platform Perangkat Lunak sebagai Layanan (SaaS). Sangat disarankan bahwa daripada menggunakan protokol asli seperti SSH atau RDP, [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) digunakan untuk semua akses administratif ke instans Amazon EC2. Akses ini dapat dikontrol menggunakan IAM, yang aman dan diaudit. Dimungkinkan juga untuk mengotomatiskan bagian dari playbook Anda dengan menggunakan [dokumen AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), yang dapat mengurangi kesalahan pengguna dan meningkatkan waktu untuk pemulihan. Untuk akses ke basis data dan alat-alat pihak ketiga, kami sarankan menyimpan kredensial akses di AWS Secrets Manager dan memberikan akses ke peran perespons insiden.
Terakhir, pengelolaan akun IAM respons insiden harus ditambahkan ke [proses Joiner, Movers, dan Leavers Anda](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) dan kemudian ditinjau dan diuji secara berkala untuk memverifikasi bahwa hanya akses yang dimaksudkan yang diizinkan.
## Sumber daya
**Dokumen terkait:**
+ [Mengelola peningkatan akses sementara ke lingkungan AWS Anda](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [Panduan Respons Insiden Keamanan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Manajer Insiden AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [Mengatur kebijakan kata sandi akun untuk pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Menggunakan autentikasi multi-faktor (MFA) di AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)
+ [ Mengonfigurasi Akses Lintas Akun dengan MFA ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Menggunakan IAM Access Analyzer untuk menghasilkan kebijakan IAM ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Praktik Terbaik untuk Kebijakan Kontrol Layanan AWS Organizations di Lingkungan Multi-akun ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ Cara Menerima Notifikasi Ketika Kunci Akses Root Akun AWS Anda Digunakan ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Membuat izin sesi mendetail menggunakan kebijakan terkelola IAM ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+ [Akses pecah kaca](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Video terkait:**
+ [ Mengotomatiskan Respons Insiden dan Forensik di AWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+ [Panduan mandiri untuk runbook, laporan insiden, dan respons insiden](https://youtu.be/E1NaYN_fJUo)
+ [ Bersiap dan merespons insiden keamanan di lingkungan AWS Anda ](https://www.youtube.com/watch?v=8uiO0Z5meCs)
# SEC10-BP06 Melakukan deployment alat di awal
Pastikan personel keamanan sejak awal telah melakukan deployment alat yang tepat untuk mengurangi waktu investigasi melalui pemulihan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Untuk mengotomatiskan respons keamanan dan fungsi operasi, Anda dapat menggunakan set API dan alat yang komprehensif dari AWS. Anda dapat sepenuhnya mengotomatiskan manajemen identitas, keamanan jaringan, perlindungan data, dan kemampuan pemantauan, serta menyediakannya menggunakan metode pengembangan perangkat lunak populer yang sudah Anda gunakan. Saat Anda membangun otomatisasi keamanan, sistem Anda dapat memantau, meninjau, dan menginisiasi respons, tanpa memerlukan orang untuk memantau posisi keamanan Anda dan memberikan reaksi terhadap peristiwa secara manual.
Jika tim respons insiden Anda terus merespons peringatan dengan cara yang sama, mereka berisiko mengalami kelelahan alarm (alarm fatigue). Seiring berjalannya waktu, tim dapat menjadi tidak peka terhadap peringatan sehingga dapat membuat kesalahan saat menangani situasi biasa atau melewatkan peringatan yang tidak biasa. Otomatisasi membantu mencegah kelelahan alarm dengan menggunakan fungsi yang memproses peringatan biasa dan repetitif, sehingga manusia cukup menangani insiden yang sensitif dan unik. Integrasi sistem deteksi anomali, seperti Amazon GuardDuty, Wawasan AWS CloudTrail, dan Deteksi Anomali Amazon CloudWatch, dapat mengurangi beban dari peringatan umum berbasis ambang batas.
Anda dapat memperbaiki proses manual dengan mengotomatiskan langkah-langkah dalam proses secara terprogram. Setelah Anda menentukan perbaikan pola pada peristiwa, Anda dapat menguraikan pola tersebut menjadi logika yang dapat ditindaklanjuti, dan menulis kode untuk menjalankan logika tersebut. Pemberi respons selanjutnya dapat menjalankan kode tersebut untuk memperbaiki masalah. Seiring berjalannya waktu, Anda dapat mengotomatiskan lebih banyak langkah, dan pada akhirnya secara otomatis menangani semua jenis insiden yang biasa muncul.
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. Selain itu, cara yang efektif untuk menyediakan alat untuk mencari data log adalah [Amazon Detective](https://aws.amazon.com/detective/).
AWS menawarkan lebih dari 200 layanan cloud dan ribuan fitur. Kami menyarankan Anda meninjau layanan yang dapat mendukung dan menyederhanakan strategi respons insiden Anda.
Selain pencatatan log, Anda harus mengembangkan dan menerapkan [strategi pemberian tag](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). Pemberian tag dapat membantu memberikan konteks seputar tujuan sebuah sumber daya AWS. Pemberian tag juga dapat digunakan untuk otomatisasi.
### Langkah-langkah implementasi
**Memilih dan mengatur log untuk analisis dan peringatan**
Lihat dokumentasi berikut tentang cara mengonfigurasi pencatatan log untuk respons insiden:
+ [ Strategi pencatatan log untuk respons insiden keamanan ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [SEC04-BP01 Mengonfigurasi pencatatan log layanan dan aplikasi](sec_detect_investigate_events_app_service_logging.md)
**Aktifkan layanan keamanan untuk mendukung deteksi dan respons**
AWS menyediakan kemampuan deteksi, pencegahan, serta respons, dan layanan lainnya dapat digunakan untuk merancang solusi keamanan khusus. Untuk daftar layanan yang paling relevan untuk respons insiden keamanan, lihat [Definisi kemampuan cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html) dan [halaman beranda Respons Insiden Keamanan](https://aws.amazon.com/security-incident-response/).
**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.
Memiliki strategi pemberian tag yang konsisten dapat mempercepat waktu respons dan meminimalkan waktu yang dihabiskan untuk konteks organisasi dengan memungkinkan Anda mengidentifikasi dan membedakan informasi kontekstual tentang sumber daya AWS dengan cepat. Tag juga dapat berfungsi sebagai mekanisme untuk memulai otomatisasi respons. Untuk detail selengkapnya tentang apa yang harus diberi tag, lihat [Memberikan tag pada sumber daya AWS Anda](https://docs.aws.amazon.com/tag-editor/latest/userguide/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. Untuk mendapatkan detail selengkapnya tentang implementasi dan penegakan, lihat [Menerapkan strategi penandaan sumber daya AWS dengan menggunakan Kebijakan Tag AWS dan Kebijakan Kontrol Layanan (SCP)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/).
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [SEC04-BP01 Mengonfigurasi pencatatan log layanan dan aplikasi](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Catat log, temuan, dan metrik di lokasi standar](sec_detect_investigate_events_logs.md)
**Dokumen terkait:**
+ [ Strategi pencatatan log untuk respons insiden keamanan ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Definisi kemampuan cloud respons insiden ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)
**Contoh terkait:**
+ [ Deteksi dan Respons Ancaman dengan Amazon GuardDuty dan Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Lokakarya Security Hub ](https://catalog.workshops.aws/security)
+ [ Manajemen Kerentanan dengan Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)
# SEC10-BP07 Menjalankan simulasi
Organisasi tumbuh dan berkembang dari waktu ke waktu, begitu juga dengan lanskap ancaman. Oleh karena itu, penting untuk terus-menerus mengkaji kemampuan Anda dalam merespons insiden. Menjalankan simulasi (juga dikenal dengan nama game day) 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.
**Manfaat menjalankan praktik terbaik ini:** Simulasi memiliki berbagai manfaat:
+ 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.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
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, bangunan fisik, atau kombinasi keduanya. Karena berbasis diskusi, latihan meja berfokus pada proses, orang, dan kolaborasi. Teknologi merupakan bagian tak terpisahkan dari diskusi, tetapi penggunaan nyata alat atau skrip respons insiden umumnya bukan bagian dari latihan meja.
+ **Latihan tim ungu:** Latihan Tim Ungu meningkatkan level kolaborasi antara tim responden insiden (Tim Biru) dan tim aktor ancaman simulasi (Tim Merah). Tim biru terdiri dari anggota pusat operasi keamanan (SOC), tetapi juga bisa melibatkan pemangku kepentingan lain yang akan terlibat selama peristiwa dunia maya nyata. Tim merah terdiri dari tim uji penetrasi atau pemangku kepentingan utama yang terlatih dalam hal 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 bisa bersifat invasif, berhati-hatilah dan terapkan kontrol untuk memverifikasi bahwa latihan tidak menyebabkan kerusakan nyata pada lingkungan Anda.
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.
## Langkah-langkah implementasi
Terlepas dari jenis simulasi yang Anda pilih, simulasi umumnya mengikuti langkah-langkah implementasi berikut ini:
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.
## Sumber daya
**Dokumen terkait:**
+ [Panduan Respons Insiden AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Video terkait:**
+ [AWS GameDay - Edisi Keamanan](https://www.youtube.com/watch?v=XnfDWID_OQs)
+ [Menjalankan simulasi respons insiden keamanan yang efektif](https://www.youtube.com/watch?v=63EdzHT25_A)