Kort sagt: En tidslinje för en it-incident ordnar alla observationer, beslut och åtgärder kronologiskt i en enhetlig tidszon, helst UTC. Varje rad anger källa, observation, belägg och en bedömning som belagd, sannolik eller okänd. Så uppstår en spårbar bild av när angriparen fanns i systemet, vad han kunde nå och när ni hade kännedom om det.
Varför alla till slut frågar efter när
Efter en incident kommer frågorna från alla håll. Dataskyddsombudet vill veta sedan när personuppgifter var nåbara. Försäkringsgivaren frågar när skadan upptäcktes och anmäldes. Ledningen vill veta om sårbarheten redan var öppen före den senaste uppdateringen. Alla de frågorna har något gemensamt: de handlar om tidpunkter.
Utan tidslinje besvarar var och en frågorna ur minnet, och svaren motsäger varandra. Med en ordentligt förd tidslinje finns en gemensam grund som alla inblandade kan hänvisa till. Den är samtidigt stommen för slutrapporten.
Vid PHP2Shell är tidslinjen särskilt talande, eftersom de offentliga huvuddatumen är väl dokumenterade. De går att lägga som ankarpunkter bredvid de egna observationerna. Hela förloppet av de offentliga händelserna beskriver guiden PHP2Shell: kronologin.
Uppbyggnaden: vilka kolumner en tidslinje behöver
En tabell räcker, i ett kalkylprogram eller ett gemensamt dokument. Viktiga är fasta kolumner som fylls i för varje rad. Mönstret nedan visar de offentliga PHP2Shell-huvuddatumen som ankare och under dem typiska egna poster i platshållarform:
| Tid (UTC) | Källa | Observation | Belägg | Bedömning |
|---|---|---|---|---|
| 17.10.2026 | Mediarapporter | första observerade angreppsförsöket mot PHP2Shell | Pressrapport | belagd som mediarapport |
| 20.10.2026 | php.net | förhandsmeddelande om säkerhetsuppdateringarna | Meddelande på php.net | belagd |
| 21.10.2026, 14:00 | php.net | publicering av 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Meddelande på php.net | belagd |
| egen tid | Access-logg | ökning av fel 500 på normala sidor | Loggutdrag, radnummer | sannolikt relevant |
| egen tid | Filsystem | ny PHP-fil i uppladdningsmappen | Kopia med kontrollsumma | belagd, tidpunkt osäker |
| egen tid | internt | incidenten märkt, ledningen informerad | E-post, samtalsanteckning | belagd |
| egen tid | internt | uppdatering installerad, alla workers omstartade | Paketlogg, processlista | belagd |
Kolumnen Bedömning är den viktigaste delen. Den skiljer på vad som är styrkt, vad som framstår som rimligt och vad som förblir öppet. Senare läsare ser då direkt var tidslinjen bär och var luckor finns.
Tidslinje för en it-incident: sammanför källorna
Posterna kommer från många källor som var och en har egna format och tidszoner. Gå fram i den här ordningen:
- Fastställ tidszonen: För allt i UTC. Övergången till vintertid den 25 oktober 2026 förskjuter tyska lokala tider med en timme mitt i tidsperioden. Den som blandar lokala tider förskjuter händelser obemärkt.
- Kontrollera klockorna: Gick serverns klocka rätt? En jämförelse med en känd händelse, till exempel den egna inloggningen, visar avvikelser.
- Externa källor först: Loggar från CDN, WAF, webbhotell eller brandvägg ligger utanför servern och är svåra att manipulera. De utgör stommen.
- Komplettera med serverloggar: Webbserver, PHP-FPM, inloggningar, systemjournal. Metoden för det beskriver Analysera webbserverloggar efter ett angrepp.
- Placera in filsystemet: Lägg till tidsstämplar för nya och ändrade filer som fingervisningar.
- För in interna händelser: När märktes något, vem informerades, vilket beslut fattades när?
Vad filernas tidsstämplar avslöjar och vad de inte gör
Linux lagrar flera tidpunkter för varje fil, bland annat den senaste ändringen av innehållet (mtime) och den senaste ändringen av metadata (ctime). Båda går att skriva ut läsande, här som en lista över PHP-filer ändrade sedan ett stickdatum, sorterad efter tid i UTC:
# Innehållsändringar sedan 17.10.2026, sorterade, i UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Alla tidsstämplar för en enskild fil
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Arbeta då bara på en kopia eller en säkrad avbildning, som beskrivs i Säkra bevis innan ni installerar om. Tänk på två begränsningar. För det första kan en angripare återställa en fils ändringsdatum med enkla medel; en oansenlig mtime är ingen friskrivning. För det andra ändrar kopieringsförlopp och vissa verktyg tidsstämplar. Därför gäller: filtider är fingervisningar, loggposter utifrån är belägg.
För in tidpunkten då ert företag fick kännedom om ett möjligt dataintrång. Enligt art. 33 GDPR börjar fristen på 72 timmar för en anmälan i princip med kännedomen. Bedömningen hör hemma hos ert dataskyddsombud eller en jurist.
Typiska fel och hur ni undviker dem
De vanligaste felen är föga spektakulära. Tidslinjen rekonstrueras först i slutet ur minnet i stället för att föras löpande. Posterna innehåller slutsatser i stället för observationer, till exempel ”Angriparen kom in via formuläret” i stället för ”POST-förfrågan mot formuläret, därefter ny fil”. Och belägg saknas eftersom ingen har antecknat vilken loggfil och vilken rad en post kommer från.
Utse därför en person som för tidslinjen och för in händelser så snart de inträffar. Slutsatser hör hemma i en egen kolumn eller i rapporten, inte i observationen.
Behandla dessutom tidslinjen som ett konfidentiellt dokument. Den innehåller ofta IP-adresser, användarnamn och ledtrådar till svagheter. Bestäm vem som får läsa och ändra den och spara tidigare versioner. Om en bedömning ändras, till exempel för att ett nytt loggutdrag dyker upp, skrivs den gamla raden inte över utan kompletteras. Så förblir det spårbart vad som var känt vid vilken tidpunkt och på vilken grund beslut fattades.
Hur hjälper PHP SOS konkret?
- Vi för tidslinjen löpande från första kontakten och i UTC, med källa och belägg för varje post.
- Vi analyserar externa loggar, serverloggar och filsystem tillsammans och märker varje uppgift som belagd, sannolik eller okänd.
- Vid behov tar vi tillsammans med specialiserade partner hand om IT-forensiken för en analys som håller i domstol.
- Vi överlämnar tidslinjen som en del av en rapport till ledning, dataskydd och försäkring.
Vanliga frågor
Varför behöver jag en tidslinje efter en säkerhetsincident?
Den ordnar alla observationer i en följd och visar när angriparen fanns i systemet, vad han kunde nå och när ni fick kännedom om det. De uppgifterna behöver dataskyddsombud, försäkringsgivare, myndigheter och ledningen för sina beslut.
I vilken tidszon bör jag föra tidslinjen?
Enhetligt i UTC. Servrar, tjänster och meddelanden använder olika tidszoner, och övergången till vintertid i slutet av oktober förskjuter dessutom lokala tider. Den som räknar om allt till UTC och bara kompletterar med lokal tid undviker fel vid avstämningen.
Kan jag lita på filernas tidsstämplar?
Bara med förbehåll. En fils ändringsdatum går att förfalska med enkla medel. Tillförlitligare är poster i loggar, särskilt loggar utanför den berörda servern. Filernas tidsstämplar är fingervisningar som bör bekräftas av andra källor.
Vad hör hemma i tidslinjen utöver tekniska händelser?
Även beslut och kommunikation: när incidenten märktes, vem som informerades, när servern kopplades bort från nätet, när patchen installerades. Just tidpunkten för kännedom är viktig för anmälningsfrister.