Kort gezegd: Een tijdlijn van een IT-incident ordent alle waarnemingen, beslissingen en maatregelen chronologisch in één uniforme tijdzone, bij voorkeur UTC. Elke regel noemt bron, waarneming, bewijs en een beoordeling als aangetoond, waarschijnlijk of onbekend. Zo ontstaat een navolgbaar beeld van wanneer de aanvaller in het systeem zat, wat hij kon bereiken en wanneer u daarvan kennis had.
Waarom uiteindelijk iedereen naar het tijdstip vraagt
Na een incident komen de vragen van alle kanten. De functionaris voor gegevensbescherming wil weten sinds wanneer persoonsgegevens bereikbaar waren. De verzekeraar vraagt wanneer de schade is ontdekt en gemeld. De directie wil weten of de kwetsbaarheid al vóór de laatste update openstond. Al deze vragen hebben iets gemeen: ze draaien om tijdstippen.
Zonder tijdlijn beantwoordt ieder deze vragen uit het geheugen en spreken de antwoorden elkaar tegen. Met een zorgvuldig bijgehouden tijdlijn is er een gemeenschappelijke basis waarnaar alle betrokkenen verwijzen. Ze is tevens het skelet van het eindrapport.
Bij PHP2Shell is de tijdlijn bijzonder veelzeggend, omdat de openbare hoofdgegevens goed gedocumenteerd zijn. Ze zijn als ankerpunten naast de eigen waarnemingen te leggen. De volledige opeenvolging van de openbare gebeurtenissen beschrijft de gids PHP2Shell: de chronologie.
De opbouw: welke kolommen een tijdlijn nodig heeft
Een tabel volstaat, in een spreadsheet of een gedeeld document. Belangrijk zijn vaste kolommen die voor elke regel worden ingevuld. Het volgende voorbeeld toont de openbare PHP2Shell-hoofdgegevens als anker en daaronder typische eigen vermeldingen in de vorm van plaatshouders:
| Tijd (UTC) | Bron | Waarneming | Bewijs | Beoordeling |
|---|---|---|---|---|
| 17-10-2026 | Mediaberichten | eerste waargenomen aanvalspoging op PHP2Shell | Persbericht | aangetoond als mediabericht |
| 20-10-2026 | php.net | Voorafgaande aankondiging van de beveiligingsupdates | Melding op php.net | aangetoond |
| 21-10-2026, 14:00 | php.net | Publicatie van 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Melding op php.net | aangetoond |
| eigen tijd | Access-log | Toename van 500-fouten op normale pagina's | Logfragment, regelnummer | waarschijnlijk relevant |
| eigen tijd | Bestandssysteem | nieuw PHP-bestand in de uploadmap | Kopie met controlesom | aangetoond, tijdstip onzeker |
| eigen tijd | intern | Incident opgemerkt, directie geïnformeerd | Mail, gespreksnotitie | aangetoond |
| eigen tijd | intern | Update geïnstalleerd, alle workers herstart | Pakketlog, procesoverzicht | aangetoond |
De kolom Beoordeling is het belangrijkste deel. Ze scheidt wat is aangetoond, wat aannemelijk lijkt en wat open blijft. Latere lezers zien zo meteen waar de tijdlijn standhoudt en waar hiaten zijn.
Tijdlijn van een IT-incident: bronnen samenvoegen
De vermeldingen komen uit vele bronnen met elk eigen formaten en tijdzones. Ga in deze volgorde te werk:
- Tijdzone vastleggen: alles in UTC bijhouden. De overgang naar wintertijd op 25-10-2026 verschuift de plaatselijke tijden in Duitsland midden in de periode met een uur. Wie plaatselijke tijden vermengt, verschuift gebeurtenissen ongemerkt.
- Klokken controleren: liep de klok van de server goed? Een vergelijking met een bekende gebeurtenis, bijvoorbeeld de eigen login, toont afwijkingen.
- Externe bronnen eerst: logs van CDN, WAF, hostingprovider of firewall liggen buiten de server en zijn moeilijk te manipuleren. Ze vormen het skelet.
- Serverlogs aanvullen: webserver, PHP-FPM, aanmeldingen, systeemjournaal. De methodiek daarvoor beschrijft Webserverlogs na een aanval analyseren.
- Bestandssysteem plaatsen: tijdstempels van nieuwe en gewijzigde bestanden als aanwijzingen aanvullen.
- Interne gebeurtenissen invoeren: wanneer is iets opgemerkt, wie is geïnformeerd, welke beslissing viel wanneer?
Wat tijdstempels van bestanden wel en niet verraden
Linux slaat voor elk bestand meerdere tijdstippen op, onder andere de laatste wijziging van de inhoud (mtime) en de laatste wijziging van de metagegevens (ctime). Beide zijn alleen-lezen op te vragen, hier als lijst van sinds een peildatum gewijzigde PHP-bestanden, gesorteerd op tijd in UTC:
# Inhoudswijzigingen sinds 17-10-2026, gesorteerd, in UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Alle tijdstempels van één enkel bestand
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Werk daarbij alleen op een kopie of een veiliggestelde schijfkopie, zoals beschreven onder Bewijs veiligstellen voordat u opnieuw opzet. Houd rekening met twee grenzen. Ten eerste kan een aanvaller de wijzigingsdatum van een bestand met eenvoudige middelen terugzetten; een onopvallende mtime is geen vrijspraak. Ten tweede wijzigen kopieerbewerkingen en sommige tools tijdstempels. Daarom geldt: bestandstijden zijn aanwijzingen, logvermeldingen van buitenaf zijn bewijs.
Noteer het moment waarop uw bedrijf van een mogelijk datalek hoorde. Volgens art. 33 AVG begint de termijn van 72 uur voor een melding in beginsel bij de kennisname. De beoordeling is aan uw functionaris voor gegevensbescherming of een advocaat.
Typische fouten en hoe u ze voorkomt
De meest voorkomende fouten zijn onopvallend. De tijdlijn wordt pas aan het eind uit het geheugen gereconstrueerd, in plaats van doorlopend te worden bijgehouden. Vermeldingen bevatten conclusies in plaats van waarnemingen, bijvoorbeeld „aanvaller kwam binnen via het formulier" in plaats van „POST-verzoek naar het formulier, daarna nieuw bestand". En bewijs ontbreekt omdat niemand heeft genoteerd uit welk logbestand en welke regel een vermelding komt.
Wijs daarom één persoon aan die de tijdlijn bijhoudt en voer gebeurtenissen in zodra ze zich voordoen. Conclusies horen in een aparte kolom of in het rapport, niet in de waarneming.
Behandel de tijdlijn bovendien als vertrouwelijk document. Ze bevat vaak IP-adressen, gebruikersnamen en aanwijzingen over zwakke plekken. Bepaal wie haar mag lezen en wijzigen, en bewaar eerdere versies. Verandert een inschatting, bijvoorbeeld doordat een nieuw logfragment opduikt, dan wordt de oude regel niet overschreven maar aangevuld. Zo blijft navolgbaar wat op welk moment bekend was en op welke grond is besloten.
Hoe helpt PHP SOS concreet?
- Wij houden de tijdlijn vanaf het eerste contact doorlopend bij en in UTC, met bron en bewijs bij elke vermelding.
- Wij analyseren externe logs, serverlogs en bestandssysteem samen en markeren elke uitspraak als aangetoond, waarschijnlijk of onbekend.
- Zo nodig nemen wij met gespecialiseerde partners het IT-forensisch onderzoek over voor een analyse die voor de rechter bruikbaar is.
- Wij leveren de tijdlijn als onderdeel van een rapport voor directie, gegevensbescherming en verzekering.
Veelgestelde vragen
Waarvoor heb ik na een beveiligingsincident een tijdlijn nodig?
Ze brengt alle waarnemingen in een volgorde en laat zien wanneer de aanvaller in het systeem zat, wat hij kon bereiken en wanneer u ervan hoorde. Deze gegevens hebben functionarissen voor gegevensbescherming, verzekeraars, autoriteiten en de directie nodig voor hun beslissingen.
In welke tijdzone moet ik de tijdlijn bijhouden?
Uniform in UTC. Servers, diensten en meldingen gebruiken verschillende tijdzones en de overgang naar wintertijd eind oktober verschuift plaatselijke tijden bovendien. Wie alles naar UTC omrekent en de plaatselijke tijd alleen aanvult, voorkomt fouten bij het vergelijken.
Kan ik afgaan op de tijdstempels van bestanden?
Slechts beperkt. De wijzigingsdatum van een bestand is met eenvoudige middelen te vervalsen. Betrouwbaarder zijn vermeldingen in logs, vooral logs buiten de getroffen server. Tijdstempels van bestanden zijn aanwijzingen die u met andere bronnen moet bevestigen.
Wat hoort er behalve technische gebeurtenissen in de tijdlijn?
Ook beslissingen en communicatie: wanneer het incident werd opgemerkt, wie werd geïnformeerd, wanneer de server van het netwerk ging, wanneer er is gepatcht. Juist het moment van kennisname is voor meldtermijnen belangrijk.