# Risposta agli imprevisti
**Topics**
+ [SEC 10 In che modo prevedi, reagisci a e risolvi gli incidenti?](w2aac19b7c15b5.md)
# SEC 10 In che modo prevedi, reagisci a e risolvi gli incidenti?
La preparazione è cruciale per un esame tempestivo ed efficace degli incidenti di sicurezza, nonché per la risposta e il ripristino, così da ridurre al minimo potenziali interruzioni dell'organizzazione.
**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 Automatizzazione della capacità di contenimento](sec_incident_response_auto_contain.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 giornate di gioco](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 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
+ Identifica il 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.
+ Identifica i 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](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
Crea piani che ti aiutino a rispondere a un incidente, comunicare durante lo stesso e ripristinare in seguito le risorse. Ad esempio, puoi avviare un piano di risposta agli incidenti con gli scenari più probabili per il carico di lavoro e l'organizzazione. Includi il modo in cui gestiresti la comunicazione e l'escalation internamente ed esternamente.
**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 dati PII (informazioni personali di identificazione) europei, 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 eseguiti 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.
+ **Istruzione e formazione per la risposta agli incidenti:** quando si verifica una deviazione dalla linea di base definita (ad esempio, un'implementazione o una configurazione errata), potrebbe essere necessario rispondere e analizzare. Per farlo correttamente, è necessario comprendere quali controlli e capacità è possibile utilizzare per la risposta agli incidenti di sicurezza all'interno del proprio ambiente AWS, nonché i processi che è necessario implementare per preparare, istruire e formare i team cloud che partecipano alla risposta agli incidenti.
+ [Playbook](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) e [runbook](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) sono meccanismi efficaci per creare coerenza nella formazione su come rispondere agli incidenti. Inizia con la creazione di un elenco di procedure eseguite di frequente per rispondere agli incidenti e continua a ripetere le operazioni mentre apprendi o utilizzi nuove procedure.
+ Acquisisci familiarità con i playbook e i runbook con i previsti [game day](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html). Durante i game day, simula la risposta agli incidenti in un ambiente controllato in modo che i team possano apprendere come rispondere e per verificare che i team coinvolti nella risposta agli incidenti conoscano bene i flussi di lavoro. Esamina i risultati dell'evento simulato per identificare i miglioramenti e determinare le necessità di ulteriore formazione o strumenti aggiuntivi.
+ La sicurezza deve essere considerata un impegno per tutti. Sviluppa una conoscenza collettiva del processo di gestione degli incidenti coinvolgendo tutto il personale che normalmente gestisce i carichi di lavoro. Includi tutti gli aspetti dell'azienda, come le operazioni, i test, lo sviluppo, la sicurezza, la direzione e l'esecutivo.
+ **Documentazione del piano di gestione degli incidenti:** documenta gli strumenti e il processo per registrare, agire, comunicare lo stato di avanzamento e fornire notifiche sugli incidenti attivi. L'obiettivo del piano di gestione degli incidenti è verificare che il normale funzionamento venga ripristinato il più rapidamente possibile, l'impatto sul business sia ridotto al minimo e tutte le parti interessate siano informate. Esempi di incidenti includono, tra gli altri, la perdita o il deterioramento della connettività di rete, un processo o un'API che non risponde, un'attività pianificata che non viene eseguita (ad esempio le patch non riuscite), l'indisponibilità dei dati o del servizio dell'applicazione, l'interruzione del servizio non pianificata a causa di eventi di sicurezza, la perdita di credenziali o gli errori di configurazione.
+ Identifica il proprietario principale responsabile della risoluzione degli incidenti, ad esempio il proprietario del carico di lavoro. Predisponi una guida chiara su chi guiderà la risposta all'incidente e come verrà gestita la comunicazione. Quando più di una parte partecipa al processo di risoluzione degli incidenti, ad esempio un fornitore esterno, prendi in considerazione la creazione di una *matrice di responsabilità (RACI)*dettagliando i ruoli e le responsabilità di vari team o persone necessari per la risoluzione degli incidenti.
La matrice RACI descrive quanto segue:
+ **R:** *Responsible,* la parte responsabile che svolge il lavoro per completare l'attività.
+ **A:** *Accountable,* parte o stakeholder predisposta con l'autorità finale sul completamento corretto dell'attività specifica.
+ **C:** *Consulted,* parte consultata le cui opinioni sono richieste, tipicamente come esperti in materia.
+ **I:** *Informed,* parte a cui viene notificato lo stato di avanzamento, spesso solo al completamento dell'attività o del risultato finale.
+ **Classificazione degli incidenti:** la definizione e la classificazione degli incidenti in base alla gravità e al punteggio di impatto consente un approccio strutturato al triage e alla risoluzione degli incidenti. Le seguenti raccomandazioni illustrano *una matrice di urgenza dall'impatto alla risoluzione* per quantificare un incidente. Ad esempio, un incidente a basso impatto e a bassa urgenza è considerato un incidente di bassa gravità.
+ **Alto:** l'impatto sulla tua attività è significativo. Le funzioni critiche dell'applicazione relative alle risorse AWS non sono disponibili. Questa categoria è riservata agli eventi più critici che interessano i sistemi produttivi. L'impatto dell'incidente aumenta rapidamente poiché la correzione è soggetta a requisiti di tempo.
+ **Medio:** un servizio aziendale o un'applicazione correlata alle risorse AWS ha subito un impatto moderato e continua a funzionare in uno stato degradato. Le applicazioni che contribuiscono agli obiettivi del livello di servizio (SLO) sono interessate entro i limiti dell'Accordo sul livello di servizio (SLA). I sistemi possono funzionare con capacità ridotte senza grande impatto finanziario e reputazionale.
+ **Basso:** sono interessate le funzioni non critiche del servizio aziendale o dell'applicazione relative alle risorse AWS. I sistemi possono funzionare con capacità ridotta con minimo impatto finanziario e reputazionale.
+ **Standardizzazione dei controlli di sicurezza:** l'obiettivo della standardizzazione dei controlli di sicurezza è ottenere coerenza, tracciabilità e ripetibilità per quanto riguarda i risultati operativi. Promuovi la standardizzazione tra le attività chiave che sono critiche per la risposta agli incidenti, ad esempio:
+ **Gestione di identità e accessi:** stabilisci i meccanismi per controllare l'accesso ai tuoi dati e gestire i privilegi per le identità di persone fisiche e macchine. Estendi la tua gestione di identità e accessi al cloud, utilizzando la sicurezza federata con autenticazione unica e privilegi basati sui ruoli per ottimizzare la gestione degli accessi. Per i suggerimenti sulle best practice e i piani di miglioramento per standardizzare la gestione degli accessi, consulta la [sezione della gestione di identità e accessi](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) del whitepaper Security Pillar (Principio della sicurezza).
+ **Gestione delle vulnerabilità:** stabilisci i meccanismi per identificare le vulnerabilità del tuo ambiente AWS che potrebbero essere utilizzate dagli aggressori per compromettere e abusare del tuo sistema. Implementa i controlli preventivi e investigativi come meccanismi di sicurezza per rispondere e mitigare il potenziale impatto degli incidenti di sicurezza. Standardizza i processi come la modellazione delle minacce come parte della creazione dell'infrastruttura e del ciclo di vita della distribuzione delle applicazioni.
+ **Gestione delle configurazioni:** definisci le configurazioni standard e automatizza le procedure per l'implementazione delle risorse nel Cloud AWS. La standardizzazione dell'infrastruttura e del provisioning delle risorse aiuta a mitigare il rischio di configurazioni errate dovute a implementazioni o configurazioni errate per incidente umano. Consulta la [sezione Design Principles (principi di progettazione)](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) del whitepaper Operational Excellence Pillar (Principio dell'eccellenza operativa) per linee guida e piani di miglioramento per l'applicazione di questo controllo.
+ **Registrazione e monitoraggio per il controllo di audit:** implementa i meccanismi per monitorare le tue risorse per errori, degrado delle prestazioni e problemi di sicurezza. La standardizzazione di questi controlli fornisce anche gli audit trail delle attività che si verificano nel sistema, aiutando il triage tempestivo e la risoluzione dei problemi. Le best practice incluse in [SEC 4 ("In che modo individui ed esamini gli eventi di sicurezza?")](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) forniscono le indicazioni per l'applicazione di questo controllo.
+ **Utilizzo dell'automazione:** l'automazione consente una risoluzione tempestiva degli incidenti su vasta scala. AWS fornisce diversi servizi per automatizzare nel contesto della strategia di risposta agli incidenti. Concentrati sulla ricerca di un equilibrio appropriato tra automazione e intervento manuale. Quando crei la risposta agli incidenti nei playbook e nei runbook, automatizza i passaggi ripetibili. Usa i servizi AWS come Strumento di gestione degli incidenti AWS Systems Manager per [risolvere gli incidenti IT più velocemente](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/). Utilizza [gli strumenti per sviluppatori](https://aws.amazon.com/devops/) per fornire il controllo delle versioni e automatizzare le implementazioni di [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) e Infrastruttura come codice (IaC) senza l'intervento umano. Ove applicabile, automatizza il rilevamento e la valutazione della conformità utilizzando servizi gestiti come Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM, AWS Config e Amazon Macie. Ottimizza le capacità di rilevamento con soluzioni di machine learning come Amazon DevOps Guru per rilevare problemi di schemi operativi anomali prima che si verifichino.
+ **Esecuzione dell'analisi della causa principale e acquisizione delle lezioni apprese:** implementa i meccanismi per acquisire le lezioni apprese come parte di una revisione della risposta successiva all'incidente. Quando la causa principale di un incidente rivela un difetto più grande, un difetto di progettazione, una configurazione errata o una possibilità di ricorrenza, essa viene classificata come problema. In questi casi, analizza e risolvi il problema per ridurre al minimo l'interruzione delle normali operazioni.
## Risorse
**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)
**Video correlati:**
+ [Automating Incident Response and ForensicsAWS](https://youtu.be/f_EcwmmXkXk)
+ [ DIY guide to runbooks, incident reports, and incident response ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [ Prepare for and respond to security incidents in your AWS environment ](https://www.youtube.com/watch?v=8uiO0Z5meCs)
**Esempi correlati:**
+ [Laboratorio: Incident Response Playbook with Jupyter - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
+ [ 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-BP03 Preparazione di funzionalità forensi
È importante che le persone che intervengono dopo un incidente siano in grado di capire quando e come un'indagine forense è richiesta nel piano di risposta. L'organizzazione deve stabilire le prove da raccogliere e gli strumenti da utilizzare nel processo. Identifica e prepara capacità di indagine forensi idonee, tra cui specialisti esterni, strumenti e automazione. Una decisione importante da prendere in anticipo è se raccogliere i dati da un sistema live. Alcuni dati, come i contenuti della memoria volatile o le connessioni di rete attive, andranno perse se il sistema viene spento o riavviato.
Il team di risposta agli incidenti può abbinare strumenti, come AWS Systems Manager, Amazon EventBridge e AWS Lambda, per eseguire in automatico strumenti forensi all'interno di un sistema operativo e il mirroring del traffico VPC e ottenere un pacchetto di rete, per raccogliere prove non persistenti. Conduci altre attività, come l'analisi dei log o l'analisi delle immagini del disco, in un account di sicurezza dedicato con workstation forensi personalizzate e strumenti accessibili per i soccorritori.
Invia con regolarità i log rilevanti a un data store che garantisce durabilità e integrità elevate. I soccorritori devono avere accesso a tali log. AWS offre diversi strumenti che possono semplificare l'analisi dei log, come Amazon Athena, Amazon OpenSearch Service (OpenSearch Service) e Amazon CloudWatch Logs Insights. Inoltre, conserva le prove in modo sicuro con Amazon Simple Storage Service (Amazon S3) Object Lock. Questo servizio è in linea con il modello WORM (scrivi uno - leggi molti) e impedisce l'eliminazione o la sovrascrittura di oggetti per un periodo definito. Poiché le tecniche di indagine forensi richiedono una formazione specializzata, potrebbe essere necessario coinvolgere specialisti esterni.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Identifica le capacità forensi: ricerca le capacità di indagine forense della tua organizzazione, gli strumenti disponibili e gli specialisti esterni.
+ [Automatizzazione delle indagini e della risposta agli incidenti ](https://youtu.be/f_EcwmmXkXk)
## Risorse
**Documenti correlati:**
+ [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
# SEC10-BP04 Automatizzazione della capacità di contenimento
Automatizza il contenimento di un incidente e il successivo ripristino per ridurre i tempi di risposta e l'impatto sull'organizzazione.
Dopo aver creato e utilizzato i processi e gli strumenti dai playbook, puoi decostruire la logica in una soluzione basata su codice, che può essere utilizzata come strumento dal team di risposta per automatizzare la risposta e rimuovere la varianza o le supposizioni. Questo può accelerare il ciclo di vita di una risposta. L'obiettivo successivo è abilitare questo codice in modo che sia completamente automatizzato e che possa essere richiamato dagli avvisi o dagli eventi stessi, piuttosto che da un addetto alle risposte, per creare una risposta basata sugli eventi. Questi processi devono anche aggiungere automaticamente dati pertinenti ai sistemi di sicurezza. Ad esempio, un incidente che comporta traffico da un indirizzo IP non desiderato può automaticamente popolare un elenco i blocco AWS WAF o un gruppo di regole del firewall di rete per prevenire ulteriori attività.
![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)
*Figura 3: AWS WAF automatizza il blocco di indirizzi IP dannosi noti.*
Tramite un sistema di risposta basata sugli eventi, un meccanismo di rilevamento attiva un meccanismo di risposta per correggere automaticamente l'evento. Puoi utilizzare le funzionalità di risposta basata sugli eventi per ridurre il time-to-value tra meccanismi di rilevamento e di risposta. Per creare questa architettura basata sugli eventi, puoi utilizzare AWS Lambda, un servizio di elaborazione serverless che esegue il codice in risposta a eventi e gestisce automaticamente le risorse di calcolo sottostanti per tuo conto. Ad esempio, supponiamo che tu disponga di un account AWS con il servizio AWS CloudTrail abilitato. Se AWS CloudTrail è disabilitato (tramite la chiamata API `cloudtrail:StopLogging` ), puoi utilizzare Amazon EventBridge per monitorare l'evento specifico `cloudtrail:StopLogging` e richiamare una funzione AWS Lambda al fine di chiamare `cloudtrail:StartLogging` per riavviare la registrazione.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
Automatizzazione della capacità di contenimento.
## Risorse
**Documenti correlati:**
+ [AWS Incident Response Guide](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)
# 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
assicurati che il personale addetto alla sicurezza disponga degli strumenti giusti pre-distribuiti in AWS per ridurre i tempi di verifica fino al ripristino.
Per automatizzare le funzioni delle operazioni e la progettazione della sicurezza, puoi utilizzare un set completo di API e strumenti di 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. Un modo efficace per fornire in automatico dati di log pertinenti e su cui è possibile effettuare ricerche nei servizi AWS a chi si attiva in seguito a un incidente è abilitare [Amazon Detective](https://aws.amazon.com/detective/).
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 di 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.
Per gli strumenti eseguiti all'interno del sistema operativo dell'istanza Amazon Elastic Compute Cloud (Amazon EC2), considera l'utilizzo di AWS Systems Manager Run Command, che consente di amministrare le istanze in remoto e in modo sicuro utilizzando un agente installato nel sistema operativo delle istanze Amazon EC2. È richiesto l'agente Systems Manager (Agente SSM), installato per impostazione predefinita su molte Amazon Machine Image (AMI). Tieni presente, tuttavia, che una volta che un'istanza è stata compromessa, nessuna risposta da parte di strumenti o agenti in esecuzione su di essa va considerata affidabile.
**Livello di rischio associato se questa best practice non fosse adottata:** Basso
## Guida all'implementazione
+ Distribuisci gli strumenti in anticipo: verifica che il personale addetto alla sicurezza disponga dei corretti strumenti pre-distribuiti in AWS affinché si possa implementare una risposta adeguata a un incidente.
+ [Laboratorio: Incident response with Console di gestione AWS and CLI ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
+ [ Incident Response Playbook with Jupyter - AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
+ [ Automazione della sicurezza in AWS](https://github.com/awslabs/aws-security-automation)
+ Implementa l'applicazione di tag alle risorse: applica tag alle risorse con informazioni, ad esempio un codice per la risorsa sottoposta a verifica, in modo da poter identificare le risorse durante un incidente.
+ [ Strategie di applicazione di tag AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
## 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:**
+ [ DIY guide to runbooks, incident reports, and incident response ](https://youtu.be/E1NaYN_fJUo)
# SEC10-BP07 Esecuzione di giornate di gioco
i game day, noti anche come simulazioni o esercizi, sono eventi interni che offrono un'opportunità strutturata per mettere in pratica i piani e le procedure di gestione degli incidenti in uno scenario realistico. Tali attività sono importanti per esercitare le capacità dei partecipanti, con gli stessi strumenti e le stesse tecniche del mondo reale e persino gli stessi ambienti. I game day riguardano fondamentalmente la preparazione e il miglioramento iterativo delle capacità di risposta. Alcuni dei motivi per cui potresti trovare utile l'organizzazione di game day includono:
+ Convalida della preparazione
+ Sviluppo delle competenze: apprendimento da simulazioni e dal personale preposto alla formazione
+ Rispetto degli obblighi contrattuali o di conformità
+ Generazione di artefatti per l'accreditamento
+ Agilità: miglioramento incrementale
+ Maggiore rapidità e miglioramento degli strumenti
+ Perfezionamento della comunicazione e dell'escalation
+ Gestione più sicura delle situazioni rare e inaspettate
Per questi motivi, il valore derivato dalla partecipazione a un'attività di simulazione aumenta l'efficacia di un'organizzazione durante gli eventi stressanti. Sviluppare un'attività di simulazione realistica e utile può essere un esercizio difficile. Anche se testare le procedure o l'automazione che gestisce eventi noti presenta alcuni vantaggi, è altrettanto utile partecipare alle attività [Security Incident Response Simulations (SIRS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) creative per mettersi alla prova in situazioni impreviste e migliorare continuamente.
Crea simulazioni personalizzate in base al tuo ambiente, al tuo team e ai tuoi strumenti. Trova un problema e progetta una simulazione. Potrebbe trattarsi di una credenziale compromessa, di un server che comunica con sistemi indesiderati o di una configurazione errata che comporta un'esposizione non autorizzata. Identifica gli ingegneri che conoscono l'organizzazione per creare lo scenario e per la partecipazione di un altro gruppo. Lo scenario deve essere realistico e abbastanza impegnativo per essere rilevante. Deve offrire la possibilità di fare pratica con registri, notifiche, escalation ed esecuzioni di runbook o automazioni. Durante la simulazione, i soccorritori devono esercitare le proprie capacità tecniche e organizzative e i leader devono essere coinvolti per sviluppare le competenze necessarie per la gestione degli incidenti. Alla fine della simulazione, riconosci l'impegno del team e trova il modo di iterare, ripetere e ampliare nuove simulazioni.
[AWS ha creato modelli di Runbook di risposta agli incidenti](https://github.com/aws-samples/aws-incident-response-playbooks) che puoi usare non solo per preparare la tua risposta, ma anche come base per una simulazione. Nella fase di pianificazione, una simulazione può essere suddivisa in cinque fasi.
**Raccolta delle prove: **In questa fase, un team riceverà avvisi tramite diversi mezzi, come, ad esempio, un sistema di ticket interno, avvisi da strumenti di monitoraggio, suggerimenti anonimi o persino notizie pubbliche. I team cominciano quindi a esaminare i log di infrastrutture e applicazioni per stabilire l'origine della compromissione. Questa fase deve coinvolgere anche escalation interne e leadership degli incidenti. Una volta identificate queste informazioni, i team passano al contenimento dell'incidente
**Contenimento dell'incidente: **I team avranno stabilito che si è verificato un incidente e avranno identificato l'origine del compromissione. I team devono ora agire per contenerlo disabilitando ad esempio le credenziali compromesse, isolando una risorsa di calcolo o revocando l'autorizzazione di un ruolo.
**Eliminazione dell'incidente: **Ora che l'incidente è stato contenuto, i team lavoreranno per mitigare le vulnerabilità nelle applicazioni o nelle configurazioni dell'infrastruttura che sono state coinvolte nella compromissione. Potrebbe essere necessario ruotare tutte le credenziali utilizzate per un carico di lavoro, modificare le liste di controllo degli accessi (ACL) o cambiare le configurazioni di rete.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Esegui [game day](https://wa.aws.amazon.com/wat.concept.gameday.en.html): esegui eventi di risposta [a](https://wa.aws.amazon.com/wat.concept.incident.en.html) incidenti simulati [(game day)](https://wa.aws.amazon.com/wat.concept.event.en.html) per minacce diverse che coinvolgono personale e dirigenza chiave.
+ Integrazione dei concetti appresi: le lezioni apprese dall'esecuzione di [game day](https://wa.aws.amazon.com/wat.concept.gameday.en.html) devono essere parte del loop di feedback per migliorare i processi.
## Risorse
**Documenti correlati:**
+ [AWS Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Elastic Disaster Recovery (Ripristino di emergenza elastico AWS)](https://aws.amazon.com/cloudendure-disaster-recovery/)
**Video correlati:**
+ [ DIY guide to runbooks, incident reports, and incident response ](https://youtu.be/E1NaYN_fJUo)