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à.
# Processo
Lo sviluppo di processi di risposta agli incidenti completi e chiaramente definiti è fondamentale per un programma di risposta agli incidenti efficace e scalabile. Quando si verifica un evento di sicurezza, procedure e flussi di lavoro chiari vi aiuteranno a rispondere in modo tempestivo. È possibile che esistano già dei processi di risposta agli incidenti. Indipendentemente dallo stato attuale, è importante aggiornare, iterare e testare con regolarità i processi di risposta agli incidenti.
# Sviluppa e testa un piano di risposta agli incidenti
Il primo documento da sviluppare per la risposta agli incidenti è il *piano di risposta agli incidenti*. Lo scopo del piano di risposta agli incidenti è costituire la base del programma e della strategia di risposta agli incidenti. Un piano di risposta agli incidenti è un documento di alto livello che in genere include le seguenti sezioni:
+ **Panoramica del team di risposta agli incidenti**: delinea gli obiettivi e le funzioni del team di risposta agli incidenti
+ **Ruoli e responsabilità**: elenca le parti interessate alla risposta agli incidenti e descrive in dettaglio i loro ruoli quando si verifica un incidente
+ **Un piano di comunicazione**: descrive in dettaglio le informazioni di contatto e il modo in cui comunicherai durante un incidente
È consigliabile utilizzare la out-of-band comunicazione come supporto per la comunicazione in caso di incidente. Un esempio di applicazione che fornisce un canale di out-of-band comunicazione sicuro è [AWS Wickr](https://aws.amazon.com/wickr/).
+ **Fasi di risposta agli incidenti e azioni da intraprendere**: enumera le fasi di risposta agli incidenti, ad esempio rilevamento, analisi, eliminazione, contenimento e ripristino, comprese le azioni di alto livello da intraprendere nell'ambito di tali fasi
+ **Definizioni di gravità e prioritizzazione degli incidenti**: descrive in dettaglio come classificare la gravità di un incidente, come assegnare priorità all'incidente e quindi in che modo le definizioni di gravità influiscono sulle procedure di escalation
Sebbene queste sezioni siano comuni ad aziende di diverse dimensioni e settori, il piano di risposta agli incidenti di ciascuna organizzazione è unico. Dovrai creare un piano di risposta agli incidenti che funzioni meglio per la tua organizzazione.
# Documenta e centralizza i diagrammi di architettura
Per rispondere in modo rapido e preciso a un evento di sicurezza, è necessario comprendere come sono architettati i sistemi e le reti. La comprensione di questi modelli interni non è importante solo per la risposta agli incidenti, ma anche per verificare la coerenza tra le applicazioni con cui sono progettati i modelli, secondo le migliori pratiche. È inoltre necessario verificare che questa documentazione sia aggiornata e regolarmente aggiornata in base ai nuovi modelli di architettura. È necessario sviluppare documentazione e archivi interni che descrivano in dettaglio elementi come:
+ **AWS struttura dell'account** - Devi sapere:
+ Quanti AWS account hai?
+ Come sono organizzati questi AWS conti?
+ Chi sono i titolari aziendali degli AWS account?
+ Utilizzate Service Control Policies (SCPs)? In caso affermativo, quali barriere organizzative vengono implementate utilizzando? SCPs
+ Sono previste limitazioni alle regioni e ai servizi che è possibile utilizzare?
+ Quali sono le differenze tra le unità aziendali e gli ambienti (dev/test/prod)?
+ **AWS modelli di servizio**
+ Quali AWS servizi utilizzi?
+ Quali sono i AWS servizi più utilizzati?
+ **Modelli di architettura**
+ Quali architetture cloud utilizzate?
+ **AWS modelli di autenticazione**
+ In che modo i tuoi sviluppatori si autenticano in genere? AWS
+ Utilizzate ruoli o utenti IAM (o entrambi)? La tua autenticazione è AWS connessa a un provider di identità (IdP)?
+ Come si fa a mappare un ruolo o un utente IAM a un dipendente o a un sistema?
+ In che modo l'accesso viene revocato quando qualcuno non è più autorizzato?
+ **AWS modelli di autorizzazione**
+ Quali politiche IAM utilizzano i tuoi sviluppatori?
+ Utilizzate politiche basate sulle risorse?
+ **Registrazione e monitoraggio**
+ Quali fonti di registrazione utilizzate e dove vengono archiviate?
+ Aggregate AWS CloudTrail i log? In caso affermativo, dove vengono archiviati?
+ Come si interrogano CloudTrail i log?
+ Hai GuardDuty abilitato Amazon?
+ Come si accede ai GuardDuty risultati (ad esempio, console, sistema di ticketing, SIEM)?
+ I risultati o gli eventi sono aggregati in un SIEM?
+ I biglietti vengono creati automaticamente?
+ Quali strumenti sono disponibili per analizzare i registri per un'indagine?
+ **Topologia di rete**
+ Come sono disposti fisicamente o logicamente i dispositivi, gli endpoint e le connessioni della rete?
+ Come si connette la tua rete a? AWS
+ Come viene filtrato il traffico di rete tra gli ambienti?
+ **Infrastruttura esterna**
+ Come vengono implementate le applicazioni rivolte verso l'esterno?
+ Quali risorse sono accessibili AWS al pubblico?
+ Quali AWS account contengono un'infrastruttura rivolta verso l'esterno?
+ Che cos' DDoè il filtro S o esterno?
La documentazione dei diagrammi e dei processi tecnici interni facilita il lavoro dell'analista di risposta agli incidenti, aiutandolo ad acquisire rapidamente le conoscenze istituzionali necessarie per rispondere a un evento di sicurezza. Una documentazione completa dei processi tecnici interni non solo semplifica le indagini di sicurezza, ma consente anche la razionalizzazione e la valutazione dei processi.
# Sviluppa dei playbook per la risposta agli incidenti
Una parte fondamentale della preparazione dei processi di risposta agli incidenti è costituita dalla predisposizione di playbook. I playbook di risposta agli incidenti forniscono una serie di indicazioni prescrittive e di passaggi da seguire in caso di evento di sicurezza. Una struttura e passaggi chiari semplificano la risposta e riducono la probabilità di errore umano.
# Per cosa creare playbook
È necessario creare i playbook per scenari di incidenti come:
+ **Incidenti previsti: i** playbook devono essere creati per gli incidenti che prevedi. tra cui minacce come Denial of Service (DoS), ransomware e la compromissione delle credenziali.
+ **Rilevamenti o avvisi di sicurezza noti**: è necessario creare dei playbook per i risultati e gli avvisi di sicurezza noti, ad esempio i risultati. GuardDuty Potresti ricevere una GuardDuty scoperta e pensare: «E adesso?» Per evitare che una GuardDuty scoperta venga gestita male o che la si ignori, crea un manuale per ogni potenziale scoperta. GuardDuty [Alcuni dettagli e linee guida sulla correzione sono disponibili nella documentazione. GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html) Vale la pena notare che non GuardDuty è abilitato di default e comporta un costo. Maggiori dettagli su sono GuardDuty disponibili nell'Appendice A: Definizioni delle funzionalità cloud -. [Visibilità e avvisi](visibility-and-alerting.md)
# Cosa includere nei playbook
I playbook devono contenere i passaggi tecnici che un analista della sicurezza deve seguire per indagare e rispondere in modo adeguato a un potenziale incidente di sicurezza.
Gli elementi da includere in un playbook sono:
+ **Panoramica del playbook**: a quale scenario di rischio o incidente si riferisce questo playbook? Qual è l'obiettivo del playbook?
+ **Prerequisiti**: quali registri e meccanismi di rilevamento sono necessari per questo scenario di incidente? Qual è la notifica prevista?
+ **Informazioni sulle parti interessate**: chi è coinvolto e quali sono le loro informazioni di contatto? Quali sono le responsabilità di ciascuna parte interessata?
+ Fasi di **risposta**: in tutte le fasi della risposta agli incidenti, quali misure tattiche dovrebbero essere adottate? Quali query deve eseguire l'analista? Quale codice va eseguito per ottenere il risultato desiderato?
+ **Rileva**: come verrà rilevato l'incidente?
+ **Analizza**: come verrà determinata la portata dell'impatto?
+ **Contenere**: in che modo verrà isolato l'incidente per limitarne l'ambito?
+ **Eradicazione**: come verrà rimossa la minaccia dall'ambiente?
+ **Ripristino**: in che modo il sistema o la risorsa interessati verranno riportati in produzione?
+ **Risultati attesi**: dopo l'esecuzione delle query e del codice, qual è il risultato previsto del playbook?
Per verificare la coerenza delle informazioni in ogni playbook, può essere utile creare un modello di playbook da utilizzare negli altri playbook di sicurezza. Alcuni degli elementi elencati in precedenza, come le informazioni sugli stakeholder, possono essere condivisi tra più playbook. In tal caso, puoi creare una documentazione centralizzata per tali informazioni e farvi riferimento nel playbook, quindi enumerare le differenze esplicite nel playbook. In questo modo eviterai di dover aggiornare le stesse informazioni in tutti i tuoi playbook individuali. Creando un modello e identificando le informazioni comuni o condivise nei playbook, puoi semplificare e velocizzare lo sviluppo dei playbook. Infine, è probabile che i tuoi playbook si evolveranno nel tempo; una volta confermata la coerenza dei passaggi, ecco i requisiti per l'automazione.
# Playbook di esempio
Alcuni playbook di esempio sono disponibili nell'Appendice B in. [Risorse del playbook](appendix-b-incident-response-resources.md#playbook-resources) Gli esempi riportati di seguito possono essere utilizzati per guidarvi su quali playbook creare e cosa includere nei playbook. Tuttavia, è importante creare dei playbook che includano i rischi più rilevanti per la tua attività. Devi verificare che i passaggi e i flussi di lavoro all'interno dei tuoi playbook includano le tue tecnologie e i tuoi processi.
# Esegui simulazioni regolari
Le organizzazioni crescono e si evolvono nel tempo, così come il panorama delle minacce. Per questo motivo, è importante rivedere continuamente le proprie capacità di risposta agli incidenti. Le simulazioni sono un metodo che può essere utilizzato per eseguire questa valutazione. Le simulazioni utilizzano scenari di eventi di sicurezza reali progettati per imitare le tattiche, le tecniche e le procedure di un autore della minaccia (TTPs) e consentono a un'organizzazione di esercitare e valutare le proprie capacità di risposta agli incidenti rispondendo a questi finti eventi informatici così come potrebbero verificarsi nella realtà.
Le simulazioni offrono una serie di vantaggi, tra cui:
+ Convalida della preparazione informatica e sviluppo della fiducia dei team di risposta agli incidenti.
+ Verifica della precisione e dell'efficienza di strumenti e flussi di lavoro.
+ Perfezionamento dei metodi di comunicazione ed escalation in linea con il piano di risposta agli incidenti.
+ Opportunità di rispondere per i vettori meno comuni.
# Tipi di simulazioni
Esistono tre tipi principali di simulazioni:
+ **Esercizi da tavolo**: l'approccio da tavolo alle simulazioni è strettamente una sessione basata sulla discussione che coinvolge le varie parti interessate alla risposta agli incidenti per mettere in pratica ruoli e responsabilità e utilizzare strumenti di comunicazione e playbook consolidati. La facilitazione dell'esercizio in genere può essere eseguita in un'intera giornata in un luogo virtuale, fisico o in una combinazione di essi. A causa della sua natura basata sulla discussione, l'esercizio da tavolo si concentra su processi, persone e collaborazione. La tecnologia è parte integrante della discussione; tuttavia, l'uso effettivo di strumenti o script di risposta agli incidenti in genere non rientra nell'esercizio da tavolo.
+ **Esercizi** *Purple Team: gli esercizi Purple Team aumentano il livello di collaborazione tra i soccorritori (*Blue Team*) e gli attori simulati delle minacce (Red Team).* Il Blue Team è generalmente composto da membri del Security Operations Center (SOC), ma può includere anche altre parti interessate che potrebbero essere coinvolte durante un vero evento informatico. Il Red Team è generalmente composto da un team di test di penetrazione o da stakeholder chiave formati in materia di sicurezza offensiva. Il Red Team collabora con i facilitatori degli esercizi durante la progettazione di uno scenario in modo che lo scenario sia accurato e fattibile. Durante le esercitazioni del Purple Team, l'attenzione principale è rivolta ai meccanismi di rilevamento, agli strumenti e alle procedure operative standard (SOPs) a supporto degli sforzi di risposta agli incidenti.
+ **Esercizi della Squadra** Rossa — Durante un'esercitazione della *Squadra Rossa, l'attacco (Squadra Rossa*) conduce una simulazione per raggiungere un determinato obiettivo o una serie di obiettivi da un ambito predeterminato. I difensori (*Blue Team*) non necessariamente conosceranno la portata e la durata dell'esercitazione, il che fornisce una valutazione più realistica di come reagirebbero a un incidente reale. Poiché gli esercizi della Red Team possono essere test invasivi, è necessario prestare attenzione e implementare controlli per verificare che l'esercizio non provochi danni effettivi all'ambiente.
**Nota**
AWS richiede ai clienti di rivedere la politica per i test di penetrazione disponibile sul [sito web di Penetration Testing](https://aws.amazon.com/security/penetration-testing/) prima di condurre gli esercizi del Purple Team o del Red Team.
La Tabella 1 riassume alcune differenze chiave in questi tipi di simulazioni. È importante notare che le definizioni sono generalmente considerate generiche e possono essere personalizzate per soddisfare le esigenze dell'organizzazione.
*Tabella 1 — Tipi di simulazioni*
| | Esercizio da tavolo | Esercizio Purple Team | Esercizio della squadra rossa |
| --- | --- | --- | --- |
| Riepilogo | Esercizi cartacei incentrati su uno specifico scenario di incidente di sicurezza. Questi possono essere di alto livello o tecnici e sono azionati da una serie di iniezioni di carta. | Un'offerta più realistica rispetto agli esercizi da tavolo. Durante gli esercizi del Purple Team, i facilitatori collaborano con i partecipanti per aumentare il coinvolgimento negli esercizi e offrire formazione laddove necessario. | Generalmente un'offerta di simulazione più avanzata. Di solito c'è un alto livello di segretezza, in cui i partecipanti potrebbero non conoscere tutti i dettagli dell'esercizio. |
| Risorse richieste | Risorse tecniche limitate richieste | Sono necessarie diverse parti interessate e un elevato livello di risorse tecniche | Sono necessarie diverse parti interessate e sono necessarie risorse tecniche di alto livello |
| Complessità | Bassa | Media | Elevata |
Prendi in considerazione la possibilità di svolgere simulazioni informatiche a intervalli regolari. Ogni tipo di esercizio può offrire vantaggi unici ai partecipanti e all'organizzazione nel suo insieme, quindi potresti scegliere di iniziare con tipi di simulazione meno complessi (come gli esercizi da tavolo) e passare a tipi di simulazione più complessi (esercizi della Squadra Rossa). È necessario selezionare un tipo di simulazione in base alla maturità, alle risorse e ai risultati desiderati a livello di sicurezza. Alcuni clienti potrebbero non scegliere di eseguire gli esercizi del Red Team a causa della complessità e dei costi.
# Ciclo di vita dell'esercizio
Indipendentemente dal tipo di simulazione scelto, le simulazioni generalmente seguono questi passaggi:
1. **Definisci gli elementi principali dell'esercizio**: definisci lo scenario di simulazione e gli obiettivi della simulazione. Lo scenario e gli obiettivi dovrebbero essere entrambi accettati dalla leadership.
1. **Identifica le principali parti interessate**: come minimo, un'esercitazione necessita di facilitatori e partecipanti all'esercizio. A seconda dello scenario, potrebbero essere coinvolte altre parti interessate come la leadership legale, delle comunicazioni o esecutiva.
1. **Crea e testa lo scenario**: potrebbe essere necessario ridefinire lo scenario in fase di creazione se elementi specifici non sono fattibili. Come risultato di questa fase è previsto uno scenario definitivo.
1. **Facilitare la simulazione**: il tipo di simulazione determina la facilitazione utilizzata (scenario cartaceo rispetto a uno scenario simulato altamente tecnico). I coordinatori dovrebbero allineare le loro tattiche di svolgimento agli oggetti dell'esercitazione e dovrebbero coinvolgere tutti i partecipanti ove possibile per ottimizzare i benefici.
1. **Sviluppa il rapporto post-azione (AAR)**: identifica le aree che sono andate bene, quelle che possono essere migliorate e le potenziali lacune. Il report AAR dovrebbe misurare l'efficacia della simulazione e la risposta del team all'evento simulato in modo che i progressi possano essere monitorati nel tempo con simulazioni future.