Piano di incident response nel cloud: best practice e guida passo passo

Il ciclo di vita dell'incident response, adattato al cloud

NIST SP 800-61 Rev. 3 non presenta più l'incident response come un ciclo autonomo in quattro fasi. Associa le attività di risposta alle funzioni del CSF 2.0: Govern, Identify, Protect, Detect, Respond e Recover. Nella pratica la maggior parte dei team organizza ancora i runbook attorno alle fasi familiari qui sotto, e funziona bene finché preparazione e lezioni apprese alimentano la governance.

Fase 1: preparare piano, persone e piattaforma

Definire perimetro e governance

Indicate quali ambienti copre il piano: ogni account, subscription e progetto cloud, più le piattaforme SaaS che contengono dati aziendali (Microsoft 365, Google Workspace, Salesforce e simili). Registrate le classificazioni dei dati, perché la fuga di dati personali dei clienti scala più in fretta di un bucket di test esposto.

Assegnate un responsabile del piano, una cadenza di revisione (almeno annuale, e dopo incidenti importanti o modifiche all'architettura) e il collegamento ai piani di business continuity e disaster recovery. Ai sensi della NIS2, l'articolo 20 richiede che gli organi di gestione delle entità essenziali e importanti approvino le misure di gestione del rischio di cybersicurezza e ne controllino l'attuazione, quindi l'approvazione a livello di consiglio di amministrazione non è più facoltativa per le aziende nel perimetro.

Assegnare i ruoli prima di averne bisogno

Nominate un sostituto per ogni ruolo e tenete un elenco di contatti out-of-band. Se l'attaccante ha il vostro tenant Microsoft 365, Teams non è una war room sicura.

Progettare la piattaforma per la risposta

• Logging centrale e a prova di manomissione. Inviate CloudTrail, log di attività di Azure, log di accesso e di audit di Microsoft Entra ID, Google Cloud Audit Logs, flow log di VPC/NSG e log DNS a un account o workspace di log dedicato da cui gli amministratori di produzione non possano cancellare. Usate object lock o storage immutabile per l'archivio.
• Retention adeguata alle indagini. Con un ciclo di vita delle violazioni misurato in mesi, 30 giorni di log sono troppo pochi. Definite la retention in base alla classe di dati e ai requisiti di legge.
• Accesso break-glass. Tenete un piccolo numero di account di emergenza con MFA hardware, conservati e monitorati separatamente, in modo che chi risponde non resti bloccato fuori quando l'identity provider è l'obiettivo dell'attacco.
• Capacità forense predisposta. Un account o una subscription forense separati, con gli strumenti pronti, dove copiare gli snapshot per l'analisi senza toccare la produzione.
• Segmentazione e privilegio minimo. Account separati per ambiente, ruoli circoscritti e service control policy limitano fin dove può propagarsi un incidente.
• Punti di ripristino immutabili. Backup cross-account con versioning e immagini da cui ricostruire, protetti dalle stesse credenziali che gestiscono la produzione.

Fase 2: rilevare e fare il triage degli incidenti cloud

Un buon rilevamento nel cloud combina il threat detection nativo del provider con la vostra correlazione. I servizi nativi conoscono la piattaforma; il vostro SIEM conosce il contesto di business.

• Attivate Amazon GuardDuty, Microsoft Defender for Cloud o Google Security Command Center in ogni account e regione, non solo in produzione.
• Inoltrate finding e log di identità a un unico SIEM, in modo che un'anomalia di accesso in Entra ID e una chiamata API AWS insolita dello stesso utente compaiano come un solo caso.
• Generate alert sugli eventi ad alto segnale: accesso come root o global administrator, nuove chiavi di accesso per utenti privilegiati, logging disattivato, policy di storage pubblico, nuove regioni in uso, picchi improvvisi di calcolo.
• Aggiungete threat intelligence, così che gli alert collegati a infrastrutture malevole note salgano in cima alla coda.

Una semplice matrice di triage

Runbook di esempio: uso sospetto di una chiave di accesso

1. Confermate l'attività nel log di audit: IP di origine, user agent, regioni e chiamate API delle ultime ore.
2. Disattivate la chiave (non eliminatela ancora) e revocate le sessioni attive del principal.
3. Verificate a che cosa poteva accedere la chiave e che cosa ha fatto: nuovi utenti, ruoli, chiavi, istanze, letture di dati.
4. Fate lo snapshot delle istanze coinvolte ed esportate i log rilevanti nell'account forense.
5. Avvisate l'incident commander, e l'ufficio legale se è probabile un accesso ai dati.
6. Ruotate tutti i segreti che il principal poteva leggere, poi rimuovete la persistenza creata dall'attaccante.

Fase 3: preservare le evidenze alla maniera del cloud

La forensica nel cloud riguarda soprattutto velocità e automazione. Inserite questi passaggi in ogni runbook che termina con una terminazione o una ricostruzione:

• Fate snapshot dei dischi e, se gli strumenti lo permettono, un'acquisizione della memoria prima di isolare o fermare una VM.
• Etichettate le risorse isolate con l'ID dell'incidente, così nessuno "ripulisce" le evidenze.
• Copiate snapshot ed estratti di log nell'account forense; registrate chi li ha consultati e quando.
• Mantenete tutti i sistemi sincronizzati (NTP, UTC nei log) per poter correlare gli eventi tra provider.
• Sappiate come richiedere informazioni al provider. I contratti con fornitori SaaS e MSSP dovrebbero indicare quali log conservano, per quanto tempo e con quale rapidità li consegnano.

La AWS Security Incident Response Guide illustra queste pratiche nel dettaglio per AWS; gli stessi principi valgono per Azure e Google Cloud.

Fase 4: contenere, eradicare e ripristinare

Contenimento a breve termine

• Isolate le istanze sostituendo il loro security group o NSG con un gruppo deny-all che consenta solo l'accesso forense.
• Disattivate le chiavi, revocate token e sessioni e forzate il reset di password e MFA per le identità compromesse.
• Bloccate l'accesso pubblico sullo storage esposto; applicate una policy di deny esplicito o una service control policy se l'attaccante ha diritti di amministratore.
• Aggiungete regole WAF o rate limit per gli attacchi a livello applicativo.

Contenimento a lungo termine ed eradicazione

• Rimuovete utenti backdoor, ruoli, chiavi, attività pianificate, funzioni Lambda o immagini di container aggiunti dall'attaccante.
• Ricostruite i carichi da immagini note e integre e da infrastructure as code invece di "ripulirli" sul posto.
• Correggete la causa radice: il ruolo troppo permissivo, il segreto trapelato nella pipeline CI/CD, l'immagine non aggiornata.
• Aggiungete un guardrail (policy-as-code, SCP, Azure Policy) perché la stessa configurazione errata non possa ripresentarsi.

Ripristino e validazione

Ripristinate prima i servizi critici da backup puliti, poi verificate l'integrità: eseguite i test, confrontate la configurazione con l'IaC e controllate che le policy di accesso siano quelle volute. Mantenete un monitoraggio rafforzato sugli account interessati per un periodo definito, ad esempio 30 giorni, perché gli attaccanti spesso tentano di rientrare. Il design del vostro disaster recovery cloud determina quanto può essere veloce questo passaggio.

Fase 5: comunicazione, aspetti legali e scadenze normative

Le scadenze di notifica decorrono da quando venite a conoscenza dell'incidente, non da quando termina l'indagine. Inseritele nel piano con responsabili nominati.

La NIS2 è una direttiva, quindi sono le norme nazionali a stabilire l'autorità esatta e il formato della segnalazione; verificate il recepimento nel vostro Paese. Controllate anche i contratti con i clienti: molti accordi B2B fissano finestre di notifica proprie.

Preparate in anticipo i modelli per gli aggiornamenti interni, gli avvisi ai clienti e le segnalazioni alle autorità. Concordate una matrice di notifica basata sulla gravità: chi viene informato a livello critico, alto, medio e basso, e con quale rapidità. Fate sempre passare le dichiarazioni esterne dall'ufficio legale.

Fase 6: testare, misurare e migliorare

Esercitazioni

• Esercitazioni tabletop almeno due volte l'anno: ripercorrete una chiave di accesso trapelata, un global administrator compromesso o un ransomware su VM cloud con personale tecnico, legale e della comunicazione in sala.
• Prove tecniche almeno una volta l'anno in un account non di produzione: eseguite davvero i runbook di contenimento e cronometrateli.
• Test di ripristino che dimostrino di poter ricostruire da IaC e backup in un account pulito.

Metriche

Automatizzare i passaggi ripetibili

L'automazione toglie minuti a ogni incidente. Candidati comuni: disattivare una chiave segnalata da GuardDuty, isolare un'istanza a fronte di un finding ad alta gravità e aprire un ticket con le evidenze allegate. In Azure, i playbook di Microsoft Sentinel basati su Logic Apps svolgono lo stesso compito. Mantenete un passaggio di approvazione umana per le azioni che potrebbero causare un disservizio.

Note di piattaforma per AWS, Azure e Google Cloud

AWS

• Usate un trail CloudTrail a livello di organizzazione che copra tutte le regioni, con eventi di gestione ed eventi di dati per i bucket S3 sensibili.
• Attivate GuardDuty con un account amministratore delegato e aggregate i finding in AWS Security Hub.
• Instradate i finding ad alta gravità tramite Amazon EventBridge verso lo strumento di paging o ITSM, così che chi risponde sia avvisato in pochi minuti.

Azure

• Attivate i piani rilevanti di Microsoft Defender for Cloud su tutte le subscription.
• Verificate gli accessi con i log di accesso e di audit di Microsoft Entra ID; usate il Conditional Access per bloccare gli accessi a rischio durante un incidente.
• Usate le regole di analisi e i playbook di Microsoft Sentinel per correlazione e risposta.

Google Cloud

• Attivate Security Command Center a livello di organizzazione.
• Conservate Cloud Audit Logs e VPC Flow Logs ed esportateli in un progetto di log protetto.
• Google Security Operations (già Chronicle) offre SIEM e SOAR se standardizzate su Google.

Multicloud

La principale debolezza del multicloud è la visibilità. Normalizzate in un unico SIEM i log di tutti i provider, mantenete un solo insieme di definizioni di gravità e scrivete runbook che indichino l'azione equivalente su ciascuna piattaforma. Testate le chiamate API da cui dipende la vostra automazione, perché i provider le cambiano.

Come può aiutare Opsio

Il servizio SOC e il managed detection and response di Opsio forniscono monitoraggio e risposta 24/7 per ambienti AWS e Azure dai nostri team in Svezia e in India. Aiutiamo i clienti a scrivere e testare il proprio piano, a configurare il logging centrale e ad automatizzare i primi passaggi di contenimento.

Per Branäsgruppen, uno dei maggiori gruppi di stazioni sciistiche della Svezia, Opsio gestisce le applicazioni critiche su più Availability Zone con backup incrementali giornalieri e completi settimanali conservati per 60 giorni. Il caso Branäsgruppen riporta un tempo medio di 2 giorni per identificare e risolvere i problemi critici e una disponibilità delle applicazioni del 99,9%+.

Domande frequenti

Quali sono le best practice per l'incident response nel cloud?

Attivare ovunque l'audit logging e conservarlo in modo centralizzato, seguire NIST SP 800-61 Rev. 3, scrivere runbook per gli incidenti cloud più comuni, automatizzare l'acquisizione delle evidenze, contenere tramite controlli su identità e rete, ricostruire da IaC e testare il piano con esercitazioni tabletop regolari.

In che cosa l'incident response nel cloud differisce da quella on-premises?

La responsabilità è condivisa con il provider, le evidenze provengono da log e API anziché da dischi fisici, le risorse possono svanire in pochi secondi e la maggior parte degli attacchi usa identità rubate. Il contenimento è di solito una modifica a IAM o alle policy, più che scollegare un server.

Che cosa dovrebbe includere un modello di piano di incident response nel cloud?

Perimetro e governance, ruoli con sostituti e recapiti, definizioni di gravità, fonti di log e retention, runbook per tipo di incidente, gestione delle evidenze, una matrice di notifica con le scadenze GDPR e NIS2, contatti di escalation del provider, passaggi di ripristino e un calendario dei test.

Come si integra l'incident response con gli strumenti di sicurezza cloud?

Inviando a un unico SIEM i finding di GuardDuty, Defender for Cloud o Security Command Center e i log di identità, associando ogni tipo di alert a un runbook e automatizzando i primi passaggi a basso rischio, come la disattivazione di una chiave o l'isolamento di un'istanza, con approvazione umana per le azioni che causano interruzioni.

Con quale frequenza va testato un piano di incident response nel cloud?

Eseguite esercitazioni tabletop almeno due volte l'anno, almeno una prova tecnica l'anno e una revisione aggiuntiva dopo ogni incidente importante o modifica architetturale. Aggiornate i runbook dopo ogni test.