Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# 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 | Menentukan apakah peristiwa keamanan merupakan insiden dan menilai cakupan 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 | Mengembalikan sistem ke keadaan aman yang diketahui dan memantau 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. Peringatan menghasilkan pemberitahuan untuk memulai proses respons insiden berdasarkan aktivitas yang menarik di akun AWS.
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-pola kejahatan muncul melalui *taktik*, *teknik*, dan *prosedur* (TTP) aktor ancaman baru atau yang dimodifikasi.
+ 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** - Layanan AWS 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** — Layanan AWS, infrastruktur, dan log 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 biaya AWS Anda](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html) guna 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).
+ **Kepercayaan dan keamanan AWS** – Dukungan dapat menghubungi pelanggan apabila kami mengidentifikasi aktivitas penyalahgunaan atau yang 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 akun AWS, yang seharusnya hanya digunakan untuk aktivitas spesifik dan terdefinisi dengan sangat baik. Mereka mengaitkannya dengan kontrol pencegahan yang diterapkan dengan kebijakan kontrol layanan (SCP) organisasi AWS. 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. Sebaliknya, peringatan organisasi berdasarkan temuan tersebut harus disesuaikan tingkat kekritisannya.
# 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”. Ketika Anda melihat lebih jauh ke dalam dokumentasi, hal ini memberi tahu Anda bahwa "Model ML mengevaluasi semua permintaan API di akun Anda dan mengidentifikasi peristiwa anomali yang terkait dengan teknik yang digunakan oleh pihak penyerang," yang mengindikasikan 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 keamanan. defense-in-depth
# 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 sebaiknya menggunakan kerangka kerja seperti MITRE ATT&CK untuk memahami taktik, teknik, dan prosedur (TTP) aktor ancaman. Kerangka 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 cakupan, dan menilai dampak dari kemungkinan penyusupan.
+ *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 diuntungkan dengan adanya pekerjaan AWS Glue untuk memuat informasi intelijen ancaman dalam bentuk 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 secara 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
Otomatisasi merupakan bagian integral dari tata kelola AWS Cloud. 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 posting blog [How to enrich AWS Security Hub findings with account metadata](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/) untuk mengetahui contoh penggunaan 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. Di AWS, hal 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 menjaga lacak balak 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 layanan/bidang kontrol (, peristiwa data Amazon S3CloudTrail, Log Aliran VPC), data (metadata dan objek Amazon S3), dan sumber daya (database, instans Amazon EC2).
Log layanan/bidang kontrol dapat dikumpulkan untuk analisis lokal atau, idealnya, langsung dikueri menggunakan layanan AWS native (jika berlaku). Data (termasuk metadata) dapat langsung dikueri untuk mendapatkan informasi yang relevan atau untuk memperoleh objek sumber; misalnya, gunakan AWS CLI untuk memperoleh bucket Amazon S3 serta metadata objek dan secara langsung memperoleh objek sumber. Sumber daya perlu dikumpulkan dengan cara yang konsisten dengan jenis sumber daya dan metode analisis yang dimaksudkan. Misalnya, basis data dapat dikumpulkan dengan membuat salinan/snapshot dari sistem yang menjalankan basis data, membuat salinan/snapshot dari seluruh basis data itu sendiri, atau mengueri dan mengekstrak data serta log tertentu dari basis data yang relevan dengan penyelidikan.
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. **Mendapatkan metadata instans** – Dapatkan metadata instans yang relevan dengan penyelidikan dan kueri data (ID instans, jenis, alamat IP, ID VPC/subnet, Wilayah, ID Amazon Machine Image (AMI), grup keamanan yang terlampir, 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 pengumpulan respons langsung/artefak jika Anda menggunakan volume penyimpanan instans.
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) Melakukan pengumpulan respons langsung/artefak** – Lakukan pengumpulan data yang ditargetkan (disk/memori/log) melalui respons langsung pada sistem hanya jika disk atau memori tidak dapat diperoleh, atau jika ada alasan bisnis atau operasional yang valid. Melakukan hal ini akan memodifikasi data sistem dan artefak yang berharga.
1. **Menonaktifkan instans** – Lepaskan instans dari grup penskalaan otomatis, batalkan register instans dari penyeimbang beban, dan sesuaikan atau terapkan profil instans yang dibuat sebelumnya 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 ke depannya dari instans terhadap lingkungan.
+ Terus jalankan instans dalam lingkungan terisolasi yang diinstrumentasi untuk pemantauan.
Meskipun tidak direkomendasikan sebagai pendekatan standar, jika suatu situasi memerlukan pengamatan instans secara berkelanjutan (seperti ketika data atau indikator tambahan diperlukan untuk melakukan penyelidikan dan analisis instans secara komprehensif), Anda dapat mempertimbangkan untuk mematikan instans, membuat AMI instans, dan meluncurkan kembali instans tersebut di akun forensik khusus Anda dalam lingkungan sandbox yang telah diinstrumentasi sebelumnya agar sepenuhnya diisolasi dan dikonfigurasi dengan instrumentasi untuk memfasilitasi pemantauan instans secara berkelanjutan (misalnya, Log Alur VPC atau Pencerminan Lalu Lintas VPC).
**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. [NIST SP 800-61 Computer Security Incident Handling Guide](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)
Namun, mengenai layanan di AWS, langkah-langkah penahanan mendasar dapat dikerucutkan 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 layanan AWS 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 menahan lalu lintas yang tidak sah ke instans Amazon EC2 atau sumber daya 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 (ACL web) dapat dikonfigurasi di AWS WAF untuk memberikan kontrol ketat atas permintaan web yang ditanggapi sumber daya. Anda dapat menambahkan alamat IP atau rentang jaringan ke set IP yang dikonfigurasi di 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/whitepapers/latest/aws-security-incident-response-guide/images/source-containment-example.png)
# 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 penahanan akses menggunakan layanan AWS 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. Hal 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 kredensial statis jangka panjang untuk menandatangani permintaan terprogram ke AWS CLI atau API AWS 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 kredensial keamanan sementara** – Kredensial keamanan sementara dapat digunakan oleh organisasi untuk mengontrol akses ke sumber daya AWS dan dimulai dengan awalan *ASIA* (untuk informasi tambahan, lihat bagian *Memahami awalan ID unik* di [pengidentifikasi 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 dan buat ulang pengguna IAM dengan kunci akses yang disusupi.
+ **AWS WAF** - Teknik tertentu yang digunakan oleh pengguna yang tidak diotorisasi termasuk pola lalu lintas berbahaya yang umum, seperti permintaan yang berisi injeksi SQL dan pembuatan skrip lintas situs (XSS). AWS WAF dapat dikonfigurasi untuk mencocokkan dan menolak lalu lintas dengan menerapkan teknik ini menggunakan pernyataan aturan bawaan AWS WAF.
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/whitepapers/latest/aws-security-incident-response-guide/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 layanan AWS meliputi:
+ **ACL Jaringan **– ACL jaringan (NACL) yang dikonfigurasi pada subnet yang berisi sumber daya AWS dapat ditambahkan dengan aturan penolakan. Aturan penolakan ini dapat diterapkan untuk mencegah akses ke sumber daya AWS tertentu; tetapi, menerapkan NACL akan memengaruhi setiap sumber daya di subnet, tidak hanya sumber daya yang diakses tanpa otorisasi. Aturan yang tercantum dalam NACL diproses dalam urutan top-down, sehingga aturan pertama dalam NACL yang ada harus dikonfigurasi untuk menolak lalu lintas yang tidak sah ke sumber daya dan subnet yang ditargetkan. Sebagai alternatif, NACL yang benar-benar baru dapat dibuat dengan aturan penolakan tunggal untuk lalu lintas masuk dan keluar dan dikaitkan dengan subnet yang berisi sumber daya yang ditargetkan untuk mencegah akses ke subnet menggunakan NACL 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.
+ **VPC Isolasi **– VPC isolasi 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 penskalaan otomatis dan penyeimbang beban **– Sumber daya AWS yang terlampir pada grup penskalaan otomatis dan penyeimbang beban harus dilepas dan dideregistrasi sebagai bagian dari prosedur penahanan tujuan. Pelepasan dan deregistrasi sumber daya AWS dapat dilakukan menggunakan Konsol Manajemen AWS, AWS CLI, dan AWS SDK.
Contoh penahanan tujuan ditunjukkan pada diagram berikut dengan analis respons insiden yang menambahkan NACL 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/whitepapers/latest/aws-security-incident-response-guide/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 sumber daya AWS, 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 AWS Partner atau vendor lainnya. AWS tidak menawarkan alat native untuk analisis atau penghapusan malware. Jika Anda menggunakan modul GuardDuty Malware untuk Amazon EBS, rekomendasi mungkin tersedia untuk temuan yang disediakan.
Setelah Anda memberantas sumber daya terpengaruh yang teridentifikasi, AWS menyarankan 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 munculnya kembali 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 menerapkan ulang dari sumber tepercaya menggunakan otomatisasi, terkadang di akun AWS yang baru.
+ 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/whitepapers/latest/aws-security-incident-response-guide/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/whitepapers/latest/aws-security-incident-response-guide/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/whitepapers/latest/aws-security-incident-response-guide/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/whitepapers/latest/aws-security-incident-response-guide/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/whitepapers/latest/aws-security-incident-response-guide/operations-conclusion.html) |