Allarmi di notte e nel weekend: monitoraggio e reperibilità

Quando un allarme di sicurezza arriva alle tre di notte, deve accadere una cosa sola: qualcuno di individuato in anticipo riceve una segnalazione comprensibile, con il contesto necessario e una proposta di azione, e decide entro i limiti scritti che gli sono stati delegati. Se nessuno risponde, il sistema continua a osservare e raccogliere evidenze, ma non interviene da solo: il silenzio non è un'autorizzazione. Questa guida spiega come organizzare questo percorso in una piccola azienda senza turni, distinguendo ciò che fa il software da ciò che resta alle persone.

Quali eventi meritano una segnalazione fuori orario

La prima decisione non è tecnica ma organizzativa: quali eventi giustificano una sveglia alle tre di notte. Se tutto è urgente, niente lo è: chi riceve decine di notifiche a settimana smette di leggerle, e l'app diventa rumore di fondo.

Una griglia semplice, scritta e approvata dalla direzione, aiuta a separare tre livelli:

I criteri vanno adattati alla tua realtà: per un'azienda che tratta dati sanitari, l'accesso notturno a un archivio specifico può essere alta priorità; per un'altra no. Ciò che conta è che i criteri esistano per iscritto e vengano rivisti quando cambiano sistemi, orari o attività. La pubblicazione SP 800-61 revisione 3 del NIST, l'istituto di standard e tecnologia statunitense, colloca la risposta agli incidenti nella gestione complessiva del rischio, con ruoli e preparazione definiti prima dell'evento: la griglia di priorità è esattamente questo tipo di preparazione, in scala adatta a una piccola azienda.

Cosa deve contenere la segnalazione delle tre di notte

Una notifica che dice solo «anomalia rilevata» costringe chi la riceve ad alzarsi, accendere un computer e ricostruire tutto da zero. Una segnalazione utile, invece, risponde subito a quattro domande:

• Cosa è stato osservato: l'evento concreto, con orario, account e sistema coinvolti.
• Perché è rilevante: lo scostamento rispetto alla situazione attesa, senza dare per certa una compromissione non dimostrata.
• Quali sono le opzioni: le azioni possibili, con le conseguenze di ciascuna, compresa quella di attendere.
• Cosa manca: le informazioni non disponibili, per non confondere un'ipotesi con un fatto.

Con questi elementi il responsabile può decidere dal telefono in pochi minuti; senza, anche la persona più diligente può solo rimandare al mattino, e la notifica è stata un costo senza beneficio.

Responsabili, sostituti e presa in carico concordata

Chi può autorizzare un intervento se il responsabile dorme? La risposta corretta non è «il sistema decide» e neppure «si sveglia comunque qualcuno», ma una delega scritta e limitata, concordata prima dell'emergenza. In pratica servono tre elementi:

• Un responsabile e almeno un sostituto, nominati per nome, con recapiti aggiornati e orari in cui ciascuno è effettivamente raggiungibile.
• Limiti di delega espliciti. Il sostituto può per esempio confermare attività pianificate e richiedere verifiche, ma non autorizzare il blocco di account o il fermo di un servizio: quelle decisioni restano al responsabile o alla direzione. I limiti vanno scritti nella procedura, non affidati alla memoria.
• Una presa in carico visibile. Quando qualcuno risponde, il caso risulta «preso in carico» da quella persona. Se entro il tempo concordato nessuno prende in carico, la segnalazione sale al sostituto o alla direzione secondo la catena concordata.

Definire priorità ed escalation con criteri scritti trasforma una buona intenzione in un meccanismo affidabile. Poiché le persone cambiano ruolo, numero di telefono e disponibilità, la catena va verificata periodicamente: le esercitazioni di risposta agli incidenti, anche brevi, servono a scoprire il contatto non aggiornato prima che serva davvero.

Cosa resta in osservazione quando manca un'approvazione

Il caso più delicato è quello in cui la notifica arriva ma nessuno risponde. Qui il confine tra software e responsabilità umana deve essere netto: l'assenza di risposta non può essere interpretata come autorizzazione. Se il sistema agisse da solo dopo un timeout, la delega scritta diventerebbe una finzione e la responsabilità di un intervento sbagliato ricadrebbe su nessuno.

Cosa può fare legittimamente il software mentre attende:

• continuare a osservare l'evento e raccogliere le evidenze disponibili nel perimetro autorizzato;
• correlare il segnale con altri eventi nella stessa finestra temporale, per presentare un quadro più completo alla prima persona raggiungibile;
• conservare la cronologia della segnalazione: quando è partita, a chi, e quale decisione è stata infine presa;
• applicare solo le misure eventualmente pre-autorizzate per iscritto per quello specifico scenario, nei limiti approvati.

Cosa non deve fare: bloccare account, interrompere servizi o modificare configurazioni senza l'approvazione prevista. Un intervento attivo sbagliato alle tre di notte può causare più danni dell'evento osservato, per esempio fermando una spedizione automatica o un processo produttivo legittimo.

Esempio illustrativo: sabato notte in un'azienda di produzione

Esempio illustrativo. Lo scenario seguente mostra un percorso possibile con OverZeus; non racconta un incidente avvenuto presso un cliente.

Un'azienda di produzione con una quarantina di dipendenti non ha turni IT: il referente tecnico lavora in orario d'ufficio e la titolare è la responsabile ultima delle decisioni. Nella procedura concordata, il referente tecnico è il responsabile e un responsabile di reparto, formato per l'occasione, è il sostituto con delega limitata: può confermare attività pianificate e richiedere verifiche, non autorizzare blocchi.

Sabato alle 3:12, Argus rileva un accesso con privilegi amministrativi al server del gestionale, fuori da ogni finestra di manutenzione pianificata. L'evento rientra nel livello di alta priorità della griglia. Hermes invia la notifica al referente tecnico attraverso l'app, con account, orario, dispositivo di origine e contesto disponibile. Il telefono del tecnico è silenziato: dopo il tempo concordato senza presa in carico, il caso passa al sostituto, come stabilito dalla catena definita nella procedura.

Il sostituto legge la scheda: cosa è stato osservato, perché è rilevante, quali informazioni mancano. La sua delega gli consente due scelte: confermare l'attività se la riconosce come pianificata, oppure richiedere una verifica. Non la riconosce, quindi richiede la verifica e registra la decisione nell'app. Nel frattempo Ares ha preparato una proposta di contenimento — sospensione dell'account coinvolto — ma la misura supera la delega del sostituto e resta in attesa. Il caso rimane in osservazione: le evidenze si accumulano, nessun account viene bloccato.

Alle 8:30 il referente tecnico riprende in mano il caso con una cronologia completa: segnalazione, escalation, decisione del sostituto, proposta di Ares. Verifica che l'accesso proveniva da un fornitore di manutenzione che aveva anticipato un intervento concordato per domenica, senza registrarlo nel calendario delle attività pianificate. L'incidente si chiude come attività legittima e la procedura viene corretta: gli interventi dei fornitori vanno annotati prima, non dopo. Il punto debole era la registrazione mancata, non il sistema.

Il contributo di OverZeus, con i suoi limiti

In OverZeus il percorso appena descritto coinvolge in primo piano tre agenti, ciascuno con un ruolo documentato:

• Argus osserva in continuo eventi, servizi, rete e dispositivi collegati, ed evidenzia anomalie e scostamenti dalla situazione attesa.
• Hermes è l'app dei responsabili: riceve le segnalazioni dal server locale, spiega gli interventi proposti e raccoglie approvazioni o rifiuti. La sua regola esplicita è che l'assenza di risposta non viene interpretata come autorizzazione.
• Ares organizza priorità, indagini ed escalation, e prepara proposte di contenimento: ogni intervento segue un piano con responsabilità e autorizzazioni chiare, ed esegue solo le misure elencate e approvate.

Accanto a questi, Themis applica privilegi e limiti operativi attraverso controlli esterni al modello di intelligenza artificiale (AI) — quindi i confini della delega del sostituto non dipendono dall'interpretazione del modello — e Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, rendendo ricostruibile ogni decisione, compresa quella di attendere.

Due precisazioni importanti. La prima: le notifiche sull'app richiedono connettività. Hermes collega l'app al server locale tramite una VPN (rete privata virtuale) su connessione 5G cifrata proprietaria; se il canale non è disponibile la notifica non arriva, mentre il server nel CED, il centro elaborazione dati in sede, continua la sua operatività locale — la catena dei recapiti deve prevedere anche questo caso. La seconda: OverZeus non è un presidio umano 24 ore su 24. Gli agenti osservano e preparano il caso in continuo, ma la decisione resta alle persone della tua azienda, secondo griglia e deleghe definite. È un punto da chiarire con qualsiasi fornitore, come spiega la guida su come scegliere un SOC AI, un centro operativo di sicurezza basato su agenti: «intelligenza artificiale» nel nome non significa analisti in turno dietro lo schermo.

Come evitare che l'app di notifica diventi spam

Per la sostenibilità nel tempo, alcune regole pratiche:

• Poche categorie, ben definite. La griglia a tre livelli vista sopra è sufficiente per la maggior parte delle piccole aziende: più categorie significano più casi ambigui da discutere a ogni allarme.
• Riepilogo per il livello medio. Le anomalie di media priorità possono arrivare in un riepilogo del mattino invece che una per una: riduce le interruzioni senza perdere l'informazione.
• Revisione periodica delle soglie. Ogni mese, o dopo ogni cambiamento importante, riesamina le notifiche inviate: quante erano davvero utili, quante potevano attendere, quali eventi veri mancavano. La qualità del triage si misura sui casi concreti, non sulle promesse.
• Registra anche i falsi allarmi utili. Una notifica infondata ma ben motivata non va cancellata come errore: serve a calibrare i criteri e a spiegare, nel tempo, perché una soglia è stata modificata.

Una responsabilità organizzata, non delegata al software

Organizzare monitoraggio e reperibilità fuori orario significa mettere per iscritto tre cose: quali eventi meritano una sveglia, chi risponde e con quali limiti, cosa accade quando nessuno risponde. Il software può osservare di continuo, spiegare, proporre e conservare le evidenze; la decisione e la responsabilità restano di persone nominate, con deleghe chiare. È il modo realistico con cui una piccola azienda può coprire notti e weekend senza finanziare un centro operativo interno.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus