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 verificare 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 la CLI che la AWS Management Console CLI. AWS
Argomenti
Prima della convalida
Prerequisiti per la convalida della configurazione 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)
Regione AWS Dove hai attivato l'abbonamento
Il tuo ID di iscrizione (se convalidi utilizzando il AWS CLI)
Conferma la disponibilità del registro
AWS Security Incident Response non abilita le sorgenti di registro per tuo conto. Durante un'indagine, gli ingegneri si affidano ai registri già presenti nell'ambiente in uso. 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 ai 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 esegui la 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
Fase 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 viene selezionata a livello di unità organizzativa (OU), non a livello di account individuale. Tutti gli account all'interno di un'unità organizzativa selezionata (incluse le unità organizzative secondarie) sono coperti.
Verifica che la regione elencata corrisponda a quella in cui vengono eseguiti i tuoi 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 comando seguente:
aws security-ir get-membership --membership-idmembership-id
Utilizza 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 sia 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: utilizzare lo stesso account di amministratore delegato impostato per altri servizi AWS di sicurezza (come AWS Security Hub CSPM and GuardDuty). La AWS Security Reference Architecture consiglia di utilizzare l'account Security Tooling.
Fase 2: Verificare le fonti di rilevamento e il triage
AWS Security Incident Response monitora i risultati di sicurezza provenienti da GuardDuty strumenti di terze parti tramite Security Hub CSPM. Il servizio utilizza un ruolo collegato al servizio per acquisire i risultati tramite EventBridge le regole di Amazon distribuite ai tuoi account durante l'onboarding.
Verifica il ruolo collegato al servizio Triage
Il ruolo AWSServiceRoleForSecurityIncidentResponse_Triage collegato al servizio deve esistere nel tuo account di gestione e in tutti gli account dei membri interessati.
Per verificare, esegui il comando seguente negli account di gestione e dei membri interessati:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage
Una risposta corretta 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 avrebbe dovuto essere creato automaticamente. Contatto. Supporto AWS
Se hai effettuato l'onboarding utilizzando l'API o AWS CLI: consulta Enable Security Incident Response utilizzando il API/CLI per istruzioni sulla creazione manuale del ruolo.
Verifica il ruolo principale collegato al servizio
Il AWSServiceRoleForSecurityIncidentResponse ruolo dovrebbe esistere anche nel tuo account di amministratore delegato. Per verificare l'esistenza del ruolo, 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, verifica che la risposta proattiva sia attivata. Se abilitato, il servizio esegue le seguenti operazioni:
Acquisisce i risultati dal GuardDuty CSPM di Security Hub tramite regole EventBridge
Valuta automaticamente i risultati utilizzando il contesto specifico del cliente (IP noti, entità IAM previste)
Crea casi di indagine proattivi quando vengono identificati problemi di sicurezza confermati
Archivia GuardDuty i risultati ritenuti innocui (visualizzabili nella GuardDuty console alla voce 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 seguenti passaggi.
Apri la EventBridge console Amazon in un account membro coperto.
Seleziona Rules (Regole).
Verifica che le regole indicate
SecurityIncidentResponsenel 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 risultati vengano trasmessi tramite Security Hub CSPM:
Apri la AWS Security Hub CSPM console
. Vai a Integrazioni.
Conferma che l'integrazione con un fornitore di terze parti riporti la dicitura 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.
Fase 3: Verifica la pipeline di ricerca automatizzata
Questo passaggio conferma che la EventBridge pipeline è attiva e che i risultati sono in fase di triage automatico.
Informazioni sui risultati di esempio GuardDuty
GuardDutyLa funzione integrata Genera risultati di esempio produce risultati contrassegnati come campioni. Il triage automatico filtra i risultati dei campioni per prevenire il rumore; non rientrano nell'intera pipeline di triage e non possono essere utilizzati per convalidare la configurazione di Security Incident Response. Non utilizzarli per questa fase.
Convalida con il dominio di GuardDuty test
La GuardDuty documentazione fornisce un dominio di test (guarddutyc2activityb.com) che genera un risultato reale senza richiedere eventi di sicurezza reali. L'interrogazione di questo dominio da un'istanza Amazon EC2 in un account coperto produce un risultato che Security Incident Response acquisisce ed elabora.
Per generare un risultato di test:
Connect 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 automatizzato elabora la scoperta e determina che non è indicativa di un vero evento di sicurezza.
Il risultato è archiviato in. GuardDuty Per visualizzarlo, seleziona Archiviato dal filtro Stato.
Se utilizzi Security Hub CSPM, lo stato del flusso di lavoro del risultato 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 giustifica l'indagine umana.
Nota
Se il risultato del test non compare nell'elenco GuardDuty archiviato entro 15 minuti, consulta. Risoluzione dei problemi Se non è disponibile alcuna istanza Amazon EC2, procedi allo Step 4 e torna a questo test quando l'ambiente è pronto.
Fase 4: Verifica delle notifiche e del 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.
In alternativa, esegui il comando seguente per verificare utilizzando AWS CLI:
aws security-ir get-membership --membership-idmembership-id
Confermate che:
Sono elencate tutte le parti interessate
Gli indirizzi e-mail sono corretti
Le preferenze di comunicazione di ogni 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 chi osserva i casi
Gli osservatori del caso sono parti interessate a cui è concesso l'accesso per visualizzare un caso specifico. Dettagli chiave:
Gli osservatori sono suddivisi per caso, non per account. L'aggiunta di un osservatore a un caso non garantisce loro l'accesso a nessun altro caso. Devi aggiungere esplicitamente gli 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 predefinita che concede l'accesso solo a quel caso specifico, mantenendo l'accesso con privilegi minimi.
Questa classificazione per caso è particolarmente importante quando si concede l'accesso a parti esterne, come i partner di Managed Detection and Response (MDR) o i team investigativi di terze parti, che devono visualizzare 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 consiste nel 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: «Si tratta di un test di convalida della configurazione, non esiste un evento di sicurezza reale».
Verifica che tutti i membri del team di risposta agli incidenti configurato ricevano la notifica via e-mail.
Chiudi il caso dopo aver confermato la ricezione delle notifiche.
Importante
La creazione di un test case può generare una risposta da parte dei tecnici del Security Incident Response se richiedi un intervento AWS supportato. Contrassegna chiaramente il tuo caso come test per evitare inutili escalation. Usa questo passaggio una volta per confermare che il canale funziona, 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 EventBridge il routing degli eventi dei case su piattaforme di terze parti (come ServiceNow Jira, Slack o PagerDuty), verifica che il test case attivi la notifica prevista in tali 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 il Security Incident Response per monitorare l'ambiente, analizzare 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 automatizzate 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 i runbook per:
Bucket Amazon S3 interessati
Istanze Amazon EC2 interessate
Principali IAM interessati
Verifica che CloudFormation StackSet sia distribuito. Il contenimento richiede ruoli IAM (AWSSecurityIncidentResponseContainmenteAWSSecurityIncidentResponseContainmentExecution) negli account coperti:
Apri AWS CloudFormation nel tuo account di gestione.
Scegli StackSets.
Verifica che il contenuto del Security Incident Response sia StackSet visibile
SUCCEEDEDin tutti gli account di destinazione.
Se StackSet non viene distribuito, l'autorizzazione di contenimento nella console non comporta l'adozione di azioni di contenimento effettive.
Conferma le tue preferenze di contenimento. Security Incident Response supporta tre livelli di contenimento:
Approvazione richiesta (impostazione predefinita): nessuna azione di contenimento senza l'autorizzazione esplicita caso per caso.
Contenuto confermato: contenimento proattivo delle risorse confermate come interessate.
Contenitore sospetto: contenimento proattivo delle risorse con elevata probabilità di essere colpite.
Per inviare o aggiornare le tue preferenze, crea un Supporto AWS caso con il tipo di caso Tecnico: Security Incident Response Service/Altro.
Se desideri il modello EC2 Triage: Deploy the Containment with EC2 Triage. CloudFormation Ciò consente ai tecnici 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, utilizzate questi indicatori per confermare che Security Incident Response funziona continuamente come previsto.
L'assenza di casi è normale
Security Incident Response crea un caso proattivo solo quando il triage automatico identifica attività che giustificano l'indagine umana. Quando il triage determina che una scoperta è innocua, la 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 vengono rilevati casi né risultati archiviati dopo che l'ambiente è attivo da diversi giorni, è possibile che la pipeline non sia 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 sanitari
Poiché Security Incident Response elabora i risultati nel tempo, crea due elementi osservabili:
Risultati archiviati: risultati che il triage automatizzato ha ritenuto benigni. Questi si accumulano nel tempo e sono visibili nella GuardDuty console sotto Findings, quindi seleziona Archiviato.
GuardDuty regole di soppressione: per trovare i tipi confermati come attività prevista nell'ambiente, Security Incident Response implementa regole di soppressione denominate (con il prefisso).
SIRTriage-Questi sono il segnale continuo più chiaro che il triage automatizzato sta funzionando attivamente. Visualizzali nella GuardDuty console in base alle regole di soppressione.
Il team di risposta agli incidenti riceve una notifica quando viene creata una regola di soppressione. Se una regola è stata creata per errore, contatta 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 sulle attività al team di risposta agli incidenti che riassume i risultati elaborati, la valutazione dei risultati e tutti i casi aperti. Se il team non ha ricevuto un rapporto 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 una richiesta di supporto con tipo di caso: Tecnico: Security Incident Response Service /Altro e includi le seguenti informazioni:
Il 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 dell'account coperti dall'iscrizione a Security Incident Response
Cosa aspettarsi dai tecnici del Security Incident Response
Quando crei 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 riconoscimento 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 corso 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 all'apertura del caso.
Lista di controllo per la convalida
Utilizza questa lista di controllo per confermare che la configurazione è completa:
Fonti di log abilitate: eventi di CloudTrail gestione (richiesto), Amazon VPC Flow Logs, registrazione degli accessi 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 (è consigliato l'account Security Tooling)
L'ambito dell'account include le unità organizzative previste
AWSServiceRoleForSecurityIncidentResponse_Triageesiste nell'account di gestioneAWSServiceRoleForSecurityIncidentResponse_Triageesiste negli account dei membri pertinentiAWSServiceRoleForSecurityIncidentResponseesiste in un account amministratore delegatoThird-party le integrazioni (se applicabili) vengono mostrate come risultati di accettazione in Security Hub CSPM
EventBridge le regole contenute
SecurityIncidentResponsenel 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 abilitate
Test case creato e notifiche e-mail ricevute da tutti i membri del team
Test domain finding (
guarddutyc2activityb.com) archiviato entro 15 minutiContenimento StackSet implementato con successo (se il contenimento è abilitato)
Preferenza di contenimento inviata (se il contenimento è abilitato)
EventBridge le integrazioni (se configurate) forniscono eventi a piattaforme di terze parti
I risultati archiviati sono visibili GuardDuty dopo la prima settimana di attività
Verifica della fatturazione
Clienti Enterprise Support e Unified Operations: Security Incident Response è incluso senza costi aggiuntivi come parte del piano di supporto. I costi di Security Incident Response non vengono visualizzati in AWS Cost Explorer o nel AWS Cost and Usage Report.
Tutti gli altri clienti: i prezzi si basano sul numero di risultati di sicurezza acquisiti. 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 di iscrizione è In sospeso | L'onboarding non è stato completato | Completa tutti i passaggi di configurazione. Vedi Guida introduttiva. |
list-membershipsrestituisce vuote |
La regione CLI non corrisponde alla regione di abbonamento | Specificate la regione in cui avete effettuato l'attivazione: --region |
| Triage SLR non è stato trovato nell'account di gestione | Inserito tramite senza crearlo API/CLI | Crea manualmente: aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" |
| Account membri mancanti dalla copertura | La reflex non è stata distribuita sull'account del membro | Re-run configurazione proattiva della risposta 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 campionari non elaborati | I risultati del campione vengono filtrati mediante un triage automatico (previsto) | Controlla i risultati archiviati in GuardDuty |
| I risultati del dominio di prova non sono stati archiviati dopo 15 minuti | EventBridge regole mancanti o disabilitate; 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 connesse | 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 determinato che l'attività rilevata è prevista | Esamina i risultati GuardDuty archiviati e i risultati SUPPRESSED CSPM di Security Hub |
| I membri del team non ricevono notifiche | Email errata, comunicazioni disattivate o posta indesiderata | Verifica gli indirizzi e-mail e le preferenze di comunicazione; controlla le cartelle spam |
| Le azioni di contenimento non sono in esecuzione | StackSet non distribuito o preferenza non inviata | Verifica StackSet lo stato CloudFormation e conferma la preferenza inviata tramite Supporto AWS |
Risorse correlate
