CHI_SONO

// step 01 · Triage

Classificazione severity (P1-P4), identificazione asset coinvolti, attivazione del canale di comunicazione dedicato. Il ticket apre con uno stato chiaro e un owner unico.

// step 02 · Contenimento

Isolation degli host compromessi (network o EDR), revoca credenziali sospette, blocco IOC su firewall e endpoint. Priorità: fermare la propagazione, non investigare.

// step 03 · Eradicazione

Rimozione persistenza (registry, scheduled task, servizi), patching delle vulnerabilità sfruttate, hardening delle configurazioni che hanno permesso l'incident.

// step 04 · Recovery

Restore da backup verificati, validation servizi business, monitoring intensivo nelle 72h successive. Nessun servizio torna online finché non passa lo smoke test.

// step 05 · Post-mortem

Retrospective blameless, gap analysis, aggiornamento runbook L1/L2. La lessons learned diventa un commit nel knowledge base, non un PDF dimenticato.

// step 01 · Assessment

Asset inventory completo (nmap, Lansweeper), baseline configurazioni, mappatura porte/servizi esposti vs. funzionalità business effettivamente in uso.

// step 02 · Planning

Prioritizzazione interventi su matrice impatto × rischio. Una roadmap a 90 giorni, scritta in un Confluence con owner e date — non un PowerPoint generico.

// step 03 · Pilota

Rollout su un sottoinsieme rappresentativo (5-10% asset). Si misura impatto operativo prima di estendere. Un hardening che blocca la produzione è un fallimento, non un successo.

// step 04 · Flotta completa

Estensione graduale con finestre di manutenzione concordate. Reporting compliance settimanale agli stakeholder business.

// step 05 · Verifica

Re-scan, comparazione baseline pre/post, validazione che le metriche di riduzione superficie siano reali e mantenute.

// step 01 · As-is

Documentazione esaustiva dello stato attuale: dipendenze applicative, integrazioni, performance baseline. Senza un as-is preciso ogni migrazione diventa un debug in produzione.

// step 02 · To-be

Design target con tradeoff espliciti (costo, performance, complessità operativa). Architettura validata con CTO o infrastructure lead prima di toccare un file.

// step 03 · Planning

Runbook step-by-step con tempi stimati, criteri di go/no-go a ogni step, e — questa è la parte importante — un fallback plan dettagliato per ogni step critico.

// step 04 · Pilot

Migrazione di un workload non critico per validare il runbook end-to-end. È qui che emergono i problemi, non al cutover.

// step 05 · Cutover

Esecuzione del runbook in finestra concordata. Comunicazione costante agli stakeholder. Se un criterio di go/no-go fallisce, si esegue il fallback senza esitare.