Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Respons Insiden Keamanan AWS Panduan Teknis
**Topics**
+ [Abstrak](#abstract)
+ [Apakah Anda sudah Well-Architected?](#are-you-well-architected)
+ [Pengantar](introduction.md)
+ [Persiapan](preparation.md)
+ [Operasi](operations.md)
+ [Aktivitas pascainsiden](post-incident-activity.md)
+ [Kesimpulan](conclusion.md)
+ [Kontributor](contributors.md)
+ [Lampiran A: Definisi kemampuan cloud](appendix-a-cloud-capability-definitions.md)
+ [Lampiran B: sumber daya respons AWS insiden](appendix-b-incident-response-resources.md)
+ [Pemberitahuan](notices.md)
## Abstrak
Panduan ini menyajikan ikhtisar dasar-dasar menanggapi insiden keamanan dalam lingkungan Amazon Web Services (AWS) Cloud pelanggan. Panduan ini memberikan ikhtisar tentang keamanan cloud dan konsep respons insiden serta mengidentifikasi kemampuan, layanan, dan mekanisme cloud yang tersedia bagi pelanggan yang merespons masalah keamanan.
Panduan ini ditujukan bagi mereka yang memiliki peran teknis dan mengasumsikan bahwa Anda terbiasa dengan prinsip-prinsip umum keamanan informasi, memiliki pemahaman dasar tentang respons insiden keamanan di lingkungan lokal Anda saat ini, dan memiliki keakraban dengan layanan cloud.
## Apakah Anda sudah Well-Architected?
[Kerangka Kerja AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/) membantu Anda memahami pro dan kontra dari keputusan yang Anda buat saat membangun sistem di cloud. Enam pilar dari Kerangka Kerja ini memungkinkan Anda mempelajari praktik terbaik arsitektural untuk merancang dan mengoperasikan sistem yang andal, aman, efisien, hemat biaya, dan berkelanjutan. Menggunakan [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/), tersedia tanpa biaya di [AWS Well-Architected Tool konsol](https://console.aws.amazon.com/wellarchitected), Anda dapat meninjau beban kerja Anda terhadap praktik terbaik ini dengan menjawab serangkaian pertanyaan untuk setiap pilar.
Untuk panduan lebih lanjut dari para ahli dan praktik terbaik untuk arsitektur cloud Anda—referensi penerapan arsitektur, diagram, dan laporan resmi—lihat [Pusat Arsitektur AWS](https://aws.amazon.com/architecture/).
# Pengantar
Keamanan adalah prioritas utama di AWS. AWS pelanggan mendapat manfaat dari pusat data dan arsitektur jaringan yang dibangun untuk membantu mendukung kebutuhan organisasi yang paling sensitif terhadap keamanan. AWS *memiliki model tanggung jawab bersama: AWS mengelola keamanan cloud, dan pelanggan bertanggung jawab atas keamanan *di* cloud.* Artinya, Anda memiliki kendali penuh atas implementasi keamanan Anda, termasuk akses ke beberapa alat dan layanan untuk membantu memenuhi tujuan keamanan Anda. Berbagai kemampuan ini membantu Anda menetapkan garis dasar keamanan untuk aplikasi yang berjalan di AWS Cloud.
Ketika terjadi penyimpangan dari garis dasar, misalnya karena kesalahan konfigurasi atau perubahan faktor eksternal, Anda perlu merespons dan menyelidikinya. Agar bisa melakukannya dengan baik, Anda perlu memahami konsep dasar respons insiden keamanan di lingkungan AWS Anda dan persyaratan untuk mempersiapkan, mengedukasi, dan melatih tim cloud sebelum masalah keamanan terjadi. Penting untuk mengetahui kontrol dan kemampuan mana yang dapat Anda gunakan, meninjau contoh topikal untuk mengatasi masalah potensial, dan mengidentifikasi metode remediasi yang menggunakan otomatisasi untuk meningkatkan kecepatan dan konsistensi respons. Selain itu, Anda harus memahami persyaratan kepatuhan dan peraturan karena hal ini berkaitan dengan pembuatan program respons insiden keamanan untuk memenuhi persyaratan tersebut.
Respons insiden keamanan bisa menjadi hal yang kompleks, jadi kami mendorong Anda untuk menerapkan pendekatan iteratif: mulai dengan layanan keamanan inti, bangun kemampuan deteksi dan respons dasar, kemudian kembangkan playbook untuk membuat pustaka awal mekanisme respons insiden yang dapat diiterasi dan ditingkatkan.
## Sebelum Anda mulai
Sebelum Anda mulai belajar tentang respons insiden untuk peristiwa keamanan di AWS, biasakan diri Anda dengan standar dan kerangka kerja yang relevan untuk AWS keamanan dan respons insiden. Fondasi ini akan membantu Anda memahami konsep dan praktik terbaik yang disajikan dalam panduan ini.
### AWS standar keamanan dan kerangka kerja
Untuk memulai, kami mendorong Anda untuk meninjau [Praktik Terbaik untuk Keamanan, Identitas, dan Kepatuhan, Pilar Keamanan - Kerangka Kerja AWS Well-Architected](https://aws.amazon.com/architecture/security-identity-compliance/) dan [Perspektif Keamanan dari whitepaper Ikhtisar Cloud Adoption Framework AWS (](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)CAF). AWS
AWS CAF menyediakan panduan yang mendukung koordinasi antara berbagai bagian organisasi yang bergerak ke cloud. Panduan AWS CAF dibagi menjadi beberapa area fokus, yang disebut sebagai perspektif, yang relevan untuk membangun sistem TI berbasis cloud. Perspektif keamanan menjelaskan cara menerapkan program keamanan di seluruh alur kerja, salah satunya adalah respons insiden. Dokumen ini merupakan produk dari pengalaman kami bekerja dengan pelanggan untuk membantu mereka membangun kemampuan serta program respons insiden keamanan yang efektif dan efisien.
### Standar dan kerangka kerja respons insiden industri
Whitepaper ini mengikuti standar respons insiden dan praktik terbaik dari [Computer Security Incident Handling Guide SP 800-61 r3](https://csrc.nist.gov/pubs/sp/800/61/r3/final), yang dibuat oleh National Institute of Standards and Technology (NIST). Membaca dan memahami konsep yang diperkenalkan oleh NIST adalah prasyarat yang bermanfaat. Konsep dan praktik terbaik dari panduan NIST ini akan diterapkan pada AWS teknologi dalam paper ini. Namun, skenario insiden on-premise tidak tercakup dalam panduan ini.
## AWS ikhtisar respons insiden
Sebagai awal, penting untuk memahami bagaimana operasi keamanan dan respons insiden merupakan hal yang berbeda di cloud. Untuk membangun kemampuan respons yang efektif AWS, Anda perlu memahami penyimpangan dari respons lokal tradisional dan dampaknya terhadap program respons insiden Anda. Masing-masing perbedaan ini, serta prinsip desain respons AWS insiden inti, dirinci dalam bagian ini.
### Aspek respon AWS insiden
Semua AWS pengguna dalam suatu organisasi harus memiliki pemahaman dasar tentang proses respons insiden keamanan, dan staf keamanan harus memahami bagaimana menanggapi masalah keamanan. Pendidikan, pelatihan, dan pengalaman sangat penting agar program respons insiden cloud berjalan dengan baik, dan idealnya diimplementasikan dengan baik sebelum harus menangani kemungkinan insiden keamanan. Fondasi program respons insiden yang baik di cloud adalah *Persiapan*, *Operasi*, dan *Aktivitas Pascainsiden*.
Untuk memahami setiap aspek ini, lihat deskripsi berikut:
+ **Persiapan** — Siapkan tim respons insiden Anda untuk mendeteksi dan menanggapi insiden di dalamnya AWS dengan mengaktifkan kontrol detektif dan memverifikasi akses yang tepat ke alat dan layanan cloud yang diperlukan. Selain itu, siapkan playbook yang diperlukan, baik manual maupun otomatis, untuk memverifikasi respons yang andal dan konsisten.
+ **Operasi** – Beroperasi pada peristiwa keamanan dan insiden potensial dengan mengikuti fase respons insiden NIST: mendeteksi, menganalisis, menahan, memberantas, dan memulihkan.
+ **Aktivitas pascainsiden** – Lakukan iterasi pada hasil simulasi dan peristiwa keamanan Anda untuk meningkatkan efektivitas respons Anda, sehingga respons dan investigasi yang dilakukan bisa lebih bernilai, dan mengurangi risiko lebih lanjut. Anda harus belajar dari insiden dan memiliki sikap kepemilikan yang kuat terhadap aktivitas perbaikan.
Setiap aspek ini dikupas dan dibahas secara mendetail dalam panduan ini. Diagram berikut menunjukkan alur aspek-aspek ini, selaras dengan siklus hidup respons insiden NIST yang disebutkan sebelumnya, tetapi dengan operasi yang mencakup deteksi dan analisis dengan penahanan, pemberantasan, dan pemulihan.
![\[Diagram yang menunjukkan aspek respon AWS insiden\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/images/aspects-of-incident-response.png)
### AWS prinsip respons insiden dan tujuan desain
Meskipun proses umum dan mekanisme respons insiden sebagaimana didefinisikan oleh [NIST SP 800-61 Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) sudah baik, kami mendorong Anda untuk juga mempertimbangkan tujuan desain spesifik ini, yang relevan untuk merespons insiden keamanan di lingkungan cloud:
+ **Menetapkan tujuan respons** – Bekerja sama dengan pemangku kepentingan, penasihat hukum, dan kepemimpinan organisasi untuk menentukan tujuan dalam merespons suatu insiden. Beberapa tujuan umum termasuk menahan dan memitigasi masalah, memulihkan sumber daya yang terkena dampak, menyimpan data untuk forensik, kembali ke operasi aman yang diketahui, dan belajar dari insiden.
+ **Merespons menggunakan cloud** – Menerapkan pola respons di dalam cloud, tempat peristiwa dan data terjadi.
+ **Ketahui apa yang Anda miliki dan apa yang Anda butuhkan** – Simpan log, sumber daya, snapshot, dan bukti lainnya dengan menyalin dan menyimpannya di akun cloud terpusat khusus untuk respons. Gunakan tag, metadata, dan mekanisme yang menerapkan kebijakan retensi. Anda harus memahami layanan apa yang Anda gunakan dan kemudian mengidentifikasi persyaratan untuk menyelidiki layanan tersebut. Untuk membantu Anda memahami lingkungan Anda, Anda juga dapat menggunakan tag, yang akan dibahas nanti dalam dokumen ini di bagian [Mengembangkan dan menerapkan strategi pemberian tag](develop-and-implement-tagging-strategy.md).
+ **Gunakan mekanisme deployment ulang** – Jika anomali keamanan dapat dikaitkan dengan kesalahan konfigurasi, remediasinya mungkin cukup dengan menghapus perbedaan konfigurasi ini dengan deployment ulang sumber daya menggunakan konfigurasi yang tepat. Jika teridentifikasi adanya kemungkinan penyusupan, verifikasi bahwa deployment ulang Anda mencakup mitigasi akar penyebab yang berhasil dan terverifikasi.
+ **Otomatiskan jika memungkinkan** – Ketika masalah muncul atau insiden berulang, bangun mekanisme untuk melakukan triase secara terprogram dan merespons peristiwa umum. Gunakan respons manusia untuk insiden unik, kompleks, atau sensitif yang tidak cukup dengan otomatisasi.
+ **Pilih solusi yang dapat diskalakan** – Berusahalah untuk mengimbangi skalabilitas pendekatan organisasi Anda terhadap komputasi cloud. Terapkan mekanisme deteksi dan respons yang dapat diskalakan di seluruh lingkungan Anda agar dapat memangkas waktu antara deteksi dan respons secara efektif.
+ **Pelajari dan tingkatkan proses Anda** – Bersikaplah proaktif ketika mengidentifikasi kesenjangan dalam proses, alat, atau orang Anda, dan terapkan rencana untuk memperbaikinya. Simulasi adalah metode yang aman untuk menemukan kesenjangan dan memperbaiki proses. Lihat bagian [Aktivitas pascainsiden](post-incident-activity.md) di dokumen ini untuk detail tentang cara melakukan iterasi proses Anda.
Sasaran desain ini merupakan pengingat untuk meninjau implementasi arsitektur Anda agar dapat melakukan respons insiden dan deteksi ancaman. Saat Anda merencanakan implementasi cloud Anda, pikirkan tentang menanggapi suatu insiden, idealnya dengan metodologi respons yang baik secara forensik. Dalam beberapa kasus, ini berarti Anda mungkin memiliki beberapa organisasi, akun, dan alat yang secara khusus disiapkan untuk tugas respons ini. Alat dan fungsi ini harus tersedia bagi responden insiden melalui alur deployment. Alat dan fungsi tersebut tidak boleh statis karena dapat menyebabkan risiko yang lebih besar.
### Domain insiden keamanan cloud
Untuk secara efektif mempersiapkan dan menanggapi peristiwa keamanan di AWS lingkungan Anda, Anda perlu memahami jenis insiden keamanan cloud bersama. Ada tiga domain dalam tanggung jawab pelanggan tempat insiden keamanan dapat terjadi: layanan, infrastruktur, dan aplikasi. Domain yang berbeda membutuhkan pengetahuan, alat, dan proses respons yang berbeda. Pertimbangkan domain berikut:
+ **Domain layanan** — Insiden dalam domain layanan dapat memengaruhi izin [AWS Identity and Access Management](https://aws.amazon.com/iam/)(IAM) Akun AWS, metadata sumber daya, penagihan, atau area lainnya. Peristiwa domain layanan adalah peristiwa yang Anda tanggapi secara eksklusif dengan mekanisme AWS API, atau di mana Anda memiliki akar penyebab yang terkait dengan konfigurasi atau izin sumber daya, dan mungkin memiliki logging berorientasi layanan terkait.
+ **Domain infrastruktur** – Insiden dalam domain infrastruktur mencakup data atau aktivitas terkait jaringan, seperti proses dan data pada instans [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2), lalu lintas ke instans Amazon EC2 Anda dalam cloud privat virtual (VPC), dan area lainnya, seperti kontainer atau layanan lain ke depannya. Respons Anda terhadap peristiwa domain infrastruktur sering kali melibatkan perolehan data terkait insiden untuk analisis forensik. Ini mungkin mencakup interaksi dengan sistem operasi sebuah instance, dan, dalam berbagai kasus, mungkin juga melibatkan mekanisme AWS API. Di domain infrastruktur, Anda dapat menggunakan kombinasi alat AWS API dan forensics/incident respons digital (DFIR) dalam sistem operasi tamu, seperti instans Amazon EC2 yang didedikasikan untuk melakukan analisis dan investigasi forensik. Insiden domain infrastruktur mungkin melibatkan analisis tangkapan paket jaringan, blok disk pada volume [Amazon Elastic Block Store](https://aws.amazon.com/ebs/) (Amazon EBS), atau memori volatil yang diperoleh dari sebuah instans.
+ **Domain aplikasi** – Insiden dalam domain aplikasi terjadi dalam kode aplikasi atau dalam perangkat lunak yang di-deploy untuk layanan atau infrastruktur. Domain ini harus disertakan dalam playbook deteksi dan respons ancaman cloud Anda, dan dapat menyertakan respons serupa dengan yang ada di domain infrastruktur. Dengan arsitektur aplikasi yang tepat dan bijaksana, Anda dapat mengelola domain ini dengan alat cloud dengan menggunakan akuisisi, pemulihan, dan penerapan otomatis.
Dalam domain ini, pertimbangkan aktor yang mungkin bertindak melawan AWS akun, sumber daya, atau data. Baik internal maupun eksternal, gunakan kerangka risiko untuk menentukan risiko spesifik bagi organisasi dan melakukan persiapan sebagaimana mestinya. Selain itu, Anda harus mengembangkan model ancaman, yang dapat membantu perencanaan respons insiden dan pembangunan arsitektur yang cermat.
### Perbedaan utama dari respons insiden di AWS
Respons insiden merupakan bagian integral dari strategi keamanan siber, baik on-premise maupun di cloud. Prinsip-prinsip keamanan seperti hak istimewa terkecil dan pertahanan secara mendalam dimaksudkan untuk melindungi kerahasiaan, integritas, dan ketersediaan data baik di tempat maupun di cloud. Beberapa pola respons insiden yang mendukung prinsip-prinsip keamanan ini mengikuti, termasuk retensi log, pemilihan peringatan yang berasal dari pemodelan ancaman, pengembangan playbook, serta integrasi informasi keamanan dan manajemen peristiwa (SIEM). Perbedaannya dimulai ketika pelanggan mulai merancang dan merekayasa pola-pola ini di cloud. Berikut ini adalah perbedaan utama dari respons insiden di AWS.
#### Perbedaan \$11: Keamanan sebagai tanggung jawab bersama
Tanggung jawab untuk keamanan dan kepatuhan dibagi antara AWS dan pelanggannya. Model tanggung jawab bersama ini meringankan beberapa beban operasional pelanggan karena AWS mengoperasikan, mengelola, dan mengendalikan komponen dari sistem operasi host dan lapisan virtualisasi hingga keamanan fisik fasilitas di mana layanan beroperasi. Untuk detail lebih lanjut tentang model tanggung jawab bersama, lihat dokumentasi [Model Tanggung Jawab Bersama](https://aws.amazon.com/compliance/shared-responsibility-model/).
Saat tanggung jawab bersama Anda di cloud berubah, opsi Anda untuk respons insiden juga berubah. Merencanakan dan memahami timbal balik ini serta mencocokkannya dengan kebutuhan tata kelola Anda adalah langkah penting dalam respons insiden.
Selain hubungan langsung yang Anda miliki dengan AWS, mungkin ada entitas lain yang memiliki tanggung jawab dalam model tanggung jawab khusus Anda. Misalnya, Anda mungkin memiliki unit organisasi internal yang bertanggung jawab atas beberapa aspek operasi Anda. Anda mungkin juga memiliki hubungan dengan pihak lain yang mengembangkan, mengelola, atau mengoperasikan beberapa teknologi cloud Anda.
Membuat dan menguji rencana respons insiden yang sesuai dan playbook yang sesuai dengan model operasi Anda sangatlah penting.
#### Perbedaan \$12: Domain layanan cloud
Karena perbedaan tanggung jawab keamanan yang ada di layanan cloud, diperkenalkanlah domain baru untuk insiden keamanan: domain layanan, yang dijelaskan sebelumnya di bagian [Domain insiden](#cloud-security-incident-domains). Domain layanan mencakup AWS akun pelanggan, izin IAM, metadata sumber daya, penagihan, dan area lainnya. Domain ini berbeda untuk respons insiden karena cara meresponsnya. Respons dalam domain layanan biasanya dilakukan dengan meninjau dan mengeluarkan panggilan API, bukan respons berbasis host dan berbasis jaringan tradisional. Dalam domain layanan, Anda tidak akan berinteraksi dengan sistem operasi sumber daya yang terpengaruh.
Diagram berikut menunjukkan contoh peristiwa keamanan dalam domain layanan berdasarkan anti-pola arsitektur. Dalam peristiwa ini, pengguna yang tidak sah mendapatkan kredensial keamanan jangka panjang dari pengguna IAM. Pengguna IAM memiliki kebijakan IAM yang memungkinkan mereka mengambil objek dari bucket [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3). Untuk menanggapi peristiwa keamanan ini, Anda akan menggunakan AWS APIs untuk menganalisis AWS log seperti [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)dan log akses Amazon S3. Anda juga akan menggunakan AWS APIs untuk menahan dan memulihkan dari insiden tersebut.
![\[Diagram contoh domain layanan\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/images/service-domain-example.png)
#### Perbedaan \$13: APIs untuk penyediaan infrastruktur
Perbedaan lain berasal dari [Karakteristik cloud layanan mandiri on-demand](https://csrc.nist.gov/publications/detail/sp/800-145/final). Pelanggan fasilitas utama berinteraksi dengan menggunakan RESTful API melalui titik akhir publik dan pribadi yang tersedia di banyak lokasi geografis di seluruh dunia. AWS Cloud Pelanggan dapat mengaksesnya APIs dengan AWS kredensil. Berbeda dengan kontrol akses on-premise, kredensial ini tidak harus terikat oleh jaringan atau domain Microsoft Active Directory. Kredensyal malah dikaitkan dengan prinsipal IAM di dalam akun. AWS Titik akhir API ini dapat diakses di luar jaringan perusahaan Anda, yang penting untuk dipahami ketika Anda merespons insiden di mana kredensial digunakan di luar jaringan atau geografi yang Anda harapkan.
Karena sifat berbasis API AWS, sumber log penting untuk menanggapi peristiwa keamanan adalah AWS CloudTrail, yang melacak panggilan API manajemen yang dibuat di AWS akun Anda dan di mana Anda dapat menemukan informasi tentang lokasi sumber panggilan API.
#### Perbedaan \$14: Sifat dinamis cloud
Cloud bersifat dinamis; memungkinkan Anda membuat dan menghapus sumber daya dengan cepat. Dengan penskalaan otomatis, sumber daya dapat diputar dan diputar berdasarkan peningkatan lalu lintas. Dengan infrastruktur berumur pendek dan perubahan yang serbacepat, sumber daya yang Anda selidiki mungkin sudah tidak ada lagi atau mungkin telah dimodifikasi. Memahami sifat AWS sumber daya yang fana dan bagaimana Anda dapat melacak pembuatan dan penghapusan AWS sumber daya akan menjadi penting untuk analisis insiden. Anda dapat menggunakan [AWS Config](https://aws.amazon.com/config/)untuk melacak riwayat konfigurasi AWS sumber daya Anda.
#### Perbedaan \$15: Akses data
Akses data juga berbeda di cloud. Anda tidak dapat terhubung ke server untuk mengumpulkan data yang Anda butuhkan untuk penyelidikan keamanan. Data dikumpulkan melalui kabel dan melalui panggilan API. Anda harus berlatih dan memahami cara melakukan pengumpulan data agar siap menghadapi shift ini, dan memverifikasi penyimpanan yang sesuai untuk pengumpulan dan akses yang efektif. APIs
#### Perbedaan \$16: Pentingnya otomatisasi
Agar pelanggan dapat sepenuhnya menyadari manfaat adopsi cloud, strategi operasional mereka harus menerapkan otomatisasi. Infrastructure as code (IAc) adalah pola lingkungan otomatis yang sangat efisien di mana AWS layanan dikerahkan, dikonfigurasi, dikonfigurasi ulang, dan dihancurkan menggunakan kode yang difasilitasi oleh layanan IAc asli seperti atau solusi pihak ketiga. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) Hal ini mendorong implementasi respons insiden menjadi sangat otomatis, yang diinginkan untuk menghindari kesalahan manusia, terutama saat menangani bukti. Meskipun otomatisasi digunakan di lingkungan on-premise, otomatisasi sangat penting dan lebih sederhana di AWS Cloud.
#### Mengatasi perbedaan-perbedaan ini
Untuk mengatasi perbedaan ini, ikuti langkah-langkah yang diuraikan di bagian berikutnya untuk memverifikasi bahwa program respons insiden Anda untuk orang, proses, dan teknologi dipersiapkan dengan baik.
# Persiapan
Persiapan untuk menghadapi insiden merupakan hal yang sangat penting agar respons insiden bisa dilakukan dengan cepat dan efektif. Persiapan dilakukan di tiga domain:
+ **Orang** – Dalam mempersiapkan orang-orang Anda untuk menghadapi insiden keamanan, pemangku kepentingan yang relevan perlu diidentifikasi untuk respons insiden, dan dilatih tentang respons insiden dan teknologi cloud.
+ **Proses** – Dalam mempersiapkan proses Anda untuk menghadapi insiden keamanan, perlu adanya pendokumentasian arsitektur, pengembangan rencana respons insiden menyeluruh, dan pembuatan playbook agar respons terhadap peristiwa keamanan bisa dilakukan secara konsisten.
+ **Teknologi** – Dalam mempersiapkan teknologi Anda untuk menghadapi insiden keamanan, perlu adanya pengaturan akses, agregasi dan pemantauan log yang diperlukan, penerapan mekanisme peringatan yang efektif, dan pengembangan respons serta kemampuan penyelidikan.
Setiap domain ini sama pentingnya agar respons insiden berjalan efektif. Tanpa ketiga domain ini, program respons insiden tidak akan lengkap atau efektif. Anda perlu mempersiapkan orang, proses, dan teknologi dengan integrasi yang erat agar siap menghadapi suatu insiden.
# Orang
Untuk merespons peristiwa keamanan, Anda perlu mengidentifikasi pemangku kepentingan yang akan mendukung respons terhadap peristiwa keamanan. Selain itu, sangat penting untuk respons yang efektif agar mereka dilatih tentang AWS teknologi dan AWS lingkungan Anda.
# Menentukan peran dan tanggung jawab
Menangani peristiwa keamanan membutuhkan disiplin lintas organisasi dan komitmen untuk bertindak. Dalam struktur organisasi Anda, harus ada banyak orang yang bertanggung jawab, akuntabel, dimintai pendapat, atau diinformasikan saat terjadi insiden, seperti perwakilan dari sumber daya manusia (SDM), tim eksekutif, dan hukum. Pertimbangkan peran dan tanggung jawab ini, dan apakah ada pihak ketiga yang harus dilibatkan. Perhatikan bahwa di banyak geografi, ada hukum setempat yang mengatur apa yang harus dan tidak boleh dilakukan. Meskipun upaya untuk membangun bagan yang bertanggung jawab, akuntabel, berdasarkan konsultasi, dan terinformasi (RACI) untuk rencana respons keamanan Anda terasa birokratis, hal itu memungkinkan komunikasi yang cepat dan langsung serta dengan jelas menguraikan kepemimpinan di berbagai tahap peristiwa.
Selama insiden, termasuk aplikasi dan sumber daya yang terkena dampak adalah kunci karena mereka adalah ahli materi pelajaran (SMEs) yang dapat memberikan informasi dan konteks untuk membantu dalam mengukur dampak. owners/developers Pastikan untuk mempraktikkan dan membangun hubungan dengan developer serta pemilik aplikasi sebelum Anda mengandalkan keahlian mereka untuk respons insiden. Pemilik aplikasi atau SMEs, seperti administrator atau insinyur cloud Anda, mungkin perlu bertindak dalam situasi di mana lingkungan tidak dikenal atau memiliki kompleksitas, atau di mana responden tidak memiliki akses.
Terakhir, hubungan tepercaya mungkin terlibat dalam penyelidikan atau tanggapan karena mereka dapat memberikan keahlian tambahan dan pengawasan yang berharga. Ketika tidak ada orang yang memiliki keterampilan ini dalam tim Anda sendiri, ada baiknya Anda menyewa pihak eksternal untuk bantuan.
# Melatih staf respons insiden
Melatih staf respons insiden Anda tentang teknologi yang digunakan organisasi mereka akan sangat penting agar mereka mampu merespons peristiwa keamanan secara memadai. Respons mungkin akan berlarut-larut jika anggota staf Anda tidak memahami teknologi yang mendasarinya. Selain konsep respons insiden tradisional, penting juga bagi mereka untuk memahami AWS layanan dan AWS lingkungan mereka. Ada sejumlah mekanisme tradisional untuk melatih staf insiden Anda, seperti pelatihan online dan pelatihan di ruang kelas. Anda juga dapat mempertimbangkan untuk menjalankan simulasi atau gameday sebagai mekanisme untuk pelatihan. Untuk detail tentang cara menjalankan simulasi, lihat [Menjalankan simulasi reguler](run-regular-simulations.md) bagian dokumen ini.
# Memahami AWS Cloud teknologi
Untuk mengurangi ketergantungan dan memangkas waktu respons, pastikan tim keamanan dan responden Anda diedukasi tentang layanan cloud dan memiliki kesempatan untuk praktik langsung dengan lingkungan cloud spesifik yang digunakan organisasi Anda. Agar responden insiden menjadi efektif, penting untuk memahami AWS yayasan, IAM,, layanan AWS penebangan dan pemantauan, dan layanan AWS keamanan. AWS Organizations
AWS menyediakan lokakarya keamanan online (lihat [Lokakarya AWS Keamanan](https://workshops.aws/categories/Security)) di mana Anda bisa mendapatkan pengalaman langsung dengan layanan AWS keamanan dan pemantauan. AWS juga menyediakan sejumlah opsi pelatihan dan jalur pembelajaran melalui pelatihan digital, pelatihan kelas, mitra AWS pelatihan, dan sertifikasi. Untuk mempelajari lebih lanjut, lihat [AWS Training and Certification](https://aws.amazon.com/training/).
AWS menyediakan pelatihan berbasis gratis dan berlangganan yang mendukung banyak persona dan area fokus. Kunjungi [AWS Skillbuilder](https://skillbuilder.aws/) untuk mempelajari lebih lanjut.
# Pahami AWS lingkungan Anda
Selain memahami AWS layanan, kasus penggunaannya, dan bagaimana mereka berintegrasi satu sama lain, sama pentingnya untuk memahami bagaimana AWS lingkungan organisasi Anda sebenarnya dirancang dan proses operasional apa yang ada. Sering kali, pengetahuan internal seperti ini tidak didokumentasikan dan hanya dipahami oleh beberapa pakar domain, yang dapat menciptakan ketergantungan, menghambat inovasi, dan memperlambat waktu respons.
Untuk menghindari ketergantungan ini dan mempercepat waktu respons, pengetahuan internal tentang lingkungan AWS Anda harus didokumentasikan, dapat diakses, dan dipahami oleh analis keamanan Anda. Memahami cakupan cloud Anda secara menyeluruh akan membutuhkan kolaborasi antara pemangku kepentingan keamanan yang relevan dan administrator cloud. Bagian dari mempersiapkan proses Anda untuk respons insiden mencakup mendokumentasikan dan memusatkan diagram arsitektur, yang [Mendokumentasikan dan memusatkan diagram arsitektur](document-and-centralize-architecture-diagrams.md) nantinya dalam laporan resmi ini. Namun, dari perspektif orang, penting bagi analis Anda untuk mengakses dan memahami diagram dan proses operasional yang terkait dengan lingkungan Anda AWS .
# Memahami tim AWS respons dan dukungan
## Dukungan
[Dukungan](https://aws.amazon.com/premiumsupport/)menawarkan berbagai rencana yang menyediakan akses ke alat dan keahlian yang mendukung keberhasilan dan kesehatan operasional AWS solusi Anda. Jika Anda memerlukan dukungan teknis dan lebih banyak sumber daya untuk membantu merencanakan, menerapkan, dan mengoptimalkan AWS lingkungan Anda, Anda dapat memilih paket dukungan yang paling sesuai dengan kasus AWS penggunaan Anda.
Pertimbangkan [Pusat Dukungan](https://console.aws.amazon.com/support) di Konsol Manajemen AWS (diperlukan login) sebagai titik kontak utama untuk mendapatkan dukungan untuk masalah yang memengaruhi AWS sumber daya Anda. Akses ke Dukungan dikendalikan oleh IAM. Untuk informasi selengkapnya tentang mendapatkan akses ke fitur AWS Support, lihat [Memulai dengan Dukungan](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
Selain itu, jika Anda perlu melaporkan penyalahgunaan, hubungi [tim AWS Tust and Safety](https://aws.amazon.com/forms/report-abuse).
## Insinyur Respons Insiden Keamanan
Insinyur Security Incident Response adalah AWS tim global khusus yang selalu tersedia yang memberikan dukungan kepada pelanggan selama acara keamanan aktif di sisi pelanggan [Model Tanggung Jawab AWS Bersama](https://aws.amazon.com/compliance/shared-responsibility-model/).
Ketika teknisi Security Incident Response mendukung Anda, Anda akan menerima bantuan dengan triase dan pemulihan untuk acara keamanan aktif. AWS Mereka akan membantu dalam analisis akar penyebab melalui penggunaan log AWS layanan dan memberi Anda rekomendasi untuk pemulihan. Mereka juga akan memberikan rekomendasi keamanan dan praktik terbaik untuk membantu Anda menghindari peristiwa keamanan ke depannya.
AWS pelanggan dapat melibatkan insinyur Respons Insiden Keamanan melalui [kasus AWS dukungan](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
+ **Semua Pelanggan**:
1. Akun dan penagihan
1. Layanan: Akun
1. Kategori: Keamanan
1. Keparahan: Pertanyaan umum
+ **Pelanggan dengan Dukungan paket Pengembang**:
1. Akun dan penagihan
1. Layanan: Akun
1. Kategori: Keamanan
1. Keparahan: Pertanyaan penting
+ **Pelanggan dengan Dukungan rencana Bisnis**:
1. Akun dan penagihan
1. Layanan: Akun
1. Kategori: Keamanan
1. Keparahan: Pertanyaan berdampak bisnis yang mendesak
+ **Pelanggan dengan Dukungan paket Enterprise**:
1. Akun dan penagihan
1. Layanan: Akun
1. Kategori: Keamanan
1. Keparahan: Pertanyaan risiko bisnis kritis
+ **Pelanggan dengan Respons Insiden Keamanan AWS langganan**: Buka konsol Respons Insiden Keamanan di https://console.aws.amazon.com/security-ir/
## DDoDukungan respons S
AWS penawaran [AWS Shield](https://aws.amazon.com/shield/), yang menyediakan layanan perlindungan penolakan layanan terdistribusi (DDoS) terkelola yang melindungi aplikasi web yang berjalan. AWS AWS Shield menyediakan deteksi selalu aktif dan mitigasi inline otomatis yang dapat meminimalkan waktu henti dan latensi aplikasi, sehingga tidak perlu terlibat untuk mendapatkan manfaat dari perlindungan S. Dukungan DDo Ada dua tingkatan AWS Shield: Shield Standard dan Shield Advanced. Untuk mengetahui perbedaan antara kedua tingkatan ini, lihat [Dokumentasi fitur Shield](https://aws.amazon.com/shield/features/).
## AWS Managed Services (AMS)
[AWS Managed Services](https://aws.amazon.com/managed-services/)(AMS) menyediakan pengelolaan AWS infrastruktur 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 menyebarkan serangkaian kontrol detektif keamanan dan memberikan respons pertama setiap hari terhadap peringatan. Saat peringatan dimulai, AMS mengikuti seperangkat standar playbook otomatis dan manual untuk memverifikasi respons yang konsisten. Playbook ini dibagikan kepada pelanggan AMS saat orientasi agar mereka dapat mengembangkan dan mengoordinasikan respons dengan AMS.
# Proses
Mengembangkan proses respons insiden yang menyeluruh dan jelas adalah kunci untuk program respons insiden yang sukses dan terukur. Ketika peristiwa keamanan terjadi, langkah dan alur kerja yang jelas akan membantu Anda merespons secara tepat waktu. Anda mungkin sudah memiliki proses respons insiden yang ada. Terlepas dari keadaan saat ini, penting untuk memperbarui, mengulangi, dan menguji proses respons insiden Anda secara teratur.
# Mengembangkan dan menguji rencana respons insiden
Dokumen pertama yang dikembangkan untuk respons insiden adalah *rencana respons insiden*. Rencana respons insiden dirancang untuk menjadi dasar bagi program dan strategi respons insiden Anda. Rencana respons insiden adalah dokumen komprehensif yang biasanya mencakup bagian-bagian ini:
+ **ikhtisar tim respons insiden** – Menguraikan tujuan dan fungsi tim respons insiden
+ **Peran dan tanggung jawab** – Membuat daftar pemangku kepentingan respons insiden dan menjabarkan peran mereka ketika insiden terjadi
+ **Rencana komunikasi** – Detail informasi kontak dan bagaimana mekanisme komunikasi selama insiden
Ini adalah praktik terbaik untuk memiliki out-of-band komunikasi sebagai cadangan untuk komunikasi insiden. Contoh aplikasi yang menyediakan saluran out-of-band komunikasi aman adalah [AWS Wickr](https://aws.amazon.com/wickr/).
+ **Fase respons insiden dan tindakan yang harus diambil** - Menghitung fase respons insiden - misalnya, mendeteksi, menganalisis, memberantas, menahan, dan memulihkan - termasuk tindakan tingkat tinggi yang harus diambil dalam fase-fase tersebut
+ **Definisi keparahan insiden dan prioritas** – Memerinci cara mengklasifikasikan tingkat keparahan suatu insiden, bagaimana memprioritaskan insiden, lalu bagaimana definisi keparahan mempengaruhi prosedur eskalasi
Meskipun bagian-bagian ini umumnya ada di perusahaan dalam berbagai ukuran dan industri yang berbeda, rencana respons insiden akan berbeda-beda di setiap organisasi. Anda perlu membuat rencana respons insiden yang paling sesuai untuk organisasi Anda.
# Mendokumentasikan dan memusatkan diagram arsitektur
Untuk merespons peristiwa keamanan dengan cepat dan akurat, Anda perlu memahami bagaimana sistem dan jaringan Anda dirancang. Memahami pola internal ini tidak hanya penting untuk respons insiden, tetapi juga untuk memverifikasi konsistensi di seluruh aplikasi yang dirancang dengan pola tersebut, sesuai dengan praktik terbaik. Anda juga harus memverifikasi bahwa dokumentasi ini aktual dan diperbarui secara berkala sesuai pola arsitektur baru. Anda sebaiknya mengembangkan dokumentasi dan repositori internal yang menjabarkan item-item seperti:
+ **AWS struktur akun** - Anda perlu tahu:
+ Berapa banyak AWS akun yang Anda miliki?
+ Bagaimana AWS akun-akun itu diatur?
+ Siapa pemilik bisnis AWS akun tersebut?
+ Apakah Anda menggunakan Kebijakan Kontrol Layanan (SCPs)? Jika demikian, pagar pembatas organisasi apa yang diterapkan dengan menggunakan? SCPs
+ Apakah Anda membatasi Wilayah dan layanan yang dapat digunakan?
+ Apa perbedaan antara unit bisnis dan lingkungan (dev/test/prod)?
+ **AWS pola layanan**
+ AWS Layanan apa yang Anda gunakan?
+ Apa AWS layanan yang paling banyak digunakan?
+ **Pola arsitektur**
+ Arsitektur cloud apa yang Anda gunakan?
+ **AWS pola otentikasi**
+ Bagaimana developer Anda biasanya mengautentikasi ke AWS?
+ Apakah Anda menggunakan pengguna atau peran IAM (atau keduanya)? Apakah otentikasi Anda AWS terhubung ke penyedia identitas (iDP)?
+ Bagaimana Anda memetakan pengguna atau peran IAM ke karyawan atau sistem?
+ Bagaimana cara akses dicabut ketika seseorang tidak lagi diotorisasi?
+ **AWS pola otorisasi**
+ Kebijakan IAM apa yang digunakan developer Anda?
+ Apakah Anda menggunakan kebijakan berbasis sumber daya?
+ **Pencatatan dan pemantauan**
+ Sumber pencatatan apa yang Anda gunakan dan di mana sumber tersebut disimpan?
+ Apakah Anda mengumpulkan AWS CloudTrail log? Jika iya, di mana log tersebut disimpan?
+ Bagaimana Anda menanyakan CloudTrail log?
+ Apakah Anda GuardDuty mengaktifkan Amazon?
+ Bagaimana Anda mengakses GuardDuty temuan (misalnya, konsol, sistem tiket, SIEM)?
+ Apakah temuan atau peristiwa dikumpulkan dalam SIEM?
+ Apakah tiket dibuat secara otomatis?
+ Alat apa yang ada untuk menganalisis log dalam sebuah penyelidikan?
+ **Topologi jaringan**
+ Bagaimana perangkat, titik akhir, dan koneksi di jaringan Anda diatur secara fisik atau logis?
+ Bagaimana jaringan Anda terhubung AWS?
+ Bagaimana lalu lintas jaringan disaring antarlingkungan?
+ **Infrastruktur eksternal**
+ Bagaimana aplikasi yang menghadap ke luar digunakan?
+ AWS Sumber daya apa yang dapat diakses publik?
+ AWS Akun apa yang mengandung infrastruktur yang dihadapi secara eksternal?
+ Apa DDo S atau penyaringan eksternal yang ada?
Mendokumentasikan diagram dan proses teknis internal memudahkan pekerjaan analis respons insiden, membantu mereka dengan cepat memperoleh pengetahuan kelembagaan untuk merespons peristiwa keamanan. Dokumentasi proses teknis internal secara menyeluruh tidak hanya menyederhanakan investigasi keamanan, tetapi juga menyesuaikan rasionalisasi dan evaluasi proses.
# Mengembangkan playbook respons insiden
Bagian penting dari mempersiapkan proses respons insiden Anda adalah mengembangkan playbook. Playbook respons insiden memberikan serangkaian panduan preskriptif dan langkah-langkah yang harus diikuti ketika terjadi peristiwa keamanan. Struktur dan langkah yang jelas akan menyederhanakan respons dan mengurangi kemungkinan kesalahan manusia.
# Untuk apa saja playbook dibuat
Playbook sebaiknya dibuat untuk skenario insiden seperti:
+ **Insiden yang diantisipasi** – Playbook harus dibuat untuk insiden yang Anda antisipasi. Hal ini termasuk ancaman seperti denial of service (DoS), ransomware, dan pembobolan kredensial.
+ **Temuan atau peringatan keamanan yang diketahui** — Buku pedoman harus dibuat untuk temuan dan peringatan keamanan Anda yang diketahui, seperti temuan. GuardDuty Anda mungkin menerima GuardDuty temuan dan berpikir, “Sekarang apa?” Untuk mencegah kesalahan penanganan GuardDuty temuan atau mengabaikan temuan, buat buku pedoman untuk setiap temuan potensial. GuardDuty Beberapa rincian remediasi dan panduan dapat ditemukan dalam [GuardDutydokumentasi](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). Perlu dicatat bahwa tidak GuardDuty diaktifkan secara default dan menimbulkan biaya. Detail lebih lanjut tentang GuardDuty dapat ditemukan di Lampiran A: Definisi kemampuan cloud -. [Visibilitas dan peringatan](visibility-and-alerting.md)
# Apa saja yang perlu dimasukkan dalam playbook
Playbook harus berisi langkah-langkah teknis yang akan dijalankan oleh analis keamanan untuk menyelidiki dan merespons insiden keamanan potensial secara memadai.
Item yang akan disertakan dalam playbook meliputi:
+ **Gambaran umum playbook** – Skenario risiko atau insiden apa yang ditangani oleh playbook ini? Apa tujuan dari playbook ini?
+ **Prasyarat** – Log dan mekanisme deteksi apa yang diperlukan untuk skenario insiden ini? Apa notifikasi yang diharapkan?
+ **Informasi pemangku kepentingan** – Siapa yang terlibat dan apa informasi kontak mereka? Apa saja tanggung jawab setiap pemangku kepentingan?
+ **Langkah respons** – Di seluruh fase respons insiden, langkah taktis apa yang perlu diambil? Kueri apa yang perlu dijalankan analis? Kode apa yang perlu dijalankan untuk mencapai hasil yang diinginkan?
+ ** Deteksi **– Bagaimana insiden tersebut akan terdeteksi?
+ ** Analisis** – Bagaimana cakupan dampak akan ditentukan?
+ ** Tahan** – Bagaimana insiden akan diisolasi untuk membatasi cakupan?
+ ** Berantas** – Bagaimana ancaman akan dihilangkan dari lingkungan?
+ ** Pulihkan** – Bagaimana sistem atau sumber daya yang terpengaruh akan dibawa kembali ke produksi?
+ ** Hasil yang diharapkan** – Setelah kueri dan kode dijalankan, apa hasil yang diharapkan dari playbook tersebut?
Untuk memverifikasi informasi yang konsisten di setiap playbook, sebaiknya buat templat playbook yang dapat digunakan di seluruh playbook keamanan Anda yang lainnya. Beberapa item yang sudah terdaftar, seperti informasi pemangku kepentingan, dapat digunakan di beberapa playbook. Jika demikian, Anda dapat membuat dokumentasi terpusat untuk informasi tersebut dan merujuknya di dalam playbook, lalu menyebutkan perbedaan eksplisitnya di dalam playbook. Dengan begitu, Anda tidak perlu memperbarui informasi yang sama di setiap playbook Anda. Dengan membuat templat dan mengidentifikasi informasi umum atau bersama di playbook, Anda dapat menyederhanakan dan mempercepat pengembangan playbook. Terakhir, playbook Anda kemungkinan akan berkembang seiring waktu; setelah Anda memastikan bahwa langkah-langkahnya konsisten, hal ini membentuk persyaratan untuk otomatisasi.
# Contoh playbook
Sejumlah contoh playbook dapat ditemukan di Lampiran B di [Sumber daya playbook](appendix-b-incident-response-resources.md#playbook-resources). Contoh-contoh di sini dapat digunakan sebagai referensi Anda untuk playbook apa yang perlu dibuat dan apa yang perlu disertakan dalam playbook Anda. Namun, penting bagi Anda untuk membuat playbook yang menggabungkan risiko yang paling relevan dengan bisnis Anda. Anda perlu memverifikasi bahwa langkah-langkah dan alur kerja dalam playbook Anda mencakup teknologi dan proses Anda.
# Menjalankan simulasi reguler
Organisasi tumbuh dan berkembang dari waktu ke waktu, begitu pun halnya dengan ancaman. Karena itu, penting bagi Anda untuk terus meninjau kemampuan respons insiden Anda. Simulasi adalah salah satu metode yang dapat digunakan untuk melakukan penilaian ini. Simulasi menggunakan skenario peristiwa keamanan dunia nyata yang dirancang untuk meniru taktik, teknik, dan prosedur aktor ancaman (TTPs) dan memungkinkan organisasi untuk melatih dan mengevaluasi kemampuan respons insiden mereka dengan menanggapi peristiwa cyber tiruan ini karena mungkin terjadi dalam kenyataan.
Simulasi memiliki berbagai manfaat, termasuk:
+ Memvalidasi kesiapan siber dan mengembangkan kepercayaan diri responden insiden Anda.
+ Menguji akurasi dan efisiensi alat serta alur kerja.
+ Menyempurnakan metode komunikasi dan eskalasi yang selaras dengan rencana respons insiden Anda.
+ Memberikan kesempatan untuk merespons vektor yang kurang umum.
# Jenis simulasi
Ada tiga jenis simulasi utama:
+ **Latihan meja** – Pendekatan latihan meja dalam simulasi adalah sesi berbasis diskusi yang melibatkan berbagai pemangku kepentingan respons insiden untuk mempraktikkan peran dan tanggung jawab serta menggunakan alat komunikasi dan playbook yang telah ditetapkan. Fasilitasi latihan biasanya dapat dilakukan dalam sehari penuh di tempat virtual, tempat fisik, atau kombinasi. Karena sifatnya yang berbasis diskusi, latihan meja berfokus pada proses, orang, dan kolaborasi. Teknologi adalah bagian integral dari diskusi; tetapi, latihan meja umumnya tidak menggunakan alat atau skrip respons insiden yang sebenarnya.
+ **Latihan Tim Ungu** – Latihan Tim Ungu meningkatkan level kolaborasi antara tim responden insiden (*Tim Biru*) dan tim aktor ancaman simulasi (*Tim Merah*). Tim Biru umumnya terdiri dari anggota Security Operations Center (SOC), tetapi juga dapat mencakup pemangku kepentingan lain yang akan terlibat dalam peristiwa siber yang sebenarnya. Tim Merah umumnya terdiri dari tim uji penetrasi atau pemangku kepentingan utama yang dilatih dalam keamanan ofensif. Tim Merah bekerja secara kolaboratif dengan fasilitator latihan dalam merancang skenario yang akurat dan memungkinkan. Selama latihan Tim Ungu, fokus utamanya adalah pada mekanisme deteksi, alat, dan prosedur operasi standar (SOPs) yang mendukung upaya respons insiden.
+ **Latihan Tim Merah** – Dalam latihan Tim Merah, penyerang (*Tim Merah*) melakukan simulasi untuk mencapai tujuan tertentu atau serangkaian tujuan dari cakupan yang telah ditentukan sebelumnya. Pembela (*Tim Biru*) belum tentu mengetahui ruang lingkup dan durasi latihan, yang memberikan penilaian yang lebih realistis tentang bagaimana mereka akan menanggapi insiden yang sebenarnya. Karena latihan Tim Merah dapat menjadi uji invasif, Anda harus berhati-hati dan menerapkan kontrol untuk memverifikasi bahwa latihan tersebut tidak menyebabkan kerusakan nyata pada lingkungan Anda.
**catatan**
AWS mengharuskan pelanggan untuk meninjau kebijakan pengujian penetrasi yang tersedia di [situs web Pengujian Penetrasi](https://aws.amazon.com/security/penetration-testing/) sebelum mereka melakukan latihan Tim Ungu atau Tim Merah.
Tabel 1 merangkum beberapa perbedaan utama dalam jenis simulasi ini. Penting untuk dicatat bahwa definisinya secara umum dianggap lentur dan dapat disesuaikan dengan kebutuhan organisasi Anda.
*Tabel 1 — Jenis simulasi*
| | Latihan meja | Latihan Tim Ungu | Latihan Tim Merah |
| --- | --- | --- | --- |
| Ringkasan | Latihan berbasis kertas yang berfokus pada satu skenario insiden keamanan tertentu. Latihan ini dapat berupa latihan tingkat tinggi atau teknis, dan dijalankan dengan serangkaian skenario tertulis. | Penawaran yang lebih realistis dibandingkan dengan latihan meja. Selama latihan Tim Ungu, fasilitator bekerja secara kolaboratif dengan para peserta untuk meningkatkan keterlibatan latihan dan menawarkan pelatihan jika diperlukan. | Penawaran simulasi yang umumnya lebih canggih. Biasanya ada informasi yang disamarkan, sehingga para peserta mungkin tidak mengetahui semua detail latihan. |
| Sumber daya yang diperlukan | Diperlukan sumber daya teknis terbatas | Diperlukan berbagai pemangku kepentingan dan sumber daya teknis tingkat tinggi | Diperlukan berbagai pemangku kepentingan dan sumber daya teknis tingkat tinggi |
| Kompleksitas | Rendah | Sedang | Tinggi |
Pertimbangkan untuk memfasilitasi simulasi siber secara reguler. Setiap jenis latihan dapat memberikan manfaat tersendiri bagi peserta dan organisasi secara keseluruhan, sehingga Anda dapat memilih untuk memulai dengan jenis simulasi yang kurang kompleks (seperti latihan meja) lalu beralih ke jenis simulasi yang lebih kompleks (latihan Tim Merah). Anda sebaiknya memilih jenis simulasi berdasarkan kematangan keamanan, sumber daya, dan hasil yang Anda inginkan. Beberapa pelanggan mungkin tidak memilih untuk melakukan latihan Tim Merah karena kompleksitas dan biayanya.
# Siklus hidup latihan
Apa pun jenis simulasi yang Anda pilih, simulasi umumnya mengikuti langkah-langkah berikut:
1. **Menentukan elemen latihan inti** – Tentukan skenario simulasi dan tujuan simulasi. Dua hal ini harus disetujui oleh kepemimpinan.
1. **Mengidentifikasi pemangku kepentingan utama** – Latihan setidaknya membutuhkan fasilitator dan peserta latihan. Tergantung skenarionya, pemangku kepentingan tambahan seperti pimpinan dari departemen hukum, komunikasi, atau eksekutif dapat dilibatkan.
1. **Membangun dan menguji skenario** – Skenario mungkin perlu disesuaikan jika elemen tertentu tidak memungkinkan dalam pengembangannya. Tahap ini diharapkan menghasilkan skenario final.
1. **Memfasilitasi simulasi** – Jenis simulasi menentukan fasilitas yang digunakan (skenario tertulis atau skenario simulasi yang sangat teknis). Fasilitator harus menyelaraskan taktik fasilitasi mereka dengan objek latihan dan harus sebisa mungkin melibatkan semua peserta latihan agar hasilnya bisa optimal.
1. **Mengembangkan laporan setelah tindakan (AAR)** – Identifikasi area yang berjalan dengan baik, area yang dapat ditingkatkan lagi, dan potensi kesenjangan. AAR harus mengukur efektivitas simulasi serta respons tim terhadap peristiwa simulasi agar kemajuan dapat dilacak dari waktu ke waktu dengan simulasi mendatang.
# Teknologi
Jika Anda mengembangkan dan menerapkan teknologi yang tepat sebelum insiden keamanan, staf respons insiden Anda akan dapat menyelidiki, memahami ruang lingkup, dan mengambil tindakan tepat waktu.
# Kembangkan struktur AWS akun
[AWS Organizations](https://aws.amazon.com/organizations/)membantu mengelola dan mengatur AWS lingkungan secara terpusat saat Anda tumbuh dan meningkatkan AWS sumber daya. AWS Organisasi mengkonsolidasikan AWS akun Anda sehingga Anda dapat mengelolanya sebagai satu unit. Anda dapat menggunakan unit organisasi (OUs) untuk mengelompokkan akun bersama untuk mengelola sebagai satu unit.
Untuk respons insiden, akan sangat membantu untuk memiliki struktur AWS akun yang mendukung fungsi respons insiden, yang mencakup *OU keamanan dan OU* *forensik*. Dalam unit organisasi keamanan, Anda harus memiliki akun untuk:
+ **Pengarsipan log **– Menggabungkan log dalam akun AWS pengarsipan.
+ **Perkakas keamanan — Memusatkan** layanan keamanan di akun alat AWS keamanan. Akun ini beroperasi sebagai administrator yang didelegasikan untuk layanan keamanan.
Dalam forensik unit organisasi, Anda memiliki opsi untuk menerapkan satu akun forensik atau akun-akun untuk setiap Wilayah tempat Anda beroperasi, bergantung pada mana yang paling sesuai untuk model bisnis dan operasional Anda. Untuk contoh pendekatan akun per Wilayah, jika Anda hanya beroperasi di AS Timur (Virginia Utara) (us-east-1) dan AS Barat (Oregon) (us-west-2), Anda akan memiliki dua akun di forensik unit organisasi: satu untuk us-east-1 dan satu untuk us-west-2. Karena penyediaan akun baru membutuhkan waktu, akun forensik harus dibuat dan digunakan jauh sebelum insiden, sehingga bisa siap digunakan oleh responden secara efektif ketika merespons insiden.
Diagram berikut menampilkan struktur akun sampel, termasuk unit organisasi forensik dengan akun forensik per Wilayah:
![\[Diagram struktur akun per wilayah untuk respons insiden\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/images/incident-response-account-structure.png)
# Mengembangkan dan menerapkan strategi pemberian tag
Memperoleh informasi kontekstual tentang kasus penggunaan bisnis dan pemangku kepentingan internal yang relevan di sekitar AWS sumber daya bisa jadi sulit. Salah satu cara untuk melakukannya adalah dalam bentuk tag, yang menetapkan metadata ke AWS sumber daya 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 penandaan yang konsisten dapat mempercepat waktu respons dengan memungkinkan Anda mengidentifikasi dan membedakan informasi kontekstual tentang sumber daya dengan cepat. AWS Tag juga dapat berfungsi sebagai mekanisme untuk memulai otomatisasi respons. Untuk informasi lebih lanjut tentang apa yang harus diberi tag, lihat [dokumentasi tentang AWS sumber daya penandaan](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). Anda harus terlebih dahulu menentukan tag yang ingin Anda terapkan di organisasi Anda. Setelah itu, Anda akan menerapkan dan menegakkan strategi pemberian tag ini. Detail tentang implementasi dan penegakan dapat ditemukan di AWS blog [Menerapkan strategi penandaan AWS sumber daya menggunakan Kebijakan AWS Tag dan Kebijakan Kontrol Layanan (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/).
# Perbarui informasi kontak AWS akun
Untuk setiap AWS akun Anda, penting untuk memiliki informasi up-to-date kontak yang akurat sehingga pemangku kepentingan yang benar menerima pemberitahuan penting dari AWS topik seperti keamanan, penagihan, dan operasi. Untuk setiap AWS akun, Anda memiliki kontak utama dan kontak alternatif untuk keamanan, penagihan, dan operasi. Perbedaan antara kontak ini dapat ditemukan di [Panduan Referensi Manajemen AWS Akun](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate).
Untuk detail tentang mengelola kontak alternatif, lihat [AWS dokumentasi tentang menambahkan, mengubah, atau menghapus kontak alternatif](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html#manage-account-payment-alternate-contacts). Jika tim Anda mengelola penagihan, operasi, dan masalah terkait keamanan, penggunaan daftar distribusi email merupakan praktik terbaik. Dengan daftar distribusi email, ketergantungan pada satu orang bisa dihindari, karena hal ini dapat menyulitkan apabila orang tersebut sedang tidak di kantor atau sudah keluar dari perusahaan. Anda juga harus memverifikasi bahwa informasi kontak email dan akun, termasuk nomor telepon, terlindungi dengan baik untuk berjaga-jaga jika terjadi pengaturan ulang kata sandi akun root dan pengaturan ulang autentikasi multi-faktor (MFA).
Untuk pelanggan yang menggunakan AWS Organizations, administrator organisasi dapat secara terpusat mengelola kontak alternatif untuk akun anggota menggunakan akun manajemen atau akun administrator yang didelegasikan tanpa memerlukan kredensil untuk setiap akun. AWS Anda juga perlu memverifikasi bahwa akun yang baru dibuat memiliki informasi kontak yang akurat. Lihat [Perbarui kontak alternatif secara otomatis untuk posting Akun AWS blog yang baru dibuat](https://aws.amazon.com/blogs/mt/automatically-update-alternate-contacts-for-newly-created-aws-accounts/).
# Siapkan akses ke Akun AWS
Selama insiden, tim respons insiden Anda harus memiliki akses ke lingkungan dan sumber daya yang terlibat dalam insiden tersebut. Pastikan tim Anda memiliki akses yang tepat untuk melakukan tugas mereka sebelum suatu peristiwa terjadi. Untuk melakukan itu, Anda harus tahu tingkat akses apa yang dibutuhkan anggota tim Anda (misalnya, jenis tindakan apa yang mungkin mereka ambil) dan harus memberikan akses hak istimewa paling sedikit terlebih dahulu.
Untuk menerapkan dan menyediakan akses ini, Anda harus mengidentifikasi dan mendiskusikan strategi akun AWS dan strategi identitas cloud dengan arsitek cloud organisasi Anda untuk memahami metode autentikasi dan otorisasi yang dikonfigurasi. Karena kredensial ini bersifat istimewa, Anda sebaiknya mempertimbangkan untuk menggunakan alur persetujuan atau mengambil kredensial dari brankas sebagai bagian dari implementasi Anda. Setelah implementasi, Anda perlu mendokumentasikan dan menguji akses anggota tim dengan baik sebelum peristiwa terjadi untuk memastikan mereka dapat merespons tanpa penundaan.
Terakhir, pengguna yang dibuat khusus untuk merespons insiden keamanan sering kali diberi hak istimewa agar dapat memiliki akses yang memadai. Oleh karena itu, penggunaan kredensial ini harus dibatasi, dipantau, dan tidak digunakan untuk kegiatan sehari-hari.
# Memahami lanskap ancaman
## Mengembangkan model ancaman
Dengan mengembangkan model ancaman, organisasi dapat mengidentifikasi ancaman dan mitigasi sebelum pengguna yang tidak sah dapat melakukannya. Ada sejumlah strategi dan pendekatan untuk pemodelan ancaman; lihat posting blog [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/). Untuk respons insiden, model ancaman dapat membantu mengidentifikasi vektor serangan yang mungkin digunakan aktor ancaman dalam insiden. Memahami apa yang Anda pertahankan akan sangat penting agar dapat merespons dengan segera. Anda juga dapat menggunakan pemodelan AWS Partner untuk ancaman. Untuk mencari AWS pasangan, gunakan [AWS Partner Network](https://partners.amazonaws.com/).
## Mengintegrasikan dan menggunakan intelijen ancaman siber
Intelijen ancaman siber adalah data dan analisis intensi, peluang, dan kemampuan aktor ancaman. Memperoleh dan menggunakan intelijen ancaman sangat membantu untuk mendeteksi insiden sejak dini dan memahami perilaku aktor ancaman dengan lebih baik. Intelijen ancaman siber mencakup indikator statis seperti alamat IP atau hash file malware. Hal ini juga mencakup informasi tingkat tinggi, seperti pola perilaku dan intensi. Anda dapat mengumpulkan intelijen ancaman dari sejumlah vendor keamanan siber dan dari repositori sumber terbuka.
Untuk mengintegrasikan dan memaksimalkan kecerdasan ancaman untuk AWS lingkungan Anda, Anda dapat menggunakan beberapa out-of-the-box kemampuan dan mengintegrasikan daftar intelijen ancaman Anda sendiri. Amazon GuardDuty menggunakan sumber intelijen ancaman AWS internal dan pihak ketiga. AWS Layanan lain, seperti firewall dan AWS WAF aturan DNS, juga mengambil masukan dari AWS'kelompok intelijen ancaman canggih. Beberapa GuardDuty temuan dipetakan ke [MITRE ATT&CK Framework](https://attack.mitre.org/), yang memberikan informasi tentang pengamatan dunia nyata tentang taktik dan teknik musuh.
# Memilih dan mengatur log untuk analisis dan peringatan
Selama penyelidikan keamanan, Anda harus dapat meninjau log yang relevan untuk mencatat dan memahami cakupan serta garis waktu lengkap insiden tersebut. Log juga diperlukan untuk pembuatan peringatan, yang menunjukkan terjadinya tindakan tertentu yang menarik. Sangat penting untuk memilih, mengaktifkan, menyimpan, serta mengatur mekanisme kueri dan pengambilan, serta mengatur peringatan. Setiap tindakan ini ditinjau di bagian ini. Untuk detail selengkapnya, lihat posting AWS blog [Strategi pencatatan untuk respons insiden keamanan](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/).
# Memilih dan mengaktifkan sumber log
Menjelang penyelidikan keamanan, Anda perlu menangkap log yang relevan untuk merekonstruksi aktivitas secara surut di akun. AWS Pilih dan aktifkan sumber log yang relevan dengan beban kerja AWS akun mereka.
AWS CloudTrail adalah layanan logging yang melacak panggilan API yang dilakukan terhadap aktivitas AWS layanan pengambilan AWS akun. Ini diaktifkan secara default dengan retensi 90 hari peristiwa manajemen yang dapat [diambil melalui CloudTrail fasilitas Riwayat Acara](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) menggunakan Konsol Manajemen AWS, AWS CLI, atau SDK. AWS Untuk retensi dan visibilitas peristiwa data yang lebih lama, Anda perlu [membuat CloudTrail Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) dan dikaitkan dengan bucket Amazon S3, dan secara opsional, dengan CloudWatch grup log. Atau, Anda dapat membuat [CloudTrail Danau](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html), yang menyimpan CloudTrail log hingga tujuh tahun dan menyediakan fasilitas kueri berbasis SQL.
AWS merekomendasikan agar pelanggan yang menggunakan VPC mengaktifkan lalu lintas jaringan dan log DNS masing-masing menggunakan Log [Aliran VPC dan log](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) [kueri penyelesai Amazon Route 53, mengalirkannya ke bucket Amazon S3 atau grup log](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html). CloudWatch Anda dapat membuat log alur VPC untuk VPC, subnet, atau antarmuka jaringan. Untuk Log Alur VPC, Anda dapat bersikap selektif tentang bagaimana dan di mana Anda mengaktifkan Log Alur untuk mengurangi biaya.
AWS CloudTrail Log, Log Aliran VPC, dan log kueri resolver Route 53 adalah *trifecta logging dasar* untuk mendukung penyelidikan keamanan di. AWS
AWS layanan dapat menghasilkan log yang tidak ditangkap oleh trifecta logging dasar, seperti log Elastic Load Balancing AWS WAF , log, log perekam, temuan Amazon AWS Config , log audit GuardDuty Amazon Elastic Kubernetes Service (Amazon EKS), dan sistem operasi instans Amazon EC2 dan log aplikasi. Lihat daftar lengkap opsi pencatatan log dan pemantauan di [Lampiran A: Definisi kemampuan cloud](appendix-a-cloud-capability-definitions.md).
# Memilih penyimpanan log
Pilihan penyimpanan log umumnya terkait dengan alat kueri yang Anda gunakan, kemampuan retensi, pemahaman, dan biaya. Saat Anda mengaktifkan log AWS layanan, sediakan fasilitas penyimpanan; biasanya bucket atau grup CloudWatch log Amazon S3.
Bucket Amazon S3 menyediakan penyimpanan tahan lama yang hemat biaya dengan kebijakan siklus hidup opsional. Log yang disimpan di bucket Amazon S3 dapat dikueri secara native menggunakan layanan seperti Amazon Athena. Grup CloudWatch log menyediakan penyimpanan yang tahan lama dan fasilitas kueri bawaan melalui Wawasan CloudWatch Log.
# Mengidentifikasi retensi log yang sesuai
Bila Anda menggunakan bucket S3 atau grup CloudWatch log untuk menyimpan log, Anda harus menetapkan siklus hidup yang memadai untuk setiap sumber log guna mengoptimalkan biaya penyimpanan dan pengambilan. Pelanggan umumnya memiliki antara 3 dan 12 bulan log yang tersedia untuk kueri, dengan retensi hingga tujuh tahun. Pilihan ketersediaan dan retensi harus selaras dengan persyaratan keamanan Anda serta gabungan mandat hukum, peraturan, dan bisnis.
# Memilih dan menerapkan mekanisme kueri untuk log
Di AWS, layanan utama yang dapat Anda gunakan untuk menanyakan [CloudWatch log adalah Wawasan Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) untuk data yang disimpan dalam grup CloudWatch log, serta [Amazon](https://aws.amazon.com/athena/) Athena dan Layanan [ OpenSearch Amazon](https://aws.amazon.com/opensearch-service/) untuk data yang disimpan di Amazon S3. Anda juga dapat menggunakan alat kueri pihak ketiga seperti informasi keamanan dan manajemen peristiwa (SIEM).
Proses untuk memilih alat kueri log harus mempertimbangkan aspek orang, proses, dan teknologi dalam operasi keamanan Anda. Pilih alat yang memenuhi persyaratan operasional, bisnis, dan keamanan, serta dapat diakses dan dipelihara dalam jangka panjang. Perlu diingat bahwa alat kueri log bekerja secara optimal ketika jumlah log yang akan dipindai tidak melebihi batas alat. Tidak jarang pelanggan memiliki beberapa alat kueri karena kendala biaya atau teknis. Misalnya, pelanggan mungkin menggunakan SIEM pihak ketiga untuk melakukan kueri data selama 90 hari terakhir, dan menggunakan Athena untuk melakukan kueri melebihi 90 hari karena biaya penyerapan log SIEM. Apa pun implementasinya, verifikasi bahwa pendekatan Anda meminimalkan jumlah alat yang diperlukan untuk memaksimalkan efisiensi operasional, terutama selama penyelidikan peristiwa keamanan.
# Menggunakan log untuk peringatan
AWS secara native memberikan peringatan melalui layanan keamanan, seperti Amazon, GuardDuty [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), dan. AWS Config Anda juga dapat menggunakan mesin pembuat peringatan kustom untuk peringatan keamanan yang tidak tercakup oleh layanan ini atau untuk peringatan spesifik yang relevan dengan lingkungan Anda. Membangun peringatan dan deteksi ini tercakup dalam bagian bernama [Deteksi](detection.md) dalam dokumen ini.
# Mengembangkan kemampuan forensik
Menjelang insiden keamanan, pertimbangkan untuk mengembangkan kemampuan forensik guna mendukung investigasi peristiwa keamanan. [Guide to Integrating Forensic Techniques into Incident Response](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf) dari NIST menyediakan panduan tersebut.
# Forensik pada AWS
Konsep dari forensik lokal tradisional berlaku untuk. AWS[Strategi lingkungan investigasi forensik dalam](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/) posting AWS Cloud blog memberi Anda informasi penting untuk mulai memigrasikan keahlian forensik mereka ke. AWS
Setelah lingkungan dan struktur AWS akun Anda disiapkan untuk forensik, Anda akan ingin menentukan teknologi yang diperlukan untuk secara efektif melakukan metodologi forensik yang sehat di empat fase:
+ **Koleksi** — Kumpulkan AWS log yang relevan, seperti AWS CloudTrail, AWS Config, Log Aliran VPC, dan log tingkat host. Kumpulkan snapshot, backup, dan dump memori dari sumber daya yang terkena dampak. AWS
+ ** Pemeriksaan** – Memeriksa data yang dikumpulkan dengan mengekstraksi dan menilai informasi yang relevan.
+ ** Analisis** – Menganalisis data yang dikumpulkan untuk memahami insiden dan menarik kesimpulan dari insiden tersebut.
+ ** Pelaporan** – Menyajikan informasi yang dihasilkan dari fase analisis.
# Menangkap cadangan dan snapshot
Menyiapkan cadangan sistem kunci dan basis data sangat penting untuk pemulihan dari insiden keamanan dan untuk tujuan forensik. Dengan memiliki cadangan, Anda dapat memulihkan sistem Anda ke keadaan aman sebelumnya. Pada AWS, Anda dapat mengambil snapshot dari berbagai sumber daya. Snapshot memberi Anda point-in-time cadangan sumber daya tersebut. Ada banyak layanan AWS yang dapat mendukung Anda dalam pencadangan dan pemulihan. Lihat [Panduan Preskriptif Pencadangan dan Pemulihan](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) untuk detail tentang layanan ini dan pendekatan untuk pencadangan dan pemulihan. Untuk detail selengkapnya, lihat posting blog [Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/).
Terutama ketika berhubungan dengan situasi seperti ransomware, sangat penting agar cadangan Anda dilindungi dengan baik. Lihat [10 praktik terbaik keamanan teratas untuk mengamankan cadangan di](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/) posting AWS blog untuk panduan mengamankan cadangan Anda. Selain mengamankan cadangan, Anda juga sebaiknya menguji proses pencadangan dan pemulihan Anda secara teratur untuk memverifikasi bahwa teknologi dan proses yang Anda miliki berfungsi sesuai harapan.
# Otomatisasi forensik pada AWS
Ketika terjadi peristiwa keamanan, tim respons insiden Anda harus dapat mengumpulkan dan menganalisis bukti dengan cepat sambil mempertahankan akurasi untuk periode waktu yang mengitari peristiwa tersebut. Mengumpulkan bukti yang relevan di lingkungan cloud, terutama di sejumlah besar contoh dan akun secara manual merupakan hal yang menyulitkan sekaligus memakan waktu bagi tim respons insiden. Selain itu, kesalahan manusia rentan terjadi dalam pengumpulan secara manual. Untuk alasan ini, pelanggan harus mengembangkan dan menerapkan otomatisasi untuk forensik.
AWS menawarkan sejumlah sumber daya otomatisasi untuk forensik, yang dikonsolidasikan dalam Lampiran di bawah. [Sumber daya forensik](appendix-b-incident-response-resources.md#forensic-resources) Sumber daya ini adalah contoh pola forensik yang telah kami kembangkan dan telah diterapkan pelanggan. Meskipun sumber daya ini mungkin merupakan arsitektur referensi yang berguna untuk memulai, pertimbangkan untuk memodifikasinya atau membuat pola otomatisasi forensik baru berdasarkan lingkungan, persyaratan, alat, dan proses forensik Anda.
# Ringkasan item persiapan
Persiapan menyeluruh untuk merespons peristiwa keamanan sangat penting agar respons insiden bisa dilakukan tepat waktu dan efektif. Persiapan respons insiden melibatkan orang, proses, dan teknologi. Ketiga domain ini sama pentingnya dalam persiapan. Anda harus mempersiapkan dan mengembangkan program respons insiden Anda di ketiga domain tersebut.
Tabel 2 merangkum item persiapan yang dijabarkan dalam bagian ini.
* Tabel 2 – Item persiapan respons insiden*
| Domain | Item persiapan | Item tindakan |
| --- | --- | --- |
| Orang | Menentukan peran dan tanggung jawab. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Orang | Latih staf respons insiden di AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Orang | Memahami opsi AWS dukungan. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Proses | Mengembangkan rencana respons insiden. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Proses | Mendokumentasikan dan memusatkan diagram arsitektur. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Proses | Mengembangkan playbook respons insiden. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Proses | Menjalankan simulasi reguler. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Teknologi | Kembangkan struktur AWS akun. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Teknologi | Mengembangkan dan menerapkan strategi pemberian tag yang membantu responden untuk mengidentifikasi kepemilikan dan konteks temuan. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Teknologi | Perbarui informasi kontak AWS akun. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Teknologi | Siapkan akses ke AWS akun. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Teknologi | Memahami lanskap ancaman. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Teknologi | Memilih dan mengatur log. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
| Teknologi | Mengembangkan kemampuan forensik. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/preparation-summary.html) |
Pendekatan berulang direkomendasikan untuk persiapan respons insiden. Semua item persiapan ini tidak dapat dilakukan dalam waktu singkat; Anda harus membuat rencana untuk memulai dari yang kecil dan terus meningkatkan kemampuan respons insiden Anda dari waktu ke waktu.
# Operasi
Operasi adalah hal inti dalam melakukan respons insiden. Di sinilah tindakan merespons dan meremediasi insiden keamanan terjadi. Operasi meliputi lima fase berikut: *deteksi*, *analisis*, *penahanan*, *pemberantasan*, dan *pemulihan*. Deskripsi fase dan tujuan ini dapat ditemukan pada Tabel 3.
*Tabel 3 – Fase operasi*
| Fase | Tujuan |
| --- | --- |
| Deteksi | Mengidentifikasi peristiwa keamanan potensial. |
| Analisis | Tentukan apakah peristiwa keamanan adalah insiden dan menilai ruang lingkup insiden tersebut. |
| Penahanan | Meminimalkan dan membatasi cakupan peristiwa keamanan. |
| Pemberantasan | Menghapus sumber daya atau artefak tidak sah yang terkait dengan peristiwa keamanan. Menerapkan mitigasi yang menyebabkan insiden keamanan tersebut. |
| Pemulihan | Kembalikan sistem ke keadaan aman yang diketahui dan pantau sistem ini untuk memverifikasi bahwa ancaman tidak kembali. |
Fase-fase ini akan berfungsi sebagai panduan ketika Anda merespons dan beroperasi pada insiden keamanan untuk merespons dengan cara yang efektif dan kuat. Tindakan aktual yang Anda ambil akan bervariasi, tergantung insiden Anda. Insiden yang melibatkan ransomware, misalnya, akan memiliki serangkaian langkah respons yang berbeda untuk diikuti dibandingkan insiden yang melibatkan bucket Amazon S3 publik. Selain itu, fase-fase ini tidak selalu terjadi secara berurutan. Setelah penahanan dan pemberantasan, Anda mungkin perlu kembali ke analisis untuk mengetahui apakah tindakan Anda efektif.
# Deteksi
Peringatan adalah komponen utama dari fase deteksi. Ini menghasilkan pemberitahuan untuk memulai proses respons insiden berdasarkan aktivitas ancaman AWS akun yang menarik.
Akurasi peringatan merupakan hal yang menantang; terjadinya, berlangsungnya, atau akan terjadinya suatu insiden tidak selalu dapat ditentukan dengan pasti. Berikut ini beberapa alasannya:
+ Mekanisme deteksi didasarkan pada simpangan dasar, pola yang diketahui, dan pemberitahuan dari entitas internal atau eksternal.
+ Karena sifat teknologi dan manusia yang tidak dapat diprediksi, yaitu *cara* dan *aktor* insiden keamanan, garis dasar berubah seiring waktu. Pola nakal muncul melalui *taktik*, *teknik*, dan *prosedur* aktor ancaman baru atau yang dimodifikasi ()TTPs.
+ Perubahan pada orang, teknologi, dan proses tidak segera dimasukkan ke dalam proses respons insiden. Sebagian di antaranya ditemukan dalam proses penyelidikan.
# Sumber peringatan
Anda sebaiknya mempertimbangkan sumber berikut untuk menentukan peringatan:
+ **Temuan** — AWS layanan seperti [Amazon GuardDuty, Amazon](https://aws.amazon.com/guardduty/) [Macie [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), Amazon](https://aws.amazon.com/macie/) [Inspector](https://aws.amazon.com/inspector/),, [IAM Access Analyzer [AWS Config](https://aws.amazon.com/config/), [dan Network Access](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html)](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) Analyzer menghasilkan temuan yang dapat digunakan untuk membuat peringatan.
+ **Log — log** AWS layanan, infrastruktur, dan aplikasi yang disimpan di bucket Amazon S3 dan grup CloudWatch log dapat diuraikan dan dikorelasikan untuk menghasilkan peringatan.
+ **Aktivitas penagihan** – Perubahan mendadak dalam aktivitas penagihan dapat mengindikasikan adanya peristiwa keamanan. Ikuti dokumentasi tentang [Membuat alarm penagihan untuk memantau perkiraan AWS biaya Anda](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html) untuk memantau hal ini.
+ **Intelijen ancaman siber** – Jika Anda berlangganan feed intelijen ancaman siber pihak ketiga, Anda dapat menghubungkan informasi tersebut dengan alat pencatatan dan pemantauan lainnya untuk mengidentifikasi indikator potensial peristiwa.
+ **Alat partner** – Partner di AWS Partner Network (APN) menawarkan produk unggulan yang dapat membantu Anda memenuhi tujuan keamanan Anda. Untuk respons insiden, produk partner dengan deteksi dan respons titik akhir (EDR) atau SIEM dapat membantu mendukung tujuan respons insiden Anda. Untuk informasi selengkapnya, lihat [Solusi Partner Keamanan](https://aws.amazon.com/security/partner-solutions/) dan [Solusi Keamanan di AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security).
+ **AWS kepercayaan dan keamanan** — Dukungan dapat menghubungi pelanggan jika kami mengidentifikasi aktivitas kasar atau berbahaya.
+ ** Sekali kontak** – Karena sesuatu yang tidak biasa mungkin saja diperhatikan oleh pelanggan, developer, atau staf lain di organisasi Anda, penting agar Anda memiliki metode yang dikenali dan dipublikasikan dengan baik untuk menghubungi tim keamanan Anda. Pilihan populer termasuk sistem tiket, alamat email kontak, dan formulir web. Jika organisasi Anda bekerja dengan masyarakat umum, Anda mungkin juga memerlukan mekanisme kontak keamanan yang digunakan publik.
Untuk informasi selengkapnya tentang kemampuan cloud yang dapat Anda gunakan selama penyelidikan, lihat [Lampiran A: Definisi kemampuan cloud](appendix-a-cloud-capability-definitions.md) di dokumen ini.
# Deteksi sebagai bagian dari rekayasa kontrol keamanan
Mekanisme deteksi merupakan bagian integral dari pengembangan kontrol keamanan. Ketika kontrol *direktif* dan *pencegahan* ditentukan, kontrol *detektif* dan *responsif* terkait harus dibangun. Sebagai contoh, sebuah organisasi menetapkan kontrol direktif yang terkait dengan pengguna root AWS akun, yang seharusnya hanya digunakan untuk aktivitas spesifik dan sangat terdefinisi dengan baik. Mereka mengaitkannya dengan kontrol preventif yang diterapkan dengan menggunakan kebijakan kontrol layanan AWS organisasi (SCP). Jika aktivitas pengguna root di luar baseline yang diharapkan terjadi, kontrol detektif yang diterapkan dengan EventBridge aturan dan topik SNS akan memperingatkan pusat operasi keamanan (SOC). Dalam kontrol responsif, SOC memilih playbook yang sesuai, melakukan analisis, dan bekerja sampai insiden terselesaikan.
Kontrol keamanan paling baik ditentukan oleh pemodelan ancaman beban kerja yang berjalan di AWS. Tingkat kekritisan kontrol detektif akan ditetapkan dengan melihat analisis dampak bisnis (BIA) untuk beban kerja tertentu. Peringatan yang dihasilkan oleh kontrol detektif tidak ditangani saat masuk, melainkan berdasarkan kekritisan awalnya, untuk disesuaikan selama analisis. Set kekritisan awal adalah bantuan untuk menentukan prioritas; konteks terjadinya peringatan akan menentukan kekritisan yang sebenarnya. Sebagai contoh, sebuah organisasi menggunakan Amazon GuardDuty sebagai komponen kontrol detektif yang digunakan untuk instans EC2 yang merupakan bagian dari beban kerja. Temuan `Impact:EC2/SuspiciousDomainRequest.Reputation` ini dibuat, menginformasikan Anda bahwa instans Amazon EC2 yang terdaftar dalam beban kerja Anda sedang melakukan kueri terhadap nama domain yang dicurigai berbahaya. Peringatan ini ditetapkan secara default sebagai tingkat keparahan rendah, dan saat fase analisis berlangsung, ditentukan bahwa beberapa ratus instans EC2 jenis `p4d.24xlarge` telah digunakan oleh aktor yang tidak memiliki otorisasi, meningkatkan biaya operasi organisasi tersebut secara signifikan. Pada titik ini, tim respons insiden membuat keputusan untuk menyesuaikan kekritisan peringatan ini menjadi *tinggi*, meningkatkan rasa urgensi dan mempercepat tindakan lebih lanjut. Perhatikan bahwa tingkat keparahan GuardDuty temuan tidak dapat diubah.
# Menerapkan kontrol detektif
Penting untuk memahami bagaimana kontrol detektif diterapkan karena kontrol tersebut membantu menentukan bagaimana peringatan akan digunakan untuk peristiwa tertentu. Ada dua implementasi utama untuk kontrol detektif teknis:
+ **Deteksi perilaku** bergantung pada model matematika yang biasa disebut sebagai machine learning (ML) atau kecerdasan buatan (AI). Deteksi dilakukan dengan inferensi; oleh karena itu, peringatan mungkin tidak mencerminkan peristiwa yang sebenarnya.
+ **Deteksi berbasis aturan** bersifat deterministik; pelanggan dapat mengatur parameter yang tepat dari aktivitas apa yang akan memunculkan peringatan, dan itu bersifat pasti.
Implementasi modern sistem detektif, seperti sistem deteksi intrusi (IDS), umumnya memiliki dengan kedua mekanisme tersebut. Berikut adalah beberapa contoh untuk deteksi berbasis aturan dan perilaku dengan. GuardDuty
+ Ketika temuan `Exfiltration:IAMUser/AnomalousBehavior` dibuat, temuan tersebut menginformasikan bahwa “terdapat permintaan API anomali di akun Anda”. Saat Anda melihat lebih jauh ke dalam dokumentasi, ia memberi tahu Anda bahwa “Model ML mengevaluasi semua permintaan API di akun Anda dan mengidentifikasi peristiwa anomali yang terkait dengan teknik yang digunakan oleh musuh,” yang menunjukkan bahwa temuan ini bersifat perilaku.
+ Untuk temuan GuardDuty ini`Impact:S3/MaliciousIPCaller`, menganalisis panggilan API dari layanan Amazon S3 di CloudTrail, membandingkan elemen `SourceIPAddress` log dengan tabel alamat IP publik yang mencakup umpan intelijen ancaman. Setelah menemukan kecocokan langsung dengan sebuah entri, temuan akan dihasilkan.
Kami merekomendasikan untuk menerapkan campuran peringatan berbasis perilaku dan aturan, karena menerapkan peringatan berbasis aturan untuk setiap aktivitas dalam model ancaman Anda bukanlah hal yang selalu memungkinkan.
# Deteksi berbasis orang
Pada titik ini, kita telah membahas deteksi berbasis teknologi. Sumber deteksi penting lainnya berasal dari orang-orang di dalam atau di luar organisasi pelanggan. *Orang dalam* dapat didefinisikan sebagai karyawan atau kontraktor, dan *orang luar* adalah entitas seperti peneliti keamanan, penegak hukum, berita, dan media sosial.
Meskipun deteksi berbasis teknologi dapat dikonfigurasi secara sistematis, deteksi berbasis orang datang dalam berbagai bentuk seperti email, tiket, surat, kiriman berita, panggilan telepon, dan interaksi langsung. Notifikasi deteksi berbasis teknologi dapat diharapkan untuk dikirimkan secara hampir waktu nyata, tetapi deteksi berbasis orang tidak memiliki jadwal yang bisa diacu secara pasti. Sangat penting bahwa budaya keamanan menggabungkan, memfasilitasi, dan memberdayakan mekanisme deteksi berbasis orang untuk pendekatan pertahanan yang mendalam terhadap keamanan.
# Ringkasan
Dengan deteksi, penting untuk memiliki campuran peringatan berbasis aturan dan perilaku. Selain itu, Anda harus memiliki mekanisme untuk orang, baik secara internal maupun eksternal, untuk mengirimkan tiket tentang masalah keamanan. Manusia dapat menjadi salah satu sumber paling berharga untuk peristiwa keamanan, jadi penting untuk memiliki proses bagi orang untuk mengeskalasikan kekhawatirannya. Anda sebaiknya menggunakan model ancaman lingkungan Anda untuk mulai membangun deteksi. Model ancaman akan membantu Anda membangun peringatan berdasarkan ancaman yang paling relevan dengan lingkungan Anda. Terakhir, Anda dapat menggunakan kerangka kerja seperti MITRE ATT&CK untuk memahami taktik, teknik, dan prosedur aktor ancaman (). TTPs Kerangka kerja MITRE ATT&CK dapat membantu untuk digunakan sebagai bahasa umum di berbagai mekanisme deteksi Anda.
# Analisis
Log, kemampuan kueri, dan intelijen ancaman adalah beberapa komponen pendukung yang dibutuhkan oleh fase analisis. Banyak log yang digunakan untuk deteksi juga digunakan untuk analisis, dan akan memerlukan orientasi dan konfigurasi alat kueri.
# Memvalidasi, menentukan cakupan, dan menilai dampak peringatan
Selama fase analisis, analisis log komprehensif dilakukan dengan tujuan untuk memvalidasi peringatan, menentukan ruang lingkup, dan menilai dampak dari kemungkinan kompromi.
+ *Validasi* peringatan adalah titik masuk fase analisis. Responden insiden akan mencari entri log dari berbagai sumber dan langsung terlibat dengan pemilik beban kerja yang terdampak.
+ *Pencakupan* adalah langkah berikutnya, ketika semua sumber daya yang terlibat diinventarisasi dan kekritisan peringatan disesuaikan setelah pemangku kepentingan setuju bahwa peringatan tersebut tidak mungkin bersifat positif palsu.
+ Terakhir, *analisis dampak* memerinci gangguan yang sebenarnya pada bisnis.
Setelah komponen beban kerja yang terpengaruh diidentifikasi, hasil pencakupan dapat dikorelasikan dengan sasaran titik pemulihan (RPO) beban kerja terkait dan sasaran waktu pemulihan (RTO), menyesuaikan tingkat kekritisan peringatan, yang akan memulai alokasi sumber daya dan semua aktivitas yang terjadi selanjutnya. Tidak semua insiden akan secara langsung mengganggu operasi beban kerja yang mendukung proses bisnis. Insiden seperti pengungkapan data sensitif, pencurian kekayaan intelektual, atau pembajakan sumber daya (seperti dalam penambangan mata uang kripto) mungkin tidak segera menghentikan atau melemahkan proses bisnis, tetapi dapat mengakibatkan konsekuensi ke depannya.
# Memperkaya log dan temuan keamanan
## Pengayaan dengan intelijen ancaman dan konteks organisasi
Selama proses analisis, hal yang menarik untuk diamati memerlukan pengayaan untuk meningkatkan kontekstualisasi peringatan. Sebagaimana dinyatakan dalam bagian Persiapan, mengintegrasikan dan memanfaatkan intelijen ancaman siber dapat membantu untuk memahami lebih lanjut tentang temuan keamanan. Layanan intelijen ancaman digunakan untuk menetapkan reputasi dan atribut kepemilikan ke alamat IP publik, nama domain, dan hash file. Alat-alat ini tersedia sebagai layanan berbayar dan tanpa biaya.
Pelanggan yang mengadopsi Amazon Athena sebagai alat kueri log mendapatkan keuntungan dari pekerjaan AWS Glue untuk memuat informasi intelijen ancaman sebagai tabel. Tabel intelijen ancaman dapat digunakan dalam kueri SQL untuk menghubungkan elemen log seperti alamat IP dan nama domain, sehingga memberikan tampilan yang diperkaya dari data yang akan dianalisis.
AWS tidak memberikan intelijen ancaman langsung kepada pelanggan, tetapi layanan seperti Amazon GuardDuty memanfaatkan intelijen ancaman untuk pengayaan dan generasi pencarian. Anda juga dapat mengunggah daftar ancaman khusus GuardDuty berdasarkan intelijen ancaman Anda sendiri.
## Pengayaan dengan otomatisasi
Otomasi merupakan bagian integral dari AWS Cloud tata kelola. Hal ini dapat digunakan di berbagai fase siklus respons insiden.
Untuk fase deteksi, otomatisasi berbasis aturan mencocokkan pola yang menarik dari model ancaman dalam log dan mengambil tindakan yang sesuai, seperti mengirim pemberitahuan. Fase analisis dapat memanfaatkan mekanisme deteksi dan meneruskan isi peringatan ke mesin yang mampu mengueri log dan memperkaya hal-hal yang dapat diamati untuk kontekstualisasi peristiwa.
Isi peringatan, dalam bentuk fundamentalnya, terdiri dari *sumber daya* dan *identitas.* Sebagai contoh, Anda dapat menerapkan otomatisasi CloudTrail untuk kueri aktivitas AWS API yang dilakukan oleh identitas atau sumber daya badan peringatan di sekitar waktu peringatan, memberikan wawasan tambahan termasuk`eventSource`, `eventName``SourceIPAddress`, dan aktivitas API `userAgent` yang diidentifikasi. Dengan melakukan kueri ini secara otomatis, responden dapat menghemat waktu selama triase dan mendapatkan konteks tambahan untuk membantu membuat keputusan yang lebih tepat.
Lihat [Cara memperkaya temuan AWS Security Hub dengan posting blog metadata akun](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/) untuk contoh tentang cara menggunakan otomatisasi untuk memperkaya temuan keamanan dan menyederhanakan analisis.
# Mengumpulkan dan menganalisis bukti forensik
Forensik, sebagaimana disebutkan di bagian [Persiapan](preparation.md) dokumen ini, adalah proses mengumpulkan dan menganalisis artefak selama respons insiden. Pada AWS, ini berlaku untuk sumber daya domain infrastruktur seperti tangkapan paket lalu lintas jaringan, dump memori sistem operasi, dan untuk sumber daya domain layanan seperti log. AWS CloudTrail
Proses forensik memiliki karakteristik mendasar sebagai berikut:
+ **Konsisten** – Mengikuti langkah-langkah tepat yang didokumentasikan, tanpa menyimpang.
+ **Dapat Diulang** – Menciptakan hasil yang sama persis ketika diulang terhadap artefak yang sama.
+ **Menjadi Norma** – Didokumentasikan secara publik dan diadopsi secara luas.
Penting untuk mempertahankan rantai penahanan untuk artefak yang dikumpulkan selama respons insiden. Menggunakan otomatisasi dan membuat dokumentasi otomatis dari pengumpulan ini dapat membantu, selain menyimpan artefak dalam repositori hanya-baca. Analisis hanya boleh dilakukan pada replika yang tepat dari artefak yang dikumpulkan untuk menjaga integritas.
# Mengumpulkan artefak yang relevan
Dengan mempertimbangkan karakteristik ini, dan berdasarkan peringatan yang relevan serta penilaian dampak dan cakupannya, Anda perlu mengumpulkan data yang relevan untuk penyelidikan dan analisis lebih lanjut. Berbagai jenis dan sumber data yang mungkin relevan dengan investigasi, termasuk log service/control pesawat (, peristiwa data Amazon S3CloudTrail, Log Aliran VPC), data (metadata dan objek Amazon S3), dan sumber daya (database, instans Amazon EC2).
Service/control log pesawat dapat dikumpulkan untuk analisis lokal atau, idealnya, langsung ditanyakan menggunakan AWS layanan asli (jika berlaku). Data (termasuk metadata) dapat langsung ditanyakan untuk mendapatkan informasi yang relevan atau untuk memperoleh objek sumber; misalnya, gunakan untuk memperoleh bucket Amazon S3 dan metadata objek dan langsung memperoleh objek sumber. AWS CLI Sumber daya perlu dikumpulkan dengan cara yang konsisten dengan jenis sumber daya dan metode analisis yang dimaksudkan. Misalnya, database dapat dikumpulkan dengan membuat sistem yang copy/snapshot menjalankan database, membuat seluruh database itu sendiri, atau menanyakan dan mengekstrak data dan log tertentu dari database yang relevan dengan penyelidikan. copy/snapshot
Untuk instans Amazon EC2, ada set data tertentu yang harus dikumpulkan dan urutan spesifik untuk pengumpulan yang harus dilakukan guna memperoleh dan mempertahankan jumlah data terbanyak untuk analisis dan penyelidikan.
Secara khusus, urutan respons untuk memperoleh dan mempertahankan jumlah data terbanyak dari instans Amazon EC2 adalah sebagai berikut:
1. **Dapatkan metadata instans** — Dapatkan metadata instans yang relevan dengan penyelidikan dan kueri data (ID instans, jenis, alamat IP, ID, Wilayah VPC/subnet , ID Amazon Machine Image (AMI), grup keamanan yang dilampirkan, waktu peluncuran).
1. **Mengaktifkan perlindungan instans dan tag** – Aktifkan perlindungan instans seperti perlindungan dari penghentian, mengatur perilaku shutdown agar berhenti (jika diatur untuk melakukan penghentian), menonaktifkan atribut Delete on Termination untuk volume EBS yang terlampir, dan menerapkan tag yang sesuai untuk denotasi visual dan penggunaan dalam kemungkinan otomatisasi respons (misalnya, setelah menerapkan tag dengan nama `Status` dan nilai `Quarantine`, melakukan akuisisi data secara forensik dan mengisolasi instans).
1. **Mendapatkan disk (snapshot EBS)** – Dapatkan snapshot EBS dari volume EBS yang terlampir. Setiap snapshot berisi informasi yang Anda perlukan untuk memulihkan data Anda (dari saat ketika snapshot diambil) ke volume EBS baru. Lihat langkah untuk melakukan response/artifact koleksi langsung jika Anda menggunakan volume penyimpanan instance.
1. **Memperoleh memori** – Karena snapshot EBS hanya menangkap data yang telah ditulis ke volume Amazon EBS Anda, yang mungkin mengecualikan data yang disimpan atau di-cache dalam memori oleh aplikasi atau OS Anda, sangat penting untuk memperoleh gambar memori sistem menggunakan alat sumber terbuka atau komersial pihak ketiga yang sesuai untuk memperoleh data yang tersedia dari sistem.
1. **(Opsional) Lakukan pengumpulan respons langsung/artefak** — Lakukan pengumpulan data yang ditargetkan (disk/memory/logs) melalui respons langsung pada sistem hanya jika disk atau memori tidak dapat diperoleh sebaliknya, atau ada alasan bisnis atau operasional yang valid. Melakukan hal ini akan memodifikasi data sistem dan artefak yang berharga.
1. **Menonaktifkan instance** — Lepaskan instance dari grup Auto Scaling, deregister instance dari load balancer, dan sesuaikan atau terapkan profil instans bawaan dengan izin yang diminimalkan atau tanpa izin.
1. **Mengisolasi atau memuat instans** – Verifikasi bahwa instans secara efektif diisolasi dari sistem dan sumber daya lain dalam lingkungan dengan mengakhiri dan mencegah koneksi saat ini dan mendatang ke dan dari instans tersebut. Lihat bagian [Penahanan](containment.md) dari dokumen ini untuk lebih jelasnya.
1. **Pilihan responden** – Berdasarkan situasi dan tujuan, pilih salah satu dari yang berikut ini:
+ Nonaktifkan dan matikan sistem (disarankan).
Matikan sistem setelah bukti yang tersedia diperoleh untuk memverifikasi mitigasi paling efektif terhadap kemungkinan dampak masa depan terhadap lingkungan oleh instans.
+ Terus jalankan instans dalam lingkungan terisolasi yang diinstrumentasi untuk pemantauan.
Meskipun tidak direkomendasikan sebagai pendekatan standar, jika suatu situasi memerlukan pengamatan lanjutan dari instance (seperti ketika data atau indikator tambahan diperlukan untuk melakukan penyelidikan dan analisis komprehensif instance), Anda dapat mempertimbangkan untuk mematikan instance, membuat AMI dari instance, dan meluncurkan kembali instance di akun forensik khusus Anda dalam lingkungan kotak pasir yang telah diinstrumentasi sebelumnya untuk sepenuhnya diisolasi dan dikonfigurasi dengan instrumentasi untuk memfasilitasi hampir berkelanjutan pemantauan instance (untuk contoh, VPC Flow Logs atau VPC Traffic Mirroring).
**catatan**
Sangat penting untuk mengambil memori sebelum aktivitas respons langsung atau isolasi sistem atau mematikan sistem untuk mengambil data yang mudah menguap (dan berharga) yang tersedia.
# Mengembangkan narasi
Selama analisis dan investigasi, dokumentasikan tindakan yang diambil, analisis yang dilakukan, dan informasi yang diidentifikasi, untuk digunakan oleh fase berikutnya dan laporan final. Narasi ini harus ringkas dan presisi, menegaskan bahwa informasi yang relevan disertakan untuk memverifikasi pemahaman yang efektif tentang insiden tersebut dan untuk mempertahankan garis waktu yang akurat. Narasi juga membantu ketika Anda melibatkan orang-orang di luar tim respons insiden inti. Inilah contohnya:
****
*Departemen pemasaran dan penjualan menerima surat pemerasan pada 15 Maret 2022 yang menuntut pembayaran dalam mata uang kripto jika tidak ingin data yang berpotensi sensitif dibocorkan ke publik. SOC menetapkan bahwa basis data Amazon RDS milik pemasaran dan penjualan dapat diakses publik pada 20 Februari 2022. SOC mengueri log akses RDS dan menentukan bahwa alamat IP 198.51.100.23 digunakan pada 20 Februari 2022 dengan kredensial `mm03434` milik *Major Mary*, salah satu developer web. SOC mengueri Log Alur VPC dan menentukan bahwa data berukuran sekitar 256 MB keluar ke alamat IP yang sama pada tanggal yang sama (cap waktu 2022-02-20T15:50\$100Z). SOC menentukan melalui intelijen ancaman sumber terbuka bahwa kredensial saat ini tersedia dalam teks biasa di repositori publik `https[:]//example[.]com/majormary/rds-utils`.*
# Penahanan
Salah satu definisi penahanan, yang berkaitan dengan respons insiden, adalah proses atau implementasi strategi selama penanganan peristiwa keamanan yang bertindak untuk meminimalkan cakupan peristiwa keamanan dan menahan efek penggunaan yang tidak sah dalam lingkungan.
Strategi penahanan tergantung pada segudang faktor dan penerapan taktik penahanan, waktu, dan tujuannya dapat berbeda dari satu organisasi ke organisasi lain. [Panduan Penanganan Insiden Keamanan Komputer NIST SP 800-61](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) menguraikan beberapa kriteria untuk menentukan strategi penahanan yang tepat, yang meliputi:
+ Potensi kerusakan dan pencurian sumber daya
+ Kebutuhan preservasi bukti
+ Ketersediaan layanan (konektivitas jaringan, layanan yang diberikan kepada pihak eksternal)
+ Waktu dan sumber daya yang dibutuhkan untuk mengimplementasikan strategi
+ Efektivitas strategi (penahanan sebagian atau penuh)
+ Durasi solusi (solusi darurat akan dihapus dalam empat jam, solusi sementara akan dihapus dalam dua minggu, solusi permanen)
Mengenai layanan AWS, bagaimanapun, langkah-langkah penahanan mendasar dapat disuling menjadi tiga kategori:
+ ** Penahanan sumber** – Gunakan penyaringan dan perutean untuk mencegah akses dari sumber tertentu.
+ ** Teknik dan penahanan akses** – Hapus akses untuk mencegah akses tidak sah ke sumber daya yang terpengaruh.
+ ** Penahanan tujuan** – Gunakan penyaringan dan perutean untuk mencegah akses ke sumber daya target.
# Penahanan sumber
Penahanan sumber adalah penggunaan dan aplikasi penyaringan atau perutean dalam suatu lingkungan untuk mencegah akses ke sumber daya dari alamat IP sumber tertentu atau jangkauan jaringan. Contoh penahanan sumber menggunakan AWS layanan disorot di sini:
+ **Grup keamanan** — Membuat dan menerapkan grup keamanan isolasi ke instans Amazon EC2 atau menghapus aturan dari grup keamanan yang ada dapat membantu memuat lalu lintas tidak sah ke instans atau sumber daya Amazon EC2. AWS Penting untuk dicatat bahwa koneksi terlacak yang ada tidak akan dimatikan sebagai akibat dari perubahan grup keamanan - hanya lalu lintas mendatang yang akan diblokir secara efektif oleh grup keamanan baru (lihat [Playbook Respons Insiden ini](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md) dan [Pelacakan koneksi grup keamanan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) untuk informasi tambahan tentang koneksi terlacak dan tidak terlacak).
+ **Kebijakan** – Kebijakan bucket Amazon S3 dapat dikonfigurasi untuk memblokir atau mengizinkan lalu lintas dari alamat IP, rentang jaringan, atau titik akhir VPC. Kebijakan menciptakan kemampuan untuk memblokir alamat dan akses yang mencurigakan ke bucket Amazon S3. Informasi selengkapnya tentang kebijakan bucket dapat dilihat di [Menambahkan kebijakan bucket menggunakan konsol Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html).
+ **AWS WAF **Daftar kontrol akses web (web ACLs) dapat dikonfigurasi AWS WAF untuk memberikan kontrol halus atas permintaan web yang ditanggapi sumber daya. Anda dapat menambahkan alamat IP atau rentang jaringan ke set IP yang dikonfigurasi AWS WAF, dan menerapkan kondisi kecocokan, seperti blok, ke set IP. Hal ini akan memblokir permintaan web ke sumber daya jika alamat IP atau rentang jaringan dari lalu lintas asal sesuai dengan yang dikonfigurasi dalam aturan set IP.
Contoh penahanan sumber dapat dilihat pada diagram berikut ini dengan analis respons insiden yang memodifikasi grup keamanan pada instans Amazon EC2 untuk membatasi koneksi baru hanya untuk alamat IP tertentu. Sebagaimana dinyatakan dalam poin grup keamanan, koneksi terlacak yang ada tidak akan dimatikan sebagai akibat dari perubahan grup keamanan.
![\[Diagram yang menunjukkan contoh penahanan sumber\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/images/source-containment-example.png)
**catatan**
Grup Keamanan dan ACL Jaringan tidak memfilter lalu lintas ke Amazon Route 53. Saat berisi instans EC2, jika Anda ingin mencegahnya menghubungi host eksternal, pastikan Anda juga memblokir komunikasi DNS secara eksplisit.
# Teknik dan penahanan akses
Mencegah penggunaan sumber daya yang tidak sah dengan membatasi fungsi dan pengguna utama IAM dengan akses ke sumber daya. Hal ini termasuk membatasi izin pengguna utama IAM yang memiliki akses ke sumber daya; juga termasuk pencabutan kredensial keamanan sementara. Contoh teknik dan akses penahanan menggunakan AWS layanan disorot di sini:
+ **Membatasi izin** – Izin yang ditetapkan ke pengguna utama IAM harus mengikuti [Prinsip Hak Akses Paling Rendah](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). Namun, selama peristiwa keamanan aktif, Anda mungkin perlu membatasi akses ke sumber daya yang ditargetkan dari pengguna utama IAM tertentu lebih jauh. Dalam hal ini, akses ke sumber daya bisa ditahan dengan menghapus izin dari pengguna utama IAM yang akan ditahan. Ini dilakukan dengan layanan IAM dan dapat diterapkan menggunakan Konsol Manajemen AWS, AWS CLI, atau AWS SDK.
+ **Mencabut kunci** – Kunci akses IAM digunakan oleh pengguna utama IAM untuk mengakses atau mengelola sumber daya. [Ini adalah kredensil statis jangka panjang untuk menandatangani permintaan terprogram ke AWS CLI atau AWS API dan dimulai dengan awalan *AKIA* (untuk informasi tambahan, lihat bagian *Memahami awalan ID unik* di pengidentifikasi IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html) Untuk menahan akses bagi pengguna utama IAM yang kunci akses IAM-nya telah disusupi, kunci akses dapat dinonaktifkan atau dihapus. Penting untuk memperhatikan hal-hal berikut ini:
+ Kunci akses dapat diaktifkan kembali setelah dinonaktifkan.
+ Kunci akses tidak dapat dipulihkan setelah dihapus.
+ Seorang pengguna utama IAM dapat memiliki hingga dua kunci akses kapan saja.
+ Pengguna atau aplikasi yang menggunakan kunci akses akan kehilangan akses setelah kunci tersebut dinonaktifkan atau dihapus.
+ **Mencabut kredensil keamanan sementara — Kredensil** [keamanan sementara dapat digunakan oleh organisasi untuk mengontrol akses ke AWS sumber daya dan mulai dengan awalan *ASIA* (untuk informasi tambahan, lihat bagian *Memahami awalan ID unik* di pengenal IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html) Kredensial sementara biasanya digunakan oleh peran IAM dan tidak harus dirotasi atau dicabut secara eksplisit karena masa pakainya terbatas. Jika terjadi peristiwa keamanan yang melibatkan kredensial keamanan sementara sebelum masa berlaku kredensial keamanan sementara habis, Anda mungkin perlu mengubah izin efektif kredensial keamanan sementara yang ada. Hal ini dapat diselesaikan [menggunakan layanan IAM di dalam Konsol Manajemen AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html). Kredensial keamanan sementara juga dapat dikeluarkan untuk pengguna IAM (berlawanan dengan peran IAM); namun, pada saat artikel ini ditulis, tidak ada opsi untuk mencabut kredensial keamanan sementara untuk pengguna IAM di dalam Konsol Manajemen AWS. Untuk peristiwa keamanan di mana kunci akses IAM pengguna disusupi oleh pengguna yang tidak sah yang membuat kredensial keamanan sementara, kredensial keamanan sementara dapat dicabut menggunakan dua metode:
+ Lampirkan kebijakan sebaris ke pengguna IAM yang mencegah akses berdasarkan waktu penerbitan token keamanan (lihat bagian *Menolak akses ke kredensial keamanan sementara yang dikeluarkan sebelum waktu spesifik* di [Menonaktifkan izin untuk kredensial keamanan sementara](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html) untuk detail selengkapnya).
+ Hapus pengguna IAM yang memiliki kunci akses yang disusupi. Buat ulang pengguna jika diperlukan.
+ **AWS WAF**- Teknik tertentu yang digunakan oleh pengguna yang tidak sah termasuk pola lalu lintas berbahaya yang umum, seperti permintaan yang berisi injeksi SQL dan skrip lintas situs (XSS). AWS WAF dapat dikonfigurasi untuk mencocokkan dan menolak lalu lintas menggunakan teknik ini menggunakan pernyataan aturan AWS WAF bawaan.
Contoh teknik dan penahanan akses dapat dilihat pada diagram berikut, dengan responden insiden merotasi kunci akses atau menghapus kebijakan IAM untuk mencegah pengguna IAM mengakses bucket Amazon S3.
![\[Diagram yang menunjukkan contoh teknik dan penahanan akses\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/images/technique-and-access-containment.png)
# Penahanan tujuan
Penahanan tujuan adalah aplikasi penyaringan atau perutean dalam suatu lingkungan untuk mencegah akses ke host atau sumber daya yang ditargetkan. Dalam beberapa kasus, penahanan tujuan juga melibatkan suatu bentuk ketahanan untuk memverifikasi bahwa sumber daya yang sah direplikasi untuk ketersediaan; sumber daya harus dilepaskan dari bentuk-bentuk ketahanan ini untuk isolasi dan penahanan. Contoh penahanan tujuan menggunakan AWS layanan meliputi:
+ **Jaringan ACLs ** — Jaringan ACLs (jaringan ACLs) yang dikonfigurasi pada subnet yang berisi AWS sumber daya dapat memiliki aturan penolakan yang ditambahkan. Aturan penolakan ini dapat diterapkan untuk mencegah akses ke AWS sumber daya tertentu; Namun, menerapkan daftar kontrol akses jaringan (ACL jaringan) akan memengaruhi setiap sumber daya di subnet, tidak hanya sumber daya yang diakses tanpa otorisasi. Aturan yang tercantum dalam ACL jaringan diproses dalam urutan top-down, sehingga aturan pertama dalam ACL jaringan yang ada harus dikonfigurasi untuk menolak lalu lintas yang tidak sah ke sumber daya dan subnet yang ditargetkan. Atau, ACL jaringan yang sama sekali baru dapat dibuat dengan aturan penolakan tunggal untuk lalu lintas masuk dan keluar dan terkait dengan subnet yang berisi sumber daya yang ditargetkan untuk mencegah akses ke subnet menggunakan ACL jaringan baru.
+ **Mematikan sumber daya** – Mematikan sumber daya sepenuhnya dapat efektif dalam menahan efek penggunaan yang tidak sah. Mematikan sumber daya juga akan mencegah akses yang sah untuk kebutuhan bisnis dan mencegah diperolehnya data forensik yang mudah berubah, jadi ini harus merupakan keputusan yang disengaja dan harus dinilai berdasarkan kebijakan keamanan organisasi.
+ **Isolasi VPCs ** — Isolasi VPC dapat digunakan untuk menyediakan penahanan sumber daya yang efektif sambil menyediakan akses ke lalu lintas yang sah (seperti solusi anti-virus (AV) atau EDR yang memerlukan akses ke internet atau konsol manajemen eksternal). VPC isolasi dapat dikonfigurasikan terlebih dahulu sebelum peristiwa keamanan untuk mengizinkan alamat IP dan port yang valid, dan sumber daya yang ditargetkan dapat segera dipindahkan ke dalam VPC isolasi ini selama peristiwa keamanan aktif untuk menahan sumber daya sambil memungkinkan lalu lintas yang sah dikirim dan diterima oleh sumber daya yang ditargetkan selama fase respons insiden berikutnya. Aspek penting dalam menggunakan VPC isolasi adalah sumber daya, seperti instans EC2, harus dimatikan dan diluncurkan kembali di VPC isolasi yang baru sebelum digunakan. Instans EC2 yang ada tidak dapat dipindahkan ke VPC atau Zona Ketersediaan lainnya. Untuk melakukannya, ikuti langkah-langkah yang diuraikan dalam [Bagaimana cara memindahkan instans Amazon EC2 saya ke subnet, Zona Ketersediaan, atau VPC lainnya?](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/)
+ **Grup Auto Scaling dan penyeimbang beban — AWS sumber daya yang melekat pada grup Auto Scaling dan penyeimbang** beban harus dilepas dan dideregistrasi sebagai bagian dari prosedur penahanan tujuan. Detasemen dan deregistrasi AWS sumber daya dapat dilakukan dengan menggunakan,, dan SDK. Konsol Manajemen AWS AWS CLI AWS
Contoh penahanan tujuan ditunjukkan dalam diagram berikut dengan analis respons insiden menambahkan ACL jaringan ke subnet untuk memblokir permintaan koneksi jaringan dari host yang tidak sah.
![\[Diagram yang menunjukkan contoh penahanan tujuan\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/images/destination-containment.png)
# Ringkasan
Penahanan adalah salah satu langkah dari proses respons insiden dan dapat dilakukan secara manual atau otomatis. Strategi penahanan keseluruhan harus selaras dengan kebijakan keamanan organisasi dan kebutuhan bisnis, dan memverifikasi bahwa efek negatif dikurangi seefisien mungkin sebelum pemberantasan dan pemulihan.
# Pemberantasan
Pemberantasan, dalam kaitannya dengan respons insiden keamanan, adalah penghapusan sumber daya yang mencurigakan atau tidak sah dalam upaya mengembalikan akun ke kondisi aman yang diketahui. Strategi pemberantasan bergantung pada beberapa faktor, yang berkaitan dengan persyaratan bisnis untuk organisasi Anda.
Beberapa langkah pemberantasan tersedia di [NIST SP 800-61 Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final):
1. Identifikasi dan mitigasi semua kerentanan yang dieksploitasi.
1. Hapus malware, materi yang tidak pantas, dan komponen lainnya.
1. Jika ternyata ada banyak host yang terpengaruh (misalnya, infeksi malware baru), ulangi langkah-langkah deteksi dan analisis untuk mengidentifikasi semua host lain yang terkena dampak, lalu tahan dan berantas insiden untuk host-host tersebut.
Untuk AWS sumber daya, ini dapat disempurnakan lebih lanjut melalui peristiwa yang terdeteksi dan dianalisis melalui log yang tersedia atau perkakas otomatis seperti CloudWatch Log dan Amazon GuardDuty. Peristiwa-peristiwa tersebut harus menjadi dasar untuk menentukan remediasi mana yang harus dilakukan untuk memulihkan lingkungan ke kondisi aman yang diketahui.
Langkah pertama pemberantasan adalah menentukan sumber daya mana yang terpengaruh dalam akun. AWS Hal ini dicapai melalui analisis sumber data log yang tersedia, sumber daya, dan alat otomatis.
+ Identifikasi tindakan tidak sah yang diambil oleh identitas IAM di akun Anda.
+ Identifikasi akses yang tidak sah atau perubahan pada akun Anda.
+ Identifikasi pembuatan sumber daya atau pengguna IAM yang tidak sah.
+ Identifikasi sistem atau sumber daya dengan perubahan yang tidak sah.
Setelah daftar sumber daya diidentifikasi, Anda harus menilai setiap sumber daya untuk menentukan dampak bisnis jika sumber daya dihapus atau dipulihkan. Sebagai contoh, jika server web menghosting aplikasi bisnis Anda dan menghapus server tersebut akan menyebabkan waktu henti, Anda harus mempertimbangkan untuk memulihkan sumber daya dari cadangan aman yang diverifikasi atau meluncurkan ulang sistem dari AMI yang bersih sebelum menghapus server yang terkena dampak.
Setelah Anda menyimpulkan analisis dampak bisnis Anda, maka, dengan menggunakan peristiwa dari analisis log Anda, Anda harus masuk ke akun dan melakukan remediasi yang sesuai, seperti:
+ Merotasi atau menghapus kunci - langkah ini menghilangkan kemampuan aktor untuk terus melakukan aktivitas di dalam akun.
+ Merotasi kredensial pengguna IAM yang berpotensi tidak sah.
+ Menghapus sumber daya yang tidak dikenal atau tidak sah.
**penting**
Jika Anda harus menyimpan sumber daya untuk penyelidikan Anda, pertimbangkan untuk mencadangkan sumber daya tersebut. Misalnya, jika Anda harus mempertahankan instans Amazon EC2 untuk alasan peraturan, kepatuhan, atau hukum, [buat snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) sebelum menghapus instans tersebut.
+ Untuk infeksi malware, Anda mungkin perlu menghubungi vendor AWS Partner atau vendor lain. AWS tidak menawarkan alat asli untuk analisis atau penghapusan malware. Namun, jika Anda menggunakan modul GuardDuty Malware untuk Amazon EBS, maka rekomendasi mungkin tersedia untuk temuan yang disediakan.
Setelah Anda menghapus sumber daya yang teridentifikasi, AWS sarankan Anda melakukan tinjauan keamanan akun Anda. Ini dapat dilakukan dengan menggunakan AWS Config aturan, menggunakan solusi open-source seperti Prowler dan ScoutSuite, atau melalui vendor lain. Anda juga dapat mempertimbangkan untuk melakukan pemindaian kerentanan terhadap sumber daya yang digunakan publik (internet) untuk menilai risiko residual.
Pemberantasan adalah salah satu langkah dari proses respons insiden dan dapat dilakukan secara manual atau otomatis, tergantung insiden dan sumber daya yang terpengaruh. Strategi keseluruhan harus selaras dengan kebijakan keamanan dan kebutuhan bisnis organisasi, dan memverifikasi bahwa efek negatif dimitigasi saat sumber daya atau konfigurasi yang tidak sesuai dihapus.
# Pemulihan
Pemulihan adalah proses memulihkan sistem ke keadaan aman yang diketahui, memvalidasi bahwa cadangan aman atau tidak terpengaruh oleh insiden sebelum restorasi, pengujian untuk memverifikasi bahwa sistem berfungsi dengan baik setelah restorasi, dan mengatasi kerentanan yang terkait dengan peristiwa keamanan.
Urutan pemulihan bergantung pada kebutuhan organisasi Anda. Sebagai bagian dari proses pemulihan, Anda harus melakukan analisis dampak bisnis untuk menentukan, setidaknya:
+ Prioritas bisnis atau dependensi
+ Rencana restorasi
+ Autentikasi dan otorisasi
NIST SP 800-61 Computer Security Incident Handling Guide menyediakan beberapa langkah untuk memulihkan sistem, termasuk:
+ Memulihkan sistem dari cadangan bersih.
+ Verifikasi bahwa cadangan dievaluasi sebelum memulihkan ke sistem untuk memastikan bahwa infeksi tidak ada dan untuk mencegah kebangkitan peristiwa keamanan.
Cadangan harus dievaluasi secara teratur sebagai bagian dari pengujian pemulihan bencana untuk memverifikasi bahwa mekanisme cadangan berfungsi dengan baik dan integritas data memenuhi tujuan titik pemulihan.
+ Jika memungkinkan, gunakan cadangan dari sebelum stempel waktu kejadian pertama yang diidentifikasi sebagai bagian dari analisis akar masalah.
+ Membangun kembali sistem dari awal, termasuk memindahkan dari sumber tepercaya menggunakan otomatisasi, kadang-kadang di akun baru. AWS
+ Mengganti file yang disusupi dengan versi bersih.
Anda harus sangat berhati-hati saat melakukan ini. Anda harus benar-benar yakin bahwa file yang Anda pulihkan diketahui aman dan tidak terpengaruh oleh insiden tersebut
+ Menginstal patch.
+ Mengubah kata sandi.
+ Hal ini termasuk kata sandi untuk pengguna utama IAM yang mungkin telah disalahgunakan.
+ Jika memungkinkan, sebaiknya gunakan peran untuk pengguna utama dan federasi IAM sebagai bagian dari strategi hak akses paling rendah.
+ Memperketat keamanan perimeter jaringan (aturan firewall, daftar kontrol akses router batas).
Setelah sumber daya dipulihkan, penting untuk mengambil pelajaran yang dapat dipetik untuk memperbarui kebijakan, prosedur, dan panduan respons insiden.
Singkatnya, sangat penting untuk menerapkan proses pemulihan yang memfasilitasi kembalinya ke operasi aman yang diketahui. Pemulihan dapat memakan waktu lama dan membutuhkan hubungan yang erat dengan strategi penahanan untuk menyeimbangkan dampak bisnis terhadap risiko infeksi ulang. Prosedur pemulihan harus mencakup langkah-langkah untuk memulihkan sumber daya dan layanan, pengguna utama IAM, dan melakukan tinjauan keamanan akun untuk menilai risiko residual.
# Kesimpulan
Setiap fase operasi memiliki tujuan, teknik, metodologi, dan strategi yang unik. Tabel 4 merangkum fase-fase ini dan beberapa teknik serta metodologi yang tercakup dalam bagian ini.
*Tabel 4 – Fase operasi: Tujuan, teknik, dan metodologi*
| Fase | Tujuan | Teknik dan metodologi |
| --- | --- | --- |
| Deteksi | Mengidentifikasi peristiwa keamanan potensial. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/operations-conclusion.html) |
| Analisis | Menentukan apakah peristiwa keamanan tersebut merupakan insiden dan menilai cakupan insiden tersebut. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/operations-conclusion.html) |
| Penahanan | Meminimalkan dan membatasi dampak peristiwa keamanan. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/operations-conclusion.html) |
| Pemberantasan | Menghapus sumber daya atau artefak tidak sah yang terkait dengan peristiwa keamanan. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/operations-conclusion.html) |
| Pemulihan | Mengembalikan sistem ke kondisi yang diketahui baik dan pantau sistem ini untuk memastikan ancaman tidak kembali. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/security-ir/latest/userguide/operations-conclusion.html) |
# Aktivitas pascainsiden
Lanskap ancaman terus berubah dan penting agar organisasi Anda memiliki kemampuan yang juga dinamis untuk melindungi lingkungan Anda secara efektif. Kunci untuk perbaikan berkelanjutan adalah mengulangi hasil insiden dan simulasi Anda untuk meningkatkan kemampuan Anda untuk secara efektif mendeteksi, merespons, dan menyelidiki kemungkinan insiden keamanan, mengurangi kemungkinan kerentanan Anda, waktu untuk merespons, dan kembali ke operasi yang aman. Mekanisme berikut dapat membantu Anda memverifikasi bahwa organisasi Anda tetap siap dengan kemampuan dan pengetahuan terbaru untuk merespons secara efektif, apa pun situasinya.
# Menetapkan kerangka kerja untuk belajar dari insiden
Menerapkan kerangka kerja dan metodologi *pembelajaran* tidak hanya akan membantu meningkatkan kemampuan respons insiden, tetapi juga membantu mencegah insiden terulang kembali. Dengan belajar dari setiap kejadian, Anda dapat membantu menghindari terulangnya kesalahan, eksposur, atau kesalahan konfigurasi, yang tidak hanya meningkatkan postur keamanan Anda, tetapi juga meminimalkan waktu yang terbuang untuk situasi yang dapat dicegah.
Penting untuk menerapkan kerangka kerja pembelajaran dan meraih poin-poin berikut di tingkatan tinggi:
+ Kapan pembelajaran diadakan?
+ Apa saja yang terlibat dalam proses pembelajaran tersebut?
+ Bagaimana pembelajaran dilakukan?
+ Siapa yang terlibat dalam proses tersebut dan bagaimana caranya?
+ Bagaimana cara mengenali area yang perlu ditingkatkan?
+ Bagaimana Anda memastikan perbaikan dilacak dan diimplementasikan secara efektif?
Selain dari hasil tingkat tinggi yang tercantum di atas, penting untuk memastikan bahwa Anda mengajukan pertanyaan yang tepat untuk mendapatkan nilai terbaik (informasi yang mengarah pada peningkatan yang dapat ditindaklanjuti) dari proses tersebut. Pertimbangkan pertanyaan-pertanyaan ini untuk membantu Anda memulai dalam mendorong diskusi pembelajaran Anda:
+ Apa insiden yang terjadi?
+ Kapan insiden tersebut pertama kali diidentifikasi?
+ Bagaimana insiden tersebut diidentifikasi?
+ Sistem apa yang memunculkan peringatan tentang aktivitas tersebut?
+ Sistem, layanan, dan data apa yang terlibat?
+ Secara khusus, apa yang terjadi?
+ Apa yang berjalan dengan baik?
+ Apa yang tidak berjalan dengan baik?
+ Proses atau prosedur mana yang gagal atau tidak dapat diskalakan untuk merespons insiden tersebut?
+ Apa yang dapat ditingkatkan dalam bidang berikut:
+ **Orang**
+ Apakah orang-orang yang perlu dihubungi benar-benar tersedia dan apakah daftar kontak sudah aktual?
+ Apakah orang-orang tidak mendapatkan pelatihan atau tidak memiliki kemampuan yang diperlukan untuk merespons dan menyelidiki insiden tersebut secara efektif?
+ Apakah sumber daya yang sesuai siap dan tersedia?
+ **Proses**
+ Apakah proses dan prosedur diikuti?
+ Apakah proses dan prosedur didokumentasikan dan tersedia untuk (jenis) insiden ini?
+ Apakah proses dan prosedur yang diperlukan tidak ada?
+ Apakah responden dapat memperoleh akses tepat waktu ke informasi yang diperlukan untuk merespons masalah ini?
+ **Teknologi**
+ Apakah sistem peringatan yang ada mampu mengidentifikasi dan memperingatkan tentang aktivitas tersebut secara efektif?
+ Apakah peringatan yang ada perlu ditingkatkan atau apakah peringatan baru perlu dibangun untuk (jenis) insiden ini?
+ Apakah alat yang ada membuat penyelidikan (pencarian/analisis) insiden tersebut dapat dilakukan secara efektif?
+ Apa yang dapat dilakukan untuk membantu mengidentifikasi (jenis) insiden ini lebih cepat?
+ Apa yang dapat dilakukan untuk membantu mencegah (jenis) insiden ini terjadi lagi?
+ Siapa yang bertanggung jawab atas rencana peningkatan dan bagaimana cara untuk menguji apakah rencana tersebut telah diimplementasikan?
+ Apa timeline untuk monitoring/preventative kontrol/proses tambahan yang akan diimplementasikan dan diuji?
Daftar ini tidak mencakup semua; hal ini dimaksudkan untuk berfungsi sebagai titik awal guna mengidentifikasi kebutuhan organisasi dan bisnis dan bagaimana Anda dapat menganalisisnya agar dapat belajar secara efektif dari insiden dan terus meningkatkan postur keamanan Anda. Yang paling penting adalah memulai dengan memasukkan pembelajaran yang diambil sebagai bagian standar dari proses respons insiden, dokumentasi, dan ekspektasi di seluruh pemangku kepentingan.
# Menetapkan metrik keberhasilan
Metrik diperlukan untuk mengukur, menilai, dan meningkatkan kemampuan respons insiden Anda secara efektif. Tanpa metrik, Anda tidak memiliki referensi untuk mengukur secara akurat atau bahkan mengidentifikasi seberapa baik (atau buruk) performa organisasi Anda. Ada beberapa metrik umum untuk respons insiden yang merupakan titik awal yang baik bagi organisasi yang ingin menetapkan ekspektasi serta referensi untuk berupaya mewujudkan keunggulan operasional.
# Waktu rata-rata untuk mendeteksi
*Waktu rata-rata untuk mendeteksi* adalah waktu rata-rata yang diperlukan untuk menemukan kemungkinan insiden keamanan. Secara khusus, ini adalah waktu antara terjadinya indikator penyusupan pertama dan identifikasi atau peringatan awal.
Anda dapat menggunakan metrik ini untuk melacak seberapa efektif performa sistem deteksi dan peringatan Anda. Mekanisme deteksi dan peringatan yang efektif adalah kunci untuk memverifikasi bahwa kemungkinan insiden keamanan tidak berlangsung lama di lingkungan Anda.
Makin tinggi waktu rata-rata deteksi, makin besar kebutuhan untuk membangun peringatan dan mekanisme tambahan atau yang lebih efektif untuk mengidentifikasi dan menemukan kemungkinan insiden keamanan. Makin rendah waktu rata-rata deteksi, makin baik fungsi mekanisme deteksi dan peringatan Anda.
# Waktu rata-rata untuk mengakui
*Waktu rata-rata untuk mengakui* adalah waktu rata-rata yang diperlukan untuk mengakui dan memprioritaskan kemungkinan insiden keamanan. Secara khusus, ini adalah waktu antara pembuatan peringatan dan anggota SOC Anda atau staf respons insiden mengidentifikasi dan memprioritaskan peringatan untuk diproses.
Anda dapat menggunakan metrik ini untuk melacak seberapa baik tim Anda memproses dan memprioritaskan peringatan. Jika tim Anda tidak dapat mengidentifikasi dan memprioritaskan peringatan secara efektif, respons akan tertunda dan menjadi tidak efektif.
Makin tinggi waktu rata-rata untuk mengakui, makin besar kebutuhan untuk memverifikasi bahwa tim Anda memiliki sumber daya yang memadai dan terlatih untuk dengan cepat mengetahui dan memprioritaskan kemungkinan insiden keamanan untuk direspons. Makin rendah waktu rata-rata untuk mengakui, makin baik tim Anda dalam merespons peringatan keamanan, yang menunjukkan bahwa mereka melakukan persiapan secara efektif dan mampu menentukan prioritas dengan baik.
# Waktu rata-rata untuk merespons
Waktu rata-rata untuk merespons adalah waktu rata-rata yang diperlukan untuk memulai respons awal terhadap kemungkinan insiden keamanan. Secara khusus, ini adalah waktu antara peringatan awal atau penemuan kemungkinan insiden keamanan dan tindakan pertama yang diambil untuk merespons. Ini mirip dengan waktu rata-rata untuk mengakui, tetapi ini merupakan pengukuran tindakan responsif tertentu (misalnya, memperoleh data sistem, menahan sistem), bukan pengenalan atau pengakuan sederhana atas situasinya.
Anda dapat menggunakan metrik ini untuk melacak kesiapan Anda dalam merespons insiden keamanan. Seperti disebutkan, persiapan adalah kunci untuk respons yang efektif. Lihat bagian [Persiapan](preparation.md) dari dokumen ini.
Makin tinggi waktu rata-rata untuk merespons, makin besar kebutuhan untuk memverifikasi bahwa tim Anda dilatih dengan baik tentang cara merespons sehingga proses respons didokumentasikan dan digunakan secara efektif. Makin rendah waktu rata-rata untuk merespons, makin baik tim Anda dalam mengidentifikasi respons yang tepat terhadap peringatan yang teridentifikasi dan melakukan tindakan responsif yang diperlukan untuk memulai pengembalian ke operasi yang aman.
# Waktu rata-rata untuk menahan
*Waktu rata-rata untuk menahan* adalah waktu rata-rata yang diperlukan untuk menahan kemungkinan insiden keamanan. Secara khusus, ini adalah waktu antara peringatan awal atau penemuan kemungkinan insiden keamanan dan penyelesaian tindakan responsif yang secara efektif mencegah penyerang atau sistem yang dikompromikan dari melakukan kerusakan lebih lanjut.
Anda dapat menggunakan metrik ini untuk melacak seberapa baik tim Anda dapat memitigasi atau menahan kemungkinan insiden keamanan. Ketidakmampuan untuk menahan kemungkinan insiden keamanan secara cepat dan efektif akan meningkatkan dampak, cakupan, dan eksposur dari kemungkinan penyusupan lebih lanjut.
Makin tinggi waktu rata-rata untuk menahan, makin besar kebutuhan untuk membangun pengetahuan dan kemampuan agar dapat mengurangi dan menahan insiden keamanan yang Anda alami dengan cepat dan efektif. Makin rendah waktu rata-rata untuk menahan, makin baik tim Anda dalam memahami dan menggunakan langkah-langkah yang diperlukan untuk memitigasi dan menahan ancaman yang teridentifikasi guna mengurangi dampak, cakupan, dan risiko terhadap bisnis.
# Waktu rata-rata untuk pulih
*Waktu rata-rata untuk memulihkan* adalah waktu rata-rata yang diperlukan untuk sepenuhnya kembali ke operasi yang aman dari kemungkinan insiden keamanan. Secara khusus, ini adalah waktu antara peringatan awal atau penemuan kemungkinan insiden keamanan dan ketika bisnis kembali beroperasi secara normal dan aman tanpa terpengaruh oleh insiden tersebut.
Anda dapat menggunakan metrik ini untuk melacak seberapa efektif tim Anda dalam mengembalikan sistem, akun, dan lingkungan ke operasi yang aman setelah insiden keamanan terjadi. Ketidakmampuan untuk kembali ke operasi yang aman dengan cepat atau efektif tidak hanya dapat berdampak pada keamanan, tetapi juga dapat meningkatkan dampak dan biaya bagi bisnis dan operasinya.
Semakin tinggi waktu rata-rata untuk pulih, semakin besar kebutuhan untuk mempersiapkan tim dan lingkungan Anda untuk memiliki mekanisme yang sesuai (misalnya, proses failover dan CI/CD saluran pipa untuk menerapkan kembali sistem bersih yang aman) untuk meminimalkan dampak insiden keamanan terhadap operasi dan bisnis. Makin rendah waktu rata-rata untuk pulih, makin efektif tim Anda dalam meminimalkan dampak insiden keamanan pada operasi dan bisnis Anda.
# Waktu tinggal penyerang
*Waktu tinggal penyerang adalah waktu* rata-rata bahwa pengguna yang tidak sah memiliki akses ke sistem atau lingkungan. Hal ini mirip dengan waktu rata-rata untuk menahan, tetapi kerangka waktu ini dimulai dengan waktu awal penyerang memperoleh akses ke sistem atau lingkungan, yang mungkin lebih awal dari peringatan atau penemuan awal.
Anda dapat menggunakan metrik ini untuk melacak seberapa baik sistem dan mekanisme Anda bekerja sama untuk mengurangi jumlah waktu, akses, dan kesempatan yang dimiliki penyerang atau ancaman untuk memengaruhi lingkungan Anda. Mengurangi waktu tinggal penyerang harus menjadi prioritas utama bagi tim dan bisnis Anda.
Makin tinggi waktu tinggal penyerang, makin besar kebutuhan untuk mengidentifikasi bagian mana dari proses respons insiden yang perlu ditingkatkan untuk memastikan kemampuan tim Anda dalam meminimalkan dampak dan cakupan ancaman atau serangan di lingkungan Anda. Makin rendah waktu tinggal penyerang, makin baik tim Anda meminimalkan waktu dan peluang yang dimiliki ancaman atau penyerang dalam lingkungan Anda, yang pada akhirnya mengurangi risiko dan dampak terhadap operasi dan bisnis Anda.
# Ringkasan metrik
Membuat dan melacak metrik untuk respons insiden memungkinkan Anda mengukur, menilai, dan meningkatkan kemampuan respons insiden secara efektif. Untuk mencapai hal ini, ada sejumlah metrik respons insiden umum yang disorot di bagian ini. Tabel 5 merangkum metrik-metrik ini.
*Tabel 5 – Metrik respons insiden*
| Metrik | Deskripsi |
| --- | --- |
| Waktu rata-rata untuk mendeteksi | Waktu rata-rata yang diperlukan untuk menemukan kemungkinan insiden keamanan |
| Waktu rata-rata untuk mengakui | Waktu rata-rata yang diperlukan untuk mengakui (dan memprioritaskan) kemungkinan insiden keamanan |
| Waktu rata-rata untuk merespons | Waktu rata-rata yang diperlukan untuk memulai respons awal terhadap kemungkinan insiden keamanan |
| Waktu rata-rata untuk menahan | Waktu rata-rata yang diperlukan untuk menahan kemungkinan insiden keamanan |
| Waktu rata-rata untuk pulih | Waktu rata-rata yang diperlukan untuk sepenuhnya kembali ke operasi yang aman dari kemungkinan insiden keamanan |
| Waktu tinggal penyerang | Waktu rata-rata pengguna yang tidak sah memiliki akses ke sistem atau lingkungan |
# Gunakan indikator kompromi () IOCs
*Indikator kompromi* (IOC) adalah artefak yang diamati di dalam atau pada jaringan, sistem, atau lingkungan yang dapat (dengan tingkat kepercayaan tinggi) mengidentifikasi aktivitas berbahaya atau insiden keamanan. IOCs dapat ada dalam berbagai bentuk, termasuk alamat IP, domain, artefak tingkat jaringan seperti bendera atau muatan TCP, artefak sistem atau tingkat host seperti executable, nama file dan hash, entri file log, atau entri registri, dan banyak lagi. IOC juga dapat berupa kombinasi item atau aktivitas, seperti keberadaan item atau artefak tertentu pada sistem (file tertentu atau set file dan item registri), tindakan yang dilakukan dalam urutan tertentu (masuk ke sistem dari IP tertentu diikuti oleh perintah anomali tertentu), atau aktivitas jaringan (lalu lintas masuk atau keluar anomali ke atau dari domain tertentu) yang dapat menunjukkan ancaman, serangan, atau metodologi penyerang tertentu.
Saat Anda bekerja untuk meningkatkan program respons insiden secara berulang, Anda harus menerapkan kerangka kerja untuk mengumpulkan, mengelola, dan memanfaatkan IOCs sebagai mekanisme untuk terus membangun dan meningkatkan deteksi dan peringatan serta meningkatkan kecepatan dan kemanjuran investigasi. Anda dapat mulai dengan memasukkan pengumpulan dan pengelolaan IOCs ke dalam fase analisis dan investigasi dari proses respons insiden Anda. Dengan secara proaktif mengidentifikasi, mengumpulkan, dan menyimpan IOCs sebagai bagian standar dari proses Anda, Anda dapat membangun repositori data (sebagai bagian dari program intelijen ancaman yang lebih komprehensif) yang pada gilirannya dapat digunakan untuk meningkatkan deteksi dan peringatan yang ada, membangun deteksi dan peringatan tambahan, mengidentifikasi di mana dan kapan artefak terlihat sebelumnya, membangun dan mereferensikan dokumentasi tentang bagaimana investigasi sebelumnya dilakukan yang melibatkan pencocokan, dan banyak lagi. IOCs
# Pendidikan dan pelatihan berkelanjutan
Pendidikan dan pelatihan merupakan upaya yang terus berkembang dan berkelanjutan yang harus diupayakan dan dipertahankan. Ada berbagai mekanisme untuk memverifikasi bahwa tim Anda menjaga kewaspadaan, pengetahuan, dan kemampuan yang sejalan dengan perkembangan teknologi serta lanskap ancaman.
Salah satu mekanismenya adalah menggunakan pendidikan berkelanjutan sebagai bagian standar dari tujuan dan operasi tim Anda. Seperti yang disebutkan di bagian Persiapan, staf dan pemangku kepentingan respons insiden Anda harus dilatih secara efektif dalam mendeteksi, menanggapi, dan menyelidiki insiden di dalamnya. AWS Namun, pendidikan bukanlah upaya yang “sekali jadi”. Pendidikan harus terus dijalankan untuk memverifikasi bahwa tim Anda dapat mengikuti kemajuan teknologi terbaru, informasi terbaru, dan peningkatan yang dapat dimanfaatkan untuk meningkatkan efektivitas dan efisiensi respons, serta penambahan atau pembaruan pada data yang dapat dimanfaatkan untuk meningkatkan penyelidikan dan analisis.
Mekanisme lain adalah memverifikasi bahwa simulasi dilakukan secara teratur (misalnya, setiap triwulan) dan berfokus pada hasil spesifik untuk bisnis. Lihat bagian [Menjalankan simulasi reguler](run-regular-simulations.md) dari dokumen ini.
Meskipun menjalankan latihan meja awal adalah cara terbaik untuk menghasilkan dasar awal untuk perbaikan, pengujian berkelanjutan adalah kunci untuk perbaikan berkelanjutan dan mempertahankan refleksi yang up-to-date akurat dari keadaan operasi saat ini. Menguji situasi keamanan terbaru dan paling kritis dan kemampuan respons yang paling penting atau terbaru, dan memasukkan pelajaran yang dipetik kembali ke dalam pendidikan, operasi, dan processes/procedures akan memverifikasi bahwa Anda dapat terus meningkatkan proses dan program respons Anda secara keseluruhan.
# Kesimpulan
Saat Anda melanjutkan perjalanan cloud Anda, penting bagi Anda untuk mempertimbangkan konsep respons insiden keamanan mendasar untuk AWS lingkungan Anda. Anda dapat menggabungkan kontrol yang tersedia, kemampuan cloud, dan opsi remediasi untuk membantu Anda meningkatkan keamanan lingkungan cloud Anda. Anda juga dapat memulai dari yang kecil dan melakukan iterasi saat Anda mengadopsi kemampuan otomatisasi yang meningkatkan kecepatan respons Anda, sehingga Anda menjadi lebih siap saat peristiwa keamanan terjadi.
# Kontributor
Kontributor saat ini dan terdahulu untuk dokumen ini meliputi:
+ Anna McAbee, Arsitek Solusi Keamanan Senior, Amazon Web Services
+ Freddy Kasprzykowski, Senior Security Consultant, Amazon Web Services
+ Jason Hurst, Insinyur Keamanan Senior, Amazon Web Services
+ Jonathon Poling, Principal Security Consultant, Amazon Web Services
+ Josh Du Lac, Senior Manager, Security Solutions Architecture, Amazon Web Services
+ Paco Hope, Insinyur Keamanan Utama, Amazon Web Services
+ Ryan Tick, Senior Security Engineer, Amazon Web Services
+ Steve de Vera, Insinyur Keamanan Senior, Amazon Web Services
# Lampiran A: Definisi kemampuan cloud
AWS menawarkan lebih dari 200 layanan cloud dan ribuan fitur. Banyak di antaranya menyediakan kemampuan detektif, pencegahan, dan responsif native, dan lainnya dapat digunakan untuk merancang solusi keamanan khusus. Bagian ini mencakup sebagian dari layanan yang paling relevan dengan respons insiden di cloud.
**Topics**
+ [Pencatatan log dan peristiwa](logging-and-events.md)
+ [Visibilitas dan peringatan](visibility-and-alerting.md)
+ [Otomatisasi](automation-1.md)
+ [Penyimpanan aman](secure-storage.md)
+ [Kemampuan Keamanan Masa Depan dan Kustom](custom.md)
# Pencatatan log dan peristiwa
[https://aws.amazon.com/cloudtrail/](https://aws.amazon.com/cloudtrail/)— AWS CloudTrail layanan yang memungkinkan tata kelola, kepatuhan, audit operasional, dan audit risiko akun. AWS Dengan CloudTrail, Anda dapat log, terus memantau, dan mempertahankan aktivitas akun yang terkait dengan tindakan di seluruh AWS layanan. CloudTrail menyediakan riwayat peristiwa aktivitas AWS akun Anda, termasuk tindakan yang diambil melalui Konsol Manajemen AWS, AWS SDKs, alat baris perintah, dan AWS layanan lainnya. Riwayat peristiwa ini menyederhanakan analisis keamanan, pelacakan perubahan sumber daya, dan pemecahan masalah. CloudTrail mencatat dua jenis tindakan AWS API yang berbeda:
+ **CloudTrail Peristiwa manajemen** (juga dikenal sebagai operasi pesawat kontrol) menunjukkan operasi manajemen yang dilakukan pada sumber daya di AWS akun Anda. Hal ini termasuk tindakan seperti membuat bucket Amazon S3 dan menyiapkan pencatatan log.
+ ** CloudTrail Peristiwa data** (juga dikenal sebagai operasi bidang data) menunjukkan operasi sumber daya yang dilakukan pada atau di dalam sumber daya di AWS akun Anda. Operasi ini sering kali merupakan aktivitas bervolume tinggi. Hal ini mencakup tindakan seperti aktivitas API tingkat objek Amazon S3 (misalnya, operasi API `GetObject`, `DeleteObject`, dan `PutObject`) dan aktivitas invokasi fungsi Lambda.
[https://aws.amazon.com/config/](https://aws.amazon.com/config/)— AWS Config adalah layanan yang memungkinkan pelanggan menilai, mengaudit, dan mengevaluasi konfigurasi sumber daya Anda AWS . AWS Config terus memantau dan merekam konfigurasi AWS sumber daya Anda dan memungkinkan Anda untuk mengotomatiskan evaluasi konfigurasi yang direkam terhadap konfigurasi yang diinginkan. Dengan AWS Config, pelanggan dapat meninjau perubahan konfigurasi dan hubungan antar AWS sumber daya, secara manual atau otomatis, riwayat konfigurasi sumber daya terperinci, dan menentukan kepatuhan keseluruhan terhadap konfigurasi yang ditentukan dalam pedoman pelanggan. Hal ini memungkinkan penyederhanaan audit kepatuhan, analisis keamanan, manajemen perubahan, dan pemecahan masalah operasional.
[https://aws.amazon.com/eventbridge/](https://aws.amazon.com/eventbridge/) — Amazon EventBridge memberikan aliran peristiwa sistem yang mendekati real-time yang menjelaskan perubahan AWS sumber daya, atau saat panggilan API dipublikasikan oleh AWS CloudTrail. Dengan menggunakan aturan sederhana yang dapat Anda atur dengan cepat, Anda dapat mencocokkan acara dan mengarahkannya ke satu atau lebih fungsi atau aliran target. EventBridge menjadi sadar akan perubahan operasional saat terjadi. EventBridge dapat menanggapi perubahan operasional ini dan mengambil tindakan korektif seperlunya, dengan mengirim pesan untuk merespons lingkungan, mengaktifkan fungsi, membuat perubahan, dan menangkap informasi negara. Beberapa layanan keamanan, seperti Amazon GuardDuty, menghasilkan output mereka dalam bentuk EventBridge acara. Banyak layanan keamanan juga menyediakan opsi untuk mengirim output-nya ke Amazon S3.
**Log akses Amazon S3** – Jika informasi sensitif disimpan dalam bucket Amazon S3, pelanggan dapat mengaktifkan log akses Amazon S3 untuk merekam setiap unggahan, unduhan, dan modifikasi data tersebut. Log ini terpisah dari, dan sebagai tambahan, CloudTrail log yang mencatat perubahan pada bucket itu sendiri (seperti mengubah kebijakan akses dan kebijakan siklus hidup). Perlu diketahui bahwa catatan log akses server disampaikan atas dasar upaya terbaik. Sebagian besar permintaan bucket yang dikonfigurasi dengan benar untuk mencatat hasil dalam catatan log yang dikirim. Kelengkapan dan ketepatan waktu pencatatan server tidak dijamin.
[https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) — Pelanggan dapat menggunakan CloudWatch Log Amazon untuk memantau, menyimpan, dan mengakses file log yang berasal dari sistem operasi, aplikasi, dan sumber lain yang berjalan di instans Amazon EC2 dengan CloudWatch agen Log. CloudWatch Log dapat menjadi tujuan untuk AWS CloudTrail, Kueri DNS Route 53, Log Aliran VPC, fungsi Lambda, dan lainnya. Pelanggan kemudian dapat mengambil data log terkait dari CloudWatch Log.
[https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) – Log Alur VPC memungkinkan pelanggan untuk menangkap informasi tentang lalu lintas IP ke dan dari antarmuka jaringan di VPC. Setelah mengaktifkan flow log, mereka dapat dialirkan ke Amazon CloudWatch Logs dan Amazon S3. Log Alur VPC membantu pelanggan dengan sejumlah tugas seperti pemecahan masalah lalu lintas tertentu yang tidak mencapai instans, mendiagnosis aturan grup keamanan yang terlalu ketat, dan menggunakannya sebagai alat keamanan untuk memantau lalu lintas ke instans EC2. Gunakan pencatatan alur VPC versi terbaru untuk mendapatkan bidang yang paling kuat.
[https://aws.amazon.com/waf/](https://aws.amazon.com/waf/) — AWS WAF mendukung pencatatan penuh dari semua permintaan web yang diperiksa oleh layanan. Pelanggan dapat menyimpannya di Amazon S3 untuk memenuhi persyaratan kepatuhan dan audit, serta debugging dan forensik. Log ini membantu pelanggan menentukan akar penyebab aturan yang dimulai dan permintaan web yang diblokir. Log dapat diintegrasikan dengan SIEM pihak ketiga dan alat analisis log.
[https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html) – Log kueri Route 53 Resolver akan memungkinkan Anda mencatat semua kueri DNS yang dibuat oleh sumber daya dalam Amazon Virtual Private Cloud (Amazon VPC). Baik itu instans Amazon EC2, AWS Lambda fungsi, atau wadah, jika itu hidup di VPC Amazon Anda dan membuat kueri DNS, maka fitur ini akan mencatatnya; Anda kemudian dapat menjelajahi dan lebih memahami bagaimana aplikasi Anda beroperasi.
** AWS Log lain** — AWS terus merilis fitur dan kemampuan layanan untuk pelanggan dengan kemampuan logging dan pemantauan baru. Untuk informasi tentang fitur yang tersedia untuk setiap AWS layanan, lihat dokumentasi publik kami.
# Visibilitas dan peringatan
[https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)- Respons Insiden Keamanan AWS adalah layanan komprehensif yang membantu organisasi menangani peristiwa keamanan sepanjang siklus hidup mereka dengan menggabungkan kemampuan otomatis dengan dukungan manusia ahli. Layanan ini memanfaatkan fitur pemantauan dan investigasi otomatis untuk membebaskan sumber daya organisasi sambil mempertahankan pengawasan keamanan yang waspada, dan ketika peristiwa keamanan terjadi, ini memfasilitasi komunikasi dan koordinasi yang dipercepat di antara para pemangku kepentingan untuk waktu respons yang cepat. Layanan ini mendukung beberapa kasus penggunaan, termasuk persiapan dan simulasi peristiwa keamanan, respons terhadap insiden aktif, dan pelaporan dan analisis pasca-insiden yang efisien, memastikan organisasi dilengkapi dengan baik untuk menangani tantangan keamanan di setiap tahap.
[https://aws.amazon.com/security-hub/](https://aws.amazon.com/security-hub/)— AWS Security Hub CSPM memberi pelanggan pandangan komprehensif tentang peringatan keamanan prioritas tinggi dan status kepatuhan di seluruh akun. AWS Security Hub CSPM mengumpulkan, mengatur, dan memprioritaskan temuan ancaman dari layanan AWS seperti Amazon, Amazon Inspector, GuardDuty Amazon Macie, dan solusi. AWS Partner Temuan dirangkum secara visual pada dasbor terintegrasi dengan grafik dan tabel yang dapat ditindaklanjuti. Anda juga dapat terus memantau lingkungan Anda menggunakan pemeriksaan kepatuhan otomatis berdasarkan praktik AWS terbaik dan standar industri yang diikuti organisasi Anda.
[https://aws.amazon.com/guardduty/](https://aws.amazon.com/guardduty/) GuardDuty adalah layanan deteksi ancaman terkelola yang terus memantau perilaku berbahaya atau tidak sah untuk membantu pelanggan melindungi AWS akun dan beban kerja. Layanan ini memantau aktivitas seperti panggilan API yang tidak biasa atau deployment yang berpotensi tidak sah yang menunjukkan kemungkinan pembobolan akun atau sumber daya instans Amazon EC2, bucket Amazon S3, atau pengintaian oleh pihak yang tidak bertanggung jawab.
GuardDuty mengidentifikasi tersangka pelaku jahat melalui umpan intelijen ancaman terintegrasi menggunakan pembelajaran mesin untuk mendeteksi anomali dalam aktivitas akun dan beban kerja. Ketika ancaman potensial terdeteksi, layanan memberikan peringatan keamanan terperinci ke GuardDuty konsol dan CloudWatch Acara. Hal ini membuat peringatan dapat ditindaklanjuti dan mudah diintegrasikan ke dalam manajemen peristiwa dan sistem alur kerja yang ada.
GuardDuty juga menawarkan dua add-on untuk memantau ancaman dengan layanan tertentu: Amazon GuardDuty untuk perlindungan Amazon S3 dan Amazon GuardDuty untuk perlindungan Amazon EKS. Perlindungan Amazon S3 memungkinkan GuardDuty untuk memantau operasi API tingkat objek untuk mengidentifikasi potensi risiko keamanan untuk data dalam bucket Amazon S3. Perlindungan Kubernetes memungkinkan GuardDuty untuk mendeteksi aktivitas mencurigakan dan potensi kompromi klaster Kubernetes di Amazon EKS.
[https://aws.amazon.com/macie/](https://aws.amazon.com/macie/) - Amazon Macie adalah layanan keamanan bertenaga AI yang membantu mencegah kehilangan data dengan secara otomatis menemukan, mengklasifikasikan, dan melindungi data sensitif yang disimpan. AWS Macie menggunakan machine learning (ML) untuk mengenali data sensitif seperti informasi pengenal pribadi (PII) atau kekayaan intelektual, menetapkan nilai bisnis, dan memberikan visibilitas ke tempat data ini disimpan dan bagaimana data tersebut digunakan dalam organisasi Anda. Amazon Macie terus memantau adanya anomali dalam aktivitas akses data, dan memberikan peringatan ketika mendeteksi risiko akses tidak sah atau kebocoran data yang tidak disengaja.
[https://aws.amazon.com/config/](https://aws.amazon.com/config/) AWS Config Aturan mewakili konfigurasi yang disukai untuk sumber daya dan dievaluasi terhadap perubahan konfigurasi pada sumber daya yang relevan, seperti yang dicatat oleh. AWS Config Anda dapat melihat hasil evaluasi aturan terhadap konfigurasi sumber daya di dasbor. Dengan menggunakan AWS Config aturan, Anda dapat menilai kepatuhan dan status risiko secara keseluruhan dari perspektif konfigurasi, melihat tren kepatuhan dari waktu ke waktu, dan menemukan perubahan konfigurasi mana yang menyebabkan sumber daya tidak sesuai dengan aturan.
[https://aws.amazon.com/premiumsupport/technology/trusted-advisor/](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)— AWS Trusted Advisor adalah sumber daya online untuk membantu Anda mengurangi biaya, meningkatkan kinerja, dan meningkatkan keamanan dengan mengoptimalkan AWS lingkungan Anda. Trusted Advisor memberikan panduan waktu nyata untuk membantu Anda menyediakan sumber daya Anda dengan mengikuti praktik AWS terbaik. Set lengkap Trusted Advisor pemeriksaan, termasuk integrasi CloudWatch Acara, tersedia untuk pelanggan paket Business and Enterprise Support.
[https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/) — Amazon CloudWatch adalah layanan pemantauan untuk AWS Cloud sumber daya dan aplikasi yang Anda jalankan AWS. Anda dapat menggunakannya CloudWatch untuk mengumpulkan dan melacak metrik, mengumpulkan dan memantau file log, mengatur alarm, dan secara otomatis bereaksi terhadap perubahan sumber daya Anda AWS . CloudWatch dapat memantau AWS sumber daya, seperti instans Amazon EC2, tabel Amazon DynamoDB, dan instans Amazon RDS DB, serta metrik khusus yang dihasilkan oleh aplikasi dan layanan Anda, dan file log apa pun yang dihasilkan aplikasi Anda. Anda dapat menggunakan Amazon CloudWatch untuk mendapatkan visibilitas seluruh sistem ke dalam pemanfaatan sumber daya, kinerja aplikasi, dan kesehatan operasional. Anda dapat menggunakan wawasan ini untuk bereaksi dengan tepat dan menjaga aplikasi Anda tetap berjalan dengan lancar.
[https://aws.amazon.com/inspector/](https://aws.amazon.com/inspector/) - Amazon Inspector adalah layanan penilaian keamanan otomatis yang membantu meningkatkan keamanan dan kepatuhan aplikasi yang digunakan. AWS Amazon Inspector secara otomatis menilai kerentanan atau penyimpangan dari praktik terbaik pada aplikasi. Setelah melakukan penilaian, Amazon Inspector menghasilkan daftar detail temuan keamanan yang diprioritaskan berdasarkan tingkat keparahan. Temuan ini dapat ditinjau secara langsung atau sebagai bagian dari laporan penilaian terperinci yang tersedia melalui konsol Amazon Inspector atau API.
[https://aws.amazon.com/detective/](https://aws.amazon.com/detective/) — Amazon Detective adalah layanan keamanan yang secara otomatis mengumpulkan data log dari AWS sumber daya Anda dan menggunakan pembelajaran mesin, analisis statistik, dan teori grafik untuk membangun kumpulan data terkait yang memungkinkan Anda melakukan investigasi keamanan yang lebih cepat dan lebih efisien. Detective dapat menganalisis triliunan peristiwa dari berbagai sumber data seperti VPC Flow Logs, dan, dan CloudTrail GuardDuty, dan secara otomatis membuat tampilan interaktif terpadu dari sumber daya, pengguna, dan interaksi Anda di antara mereka dari waktu ke waktu. Dengan pandangan terpadu ini, Anda dapat memvisualisasikan semua detail dan konteks di satu tempat untuk mengidentifikasi alasan yang mendasari temuan, menggali aktivitas historis yang relevan, dan menentukan akar penyebabnya dengan cepat.
# Otomatisasi
[https://aws.amazon.com/lambda](https://aws.amazon.com/lambda)— AWS Lambda adalah layanan komputasi tanpa server yang menjalankan kode Anda sebagai respons terhadap peristiwa, dan secara otomatis mengelola sumber daya komputasi yang mendasarinya untuk Anda. Anda dapat menggunakan Lambda untuk memperluas AWS layanan lain dengan logika khusus, atau membuat layanan backend Anda sendiri yang beroperasi pada AWS skala, kinerja, dan keamanan. Lambda menjalankan kode Anda pada infrastruktur komputasi dengan ketersediaan tinggi dan melakukan administrasi sumber daya komputasi untuk Anda. Hal ini termasuk pemeliharaan server dan sistem operasi, penyediaan kapasitas dan penskalaan otomatis, deployment kode dan patch keamanan, serta pemantauan dan pencatatan kode. Anda hanya tinggal menyediakan kode.
[https://aws.amazon.com/step-functions/](https://aws.amazon.com/step-functions/)— AWS Step Functions membuatnya mudah untuk mengoordinasikan komponen aplikasi terdistribusi dan layanan mikro menggunakan alur kerja visual. Step Functions menyediakan konsol grafis bagi Anda untuk mengatur dan memvisualisasikan komponen aplikasi Anda sebagai serangkaian langkah. Hal ini memudahkan Anda untuk membangun dan menjalankan aplikasi multilangkah. Step Functions secara otomatis memulai dan melacak setiap langkah, dan mencoba kembali ketika ada kesalahan, sehingga aplikasi Anda berjalan sesuai urutan dan seperti yang diharapkan.
Step Functions mencatat status setiap langkah, jadi ketika terjadi kesalahan, Anda dapat mendiagnosis dan melakukan debug masalah dengan cepat. Anda dapat mengubah dan menambahkan langkah-langkah tanpa menulis kode, sehingga Anda dapat mengembangkan aplikasi Anda dan berinovasi lebih cepat. AWS Step Functions adalah bagian dari AWS Tanpa Server, dan membuatnya mudah untuk mengatur fungsi untuk aplikasi tanpa server. AWS Lambda Anda juga dapat menggunakan Step Functions untuk orkestrasi layanan mikro menggunakan sumber daya komputasi seperti Amazon EC2 dan Amazon ECS.
[https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/) — AWS Systems Manager memberi Anda visibilitas dan kontrol atas AWS infrastruktur Anda. Systems Manager menyediakan antarmuka pengguna terpadu sehingga Anda dapat melihat data operasional dari beberapa AWS layanan, dan memungkinkan Anda untuk mengotomatiskan tugas operasional di seluruh sumber daya Anda AWS . Dengan Systems Manager, Anda dapat mengelompokkan sumber daya berdasarkan aplikasi, melihat data operasional untuk pemantauan dan pemecahan masalah, dan bertindak pada kelompok sumber daya Anda. Systems Manager dapat menyimpan instans Anda dalam status yang ditentukan, melakukan perubahan sesuai permintaan, seperti memperbarui aplikasi atau menjalankan skrip shell, serta melakukan tugas otomatisasi dan patching lainnya.
# Penyimpanan aman
[https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) – Amazon S3 adalah penyimpanan objek yang dibuat untuk menyimpan dan mengambil sejumlah data dari mana saja. Penyimpanan ini dirancang untuk memberikan daya tahan 99,999999999%, dan menyimpan data untuk jutaan aplikasi yang digunakan oleh para pemimpin pasar di setiap industri. Amazon S3 memberikan keamanan komprehensif dan dirancang untuk membantu Anda memenuhi persyaratan peraturan Anda. Ini memberi pelanggan fleksibilitas dalam metode yang mereka gunakan untuk mengelola data untuk pengoptimalan biaya, kontrol akses, dan kepatuhan. Amazon S3 menyediakan query-in-place fungsionalitas, yang memungkinkan Anda menjalankan analitik yang kuat langsung pada data Anda saat istirahat di Amazon S3. Amazon S3 adalah layanan penyimpanan cloud yang sangat didukung, dengan integrasi dari salah satu komunitas terbesar solusi pihak ketiga, mitra integrator sistem, dan layanan lainnya. AWS
[https://aws.amazon.com/s3/storage-classes/glacier/](https://aws.amazon.com/s3/storage-classes/glacier/) Glacier adalah layanan penyimpanan cloud yang aman, tahan lama, dan sangat murah untuk pengarsipan data dan pencadangan jangka panjang. Layanan ini dirancang untuk memberikan ketahanan 99,999999999%, keamanan komprehensif dan dirancang untuk membantu Anda memenuhi persyaratan peraturan Anda. Amazon Glacier query-in-place menyediakan fungsionalitas, yang memungkinkan Anda menjalankan analitik yang kuat secara langsung pada data arsip Anda saat istirahat. Untuk menjaga biaya tetap rendah namun cocok untuk berbagai kebutuhan pengambilan, Amazon Glacier menyediakan tiga opsi untuk akses ke arsip, dari beberapa menit hingga beberapa jam.
# Kemampuan Keamanan Masa Depan dan Kustom
Layanan dan fitur yang disebutkan di atas bukanlah daftar lengkap. AWS terus menambahkan kemampuan baru. Untuk informasi lebih lanjut, kami mendorong Anda untuk meninjau halaman [Apa yang Baru di AWS](https://aws.amazon.com/new/) dan [Keamanan AWS Cloud](https://aws.amazon.com/security/). Selain layanan keamanan yang AWS menawarkan layanan cloud asli, Anda mungkin tertarik untuk membangun kemampuan Anda sendiri di atas AWS layanan.
Meskipun kami menyarankan untuk mengaktifkan serangkaian layanan keamanan dasar dalam akun Anda, seperti Amazon AWS CloudTrail GuardDuty, dan Amazon Macie, Anda mungkin ingin memperluas kemampuan ini untuk mendapatkan nilai tambahan dari aset log Anda. Ada sejumlah alat partner yang tersedia, seperti yang tercantum dalam program Kompetensi Keamanan APN kami. Anda mungkin juga ingin menulis kueri Anda sendiri untuk mencari log Anda. Dengan banyaknya layanan terkelola yang AWS menawarkan, ini tidak pernah semudah ini. Ada banyak AWS layanan tambahan yang dapat membantu Anda dengan penyelidikan yang berada di luar cakupan paper ini, seperti Amazon Athena, Amazon OpenSearch Service, Amazon Quick, Amazon Machine Learning, dan Amazon EMR.
# Lampiran B: sumber daya respons AWS insiden
AWS menerbitkan sumber daya untuk membantu pelanggan mengembangkan kemampuan respons insiden. Sebagian besar contoh kode dan prosedur dapat ditemukan di repositori GitHub publik AWS eksternal. Berikut ini adalah beberapa sumber daya yang memberikan contoh cara melakukan respons insiden.
## Sumber daya playbook
+ [Framework for Incident Response Playbooks](https://github.com/aws-samples/aws-customer-playbook-framework) - Contoh kerangka kerja bagi pelanggan untuk membuat, mengembangkan, dan mengintegrasikan buku pedoman keamanan dalam persiapan untuk skenario serangan potensial saat menggunakan AWS layanan.
+ [Sampel Playbook Respon Insiden](https://github.com/aws-samples/aws-incident-response-playbooks) - Buku pedoman yang mencakup skenario umum yang dihadapi oleh AWS pelanggan.
+ [AWS mengumumkan rilis lima lokakarya yang tersedia untuk umum](https://aws.amazon.com/blogs/security/aws-cirt-announces-the-release-of-five-publicly-available-workshops/).
## Sumber daya forensik
+ [Automated Incident Response and Forensics Framework](https://github.com/awslabs/aws-automated-incident-response-and-forensics) – Kerangka kerja dan solusi ini menyediakan proses forensik digital standar, yang terdiri dari fase-fase berikut: penahanan, akuisisi, pemeriksaan, dan analisis. Ini memanfaatkan fungsi AWS Λ untuk memicu proses respons insiden dengan cara berulang otomatis. Hal ini menyediakan segregasi akun untuk mengoperasikan langkah-langkah otomatisasi, menyimpan artefak, dan menciptakan lingkungan forensik.
+ [Orkestrator Forensik Otomatis untuk Amazon EC2](https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/) – Panduan implementasi ini menyediakan solusi otomatis untuk menangkap dan memeriksa data dari instans EC2 dan volume terlampir untuk analisis forensik jika terjadi potensi masalah keamanan yang terdeteksi. Ada AWS CloudFormation template untuk menyebarkan solusi.
+ [Cara mengotomatiskan pengumpulan disk forensik di AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) — AWS Blog ini merinci cara mengatur alur kerja otomatisasi untuk menangkap bukti disk untuk analisis guna menentukan ruang lingkup dan dampak potensi insiden keamanan. Ada juga AWS CloudFormation template yang disertakan untuk menyebarkan solusi.
# Pemberitahuan
Pelanggan bertanggung jawab untuk membuat penilaian independen mereka sendiri atas informasi dalam dokumen ini. Dokumen ini: (a) hanya untuk tujuan informasi, (b) mewakili penawaran dan praktik AWS produk saat ini, yang dapat berubah tanpa pemberitahuan, dan (c) tidak membuat komitmen atau jaminan apa pun dari AWS dan afiliasinya, pemasok, atau pemberi lisensinya. AWS produk atau layanan disediakan “sebagaimana adanya” tanpa jaminan, representasi, atau kondisi apa pun, baik tersurat maupun tersirat. Tanggung jawab dan kewajiban AWS kepada pelanggannya dikendalikan oleh AWS perjanjian, dan dokumen ini bukan bagian dari, juga tidak mengubah, perjanjian apa pun antara AWS dan pelanggannya.
© 2024 Amazon Web Services, Inc. atau afiliasinya. Semua hak dilindungi undang-undang.