# Respons insiden
**Topics**
+ [SEC 10 Bagaimana cara mengantisipasi, merespons, dan pulih dari insiden?](w2aac19b7c15b5.md)
# SEC 10 Bagaimana cara mengantisipasi, merespons, dan pulih dari insiden?
Persiapan sangat penting untuk penyelidikan, respons, dan pemulihan peristiwa keamanan secara tepat waktu dan efektif guna membantu meminimalkan gangguan terhadap organisasi Anda.
**Topics**
+ [SEC10-BP01 Identifikasikan sumber daya eksternal dan personel kunci](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 Mengotomatiskan kemampuan kontainer](sec_incident_response_auto_contain.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 game day](sec_incident_response_run_game_days.md)
# SEC10-BP01 Identifikasikan sumber daya eksternal dan personel kunci
Identifikasikan kewajiban legal, sumber daya, dan personel internal serta eksternal yang dapat membantu organisasi Anda merespons insiden.
Saat Anda menentukan pendekatan Anda terhadap respons insiden di cloud, bersama dengan tim lainnya (seperti penasihat hukum, pimpinan, pemangku kepentingan bisnis, Layanan AWS Support, dan lainnya), Anda harus mengidentifikasi personel kunci, pemangku kepentingan, dan kontak yang relevan. Untuk mengurangi dependensi dan mempercepat waktu respons, pastikan tim Anda, tim keamanan spesialis, dan pemberi respons paham tentang layanan yang Anda gunakan dan memiliki kesempatan untuk praktik langsung.
Sebaiknya identifikasikan partner keamanan AWS eksternal yang dapat memberi Anda ahli dari luar perusahaan dan memberikan perspektif yang berbeda untuk melengkapi kemampuan respons Anda. Partner keamanan tepercaya Anda dapat membantu Anda mengidentifikasi potensi risiko atau ancaman yang belum Anda kenali dengan baik.
**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 untuk merespons dan melakukan pemulihan dari insiden.
+ Identifikasikan partner eksternal: Bekerja samalah dengan partner eksternal yang dapat membantu Anda merespons dan melakukan pemulihan dari insiden, jika diperlukan.
## Sumber daya
**Dokumen terkait:**
+ [Panduan Respons Insiden AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Video terkait:**
+ [Prepare for and respond to security incidents in your AWS environment ](https://youtu.be/8uiO0Z5meCs)
**Contoh terkait:**
# SEC10-BP02 Membuat rencana manajemen insiden
Buat rencana untuk membantu Anda merespons insiden, berkomunikasi selama insiden, dan melakukan pemulihan setelah insiden. Misalnya, Anda bisa mulai membuat rencana respons insiden dengan skenario yang paling mungkin dilakukan untuk beban kerja atau organisasi Anda. Sertakan cara berkomunikasi dan eskalasi baik secara internal maupun eksternal.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Rencana manajemen insiden sangat penting untuk merespons, memitigasi, dan pulih dari potensi dampak insiden keamanan. Rencana manajemen insiden adalah 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 membuat rencana manajemen insiden, penting untuk 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 patuh terhadap FedRAMP di Amerika Serikat, ada gunanya Anda mematuhi [NIST SP 800-61 Panduan Penanganan Keamanan Komputer](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Begitu juga, saat mengoperasikan beban kerja dengan data PII (informasi identitas pribadi) Eropa, pertimbangkan skenario seperti cara Anda melindungi dan merespons permasalahan terkait residensi data yang diatur oleh [Peraturan Perlindungan Data Umum (GDPR) Uni Eropa](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en).
Saat membangun rencana manajemen insiden untuk beban kerja yang beroperasi di AWS, mulailah dengan [Model Tanggung Jawab Bersama AWS](https://aws.amazon.com/compliance/shared-responsibility-model/), untuk membangun pendekatan pertahanan mendalam untuk respons insiden. Dalam model ini, AWS mengelola keamanan cloud, dan Anda bertanggung jawab atas keamanan di cloud. 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 berorientasi cloud.
Rencana manajemen insiden yang efektif harus diiterasi secara berkelanjutan, dan harus tetap mutakhir sesuai tujuan operasi cloud Anda. Pertimbangkan menggunakan rencana implementasi yang diuraikan di bawah seiring Anda membuat dan mengembangkan rencana manajemen insiden Anda.
+ **Berikan edukasi dan pelatihan untuk respons insiden:** Saat terjadi penyimpanan dari patokan yang telah Anda tetapkan (misalnya, deployment yang tidak tepat atau kesalahan konfigurasi), Anda mungkin perlu merespons dan menyelidikinya. Untuk keberhasilan dalam melakukannya, Anda harus memahami kontrol dan kemampuan mana yang dapat Anda gunakan untuk keamanan dan respons insiden di dalam lingkungan AWS Anda, serta proses yang perlu Anda pertimbangkan untuk menyiapkan, mengedukasi, dan melatih tim cloud Anda dalam merespons insiden.
+ [Playbook](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) dan [runbook](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) adalah mekanisme yang efektif untuk membangun konsistensi dalam melatih cara merespons insiden. Mulailah dengan membuat daftar awal prosedur yang sering dijalankan selama respons insiden, dan lanjutkan untuk melakukan iterasi seiring Anda mempelajari atau menggunakan prosedur baru.
+ Sosialisasikan playbook dan runbook melalui [game day](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)terjadwal. Selama game day, simulasikan respons insiden dalam lingkungan terkontrol sehingga tim Anda dapat mengingat cara merespons, dan untuk memverifikasi bahwa tim yang terlibat dalam respons insiden sangat memahami alur kerja. Tinjau hasil simulasi peristiwa untuk mengidentifikasi perbaikan dan menentukan kebutuhan untuk diadakannya pelatihan lebih lanjut atau alat-alat tambahan.
+ Keamanan harus dianggap sebagai tugas setiap orang. Bangun pengetahuan bersama tentang proses manajemen insiden dengan melibatkan semua personel yang normalnya mengoperasikan beban kerja Anda. Ini mencakup semua aspek bisnis Anda: operasi, pengujian, pengembangan, keamanan, operasi bisnis, dan pemimpin bisnis.
+ **Dokumentasikan rencana manajemen insiden:** Dokumentasikan alat dan proses untuk merekam, menindaklanjuti, mengomunikasikan progres, dan menyediakan notifikasi tentang insiden aktif. Tujuan rencana manajemen insiden adalah untuk memverifikasi bahwa operasi normal dipulihkan secepat mungkin, dampak bisnis diminimalkan, dan semua pihak yang terkait mendapatkan informasi terbaru. Contoh insiden mencakup (tetapi tidak terbatas pada) hilangnya atau menurunnya konektivitas jaringan, proses atau API tidak responsif, tugas terjadwal tidak dijalankan (misalnya patching gagal), ketidaktersediaan data atau layanan aplikasi, gangguan layanan yang tidak terencana akibat peristiwa keamanan, kebocoran kredensial, atau kesalahan konfigurasi.
+ Identifikasi pemilik utama yang bertanggung jawab atas penyelesaian insiden, seperti pemilik beban kerja. Miliki panduan yang jelas tentang orang yang akan menjalankan penyelesaian insiden dan bagaimana komunikasi akan ditangani. Saat Anda memiliki lebih dari satu pihak yang berpartisipasi dalam proses penyelesaian insiden, seperti vendor eksternal, pertimbangkan membangun *matriks tanggung jawab (RACI)*, yang menguraikan peran serta tanggung jawab berbagai tim dan individu yang diperlukan untuk penyelesaian insiden.
Matriks RACI berisi detail tentang hal-hal berikut:
+ **R:** *Pihak yang Bertanggung jawab (Responsible)* yang melakukan pekerjaan untuk menyelesaikan tugas.
+ **A:** *Pihak atau pemangku kepentingan yang akuntabel (Accountable)* dengan otoritas akhir terhadap keberhasilan penyelesaian tugas tertentu.
+ **C:** *Pihak yang menerima konsultasi (Consulted)* yang dimintai opini, umumnya sebagai pakar pokok pembahasan.
+ **I:** *Pihak penerima informasi (informed)* yang diberi tahu tentang progres, sering kali tentang penyelesaian tugas atau hasil.
+ **Kategorikan insiden:** Menetapkan dan mengkategorikan insiden berdasarkan skor tingkat keparahan dan dampak memungkinkan pendekatan terstruktur untuk memeriksa dan menyelesaikan insiden. Rekomendasi berikut ini menggambarkan *matriks urgensi dampak-penyelesaian* untuk memperhitungkan suatu insiden. Sebagai contoh, insiden dengan dampak rendah dan urgensi rendah dianggap sebagai insiden dengan keparahan rendah.
+ **Tinggi (H):** Bisnis Anda menerima dampak besar. Fungsi-fungsi vital aplikasi Anda terkait sumber daya AWS tidak tersedia. Dicadangkan untuk peristiwa paling kritis yang memengaruhi sistem produksi. Dampak insiden meningkat dengan cepat karena perbaikan sangat dipengaruhi oleh waktu.
+ **Sedang (M):** Sebuah layanan atau aplikasi bisnis terkait sumber daya AWS menerima dampak sedang dan berfungsi dengan penurunan kondisi. Aplikasi yang berkontribusi pada sasaran tingkat layanan (SLO) terkena dampak di dalam batas persetujuan tingkat layanan (SLA). Sistem dapat berjalan dengan penurunan kemampuan tanpa berdampak besar pada keuangan dan reputasi.
+ **Rendah (L):** Fungsi-fungsi non-vital layanan bisnis atau aplikasi Anda terkait sumber daya AWS terkena dampak. Sistem dapat berjalan dengan penurunan kemampuan dengan dampak minimal pada keuangan dan reputasi.
+ **Standardisasi kontrol keamanan:** Tujuan standardisasi kontrol keamanan adalah untuk mencapai konsistensi, keterlacakan, dan kemampuan pengulangan terkait hasil-hasil operasi. Dorong standardisasi di seluruh aktivitas utama yang vital untuk respons insiden, seperti:
+ **Manajemen identitas dan akses:** Bangun mekanisme untuk mengontrol akses ke data Anda dan mengelola hak akses untuk identitas manusia serta mesin. Perluas manajemen identitas dan akses Anda sendiri ke cloud, menggunakan keamanan terfederasi dengan masuk tunggal (single sign-on) dan hak akses berbasis peran untuk mengoptimalkan manajemen akses. Untuk rekomendasi praktik terbaik dan rencana perbaikan untuk menstandarkan manajemen akses, lihat [bagian manajemen identitas dan akses](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) laporan resmi Pilar Keamanan.
+ **Manajemen kelemahan:** Bangun mekanisme untuk mengidentifikasi kelemahan dalam lingkungan AWS Anda yang kemungkinan dapat dimanfaatkan oleh penyerang untuk mengganggu dan menyalahgunakan sistem Anda. Implementasikan kontrol deteksi dan preventif sebagai mekanisme keamanan untuk merespons dan memitigasi potensi dampak insiden keamanan. Standarkan proses seperti pemodelan ancaman sebagai bagian dari pembangunan infrastruktur dan siklus hidup penyampaian aplikasi Anda.
+ **Manajemen konfigurasi:** Tetapkan konfigurasi standar dan otomatiskan prosedur untuk men-deploy sumber daya di AWS Cloud. Menstandarkan pengadaan infrastruktur dan sumber daya dapat membantu memitigasi risiko kesalahan konfigurasi melalui deployment yang salah atau kesalahan konfigurasi manusiawi yang tidak disengaja. Lihat [bagian prinsip desain](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) laporan resmi Pilar Keunggulan Operasional untuk mendapatkan panduan dan rendana perbaikan untuk mengimplementasikan kontrol ini.
+ **Pencatatan log dan pemantauan untuk kontrol audit:** Implementasikan mekanisme untuk memantau sumber daya Anda guna mendeteksi kegagalan, penurunan kinerja, dan masalah keamanan. Standardisasi kontrol ini juga menyediakan jejak audit aktivitas yang terjadi dalam sistem Anda, sehingga mempercepat pemeriksaan dan perbaikan masalah. Praktik terbaik di dalam [SEC 4 (“Bagaimana cara mendeteksi dan menyelidiki peristiwa keamanan?”)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) menyediakan panduan untuk mengimplementasikan kontrol ini.
+ **Gunakan otomatisasi:** Otomatisasi memungkinkan penyelesaian insiden yang cepat dalam skala besar. AWS menyediakan sejumlah layanan untuk mengotomatisasi dalam konteks strategi respons insiden. Fokus pada penemuan keseimbangan yang tepat antara otomatisasi dan campur tangan manual. Seiring Anda membangun respons insiden di dalam playbook dan runbook, otomatiskan langkah-langkah yang dapat diulang. Gunakan layanan AWS seperti Manajer Insiden AWS Systems Manager untuk [menyelesaikan insiden IT lebih cepat](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/). Gunakan [alat developer](https://aws.amazon.com/devops/) untuk menyediakan kontrol versi dan otomatiskan [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) dan deployment Infrastruktur sebagai Kode (IaC) tanpa campur tangan manusia. Jika memungkinkan, otomatiskan deteksi dan penilaian kepatuhan menggunakan layanan terkelola seperti Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM, AWS Config, dan Amazon Macie. Otomatiskan kemampuan deteksi dengan machine learning seperti Amazon DevOps Guru untuk mendeteksi masalah pola operasi yang tidak normal sebelum terjadi.
+ **Lakukan analisis akar masalah dan tindak lanjuti pelajaran yang didapatkan:** Implementasikan mekanisme untuk menyerap pelajaran yang didapatkan sebagai bagian dari peninjauan respons pascainsiden. Saat akar masalah suatu insiden mengungkap kerusakan yang lebih besar, kesalahan desain, kesalahan konfigurasi, atau kemungkinan kambuh, insiden ini diklasifikasikan sebagai masalah. Pada kasus tersebut, analisis dan selesaikan masalah untuk meminimalkan gangguan pada operasi normal.
## Sumber daya
**Dokumen terkait:**
+ [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)
**Video terkait:**
+ [Mengotomatiskan Respons Insiden dan Forensik di AWS](https://youtu.be/f_EcwmmXkXk)
+ [ Panduan mandiri untuk runbook, laporan insiden, dan respons insiden ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [ Bersiap dan merespons insiden keamanan di lingkungan AWS Anda ](https://www.youtube.com/watch?v=8uiO0Z5meCs)
**Contoh terkait:**
+ [Lab: Buku Panduan Respons Insiden dengan Jupyter - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
+ [ Lab: Respons insiden dengan Konsol AWS dan CLI ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)
# SEC10-BP03 Menyiapkan kemampuan forensik
Penting bagi tim respons insiden Anda untuk memahami kapan dan bagaimana penyelidikan forensik sesuai dengan rencana respons Anda. Organisasi Anda harus menetapkan bukti apa yang dikumpulkan dan alat-alat apa yang digunakan di dalam prosesnya. Identifikasi dan siapkan kemampuan penyelidikan forensik yang sesuai, termasuk spesialis eksternal, alat, dan otomatisasi. Keputusan utama yang harus Anda ambil di awal adalah apakah Anda akan mengumpulkan data dari sistem langsung. Beberapa data, seperti konten memori yang mudah berubah atau koneksi jaringan aktif, akan hilang jika sistem dimatikan atau dimulai ulang.
Tim respons Anda dapat menggabungkan alat, seperti AWS Systems Manager, Amazon EventBridge, dan AWS Lambda, untuk menjalankan alat-alat forensik secara otomatis di dalam sistem operasi dan mirroring lalu lintas VPC untuk mendapatkan perekaman paket jaringan, untuk mengumpulkan bukti nonpersisten. Lakukan aktivitas lain, seperti analisis log atau menganalisis image disk, di dalam akun keamanan khusus dengan stasiun kerja forensik yang dikustomisasi dan alat-alat yang dapat diakses oleh tim respons Anda.
Secara rutin kirimkan log relevan ke penyimpanan data yang menyediakan durabilitas dan integritas tinggi. Tim respons harus memiliki akses ke log-log tersebut. AWS menawarkan sejumlah alat yang dapat mempermudah penyelidikan log, seperti Amazon Athena, Amazon OpenSearch Service (OpenSearch Service), dan Amazon CloudWatch Logs Insights. Selain itu, simpan bukti secara aman menggunakan Amazon Simple Storage Service (Amazon S3) Object Lock. Layanan ini mengikuti model WORM (tulis sekali - baca banyak) dan mencegah objek dihapus atau ditimpa selama jangka waktu yang ditetapkan. Karena teknik-teknik penyelidikan forensik memerlukan pelatihan spesialis, Anda mungkin perlu melibatkan spesialis eksternal.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Identifikasi kemampuan forensik: Teliti kemampuan penyelidikan forensik organisasi Anda, alat-alat yang tersedia, dan spesialis eksternal.
+ [Mengotomatiskan Respons Insiden dan Forensik ](https://youtu.be/f_EcwmmXkXk)
## Sumber daya
**Dokumen terkait:**
+ [Cara mengotomatiskan pengumpulan disk forensik di AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
# SEC10-BP04 Mengotomatiskan kemampuan kontainer
Otomatiskan pengendalian dan pemulihan insiden untuk mempercepat waktu respons dan meminimalkan dampaknya terhadap organisasi.
Begitu Anda membuat dan mempraktikkan proses dan alat dari buku panduan Anda, Anda dapat mendekonstruksi logika menjadi solusi berbasis kode, yang dapat digunakan sebagai alat oleh beberapa staf respons untuk mengotomatiskan respons dan menghapus varian atau dugaan oleh staf respons Anda. Hal ini dapat mempercepat siklus respons. Tujuan selanjutnya adalah memungkinkan kode ini menjadi otomatis sepenuhnya dengan cara dipanggil oleh peringatan atau peristiwa sendiri, bukan oleh staf respons manusia, untuk menciptakan respons yang didorong peristiwa. Proses ini juga harus menambahkan data yang relevan secara otomatis ke sistem keamanan Anda. Misalnya, insiden yang melibatkan lalu lintas dari alamat IP yang tidak diinginkan dapat secara otomatis mengisi daftar blok WAF AWS atau grup aturan Network Firewall untuk mencegah aktivitas lebih lanjut.
![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)
*Gambar 3: AWS WAF mengotomatiskan pemblokiran alamat IP berbahaya.*
Dengan sistem respons yang didorong peristiwa, mekanisme deteksi memicu mekanisme responsif untuk memperbaiki peristiwa secara otomatis. Anda bisa menggunakan kemampuan respons yang didorong peristiwa untuk mengurangi waktu penciptaan nilai antara mekanisme deteksi dan mekanisme responsif. Untuk membuat arsitektur yang didorong peristiwa ini, Anda bisa menggunakan AWS Lambda, yang merupakan layanan komputasi nirserver yang menjalankan kode Anda ketika merespons peristiwa serta mengelola secara otomatis sumber daya komputasi dasar untuk Anda. Misalnya, anggaplah Anda memiliki akun AWS dengan layanan AWS CloudTrail yang diaktifkan. Jika AWS CloudTrail dinonaktifkan (melalui panggilan API `cloudrail:StopLogging` ), Anda bisa menggunakan Amazon EventBridge untuk memantau peristiwa `cloudrail:StopLogging` tertentu, dan memanggil fungsi AWS Lambda untuk memanggil `cloudtrail:StartLogging` untuk memulai ulang pencatatan log.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Mengotomatiskan kemampuan kontainer
## Sumber daya
**Dokumen terkait:**
+ [ Panduan Respons Insiden AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Video terkait:**
+ [Bersiap dan merespons insiden keamanan di lingkungan AWS Anda](https://youtu.be/8uiO0Z5meCs)
# 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.
**Antipola umum:**
+ Menggunakan akun root untuk merespons insiden.
+ Mengubah akun-akun pengguna yang ada.
+ Memanipulasi izin IAM secara langsung saat menyediakan peningkatan hak akses yang sedang dibutuhkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
AWS menyarankan Anda untuk sebisa mungkin mengurangi atau menghilangkan kebergantungan pada kredensial berumur panjang, dan memilih kredensial sementara dan *mekanisme* peningkatan hak akses hanya saat diperlukan. Kredensial berumur panjang rentang terkena risiko keamanan dan meningkatkan biaya overhead operasional. Untuk sebagian besar tugas manajemen, serta tugas respons insiden, kami menyarankan Anda untuk mengimplementasikan [federasi identitas](https://docs.aws.amazon.com/identity/federation/) bersamaan dengan [peningkatan 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 tersebut disetujui, pengguna menerima serangkaian [kredensial AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) sementara yang dapat digunakan untuk menyelesaikan tugas-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 tepat untuk melakukannya 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 membuat cakupan 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.
Pada kasus-kasus di atas, harus terdapat akses *mendesak (break glass)* yang dikonfigurasi untuk mengizinkan penyelidikan dan perbaikan peristiwa secara cepat. Sebaiknya gunakan juga [pengguna IAM dengan izin yang tepat](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) untuk menjalankan tugas dan mengakses sumber daya AWS. Gunakan kredensial root hanya untuk [tugas yang memerlukan akses 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 pengguna khusus sejak awal. Akun pengguna tersebut memerlukan akses istimewa, dan harus dikontrol dan dipantau secara ketat. Akun-akun tersebut harus dibuat dengan hak akses paling sedikit 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 playbook untuk memastikan pengguna respons insiden dibuat sebagai pengguna AWS Identity and Access Management 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 menegakkan [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 untu [AWS Organizations SCP](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, penting untuk tidak membagikan akun pengguna 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 kata sandi pengguna root dan token MFA.
Untuk mengonfigurasi kebijakan IAM untuk peran respons insiden, pertimbangkan menggunakan [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) untuk menghasilkan 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 pengguna respons insiden untuk mengambil [peran IAM respons insiden khusus di Akun AWS lain](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 principal pemanggil telah mengautentikasi 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 akun pengguna IAM serta IAM role disebutkan secara jelas agar dapat ditemukan dengan mudah di log CloudTrail. Contohnya adalah dengan menamai akun IAM dengan `-BREAK-GLASS` dan IAM role dengan `BREAK-GLASS-ROLE`.
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) digunakan untuk membuat log aktivitas API di akun AWS Anda dan harus digunakan untuk [mengonfigurasi peringatan 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. Instruksi dapat dimodifikasi untuk mengonfigurasi filter-ke-filter metrik [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) pada peristiwa `AssumeRole` terkait dengan IAM role 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. Sistem-sistem tersebut dapat mencakup instans Amazon Elastic Compute Cloud, basis data Amazon Relational Database Service, atau platform perangkat lunak sebagai layanan (SaaS). Sangat disarankan untuk tidak menggunakan protokol native seperti SSH atau RDP, melainkan [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) untuk semua akses administratif ke instans Amazon EC2. Akses ini dapat dikontrol menggunakan IAM, yang aman dan diaudit. Memungkinkan juga untuk mengotomatisasi bagian-bagian playbook Anda 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 mempercepat waktu 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, manajemen akun pengguna IAM perespons insiden harus ditambahkan ke [proses Joiners, Movers, dan Leavers](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) Anda dan ditinjau serta diuji secara berkala untuk memastikan bahwa yang diizinkan hanyalah akses yang diinginkan.
## 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/)
**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)
**Contoh terkait:**
+ [ Lab: Penyiapan dan Pengguna Root Akun AWS](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Lab: Respons insiden dengan Konsol AWS dan CLI ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)
# SEC10-BP06 Melakukan deployment alat di awal
Pastikan bahwa personel keamanan sejak awal telah melakukan deployment alat yang tepat ke dalam AWS untuk mengurangi waktu investigasi melalui pemulihan.
Untuk mengotomatiskan rekayasa 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. Cara efektif untuk secara otomatis menyediakan data log yang relevan dan dapat dicari di seluruh layanan AWS kepada pemberi respons insiden Anda adalah dengan mengaktifkan [Amazon Detective](https://aws.amazon.com/detective/).
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 mengeksekusi 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.
Untuk alat yang melakukan eksekusi dalam sistem operasi instans Amazon Elastic Compute Cloud (Amazon EC2), Anda harus melakukan evaluasi menggunakan AWS Systems Manager Run Command, agar Anda dapat mengadministrasikan instans dari jarak jauh secara aman menggunakan agen yang Anda instal di sistem operasi instans Amazon EC2 Anda. Hal ini memerlukan Systems Manager Agent (SSM Agent), yang diinstal secara default di banyak Amazon Machine Images (AMI). Namun, perlu diperhatikan bahwa ketika instans disusupi, respons dari alat atau agen yang berjalan pada instans tersebut tidak dapat dianggap tepercaya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
+ Melakukan deployment alat di awal: Pastikan bahwa personel keamanan memiliki alat yang tepat yang telah di-deploy di awal di AWS sehingga respons yang tepat terhadap insiden dapat dilakukan.
+ [Lab: Respons insiden dengan Konsol Manajemen AWS dan CLI ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
+ [ Lab: Buku Panduan Respons Insiden dengan Jupyter - AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
+ [ Otomatisasi Keamanan AWS](https://github.com/awslabs/aws-security-automation)
+ Implementasikan penandaan sumber daya: Tandai sumber daya dengan informasi, seperti kode untuk sumber daya yang diinvestigasi, agar Anda dapat mengidentifikasi sumber daya selama insiden.
+ [ Strategi Penandaan AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
## Sumber daya
**Dokumen terkait:**
+ [ Panduan Respons Insiden AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Video terkait:**
+ [ Panduan mandiri untuk runbook, laporan insiden, dan respons insiden ](https://youtu.be/E1NaYN_fJUo)
# SEC10-BP07 Menjalankan game day
Game day, juga disebut simulasi atau latihan, adalah acara internal yang menyediakan peluang terstruktur untuk mempraktikkan rencana dan prosedur manajemen insiden Anda selama skenario yang realistis. Acara-acara ini harus melatih tim respons menggunakan alat dan teknik yang sama yang akan digunakan dalam skenario dunia nyata - bahkan meniru lingkungan dunia nyata. Game day pada dasarnya adalah tentang bersiap-siap dan meningkatkan kemampuan respons Anda secara iteratif. Beberapa alasan Anda mungkin menemukan nilai dalam pelaksanaan aktivitas game day antara lain:
+ Memvalidasi kesiapan
+ Mengembangkan kepercayaan diri – belajar dari simulasi dan staf pelatihan
+ Mengikuti kepatuhan atau kewajiban kontraktual
+ Menghasilkan artefak untuk akreditasi
+ Menjadi tangkas – perbaikan bertahap
+ Menjadi lebih cepat dan meningkatkan alat
+ Menyempurnakan komunikasi dan eskalasi
+ Mengembangkan kenyamanan dengan hal yang langka dan tidak terduga
Untuk alasan-alasan tersebut, nilai yang didapatkan dari keikutsertaan dalam aktivitas simulasi meningkatkan efektivitas organisasi selama peristiwa yang penuh tekanan. Mengembangkan aktivitas simulasi yang realistis sekaligus bermanfaat bisa jadi sesuatu yang sulit. Meskipun menguji prosedur atau otomatisasi Anda yang menangani peristiwa yang dipahami dengan baik memiliki manfaat tertentu, sama bernilainya untuk ikut serta dalam aktivitas [Simulasi Respons Insiden Keamanan (SIRS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) kreatif untuk menguji diri Anda terhadap hal-hal tidak terduga dan melakukan perbaikan secara berkelanjutan.
Buat simulasi kustom yang disesuaikan dengan lingkungan, tim, dan alat-alat Anda. Temukan masalah dan rancang simulasi Anda seputar masalah tersebut. Masalah tersebut bisa jadi hal-hal seperti kebocoran kredensial, server yang berkomunikasi dengan sistem yang tidak diinginkan, atau kesalahan konfigurasi yang mengakibatkan paparan tanpa otorisasi. Identifikasi teknisi yang memahami organisasi Anda untuk membuat skenario serta grup lain untuk ikut serta. Skenario tersebut harus realitis dan cukup menantang untuk memberikan nilai. Skenario harus menyertakan peluang untuk melakukan praktik langsung pencatatan log, notifikasi, eskalasi, dan menjalankan runbook atau otomatisasi. Selama simulasi, tim respons Anda harus melatih keterampilan teknis dan organisasi mereka, dan pemimpin harus terlibat untuk membangun keterampilan manajemen insiden mereka. Pada akhir simulasi, rayakan upaya tim dan cari cara-cara untuk menjadwalkan, mengulangi, dan mengembangkan simulasi lebih lanjut.
[AWS telah membuat templat Runbook Respons Insiden](https://github.com/aws-samples/aws-incident-response-playbooks) yang dapat Anda gunakan bukan hanya untuk menyiapkan upaya respons Anda, melainkan juga sebagai dasar untuk simulasi. Ketika merencanakan, simulasi dapat diurai ke dalam lima fase.
**Pengumpulan bukti: **Dalam fase ini, tim akan menerima pemberitahuan melalui berbagai sarana, seperti sistem ticketing internal, pemberitahuan dari alat pemantauan, tips anonim, atau bahkan berita publik. Tim kemudian mulai meninjau log infrastruktur dan aplikasi untuk menentukan sumber gangguan. Langkah ini juga harus melibatkan eskalasi internal dan kepemimpinan insiden. Setelah diidentifikasi, tim beralih ke penanganan insiden
**Mengendalikan insiden: **Tim akan menentukan bahwa telah ada insiden dan menetapkan sumber gangguan. Tim sekarang harus melakukan tindakan untuk mengendalikannya, misalnya dengan menonaktifkan kredensial yang terganggu, mengisolasi sumber daya komputasi, atau menarik izin suatu peran.
**Menghilangkan insiden: **Setelah mereka mengendalikan insiden, tim akan berupaya memitigasi semua kelemahan dalam aplikasi atau konfigurasi infrastruktur yang sebelumnya rentan terhadap gangguan. Upaya ini dapat mencakup perotasian semua kredensial yang digunakan untuk beban kerja, memodifikasi Daftar Kontrol Akses (ACL), atau mengubah konfigurasi jaringan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
+ Jalankan [game day](https://wa.aws.amazon.com/wat.concept.gameday.en.html): Jalankan simulasi [acara](https://wa.aws.amazon.com/wat.concept.incident.en.html) respons [insiden (game day)](https://wa.aws.amazon.com/wat.concept.event.en.html) untuk berbagai ancaman yang melibatkan staf dan manajemen utama.
+ Catat pelajaran yang didapatkan: Pelajaran yang didapatkan dari pelaksanaan [game day](https://wa.aws.amazon.com/wat.concept.gameday.en.html) harus menjadi bagian dari loop umpan balik guna meningkatkan kualitas proses Anda.
## Sumber daya
**Dokumen terkait:**
+ [ Panduan Respons Insiden AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [ Pemulihan Bencana Elastis AWS](https://aws.amazon.com/cloudendure-disaster-recovery/)
**Video terkait:**
+ [ Panduan mandiri untuk runbook, laporan insiden, dan respons insiden ](https://youtu.be/E1NaYN_fJUo)