# SEC 10. In che modo è possibile prevedere gli eventi, rispondere ad essi e risolverli?
Anche se dispone di controlli preventivi e di rilevamento maturi, l'organizzazione deve ancora implementare meccanismi per rispondere e mitigare il potenziale impatto degli incidenti di sicurezza. La tua preparazione influisce fortemente sulla capacità dei team di operare in modo efficace durante un incidente, isolare, contenere ed eseguire indagini sui problemi e ripristinare le operazioni a uno stato valido noto. La messa in atto degli strumenti e l'accesso prima di un incidente di sicurezza, quindi la pratica sistematica della risposta agli incidenti durante le giornate di gioco, aiuterà a garantire il ripristino, riducendo al minimo le interruzioni dell'attività.
**Topics**
+ [SEC10-BP01 Identificazione del personale chiave e delle risorse esterne](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Sviluppo di piani di gestione degli incidenti](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Preparazione di funzionalità forensi](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Sviluppo e test di playbook di risposta agli incidenti di sicurezza](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Preassegnazione dell'accesso](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Distribuzione anticipata degli strumenti](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Esecuzione di simulazioni](sec_incident_response_run_game_days.md)
+ [SEC10-BP08 Definizione di un framework per apprendere dagli incidenti](sec_incident_response_establish_incident_framework.md)
# SEC10-BP01 Identificazione del personale chiave e delle risorse esterne
Identifica personale, risorse e requisiti legali interni ed esterni che potrebbero aiutare l'organizzazione a rispondere a un incidente.
Quando definisci come affrontare la risposta agli incidenti nel cloud, insieme ad altri team (ad esempio il consulente legale, la leadership dell'organizzazione, le parti interessate, i servizi AWS Support e altri), devi identificare il personale chiave, le parti interessate e i contatti pertinenti. Per ridurre le dipendenze e i tempi di risposta, assicurati che il personale, i team di sicurezza specializzati e i team che rispondono agli incidenti ricevano informazioni sui servizi che utilizzi e abbiano l'opportunità di esercitarsi direttamente.
Ti invitiamo a identificare i partner di sicurezza AWS esterni in grado di fornirti competenze e una prospettiva diversa per potenziare le tue capacità di risposta. I partner di sicurezza affidabili possono aiutarti a identificare potenziali rischi o minacce che potresti non conoscere.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
+ **Identificazione del personale chiave all'interno dell'organizzazione:** Conserva un elenco di contatti del personale interno alla tua organizzazione che potrebbe essere necessario coinvolgere per rispondere a un incidente ed effettuare il ripristino.
+ **Identificazione dei partner esterni:** Se necessario, coinvolgi partner esterni che possano aiutarti a rispondere a un incidente e a effettuare il ripristino.
## Risorse
**Documenti correlati:**
+ [AWS Incident Response Guide (Guida alle risposte agli incidenti)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Video correlati:**
+ [Prepare for and respond to security incidents in your AWS environment ](https://youtu.be/8uiO0Z5meCs)
**Esempi correlati:**
# SEC10-BP02 Sviluppo di piani di gestione degli 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.
**Vantaggi dell'adozione di questa best practice:** 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, passaggi e flussi di lavoro ben definiti ti aiuteranno a rispondere in modo tempestivo. Potrebbero essere già presenti processi di risposta agli incidenti. Indipendentemente dallo stato attuale, è importante aggiornare, iterare e testare regolarmente i processi di risposta agli incidenti.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Un piano di gestione degli incidenti è fondamentale per rispondere, mitigare e ripristinare lo stato a seguito del potenziale impatto degli incidenti di sicurezza. Un piano di gestione degli incidenti è un processo strutturato per identificare, correggere e rispondere tempestivamente agli incidenti di sicurezza.
Il cloud ha molti degli stessi ruoli e requisiti operativi che si trovano in un ambiente on-premise. Quando si crea un piano di gestione degli incidenti è importante tenere conto delle strategie di risposta e ripristino che meglio si allineano ai risultati aziendali e ai requisiti di conformità. Ad esempio, se gestisci carichi di lavoro in AWS conformi a FedRAMP negli Stati Uniti, è utile attenersi a [NIST SP 800-61 Computer Security Handling Guide (NIST SP 800-61 Guida alla gestione della sicurezza informatica)](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Analogamente, quando gestisci carichi di lavoro con informazioni di identificazione personale (PII) europee, considera ad esempio come potresti proteggere e rispondere a problemi relativi alla residenza dei dati come richiesto dalle [normative del Regolamento generale sulla protezione dei dati (GDPR) dell'Unione europea](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en).
Quando crei un piano di gestione degli incidenti per i carichi di lavoro in AWS, inizia con il [modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) per creare un approccio di difesa in profondità in risposta agli incidenti. In questo modello, AWS gestisce la sicurezza del cloud e tu sei responsabile della sicurezza nel cloud. Ciò significa che mantieni il controllo e sei responsabile dei controlli di sicurezza che scegli di implementare. La [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) illustra i concetti chiave e le linee guida di base per la creazione di un piano di gestione degli incidenti incentrato sul cloud.
Un piano di gestione degli incidenti efficace deve essere continuamente iterato per rimanere in linea con l'obiettivo delle operazioni cloud. Prendi in considerazione l'utilizzo dei piani di implementazione descritti di seguito durante la creazione e l'evoluzione del tuo piano di gestione degli incidenti.
## Passaggi dell'implementazione
**Definizione di ruoli e responsabilità**
La gestione degli eventi di sicurezza richiede disciplina interorganizzativa e propensione all'azione. All'interno della struttura organizzativa, dovrebbero esserci molte persone da considerarsi responsabili, affidabili, consultabili o informate durante un incidente, come i rappresentanti delle risorse umane (HR), i membri del team esecutivo e quelli dell'ufficio legale. Considera questi ruoli e queste responsabilità e se è necessario coinvolgere terze parti. Si noti che molte aree geografiche hanno leggi locali che regolano cosa dovrebbe e non dovrebbe essere fatto. Sebbene possa sembrare burocratico creare una tabella delle persone responsabili, affidabili, consultabili e informate (RACI) per i piani di risposta relativi alla sicurezza, ciò facilita una comunicazione rapida e diretta e delinea chiaramente la leadership nelle diverse fasi dell'evento.
Durante un incidente, includere i proprietari e gli sviluppatori delle applicazioni e delle risorse interessate è fondamentale perché sono esperti in materia (PMI) che possono fornire informazioni e contesto per aiutare a valutare l'impatto. Assicurati di fare pratica e instaurare relazioni con gli sviluppatori e i proprietari delle applicazioni prima di affidarti alla loro esperienza per la gestione della risposta agli incidenti. I proprietari di applicazioni o le PMI, come gli amministratori o gli ingegneri del cloud, potrebbero dover intervenire in situazioni in cui l'ambiente non è noto oppure è complesso o chi risponde non ha accesso all'ambiente interessato.
Infine, nell'indagine o nella risposta potrebbero essere coinvolti partner affidabili perché possono fornire competenze aggiuntive e capacità analitiche strategiche. Quando non disponi di queste competenze nel tuo team, potresti voler assumere una persona esterna per assistenza.
**Analisi del team di risposta di AWS e del supporto**
+ **Supporto AWS**
+ [Supporto](https://aws.amazon.com/premiumsupport/) offre un'ampia gamma di piani che forniscono accesso agli strumenti e alla competenza che genera successo e stato operativo delle soluzioni AWS. Se hai bisogno di supporto tecnico e di ulteriori risorse per pianificare, implementare e ottimizzare il tuo ambiente AWS, puoi selezionare il piano di supporto più adatto al tuo caso d'uso AWS.
+ Valuta l'ipotesi di utilizzare il [Centro di supporto](https://console.aws.amazon.com/support) in Console di gestione AWS (è richiesto l'accesso) come punto di contatto centralizzato per ottenere assistenza per problemi che riguardano le tue risorse AWS. L'accesso a Supporto è controllato da AWS Identity and Access Management. Per ulteriori informazioni sull'accesso alle funzionalità Supporto, consulta la sezione [Nozioni di base su Supporto](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
+ **Team di risposta agli incidenti dei clienti AWS (CIRT)**
+ Il Team di risposta agli incidenti dei clienti AWS (CIRT) è un team AWS globale specializzato disponibile 24 ore su 24, 7 giorni su 7, che fornisce supporto ai clienti durante eventi di sicurezza attivi sul lato cliente del [modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/).
+ Quando il team AWS CIRT ti supporta, fornisce assistenza nella valutazione e nel ripristino di un evento di sicurezza attivo AWS. Può aiutare nell'analisi delle cause principali con l'uso dei log dei servizi AWS e fornire suggerimenti per il ripristino. Può anche fornire consigli e best practice sulla sicurezza per aiutarti a evitare eventi di sicurezza in futuro.
+ I clienti AWS possono coinvolgere il team AWS CIRT attraverso un [caso Supporto](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
+ **Supporto per la risposta agli attacchi DDoS**
+ AWS offre [AWS Shield](https://aws.amazon.com/shield/), che fornisce un servizio di protezione DDoS (Distributed Denial of Service) gestito che protegge le applicazioni Web in esecuzione su AWS. Shield fornisce un rilevamento sempre attivo e mitigazioni automatiche in linea che possono ridurre al minimo i tempi di inattività e la latenza delle applicazioni, quindi non è necessario utilizzare Supporto per avvalersi della protezione dagli attacchi DDoS. Esistono due livelli di Shield: AWS Shield Standard e AWS Shield Advanced. Per maggiori informazioni sulle differenze tra questi due livelli, consulta la [documentazione delle funzionalità di Shield](https://aws.amazon.com/shield/features/).
+ **AWS Managed Services (AMS)**
+ [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) offre gestione continua dell'infrastruttura AWS, così potrai occuparti a tempo pieno delle tue applicazioni. Grazie all'implementazione delle best practice per la gestione dell'infrastruttura, AMS riduce il sovraccarico operativo e il livello di rischio. AMS automatizza attività frequenti quali richieste di modifica, monitoraggio, gestione di patch, sicurezza e backup, nonché fornisce servizi completi per il ciclo di vita per gestire provisioning, esecuzione e supporto dell'infrastruttura.
+ AMS è responsabile dell'implementazione di una suite di controlli di sicurezza e fornisce una risposta di prima linea agli avvisi 24 ore su 24, 7 giorni su 7. Quando viene avviato un avviso, AMS segue una serie standard di playbook automatici e manuali per verificare una risposta coerente. Questi playbook vengono condivisi con i clienti AMS durante l'onboarding in modo che possano sviluppare e coordinare una risposta con AMS.
**Sviluppo di piani di risposta agli incidenti**
Lo scopo del piano di risposta agli incidenti è costituire la base del programma e della strategia di risposta agli incidenti. Il piano di risposta agli incidenti deve essere contenuto in un documento formale. Un piano di risposta agli incidenti include in genere le seguenti sezioni:
+ **Una 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:** dettagli sulle informazioni di contatto e su come comunichi durante un incidente.
+ **Metodi di comunicazione di backup:** è consigliabile utilizzare la comunicazione fuori banda come backup in caso di incidente. Un esempio di applicazione che fornisce un canale di comunicazione fuori banda sicuro è AWS Wickr.
+ **Fasi di risposta agli incidenti e azioni da intraprendere:** enumera le fasi della risposta agli incidenti (ad esempio, rilevamento, analisi, eliminazione, contenimento e ripristino), comprese le azioni di alto livello da intraprendere all'interno di tali fasi.
+ **Definizioni di gravità e prioritizzazione degli incidenti:** descrive in dettaglio come classificare la gravità di un incidente, come assegnare la priorità all'incidente e, quindi, in che modo le definizioni di gravità influiscono sulle procedure di escalation.
Sebbene queste sezioni siano comuni a società di diverse dimensioni e settori, il piano di risposta agli incidenti di ciascuna organizzazione è unico. Devi creare un piano di risposta agli incidenti che funzioni al meglio per la tua organizzazione.
## Risorse
**Best practice correlate:**
+ [SEC 4 (In che modo individui ed esamini gli eventi di sicurezza?)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documenti correlati:**
+ [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [ NIST: Guida alla gestione degli incidenti di sicurezza informatica ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)
# SEC10-BP03 Preparazione di funzionalità forensi
Prima che si verifichi un incidente di sicurezza, puoi sviluppare le funzionalità forensi per supportare le indagini sugli eventi di sicurezza.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
Il concetto della tradizionale analisi forense on-premise si applica ad AWS. Per informazioni chiave su come iniziare a sviluppare funzionalità forensi in Cloud AWS, consulta [Forensic investigation environment strategies in the Cloud AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/).
Una volta configurati l'ambiente e la struttura di Account AWS per le funzionalità forensi, definisci le tecnologie necessarie in modo da eseguire efficacemente le metodologie forensi in quattro fasi:
+ **Raccolta:** acquisisci i log AWS pertinenti, come quelli di AWS CloudTrail, AWS Config, del flusso VPC e dell'host. Raccogli snapshot, backup e dump di memoria delle risorse AWS interessate, se disponibili.
+ **Esame:** rivedi i dati raccolti estraendo e valutando le informazioni pertinenti.
+ **Analisi:** studia i dati raccolti per comprendere l'incidente e trarre le conclusioni.
+ **Segnalazione:** presenta le informazioni risultanti dalla fase di analisi.
## Passaggi dell'implementazione
**Preparazione dell'ambiente per le funzionalità forensi**
[AWS Organizations](https://aws.amazon.com/organizations/) ti aiuta a gestire e governare centralmente un ambiente AWS mentre le risorse AWS crescono e si dimensionano. Un'organizzazione AWS consolida gli Account AWS in modo da poterli amministrare come una singola unità. È possibile utilizzare le unità organizzative per raggruppare gli account e amministrarli come singola unità.
Per rispondere agli incidenti è utile disporre di una struttura di Account AWS che supporti le funzioni di risposta agli incidenti e includa una *Unità organizzativa di sicurezza* e una *Unità organizzativa forense*. All'interno dell'unità organizzativa di sicurezza, è necessario disporre degli account per:
+ **Archiviazione dei log:** aggrega i log in un Account AWS di archiviazione dei log con autorizzazioni limitate.
+ **Strumenti di sicurezza:** centralizza i servizi di sicurezza in un Account AWS dello strumento di sicurezza. Questo account funge da amministratore delegato per i servizi di sicurezza.
Nell'unità organizzativa di funzionalità forensi, hai la possibilità di implementare uno o più account di funzionalità forensi per ogni regione in cui operi, a seconda di quale è più adatta all'azienda e al modello operativo. Se crei un account di funzionalità forensi per regione, puoi bloccare la creazione di risorse AWS al di fuori della regione e ridurre il rischio che le risorse vengano copiate in una regione indesiderata. Ad esempio, se operi solo in US East (N. Virginia) Region (`us-east-1`) e US West (Oregon) (`us-west-2`), allora avresti due account nell'unità organizzativa forense: uno per `us-east-1` e uno per `us-west-2`.
Puoi creare un Account AWS di funzionalità forensi per più regioni. Quando si copiano le risorse AWS nell'account occorre prestare attenzione a rispettare i requisiti di sovranità dei dati. Poiché la creazione di nuovi account richiede tempo, è fondamentale creare e strumentare gli account di funzionalità forensi con largo anticipo rispetto agli incidenti, in modo che gli addetti siano preparati a utilizzarli efficacemente per la risposta.
Il diagramma seguente mostra una struttura degli account di esempio che include un'unità organizzativa di funzionalità forensi con gli account di funzionalità forensi per regione:
![\[Diagramma di flusso che mostra la struttura degli account per regione per la risposta agli incidenti, suddivisa nelle unità organizzative di sicurezza e funzionalità forensi.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/region-account-structure.png)
**Acquisizione di backup e snapshot**
La configurazione dei backup dei sistemi e dei database importanti è fondamentale per il ripristino da un incidente di sicurezza e per scopi forensi. Con i backup puoi ripristinare i tuoi sistemi allo stato di sicurezza precedente. In AWS puoi acquisire snapshot di varie risorse. Gli snapshot forniscono i backup point-in-time delle risorse. Esistono molti servizi AWS che possono supportarti nelle operazioni di backup e ripristino. Per informazioni dettagliate su questi servizi e approcci per il backup e il ripristino, consultare [Guida prescrittiva per il backup e il ripristino](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) e [Usa i backup per il ripristino in seguito a incidenti di sicurezza](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/).
Soprattutto in situazioni come un attacco ransomware, è fondamentale che i backup siano ben protetti. Per indicazioni sulla protezione dei backup, consultare [Le 10 migliori pratiche di sicurezza per proteggere i backup in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Oltre a proteggere, è necessario eseguire regolarmente i test dei processi di backup e ripristino per verificare che la tecnologia e le procedure in uso funzionino come previsto.
**Automazione delle funzionalità forensi**
Durante un evento di sicurezza, il team addetto a rispondere agli incidenti deve essere in grado di raccogliere e analizzare rapidamente le prove, mantenendo la precisione per il periodo di tempo relativo all'evento (ad esempio acquisendo i log relativi a una risorsa o un evento specifico o raccogliendo il dump della memoria di un'istanza Amazon EC2). Per il team addetto a rispondere agli incidenti è difficile e dispendioso in termini di tempo raccogliere manualmente le prove pertinenti, soprattutto se le istanze e gli account sono numerosi. Inoltre, la raccolta manuale può essere soggetta all'errore umano. Per questi motivi, è necessario sviluppare e implementare il più possibile l'automazione per le funzionalità forensi.
AWS offre una serie di risorse di automazione per le funzionalità forensi, elencate nella sezione Risorse di seguito. Queste risorse sono esempi di modelli di funzionalità forensi che abbiamo sviluppato e che i clienti hanno implementato. Costituiscono un'utile architettura di riferimento per iniziare, ma prendi in considerazione la possibilità di modificarli o creare nuovi modelli di automazione per le funzionalità forensi in base all'ambiente, ai requisiti, agli strumenti e ai processi forensi.
## Risorse
**Documenti correlati:**
+ [AWS Security Incident Response Guide - Develop Forensics Capabilities ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [AWS Security Incident Response Guide - Forensics Resources ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Forensic investigation environment strategies in the Cloud AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+ [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
+ [AWS Prescriptive Guidance - Automate incident response and forensics ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)
**Video correlati:**
+ [ Automatizzazione delle indagini e della risposta agli incidenti ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
**Esempi correlati:**
+ [ Automated Incident Response and Forensics Framework ](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [ Automated Forensics Orchestrator for Amazon EC2 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)
# SEC10-BP04 Sviluppo e test di playbook di risposta agli incidenti di sicurezza
Una parte fondamentale della preparazione dei processi di risposta agli incidenti è costituita dallo sviluppo di playbook. I playbook di risposta agli incidenti forniscono una serie di indicazioni prescrittive e di passaggi da seguire quando si verifica un evento di sicurezza. Avere una struttura e passaggi chiari semplifica la risposta e riduce la probabilità di errore umano.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
È necessario creare i playbook per scenari di incidenti come:
+ **Incidenti previsti**: i playbook devono essere creati per gli incidenti previsti. tra cui minacce come il Denial of Service (DoS), il ransomware e la compromissione delle credenziali.
+ **Avvisi o esiti di sicurezza noti**: i playbook devono essere creati per gli esiti e gli avvisi di sicurezza noti, ad esempio gli esiti GuardDuty. Potresti ricevere un risultato di GuardDuty e non sapere cosa fare. Per evitare di mal gestire o ignorare un risultato di GuardDuty, crea un playbook per ogni potenziale risultato di GuardDuty. I dettagli e le indicazioni sulla correzione sono disponibili nella [documentazione di GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). Vale la pena notare che GuardDuty non è abilitato per impostazione predefinita e comporta costi. Per maggiori dettagli su GuardDuty, consulta [Appendice A: Definizioni delle capacità del cloud - Visibilità e avvisi](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/visibility-and-alerting.html).
I playbook devono contenere i passaggi tecnici che un analista deve completare per indagare e rispondere adeguatamente a un potenziale incidente di sicurezza.
### Passaggi dell'implementazione
Gli elementi da includere in un playbook sono:
+ **Panoramica del playbook**: quale scenario di rischio o incidente affronta questo playbook? Qual è l'obiettivo del playbook?
+ **Prerequisiti**: quali log, meccanismi di rilevamento e strumenti automatizzati sono necessari per questo scenario di incidente? Qual è la notifica prevista?
+ **Informazioni sulla comunicazione e sull'escalation**: chi è coinvolto e quali sono le loro informazioni di contatto? Quali sono le responsabilità di ogni stakeholder?
+ **Fasi di risposta**: in tutti i passaggi per la risposta agli incidenti, quali misure tattiche devono essere prese? Quali query deve eseguire l'analista? Quale codice deve essere eseguito per ottenere il risultato desiderato?
+ **Individuazione**: come verrà rilevato l'incidente?
+ **Analisi**: come verrà determinato l'ambito dell'impatto?
+ **Contenimento**: come verrà isolato l'incidente per limitarne la portata?
+ **Sradicamento**: come verrà rimossa la minaccia dall'ambiente?
+ **Recupero**: 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?
## Risorse
**Best practice Well-Architected correlate:**
+ [SEC10-BP02 Sviluppo di piani di gestione degli incidenti](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
**Documenti correlati:**
+ [Framework for Incident Response Playbooks](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Develop your own Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)
+ [Incident Response Playbook Samples](https://github.com/aws-samples/aws-incident-response-playbooks)
+ [Building an AWS incident response runbook using Jupyter playbooks and CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)
# SEC10-BP05 Preassegnazione dell'accesso
Verifica che il team di risposta agli incidenti disponga degli opportuni diritti di accesso allocati in AWS per ridurre i tempi necessari per l'analisi e il ripristino.
**Anti-pattern comuni:**
+ L'utilizzo dell'account root per la risposta agli incidenti.
+ La modifica degli account utente esistenti.
+ La manipolazione diretta delle autorizzazioni IAM quando si fornisce l'elevazione dei privilegi just-in-time.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
AWS raccomanda di ridurre o eliminare, ove possibile, la dipendenza da credenziali di lunga durata, a favore delle credenziali temporanee e dei meccanismi di escalation dei privilegi *just-in-time* . Le credenziali di lunga durata sono soggette a rischi per la sicurezza e aumentano il sovraccarico operativo. Per la maggior parte delle attività di gestione, nonché per le attività di risposta agli incidenti, consigliamo di implementare [la federazione delle identità](https://docs.aws.amazon.com/identity/federation/) insieme [all'escalation temporanea per l'accesso amministrativo](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). In questo modello, un utente richiede l'elevazione a un livello di privilegio superiore (come un ruolo di risposta agli incidenti) e, se è idoneo all'elevazione, la richiesta viene inviata al responsabile dell'approvazione. Se la richiesta viene approvata, l'utente riceve un set di credenziali [AWS temporanee](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) che può utilizzare per eseguire le sue attività. Alla scadenza di queste credenziali, l'utente deve inviare una nuova richiesta di elevazione.
Si consiglia l'uso dell'escalation temporanea dei privilegi nella maggior parte degli scenari di risposta agli incidenti. Il modo corretto per farlo è utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) e [le policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) per definire l'ambito di accesso.
Esistono scenari in cui le identità federate non sono disponibili, come nei casi di:
+ Interruzione correlata a un gestore dell'identità digitale (IdP) compromesso.
+ Configurazione errata o errore umano che causa l'interruzione del sistema di gestione dell'accesso federato.
+ Attività dannose come un evento DDoS (Distributed Denial of Service) o indisponibilità del sistema.
Nei casi precedenti, si deve configurare un accesso di emergenza *di tipo break-glass* per consentire l'analisi e la tempestiva risoluzione degli incidenti. Ti consigliamo di utilizzare [un utente IAM con le autorizzazioni appropriate](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) per eseguire le attività e accedere alle risorse AWS. Utilizza le credenziali root solo per le [attività che richiedono l'accesso come utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Per verificare che i team di risposta agli incidenti dispongano del corretto livello di accesso ad AWS e ad altri sistemi pertinenti, ti consigliamo di eseguire la pre-assegnazione di account utente dedicati. Gli account utente richiedono l'accesso con privilegi e devono essere rigorosamente controllati e monitorati. Gli account devono essere creati con il minor numero di privilegi richiesti per eseguire le attività e il livello di accesso deve essere basato sui playbook inclusi nel piano di gestione degli incidenti.
Utilizza utenti e ruoli specifici e dedicati come best practice. L'escalation temporanea dell'accesso di utenti o ruoli tramite l'aggiunta di policy IAM rende poco chiaro quale fosse l'accesso degli utenti durante l'incidente e rischia di non revocare i privilegi oggetto di escalation.
È importante rimuovere il maggior numero possibile di dipendenze per verificare che sia possibile ottenere l'accesso nel maggior numero possibile di scenari di errore. Per supportare questa esigenza, crea un playbook per verificare che gli utenti dei team di risposta agli incidenti vengano creati come utenti AWS Identity and Access Management in un account di sicurezza dedicato e non gestiti tramite una federazione esistente o una soluzione di autenticazione unica (SSO). Ogni singolo utente dei team di risposta deve avere il proprio account denominato. La configurazione dell'account deve applicare [una policy di password complesse](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) e l'autenticazione a più fattori (MFA). Se i playbook di risposta agli incidenti richiedono solo l'accesso alla Console di gestione AWS, non è necessario che l'utente disponga di chiavi di accesso configurate né che sia esplicitamente autorizzato a creare chiavi di accesso. A tale scopo è possibile configurare le policy IAM o le policy di controllo dei servizi come menzionato in AWS Security Best Practices (Best practice di sicurezza AWS) per [le policy di controllo dei servizi AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Gli utenti non devono avere privilegi oltre la capacità di assumere i ruoli di risposta agli incidenti in altri account.
Durante un incidente potrebbe essere necessario concedere l'accesso ad altre persone interne o esterne per supportare le attività di analisi, correzione o ripristino. In questo caso, utilizza il meccanismo del playbook menzionato in precedenza e un processo per verificare che qualsiasi accesso aggiuntivo venga revocato immediatamente dopo il completamento dell'incidente.
Per verificare che l'uso dei ruoli di risposta agli incidenti possa essere adeguatamente monitorato e controllato, è essenziale che gli account utente IAM creati a tale scopo non siano condivisi tra le persone e che l'utente root Account AWS non venga utilizzato se [non per un'attività specifica](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Se è richiesto l'utente root (ad esempio, l'accesso IAM a un account specifico non è disponibile), utilizza un processo separato con un playbook disponibile per verificare la disponibilità della password dell'utente root e del token MFA.
Per configurare le policy IAM per i ruoli di risposta agli incidenti, prendi in considerazione di usare [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) per generare le policy sulla base dei log AWS CloudTrail. In questo caso, concedi l'accesso come amministratore al ruolo di risposta agli incidenti per un account non di produzione ed esegui i playbook. Al termine, potrà essere creata una policy che consenta solo le azioni da intraprendere. Questa policy può quindi essere applicata a tutti i ruoli di risposta agli incidenti in tutti gli account. Puoi anche creare una policy IAM separata per ogni playbook per avere una gestione e un controllo più semplici. Esempi di playbook possono essere piani di risposta per ransomware, violazioni dei dati, perdita dell'accesso alla produzione e altri scenari.
Utilizza gli account utente di risposta agli incidenti per assumere i ruoli di risposta [IAM dedicati in altri Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Questi ruoli devono essere configurati in modo che possano essere assunti solo dagli utenti nell'account di sicurezza e la relazione di trust deve richiedere che il principale chiamante sia autenticato tramite MFA. I ruoli devono utilizzare policy IAM con ambito limitato per controllare l'accesso. Assicurati che tutte le richieste `AssumeRole` per questi ruoli vengano registrate in CloudTrail e notificate e che tutte le azioni intraprese utilizzando questi ruoli vengano registrate.
Ti consigliamo vivamente di nominare chiaramente gli account utente IAM e i ruoli IAM per trovarli facilmente nei log CloudTrail. Un esempio potrebbe essere quello di nominare gli account IAM `-BREAK-GLASS` e i ruoli IAM `RUOLO-BREAK-GLASS`.
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) viene utilizzato per registrare l'attività API negli account AWS e deve essere utilizzato per [configurare gli avvisi sull'utilizzo dei ruoli di risposta agli incidenti](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Fai riferimento al post del blog sulla configurazione degli avvisi quando vengono utilizzate le chiavi root. Le istruzioni possono essere modificate per configurare il parametro [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) da filtro a filtro negli eventi `AssumeRole` correlati al ruolo IAM di risposta agli incidenti:
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```
Poiché è probabile che i ruoli di risposta agli incidenti abbiano un livello di accesso elevato, è importante che questi avvisi vengano inviati a un gruppo ampio e vengano gestiti tempestivamente.
Durante un incidente, è possibile che un membro del team di risposta richieda l'accesso a sistemi che non sono direttamente protetti da IAM, ad esempio istanze Amazon Elastic Compute Cloud, database Amazon Relational Database Service o piattaforme Software-as-a-service (SaaS). Anziché i protocolli nativi come SSH o RDP, ti consigliamo vivamente di utilizzare [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) per l'accesso amministrativo completo alle istanze Amazon EC2. Questo accesso può essere monitorato utilizzando IAM, che è sicuro e controllato. Puoi anche automatizzare parti dei tuoi playbook utilizzando i documenti di [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)che possono ridurre gli errori dell'utente e migliorare i tempi di ripristino. Per l'accesso a database e strumenti di terze parti, ti consigliamo di archiviare le credenziali di accesso in Gestione dei segreti AWS e di concedere l'accesso ai ruoli degli utenti dei team di risposta agli incidenti.
Infine, la gestione degli account utente IAM di risposta agli incidenti deve essere aggiunta ai processi [degli utenti che si uniscono, si spostano o lasciano l'organizzazione](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) e deve rivista e testata periodicamente per verificare che sia consentito solo l'accesso previsto.
## Risorse
**Documenti correlati:**
+ [Managing temporary elevated access to your AWS environment (Gestione dell'accesso temporaneo con privilegi elevati all'ambiente AWS)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [Impostazione di una policy delle password dell'account per utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Utilizzo dell'autenticazione a più fattori (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)
+ [ Configuring Cross-Account Access with MFA (Configurazione dell'accesso multi-account con MFA) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies (Utilizzo di IAM Access Analyzer per generare policy IAM) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (Best practice per le policy di controllo dei servizi di AWS Organizations in un ambiente multi-account) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (Come ricevere le notifiche quando vengono utilizzate le chiavi di accesso root dell'account AWS) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Create fine-grained session permissions using IAM managed policies (Creazione di autorizzazioni di sessione dettagliate utilizzando le policy gestite da IAM) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
**Video correlati:**
+ [ Automating Incident Response and ForensicsAWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+ [DIY guide to runbooks, incident reports, and incident response](https://youtu.be/E1NaYN_fJUo)
+ [ Prepare for and respond to security incidents in your AWS environment ](https://www.youtube.com/watch?v=8uiO0Z5meCs)
**Esempi correlati:**
+ [ Lab: AWS Account Setup and Root User (Laboratorio: configurazione dell'account AWS e dell'utente root) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Lab: Incident Response with AWS Console and CLI (Laboratorio: risposta agli incidenti con la Console AWS e l'interfaccia della riga di comando) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)
# SEC10-BP06 Distribuzione anticipata degli strumenti
Verifica che il team addetto alla sicurezza disponga degli strumenti giusti pre-distribuiti per ridurre i tempi di indagine fino al ripristino.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Per automatizzare le funzioni delle operazioni e la risposta di sicurezza, puoi utilizzare un set completo di API e strumenti AWS. Puoi automatizzare completamente le funzionalità di gestione delle identità, sicurezza della rete, protezione dei dati e monitoraggio e distribuirle utilizzando metodi di sviluppo software comuni già esistenti. Quando crei l'automazione della sicurezza, il sistema può monitorare, rivedere e avviare una risposta, invece di far monitorare alle persone il comportamento di sicurezza e reagire manualmente agli eventi.
Se i team di risposta agli incidenti continuano a rispondere agli avvisi nello stesso modo, rischiano il cosiddetto affaticamento dagli avvisi ("alert fatigue"). Ciò significa che, nel corso del tempo, il team può diventare desensibilizzato agli avvisi e può commettere errori nella gestione di situazioni ordinarie o farsi sfuggire avvisi insoliti. L'automazione aiuta a evitare l'affaticamento dagli avvisi utilizzando funzioni che elaborano gli avvisi ripetitivi e ordinari, lasciando alle persone la gestione degli incidenti sensibili e univoci. Se si integrano sistemi di rilevamento delle anomalie, come Amazon GuardDuty, AWS CloudTrail Insights e Amazon CloudWatch Anomaly Detection, è possibile ridurre l'impatto di avvisi frequenti basati su soglie.
Puoi migliorare i processi manuali automatizzando le fasi del processo a livello di programmazione. Dopo aver definito il modello di correzione di un evento, puoi decomporre tale modello in una logica fruibile e scrivere il codice per eseguire tale logica. Il team addetto alla risposta può quindi eseguire il codice per risolvere il problema. Nel corso del tempo, puoi automatizzare più fasi e, infine, gestire automaticamente intere classi di incidenti comuni.
Durante un'indagine di sicurezza, devi essere in grado di esaminare i log pertinenti per registrare e comprendere l'intera portata e la tempistica dell'incidente. I log sono necessari anche per la generazione di avvisi, che indicano che sono avvenute determinate azioni di interesse. È fondamentale selezionare, attivare, memorizzare e impostare i meccanismi di query e recupero e impostare gli avvisi. Inoltre, un modo efficace per fornire gli strumenti per la ricerca nei dati di log è [Amazon Detective](https://aws.amazon.com/detective/).
AWS offre oltre 200 servizi cloud e migliaia di funzionalità. Ti consigliamo di esaminare i servizi che possono supportare e semplificare la tua strategia di risposta agli incidenti.
Oltre ai log, è necessario sviluppare e implementare una [strategia di applicazione dei tag](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). L'applicazione dei tag può aiutare a fornire il contesto per lo scopo di una risorsa AWS. I tag può essere utilizzati anche per l'automazione.
### Passaggi dell'implementazione
**Seleziona e configura i log per l'analisi e gli avvisi**
Consulta la seguente documentazione sulla configurazione dei log per la risposta agli incidenti:
+ [ Logging strategies for security incident response ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [SEC04-BP01 Configurazione dei registri di servizi e applicazioni](sec_detect_investigate_events_app_service_logging.md)
**Abilitazione dei servizi di sicurezza per supportare il rilevamento e la risposta**
AWS offre funzionalità investigative, preventive e reattive native e altri servizi che possono essere utilizzati per progettare soluzioni di sicurezza personalizzate. Per un elenco dei servizi più pertinenti per la risposta agli incidenti di sicurezza, consulta [Definizioni delle capacità del cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html).
**Sviluppa e implementa una strategia di tag**
Ottenere informazioni contestuali sul caso d'uso aziendale e sugli stakeholder interni pertinenti relativi a una risorsa AWS può essere difficile. Un modo per farlo è rappresentato dai tag che assegnano i metadati alle risorse AWS e sono composti da una chiave e un valore definiti dall'utente. Puoi creare i tag per classificare le risorse per scopo, proprietario, ambiente, tipo di dati elaborati e altri criteri di tua scelta.
Avere una strategia di tag coerente può accelerare le risposta e ridurre al minimo il tempo dedicato al contesto organizzativo, consentendo di identificare e discernere rapidamente le informazioni contestuali su una risorsa AWS. I tag possono anche fungere da meccanismo per avviare le automazioni di risposta. Per maggiori dettagli su cosa etichettare, consulta [Etichettare le tue risorse AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Dovrai prima definire i tag nella tua organizzazione e quindi implementare e applicare questa strategia di tag. Per maggiori dettagli sull'implementazione e l'applicazione, consulta [Implementa una strategia di etichettatura delle risorse AWS utilizzando AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/).
## Risorse
**Best practice Well-Architected correlate:**
+ [SEC04-BP01 Configurazione dei registri di servizi e applicazioni](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Analisi di log, risultati e parametri a livello centrale](sec_detect_investigate_events_analyze_all.md)
**Documenti correlati:**
+ [ Logging strategies for security incident response ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Incident response cloud capability definitions ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)
**Esempi correlati:**
+ [ Threat Detection and Response with Amazon GuardDuty and Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Security Hub Workshop ](https://catalog.workshops.aws/security-hub/en-US)
+ [ Vulnerability Management with Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)
# SEC10-BP07 Esecuzione di simulazioni
Man mano che le organizzazioni crescono e si evolvono nel tempo, aumentano anche le tipologie di minacce. Per questo motivo, è importante rivedere continuamente le capacità di risposta agli incidenti. L'esecuzione di simulazioni (note anche come giornate di gioco) è un metodo che può essere utilizzato per eseguire questa valutazione. Le simulazioni utilizzano scenari di eventi di sicurezza reali progettati per simulare le tattiche, le tecniche e le procedure (TTP) di un autore di minacce e consentire a un'organizzazione di esercitarsi e valutare le proprie capacità di risposta agli incidenti rispondendo a questi finti eventi informatici così come potrebbero verificarsi nella realtà.
**Vantaggi dell'adozione di questa best practice:** le simulazioni offrono una serie di vantaggi:
+ 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.
**Livello di rischio associato alla mancata adozione di questa best practice:** medio
## Guida all'implementazione
Esistono tre tipi principali di simulazioni:
+ **Simulazioni di situazioni di emergenza:** le simulazioni di situazioni di emergenza sono sessioni basate sulla discussione che coinvolgono le varie parti interessate alla risposta agli incidenti per mettere in pratica ruoli e responsabilità e utilizzare strumenti e playbook di comunicazione consolidati. Lo svolgimento dell'esercitazione può in genere essere eseguito in un'intera giornata in un luogo virtuale, in un luogo fisico o in una combinazione di questi tipi di luogo. Poiché è basato sulla discussione, questo tipo di esercitazione si concentra su processi, persone e collaborazione. La tecnologia è parte integrante della discussione, ma l'uso effettivo di strumenti o script di risposta agli incidenti in genere non rientra in questo tipo di simulazione.
+ **Esercizi del team viola:** questo tipo di esercitazioni aumenta il livello di collaborazione tra i team di risposta agli incidenti (team blu) e gli attori delle minacce simulate (team rosso). Il team blu è composto da membri del Security Operations Center (SOC), ma può includere anche altre parti interessate che sarebbero coinvolte durante un vero e proprio evento informatico. Il team rosso è composto da un team responsabile dei test di penetrazione (pen-test) o da parti interessate chiave esperte in materia di sicurezza informatica. Il team rosso lavora assieme ai coordinatori dell'esercitazione durante la progettazione di uno scenario in modo che lo scenario sia accurato e fattibile. Durante le esercitazioni del team viola, l'attenzione è rivolta principalmente ai meccanismi di rilevamento, agli strumenti e alle procedure operative standard (SOP) a supporto della risposta agli incidenti.
+ **Esercizi del team rosso:** durante un'esercitazione con il team rosso, l'attacco (team rosso) effettua una simulazione per raggiungere un determinato obiettivo o una serie di obiettivi da un ambito predeterminato. I difensori (team blu) non saranno necessariamente a conoscenza della portata e della durata dell'esercitazione, il che fornisce una valutazione più realistica di come risponderebbero a un incidente reale. Poiché le esercitazioni del team rosso possono basarsi su test invasivi, sii cauto e implementa controlli per verificare che l'esercitazione non causi danni effettivi all'ambiente.
Prendi in considerazione la possibilità di svolgere simulazioni informatiche a intervalli regolari. Ogni tipo di esercitazione può offrire vantaggi unici ai partecipanti e all'organizzazione nel suo insieme; potresti, quindi, scegliere di iniziare con tipi di simulazione meno complessi (come le simulazioni di situazioni di emergenza) e passare a tipi di simulazione più complessi (esercitazioni del team rosso). È necessario selezionare un tipo di simulazione in base alla maturità, alle risorse e ai risultati desiderati a livello di sicurezza. Alcuni clienti potrebbero scegliere di non eseguire le esercitazioni del team rosso a causa della loro complessità e dei loro costi.
## Passaggi dell'implementazione
Indipendentemente dal tipo di simulazione scelto, le simulazioni sono in genere caratterizzate dai seguenti passaggi di implementazione:
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 esercizio richiede la presenza di facilitatori e partecipanti. A seconda dello scenario, potrebbero essere coinvolte altre parti interessate come la leadership legale, delle comunicazioni o esecutiva.
1. **Crea ed esegui il test dello scenario:** potrebbe essere necessario ridefinire lo scenario durante la creazione se risulta impossibile implementare elementi specifici. Come risultato di questa fase è previsto uno scenario definitivo.
1. **Facilita la simulazione:** il tipo di simulazione determina il tipo di svolgimento usato (uno scenario basato su supporto cartaceo o uno scenario con simulazione altamente tecnologica). 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 report post-azione (AAR):** individua 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.
## Risorse
**Documenti correlati:**
+ [AWS Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Video correlati:**
+ [AWS GameDay - Security Edition](https://www.youtube.com/watch?v=XnfDWID_OQs)
# SEC10-BP08 Definizione di un framework per apprendere dagli incidenti
L'implementazione di un *framework basato sulle lezioni apprese* e di una capacità di analisi delle cause principali non solo contribuisce a migliorare le capacità di risposta agli incidenti, ma aiuta anche a prevenire il ripetersi dell'incidente. Imparando da ogni incidente, puoi evitare di ripetere gli errori, i rischi o le configurazioni non valide, non solo migliorando il tuo livello di sicurezza, ma anche riducendo al minimo il tempo speso in situazioni evitabili.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
È importante implementare un *framework basato sulle lezioni apprese* che stabilisce e raggiunge, ad alto livello, i seguenti punti:
+ Quando si tiene un framework basato sulle lezioni apprese?
+ Cosa comporta il processo basato sulle lezioni apprese?
+ Come viene eseguito un framework basato sulle lezioni apprese?
+ Chi è coinvolto nel processo e in che modo?
+ Come vengono identificate le aree di miglioramento?
+ In che modo garantisci che i miglioramenti vengano monitorati e implementati in modo efficace?
Il framework non deve concentrarsi sugli individui, ma sul miglioramento di strumenti e processi.
### Passaggi dell'implementazione
A parte i risultati di alto livello sopra elencati, è importante porsi le domande giuste per trarre il massimo valore (informazioni che portano a miglioramenti attuabili) dal processo. Considera queste domande per iniziare a promuovere le discussioni sulle lezioni apprese:
+ Qual è stato l'incidente?
+ Quando è stato identificato per la prima volta l'incidente?
+ Come è stato identificato?
+ Quali sistemi hanno avvisato dell'attività?
+ Quali sistemi, servizi e dati sono stati coinvolti?
+ Cosa è successo nello specifico?
+ Cosa ha funzionato bene?
+ Cosa non ha funzionato bene?
+ Quale processo o quali procedure non sono riusciti a dimensionare per rispondere all'incidente?
+ Cosa può essere migliorato nelle seguenti aree:
+ **Persone**
+ Le persone da contattare erano effettivamente disponibili e l'elenco dei contatti era aggiornato?
+ Il personale presentava lacune nella formazione o nelle capacità necessarie per rispondere e indagare efficacemente sull'incidente?
+ Le risorse appropriate erano pronte e disponibili?
+ **Elaborazione**
+ Sono stati seguiti i processi e le procedure?
+ I processi e le procedure erano documentati e disponibili per questo tipo di incidente?
+ Mancavano i processi e le procedure richiesti?
+ Il team di risposta è stato in grado di accedere tempestivamente alle informazioni necessarie per rispondere al problema?
+ **Tecnologia**
+ I sistemi di avviso esistenti hanno identificato e segnalato efficacemente l'attività?
+ Come si sarebbe potuto ridurre il tempo di rilevamento del 50%?
+ Gli avvisi esistenti devono essere migliorati o è necessario creare nuovi avvisi per questo tipo di incidente?
+ Gli strumenti esistenti hanno consentito un'indagine efficace (ricerca/analisi) dell'incidente?
+ Cosa si può fare per identificare prima questo tipo di incidente?
+ Cosa si può fare per evitare che questo tipo di incidente si ripeta?
+ A chi appartiene il piano di miglioramento e come verifichi che sia stato implementato?
+ Qual è la tempistica per l'implementazione e il test del monitoraggio aggiuntivo o dei controlli e dei processi preventivi?
Questo elenco non è esaustivo, ma può fungere da punto di partenza per individuare quali sono le esigenze dell'organizzazione e dell'attività e come analizzarle per imparare in modo più efficace dagli incidenti e migliorare costantemente il proprio livello di sicurezza. La cosa più importante è iniziare incorporando le lezioni apprese come parte standard del processo di risposta agli incidenti, della documentazione e delle aspettative di tutti gli stakeholder.
## Risorse
**Documenti correlati:**
+ [AWS Security Incident Response Guide - Establish a framework for learning from incidents](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/establish-framework-for-learning.html)
+ [NCSC CAF guidance - Lessons learned](https://www.ncsc.gov.uk/collection/caf/caf-principles-and-guidance/d-2-lessons-learned)