Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memvalidasi Anda Respons Insiden Keamanan AWS konfigurasi
Setelah menyelesaikan orientasi, Anda dapat memvalidasi bahwa pendaftaran, sumber deteksi, izin AWS Identity and Access Management (IAM), penahanan, dan notifikasi dikonfigurasi dengan benar sebelum peristiwa keamanan nyata terjadi. Bagian ini menyediakan prosedur verifikasi langkah demi langkah menggunakan kedua Konsol Manajemen AWS dan AWS CLI.
Topik
Sebelum Anda memvalidasi
Prasyarat untuk memvalidasi konfigurasi Respon Insiden Keamanan
Untuk menyelesaikan langkah-langkah validasi ini, pastikan Anda memiliki yang berikut:
Konsol atau AWS Command Line Interface (AWS CLI) akses ke akun administrator yang didelegasikan (akun yang Anda tentukan selama orientasi)
Wilayah AWS Tempat Anda mengaktifkan langganan
ID keanggotaan Anda (jika memvalidasi menggunakan) AWS CLI
Konfirmasikan kesiapan log
Respons Insiden Keamanan AWS tidak mengaktifkan sumber log atas nama Anda. Selama penyelidikan, insinyur mengandalkan log yang sudah ada di lingkungan Anda. Sebelum memvalidasi pengaturan Anda, konfirmasikan log berikut diaktifkan di semua akun yang tercakup dan Wilayah AWS. Tanpa log ini, insinyur Respons Insiden Keamanan memiliki visibilitas terbatas selama penyelidikan. Aktifkan mereka sebelum melanjutkan.
AWS CloudTrail: jejak acara manajemen (wajib)
Log Aliran Amazon VPC (disarankan)
Pencatatan akses server Amazon S3 untuk bucket sensitif (disarankan)
Pencatatan kueri DNS Amazon Route 53 Resolver (disarankan)
Veri GuardDuty fikasi diaktifkan
Gunakan perintah berikut untuk memverifikasi bahwa Amazon GuardDuty aktif di akun Anda:
aws guardduty list-detectors
Respons yang tidak kosong mengonfirmasi GuardDuty diaktifkan saat ini Wilayah AWS. Ulangi langkah ini untuk setiap Wilayah aktif, atau verifikasi di seluruh organisasi Anda melalui akun administrator GuardDuty yang didelegasikan.
catatan
Respons Insiden Keamanan AWS biaya tidak termasuk biaya GuardDuty penggunaan. Lihat halaman GuardDuty harga
Langkah 1: Verifikasi pendaftaran dan keanggotaan
Menggunakan Respons Insiden Keamanan AWS konsol
Masuk ke akun administrator yang didelegasikan.
Konfirmasikan bahwa status keanggotaan Anda menunjukkan Aktif. Status Tertun da menunjukkan onboarding tidak lengkap.
Di bawah cakupan Akun, verifikasi bahwa OU yang ingin Anda tangani terdaftar. Cakupan dipilih pada tingkat unit organisasi (OU), bukan di tingkat akun individu. Semua akun dalam OU yang dipilih (termasuk OU anak) dilindungi.
Konfirmasikan bahwa Region yang terdaftar cocok dengan tempat beban kerja Anda berjalan. Pemilihan wilayah terkunci saat pendaftaran dan tidak dapat diubah setelah penyiapan.
Menggunakan AWS CLI
Jalankan perintah berikut dari akun administrator yang didelegasikan:
aws security-ir list-memberships
Perintah sebelumnya mengembalikan ID dan status keanggotaan Anda.
Untuk mendapatkan detail keanggotaan lengkap termasuk konfigurasi tim respons insiden Anda, jalankan perintah berikut:
aws security-ir get-membership --membership-idmembership-id
Gunakan output perintah untuk memverifikasi informasi berikut.
Status keanggotaan adalah
ActiveAnggota tim respons insiden yang terdaftar sesuai dengan pemangku kepentingan yang Anda tuju
Setidaknya dua anggota tim respons insiden dikonfigurasi (wajib)
Verifikasi administrator yang didelegasikan
Untuk mengonfirmasi bahwa akun yang benar terdaftar sebagai administrator yang didelegasikan untuk Respon Insiden Keamanan, jalankan perintah berikut:
aws organizations list-delegated-administrators \ --service-principal security-ir.amazonaws.com
catatan
Praktik terbaik: Gunakan akun administrator yang didelegasikan yang sama yang Anda tetapkan untuk layanan AWS keamanan lainnya (seperti AWS Security Hub CSPM dan GuardDuty). Ar AWS sitektur Referensi Keamanan merekomendasikan penggunaan akun Security Tooling.
Langkah 2: Verifikasi sumber deteksi dan triase
Respons Insiden Keamanan AWS memantau temuan keamanan dari GuardDuty dan alat pihak ketiga melalui Security Hub CSPM. Layanan menggunakan peran terkait layanan untuk menyerap temuan melalui EventBridge aturan Amazon yang diterapkan ke akun Anda selama orientasi.
Verifikasi peran terkait layanan Triage
Per AWSServiceRoleForSecurityIncidentResponse_Triage an terkait layanan harus ada di akun manajemen Anda dan semua akun anggota dalam lingkup.
Untuk memverifikasi, jalankan perintah berikut di akun anggota manajemen dan dalam lingkup:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage
Tanggapan yang berhasil menegaskan peran itu ada. Jika Anda menerima NoSuchEntity kesalahan, lakukan salah satu hal berikut:
Jika Anda masuk menggunakan konsol: Per an seharusnya dibuat secara otomatis. Hubungi AWS Dukungan.
Jika Anda masuk menggunakan API atau AWS CLI: Lihat Meng aktifkan Respon Insiden Keamanan menggunakan API/CLI petunjuk tentang cara membuat peran secara manual.
Verifikasi peran terkait layanan utama
AWSServiceRoleForSecurityIncidentResponsePeran juga harus ada di akun administrator yang didelegasikan. Untuk memverifikasi bahwa peran itu ada, jalankan perintah berikut:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse
Verifikasi respon dan EventBridge aturan proaktif
Di Respons Insiden Keamanan AWS konsol, konfirmasikan bahwa respons proaktif ditampilkan sebagai diaktifkan. Saat diaktifkan, layanan melakukan hal berikut:
Mengambil temuan dari GuardDuty dan Security Hub CSPM melalui aturan EventBridge
Secara otomatis mengurutkan temuan menggunakan konteks khusus pelanggan (IP yang diketahui, entitas IAM yang diharapkan)
Membuat kasus investigasi proaktif ketika masalah keamanan yang dikonfirmasi diidentifikasi
GuardDuty Temuan arsip ditentukan jinak (dapat dilihat di GuardDuty konsol di bawah Temuan yang diarsipkan)
Veri EventBridge fikasi aturan diterapkan di akun anggota
Untuk memverifikasi bahwa EventBridge aturan diterapkan di akun anggota, selesaikan langkah-langkah berikut.
Buka EventBridge konsol Amazon di akun anggota yang ditanggung.
Pilih Aturan.
Konfirmasikan bahwa aturan dengan
SIRnama mereka ada dan Di aktifkan.
Jika aturan tidak ada, jalankan kembali pengaturan respons proaktif dari konsol Respon Insiden Keamanan atau kontak AWS Dukungan.
Verifikasi integrasi pihak ketiga (jika berlaku)
Jika Anda menggunakan alat deteksi pihak ketiga (seperti CrowdStrike Falcon, Trend Micro Cloud One, atau Fortinet Lacework ForticNapp), verifikasi bahwa temuan mereka mengalir melalui Security Hub CSPM:
Pergi ke Integrasi.
Konfirmasikan integrasi vendor pihak ketiga Anda ditampilkan sebagai M enerima temuan.
catatan
Anda tidak perlu mengaktifkan standar atau kontrol Security Hub CSPM. Hanya integrasi vendor yang diperlukan untuk Respon Insiden Keamanan untuk menyerap temuan pihak ketiga.
Langkah 3: Verifikasi pipa pencarian otomatis
Langkah ini menegaskan bahwa EventBridge pipa aktif dan temuan mencapai triase otomatis.
Tentang temuan GuardDuty sampel
GuardDutyfitur H asilkan temuan sampel bawaan menghasilkan temuan yang ditandai sebagai sampel. Triase otomatis menyaring sampel temuan untuk mencegah kebisingan; temuan tersebut tidak mengalir melalui jalur triase penuh dan tidak dapat digunakan untuk memvalidasi konfigurasi Respon Insiden Keamanan Anda. Jangan gunakan untuk langkah ini.
Validasi dengan domain GuardDuty uji
GuardDuty Dokumentasi menyediakan domain uji (guarddutyc2activityb.com) yang menghasilkan temuan nyata tanpa memerlukan peristiwa keamanan dunia nyata. Mengkueri domain ini dari instans Amazon EC2 di akun tercakup menghasilkan temuan yang diambil dan diproses oleh Respons Insiden Keamanan.
Untuk menghasilkan temuan tes:
Sambungkan ke instans Amazon EC2 di akun tercakup menggunakan Manajer Sesi Sistem atau SSH.
-
Jalankan perintah berikut:
dig guarddutyc2activityb.com Buka GuardDuty konsol, lalu pilih Find ings. Temuan itu muncul dalam waktu sekitar 5 menit.
Apa yang diharapkan:
Triase otomatis memproses temuan dan menentukan bahwa itu bukan indikasi peristiwa keamanan yang sebenarnya.
Temuan ini diarsipkan di GuardDuty. Untuk melihatnya, pilih Diarsipkan dari filter Status.
Jika Anda menggunakan Security Hub CSPM, status alur kerja temuan berubah menjadi.
SUPPRESSEDTidak ada kasus proaktif yang dibuat: ini adalah perilaku yang benar. Sebuah kasus hanya dibuka ketika triase otomatis mengidentifikasi aktivitas yang memerlukan penyelidikan manusia.
catatan
Jika temuan tes tidak muncul dalam daftar ar GuardDuty sip dalam waktu 15 menit, lihatPemecahan masalah. Jika tidak ada instans Amazon EC2 yang tersedia, lanjutkan ke Langkah 4 dan kembali ke pengujian ini ketika lingkungan Anda siap.
Langkah 4: Verifikasi notifikasi dan tim respons insiden
Verifikasi tim respons insiden Anda
Di konsol Respon Insiden Keamanan, tinjau anggota tim respons insiden yang telah dikonfigurasi. Setiap anggota menerima pemberitahuan email langsung saat kasus dibuat.
Atau, jalankan perintah berikut untuk memverifikasi menggunakan AWS CLI:
aws security-ir get-membership --membership-idmembership-id
Konfirmasikan bahwa:
Semua pemangku kepentingan yang dimaksud terdaftar
Alamat email sudah benar
Preferensi komunikasi setiap anggota diatur dengan tepat (semua opsi komunikasi diaktifkan secara default — jika anggota tidak menerima pemberitahuan, verifikasi preferensi mereka belum dihapus)
Memahami pengawas kasus
Pengamat kasus adalah pemangku kepentingan yang diberikan akses untuk melihat kasus tertentu. Rincian kunci:
Pengamat adalah per kasus, bukan per akun. Menambahkan pengamat ke satu kasus tidak memberi mereka akses ke kasus lain. Anda harus secara eksplisit menambahkan pengamat ke setiap kasus di mana Anda ingin mereka memiliki visibilitas.
Pengamat memiliki akses tampilan saja. Mereka dapat melihat detail kasus dan menerima pemberitahuan untuk pembaruan kasus, tetapi tidak dapat melakukan tindakan penahanan atau remediasi pada sumber daya.
Hingga 30 pemangku kepentingan dapat ditambahkan per kasus individu.
Setiap kasus menyertakan kebijakan IAM yang telah dicakup sebelumnya yang memberikan akses hanya ke kasus tertentu, mempertahankan akses hak istimewa terendah.
Pelingkupan per kasus ini sangat penting ketika memberikan akses ke pihak eksternal seperti mitra deteksi dan respons terkelola (MDR) atau tim investigasi pihak ketiga yang seharusnya hanya melihat kasus spesifik yang mereka terlibat.
Verifikasi pengiriman notifikasi dengan kasus uji
Cara paling efektif untuk memvalidasi aliran notifikasi ujung ke ujung adalah dengan membuat kasus uji reaktif (dikelola sendiri):
Di konsol Respon Insiden Keamanan, buat kasus baru yang dikelola sendiri.
Dalam judul dan deskripsi kasus, nyatakan dengan jelas: “Ini adalah uji validasi konfigurasi, tidak ada peristiwa keamanan nyata.”
Verifikasi bahwa semua anggota tim respons insiden yang dikonfigurasi menerima pemberitahuan email.
Tutup kasus setelah konfirmasi pemberitahuan diterima.
penting
Membuat kasus uji dapat memicu respons dari teknisi Respon Insiden Keamanan jika Anda meminta keterlibatan AWS yang didukung. Tandai kasus Anda dengan jelas sebagai tes untuk menghindari eskalasi yang tidak perlu. Gunakan langkah ini sekali untuk mengonfirmasi bahwa saluran berfungsi, lalu tutup kasing segera.
Apa yang diharapkan dari pemberitahuan kasus
Saat kasus dibuat (baik secara proaktif oleh layanan atau secara reaktif oleh tim Anda), semua anggota tim respons insiden yang dikonfigurasi menerima pemberitahuan email yang berisi detail kasus.
Veri EventBridge fikasi integrasi (jika dikonfigurasi)
Jika Anda mengonfigurasi EventBridge untuk merutekan peristiwa kasus ke platform pihak ketiga (seperti ServiceNow, Jira, Slack, atau PagerDuty), verifikasi bahwa kasus uji Anda memicu pemberitahuan yang diharapkan di sistem tersebut.
Langkah 5: Verifikasi kesiapan penahanan (opsional)
catatan
Penahanan bersifat opsional dan tidak diaktifkan secara default. Infrastruktur penahanan yang dijelaskan di bagian ini hanya diperlukan jika Anda memilih untuk mengaktifkan penahanan; tidak diperlukan Respon Insiden Keamanan untuk memantau lingkungan Anda, menyelidiki temuan, atau membuka kasus.
Jika Anda belum mengaktifkan penahanan
Tidak ada yang bisa divalidasi di sini. Respon Insiden Keamanan memberikan panduan dan penyelidikan selama peristiwa keamanan tetapi tidak mengambil tindakan penahanan otomatis kecuali Anda secara eksplisit mengizinkannya.
Jika Anda telah mengaktifkan penahanan
Periksa status penahanan di konsol. Verifikasi apakah tindakan penahanan ditampilkan sebagai Di otor isasi. Tindakan penahanan yang didukung termasuk runbook untuk:
Bucket Amazon S3 yang terpengaruh
Instans Amazon EC2 yang terpengaruh
Prinsipal IAM yang terpengaruh
Verifikasi CloudFormation StackSet sudah dikerahkan. Penahanan memerlukan peran IAM (AWSSecurityIncidentResponseContainmentdanAWSSecurityIncidentResponseContainmentExecution) di akun tercakup Anda. Untuk petunjuk tentang penerapan peran ini, lihatMenyebarkan peran penahanan dan EC2 Triage. Untuk memverifikasi StackSet yang digunakan:
Buka AWS CloudFormation di akun manajemen Anda.
Pilih StackSets.
Konfirmasikan penahanan Respons Insiden StackSet Keamanan ditampilkan
SUCCEEDEDdi semua akun target.
Jika tidak StackSet digunakan, otorisasi penahanan di konsol tidak menghasilkan tindakan penahanan aktual yang diambil.
Konfirmasikan preferensi penahanan Anda. Respon Insiden Keamanan mendukung tiga tingkat penahanan:
Diperlukan Perset ujuan (default): tidak ada tindakan penahanan tanpa otorisasi kasus per kasus eksplisit Anda.
Berisi Dikonfirmasi: penahanan proaktif sumber daya yang dikonfirmasi terpengaruh.
Mengandung Diduga: penahanan proaktif sumber daya dengan kemungkinan besar terpengaruh.
Untuk mengirimkan atau memperbarui preferensi Anda, buat AWS Dukungan kasus dengan tipe kasus Tek nis: Layanan Respon Insiden Keamanan/Lainnya.
Jika Anda menginginkan Triage EC2: Terapkan Containment dengan template EC2 Triage. CloudFormation Ini memungkinkan teknisi Respon Insiden Keamanan untuk mengumpulkan data investigasi dari instans Amazon EC2 menggunakan AWS Systems Manager.
Langkah 6: Konfirmasikan operasi yang sedang berlangsung
Setelah menyelesaikan validasi awal, gunakan indikator ini untuk mengonfirmasi bahwa Respon Insiden Keamanan terus beroperasi seperti yang diharapkan.
Tidak adanya kasus adalah normal
Respon Insiden Keamanan menciptakan kasus proaktif hanya ketika triase otomatis mengidentifikasi aktivitas yang memerlukan penyelidikan manusia. Ketika triase menentukan temuan tidak berbahaya, itu mengarsipkan temuan tanpa membuat kasus atau menghubungi tim Anda. Penerapan tanpa kasus terbuka dan aliran GuardDuty temuan yang diarsipkan yang konsisten beroperasi sebagaimana dimaksud.
Jika Anda tidak melihat kasus dan tidak ada temuan yang diarsipkan setelah lingkungan Anda aktif selama beberapa hari, pipeline mungkin tidak terhubung; verifikasi Langkah 2 dan 3.
catatan
Kasus proaktif tanpa tanggapan pelanggan selama 5 hari ditutup secara otomatis.
Temuan yang diarsipkan dan aturan penindasan sebagai sinyal kesehatan
Ketika Respon Insiden Keamanan memproses temuan dari waktu ke waktu, itu menciptakan dua artefak yang dapat diamati:
Temuan yang diarsipkan: temuan bahwa triase otomatis ditentukan jinak. Ini menumpuk dari waktu ke waktu dan terlihat di GuardDuty konsol di bawah Temuan, lalu pilih Diarsipkan.
GuardDuty aturan penindasan: untuk menemukan jenis yang dikonfirmasi sebagai aktivitas yang diharapkan di lingkungan Anda, Respon Insiden Keamanan menerapkan aturan penindasan bernama (diawali dengan
SIRTriage-). Ini adalah sinyal berkelanjutan yang paling jelas bahwa triase otomatis bekerja secara aktif. Lihat mereka di GuardDuty konsol di bawah Aturan Penindasan.
Tim respons insiden Anda diberi tahu saat aturan penindasan dibuat. Jika aturan dibuat karena kesalahan, hubungi AWS Dukungan untuk meminta rollback. Temuan yang diarsipkan GuardDuty disimpan selama 90 hari.
Laporan aktivitas bulanan
Respon Insiden Keamanan mengirimkan laporan aktivitas bulanan ke tim respons insiden Anda yang merangkum temuan yang diproses, hasil triase, dan setiap kasus yang dibuka. Jika tim Anda belum menerima laporan setelah bulan kalender penuh pertama Anda beroperasi, verifikasi bahwa anggota tim respons insiden telah mengaktifkan komunikasi. Untuk masalah lain yang terkait dengan laporan bulanan, hubungi Tim Akun Anda atau buka Kasus Dukungan dengan jenis kasus: Tek nis: Layanan Respons Insiden Keamanan/Lain nya dan sertakan informasi berikut:
Nama organisasi Anda
Pelaporan month/year yang Anda harapkan (misalnya, “Mei 2026")
ID Keanggotaan Respon Insiden Keamanan Anda jika diketahui
ID akun yang dicakup oleh keanggotaan Respon Insiden Keamanan Anda
Apa yang diharapkan dari insinyur Respons Insiden Keamanan
Saat Anda membuat kasus yang AWS didukung atau layanan membuatnya secara proaktif, teknisi Respon Insiden Keamanan mengakui kasus baru dalam waktu 15 menit. SLO pengakuan 15 menit ini berlaku untuk semua jenis AWS kasus yang didukung; baik peristiwa keamanan aktif maupun investigasi. Pengakuan awal menegaskan kasus Anda sedang ditinjau; garis waktu penilaian lengkap dapat bervariasi berdasarkan tingkat keparahan dan kompleksitas kasus.
Untuk kasus proaktif (dibuat secara otomatis saat layanan triase mengidentifikasi masalah keamanan yang dikonfirmasi), layanan membuat kasus setelah triase otomatis mengonfirmasi masalah, dan tim respons insiden Anda diberi tahu saat kasus dibuka.
Daftar periksa validasi
Gunakan daftar periksa ini untuk mengonfirmasi konfigurasi Anda selesai:
Sumber log diaktifkan: peristiwa CloudTrail manajemen (diperlukan), Log Aliran Amazon VPC, pencatatan akses Amazon S3, pencatatan kueri DNS (disarankan)
GuardDuty diaktifkan di semua akun dan Wilayah aktif
Status keanggotaan Aktif di konsol Respon Insiden Keamanan
Wilayah benar (terkunci saat pendaftaran)
Akun administrator yang didelegasikan sudah benar (disarankan akun Security Tooling)
Ruang lingkup akun mencakup OU yang dimaksudkan
AWSServiceRoleForSecurityIncidentResponse_Triageada di akun manajemenAWSServiceRoleForSecurityIncidentResponse_Triageada di akun anggota dalam lingkupAWSServiceRoleForSecurityIncidentResponseada di akun administrator yang didelegasikanThird-party integrasi (jika berlaku) ditampilkan sebagai penerimaan temuan di Security Hub CSPM
EventBridge aturan
SIRdengan nama ada dan diaktifkan di akun anggotaAnggota tim respons insiden dikonfigurasi dengan informasi kontak yang benar dan komunikasi diaktifkan
Kasus uji dibuat dan pemberitahuan email diterima oleh semua anggota tim
Uji pencarian domain (
guarddutyc2activityb.com) diarsipkan dalam waktu 15 menitPenahanan berhasil StackSet diterapkan (jika penahanan diaktifkan)
Preferensi penahanan dikirimkan (jika penahanan diaktifkan)
EventBridge integrasi (jika dikonfigurasi) mengirimkan acara ke platform pihak ketiga
Temuan yang diarsipkan terlihat GuardDuty setelah minggu pertama operasi
Verifikasi penagihan
Pelanggan Dukungan Perusahaan dan Operasi Terpadu: Respon Insiden Keamanan disertakan tanpa biaya tambahan sebagai bagian dari paket dukungan Anda. Anda tidak melihat biaya Respon Insiden Keamanan di AWS Penjelajah Biaya atau AWS Laporan Biaya dan Penggunaan.
Semua pelanggan lain: Harga didasarkan pada jumlah temuan keamanan yang dicerna. 10.000 temuan pertama per bulan gratis. Untuk detailnya, lihat Respons Insiden Keamanan AWS harga
Pemecahan masalah
| Gejala | Kemungkinan penyebabnya | Resolusi |
|---|---|---|
| Status Keanggotaan Tertunda | Onboarding belum selesai | Selesaikan semua langkah penyiapan. Lihat Memulai. |
list-membershipsmengembalikan kosong |
Wilayah CLI tidak cocok dengan Wilayah langganan | Tentukan Wilayah tempat Anda mengaktifkan: --region |
| Triage SLR tidak ditemukan di akun manajemen | Terpasang melalui API/CLI tanpa membuatnya | Buat secara manual: aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" |
| Akun anggota hilang dari cakupan | SLR tidak digunakan ke akun anggota | Re-run pengaturan respons proaktif dari konsol Respon Insiden Keamanan |
| EventBridge aturan tidak ada di akun | Pengaturan respons proaktif tidak lengkap | Re-run mengatur atau memeriksa StackSet kegagalan di CloudFormation |
| GuardDuty Temuan sampel tidak diproses | Temuan sampel disaring oleh triase otomatis (diharapkan) | Periksa temuan yang diarsipkan di GuardDuty |
| Pencarian domain uji tidak diarsipkan setelah 15 menit | EventBridge aturan hilang atau dinonaktifkan; GuardDuty tidak diaktifkan | Verifikasi Langkah 2 dan 3 |
| Tidak ada kasus setelah periode yang lama | Semua temuan diarsipkan berdasarkan triase (diharapkan), atau pipa tidak terhubung | Periksa temuan yang diarsipkan di GuardDuty. Jika tidak ada, verifikasi EventBridge aturan dan respons proaktif. |
| Tidak ada GuardDuty temuan yang diuraikan | GuardDuty tidak diaktifkan atau tidak menghasilkan temuan | Veri GuardDuty fikasi diaktifkan: aws guardduty list-detectors |
| Layanan tidak memproses temuan | Triase otomatis menentukan bahwa aktivitas yang terdeteksi diharapkan | Tinjau temuan GuardDuty yang diarsipkan dan temuan Security Hub CSPM SUPPRESSED |
| Anggota tim tidak menerima notifikasi | Email yang salah, komunikasi dinonaktifkan, atau email dalam spam | Verifikasi alamat email dan preferensi komunikasi; periksa folder spam |
| Tindakan penahanan tidak dijalankan | StackSet tidak digunakan atau preferensi tidak dikirimkan | Verifikasi StackSet status di CloudFormation dan konfirmasikan preferensi yang dikirimkan melalui AWS Dukungan |
Sumber daya terkait
