Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Convalida del tuo AWS Security Incident Response configurazione
Dopo aver completato l'onboarding, puoi convalidare che la registrazione, le fonti di rilevamento, le autorizzazioni AWS Identity and Access Management (IAM), il contenimento e le notifiche siano configurate correttamente prima che si verifichi un vero evento di sicurezza. Questa sezione fornisce procedure di verifica dettagliate utilizzando sia l'interfaccia a riga di comando che la CLI. Console di gestione AWS AWS
Argomenti
Prima di convalidare
Prerequisiti per la convalida della configurazione di Security Incident Response
Per completare questi passaggi di convalida, assicurati di disporre di quanto segue:
Accesso tramite console o AWS Command Line Interface (AWS CLI) al tuo account amministratore delegato (l'account che hai designato durante l'onboarding)
Il Regione AWS luogo in cui hai attivato l'abbonamento
Il tuo ID di iscrizione (se convalidato utilizzando il AWS CLI)
Conferma la disponibilità del registro
AWS Security Incident Response non abilita le fonti di log per tuo conto. Durante un'indagine, gli ingegneri si affidano ai log già presenti nel tuo ambiente. Prima di convalidare la configurazione, verificate che i seguenti registri siano abilitati in tutti gli account coperti e Regioni AWS. Senza questi registri, gli ingegneri di Security Incident Response hanno una visibilità limitata durante le indagini. Abilitali prima di procedere.
AWS CloudTrail: percorso degli eventi di gestione (obbligatorio)
Amazon VPC Flow Logs (consigliato)
Registrazione degli accessi al server Amazon S3 per bucket sensibili (consigliata)
Registrazione delle query DNS di Amazon Route 53 Resolver (consigliata)
GuardDuty La verifica è abilitata
Usa il seguente comando per verificare che Amazon GuardDuty sia attivo nei tuoi account:
aws guardduty list-detectors
Una risposta non vuota conferma che GuardDuty è abilitata nella versione corrente Regione AWS. Ripeti questo passaggio per ogni regione attiva o verifica in tutta l'organizzazione tramite l'account amministratore GuardDuty delegato.
Nota
AWS Security Incident Response i costi non includono i costi GuardDuty di utilizzo. Consulta la pagina GuardDuty dei prezzi
Passaggio 1: verifica l'iscrizione e l'iscrizione
Utilizzo di AWS Security Incident Response console
Accedi all'account amministratore delegato.
Conferma che lo stato della tua iscrizione sia attivo. Lo stato In sospeso indica che l'onboarding è incompleto.
Nella sezione Ambito dell'account, verifica che le unità organizzative che intendevi coprire siano elencate. La copertura è selezionata a livello di unità organizzativa (OU), non a livello di singolo account. Tutti gli account all'interno di un'unità organizzativa selezionata (comprese le unità organizzative secondarie) sono coperti.
Verifica che la regione elencata corrisponda a dove vengono eseguiti i carichi di lavoro. La selezione della regione è bloccata al momento della registrazione e non può essere modificata dopo la configurazione.
Utilizzo di AWS CLI
Esegui il comando seguente dal tuo account amministratore delegato:
aws security-ir list-memberships
Il comando precedente restituisce l'ID e lo stato dell'iscrizione.
Per ottenere i dettagli completi sull'iscrizione, inclusa la configurazione del team di risposta agli incidenti, esegui il seguente comando:
aws security-ir get-membership --membership-idmembership-id
Usa l'output del comando per verificare le seguenti informazioni.
Lo stato di iscrizione è
ActiveI membri del team di risposta agli incidenti elencati corrispondono alle parti interessate previste
Sono configurati almeno due membri del team di risposta agli incidenti (obbligatorio)
Verifica l'amministratore delegato
Per confermare che l'account corretto è registrato come amministratore delegato per Security Incident Response, esegui il comando seguente:
aws organizations list-delegated-administrators \ --service-principal security-ir.amazonaws.com
Nota
Procedura consigliata: utilizza lo stesso account di amministratore delegato impostato per altri servizi AWS di sicurezza (come AWS Security Hub CSPM e GuardDuty). La AWS Security Reference Architecture consiglia di utilizzare l'account Security Tooling.
Passaggio 2: verifica delle fonti di rilevamento e del triage
AWS Security Incident Response monitora i risultati di sicurezza provenienti da strumenti GuardDuty di terze parti tramite Security Hub CSPM. Il servizio utilizza un ruolo collegato al servizio per acquisire i risultati tramite le EventBridge regole Amazon distribuite ai tuoi account durante l'onboarding.
Verifica il ruolo collegato al servizio Triage
Il ruolo AWSServiceRoleForSecurityIncidentResponse_Triage collegato al servizio deve essere presente nel tuo account di gestione e in tutti gli account dei membri inclusi nell'ambito.
Per verificare, esegui il comando seguente negli account dei membri di gestione e inclusi nell'ambito:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage
Una risposta positiva conferma l'esistenza del ruolo. Se ricevi un NoSuchEntity errore, esegui una delle seguenti operazioni:
Se hai effettuato l'onboarding utilizzando la console: il ruolo dovrebbe essere stato creato automaticamente. Contatto. Supporto AWS
Se hai effettuato l'onboarding utilizzando l'API o AWS CLI: vedi Enable Security Incident Response using the API/CLI per istruzioni sulla creazione manuale del ruolo.
Verifica il ruolo principale collegato al servizio
Il AWSServiceRoleForSecurityIncidentResponse ruolo deve essere presente anche nel tuo account di amministratore delegato. Per verificare che il ruolo esista, esegui il comando seguente:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse
Verifica la risposta e EventBridge le regole proattive
Nella AWS Security Incident Response console, conferma che la risposta proattiva sia visualizzata come abilitata. Se abilitato, il servizio esegue le seguenti operazioni:
Acquisisce i risultati di GuardDuty Security Hub CSPM tramite regole EventBridge
Classifica automaticamente i risultati utilizzando un contesto specifico del cliente (IP noti, entità IAM previste)
Crea casi di indagine proattivi quando vengono identificati problemi di sicurezza confermati
GuardDuty Archivia i risultati ritenuti innocui (visualizzabili nella GuardDuty console in Risultati archiviati)
Verifica che EventBridge le regole siano implementate negli account dei membri
Per verificare che EventBridge le regole siano implementate negli account dei membri, completa i passaggi seguenti.
Apri la EventBridge console Amazon in un account membro coperto.
Seleziona Rules (Regole).
Verifica che le regole con
SIRil loro nome siano presenti e abilitate.
Se mancano le regole, esegui nuovamente la configurazione della risposta proattiva dalla console o dal contatto Security Incident Response. Supporto AWS
Verifica le integrazioni di terze parti (se applicabile)
Se utilizzi strumenti di rilevamento di terze parti (come CrowdStrike Falcon, Trend Micro Cloud One o Fortinet Lacework ForticNapp), verifica che i loro risultati siano trasmessi tramite Security Hub CSPM:
Apri la AWS Security Hub CSPM console
. Vai a Integrazioni.
Verifica che l'integrazione con un fornitore di terze parti sia indicata come Accettazione dei risultati.
Nota
Non è necessario abilitare gli standard o i controlli CSPM di Security Hub. Per consentire a Security Incident Response di acquisire i risultati di terze parti sono necessarie solo le integrazioni dei fornitori.
Passaggio 3: verifica la pipeline di ricerca automatica
Questo passaggio conferma che la EventBridge pipeline è attiva e che i risultati stanno arrivando al triage automatico.
Informazioni sui risultati GuardDuty degli esempi
GuardDutyLa funzione Genera campioni di risultati incorporata produce risultati contrassegnati come campioni. Il triage automatico filtra i risultati dei campioni per prevenire il rumore; non fluiscono attraverso l'intera pipeline di triage e non possono essere utilizzati per convalidare la configurazione di Security Incident Response. Non utilizzarli per questo passaggio.
Convalida con il dominio di GuardDuty test
La GuardDuty documentazione fornisce un dominio di test (guarddutyc2activityb.com) che genera una scoperta reale senza richiedere eventi di sicurezza reali. L'interrogazione di questo dominio da un'istanza Amazon EC2 in un account coperto produce la conclusione che Security Incident Response inserisce ed elabora.
Per generare un risultato di prova:
Connettiti a un'istanza Amazon EC2 in un account coperto utilizzando Systems Manager Session Manager o SSH.
-
Esegui il comando seguente:
dig guarddutyc2activityb.com Apri la GuardDuty console, quindi scegli Findings. Il risultato viene visualizzato entro circa 5 minuti.
Cosa aspettarsi:
Il triage automatico elabora la scoperta e determina che non è indicativa di un vero evento di sicurezza.
La scoperta è archiviata in. GuardDuty Per visualizzarlo, seleziona Archiviato dal filtro Stato.
Se utilizzi Security Hub CSPM, lo stato del flusso di lavoro della ricerca cambia in.
SUPPRESSEDNon viene creato alcun caso proattivo: si tratta di un comportamento corretto. Un caso viene aperto solo quando il triage automatico identifica un'attività che richiede un'indagine umana.
Nota
Se il risultato del test non appare nell'elenco GuardDuty archiviato entro 15 minuti, consultaRisoluzione dei problemi. Se non è disponibile alcuna istanza Amazon EC2, procedi al passaggio 4 e torna a questo test quando l'ambiente è pronto.
Fase 4: Verifica le notifiche e il team di risposta agli incidenti
Verifica il tuo team di risposta agli incidenti
Nella console Security Incident Response, esamina i membri del team di risposta agli incidenti configurati. Ogni membro riceve notifiche e-mail immediate quando viene creato un caso.
Oppure, esegui il comando seguente per verificare utilizzando AWS CLI:
aws security-ir get-membership --membership-idmembership-id
Conferma che:
Sono elencate tutte le parti interessate previste
Gli indirizzi e-mail sono corretti
Le preferenze di comunicazione di ciascun membro sono impostate in modo appropriato (tutte le opzioni di comunicazione sono abilitate per impostazione predefinita: se un membro non riceve notifiche, verifica che le sue preferenze non siano state cancellate)
Comprendere i case watcher
I case watcher sono parti interessate a cui viene concesso l'accesso per visualizzare un caso specifico. Dettagli chiave:
Gli osservatori si intendono per caso, non per account. L'aggiunta di un osservatore a un caso non consente loro di accedere a nessun altro caso. Devi aggiungere esplicitamente osservatori a ogni caso in cui desideri che abbiano visibilità.
Gli osservatori hanno accesso di sola visualizzazione. Possono visualizzare i dettagli dei casi e ricevere notifiche per gli aggiornamenti dei casi, ma non possono eseguire azioni di contenimento o correzione sulle risorse.
È possibile aggiungere fino a 30 parti interessate per singolo caso.
Ogni caso include una policy IAM prestabilita che concede l'accesso solo a quel caso specifico, mantenendo l'accesso con privilegi minimi.
Questo ambito per caso è particolarmente importante quando si concede l'accesso a soggetti esterni come partner di rilevamento e risposta gestiti (MDR) o team investigativi di terze parti che dovrebbero vedere solo il caso specifico in cui sono coinvolti.
Verifica l'invio delle notifiche con un test case
Il modo più efficace per convalidare il flusso di notifiche end-to-end è creare un test case reattivo (autogestito):
Nella console Security Incident Response, crea un nuovo caso autogestito.
Nel titolo e nella descrizione del caso, indica chiaramente: «Questo è un test di convalida della configurazione, non esiste un vero evento di sicurezza».
Verifica che tutti i membri del team di risposta agli incidenti configurato ricevano la notifica via email.
Chiudi il caso dopo aver confermato la ricezione delle notifiche.
Importante
La creazione di un test case può attivare una risposta da parte dei tecnici di Security Incident Response se richiedi un intervento AWS supportato. Contrassegna chiaramente il tuo caso come test per evitare inutili escalation. Effettua questo passaggio una volta per confermare che il canale funzioni, quindi chiudi immediatamente il caso.
Cosa aspettarsi dalle notifiche dei casi
Quando viene creato un caso (in modo proattivo dal servizio o in modo reattivo dal team), tutti i membri del team di risposta agli incidenti configurato ricevono una notifica e-mail contenente i dettagli del caso.
Verifica l' EventBridge integrazione (se configurata)
Se hai configurato la configurazione EventBridge per indirizzare gli eventi del caso a piattaforme di terze parti (come ServiceNow Jira, Slack o PagerDuty), verifica che il test case attivi la notifica prevista in quei sistemi.
Fase 5: Verifica della disponibilità al contenimento (opzionale)
Nota
Il contenimento è facoltativo e non è abilitato per impostazione predefinita. L'infrastruttura di contenimento descritta in questa sezione è necessaria solo se si sceglie di abilitare il contenimento; non è necessaria per Security Incident Response per monitorare l'ambiente, esaminare i risultati o aprire casi.
Se non hai abilitato il contenimento
Niente da convalidare qui. Security Incident Response fornisce indicazioni e indagini durante gli eventi di sicurezza, ma non intraprende azioni di contenimento automatiche a meno che l'utente non lo autorizzi esplicitamente.
Se hai abilitato il contenimento
Controlla lo stato del contenimento nella console. Verifica se le azioni di contenimento sono visualizzate come Autorizzate. Le azioni di contenimento supportate includono runbook per:
Bucket Amazon S3 interessati
Istanze Amazon EC2 interessate
Principi IAM interessati
Verifica che CloudFormation StackSet sia implementato. Il contenimento richiede ruoli IAM (AWSSecurityIncidentResponseContainmenteAWSSecurityIncidentResponseContainmentExecution) nei tuoi account coperti. Per istruzioni sull'implementazione di questi ruoli, consulta. Implementa ruoli di contenimento e triage EC2 Per verificare che StackSet sia distribuito:
Apri AWS CloudFormation nel tuo account di gestione.
Scegli StackSets.
Verifica che il contenimento della risposta agli incidenti di sicurezza sia StackSet visualizzato
SUCCEEDEDin tutti gli account di destinazione.
Se StackSet non viene implementato, l'autorizzazione di contenimento nella console non comporta l'esecuzione di azioni di contenimento effettive.
Conferma la tua preferenza di contenimento. Security Incident Response supporta tre livelli di contenimento:
Approvazione richiesta (impostazione predefinita): nessuna azione di contenimento senza l'esplicita autorizzazione caso per caso.
Contenimento confermato: contenimento proattivo delle risorse confermato come interessato.
Contenimento dei sospetti: contenimento proattivo delle risorse con elevata probabilità di essere compromessi.
Per inviare o aggiornare le tue preferenze, crea un Supporto AWS caso di tipo tecnico: Security Incident Response Service/Altro.
Se desideri EC2 Triage: implementa il modello Containment with EC2 Triage. CloudFormation Ciò consente agli ingegneri di Security Incident Response di raccogliere dati investigativi dalle istanze Amazon EC2 utilizzando. AWS Systems Manager
Fase 6: Conferma del funzionamento in corso
Dopo aver completato la convalida iniziale, utilizza questi indicatori per confermare che Security Incident Response funziona continuamente come previsto.
L'assenza di casi è normale
La risposta agli incidenti di sicurezza crea un caso proattivo solo quando il triage automatico identifica un'attività che richiede un'indagine umana. Quando il triage determina che un risultato è innocuo, lo archivia senza creare un caso o contattare il team. Un'implementazione senza casi aperti e con un flusso costante di GuardDuty risultati archiviati funziona come previsto.
Se non riscontri alcun caso e nessun risultato archiviato dopo che l'ambiente è stato attivo per diversi giorni, la pipeline potrebbe non essere connessa; verifica i passaggi 2 e 3.
Nota
I casi proattivi senza risposta da parte del cliente per 5 giorni vengono chiusi automaticamente.
Risultati archiviati e regole di soppressione come segnali sullo stato di salute
Man mano che Security Incident Response elabora i risultati nel tempo, crea due artefatti osservabili:
Risultati archiviati: risultati che il triage automatico ha determinato come benigni. Questi si accumulano nel tempo e sono visibili nella GuardDuty console in Risultati, quindi seleziona Archiviati.
GuardDuty regole di soppressione: per trovare i tipi confermati come attività prevista nel tuo ambiente, Security Incident Response implementa regole di soppressione denominate (precedute da).
SIRTriage-Questi sono i segnali continui più chiari che indicano che il triage automatico funziona attivamente. Visualizzali nella GuardDuty console in Regole di soppressione.
Il tuo team di risposta agli incidenti riceve una notifica quando viene creata una regola di soppressione. Se una regola è stata creata per errore, contattaci Supporto AWS per richiedere un rollback. I risultati archiviati vengono conservati GuardDuty per 90 giorni.
Rapporto mensile sulle attività
Security Incident Response invia un rapporto mensile sull'attività al team di risposta agli incidenti che riassume i risultati elaborati, i risultati del triage e tutti i casi aperti. Se il tuo team non ha ricevuto una segnalazione dopo il primo mese di calendario completo di attività, verifica che i membri del team di risposta agli incidenti abbiano abilitato le comunicazioni. Per qualsiasi altro problema relativo al rapporto mensile, contatta il team del tuo account o apri un caso di assistenza con il tipo di caso: Tecnico: Security Incident Response Service/Altro e includi le seguenti informazioni:
Nome della tua organizzazione
La segnalazione month/year prevista (ad esempio, «maggio 2026")
Il tuo ID di iscrizione a Security Incident Response, se noto
Gli ID degli account coperti dalla tua iscrizione a Security Incident Response
Cosa aspettarsi dai tecnici di Security Incident Response
Quando si crea un caso AWS supportato o il servizio ne crea uno in modo proattivo, i tecnici di Security Incident Response riconoscono i nuovi casi entro 15 minuti. Questo SLO di conferma di 15 minuti si applica a tutti i tipi di casi AWS supportati, sia agli eventi di sicurezza attivi che alle indagini. La conferma iniziale conferma che il caso è in fase di esame; la tempistica completa della valutazione può variare in base alla gravità e alla complessità del caso.
Per i casi proattivi (creati automaticamente quando il servizio di triage identifica un problema di sicurezza confermato), il servizio crea il caso dopo che il triage automatico ha confermato il problema e il team di risposta agli incidenti riceve una notifica quando il caso viene aperto.
Lista di controllo per la convalida
Usa questa lista di controllo per confermare che la configurazione è completa:
Fonti di log abilitate: eventi di CloudTrail gestione (obbligatorio), Amazon VPC Flow Logs, registrazione degli accessi ad Amazon S3, registrazione delle query DNS (consigliata)
GuardDuty è abilitato in tutti gli account e le regioni attive
Lo stato di iscrizione è Attivo nella console Security Incident Response
La regione è corretta (bloccata al momento della registrazione)
L'account amministratore delegato è corretto (si consiglia l'account Security Tooling)
L'ambito dell'account comprende le unità organizzative previste
AWSServiceRoleForSecurityIncidentResponse_Triageesiste nell'account di gestioneAWSServiceRoleForSecurityIncidentResponse_Triageesiste negli account dei membri inclusi nell'ambitoAWSServiceRoleForSecurityIncidentResponseesiste nell'account amministratore delegatoThird-party le integrazioni (se applicabile) vengono visualizzate come accettanti in Security Hub CSPM
EventBridge le regole inserite
SIRnel nome sono presenti e abilitate negli account dei membriI membri del team di risposta agli incidenti sono configurati con le informazioni di contatto corrette e le comunicazioni sono abilitate
Creazione del test case e notifiche e-mail ricevute da tutti i membri del team
La ricerca del dominio di test (
guarddutyc2activityb.com) è stata archiviata entro 15 minutiContenimento StackSet implementato correttamente (se il contenimento è abilitato)
Preferenza di contenimento inviata (se il contenimento è abilitato)
EventBridge le integrazioni (se configurate) stanno inviando eventi a piattaforme di terze parti
Risultati archiviati visibili GuardDuty dopo la prima settimana di funzionamento
Verifica della fatturazione
Clienti Enterprise Support e Unified Operations: il Security Incident Response è incluso senza costi aggiuntivi come parte del piano di supporto. I costi di Security Incident Response non sono visualizzati in AWS Cost Explorer o nel Rapporto AWS sui costi e l'utilizzo.
Tutti gli altri clienti: i prezzi si basano sul numero di rilevazioni di sicurezza acquisite. I primi 10.000 risultati al mese sono gratuiti. Per informazioni dettagliate, consulta Prezzi di AWS Security Incident Response
Risoluzione dei problemi
| Caratteristiche | Causa probabile | Risoluzione |
|---|---|---|
| Lo stato dell'iscrizione è In sospeso | L'onboarding non è stato completato | Completa tutti i passaggi di configurazione. Vedi Guida introduttiva. |
list-membershipsrestituisce vuoto |
La regione CLI non corrisponde alla regione dell'abbonamento | Specifica la regione in cui hai effettuato l'attivazione: --region |
| Triage SLR non trovato nell'account di gestione | Effettuato l'onboarding senza crearlo API/CLI | Crea manualmente: aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" |
| Account per i membri mancanti dalla copertura | SLR non utilizzato sull'account del membro | Re-run configurazione della risposta proattiva dalla console Security Incident Response |
| EventBridge regole non presenti in un account | Configurazione della risposta proattiva incompleta | Re-run configurazione o verifica la presenza di StackSet errori in CloudFormation |
| GuardDuty risultati del campione non elaborati | I risultati dei campioni vengono filtrati mediante triage automatico (previsto) | Controlla i risultati archiviati in GuardDuty |
| I risultati del dominio di test non vengono archiviati dopo 15 minuti | EventBridge regole mancanti o disattivate; GuardDuty non abilitate | Verifica i passaggi 2 e 3 |
| Nessun caso dopo un periodo prolungato | Tutti i risultati sono stati archiviati tramite triage (previsto) o pipeline non connessa | Controlla i risultati archiviati in. GuardDuty Se non ne esistono, verifica EventBridge le regole e la risposta proattiva. |
| Nessun GuardDuty risultato in fase di valutazione | GuardDuty non abilitato o non genera risultati | GuardDuty La verifica è abilitata: aws guardduty list-detectors |
| Il servizio non elabora i risultati | Il triage automatico ha stabilito che l'attività rilevata è prevista | Esamina i risultati GuardDuty archiviati e i risultati del Security Hub CSPM SUPPRESSED |
| I membri del team non ricevono notifiche | Email errata, comunicazioni disattivate o email nella posta indesiderata | Verifica gli indirizzi email e le preferenze di comunicazione; controlla le cartelle spam |
| Azioni di contenimento non eseguite | StackSet non implementata o preferenza non inviata | Verifica StackSet lo stato CloudFormation e conferma la preferenza inviata tramite Supporto AWS |
Risorse correlate
