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à.
# Operazioni
Le operazioni sono il fulcro dell'esecuzione della risposta agli incidenti. È qui che avvengono le azioni di risposta e riparazione degli incidenti di sicurezza. Le operazioni comprendono le seguenti cinque fasi: *rilevamento*, *analisi*, *contenimento*, *rimozione * e *ripristino*. Le descrizioni di queste fasi e degli obiettivi sono disponibili nella Tabella 3.
*Tabella 3 — Fasi operative*
| Fase | Obiettivo |
| --- | --- |
| Rilevamento | Identifica un potenziale evento di sicurezza. |
| Analisi | Determina se un evento di sicurezza è un incidente e valuta la portata dell'incidente. |
| Contenimento | Riduci al minimo e limita l'ambito dell'evento di sicurezza. |
| Eradicazione | Rimuovi risorse o artefatti non autorizzati correlati all'evento di sicurezza. Implementa le mitigazioni che hanno causato l'incidente di sicurezza. |
| Recupero | Ripristina i sistemi a uno stato di sicurezza noto e monitora questi sistemi per verificare che la minaccia non si ripresenti. |
Queste fasi dovrebbero servire da guida quando si risponde e si opera sugli incidenti di sicurezza per garantire una risposta efficace e forte. Le azioni effettive che intraprenderai variano a seconda dell'incidente. Un incidente relativo a un ransomware, ad esempio, presenta una serie di passaggi di risposta diversi da quelli di un incidente che coinvolge un bucket Amazon S3 pubblico. Inoltre, questi passaggi non devono essere seguiti necessariamente in sequenza. Dopo il contenimento e la rimozione, potrebbe essere necessario tornare all'analisi per capire se le azioni intraprese sono state efficaci.
# Rilevamento
Un avviso è il componente principale della fase di rilevamento. Genera una notifica per avviare il processo di risposta agli incidenti in base all'attività di minaccia dell' AWS account di interesse.
La precisione degli avvisi è difficile; non è sempre possibile determinare con assoluta certezza se un incidente si è verificato, è in corso o se si verificherà in futuro. Ecco alcuni motivi:
+ I meccanismi di rilevamento si basano sulla deviazione di base, sugli schemi noti e sulla notifica da parte di entità interne o esterne.
+ A causa della natura imprevedibile della tecnologia e delle persone, rispettivamente dei *mezzi e degli* *attori degli incidenti di sicurezza, i valori di base cambiano nel* tempo. **I modelli anomali emergono attraverso *tattiche*, tecniche e procedure nuove o modificate per gli attori delle minacce ().** TTPs
+ Le modifiche alle persone, alla tecnologia e ai processi non vengono incorporate immediatamente nel processo di risposta agli incidenti. Alcune vengono scoperte durante lo svolgimento di un'indagine.
# Sorgenti di avviso
È consigliabile prendere in considerazione l'utilizzo delle seguenti fonti per definire gli avvisi:
+ **Risultati**: AWS servizi come [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 [AWS Config](https://aws.amazon.com/config/)](https://aws.amazon.com/inspector/)[, IAM Access Analyzer [e Network](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html) Access](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) Analyzer generano risultati che possono essere utilizzati per creare avvisi.
+ Registri: **i log** di AWS servizi, infrastrutture e applicazioni archiviati nei bucket e nei gruppi di log di Amazon S3 possono essere analizzati CloudWatch e correlati per generare avvisi.
+ Attività di **fatturazione: un cambiamento improvviso nell'attività di fatturazione può** indicare un evento di sicurezza. Consulta la documentazione sulla [creazione di un allarme di fatturazione per monitorare gli AWS addebiti stimati. A tal fine, è necessario tenere](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html) sotto controllo questa situazione.
+ **Intelligence sulle minacce informatiche**: se ti abboni a un feed di intelligence sulle minacce informatiche di terze parti, puoi correlare tali informazioni con altri strumenti di registrazione e monitoraggio per identificare potenziali indicatori di eventi.
+ **Strumenti per i partner**: i partner di AWS Partner Network (APN) offrono prodotti di alto livello che possono aiutarti a raggiungere i tuoi obiettivi di sicurezza. Per quanto riguarda la risposta agli incidenti, i prodotti dei partner con endpoint detection and response (EDR) o SIEM possono aiutarti a raggiungere gli obiettivi di risposta agli incidenti. Per ulteriori informazioni, vedere [Security Partner Solutions](https://aws.amazon.com/security/partner-solutions/) e [Security Solutions](https://aws.amazon.com/marketplace/solutions/security) nel. Marketplace AWS
+ **AWS fiducia e sicurezza**: Supporto potremmo contattare i clienti se identifichiamo attività abusive o dannose.
+ **Contatto una tantum**: poiché possono essere clienti, sviluppatori o altro personale dell'organizzazione a notare qualcosa di insolito, è importante disporre di un metodo noto e ben pubblicizzato per contattare il team di sicurezza. Le scelte più comuni includono sistemi di biglietteria, indirizzi e-mail di contatto e moduli web. Se la tua organizzazione lavora con il pubblico in generale, potresti aver bisogno anche di un meccanismo di contatto di sicurezza rivolto al pubblico.
Per ulteriori informazioni sulle funzionalità cloud che puoi utilizzare durante le tue indagini, consulta questo documento[Appendice A: Definizioni delle funzionalità cloud](appendix-a-cloud-capability-definitions.md).
# Il rilevamento come parte dell'ingegneria del controllo della sicurezza
I meccanismi di rilevamento sono parte integrante dello sviluppo del controllo della sicurezza. Una volta definiti i controlli *direttivi* e *preventivi**, è necessario costruire i relativi controlli *investigativi* e reattivi*. Ad esempio, un'organizzazione stabilisce un controllo direttivo relativo all'utente root di un AWS account, che dovrebbe essere utilizzato solo per attività specifiche e ben definite. Lo associano a un controllo preventivo implementato utilizzando la politica di controllo dei servizi (SCP) di un' AWS organizzazione. Se si verifica un'attività dell'utente root oltre la linea di base prevista, un controllo investigativo implementato con una EventBridge regola e un argomento SNS avviserà il Security Operations Center (SOC). Il controllo reattivo prevede che il SOC selezioni il playbook appropriato, esegua l'analisi e lavori fino alla risoluzione dell'incidente.
Il modo migliore per definire i controlli di sicurezza è la modellazione delle minacce dei carichi di lavoro in esecuzione. AWS La criticità dei controlli investigativi verrà stabilita esaminando l'analisi dell'impatto aziendale (BIA) per il particolare carico di lavoro. Gli avvisi generati dai controlli investigativi non vengono gestiti man mano che arrivano, ma piuttosto in base alla loro criticità iniziale, per essere corretti durante l'analisi. Il set di criticità iniziale aiuta a stabilire le priorità; il contesto in cui si è verificato l'avviso determinerà la sua vera criticità. Ad esempio, un'organizzazione utilizza Amazon GuardDuty come componente del controllo investigativo utilizzato per le istanze EC2 che fanno parte di un carico di lavoro. Il risultato `Impact:EC2/SuspiciousDomainRequest.Reputation` viene generato e ti informa che l'istanza Amazon EC2 elencata all'interno del tuo carico di lavoro sta interrogando un nome di dominio sospettato di essere dannoso. Questo avviso è impostato di default su un livello di gravità basso e, man mano che la fase di analisi procede, è stato stabilito che diverse centinaia di istanze EC2 di questo tipo sono `p4d.24xlarge` state implementate da un attore non autorizzato, con un aumento significativo dei costi operativi dell'organizzazione. A questo punto, il team addetto alla risposta agli incidenti decide di aumentare la criticità di questo avviso, aumentando il senso di *urgenza* e accelerando ulteriori azioni. Tieni presente che la gravità del GuardDuty rilevamento non può essere modificata.
# Implementazioni del controllo investigativo
È importante capire come vengono implementati i controlli investigativi perché aiutano a determinare come verrà utilizzato l'avviso per un particolare evento. Esistono due implementazioni principali dei controlli investigativi tecnici:
+ Il **rilevamento comportamentale** si basa su modelli matematici comunemente denominati apprendimento automatico (ML) o intelligenza artificiale (AI). Il rilevamento viene effettuato per inferenza; pertanto, l'avviso potrebbe non riflettere necessariamente un evento reale.
+ Il **rilevamento basato su regole** è deterministico; i clienti possono impostare i parametri esatti dell'attività su cui ricevere avvisi, e questo è certo.
Le moderne implementazioni di sistemi di rilevamento, come un sistema di rilevamento delle intrusioni (IDS), sono generalmente dotate di entrambi i meccanismi. Di seguito sono riportati alcuni esempi di rilevamenti comportamentali e basati su regole con. GuardDuty
+ Quando il risultato `Exfiltration:IAMUser/AnomalousBehavior` viene generato, ti informa che «è stata rilevata una richiesta API anomala nel tuo account». Se approfondisci la documentazione, ti viene detto che «Il modello ML valuta tutte le richieste API nel tuo account e identifica gli eventi anomali associati alle tecniche utilizzate dagli avversari», indicando che questo risultato è di natura comportamentale.
+ Per la scoperta`Impact:S3/MaliciousIPCaller`, GuardDuty sta analizzando le chiamate API dal servizio CloudTrail Amazon S3, confrontando `SourceIPAddress` l'elemento di registro con una tabella di indirizzi IP pubblici che include feed di intelligence sulle minacce. Una volta trovata una corrispondenza diretta con una voce, genera il risultato.
Consigliamo di implementare una combinazione di avvisi comportamentali e basati su regole, poiché non è sempre possibile implementare avvisi basati su regole per ogni attività all'interno del modello di minaccia.
# Rilevamento basato sulle persone
Fino a questo punto, abbiamo discusso del rilevamento basato sulla tecnologia. L'altra importante fonte di rilevamento proviene da persone interne o esterne all'organizzazione del cliente. *Gli addetti ai lavori* possono essere definiti come dipendenti o collaboratori, mentre *gli estranei* sono entità come i ricercatori in materia di sicurezza, le forze dell'ordine, i notiziari e i social media.
Sebbene il rilevamento basato sulla tecnologia possa essere configurato sistematicamente, il rilevamento basato sulle persone si presenta in una varietà di forme come e-mail, biglietti, posta, post di notizie, telefonate e interazioni di persona. Ci si può aspettare che le notifiche di rilevamento basate sulla tecnologia vengano fornite quasi in tempo reale, ma non ci sono aspettative di tempistiche per il rilevamento basato sulle persone. È fondamentale che la cultura della sicurezza incorpori, faciliti e potenzi i meccanismi di rilevamento basati sulle persone per un approccio di difesa approfondito alla sicurezza.
# Riepilogo
Per quanto riguarda il rilevamento, è importante disporre di un mix di avvisi basati su regole e basati sul comportamento. Inoltre, è necessario disporre di meccanismi che consentano alle persone, interne ed esterne, di inviare un ticket relativo a un problema di sicurezza. Gli esseri umani possono essere una delle fonti più preziose per gli eventi di sicurezza, quindi è importante disporre di processi che consentano alle persone di esprimere le proprie preoccupazioni. È necessario utilizzare i modelli di minaccia del proprio ambiente per iniziare a rilevare gli edifici. I modelli di minaccia ti aiuteranno a creare avvisi basati sulle minacce più pertinenti al tuo ambiente. Infine, è possibile utilizzare framework come MITRE ATT&CK per comprendere tattiche, tecniche e procedure degli attori delle minacce (). TTPs Il framework MITRE ATT&CK può essere utile da utilizzare come linguaggio comune tra i vari meccanismi di rilevamento.
# 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`*
# Contenimento
Una definizione di contenimento, in relazione alla risposta agli incidenti, è il processo o l'implementazione di una strategia durante la gestione di un evento di sicurezza che agisce per ridurre al minimo la portata dell'evento di sicurezza e contenere gli effetti dell'uso non autorizzato all'interno dell'ambiente.
Una strategia di contenimento dipende da una miriade di fattori e può variare da un'organizzazione all'altra in termini di applicazione delle tattiche di contenimento, della tempistica e dello scopo. La [Guida alla gestione degli incidenti di sicurezza informatica NIST SP 800-61](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) delinea diversi criteri per determinare la strategia di contenimento appropriata, che include:
+ Potenziali danni e furti di risorse
+ Necessità di conservare le prove
+ Disponibilità del servizio (connettività di rete, servizi forniti a soggetti esterni)
+ Tempo e risorse necessari per attuare la strategia
+ Efficacia della strategia (contenimento parziale o totale)
+ Durata della soluzione (soluzione alternativa di emergenza da rimuovere in quattro ore, soluzione temporanea da rimuovere in due settimane, soluzione permanente)
Per quanto riguarda i servizi AWS attivi, tuttavia, le fasi fondamentali di contenimento possono essere suddivise in tre categorie:
+ **Contenimento della fonte**: utilizza il filtraggio e il routing per impedire l'accesso da una determinata fonte.
+ **Tecnica e contenimento degli accessi**: rimuovi l'accesso per impedire l'accesso non autorizzato alle risorse interessate.
+ **Contenimento della destinazione**: utilizza il filtraggio e il routing per impedire l'accesso a una risorsa di destinazione.
# Contenimento della fonte
Il contenimento della fonte è l'uso e l'applicazione del filtraggio o del routing all'interno di un ambiente per impedire l'accesso alle risorse da uno specifico indirizzo IP di origine o intervallo di rete. Di seguito sono evidenziati alcuni esempi di contenimento delle sorgenti tramite AWS servizi:
+ **Gruppi di sicurezza**: la creazione e l'applicazione di gruppi di sicurezza di isolamento alle istanze Amazon EC2 o la rimozione di regole da un gruppo di sicurezza esistente può aiutare a contenere il traffico non autorizzato verso un'istanza o una risorsa Amazon EC2. AWS È importante notare che le connessioni tracciate esistenti non verranno interrotte a seguito della modifica dei gruppi di sicurezza: solo il traffico futuro verrà effettivamente bloccato dal nuovo gruppo di sicurezza (consulta [questo Incident Response Playbook](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md) e Tracciamento delle connessioni dei gruppi di [sicurezza per ulteriori informazioni sulle connessioni tracciate](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) e non tracciate).
+ **Policy: le policy** dei bucket di Amazon S3 possono essere configurate per bloccare o consentire il traffico proveniente da un indirizzo IP, un intervallo di rete o un endpoint VPC. Le policy consentono di bloccare gli indirizzi sospetti e l'accesso al bucket Amazon S3. Ulteriori informazioni sulle policy dei bucket sono disponibili alla pagina [Aggiungere una policy sui bucket utilizzando la console Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html).
+ **AWS WAF **— Le liste di controllo degli accessi Web (web ACLs) possono essere configurate AWS WAF per fornire un controllo dettagliato sulle richieste Web a cui le risorse rispondono. È possibile aggiungere un indirizzo IP o un intervallo di rete a un set IP configurato su AWS WAF e applicare condizioni di corrispondenza, ad esempio blocco, al set IP. Ciò bloccherà le richieste Web a una risorsa se l'indirizzo IP o gli intervalli di rete del traffico di origine corrispondono a quelli configurati nelle regole del set IP.
Nel diagramma seguente è illustrato un esempio di contenimento dei sorgenti con un analista della risposta agli incidenti che modifica un gruppo di sicurezza di un'istanza Amazon EC2 per limitare le nuove connessioni solo a determinati indirizzi IP. Come indicato nel bullet sui gruppi di sicurezza, le connessioni tracciate esistenti non verranno interrotte a seguito della modifica dei gruppi di sicurezza.
![\[Diagramma che mostra un esempio di contenimento delle sorgenti\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/images/source-containment-example.png)
**Nota**
I gruppi di sicurezza e gli ACL di rete non filtrano il traffico verso Amazon Route 53. Quando contiene un'istanza EC2, se vuoi evitare che entri in contatto con host esterni, assicurati di bloccare esplicitamente anche le comunicazioni DNS.
# Tecnica e contenimento degli accessi
Impedisci l'uso non autorizzato di una risorsa limitando le funzioni e i principali IAM con accesso alla risorsa. Ciò include la limitazione delle autorizzazioni dei responsabili IAM che hanno accesso alla risorsa; include anche la revoca temporanea delle credenziali di sicurezza. Di seguito sono evidenziati esempi di tecniche e contenimento degli accessi tramite i servizi: AWS
+ **Limita le autorizzazioni: le** autorizzazioni assegnate a un principale IAM devono seguire il [principio del privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). Tuttavia, durante un evento di sicurezza attivo, potrebbe essere necessario limitare ulteriormente l'accesso a una risorsa mirata da parte di uno specifico preside IAM. In questo caso, è possibile contenere l'accesso a una risorsa rimuovendo le autorizzazioni dal principale IAM da contenere. Questa operazione viene eseguita con il servizio IAM e può essere applicata utilizzando Console di gestione AWS AWS CLI, the o un AWS SDK.
+ Chiavi di **revoca: le chiavi** di accesso IAM vengono utilizzate dai dirigenti IAM per accedere o gestire le risorse. [Si tratta di credenziali statiche a lungo termine per firmare le richieste programmatiche all' AWS API AWS CLI or e iniziano con il prefisso *AKIA* (per ulteriori informazioni, consulta la sezione *Understanding unique ID prefixes* negli identificatori IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html) Per limitare l'accesso a un principale IAM in cui una chiave di accesso IAM è stata compromessa, la chiave di accesso può essere disattivata o eliminata. È importante tenere presente quanto segue:
+ Una chiave di accesso può essere riattivata dopo essere stata disattivata.
+ Una chiave di accesso non è recuperabile una volta eliminata.
+ Un principale IAM può avere fino a due chiavi di accesso alla volta.
+ Gli utenti o le applicazioni che utilizzano la chiave di accesso perderanno l'accesso una volta disattivata o eliminata la chiave.
+ **Revoca delle credenziali di sicurezza temporanee**[: le credenziali di sicurezza temporanee possono essere utilizzate da un'organizzazione per controllare l'accesso alle AWS risorse e iniziano con il prefisso *ASIA* (per ulteriori informazioni, consulta la sezione *Understanding unique ID prefixes* negli identificatori IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html) Le credenziali temporanee vengono in genere utilizzate dai ruoli IAM e non devono essere ruotate o revocate esplicitamente perché hanno una durata limitata. Nei casi in cui si verifica un evento di sicurezza che coinvolge una credenziale di sicurezza temporanea prima della scadenza della credenziale di sicurezza temporanea, potrebbe essere necessario modificare le autorizzazioni effettive delle credenziali di sicurezza temporanee esistenti. Questa operazione può essere completata [utilizzando](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) il servizio IAM within. Console di gestione AWS Le credenziali di sicurezza temporanee possono essere rilasciate anche agli utenti IAM (a differenza dei ruoli IAM); tuttavia, al momento della stesura di questo documento, non è possibile revocare le credenziali di sicurezza temporanee per un utente IAM all'interno di. Console di gestione AWS Per gli eventi di sicurezza in cui la chiave di accesso IAM di un utente viene compromessa da un utente non autorizzato che ha creato credenziali di sicurezza temporanee, le credenziali di sicurezza temporanee possono essere revocate utilizzando due metodi:
+ Allega una policy in linea all'utente IAM che impedisca l'accesso in base alla data di emissione del token di sicurezza (per maggiori dettagli, consulta la sezione *Negare l'accesso alle credenziali di sicurezza temporanee emesse prima di un orario specifico* in [Disabilitazione delle autorizzazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html) per le credenziali di sicurezza temporanee).
+ Elimina l'utente IAM che possiede le chiavi di accesso compromesse. Ricrea l'utente se necessario.
+ **AWS WAF**- Alcune tecniche utilizzate da utenti non autorizzati includono schemi di traffico malevoli comuni, come le richieste che contengono SQL injection e cross-site scripting (XSS). AWS WAF può essere configurato per abbinare e negare il traffico utilizzando queste tecniche utilizzando le istruzioni delle regole integrate. AWS WAF
Un esempio di contenimento della tecnica e degli accessi è riportato nel diagramma seguente, con un operatore che risponde agli incidenti che ruota le chiavi di accesso o rimuove una policy IAM per impedire a un utente IAM di accedere a un bucket Amazon S3.
![\[Diagramma che mostra una tecnica e un esempio di contenimento degli accessi\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/images/technique-and-access-containment.png)
# Contenimento della destinazione
Il contenimento della destinazione è l'applicazione del filtraggio o del routing all'interno di un ambiente per impedire l'accesso a un host o a una risorsa mirati. In alcuni casi, il contenimento della destinazione implica anche una forma di resilienza per verificare che le risorse legittime vengano replicate ai fini della disponibilità; le risorse devono essere separate da queste forme di resilienza per l'isolamento e il contenimento. Alcuni esempi di contenimento della destinazione mediante servizi includono: AWS
+ **Rete ACLs **: alle reti ACLs (rete ACLs) configurate su sottoreti che contengono AWS risorse possono essere aggiunte regole di negazione. Queste regole di negazione possono essere applicate per impedire l'accesso a una particolare AWS risorsa; tuttavia, l'applicazione della lista di controllo dell'accesso alla rete (Network ACL) influirà su tutte le risorse della sottorete, non solo sulle risorse a cui si accede senza autorizzazione. Le regole elencate in un ACL di rete vengono elaborate in ordine dall'alto verso il basso, pertanto la prima regola in un ACL di rete esistente deve essere configurata in modo da impedire il traffico non autorizzato verso la risorsa e la sottorete di destinazione. In alternativa, è possibile creare un ACL di rete completamente nuovo con una regola di negazione singola per il traffico in entrata e in uscita e associato alla sottorete contenente la risorsa di destinazione per impedire l'accesso alla sottorete utilizzando il nuovo ACL di rete.
+ **Arresto**: la chiusura completa di una risorsa può essere efficace nel contenere gli effetti dell'uso non autorizzato. La chiusura di una risorsa impedirà inoltre l'accesso legittimo per esigenze aziendali e impedirà l'ottenimento di dati forensi volatili, quindi questa decisione dovrebbe essere mirata e valutata in base alle politiche di sicurezza dell'organizzazione.
+ **Isolamento VPCs **: i VPC di isolamento possono essere utilizzati per garantire un contenimento efficace delle risorse fornendo al contempo l'accesso al traffico legittimo (ad esempio soluzioni antivirus (AV) o EDR che richiedono l'accesso a Internet o a una console di gestione esterna). I VPC di isolamento possono essere preconfigurati prima di un evento di sicurezza per consentire indirizzi IP e porte validi e le risorse mirate possono essere immediatamente spostate in questo VPC di isolamento durante un evento di sicurezza attivo per contenere la risorsa e consentire al traffico legittimo di essere inviato e ricevuto dalla risorsa interessata durante le fasi successive di risposta all'incidente. Un aspetto importante dell'utilizzo di un VPC di isolamento è che le risorse, come le istanze EC2, devono essere chiuse e riavviate nel nuovo VPC di isolamento prima dell'uso. Le istanze EC2 esistenti non possono essere spostate in un altro VPC o in un'altra zona di disponibilità. A tale scopo, segui i passaggi descritti in [Come posso spostare la mia istanza Amazon EC2 su un'altra sottorete, zona di disponibilità](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/) o VPC?
+ **Gruppi di Auto Scaling e sistemi di bilanciamento del carico: AWS le risorse collegate ai** gruppi Auto Scaling e ai sistemi di bilanciamento del carico devono essere scollegate e cancellate come parte delle procedure di contenimento della destinazione. Il distacco e la cancellazione delle risorse possono essere eseguiti utilizzando l'SDK, e. AWS Console di gestione AWS AWS CLI AWS
Un esempio di contenimento della destinazione è illustrato nel diagramma seguente, con un analista della risposta agli incidenti che aggiunge un ACL di rete a una sottorete per bloccare una richiesta di connessione di rete proveniente da un host non autorizzato.
![\[Diagramma che mostra un esempio di contenimento della destinazione\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/images/destination-containment.png)
# Riepilogo
Il contenimento è una fase del processo di risposta agli incidenti e può essere manuale o automatizzato. La strategia generale di contenimento deve essere in linea con le politiche di sicurezza e le esigenze aziendali di un'organizzazione e verificare che gli effetti negativi siano mitigati nel modo più efficiente possibile prima dell'eradicazione e del ripristino.
# Rimozione
Per eradicazione, in relazione alla risposta agli incidenti di sicurezza, si intende la rimozione di risorse sospette o non autorizzate nel tentativo di riportare l'account a uno stato di sicurezza noto. La strategia di eradicazione dipende da molteplici fattori, che dipendono dai requisiti aziendali dell'organizzazione.
La [Guida alla gestione degli incidenti di sicurezza informatica NIST SP 800-61](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) fornisce diversi passaggi per l'eradicazione:
1. Identifica e mitiga tutte le vulnerabilità che sono state sfruttate.
1. Rimuovi malware, materiali inappropriati e altri componenti.
1. Se vengono scoperti altri host interessati (ad esempio, nuove infezioni da malware), ripeti i passaggi di rilevamento e analisi per identificare tutti gli altri host interessati, quindi contenere ed eliminare l'incidente per loro.
Per quanto riguarda AWS le risorse, questo può essere ulteriormente perfezionato attraverso gli eventi rilevati e analizzati tramite i log disponibili o strumenti automatizzati come CloudWatch Logs e Amazon. GuardDuty Tali eventi dovrebbero costituire la base per determinare quali interventi correttivi devono essere eseguiti per ripristinare correttamente l'ambiente a uno stato di sicurezza noto.
La prima fase dell'eliminazione consiste nel determinare quali risorse all'interno dell'account sono state danneggiate. AWS Ciò si ottiene mediante l'analisi delle fonti di dati di registro disponibili, delle risorse e degli strumenti automatizzati.
+ Identifica le azioni non autorizzate intraprese dalle identità IAM nel tuo account.
+ Identifica accessi o modifiche non autorizzati al tuo account.
+ Identifica la creazione di risorse o utenti IAM non autorizzati.
+ Identifica i sistemi o le risorse con modifiche non autorizzate.
Una volta identificato l'elenco delle risorse, è necessario valutarle ciascuna per determinare l'impatto aziendale in caso di eliminazione o ripristino della risorsa. Ad esempio, se un server Web ospita la tua applicazione aziendale e la sua eliminazione causerebbe dei tempi di inattività, dovresti prendere in considerazione la possibilità di recuperare la risorsa da backup sicuri verificati o di riavviare il sistema da un'AMI pulita prima di eliminare il server interessato.
Una volta conclusa l'analisi dell'impatto aziendale, utilizzando gli eventi dell'analisi dei log, è necessario accedere agli account ed eseguire le azioni correttive appropriate, ad esempio:
+ Ruota o elimina le chiavi: questo passaggio elimina la possibilità dell'attore di continuare a svolgere attività all'interno dell'account.
+ Ruota le credenziali utente IAM potenzialmente non autorizzate.
+ Elimina risorse non riconosciute o non autorizzate.
**Importante**
Se devi conservare risorse per le tue indagini, valuta la possibilità di effettuare un backup di tali risorse. Ad esempio, se devi conservare un'istanza Amazon EC2 per motivi normativi, di conformità o legali, [crea uno snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) prima di rimuovere l'istanza.
+ Per le infezioni da malware, potrebbe essere necessario contattare uno AWS Partner o un altro fornitore. AWS non offre strumenti nativi per l'analisi o la rimozione del malware. Tuttavia, se utilizzi il modulo GuardDuty Malware per Amazon EBS, potrebbero essere disponibili consigli per i risultati forniti.
Dopo aver eliminato le risorse interessate identificate, ti AWS consiglia di eseguire una revisione di sicurezza del tuo account. Ciò può essere fatto utilizzando AWS Config regole, utilizzando soluzioni open source come Prowler e/o tramite altri fornitori ScoutSuite. È inoltre consigliabile prendere in considerazione l'esecuzione di scansioni di vulnerabilità sulle risorse pubbliche (Internet) a disposizione per valutare il rischio residuo.
L'eradicazione è una fase del processo di risposta agli incidenti e può essere manuale o automatizzata, a seconda dell'incidente e delle risorse interessate. La strategia generale deve essere in linea con le politiche di sicurezza e le esigenze aziendali dell'organizzazione e verificare che gli effetti negativi siano mitigati dalla rimozione di risorse o configurazioni inappropriate.
# Ripristino
Il ripristino è il processo che prevede il ripristino dei sistemi a uno stato sicuro noto, la verifica della sicurezza dei backup o l'assenza dell'impatto dell'incidente prima del ripristino, la verifica del corretto funzionamento dei sistemi dopo il ripristino e la risoluzione delle vulnerabilità associate all'evento di sicurezza.
L'ordine di ripristino dipende dai requisiti dell'organizzazione. Come parte del processo di ripristino, è necessario eseguire un'analisi dell'impatto aziendale per determinare almeno:
+ Priorità aziendali o di dipendenza
+ Il piano di restauro
+ Autenticazione e autorizzazione
La Guida alla gestione degli incidenti di sicurezza informatica NIST SP 800-61 fornisce diversi passaggi per ripristinare i sistemi, tra cui:
+ Ripristino dei sistemi da backup puliti.
+ Verificate che i backup vengano valutati prima del ripristino sui sistemi per assicurarvi che l'infezione non sia presente e per prevenire il ripetersi dell'evento di sicurezza.
I backup devono essere valutati regolarmente nell'ambito dei test di disaster recovery per verificare che il meccanismo di backup funzioni correttamente e che l'integrità dei dati soddisfi gli obiettivi dei punti di ripristino.
+ Se possibile, utilizzate i backup precedenti al timestamp del primo evento identificato come parte dell'analisi della causa principale.
+ Ricostruzione dei sistemi da zero, inclusa la ridistribuzione da fonti attendibili utilizzando l'automazione, a volte in un nuovo account. AWS
+ Sostituzione di file compromessi con versioni pulite.
È necessario prestare molta attenzione quando si esegue questa operazione. È necessario essere assolutamente certi che il file che si sta recuperando sia noto, sicuro e inalterato dall'incidente.
+ Installazione delle patch.
+ Modifica delle password.
+ Ciò include le password per i presidi IAM che potrebbero essere state utilizzate in modo improprio.
+ Se possibile, consigliamo di utilizzare i ruoli per i principali e la federazione IAM come parte di una strategia con privilegi minimi.
+ Rafforzamento della sicurezza perimetrale della rete (set di regole del firewall, elenchi di controllo degli accessi ai router boundary).
Una volta recuperate le risorse, è importante raccogliere le lezioni apprese per aggiornare le politiche, le procedure e le guide di risposta agli incidenti.
In sintesi, è fondamentale implementare un processo di ripristino che faciliti il ritorno a operazioni sicure note. Il ripristino può richiedere molto tempo e richiede uno stretto collegamento con le strategie di contenimento per bilanciare l'impatto aziendale con il rischio di reinfezione. Le procedure di ripristino devono includere passaggi per il ripristino di risorse e servizi, i principi IAM e l'esecuzione di una revisione della sicurezza dell'account per valutare il rischio residuo.
# Conclusioni
Ogni fase operativa ha obiettivi, tecniche, metodologie e strategie unici. La Tabella 4 riassume queste fasi e alcune delle tecniche e metodologie trattate in questa sezione.
*Tabella 4 — Fasi operative: obiettivi, tecniche e metodologie*
| Fase | Obiettivo | Tecniche e metodologie |
| --- | --- | --- |
| Rilevamento | Identifica un potenziale evento di sicurezza. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/operations-conclusion.html) |
| Analisi | Determina se l'evento di sicurezza è un incidente e valuta la portata dell'incidente. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/operations-conclusion.html) |
| Contenimento | Riduci al minimo e limita l'impatto dell'evento di sicurezza. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/operations-conclusion.html) |
| Eradicazione | Rimuovi risorse o artefatti non autorizzati correlati all'evento di sicurezza. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/operations-conclusion.html) |
| Recupero | Ripristina i sistemi allo stato corretto noto e monitora questi sistemi per garantire che la minaccia non si ripresenti. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/security-ir/latest/userguide/operations-conclusion.html) |