# Preparazione
Essere preparati per affrontare un incidente è fondamentale per fornire una risposta tempestiva ed efficace. La preparazione viene effettuata in tre ambiti:
+ **Persone**: la preparazione del personale per un incidente di sicurezza implica l'identificazione delle persone responsabili della risposta agli incidenti e la loro formazione in merito alle modalità di risposta e alle tecnologie cloud.
+ **Processi**: la preparazione in termini di processi per un incidente di sicurezza implica la conoscenza della documentazione delle architetture, lo sviluppo di piani di risposta agli incidenti completi e la creazione di playbook per una risposta coerente agli eventi di sicurezza.
+ **Tecnologia**: la preparazione in termini di tecnologia per un incidente di sicurezza implica la configurazione dell'accesso, l'aggregazione e il monitoraggio dei log necessari, l'implementazione di meccanismi di avviso efficaci e lo sviluppo di capacità di risposta e di indagine.
Ciascuno di questi domini è importante per una risposta efficace agli imprevisti. Nessun programma di risposta agli imprevisti è completo o efficace senza tutti e tre. Una preparazione agli incidenti può dirsi efficace solo se le persone, i processi e le tecnologie sono stati preparati in maniera adeguata e integrata.
**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 Implementazione anticipata degli strumenti](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Esecuzione di simulazioni](sec_incident_response_run_game_days.md)
# SEC10-BP01 Identificazione del personale chiave e delle risorse esterne
Identifica personale, risorse e requisiti legali interni ed esterni per consentire all'organizzazione a rispondere a un incidente.
**Risultato desiderato:** presenza di un elenco del personale chiave, delle relative informazioni di contatto e dei ruoli svolti nel rispondere a un evento di sicurezza. Rivedi queste informazioni con regolarità e aggiornarle per riflettere i cambiamenti del personale dal punto di vista degli strumenti interni ed esterni. Nel documentare queste informazioni, prendi in considerazione tutti i fornitori di servizi e i venditori di terze parti, compresi partner di sicurezza, fornitori di cloud e applicazioni software-as-a-service (SaaS). Durante un evento di sicurezza, il personale è disponibile con il livello di responsabilità, il contesto e l'accesso appropriati per poter rispondere ed eseguire il ripristino.
**Anti-pattern comuni:**
+ Mancata tenuta di un elenco aggiornato del personale chiave con le informazioni di contatto, i ruoli e le responsabilità in caso di risposta a eventi di sicurezza.
+ Si presume che tutti conoscano persone, dipendenze, infrastruttura e soluzioni per rispondere a un evento ed eseguire il ripristino dopo lo stesso.
+ Mancata predisposizione di un archivio di documenti o conoscenze che rappresenti l'infrastruttura o la progettazione di applicazioni chiave.
+ Mancata predisposizione di processi di onboarding adeguati per i nuovi dipendenti, in modo che possano contribuire in modo efficace alla risposta a un evento di sicurezza, come la realizzazione di simulazioni di eventi.
+ Mancata predisposizione di un percorso di escalation quando il personale chiave è temporaneamente non disponibile o non risponde durante gli eventi di sicurezza.
**Vantaggi dell'adozione di questa best practice:** riduzione del tempo di valutazione e risposta impiegato per identificare il personale giusto e il relativo ruolo durante un evento grazie a questa pratica. Riduci al minimo le perdite di tempo durante un evento mantenendo un elenco aggiornato del personale chiave e dei relativi ruoli, in modo da poter portare le persone giuste al triage e al ripristino da un evento.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
**Identifica il personale chiave all'interno dell'organizzazione:** conserva un elenco di contatti del personale interno alla tua organizzazione che potrebbe essere necessario coinvolgere. Rivedi e aggiorna in modo regolare queste informazioni in caso di spostamento del personale, quali modifiche organizzative, promozioni e cambi di team. Questo è particolarmente importante per i ruoli chiave come gli incident manager, i team di risposta e i responsabili delle comunicazioni.
+ **Responsabile degli incidenti:** i responsabili degli incidenti dispongono dell'autorità generale durante la risposta all'evento.
+ **Persone che intervengono dopo un incidente:** le persone che intervengono dopo un incidente sono responsabili delle attività di indagine e correzione. Queste persone possono differire in base al tipo di evento, ma in genere sono sviluppatori e team operativi responsabili dell'applicazione interessata.
+ **Responsabile delle comunicazioni:** il responsabile delle comunicazioni gestisce comunicazioni interne ed esterne, in particolare con gli enti pubblici, le autorità di regolamentazione e i clienti.
+ **Processo di onboarding:** attività periodiche di formazione e onboarding per i nuovi dipendenti, mirate a fornire le competenze e le conoscenze necessarie per dare un contributo efficace alle iniziative di risposta agli incidenti. Include simulazioni ed esercizi pratici nell'ambito del processo di onboarding per facilitarne la preparazione.
+ **Esperti in materia (SME):** in caso di team distribuiti e autonomi, ti consigliamo di identificare un SME per carichi di lavoro mission critical. Queste persone offrono approfondimenti su funzionamento e classificazione dei dati dei carichi di lavoro critici coinvolti nell'evento.
Formato di tabella di esempio:
```
| Role | Name | Contact Information | Responsibilities |
1 | ——– | ——- | ——- | ——- |
2 | Incident Manager | Jane Doe| jane.doe@example.com | Overall authority during response |
3 | Incident Responder | John Smith | john.smith@example.com | Investigation and remediation |
4 | Communications Lead | Emily Johnson | emily.johnson@example.com | Internal and external communications |
5 | Communications Lead | Michael Brown | michael.brown@example.com | Insights on critical workloads |
```
Prendi in considerazione l'utilizzo della funzionalità [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) per l'acquisizione dei contatti chiave, la definizione di un piano di risposta, l'automazione degli orari delle chiamate e la creazione di piani di escalation. Automatizza e organizza i turni per tutto il personale attraverso un programma di chiamata, in modo che la responsabilità del carico di lavoro sia condivisa tra i proprietari. Ciò promuove buone pratiche, come l'emissione di metriche e log pertinenti e la definizione di soglie di allarme importanti per il carico di lavoro.
**Identifica i partner esterni:** le aziende utilizzano strumenti creati da fornitori di software indipendenti (ISV), partner e subappaltatori per creare soluzioni differenziate per i propri clienti. Coinvolgi il personale chiave di queste parti che può aiutarti a rispondere e a eseguire il ripristino dopo un incidente. Ti consigliamo di iscriverti al livello appropriato di Supporto per ottenere un rapido accesso agli SME AWS attraverso un caso di supporto. Prendi in considerazione accordi simili con tutti i fornitori di soluzioni critiche per i carichi di lavoro. Alcuni eventi di sicurezza richiedono alle aziende quotate in borsa di notificare evento ed effetti agli enti pubblici e alle autorità di regolamentazione pertinenti. Mantieni e aggiorna le informazioni di contatto per i dipartimenti pertinenti e le persone responsabili.
## Passaggi dell'implementazione
1. Configura una soluzione per la gestione degli incidenti.
1. Prendi in considerazione l'implementazione di Incident Manager nel tuo account Security Tooling.
1. Definisci i contatti nella tua soluzione di gestione degli incidenti.
1. Definisci almeno due tipi di canali per ogni contatto (come SMS, telefono o e-mail), per garantire la raggiungibilità durante un incidente.
1. Definisci un piano di risposta.
1. Identifica i contatti più opportuni da coinvolgere durante un incidente. Definisci piani di escalation in linea con i ruoli del personale da coinvolgere, piuttosto che con i singoli contatti. Valuta la possibilità di includere i contatti che potrebbero essere responsabili dell'informare entità esterne, anche se non direttamente coinvolti nella risoluzione dell'incidente.
## Risorse
**Best practice correlate:**
+ [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_ops_model_def_activity_owners.html)
**Documenti correlati:**
+ [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Esempi correlati:**
+ [AWS Framework per playbook per i clienti](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Prepare for and respond to security incidents in your AWS environment](https://youtu.be/8uiO0Z5meCs)
**Strumenti correlati:**
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
**Video correlati:**
+ [Amazon's approach to security during development](https:/www.youtube.com/watch?v=NeR7FhHqDGQ)
# SEC10-BP02 Sviluppo di piani di gestione degli incidenti
Il primo documento da predisporre 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 definiti in modo chiaro è 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 agevoleranno una risposta tempestiva. Potrebbero essere già presenti processi di risposta agli incidenti. Indipendentemente dallo stato attuale, è importante aggiornare, iterare e testare con regolarità i processi di risposta agli incidenti.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Un piano di gestione degli incidenti è fondamentale per rispondere, mitigare ed eseguire il ripristino a seguito del potenziale impatto degli incidenti di sicurezza. Un piano di gestione degli incidenti è un processo strutturato volto a identificare, correggere e rispondere tempestivamente agli incidenti di sicurezza.
Il cloud presenta molti degli stessi ruoli e requisiti operativi che si trovano in un ambiente on-premises. Nella creazione di un piano di gestione degli incidenti, è importante tenere conto delle strategie di risposta e ripristino ideali per i risultati aziendali e ai requisiti di conformità. Ad esempio, se gestisci carichi di lavoro in AWS conformi a FedRAMP negli Stati Uniti, occorre seguire le raccomandazioni enunciate nel documento [NIST SP 800-61 Computer Security Handling Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Allo stesso modo, quando gestisci carichi di lavoro che memorizzano informazioni di identificazione personale (PII), valuta come proteggere e rispondere ai problemi relativi alla residenza e all’utilizzo dei dati.
Quando crei un piano di gestione degli incidenti per i tuoi 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 approfondito alla 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](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) illustra concetti chiave e linee guida di base per la creazione di un piano di gestione degli incidenti incentrato sul cloud.
Un piano di gestione degli incidenti efficace va iterato in modo continuo per rimanere in linea con l’obiettivo delle operazioni cloud. Prendi in considerazione l’utilizzo dei piani di implementazione illustrati di seguito durante la creazione e l’evoluzione del tuo piano di gestione degli incidenti.
### Passaggi dell’implementazione
1. Definisci ruoli e responsabilità all’interno dell’organizzazione per la gestione degli eventi di sicurezza. Il processo dovrebbe coinvolgere rappresentanti di vari dipartimenti, tra cui:
+ Risorse umane (HR)
+ Team esecutivo
+ Ufficio legale
+ Proprietari e sviluppatori di applicazioni (SME, ossia esperti in materia)
1. Determina in modo chiaro i soggetti RACI (Responsible, Accountable, Consulted, and Informed) da tenere in considerazione in caso di incidente. Crea un grafico RACI per facilitare una comunicazione rapida e diretta, e delinea chiaramente la leadership nelle diverse fasi di un evento.
1. Coinvolgi i proprietari e gli sviluppatori delle applicazioni (SME) durante un incidente, poiché tali soggetti possono fornire informazioni e contesto preziosi per aiutare a misurare l’impatto. Instaura relazioni con questi SME e fai pratica con loro utilizzando vari scenari di risposta agli incidenti prima che si verifichi un incidente reale.
1. Coinvolgi partner attendibili o esperti esterni nel processo di indagine o risposta, poiché tali soggetti possono fornire competenze e prospettive aggiuntive.
1. Allinea i piani e i ruoli di gestione degli incidenti alle normative locali o ai requisiti di conformità che regolano la tua organizzazione.
1. Effettua regolarmente esercitazioni pratiche e test sui piani di risposta agli incidenti, coinvolgendo tutti i ruoli e le responsabilità definiti. Questo aiuta a semplificare il processo e ad assicurarsi di avere una risposta coordinata ed efficiente agli incidenti di sicurezza.
1. Rivedi e aggiorna i ruoli, le responsabilità e il grafico RACI periodicamente o man mano che la struttura organizzativa o i requisiti cambiano.
**Analizza il supporto e i team di risposta di AWS**
+ **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 ti occorre supporto tecnico e 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.
+ Considera il [Centro supporto](https://console.aws.amazon.com/support) in Console di gestione AWS (è richiesto l’accesso) come punto di contatto centralizzato per assistenza circa problemi relativi alle tue risorse AWS. L’accesso a Supporto è controllato da AWS Identity and Access Management. Per ulteriori informazioni sull’accesso alle funzionalità Supporto, consulta [Getting started with Supporto](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
+ **AWS Team di risposta agli incidenti dei clienti (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 di 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 su AWS. Può fornire assistenza nell’analisi delle cause principali grazie all’uso dei log dei servizi AWS e fornire suggerimenti per il ripristino. Può altresì fornire consigli e best practice sulla sicurezza così da evitare eventi di sicurezza in futuro.
+ I clienti AWS possono rivolgersi al team AWS CIRT attraverso un [caso Supporto](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
+ [https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)
+ Annunciato al re:Invent 2024, AWS Security Incident Response è un servizio gestito di risposta agli incidenti di sicurezza che utilizza sia la moderna tecnologia di triage che un operatore umano presente nel loop. Il servizio acquisisce tutti gli esiti di GuardDuty e tutti gli esiti di terze parti inviati a AWS Security Hub CSPM per la valutazione al fine di avvisare il cliente solo degli esiti che richiedono un’indagine. Il servizio fornisce anche un portale per presentare casi reattivi in caso di un evento di sicurezza notato dal cliente e ricevere supporto dal team di risposta avanzata agli incidenti di AWS.
+ **Supporto per la risposta agli attacchi DDoS**
+ AWS offre [AWS Shield](https://aws.amazon.com/shield/), un servizio gestito di protezione da attacchi di tipo DDoS (Distributed Denial of Service) che protegge le applicazioni Web in esecuzione in AWS. Shield fornisce un rilevamento continuo e prevenzione incorporata automatica che riducono al minimo il tempo di inattività e la latenza dell’applicazione, così da non dover rivolgersi al Supporto per beneficiare della protezione DDoS. I livelli esistenti di Shield sono due: AWS Shield Standard e AWS Shield Advanced. Per maggiori informazioni sulle differenze tra questi due livelli, consulta la [documentazione della funzionalità Shield](https://aws.amazon.com/shield/features/).
+ **AWS Managed Services (AMS)**
+ [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) offre una gestione continua dell’infrastruttura AWS, così potrai concentrarti solo sulle tue applicazioni. Grazie all’implementazione di best practice per la manutenzione dell’infrastruttura, AMS consente di ridurre rischi e costi operativi. 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. In caso di avviso, AMS si attiene a 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 obiettivi e funzioni del team di risposta agli incidenti.
+ **Ruoli e responsabilità:** indica le parti interessate alla risposta agli incidenti e illustra in dettaglio i loro ruoli in caso di incidente.
+ **Un piano di comunicazione:** fornisce dettagli sulle informazioni di contatto e sulle tue modalità di comunicazione 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:** elenca 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 assegnazione della priorità agli incidenti:** illustra in dettaglio come classificare la gravità di un incidente, le modalità di assegnazione della 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. Devi creare un piano di risposta agli incidenti che funzioni al meglio per la tua organizzazione.
## Risorse
**Best practice correlate:**
+ [SEC04 Rilevamento](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documenti correlati:**
+ [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [ NIST: Computer Security Incident Handling Guide ](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 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-premises 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 ambiente e struttura di Account AWS per le funzionalità forensi, definisci le tecnologie necessarie in modo da eseguire in modo ottimale le metodologie forensi in quattro fasi:
+ **Raccolta:** raccogli 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:** analizza i dati raccolti per comprendere l'incidente e trarre le conclusioni.
+ **Creazione di report:** 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 dirigere a livello centrale un ambiente AWS mentre le risorse AWS crescono e scalano. Un'organizzazione AWS consolida gli Account AWS in modo da poterli amministrare come una singola unità. Puoi utilizzare le unità organizzative (UO) 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 un'*unità organizzativa di sicurezza* e un'*unità organizzativa con funzionalità forensi*. 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 con funzionalità forensi, puoi implementare uno o più account con funzionalità forensi per ciascuna regione in cui operi, a seconda di quale è più adatta all'azienda e al modello operativo. Se crei un account con funzionalità forensi per regione, puoi bloccare la creazione di risorse AWS al di fuori della regione e ridurre il rischio di copia delle risorse in una regione indesiderata. Ad esempio, se operi solo nella regione degli Stati Uniti orientali (Virginia settentrionale) (`us-east-1`) e Stati Uniti occidentali (Oregon) (`us-west-2`), nell'unità organizzativa con funzionalità forensi avrai due account: uno per `us-east-1` e uno per `us-west-2`.
Puoi creare un Account AWS con funzionalità forensi per più regioni. Quando si copiano le risorse AWS nell'account, presta attenzione a rispettare i requisiti di sovranità dei dati. Poiché la creazione di nuovi account richiede tempo, è fondamentale creare e fornire gli strumenti adatti agli account con funzionalità forensi con largo anticipo rispetto agli incidenti, in modo che gli addetti siano preparati a utilizzarli in modo efficace per la risposta.
Il diagramma seguente mostra una struttura degli account di esempio che include un'unità organizzativa con funzionalità forensi con account con 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 con funzionalità forensi.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/security-pillar/images/region-account-structure.png)
**Acquisizione di backup e snapshot**
La configurazione dei backup di sistemi e database importanti è fondamentale per il ripristino da un incidente di sicurezza e per scopi forensi. Grazie ai 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 offrono supporto nelle operazioni di backup e ripristino. Per informazioni dettagliate su questi servizi e approcci per il backup e il ripristino, consulta la [guida prescrittiva per il backup e il ripristino](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) e [Use backups to recover from security incidents](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, consulta [Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Oltre a proteggere i backup, è necessario sottoporli regolarmente a processi di backup e ripristino per verificare che tecnologia e 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 istanze e account sono numerosi. Inoltre, la raccolta manuale può essere soggetta all'errore umano. Per questi motivi, occorre 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 più avanti. Queste risorse sono esempi di modelli di funzionalità forensi che abbiamo sviluppato, implementate dai clienti Sebbene costituiscano un'utile architettura di riferimento per iniziare, prendi in considerazione la possibilità di modificarli o creare nuovi modelli di automazione per le funzionalità forensi in base ad ambiente, requisiti, strumenti e 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:**
+ [ Automating Incident Response and Forensics ](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 dalla predisposizione di playbook. I playbook di risposta agli incidenti forniscono indicazioni prescrittive e passaggi da seguire in caso di evento di sicurezza. Una struttura e passaggi chiari semplificano la risposta e riducono 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 Denial of Service (DoS), ransomware e la compromissione delle credenziali.
+ **Avvisi o esiti di sicurezza noti**: i playbook devono essere creati per affrontare gli esiti e gli avvisi di sicurezza noti, ad esempio quelli di Amazon GuardDuty. Quando ricevi un esito di GuardDuty, il playbook dovrebbe fornire istruzioni chiare per evitare che l’avviso venga gestito in modo errato o ignorato. Per ulteriori dettagli e indicazioni sulla riparazione, consulta [Correzione dei problemi di sicurezza rilevati da GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html).
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.
Il Customer Incident Response Team (CIRT) di AWS ha pubblicato un [repository GitHub contenente i playbook di risposta agli incidenti](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main/docs), organizzati per scenario, tipo e risorsa delle minacce. Questi playbook possono essere adattati per allinearsi alle procedure di risposta agli incidenti esistenti o fungere da base per svilupparne di nuove.
### 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 su comunicazione ed escalation**: chi è coinvolto e quali sono le sue informazioni di contatto? Quali sono le responsabilità di ciascuna parte interessata?
+ **Passaggi 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 va eseguito per ottenere il risultato desiderato?
+ **Individuazione**: come verrà individuato 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?
+ **Ripristino**: in che modo il sistema o la risorsa interessati verranno riportati in produzione?
+ **Risultati previsto**: 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 le persone che intervengono dopo un incidente dispongano degli opportuni diritti di accesso allocati in AWS, così da ridurre i tempi necessari per l'analisi e il ripristino.
**Anti-pattern comuni:**
+ Utilizzo dell'account root per la risposta agli incidenti.
+ Modifica degli account utente esistenti.
+ 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 quelle di risposta agli incidenti, si consiglia di implementare la [federazione delle identità](https://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. In caso di approvazione della richiesta, l'utente riceve una serie di [credenziali AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) temporanee, utilizzabili per completare le proprie attività. Alla scadenza di tali 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 eseguire questa operazione prevede l'utilizzo di [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) e [policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) per definire l'ambito dell'accesso.
Esistono scenari in cui le identità federate non sono disponibili, come nei seguenti casi:
+ 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 l'indisponibilità del sistema.
Nei casi precedenti, occorre configurare l'accesso di emergenza *break glass* in modo da consentire l'indagine e la risoluzione tempestiva degli incidenti. È consigliabile ricorrere a [utenti, gruppi o ruoli con le autorizzazioni opportune](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) per l'esecuzione delle attività e l'accesso alle risorse AWS. Ricorri all'utente root solo per le [attività che richiedono le credenziali dell'utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Per verificare che le persone che intervengono dopo un incidente dispongano del corretto livello di accesso ad AWS e ad altri sistemi pertinenti, ti consigliamo di eseguire la preallocazione di account dedicati. Gli account richiedono l'accesso con privilegi e devono essere rigorosamente controllati e monitorati. Gli account vanno 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.
Ricorri a 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 si rischia la mancata revoca dei 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. A supporto di ciò, crea un playbook per verificare che gli utenti di risposta agli incidenti vengano creati come utenti in un account di sicurezza dedicato e non gestiti tramite una federazione esistente o una soluzione di autenticazione Single Sign-On (SSO) Ogni singola persona che interviene dopo un incidente deve avere il proprio account denominato. La configurazione dell'account deve applicare [una policy delle 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 al 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. Questo può essere configurato con policy IAM o policy di controllo dei servizi come menzionato nelle best practice di sicurezza di AWS per le [AWS Organizations SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Gli utenti non devono disporre di privilegi oltre alla 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 la revoca immediata di qualsiasi accesso aggiuntivo immediatamente dopo la risoluzione dell'incidente.
Per verificare che l'uso dei ruoli di risposta agli incidenti possa essere adeguatamente monitorato e sottoposto ad audit, è essenziale che gli account IAM creati a tale scopo non siano condivisi tra le persone e che non si faccia ricorso all'Utente root dell'account AWS, salvo che non sia [necessario 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à delle credenziali di accesso dell'utente root e del token MFA.
Per configurare le policy IAM per i ruoli di risposta agli incidenti, prendi in considerazione l'utilizzo di [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) per generare policy basate su log AWS CloudTrail. In questo caso, concedi l'accesso come amministratore al ruolo di risposta agli incidenti per un account non di produzione e segui i playbook. Al termine, potrà essere creata una policy che consenta solo le azioni da intraprendere. Questa policy potrà quindi essere applicata a tutti i ruoli di risposta agli incidenti in tutti gli account. Puoi anche creare una policy IAM separata per ciascun playbook per semplificare gestione e audit. Esempi di playbook possono essere piani di risposta per ransomware, violazioni dei dati, perdita dell'accesso alla produzione e altri scenari.
Utilizza gli account di risposta agli incidenti per assumere i [ruoli IAM dedicati di risposta agli incidenti 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 denominare in modo chiaro gli account IAM e i ruoli IAM per trovarli facilmente nei log di CloudTrail. Un esempio potrebbe essere quello di denominare gli account IAM `-BREAK-GLASS` e i ruoli IAM `BREAK-GLASS-ROLE`.
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) consente di creare log dell'attività delle API negli account AWS e va 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. È possibile modificare le istruzioni in modo da configurare la metrica da filtro a filtro di [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) sugli eventi `AssumeRole` relativi al ruolo IAM di risposta agli incidenti:
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```
Vista la probabilità che i ruoli di risposta agli incidenti abbiano un livello di accesso elevato, è importante che questi avvisi vengano inviati a un gruppo ampio e gestiti tempestivamente.
Durante un incidente, è possibile che un membro del team di risposta richieda l'accesso a sistemi non direttamente protetti da IAM, ad esempio istanze Amazon Elastic Compute Cloud, database del servizio Amazon Relational Database o piattaforme Software-as-a-Service (SaaS). Si consiglia di utilizzare [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html), anziché protocolli nativi come SSH o RDP per tutti gli accessi amministrativi alle istanze di Amazon EC2. Questo accesso può essere monitorato utilizzando IAM, che è sicuro e controllato. È inoltre possibile automatizzare parti dei playbook mediante i [documenti AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), in modo da ridurre gli errori degli utenti 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 delle persone che intervengono dopo gli incidenti.
Infine, la gestione degli account IAM per la risposta agli incidenti dovrebbe 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 va riesaminata e testata periodicamente per verificare che sia consentito solo l'accesso previsto.
## Risorse
**Documenti correlati:**
+ [Managing temporary elevated access to your AWS environment](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [AWS Security Incident Response Guide ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [Ripristino di emergenza di elastico di AWS](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)
+ [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)
+ [ Configurazione dell'accesso multi-account con MFA ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Utilizzo di IAM Access Analyzer per creare 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 ](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 ](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 ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Video correlati:**
+ [ Automating Incident Response and Forensics in AWS](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)
# SEC10-BP06 Implementazione anticipata degli strumenti
Verifica che il team addetto alla sicurezza disponga degli strumenti giusti pre-implementati 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, anziché far sì che le persone monitorino la tua posizione di sicurezza e reagiscano 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 commettere errori nella gestione di situazioni ordinarie o farsi sfuggire avvisi insoliti. L’automazione aiuta a evitare l’affaticamento dagli avvisi mediante funzioni che elaborano gli avvisi ripetitivi e ordinari, lasciando alle persone la gestione degli incidenti sensibili e univoci. L’integrazione di sistemi di rilevamento delle anomalie, come Amazon GuardDuty, AWS CloudTrail Insights e Amazon CloudWatch Anomaly Detection può 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 scomporlo in una logica fruibile e scrivere il codice per eseguirla. 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 servono anche per la generazione di avvisi, che indicano il verificarsi di determinate azioni di interesse. È fondamentale selezionare, attivare, memorizzare e impostare i meccanismi di query e recupero e impostare gli avvisi. Inoltre, una soluzione efficace per fornire gli strumenti di 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 in grado di supportare e semplificare la tua strategia di risposta agli incidenti.
Oltre ai log, è necessario sviluppare e implementare una [strategia di assegnazione tag](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). L’assegnazione dei tag può fornire il contesto per lo scopo di una risorsa AWS e può essere utilizzata anche per l’automazione.
### Passaggi dell’implementazione
**Seleziona e configura i log per analisi e 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 log di servizi e applicazioni](sec_detect_investigate_events_app_service_logging.md)
**Enable security services to support detection and response**
AWS offre funzionalità investigative, preventive e reattive e altri servizi utilizzabili 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) e la [Homepage della risposta agli incidenti di sicurezza](https://aws.amazon.com/security-incident-response/).
**Sviluppa e implementa una strategia di assegnazione tag**
Ottenere informazioni contestuali sul caso d’uso aziendale e sulle parti interessante interne pertinenti relativi a una risorsa AWS può essere difficile. Un modo per farlo sono i 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 assegnazione 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 taggare, consulta [Taggare le 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 su implementazione e applicazione, consulta [Implement AWS resource tagging strategy using 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 log di servizi e applicazioni](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Acquisizione di log, esiti e metriche in posizioni standardizzate](sec_detect_investigate_events_logs.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)
+ [ Workshop Security Hub ](https://catalog.workshops.aws/security)
+ [ Gestione delle vulnerabilità con 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 se questa best practice non fosse adottata:** 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.
+ **Esercitazioni con il 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 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 questi 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.
+ **Esercitazioni con il 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 con il team rosso possono basarsi su test invasivi, procedi con cautela 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'esercitazione:** definisci scenario e obiettivi della simulazione. Lo scenario e gli obiettivi dovrebbero essere entrambi accettati dalla leadership.
1. **Identifica le parti interessate principali:** come minimo, un'esercitazione prevede la presenza di coordinatori 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. **Fai svolgere 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. **Predisponi il report post-azione (AAR):** identifica le aree positive, quelle da migliorare 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:**
+ [Guida sulla risposta agli incidenti di sicurezza di AWS](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)
+ [Esecuzione di simulazioni di risposta agli incidenti di sicurezza efficaci](https://www.youtube.com/watch?v=63EdzHT25_A)