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à.
# Analisi
I log, le funzionalità di interrogazione e l'intelligence sulle minacce sono alcuni dei componenti di supporto richiesti dalla fase di analisi. Molti degli stessi log utilizzati per il rilevamento vengono utilizzati anche per l'analisi e richiederanno l'onboarding e la configurazione degli strumenti di interrogazione.
# Convalida, analizza e valuta l'impatto degli avvisi
Durante la fase di analisi, viene eseguita un'analisi completa dei registri con l'obiettivo di convalidare gli avvisi, definire l'ambito e valutare l'impatto della possibile compromissione.
+ La *convalida* dell'avviso è il punto di partenza della fase di analisi. I soccorritori cercheranno le voci di registro da varie fonti e interagiranno direttamente con i proprietari del carico di lavoro interessato.
+ La fase successiva consiste nell'*inventariare* tutte le risorse coinvolte e modificare la criticità degli avvisi dopo che le parti interessate concordano sul fatto che è improbabile che si tratti di un falso positivo.
+ Infine, l'*analisi dell'impatto descrive in dettaglio l'effettiva interruzione dell'attività*.
Una volta identificati i componenti del carico di lavoro interessati, è possibile correlare i risultati dell'analisi con l'obiettivo del punto di ripristino (RPO) e l'obiettivo del tempo di ripristino (RTO) del carico di lavoro correlato, adattandoli alla criticità degli avvisi, che avvieranno l'allocazione delle risorse e tutte le attività successive. Non tutti gli incidenti interromperanno direttamente le operazioni di un carico di lavoro che supporta un processo aziendale. Incidenti come la divulgazione di dati sensibili, il furto di proprietà intellettuale o il furto di risorse (come nel caso del mining di criptovalute) potrebbero non interrompere o indebolire immediatamente un processo aziendale, ma possono avere conseguenze in un secondo momento.
# Arricchisci i registri e i risultati di sicurezza
## Arricchimento con informazioni sulle minacce e contesto organizzativo
Nel corso dell'analisi, gli osservabili di interesse richiedono un arricchimento per una migliore contestualizzazione dell'avviso. Come indicato nella sezione Preparazione, l'integrazione e lo sfruttamento dell'intelligence sulle minacce informatiche possono essere utili per comprendere meglio una scoperta di sicurezza. I servizi di intelligence sulle minacce vengono utilizzati per assegnare la reputazione e attribuire la proprietà a indirizzi IP pubblici, nomi di dominio e hash di file. Questi strumenti sono disponibili come servizi a pagamento e gratuiti.
I clienti che adottano Amazon Athena come strumento di interrogazione dei log ottengono il vantaggio dei job AWS Glue per caricare le informazioni di intelligence sulle minacce sotto forma di tabelle. Le tabelle di threat intelligence possono essere utilizzate nelle query SQL per correlare elementi di log come indirizzi IP e nomi di dominio, fornendo una visione più completa dei dati da analizzare.
AWS non fornisce informazioni sulle minacce direttamente ai clienti, ma servizi come Amazon GuardDuty utilizzano l'intelligence sulle minacce per l'arricchimento e la generazione di risultati. Puoi anche caricare elenchi di minacce personalizzati in GuardDuty base alla tua intelligence sulle minacce.
## Arricchimento con l'automazione
L'automazione è parte integrante della Cloud AWS governance. Può essere utilizzata durante le varie fasi del ciclo di vita della risposta agli incidenti.
Per la fase di rilevamento, l'automazione basata su regole inserisce nei log i modelli di interesse del modello di minaccia e intraprende le azioni appropriate, come l'invio di notifiche. La fase di analisi può sfruttare il meccanismo di rilevamento e inoltrare il corpo di allerta a un motore in grado di interrogare i log e arricchire gli osservabili per la contestualizzazione dell'evento.
**Il corpo di allerta, nella sua forma fondamentale, è composto da una risorsa e da un'identità.** Ad esempio, è possibile implementare un'automazione CloudTrail per interrogare l'attività dell' AWS API eseguita dall'identità o dalla risorsa dell'organismo di allerta nel momento dell'avviso, fornendo informazioni aggiuntive tra cui `eventSource` `eventName``SourceIPAddress`, e sull'attività `userAgent` dell'API identificata. Eseguendo queste interrogazioni in modo automatizzato, gli addetti alla risposta possono risparmiare tempo durante il triage e ottenere un contesto aggiuntivo per aiutare a prendere decisioni più informate.
Per un esempio [su come utilizzare l'automazione per arricchire i risultati di AWS Security Hub con i metadati degli account](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/), consulta il post del blog How to enrich Security Hub with Account Metadata.
# Raccogli e analizza prove forensi
La scienza forense, come menzionato nella [Preparazione](preparation.md) sezione di questo documento, è il processo di raccolta e analisi degli artefatti durante la risposta agli incidenti. Attivo AWS, è applicabile alle risorse del dominio dell'infrastruttura come l'acquisizione di pacchetti del traffico di rete, il dump della memoria del sistema operativo e alle risorse del dominio di servizio come i log. AWS CloudTrail
Il processo di analisi forense presenta le seguenti caratteristiche fondamentali:
+ **Coerente**: segue i passaggi esatti documentati, senza deviazioni.
+ **Ripetibile**: produce esattamente gli stessi risultati se ripetuto sullo stesso artefatto.
+ **Conveniente**: è documentato pubblicamente e ampiamente adottato.
È importante mantenere una catena di custodia per gli artefatti raccolti durante la risposta agli incidenti. L'utilizzo dell'automazione e la generazione automatica della documentazione di questa raccolta possono essere utili, oltre a memorizzare gli artefatti in archivi di sola lettura. L'analisi deve essere eseguita solo su repliche esatte degli artefatti raccolti per mantenerne l'integrità.
# Raccogli gli artefatti pertinenti
Tenendo presenti queste caratteristiche e sulla base degli avvisi pertinenti e della valutazione dell'impatto e della portata, sarà necessario raccogliere i dati che saranno pertinenti per ulteriori indagini e analisi. Vari tipi e fonti di dati che potrebbero essere rilevanti per l'indagine, tra cui log service/control piani (CloudTraileventi di dati Amazon S3, log di flusso VPC), dati (metadati e oggetti Amazon S3) e risorse (database, istanze Amazon EC2).
Service/control I log dei piani possono essere raccolti per l'analisi locale o, idealmente, interrogati direttamente utilizzando servizi nativi (ove applicabile). AWS I dati (inclusi i metadati) possono essere interrogati direttamente per ottenere informazioni pertinenti o per acquisire gli oggetti di origine; ad esempio, puoi utilizzare il bucket Amazon S3 e i AWS CLI metadati degli oggetti e acquisire direttamente gli oggetti di origine. Le risorse devono essere raccolte in modo coerente con il tipo di risorsa e il metodo di analisi previsto. Ad esempio, i database possono essere raccolti creando un copy/snapshot sistema che esegue il database, creando uno copy/snapshot dell'intero database stesso o interrogando ed estraendo determinati dati e registri dal database pertinenti all'indagine.
Per le istanze Amazon EC2, è necessario raccogliere un set specifico di dati e eseguire un ordine di raccolta specifico per acquisire e conservare la maggior quantità di dati per analisi e indagini.
In particolare, l'ordine di risposta per acquisire e conservare la maggior quantità di dati da un'istanza Amazon EC2 è il seguente:
1. **Acquisizione di metadati** dell'istanza: acquisisci i metadati dell'istanza pertinenti all'indagine e alle richieste di dati (ID istanza, tipo, indirizzo IP, VPC/subnet ID, regione, ID Amazon Machine Image (AMI), gruppi di sicurezza collegati, ora di avvio).
1. **Abilita le protezioni e i tag** delle istanze: abilita le protezioni delle istanze come la protezione dalla terminazione, imposta il comportamento di arresto (se impostato su termina), disabilita gli attributi Delete on Termination per i volumi EBS collegati e applica i tag appropriati sia per la denotazione visiva che per l'uso in possibili automazioni di risposta (ad esempio, dopo aver applicato un tag con nome `Status` e valore di`Quarantine`, esegui l'acquisizione forense dei dati e isola l'istanza).
1. **Acquisisci disco (istantanee EBS)**: acquisisci un'istantanea EBS dei volumi EBS collegati. Ogni istantanea contiene le informazioni necessarie per ripristinare i dati (dal momento in cui è stata scattata l'istantanea) su un nuovo volume EBS. Consulta la procedura per eseguire la response/artifact raccolta in tempo reale se utilizzi volumi di Instance Store.
1. **Acquisizione di memoria**: poiché gli snapshot EBS acquisiscono solo dati che sono stati scritti sul volume Amazon EBS, il che potrebbe escludere i dati archiviati o memorizzati nella cache dalle applicazioni o dal sistema operativo, è imperativo acquisire un'immagine di memoria di sistema utilizzando uno strumento open source o commerciale di terze parti appropriato per acquisire i dati disponibili dal sistema.
1. **(Facoltativo) Esegui la risposta in tempo reale/la raccolta di artefatti**: esegui la raccolta mirata dei dati (disk/memory/logs) tramite risposta in tempo reale sul sistema solo se il disco o la memoria non possono essere acquisiti in altro modo o se esiste un motivo aziendale o operativo valido. In questo modo si modificheranno dati e artefatti importanti del sistema.
1. **Disattivazione dell'istanza: scollega l'istanza** dai gruppi di Auto Scaling, annulla la registrazione dell'istanza dai sistemi di bilanciamento del carico e modifica o applica un profilo di istanza predefinito con autorizzazioni ridotte al minimo o assenti.
1. **Isola o contiene l'istanza**: verifica che l'istanza sia effettivamente isolata da altri sistemi e risorse all'interno dell'ambiente terminando e impedendo le connessioni attuali e future da e verso l'istanza. Per ulteriori dettagli, consulta la [Contenimento](containment.md) sezione di questo documento.
1. **Scelta del risponditore**: in base alla situazione e agli obiettivi, seleziona una delle seguenti opzioni:
+ Disattivate e spegnete il sistema (scelta consigliata).
Spegnere il sistema una volta acquisite le prove disponibili per verificare la mitigazione più efficace rispetto a possibili impatti futuri sull'ambiente da parte dell'istanza.
+ Continua a eseguire l'istanza all'interno di un ambiente isolato dotato di strumentazione per il monitoraggio.
Sebbene non sia consigliato come approccio standard, se una situazione richiede un'osservazione continua dell'istanza (ad esempio quando sono necessari dati o indicatori aggiuntivi per eseguire indagini e analisi complete dell'istanza), potresti prendere in considerazione la chiusura dell'istanza, la creazione di un'AMI dell'istanza e il riavvio dell'istanza nel tuo account forense dedicato all'interno di un ambiente sandbox preattrezzato per essere completamente isolato e configurato con strumentazione per facilitare la quasi continuità monitoraggio dell'istanza (per ad esempio, VPC Flow Logs o VPC Traffic Mirroring).
**Nota**
È essenziale acquisire la memoria prima delle attività di risposta in tempo reale o dell'isolamento o dello spegnimento del sistema per acquisire i dati volatili (e preziosi) disponibili.
# Sviluppa narrazioni
Durante l'analisi e le indagini, documenta le azioni intraprese, le analisi eseguite e le informazioni identificate, da utilizzare nelle fasi successive e, infine, in un rapporto finale. Questi resoconti devono essere concisi e precisi e confermare l'inclusione di informazioni pertinenti per verificare l'effettiva comprensione dell'incidente e mantenere una tempistica accurata. Sono utili anche quando si coinvolgono persone esterne al team principale di risposta agli incidenti. Ecco un esempio:
****
*Il reparto marketing e vendite ha ricevuto una richiesta di riscatto il 15 marzo 2022 che richiedeva il pagamento in criptovaluta per evitare la pubblicazione pubblica di possibili dati sensibili. Il SOC ha stabilito che il database Amazon RDS appartenente al marketing e alle vendite era accessibile al pubblico il 20 febbraio 2022. *Il SOC ha interrogato i log di accesso RDS e ha stabilito che l'indirizzo IP 198.51.100.23 è stato utilizzato il 20 febbraio 2022 con le credenziali appartenenti a Major Mary, uno degli sviluppatori web. `mm03434`* Il SOC ha interrogato i log di flusso VPC e ha stabilito che circa 256 MB di dati sono stati trasmessi allo stesso indirizzo IP nella stessa data (timestamp 2022-02-20T 15:50 \$100Z). Il SOC ha stabilito tramite l'intelligence open source sulle minacce che le credenziali sono attualmente disponibili in testo semplice nell'archivio pubblico. `https[:]//example[.]com/majormary/rds-utils`*