

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Respon Insiden Keamanan di AMS
<a name="security-incident-response"></a>

Keamanan adalah prioritas utama di AWS Managed Services (AMS). AMS menyebarkan sumber daya dan kontrol di akun Anda untuk mengelolanya. AWS memiliki model tanggung jawab bersama: AWS mengelola keamanan cloud, dan Anda bertanggung jawab atas keamanan di cloud. AMS melindungi data dan aset Anda serta membantu menjaga AWS infrastruktur Anda tetap aman dengan menggunakan kontrol keamanan dan pemantauan aktif untuk masalah keamanan. Kemampuan ini membantu Anda menetapkan garis dasar keamanan untuk aplikasi yang berjalan di Cloud. AWS AMS bekerja sama dengan Anda melalui Security Incident Response untuk menilai efeknya, dan kemudian melakukan penahanan dan remediasi berdasarkan rekomendasi praktik terbaik.

Ketika penyimpangan dari baseline terjadi, seperti oleh kesalahan konfigurasi atau perubahan faktor eksternal, Anda perlu merespons dan menyelidiki. Agar berhasil melakukannya, Anda perlu memahami konsep dasar Respons Insiden Keamanan dalam lingkungan AMS Anda. Anda juga harus memahami persyaratan untuk mempersiapkan, mendidik, dan melatih tim cloud sebelum masalah keamanan terjadi. Penting untuk mengetahui kontrol dan kemampuan yang dapat Anda gunakan, menyiapkan rencana respons untuk masalah keamanan umum seperti kompromi akun pengguna atau penyalahgunaan akun istimewa, dan mengidentifikasi metode remediasi yang menggunakan otomatisasi untuk meningkatkan kecepatan dan konsistensi respons. Selain itu, Anda perlu memahami kepatuhan dan persyaratan peraturan Anda karena terkait dengan membangun program Respons Insiden Keamanan untuk memenuhi persyaratan tersebut.

Security Incident Response dapat menjadi kompleks, tetapi dengan menerapkan pendekatan berulang Anda dapat menyederhanakan proses dan memungkinkan tim respons insiden untuk menjaga pemangku kepentingan aset puas dengan memberikan deteksi dan respons dini dan berkelanjutan. Dalam panduan ini, kami memberi Anda metodologi yang digunakan AMS untuk respons insiden, matriks tanggung jawab AMS (RACI), bagaimana Anda dapat dipersiapkan untuk acara keamanan, cara melibatkan AMS selama insiden keamanan, dan beberapa runbook respons insiden yang digunakan AMS.

# Cara kerja AMS Security Incident Response
<a name="sir-how-works"></a>

AWS Managed Services selaras dengan [Panduan Penanganan Insiden Keamanan Komputer NIST 800-61 untuk Respons Insiden Keamanan](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final). Dengan menyelaraskan standar industri ini, kami menyediakan pendekatan yang konsisten untuk manajemen acara keamanan dan mematuhi praktik terbaik dalam mengamankan dan menanggapi insiden keamanan di cloud Anda.

![\[Siklus hidup respons insiden\]](http://docs.aws.amazon.com/id_id/managedservices/latest/accelerate-guide/images/sec-inc-response-1.png)


**Siklus hidup respons insiden**

Saat deteksi mengidentifikasi dan menghasilkan peringatan keamanan, atau Anda meminta bantuan keamanan, tim AWS Managed Services Operations memastikan bahwa ada investigasi tepat waktu, menjalankan otomatisasi untuk melakukan pengumpulan data, triase dan analisis, memberi tahu Anda tentang analisis, melakukan investigasi dan aktivitas penahanan apa pun, lalu memposting analisis peristiwa.

Pengumpulan data, triase, analisis, dan kegiatan penahanan yang dilakukan selama respons insiden bervariasi tergantung pada jenis peristiwa keamanan yang diselidiki. Contoh alur kerja Respons Insiden Keamanan untuk skenario tertentu ada di akhir dokumen ini.

Selama insiden, AMS menentukan tindakan yang benar secara dinamis, yang dapat mengakibatkan langkah-langkah yang didokumentasikan diurutkan ulang atau dilewati sebagaimana mestinya untuk memastikan bahwa hasil yang tepat terjadi.

# Persiapkan
<a name="preparation-phase"></a>

Seiring berkembangnya lanskap ancaman, AMS terus memperluas kemampuan deteksi dan respons. Saat deteksi baru ditambahkan, AMS menggabungkan peringatan dari deteksi baru ini ke dalam platform deteksi dan respons. Responden keamanan AMS dilatih untuk menyelidiki dan bermitra dengan Anda selama siklus hidup Respons Insiden Keamanan.

Karena pendekatan kemitraan ini, penting bagi tim keamanan dan aplikasi Anda untuk terlibat dengan AMS untuk menangani peristiwa keamanan saat peristiwa ini terjadi. Dokumentasi ini menjelaskan apa yang diharapkan selama acara keamanan dan membantu Anda mempersiapkan respons cepat ketika insiden keamanan terjadi.

Dokumentasi ini menggunakan definisi NIST 800-61 tentang suatu **peristiwa** sebagai kejadian yang dapat diamati dalam sistem atau jaringan dan **insiden** sebagai pelanggaran atau ancaman pelanggaran kebijakan, kebijakan penggunaan yang dapat diterima, atau praktik keamanan standar.

## Daftar periksa persiapan
<a name="sir-cklist"></a>

 Kerjakan daftar periksa berikut dengan manajer pengiriman solusi cloud AMS (CSDM) dan arsitek cloud AMS (CA) Anda:
+ Pahami beban kerja apa yang berjalan di akun mana.
+ Pahami tim internal apa yang bertanggung jawab atas berbagai beban kerja dan beri tag dengan tepat di beban kerja.
+ Pertahankan detail kontak secara internal untuk tim lain yang mungkin diperlukan selama investigasi acara keamanan dan untuk keputusan penahanan.
+ Konfirmasikan bahwa kontak keamanan telah diperbarui dan ditambahkan ke semua AWS akun yang dikelola. Kontak dikelola berdasarkan per akun.
+ Ketahui cara meningkatkan insiden keamanan ke AMS, dan ketahui tingkat keparahan dan waktu respons yang diharapkan.
+ Pastikan bahwa ketika pemberitahuan keamanan diterima, mereka diarahkan ke orang dan sistem yang sesuai seperti pager atau pusat operasi keamanan Anda.
+ Pahami sumber log apa yang tersedia untuk Anda, di mana ini disimpan di akun Anda dan siapa yang memiliki akses ke sana.
+ Memahami cara menggunakan CloudWatch Wawasan untuk Kueri Log selama investigasi.
+ Pahami opsi penahanan yang tersedia untuk Anda berdasarkan sumber daya (EC2, IAM, S3, dan son on) dan konsekuensi pada ketersediaan beban kerja Anda saat dalam penahanan.

# Mendeteksi
<a name="sir-detect"></a>

Selama pengelolaan AWS akun Anda, AMS memantau anomali dalam perilaku pengguna, aktivitas akun, dan potensi peristiwa keamanan menggunakan data yang dikumpulkan dari sumber deteksi dan kontrol termasuk namun tidak terbatas pada Amazon, Amazon, GuardDuty VPC Flow Logs, CloudWatch Amazon Macie, dan AWS Config Amazon internal Threat Intelligence feed.

AMS menggunakan AWS layanan asli dan teknologi deteksi lainnya untuk merespons peristiwa keamanan yang dibuat oleh:
+ Jenis Penemuan Kesesuaian Config
+ GuardDuty Menemukan Jenis
+ Jenis Penemuan Macie
+ Amazon Route 53 Resolver Acara Firewall DNS
+ Acara Keamanan AMS (alarm jam tangan cloud)

Temuan tambahan ditambahkan saat layanan, produk, dan ekosistem ancaman berkembang. 

## Laporkan peristiwa keamanan ke AMS
<a name="sir-report"></a>

Mengajukan insiden melalui Portal atau Dukungan Pusat Dukungan AMS untuk memberi tahu AMS tentang insiden keamanan atau untuk meminta penyelidikan.

# Analisis
<a name="sir-analyze"></a>

Setelah peristiwa keamanan diidentifikasi dan dilaporkan, langkah selanjutnya adalah menganalisis apakah peristiwa yang dilaporkan adalah positif palsu atau insiden nyata. AMS menggunakan otomatisasi dan teknik investigasi manual untuk menangani peristiwa keamanan. Analisis ini mencakup investigasi log dari sumber deteksi yang berbeda seperti log lalu lintas jaringan, log host, CloudTrail peristiwa, log AWS layanan, dan sebagainya. Analisis juga mencari pola yang menunjukkan perilaku anomali dengan korelasi.

Kemitraan Anda diperlukan untuk memahami konteks khusus untuk lingkungan akun dan untuk menetapkan apa yang normal untuk akun dan beban kerja Anda. Ini membantu AMS mengidentifikasi anomali lebih cepat dan respons insiden yang dipercepat.

## Menangani komunikasi dari AMS tentang peristiwa keamanan
<a name="sir-comms-from-ams"></a>

AMS memberi Anda informasi selama penyelidikan dengan melibatkan kontak keamanan Anda melalui tiket insiden. Manajer pengiriman layanan cloud AMS (CSDM) dan arsitek cloud AMS (CA) Anda adalah titik kontak yang harus dihubungi untuk komunikasi apa pun selama penyelidikan keamanan aktif.

Komunikasi mencakup pemberitahuan otomatis ketika peringatan keamanan dihasilkan, komunikasi setelah analisis peristiwa, membangun jembatan panggilan dan pengiriman artefak yang sedang berlangsung seperti file log, snapshot sumber daya yang terinfeksi, dan mendapatkan hasil investigasi kepada Anda selama acara keamanan.

Bidang standar yang disertakan dalam pemberitahuan peringatan keamanan AMS tercantum di bawah ini. Bidang ini memberi Anda informasi sehingga Anda dapat merutekan acara ke tim yang sesuai dalam organisasi Anda untuk perbaikan.
+ Menemukan Jenis
+ Menemukan Pengenal (Jika relevan)
+ Menemukan Tingkat Keparahan
+ Menemukan Deskripsi
+ Menemukan Tanggal & Waktu yang dibuat
+ AWS Id Akun
+ Wilayah (Jika relevan)
+ AWS Sumber Daya (IAMuser/role/policy,, S3 EC2, EKS)

Bidang tambahan disediakan tergantung pada Jenis Temuan, misalnya Temuan EKS mencakup detail Pod, Container, dan Cluster.

# Mengandung
<a name="sir-contain"></a>

Pendekatan AMS terhadap penahanan adalah kemitraan dengan Anda. Anda memahami bisnis Anda dan dampak beban kerja yang mungkin terjadi dari aktivitas penahanan, seperti isolasi jaringan, pengguna IAM atau de-penyediaan peran, pembangunan ulang instans, dan sebagainya.

Bagian penting dari penahanan adalah pengambilan keputusan. Misalnya, mematikan sistem, mengisolasi sumber daya dari jaringan, atau mematikan akses atau mengakhiri sesi. Keputusan ini lebih mudah dibuat jika ada strategi dan prosedur yang telah ditentukan untuk menahan insiden tersebut. AMS menyediakan strategi penahanan dan kemudian menerapkan solusi setelah Anda mempertimbangkan risiko yang terlibat dengan penerapan tindakan penahanan.

Ada opsi penahanan yang berbeda tergantung pada sumber daya yang dianalisis. AMS mengharapkan beberapa jenis penahanan akan dikerahkan secara bersamaan selama penyelidikan insiden. Beberapa contoh ini meliputi:
+ Menerapkan aturan perlindungan untuk memblokir lalu lintas yang tidak sah (Grup keamanan, NACL, Aturan WAF, aturan SCP, Tolak daftar, pengaturan tindakan tanda tangan ke karantina atau blokir)
+ Isolasi Sumber Daya
+ Isolasi Jaringan
+ Menonaktifkan pengguna, peran, dan kebijakan IAM
+ Memodifikasi/Mengurangi pengguna IAM, hak istimewa peran
+ Mengakhirkan/menangguhkan/menghapus sumber daya komputasi
+ Membatasi akses publik dari sumber daya yang terpengaruh
+ Memutar kunci akses, kunci API, dan kata sandi
+ Menggosok kredensi yang diungkapkan dan informasi sensitif

AMS mendorong Anda untuk mempertimbangkan jenis strategi penahanan untuk setiap jenis insiden besar yang berada dalam selera risiko mereka, dengan kriteria yang didokumentasikan dengan jelas untuk membantu pengambilan keputusan jika terjadi insiden. Kriteria untuk menentukan strategi yang tepat meliputi:
+ Potensi kerusakan sumber daya
+ Pelestarian bukti
+ Ketidaktersediaan layanan (misalnya, konektivitas jaringan, layanan yang diberikan kepada pihak eksternal)
+ Waktu dan sumber daya yang dibutuhkan untuk mengimplementasikan strategi
+ Efektivitas strategi (Misalnya, penahanan sebagian, penahanan penuh)
+ Permanen solusi (Misalnya, keputusan pintu satu arah vs pintu dua arah)
+ Durasi solusi (Misalnya, solusi darurat yang akan dihapus dalam empat jam, solusi sementara yang akan dihapus dalam dua minggu, solusi permanen).
+ Terapkan kontrol keamanan yang dapat Anda aktifkan untuk menurunkan risiko dan memberikan waktu untuk menentukan dan menerapkan penahanan yang lebih efektif. 

Kecepatan penahanan sangat penting, AMS menyarankan pendekatan bertahap untuk mencapai penahanan yang efisien dan efektif dengan menyusun strategi pendekatan jangka pendek dan jangka panjang.

Gunakan panduan ini untuk mempertimbangkan strategi penahanan Anda yang melibatkan teknik berbeda berdasarkan jenis sumber daya.
+ Strategi Penahanan
  + Dapatkah AMS mengidentifikasi ruang lingkup insiden keamanan?
    + Jika ya, identifikasi semua sumber daya (pengguna, sistem, sumber daya).
    + Jika tidak, selidiki secara paralel dengan mengeksekusi langkah berikutnya pada sumber daya yang diidentifikasi.
  + Bisakah sumber daya diisolasi?
    + Jika ya, maka lanjutkan untuk mengisolasi sumber daya yang terpengaruh.
    + Jika tidak, maka bekerja dengan pemilik dan manajer sistem untuk menentukan tindakan lebih lanjut yang diperlukan untuk mengatasi masalah.
  + Apakah semua sumber daya yang terpengaruh terisolasi dari sumber daya yang tidak terpengaruh?
    + Jika ya, lanjutkan ke langkah berikutnya.
    + Jika tidak, maka teruslah mengisolasi sumber daya yang terkena dampak sampai penahanan jangka pendek dicapai untuk mencegah insiden meningkat lebih lanjut.
+ Sistem Backup
  + Apakah salinan cadangan dari sistem yang terpengaruh dibuat untuk analisis lebih lanjut?
  + Apakah salinan forensik dienkripsi dan disimpan di lokasi yang aman?
    + Jika ya, lanjutkan ke langkah berikutnya.
    + Jika tidak, enkripsi gambar forensik, lalu simpan di lokasi yang aman untuk mencegah penggunaan, kerusakan, dan gangguan yang tidak disengaja.

# Membasmi
<a name="sir-eradicate"></a>

Setelah insiden diatasi, pemberantasan mungkin diperlukan untuk menghilangkan sumber ancaman sama sekali untuk mengamankan sistem sebelum Anda melanjutkan ke tahap pemulihan berikutnya. Langkah-langkah pemberantasan mungkin termasuk menghapus malware dan menghapus akun pengguna yang disusupi, serta mengidentifikasi dan mengurangi semua kerentanan yang dieksploitasi. Selama pemberantasan, penting untuk mengidentifikasi semua akun, sumber daya, dan contoh yang terpengaruh dalam lingkungan sehingga dapat diperbaiki. 

Ini adalah praktik terbaik bahwa pemberantasan dan pemulihan dilakukan secara bertahap sehingga langkah-langkah remediasi diprioritaskan. Untuk insiden skala besar, pemulihan mungkin memakan waktu berbulan-bulan. Maksud dari fase awal harus meningkatkan keamanan secara keseluruhan dengan perubahan nilai tinggi yang relatif cepat (hari ke minggu) untuk mencegah insiden di masa depan. Fase selanjutnya harus fokus pada perubahan jangka panjang (misalnya, perubahan infrastruktur) dan pekerjaan yang sedang berlangsung untuk menjaga perusahaan seaman mungkin.

Untuk beberapa insiden, pemberantasan tidak diperlukan atau dilakukan selama pemulihan. 

Pertimbangkan hal berikut:
+ Dapatkah sistem dicitrakan ulang dan kemudian dikeraskan dengan tambalan atau tindakan pencegahan lainnya untuk mencegah atau mengurangi risiko serangan?
+ Apakah semua malware dan artefak lainnya yang ditinggalkan oleh penyerang dihapus dan sistem yang terpengaruh mengeras terhadap serangan lebih lanjut?

# Memulihkan
<a name="sir-recover"></a>

AMS bermitra dengan Anda untuk memulihkan sistem ke operasi normal, mengonfirmasi bahwa sistem berfungsi normal, dan (sebagaimana berlaku) memulihkan kerentanan untuk mencegah insiden serupa.

 Pertimbangkan hal berikut:
+ Apakah sistem yang terpengaruh ditambal dan dikeraskan terhadap serangan baru-baru ini dan kemungkinan serangan future?
+ Hari dan waktu apa yang layak untuk mengembalikan sistem yang terkena dampak kembali ke produksi?
+ Alat apa yang akan Anda gunakan untuk menguji, memantau, dan memverifikasi bahwa sistem yang Anda kembalikan ke produksi tidak rentan terhadap teknik serangan awal?

# Laporan Pasca Insiden
<a name="sir-post-report"></a>

Setelah acara, AMS menjalankan proses peninjauan investigasi untuk semua insiden keamanan. Dan, AMS memulai proses koreksi kesalahan (COE) untuk mengatasi insiden keamanan yang disebabkan oleh sistem atau kesalahan prosedural yang masuk akal memiliki ruang untuk perbaikan. AMS bermitra dengan Anda untuk terus meningkatkan pengalaman investigasi keamanan. Proses COE membantu AMS mengidentifikasi faktor-faktor yang berkontribusi dari peristiwa yang berdampak pada pelanggan dan menghubungkan penyebab tersebut ke item tindakan berikutnya yang dapat mencegah kejadian serupa berulang, atau membantu mengurangi durasi atau tingkat dampak.

 Proses peninjauan investigasi untuk insiden keamanan membahas hal-hal berikut untuk mengidentifikasi peluang perbaikan:
+ Berapa waktu yang telah berlalu dari awal insiden hingga penemuan insiden, hingga penilaian dampak awal, dan untuk setiap tahap proses penanganan insiden (misalnya, penahanan, pemulihan)?
+ Berapa lama waktu yang dibutuhkan tim respons insiden untuk menanggapi laporan awal insiden tersebut?
+ Berapa lama waktu yang dibutuhkan untuk melakukan analisis dampak awal?
+ Apakah ini bisa dicegah dan bagaimana caranya? Apakah ada alat atau proses yang bisa mencegah hal ini?
+ Bisakah kita mendeteksi ini lebih cepat dan bagaimana?
+ Apa yang bisa membuat penyelidikan berjalan lebih cepat?
+ Apakah Prosedur Respons Insiden yang terdokumentasi diikuti? Apakah mereka memadai?
+ Apakah berbagi informasi dengan pemangku kepentingan lain dilakukan tepat waktu Bagaimana itu bisa diperbaiki?
+ Apakah kolaborasi dengan tim lain (AWS Keamanan, tim akun, tim AWS Pengembangan, dan tim keamanan pelanggan) efektif? Jika tidak, apa yang bisa diperbaiki?
+ Langkah persiapan apa yang hilang yang mungkin membantu, matriks eskalasi, RACI, model tanggung jawab bersama, dan sebagainya? Apakah ada kebutuhan untuk memperbarui Runbook?
+ Apa perbedaan antara penilaian dampak awal dan penilaian dampak akhir? Apa yang dapat kita lakukan untuk meningkatkan akurasi penilaian sebelumnya dalam respons insiden?
+ Apa Item Tindakan dari Pelajaran yang Dipetik?

# Runbook Respons Insiden Keamanan di AMS
<a name="sir-runbooks"></a>

Bagian ini berisi dua runbook:
+ [Respon terhadap aktivitas pengguna root](sir-root-user.md)
+ [Respon terhadap peristiwa malware](sir-malware.md)

# Respon terhadap aktivitas pengguna root
<a name="sir-root-user"></a>

[Pengguna root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) adalah superuser di dalam AWS akun Anda. Perhatikan bahwa AMS memantau penggunaan root. Ini adalah praktik terbaik untuk menggunakan pengguna root hanya untuk beberapa tugas yang memerlukannya, seperti mengubah pengaturan akun Anda, mengaktifkan akses AWS Identity and Access Management (IAM) ke penagihan dan manajemen biaya, mengubah kata sandi root Anda, dan mengaktifkan otentikasi multi-faktor (MFA). Untuk informasi selengkapnya, lihat [Tugas yang memerlukan kredensi pengguna root](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).

Untuk informasi selengkapnya tentang cara menginformasikan AMS tentang penggunaan root yang direncanakan, lihat [Kapan dan cara menggunakan akun root di AMS](https://docs.aws.amazon.com/managedservices/latest/userguide/how-when-to-use-root.html).

Ketika aktivitas pengguna root terdeteksi, upaya gagal untuk masuk yang mungkin menunjukkan serangan brute force atau aktivitas di akun setelah login berhasil, peristiwa yang dihasilkan, dan insiden yang dikirim ke kontak keamanan yang Anda tentukan.

AWS Managed Services Operations menyelidiki aktivitas pengguna root yang tidak direncanakan, melakukan pengumpulan data, triase, dan analisis, serta melakukan aktivitas penahanan sesuai arahan Anda, diikuti dengan analisis pasca peristiwa.

Jika Anda memiliki model operasi AMS Advanced, Anda menerima komunikasi tambahan dari insinyur AMS CSDM dan AMS Ops yang mengonfirmasi aktivitas pengguna root yang tidak direncanakan karena tanggung jawab AMS untuk mengamankan kredenal pengguna root. AMS menyelidiki aktivitas pengguna root hingga Anda mengonfirmasi jalur ke depan.

## Persiapkan
<a name="sir-prepare-root"></a>

Beri tahu AMS tentang penggunaan pengguna root yang direncanakan dengan mengirimkan permintaan layanan AMS dengan data dan waktu acara yang direncanakan untuk mencegah aktivitas respons insiden yang tidak perlu.

Lakukan secara berkala GameDays dengan AMS untuk memvalidasi proses respons insiden pelanggan AMS, orang dan sistem terkini, dan membangun memori otot dengan individu yang bertanggung jawab untuk mencapai respons insiden yang lebih cepat.

## Fase A: Mendeteksi
<a name="sir-detect-root"></a>

AMS memantau aktivitas root di akun melalui sumber deteksi termasuk GuardDuty dan pemantauan AMS.

Jika Anda memiliki AMS Accelerate, model operasi merespons insiden yang meminta penyelidikan untuk aktivitas pengguna root yang tidak terduga. Ketika ini terjadi, Operasi AMS memulai runbook Akun Terkompromi.

Jika Anda memiliki AMS Advanced, model operasi merespons insiden tersebut, atau memberi tahu CSDM tentang aktivitas pengguna root yang direncanakan untuk menghentikan investigasi Kompromi Akun yang aktif.

## Fase B: Analisis
<a name="sir-analyze-root"></a>

AMS melakukan penyelidikan menyeluruh terhadap peristiwa pengguna root ketika ditentukan bahwa aktivitas tersebut tidak diotorisasi. Menggunakan otomatisasi dan tim respons keamanan AMS, log dan peristiwa dianalisis untuk anomali dan perilaku tak terduga bagi pengguna root. Log diberikan kepada Anda untuk membantu menentukan apakah aktivitas tersebut tidak diketahui, atau apakah itu adalah peristiwa pengguna root resmi, atau jika memerlukan penyelidikan lebih lanjut.

Beberapa contoh informasi yang diberikan selama penyelidikan untuk mendukung pemeriksaan internal meliputi:
+ Informasi akun: Akun apa yang digunakan akun root?
+ Alamat e-mail untuk pengguna root: Setiap pengguna root dikaitkan dengan alamat e-mail dari organisasi Anda
+ Detail otentikasi: Dari mana dan kapan pengguna root mengakses lingkungan Anda?
+ Catatan aktivitas: Apa yang dilakukan pengguna saat masuk sebagai root? Catatan-catatan ini dalam bentuk CloudWatch peristiwa. Memahami cara membaca log ini membantu dalam penyelidikan.

Ini adalah praktik terbaik bahwa Anda siap menerima informasi analisis dan memiliki rencana bagaimana mencapai titik kontak resmi untuk akun dalam organisasi Anda. Karena pengguna root tidak disebut sebagai individu, menentukan siapa yang memiliki akses ke alamat email root yang digunakan untuk akun dalam organisasi Anda membantu merutekan pertanyaan secara internal dengan cepat. 

## Fase C: Mengandung dan Membasmi
<a name="sir-eradicate-root"></a>

AMS bermitra dengan tim keamanan Anda untuk melakukan penahanan sesuai arahan kontak Keamanan Pelanggan resmi Anda. Opsi penahanan meliputi: 
+ Memutar kredensi dan kunci yang sesuai.
+ Mengakhiri sesi aktif ke akun dan sumber daya.
+ Memberantas sumber daya yang dibuat.

Selama aktivitas penahanan, AMS bekerja sama dengan tim keamanan Anda untuk memastikan setiap gangguan pada beban kerja Anda diminimalkan dan kredenal root diamankan dengan tepat.

Setelah rencana penahanan selesai, Anda bekerja dengan tim Operasi AMS untuk tindakan pemulihan apa pun yang diperlukan.

## Laporan Pasca Insiden
<a name="sir-post-root"></a>

Sebagaimana diperlukan, AMS memulai proses peninjauan investigasi untuk mengidentifikasi pelajaran apa pun yang dipetik. Sebagai bagian dari penyelesaian COE, AMS mengkomunikasikan temuan yang relevan kepada pelanggan yang terkena dampak untuk membantu mereka meningkatkan proses respons insiden mereka.

AMS mendokumentasikan semua detail akhir investigasi, mengumpulkan metrik yang sesuai, dan kemudian melaporkan insiden tersebut ke tim internal AMS mana pun yang memerlukan informasi, termasuk CSDM dan CA yang Anda tetapkan.

# Respon terhadap peristiwa malware
<a name="sir-malware"></a>

 EC2 Instans Amazon digunakan untuk menampung berbagai beban kerja termasuk perangkat lunak pihak ketiga dan perangkat lunak yang dikembangkan khusus yang digunakan oleh tim aplikasi dalam organisasi. AMS menyediakan dan mendorong Anda untuk menerapkan beban kerja Anda pada gambar yang ditambal dan dipelihara secara berkelanjutan oleh AMS.

Selama pengoperasian instance, AMS memantau anomali perilaku atau aktivitas melalui berbagai kontrol deteksi keamanan, termasuk Amazon, Network Traffic GuardDuty, dan Amazon internal Threat Intelligence feed.

AMS juga memantau Temuan GuardDuty Malware. Ini tersedia di AMS Advanced dan AMS Accelerate, jika diaktifkan. Lihat [Perlindungan Malware di Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection.html) untuk informasi selengkapnya.

**catatan**  
Jika Anda memilih [Bring Your Own EPS](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-byoeps.html), maka proses untuk respons insiden berbeda dari apa yang diuraikan di halaman ini. Untuk informasi lebih lanjut, lihat dokumentasi yang direferensikan.

Ketika malware terdeteksi, insiden dibuat dan Anda diberitahu tentang peristiwa tersebut. Pemberitahuan ini diikuti oleh aktivitas remediasi apa pun yang terjadi. Operasi AMS menyelidiki, melakukan pengumpulan data, triase dan analisis, dan kemudian melakukan aktivitas penahanan sesuai arahan Anda, diikuti dengan analisis pasca peristiwa.

## Fase A: Mendeteksi
<a name="sir-malware-detect"></a>

AMS memantau acara pada instance dengan GuardDuty. AMS menentukan aktivitas pengayaan dan triase yang sesuai untuk membantu Anda membuat keputusan penahanan atau penerimaan risiko berdasarkan temuan atau jenis peringatan.

Pengumpulan data dilakukan berdasarkan jenis temuan. Pengumpulan data melibatkan kueri beberapa sumber data baik di dalam maupun di luar akun yang terpengaruh untuk membangun gambaran aktivitas yang diamati atau konfigurasi yang menjadi perhatian.

AMS melakukan korelasi temuan dengan alarm dan peringatan atau telemetri lain dari akun yang terkena dampak atau platform intelijen ancaman AMS.

## Fase B: Analisis
<a name="sir-malware-analyze"></a>

Setelah data dikumpulkan, data dianalisis untuk mengidentifikasi aktivitas atau indikator yang menjadi perhatian. Selama fase penyelidikan ini, AMS bermitra dengan Anda untuk mengintegrasikan pengetahuan bisnis dan domain tentang instans dan beban kerja untuk membantu memahami apa yang diharapkan dan apa yang tidak biasa.

Beberapa contoh informasi yang diberikan selama penyelidikan untuk mendukung pemeriksaan internal meliputi:
+ Informasi Akun: Di akun apa aktivitas malware diamati?
+ Detail Instance: Instance apa yang terlibat dengan peristiwa malware?
+ Stempel waktu acara: Kapan peringatan dipicu?
+ Informasi Beban Kerja: Apa yang berjalan pada instance? 
+ Detail malware, jika relevan: Keluarga malware dan informasi Open Source tentang malware.
+ Pengguna atau Rincian Peran: Pengguna atau peran apa yang dipengaruhi oleh dan terlibat dalam aktivitas?
+ Catatan Aktivitas: Aktivitas apa yang direkam pada instance? Ini dalam bentuk CloudWatch peristiwa, dan peristiwa sistem dari instance. Memahami cara membaca log ini akan membantu Anda dalam penyelidikan
+ Aktivitas Jaringan: Titik akhir apa yang terhubung ke instance, apa yang terhubung dengan instance, dan apa analisis lalu lintas?

Merupakan praktik terbaik untuk bersiap menerima informasi investigasi, dan memiliki rencana tentang cara menghubungi titik kontak yang sesuai untuk akun, contoh, dan beban kerja dalam organisasi Anda. Memahami topologi jaringan Anda dan koneksi yang diharapkan dapat membantu mempercepat analisis dampak. Pengetahuan tentang pengujian penetrasi yang direncanakan di lingkungan dan penerapan terbaru yang dilakukan oleh pemilik aplikasi juga dapat mempercepat penyelidikan.

Jika Anda menentukan bahwa kegiatan tersebut direncanakan dan diotorisasi, maka insiden tersebut diperbarui dan penyelidikan berakhir. Jika kompromi dikonfirmasi, maka Anda dan AMS menentukan rencana penahanan yang sesuai.

## Phace C: Mengandung dan Membasmi
<a name="sir-malware-eradicate"></a>

AMS bermitra dengan Anda untuk menentukan aktivitas penahanan yang sesuai berdasarkan data yang dikumpulkan dan informasi yang diketahui. Opsi penahanan termasuk tetapi tidak terbatas pada:
+ Melestarikan data melalui snapshot
+ Memodifikasi aturan jaringan untuk membatasi lalu lintas masuk atau keluar dari instance
+ Memodifikasi kebijakan pengguna dan peran SCP, IAM untuk membatasi akses
+ Mengakhiri, Menangguhkan, atau Mematikan Instans
+ Mengakhiri koneksi persisten
+ Memutar kredensial/kunci yang sesuai

Jika Anda memilih untuk melakukan aktivitas pemberantasan terhadap instans, AMS mendukung Anda dalam mencapai hal ini. Opsi termasuk, tetapi tidak terbatas pada:
+ Menghapus perangkat lunak yang tidak diinginkan
+ Membangun kembali instance dari gambar yang sepenuhnya ditambal dan menerapkan ulang aplikasi dan konfigurasi
+ Memulihkan instance dari cadangan sebelumnya
+ Menyebarkan aplikasi dan layanan ke instance lain dalam akun Anda yang mungkin cocok untuk meng-host beban kerja.

Penting untuk menentukan bagaimana malware dikirimkan dan dijalankan pada instance sebelum pemulihan layanan untuk memastikan bahwa setiap kontrol tambahan diterapkan untuk mencegah terulangnya malware pada instance. AMS memberikan wawasan atau informasi tambahan kepada mitra atau tim forensik Anda yang diperlukan untuk mendukung forensik.

Pada titik ini, Anda bekerja dengan Operasi AMS untuk kegiatan pemulihan. AMS bekerja sama dengan Anda untuk meminimalkan gangguan pada beban kerja dan mengamankan instans.

## Laporan Pasca Insiden
<a name="sir-malware-post-event"></a>

Sesuai kebutuhan, AMS memulai proses peninjauan investigasi untuk mengidentifikasi pelajaran yang dipetik. Sebagai bagian dari menyelesaikan COE, AMS mengkomunikasikan temuan yang relevan kepada Anda untuk membantu Anda meningkatkan proses respons insiden Anda.

AMS mendokumentasikan rincian akhir investigasi, mengumpulkan metrik yang sesuai, dan melaporkan insiden tersebut ke tim internal AMS yang memerlukan informasi, termasuk CSDM dan CA yang Anda tetapkan.