- Inizio
- Metodo
Metodo di lavoro
Queste abitudini non le abbiamo scritte per il sito: vengono dagli appunti di lavoro, dove si ripetono progetto dopo progetto. Servono a una cosa sola, far sì che chi ci affida i propri sistemi sappia sempre che cosa stiamo facendo, su quali prove e con quale via d’uscita.
Le abitudini che non cambiano
-
Prima si misura, poi si afferma
Ogni conclusione si regge su un dato: un log, una misura, una prova che si può ripetere. Quando qualcosa è stimato o dedotto, lo scriviamo accanto al numero. Il carico di un server si legge dalla pressione su memoria e CPU, non dalla media di carico; lo spazio di un volume si legge sul volume, non nella cache della console.
-
Sola lettura, finché non serve altro
Indagini, verifiche, inventari e monitoraggio lavorano in sola lettura. Un sistema si tocca solo quando c’è un motivo e un piano, e i comandi che cambiano qualcosa sugli apparati del cliente si eseguono così come concordati, senza «prove» fuori programma.
-
La via del ritorno prima della modifica
Prima di cambiare qualcosa in esercizio si prepara il ritorno: la copia della configurazione, un ripristino automatico programmato che riapre l’accesso se la modifica su un firewall non regge, la versione precedente di un’applicazione pronta da rimettere. Chi lavora a distanza non deve mai chiudersi fuori.
-
Un cruscotto verde non basta
Molti guasti non fanno rumore: un certificato scaduto che ferma la raccolta dei log, un antivirus installato ma spento, un backup che fallisce da settimane. Per questo controlliamo l’effetto reale (l’ultimo dato ricevuto da ogni sorgente, il servizio che risponde, la protezione attiva) e non solo il semaforo.
-
Solo dati veri
Nelle piattaforme che costruiamo, anche nelle prove e nei collaudi, ogni numero e ogni oggetto sullo schermo risale a un dato scaricato da una fonte reale. Quando qualcosa è modellato o dedotto, come la forma di un oggetto in una scena 3D, lo dichiariamo e lo teniamo separato dalle misure. Un dato mancante si mostra come mancante, non si inventa.
-
Impronta minima verso l'esterno
Ciò che si vede da Internet deve essere il minimo indispensabile: niente versioni, niente nomi di prodotto, errori generici, amministrazione dietro VPN. Vale anche per questo sito: pagine statiche, nessun codice che gira sul server, nessuna risorsa caricata da altri siti.
-
Tutto scritto
Passaggi, decisioni e misure restano documentati nel fascicolo del progetto, non in una chat o nella memoria di qualcuno. Chi viene dopo, compreso il cliente, deve poter capire che cosa è stato fatto e perché, e rifarlo.
-
Il rilascio lo decide il cliente
Si prova prima su una postazione o su un ambiente di prova, si mostra il risultato e si rilascia quando il cliente dà il via. Vale per una barra telefonica come per un portale.
Quando c'è un incidente
La sequenza che seguiamo nella risposta a un incidente informatico. L’ordine conta: ogni passo protegge quello successivo.
-
Contenere
Isolare i sistemi coinvolti senza distruggere le prove: si stacca dalla rete, non si spegne una macchina che ha ancora in memoria ciò che serve.
-
Conservare le prove
Memoria, istantanee, raccolta mirata, immagini dei dischi solo se servono; hash SHA-256 e catena di custodia, lavoro sempre sulle copie.
-
Ricostruire
Cronologia, punto d’ingresso, persistenza, che cosa è stato letto o portato via, separando ciò che è dimostrato da ciò che è solo dichiarato.
-
Delimitare i dati
Categorie e quantità dei dati coinvolti, dati particolari, ruoli di titolare e responsabile: la base per decidere le notifiche.
-
Notificare
Bozze per il Garante, per ACN e CSIRT Italia quando si applica la NIS2, per gli interessati quando il rischio è elevato, con le scadenze calcolate.
-
Ripristinare e chiudere
Bonifica, rotazione verificata delle credenziali, riduzione dell’esposizione e i controlli che servono per non ricadere nello stesso guasto.