In breve: la cronologia di un incidente IT ordina in sequenza tutte le osservazioni, decisioni e misure in un fuso orario uniforme, idealmente UTC. Ogni riga indica fonte, osservazione, prova e una valutazione come provata, probabile o sconosciuta. Ne nasce un quadro verificabile di quando l'aggressore era nel sistema, che cosa poteva raggiungere e quando Lei ne ha avuto conoscenza.
Perché alla fine tutti chiedono il quando
Dopo un incidente le domande arrivano da ogni parte. Il responsabile della protezione dei dati vuole sapere da quando i dati personali erano raggiungibili. L'assicuratore chiede quando il danno è stato scoperto e segnalato. La direzione vuole sapere se la falla era aperta già prima dell'ultimo aggiornamento. Tutte queste domande hanno una cosa in comune: ruotano intorno a momenti precisi.
Senza cronologia ciascuno risponde a queste domande a memoria, e le risposte si contraddicono. Con una cronologia tenuta in modo ordinato esiste una base comune a cui si riferiscono tutti i partecipanti. È anche l'ossatura della relazione finale.
Con PHP2Shell la cronologia è particolarmente significativa, perché i dati pubblici essenziali sono ben documentati. Si possono affiancare alle proprie osservazioni come punti di ancoraggio. La sequenza completa degli eventi pubblici la descrive la guida PHP2Shell: la cronologia.
La struttura: di quali colonne ha bisogno una cronologia
Basta una tabella, in un foglio di calcolo o in un documento condiviso. Contano colonne fisse, compilate per ogni riga. Il modello seguente mostra i dati pubblici essenziali di PHP2Shell come ancoraggio e sotto voci tipiche proprie in forma di segnaposto:
| Ora (UTC) | Fonte | Osservazione | Prova | Valutazione |
|---|---|---|---|---|
| 17/10/2026 | Notizie dei media | primo tentativo di attacco osservato su PHP2Shell | articolo di stampa | provato come notizia dei media |
| 20/10/2026 | php.net | preannuncio degli aggiornamenti di sicurezza | avviso su php.net | provato |
| 21/10/2026, 14:00 | php.net | pubblicazione di 8.5.12, 8.4.27, 8.3.36, 8.2.35 | avviso su php.net | provato |
| ora propria | access log | aumento di errori 500 su pagine normali | estratto del log, numero di riga | probabilmente rilevante |
| ora propria | file system | nuovo file PHP nella cartella degli upload | copia con checksum | provato, momento incerto |
| ora propria | interna | incidente notato, direzione informata | e-mail, appunto del colloquio | provato |
| ora propria | interna | aggiornamento applicato, tutti i worker riavviati | log dei pacchetti, elenco dei processi | provato |
La colonna Valutazione è la parte più importante. Separa ciò che è dimostrato, ciò che appare plausibile e ciò che resta aperto. I lettori successivi vedono subito dove la cronologia regge e dove ci sono lacune.
Cronologia di un incidente IT: riunire le fonti
Le voci provengono da molte fonti, ciascuna con formati e fusi orari propri. Proceda in quest'ordine:
- Stabilire il fuso orario: tenere tutto in UTC. Il passaggio all'ora solare il 25/10/2026 sposta di un'ora gli orari locali tedeschi in mezzo al periodo. Chi mescola orari locali sposta gli eventi senza accorgersene.
- Verificare gli orologi: l'orologio del server andava bene? Il confronto con un evento noto, ad esempio il proprio login, mostra le discrepanze.
- Prima le fonti esterne: i log di CDN, WAF, hoster o firewall si trovano fuori dal server e sono difficili da manipolare. Costituiscono l'ossatura.
- Integrare i log del server: server web, PHP-FPM, accessi, journal di sistema. La metodologia è descritta in Analizzare i log del server web dopo un attacco.
- Inquadrare il file system: aggiungere come indizi i timestamp dei file nuovi e modificati.
- Registrare gli eventi interni: quando è stato notato qualcosa, chi è stato informato, quale decisione è stata presa e quando?
Che cosa rivelano i timestamp dei file e che cosa no
Linux memorizza per ogni file più momenti, tra cui l'ultima modifica del contenuto (mtime) e l'ultima modifica dei metadati (ctime). Entrambi si possono visualizzare in sola lettura, qui come elenco dei file PHP modificati da una data di riferimento, ordinato per ora in UTC:
# Modifiche di contenuto dal 17/10/2026, ordinate, in UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Tutti i timestamp di un singolo file
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Lavori solo su una copia o su un'immagine messa al sicuro, come descritto in Conservare le prove prima di reinstallare. Tenga presenti due limiti. Primo, un aggressore può reimpostare con mezzi semplici la data di modifica di un file; una mtime insospettabile non è un'assoluzione. Secondo, le operazioni di copia e alcuni strumenti modificano i timestamp. Vale quindi: gli orari dei file sono indizi, le voci di log provenienti dall'esterno sono prove.
Annoti il momento in cui la Sua azienda ha saputo di una possibile violazione dei dati. Secondo l'art. 33 GDPR, il termine di 72 ore per una notifica decorre in linea di principio dalla conoscenza. La valutazione spetta al Suo responsabile della protezione dei dati o a un avvocato.
Errori tipici e come evitarli
Gli errori più frequenti sono poco spettacolari. La cronologia viene ricostruita solo alla fine a memoria, invece di essere tenuta in corso d'opera. Le voci contengono conclusioni invece di osservazioni, ad esempio «l'aggressore è entrato dal modulo» invece di «richiesta POST al modulo, poi nuovo file». E mancano le prove, perché nessuno ha annotato da quale file di log e da quale riga proviene una voce.
Designi quindi una persona che tenga la cronologia e registri gli eventi non appena si verificano. Le conclusioni vanno in una colonna a parte o nella relazione, non nell'osservazione.
Tratti inoltre la cronologia come un documento riservato. Contiene spesso indirizzi IP, nomi utente e indicazioni su punti deboli. Stabilisca chi può leggerla e modificarla e conservi le versioni precedenti. Se una valutazione cambia, ad esempio perché emerge un nuovo estratto di log, la vecchia riga non viene sovrascritta ma integrata. Così resta verificabile che cosa era noto in quale momento e su quale base è stato deciso.
Come aiuta PHP SOS in concreto?
- Teniamo la cronologia in corso d'opera dal primo contatto e in UTC, con fonte e prova per ogni voce.
- Analizziamo insieme log esterni, log del server e file system e contrassegniamo ogni affermazione come provata, probabile o sconosciuta.
- Se necessario, con partner specializzati ci occupiamo dell'IT forensics per un'analisi utilizzabile in giudizio.
- Consegniamo la cronologia come parte di una relazione per direzione, protezione dei dati e assicurazione.
Domande frequenti
A che cosa mi serve una cronologia dopo un incidente di sicurezza?
Mette in ordine tutte le osservazioni e mostra quando l'aggressore era nel sistema, che cosa poteva raggiungere e quando Lei ne è venuto a conoscenza. Queste informazioni servono ai responsabili della protezione dei dati, agli assicuratori, alle autorità e alla direzione per le proprie decisioni.
In quale fuso orario devo tenere la cronologia?
In modo uniforme in UTC. Server, servizi e segnalazioni usano fusi orari diversi, e il passaggio all'ora solare a fine ottobre sposta inoltre gli orari locali. Chi converte tutto in UTC e aggiunge l'ora locale solo come complemento evita errori nel confronto.
Posso fidarmi dei timestamp dei file?
Solo in parte. La data di modifica di un file si può falsificare con mezzi semplici. Più affidabili sono le voci nei log, soprattutto nei log fuori dal server interessato. I timestamp dei file sono indizi da confermare con altre fonti.
Oltre agli eventi tecnici, che cosa rientra nella cronologia?
Anche decisioni e comunicazioni: quando l'incidente è stato notato, chi è stato informato, quando il server è stato scollegato dalla rete, quando è stata applicata la patch. Proprio il momento della conoscenza è importante per i termini di notifica.