Lyhyesti: IT-tapauksen aikajana järjestää kaikki havainnot, päätökset ja toimet aikajärjestykseen yhtenäisessä aikavyöhykkeessä, mieluiten UTC:ssä. Jokainen rivi nimeää lähteen, havainnon, todisteen ja arvion: todistettu, todennäköinen tai tuntematon. Näin syntyy jäljitettävä kuva siitä, milloin hyökkääjä oli järjestelmässä, mihin hän pääsi käsiksi ja milloin teillä oli asiasta tieto.
Miksi lopulta kaikki kysyvät milloin
Tapauksen jälkeen kysymyksiä tulee joka suunnasta. Tietosuojavastaava haluaa tietää, mistä lähtien henkilötiedot olivat saavutettavissa. Vakuutusyhtiö kysyy, milloin vahinko havaittiin ja ilmoitettiin. Johto haluaa tietää, oliko aukko auki jo ennen viimeisintä päivitystä. Kaikilla näillä kysymyksillä on yhteistä: ne koskevat ajankohtia.
Ilman aikajanaa jokainen vastaa näihin muistinvaraisesti, ja vastaukset ovat ristiriitaisia. Huolellisesti ylläpidetty aikajana tarjoaa yhteisen perustan, johon kaikki osalliset voivat viitata. Se on samalla loppuraportin runko.
PHP2Shellin kohdalla aikajana on erityisen kertova, koska julkiset keskeiset päivämäärät on dokumentoitu hyvin. Ne voi asettaa ankkuripisteiksi omien havaintojenne rinnalle. Julkisten tapahtumien täyden kulun kuvaa opas PHP2Shell: kronologia.
Rakenne: mitä sarakkeita aikajana tarvitsee
Taulukko riittää, olipa se taulukkolaskennassa tai yhteisessä asiakirjassa. Tärkeää on kiinteät sarakkeet, jotka täytetään jokaiselle riville. Seuraava malli näyttää julkiset PHP2Shellin keskeiset päivämäärät ankkureina ja niiden alla tyypillisiä omia merkintöjä paikkamerkkimuodossa:
| Aika (UTC) | Lähde | Havainto | Todiste | Arvio |
|---|---|---|---|---|
| 17.10.2026 | mediaraportit | ensimmäinen havaittu hyökkäysyritys PHP2Shelliä vastaan | lehtiraportti | todistettu mediaraporttina |
| 20.10.2026 | php.net | tietoturvapäivitysten ennakkoilmoitus | ilmoitus php.netissä | todistettu |
| 21.10.2026, 14:00 | php.net | versioiden 8.5.12, 8.4.27, 8.3.36, 8.2.35 julkaisu | ilmoitus php.netissä | todistettu |
| oma aika | Access-loki | 500-virheiden kasaantuminen tavallisilla sivuilla | lokiote, rivinumero | todennäköisesti olennainen |
| oma aika | tiedostojärjestelmä | uusi PHP-tiedosto upload-kansiossa | kopio tarkistussummalla | todistettu, ajankohta epävarma |
| oma aika | sisäinen | tapaus huomattu, johto informoitu | sähköposti, keskustelumuistio | todistettu |
| oma aika | sisäinen | päivitys asennettu, kaikki workerit käynnistetty uudelleen | pakettiloki, prosessilista | todistettu |
Arvio-sarake on tärkein osa. Se erottaa, mikä on todistettu, mikä vaikuttaa uskottavalta ja mikä jää avoimeksi. Myöhemmät lukijat näkevät heti, missä aikajana kantaa ja missä on aukkoja.
IT-tapauksen aikajana: lähteiden yhdistäminen
Merkinnät tulevat monista lähteistä, joilla on omat muotonsa ja aikavyöhykkeensä. Edetkää tässä järjestyksessä:
- Aikavyöhykkeen määrittäminen: Pitäkää kaikki UTC:ssä. Talviaikaan siirtyminen 25.10.2026 siirtää Saksan paikallisaikoja tunnilla kesken tarkasteluajanjakson. Joka sekoittaa paikallisaikoja, siirtää tapahtumia huomaamattaan.
- Kellojen tarkistus: Kävikö palvelimen kello oikein? Vertailu tunnettuun tapahtumaan, kuten omaan kirjautumiseen, paljastaa poikkeamat.
- Ulkoiset lähteet ensin: CDN:n, WAF:n, hosting-palveluntarjoajan tai palomuurin lokit ovat palvelimen ulkopuolella, ja niitä on vaikea manipuloida. Ne muodostavat rungon.
- Palvelinlokit täydennykseksi: Verkkopalvelin, PHP-FPM, kirjautumiset, järjestelmäpäiväkirja. Menetelmän kuvaa Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen.
- Tiedostojärjestelmän sijoittaminen: Lisätkää uusien ja muuttuneiden tiedostojen aikaleimat vihjeinä.
- Sisäisten tapahtumien kirjaus: Milloin jotain huomattiin, ketä informoitiin, mikä päätös tehtiin milloin?
Mitä tiedostojen aikaleimat paljastavat ja mitä eivät
Linux tallentaa jokaisesta tiedostosta useita ajankohtia, muun muassa sisällön viimeisen muutoksen (mtime) ja metatietojen viimeisen muutoksen (ctime). Molemmat voi tulostaa lukien, tässä luettelona tiettynä päivänä jälkeen muuttuneista PHP-tiedostoista, lajiteltuna UTC-ajan mukaan:
# Sisältömuutokset 17.10.2026 alkaen, lajiteltuna, UTC-ajassa
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Yksittäisen tiedoston kaikki aikaleimat
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Työskennelkää tässä vain kopiolla tai varmistetulla levykuvalla, kuten kirjoituksessa Varmistakaa todisteet ennen palvelimen uudelleenasennusta kuvataan. Huomatkaa kaksi rajoitusta. Ensinnäkin hyökkääjä voi nollata tiedoston muutospäivämäärän yksinkertaisin keinoin; huomaamaton mtime ei ole vapauttava todiste. Toiseksi kopiointi ja jotkin työkalut muuttavat aikaleimoja. Siksi pätee: tiedostojen ajat ovat vihjeitä, ulkopuoliset lokimerkinnät ovat todisteita.
Kirjatkaa ajankohta, jolloin yrityksenne sai tiedon mahdollisesta tietomurrosta. GDPR:n 33 artiklan mukaan ilmoituksen 72 tunnin määräaika alkaa pääsääntöisesti tiedonsaannista. Arviointi kuuluu tietosuojavastaavalle tai asianajajalle.
Tyypilliset virheet ja miten ne vältetään
Yleisimmät virheet ovat vaatimattomia. Aikajana rekonstruoidaan vasta lopussa muistinvaraisesti sen sijaan, että sitä pidettäisiin jatkuvasti. Merkinnät sisältävät johtopäätöksiä havaintojen sijaan, esimerkiksi ”hyökkääjä tuli lomakkeen kautta” sen sijaan että kirjattaisiin ”POST-pyyntö lomakkeelle, sen jälkeen uusi tiedosto”. Ja todisteet puuttuvat, koska kukaan ei kirjannut, mistä lokitiedostosta ja miltä riviltä merkintä on peräisin.
Nimetkää siksi yksi henkilö, joka ylläpitää aikajanaa, ja kirjatkaa tapahtumat heti niiden ilmetessä. Johtopäätökset kuuluvat omaan sarakkeeseensa tai raporttiin, eivät havaintoon.
Käsitelkää aikajanaa lisäksi luottamuksellisena asiakirjana. Se sisältää usein IP-osoitteita, käyttäjänimiä ja viitteitä haavoittuvuuksiin. Määrittäkää, kuka saa lukea ja muuttaa sitä, ja säilyttäkää aiemmat versiot. Jos arvio muuttuu, esimerkiksi uuden lokiotteen ilmaantuessa, vanhaa riviä ei ylikirjoiteta vaan sitä täydennetään. Näin säilyy jäljitettävyys siitä, mikä oli tiedossa milloinkin ja millä perusteella päätettiin.
Miten PHP SOS auttaa konkreettisesti?
- Ylläpidämme aikajanaa ensimmäisestä yhteydenotosta alkaen jatkuvasti ja UTC-ajassa, lähde ja todiste jokaisessa merkinnässä.
- Arvioimme ulkoiset lokit, palvelinlokit ja tiedostojärjestelmän yhdessä ja merkitsemme jokaisen väitteen todistetuksi, todennäköiseksi tai tuntemattomaksi.
- Tarvittaessa hoidamme erikoistuneiden kumppanien kanssa IT-rikostekniikan oikeudessa käyttökelpoista arviointia varten.
- Luovutamme aikajanan osana raporttia johdolle, tietosuojalle ja vakuutusyhtiölle.
Usein kysytyt kysymykset
Miksi tarvitsen aikajanan tietoturvapoikkeaman jälkeen?
Se asettaa kaikki havainnot järjestykseen ja osoittaa, milloin hyökkääjä oli järjestelmässä, mihin hän pääsi käsiksi ja milloin saitte asiasta tiedon. Näitä tietoja tarvitsevat tietosuojavastaavat, vakuutusyhtiöt, viranomaiset ja johto päätöksiään varten.
Missä aikavyöhykkeessä aikajanaa pitäisi ylläpitää?
Yhtenäisesti UTC-ajassa. Palvelimet, palvelut ja ilmoitukset käyttävät eri aikavyöhykkeitä, ja talviaikaan siirtyminen lokakuun lopussa siirtää paikallisaikoja lisää. Kun kaikki muunnetaan UTC:hen ja paikallinen aika lisätään vain täydennyksenä, vältytään vertailuvirheiltä.
Voinko luottaa tiedostojen aikaleimoihin?
Vain rajallisesti. Tiedoston muutospäivämäärä voidaan väärentää yksinkertaisin keinoin. Luotettavampia ovat lokien merkinnät, erityisesti vaikutuksen alaisen palvelimen ulkopuolella olevissa lokeissa. Tiedostojen aikaleimat ovat vihjeitä, jotka pitäisi vahvistaa muilla lähteillä.
Mitä aikajanaan kuuluu teknisten tapahtumien lisäksi?
Myös päätökset ja viestintä: milloin tapaus huomattiin, ketä informoitiin, milloin palvelin irrotettiin verkosta, milloin päivitys tehtiin. Juuri tiedonsaannin hetki on tärkeä ilmoitusmääräaikojen kannalta.