Puoi automatizzare in sicurezza tutto ciò che osserva, raccoglie, collega e propone: la raccolta delle prove, la correlazione degli eventi, la proposta di priorità, la preparazione del piano di intervento e le notifiche ai responsabili. Quello che non va delegato è la decisione sulle azioni che cambiano lo stato dei sistemi: isolare un server, sospendere un account, bloccare un servizio. Il principio guida è semplice: gli interventi attivi richiedono un'approvazione esplicita, e il silenzio di chi dovrebbe decidere non vale come autorizzazione.
Perché serve un confine scritto tra automazione e autorizzazione
La pubblicazione NIST SP 800-61 revisione 3 del National Institute of Standards and Technology (NIST), pubblicata nell'aprile 2025, colloca la risposta agli incidenti dentro la gestione complessiva del rischio di sicurezza, con ruoli e responsabilità definiti prima, durante e dopo l'evento. Il messaggio pratico per un dirigente è questo: la velocità si ottiene preparando decisioni migliori, non eliminando chi decide. Per un approfondimento rimandiamo alla guida alla NIST SP 800-61r3.
Un automatismo sbagliato può costare più dell'incidente: isolare il server del gestionale in piena produzione o sospendere l'account di un direttore durante una trattativa sono azioni che un sistema esegue in pochi secondi e che un'azienda può impiegare giorni a spiegare. Il confine va quindi scritto prima dell'incidente, in un documento che elenca quali azioni sono automatizzabili, quali richiedono approvazione e chi può concederla.
Quali azioni di contenimento si possono delegare in sicurezza
Le attività adatte all'automazione hanno un tratto comune: non modificano lo stato operativo dei sistemi e sono reversibili. In questa famiglia rientrano:
- Raccolta e conservazione delle prove: registri di sistema, accessi, modifiche alle configurazioni, messi al sicuro prima che vadano persi.
- Correlazione degli eventi: collegare segnali da fonti diverse in un'unica sequenza temporale comprensibile.
- Proposta di priorità: valutare la rilevanza di un segnale rispetto al contesto aziendale, spiegando perché. Su questo vedi anche i criteri per scegliere un SOC AI, dove SOC sta per centro operativo di sicurezza.
- Arricchimento del contesto: indicare a chi appartiene un account, cosa fa un servizio, quali sistemi tocca una modifica.
- Preparazione del piano di contenimento: elencare le opzioni possibili con le conseguenze attese di ciascuna.
- Notifica ai responsabili: portare la richiesta di decisione alle persone previste, con le informazioni per decidere.
- Registrazione del percorso: conservare proposte, autorizzazioni, rifiuti ed esiti in modo ricostruibile.
La tabella seguente riassume il confine consigliato per le attività più comuni della risposta a un incidente.
| Tipo di attività | Automazione consigliata | Decisione umana richiesta |
|---|---|---|
| Raccolta e conservazione di log e prove | Sì, in modo continuo | No |
| Correlazione, priorità e preparazione del piano | Sì, come proposta con spiegazione e conseguenze stimate | No, ma una persona può correggere la priorità |
| Isolamento di un server o di un segmento di rete | Solo se preautorizzato per iscritto, con limiti e scadenza | Sì, salvo pre-autorizzazione specifica |
| Sospensione di un account | No | Sì, sempre |
| Chiusura dell'incidente e comunicazioni verso clienti, partner o autorità | No | Sì, sempre |
Cosa deve restare una decisione umana
Restano umane tutte le decisioni le cui conseguenze sono difficili da annullare o ricadono sull'operatività e sulla responsabilità dell'azienda: l'isolamento di un sistema in produzione, la sospensione di un account, il blocco di un servizio verso i clienti, la cancellazione o il ripristino di dati, la chiusura formale dell'incidente e ogni comunicazione verso l'esterno. A queste si aggiunge una decisione spesso dimenticata: modificare le regole stesse dell'automazione. Chi può allargare i limiti di ciò che il sistema fa da solo va riservato a poche persone identificate.
Il criterio di fondo non è tecnico ma organizzativo: se domani dovessi spiegare la decisione a un cliente, a un revisore o a un'autorità, chi ci metterebbe la firma? Quella persona deve esistere, essere raggiungibile secondo una catena definita e avere le informazioni per decidere. Ne parliamo anche nell'articolo su priorità ed escalation nel SOC.
Perché l'approvazione automatica per assenza di risposta è pericolosa
Alcune soluzioni propongono una regola apparentemente ragionevole: se il responsabile non risponde entro un certo numero di minuti, l'azione si considera approvata e parte da sola. È uno dei meccanismi più rischiosi che si possano introdurre, per tre motivi.
Il primo è logico: la mancata risposta non è una valutazione del merito. Trasforma un'assenza — la persona guida, dorme, ha il telefono scarico — in un'autorizzazione. La decisione viene presa da un timer, non da un responsabile.
Il secondo è operativo: gli incidenti gravi tendono ad arrivare quando la copertura è più sottile, di notte e nei fine settimana, cioè quando il «silenzio» è più probabile. La regola auto-approva gli interventi più delicati proprio quando servirebbe più attenzione. Su come organizzare il presidio in quegli orari vedi monitoraggio di notte e nei weekend.
Il terzo è probatorio: in un audit o in una ricostruzione successiva, «il sistema ha proceduto perché nessuno ha risposto» non dimostra che qualcuno ha valutato e autorizzato. Manca l'elemento che la documentazione deve provare: una decisione umana informata.
L'alternativa corretta ha due piani. Per i casi ordinari il sistema si ferma alla proposta: le attività passive continuano e la richiesta risale la catena dei responsabili finché una persona autorizzata decide. Per i casi davvero critici si può concordare una pre-autorizzazione scritta, decisa a freddo, con limiti precisi (quali sistemi, quali azioni, quali orari) e una scadenza: non «se nessuno risponde, procedi», ma «in queste condizioni specifiche abbiamo già deciso».
Come si documenta chi ha autorizzato cosa
Una registrazione utile conserva tre elementi per ogni intervento: la proposta (cosa si intende fare, perché, con quali conseguenze stimate e quali informazioni mancanti), l'autorizzazione (chi ha deciso, quando, entro quali limiti) e l'esito (cosa è successo davvero, compresi gli scostamenti dal piano). Vanno registrati anche i rifiuti e le attese motivate: «non intervenire» è una decisione tanto quanto intervenire.
Questo registro serve in almeno tre occasioni: la ricostruzione post-incidente (vedi come ricostruire un incidente con timeline ed evidenze), gli audit interni ed esterni, la raccolta di evidenze a supporto di adempimenti come DORA, NIS2 e ISO 27001. Le evidenze ben organizzate aiutano la valutazione dell'organizzazione, ma non la sostituiscono e non equivalgono a una certificazione automatica.
Esempio illustrativo: la copia anomala del sabato sera
Esempio illustrativo. Lo scenario seguente mostra il confine tra automazione e decisione nel percorso proposto da OverZeus; non racconta un incidente avvenuto presso un cliente.
Sabato sera, in una media azienda, l'account di servizio del gestionale inizia a copiare dati verso una destinazione di rete mai usata prima. Il sistema rileva l'anomalia e svolge subito la parte automatizzabile: conserva i registri, ricostruisce la sequenza degli accessi, verifica quali dati tocca quella destinazione.
Ares prepara la proposta: priorità alta, perché il volume di dati è insolito e l'orario non coincide con le attività pianificate note. Tre opzioni, con conseguenze stimate: osservare con registrazione rafforzata; limitare la destinazione tramite lo strumento di rete collegato; sospendere l'account di servizio, che però fermerebbe le elaborazioni notturne del gestionale.
La richiesta di decisione raggiunge il responsabile e poi il suo sostituto previsto: nessuno dei due risponde entro la finestra concordata. Qui entra in gioco Themis: i suoi controlli operano all'esterno del modello AI, non come istruzioni date al modello, e bloccano le due opzioni attive perché manca l'autorizzazione prevista. Il silenzio non la sostituisce. Nel frattempo Mnemosyne conserva log, timeline, proposta e richieste di approvazione rimaste senza esito.
Domenica mattina il responsabile esamina il caso e autorizza la limitazione della destinazione. Il lunedì si scopre la causa: una migrazione di archivio pianificata da un fornitore e comunicata male. La decisione di non sospendere subito l'account ha evitato un'interruzione immotivata, e il registro completo — proposta, attesa, autorizzazione, esito — resta disponibile per il riesame.
Come OverZeus mette in pratica questo confine
Nel progetto OverZeus il confine tra automazione e autorizzazione è affidato a tre agenti con ruoli distinti:
- Ares organizza priorità, indagini e proposte di contenimento: prepara il piano e lo espone con le conseguenze, ma esegue solo le misure previste e approvate.
- Themis applica privilegi, approvazioni e limiti operativi tramite controlli esterni al modello AI: non si tratta di istruzioni scritte nel modello, ma di verifiche indipendenti che bloccano le operazioni senza autorizzazione o con autorizzazione scaduta.
- Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, e segnala le lacune informative senza inventare ricostruzioni.
Le azioni effettivamente attivabili dipendono dalle integrazioni e dalle policy concordate per il singolo progetto: il perimetro va definito per iscritto in fase di adozione, insieme alla catena dei responsabili.
Domande frequenti sull'automazione della risposta agli incidenti
Posso preautorizzare alcune azioni per ridurre i tempi?
Sì, ed è il modo corretto di accelerare senza rinunciare al controllo. La pre-autorizzazione va scritta, limitata a sistemi e azioni specifici, vincolata a condizioni verificabili e dotata di scadenza. Va riesaminata periodicamente: un'autorizzazione concessa mesi prima potrebbe non corrispondere più ai sistemi attuali.
Chi risponde se un intervento causa un danno?
La responsabilità resta dell'organizzazione, che deve poter dimostrare come è stata presa la decisione: ruoli, catena di escalation e limiti per iscritto, proposte e autorizzazioni conservate. Un fornitore serio ti aiuta a costruire questa traccia, non a nasconderla dietro l'automazione.
Automatizzare il triage basta per dire di avere un SOC?
No. Il triage automatico accelera la selezione dei segnali, ma un centro operativo comprende anche indagine, decisione, contenimento, recupero e lezioni apprese: attività che richiedono persone con responsabilità definite, interne o in un servizio gestito concordato.
Velocità sì, ma con la firma di chi decide
Automatizzare la risposta agli incidenti non significa togliere le persone dal percorso: significa togliere loro il lavoro meccanico — raccogliere, collegare, preparare — perché possano decidere meglio e più in fretta. Il confine da difendere è uno solo: gli interventi attivi richiedono un'approvazione esplicita, e il silenzio non autorizza mai.
Vuoi vedere come funziona nella pratica il confine tra proposta e autorizzazione? Richiedi una demo del percorso dal segnale alla decisione.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.