Dokazi, sledljivost in forenzika
ČASOVNI ŽIG NI ČAS DOGODKA
Zakaj pravilna časovna os zahteva več kot urejene zapise v dnevniku
V treh sistemih je isti dogodek zapisan trikrat.
Aplikacija ga zabeleži ob 10:14:07.842. Strežnik, ki sprejme zahtevo, zapiše 08:14:08Z. Osrednji sistem za zbiranje dnevnikov dogodek prejme ob 08:14:41Z.
Vsi trije zapisi so lahko pravilni. Prvi lahko uporablja lokalni čas, drugi UTC, tretji pa ne beleži trenutka nastanka dogodka, temveč trenutek prejema zapisa. Razlika med njimi zato še ne pomeni napake. Pomeni pa, da same številke ne zadoščajo za sestavo časovne osi.
Pri običajnem delu nekaj sekund pogosto nima posebnega pomena. Pri rekonstrukciji incidenta, preverjanju dostopa ali ugotavljanju zaporedja sprememb pa je lahko prav teh nekaj sekund meja med vzrokom in posledico.
Časovni žig je videti kot dejstvo. V resnici je meritev, ki jo je ustvarila določena ura v določenem sistemu in za določen namen.
Natančnost še ne pomeni točnosti
Zapis 08:14:07.842 deluje natančneje od zapisa 08:14.
Res ima večjo ločljivost. Iz njega lahko razberemo milisekunde. To pa ničesar ne pove o tem, kako pravilna je bila ura, ki ga je ustvarila.
Sistem lahko beleži čas do tisočinke sekunde in hkrati za minuto zaostaja za referenčnim časom. V takem primeru dobimo zelo natančen zapis napačnega časa.
Ta razlika je pri tehnični analizi pomembna. Natančnost zapisa opisuje, kako podrobno je čas izražen. Točnost pove, kako blizu je vrednost dejanskemu referenčnemu času.
NIST v kontroli AU-8 standarda SP 800-53 Rev. 5 časovne žige obravnava kot samostojen element revizijske sledi. Organizacija mora določiti ustrezno časovno ločljivost in zagotoviti uporabo UTC, fiksnega odmika od UTC ali zapisa lokalnega odmika skupaj s časovnim žigom. NIST pri tem izrecno povezuje časovno granularnost tudi s stopnjo sinhronizacije sistemskih ur z referenčnimi urami. To je pomembnejše, kot se zdi. Časovni žig z milisekundami je uporaben samo toliko, kolikor zaupamo uri za njim.
Vsak zapis ne meri istega trenutka
Pri sestavljanju časovne osi se hitro pojavi druga težava. Različni sistemi pogosto ne beležijo iste faze dogodka.
Uporabnik klikne gumb. Aplikacija začne obdelavo. Zahteva prispe na spletni strežnik. Strežnik jo posreduje podatkovni zbirki. Sprememba se zapiše. Dogodek gre v lokalni dnevnik. Zbiralnik ga pozneje prenese v osrednji sistem.
Vsaka od teh faz ima lahko svoj časovni žig.
Če so polja poimenovana samo timestamp, time ali date, lahko pri poznejši analizi nehote primerjamo različne stvari.
Čas nastanka dogodka ni nujno čas zapisa v dnevnik. Čas zapisa ni nujno čas pošiljanja. Čas prejema v centralnem sistemu ni nujno čas, ko se je nekaj zgodilo na izvornem računalniku.
Razlika je lahko nekaj milisekund. Pri začasno nedosegljivi povezavi, čakalni vrsti ali paketnem prenosu lahko postane bistveno večja.
Osrednji sistem lahko zato ob 10.20 prejme zapis o dogodku, ki se je zgodil ob 10.15, ter ga shrani za zapisom dogodka iz 10.18, ki ga je prejel brez zamude.
Če analitik uporabi čas prejema kot čas dogodka, začne tehnologija sama preurejati preteklost.
Urejanje po času še ni časovna rekonstrukcija
Dnevnike pogosto združimo in razvrstimo po časovnem žigu. Rezultat je videti kot časovna os.
Toda razvrščanje je zanesljivo samo, če so vrednosti med seboj primerljive.
NIST SP 800-92 že dolgo opozarja na težavo neusklajenih sistemskih ur. Če posamezni gostitelji uporabljajo netočne ure, lahko dnevniki pokažejo napačno zaporedje dogodkov. Dokument izrecno navaja primer, v katerem časovni žigi kažejo eno zaporedje, dejansko pa sta se dogodka zgodila v nasprotnem vrstnem redu.
To je ena od bolj neprijetnih lastnosti tehničnih dnevnikov. Vsak posamezen zapis je lahko avtentičen, skupna časovna slika pa je kljub temu napačna.
Predstavljajmo si dva strežnika.
Prvi prehiteva za 40 sekund. Drugi zaostaja za 25 sekund.
Na prvem se zahteva zabeleži ob 10.14.50. Na drugem se njen rezultat zabeleži ob 10.14.20.
Po dnevnikih se je rezultat zgodil trideset sekund pred zahtevo.
Sistemu se ni zgodilo nič nadnaravnega. Napačno je bilo samo skupno merilo časa.
Pred analizo moramo zato vedeti, ali so bile ure sinhronizirane, s katerim virom, kakšno odstopanje je bilo mogoče pričakovati in ali je bilo med obravnavanim obdobjem zaznano odstopanje.
Brez tega kronološko sortiranje ustvari lepo urejen seznam. Ni nujno, da ustvari pravilno zgodbo.
UTC odstrani del nejasnosti
Enaka ura na zaslonu ne pomeni nujno istega trenutka.
10:30 v Ljubljani, Londonu in New Yorku predstavlja različne trenutke. Če časovni pas manjka, zapis potrebuje dodatni kontekst, preden ga lahko primerjamo z drugim virom.
RFC 3339 je bil pripravljen prav zaradi težav, ki jih različni zapisi datumov in časa povzročajo pri interoperabilnosti. Njegov internetni format časovnega žiga določa povezavo časa z UTC in omogoča zapis lokalnega odmika. RFC 9557 je leta 2024 model razširil z možnostjo dodatnih informacij, med drugim z oznako časovnega pasu.
Razlika med odmikom in časovnim pasom je uporabna tudi zunaj tehničnih standardov.
Odmik +02:00 pove, koliko je lokalni čas v določenem trenutku oddaljen od UTC. Oznaka časovnega pasu lahko poleg tega pove, katera pravila lokalnega časa so bila uporabljena.
To postane očitno ob prehodu s poletnega na zimski čas. V območjih, kjer se ura jeseni prestavi nazaj, se del lokalnega časa ponovi. Lokalni zapis, kot je 02:30, lahko zato brez odmika ali drugega konteksta označuje dva različna trenutka.
Pri vsakdanjem branju to skoraj nikoli ni težava.
Pri dnevniku avtentikacije pa lahko pomeni dve različni prijavi.
UTC takšno dvoumnost močno zmanjša. Ne reši pa vprašanja, ali je bila sistemska ura pravilna in kaj posamezen časovni žig sploh predstavlja.
Sinhronizacija je infrastruktura, ne kozmetika
Network Time Protocol obstaja zato, da sistemi svojih ur ne vzdržujejo vsak zase.
RFC 5905, ki opisuje NTPv4, cilj protokola opredeljuje kot zmanjševanje časovne in frekvenčne razlike med sistemsko uro in UTC. Sistem velja za sinhroniziranega, ko so te razlike znotraj ustreznih toleranc.
Pomembna je beseda toleranca.
Sinhronizirani sistemi nimajo matematično identičnega časa. Imajo dovolj usklajene ure za namen, za katerega jih uporabljamo.
Zahteve se zato razlikujejo. Za poslovno poročilo je lahko nekaj sekund nepomembnih. Za korelacijo varnostnih dogodkov med več sistemi je isto odstopanje že moteče. V okoljih, kjer se presoja zaporedje zelo hitrih transakcij, je lahko nesprejemljivo.
NIST AU-8 prav zato organizaciji ne predpisuje ene univerzalne vrednosti. Zahtevano granularnost časa mora določiti glede na svoj sistem in njegove potrebe.
V praksi je to pomembnejše od zahteve, da mora biti »NTP vključen«.
Koristnejši podatek je, koliko odstopanja je še sprejemljivo, kateri sistemi morajo izpolnjevati to zahtevo, kateri referenčni vir uporabljajo in kako organizacija zazna, da je posamezna ura iz dovoljenega območja izstopila.
Sinhronizacija, ki je nihče ne spremlja, lahko odpove dolgo pred prvim pregledom incidenta.
Popravljena ura ne popravi starega dnevnika
Sistemska ura lahko začne odstopati zaradi napačne konfiguracije, izgube povezave z virom časa, težav virtualizacijskega okolja ali drugih tehničnih razlogov. Ko se težava odpravi, se prihodnji časovni žigi spet približajo referenčnemu času.
Stari zapisi pa ostanejo takšni, kot so nastali.
Če je strežnik med incidentom zaostajal 90 sekund, poznejša uspešna sinhronizacija ne spremeni že zapisanih dogodkov. Pri analizi je zato pomembno tudi zgodovinsko stanje časovne sinhronizacije.
Tu se pokaže razlika med vprašanjem:
»Ali je ura zdaj pravilna?«
in vprašanjem:
»Kako pravilna je bila v času dogodka?«
Za prvo zadostuje trenutno stanje sistema. Drugo zahteva zgodovinske podatke.
Pri zahtevnejših analizah je zato lahko pomemben tudi dnevnik samega časovnega servisa. Pokaže lahko izgubo sinhronizacije, spremembo vira ali odstopanje ure v obdobju, ki ga preiskujemo.
Tak zapis lahko spremeni razumevanje vseh drugih časovnih žigov na istem sistemu.
Centralizacija ne popravi izvora
Sodobna okolja pogosto zbirajo dnevnike v centralnih sistemih. To olajša iskanje, hrambo in povezovanje dogodkov.
Centralizacija pa ne zagotavlja, da imajo izvorni zapisi pravilen čas.
Če strežnik pošlje dogodek z napačnim časovnim žigom, lahko osrednji sistem zelo zanesljivo shrani napačen čas. Če poleg njega zabeleži še čas prejema, dobimo dva podatka, ki imata različna pomena.
Prav ta razlika je lahko dragocena.
Dogodek je na izvornem sistemu označen z 08:14:07Z, zbiralnik pa ga prejme ob 08:16:12Z. Dvominutna razlika še ne pove vzroka. Lahko je posledica prenosa, čakalne vrste, začasno prekinjene povezave ali netočne izvorne ure.
Toda zdaj vemo, da obstaja nekaj, kar moramo pojasniti.
Če centralni sistem prvotni čas nadomesti s časom prejema in pri tem izgubi izvorno vrednost, je poznejša analiza revnejša. Normalizacija podatkov je koristna samo, če pri njej ostane jasno, kaj je bilo v izvirniku in kaj je bilo dodano ali preračunano.
Osnutek NIST SP 800-92 Rev. 1 to področje obravnava zelo neposredno. Med nalogami pri načrtovanju upravljanja dnevnikov posebej navaja določitev načina sinhronizacije ur ter oblik časovnih žigov in spremljajočih informacij, kot so časovni pasovi. Dokument je ob nastanku tega članka še vedno osnutek in ne nadomešča veljavne končne izdaje SP 800-92.
Časovna os potrebuje znano negotovost
Pri rekonstrukciji dogodkov pogosto ni mogoče določiti časa do sekunde natančno.
To ni nujno slab rezultat.
Bolj problematično je prikazati lažno natančnost.
Če vemo, da je sistemska ura lahko odstopala do približno 30 sekund, je poštena rekonstrukcija takšno omejitev upošteva. Dogodkov, katerih časovni razliki sta manjši od znanega možnega odstopanja, morda ne moremo zanesljivo razvrstiti.
V takem primeru je strokovno pravilneje zapisati, da njunega vrstnega reda na podlagi razpoložljivih časovnih podatkov ni mogoče potrditi.
To je lahko manj zadovoljiv odgovor od natančne časovne osi.
Je pa bolj uporaben.
Napačno zaporedje lahko analizo usmeri proti napačnemu vzroku. Če domnevamo, da se je sprememba konfiguracije zgodila pred napako, bomo iskali drugačno razlago, kot če je nastala po njej. Nekaj sekund časovne napake lahko zato spremeni celotno vzročno zgodbo.
Pri dobri rekonstrukciji meja znanja ni pomanjkljivost analize. Je del rezultata.
En dogodek potrebuje več kot eno uro
Pri pomembnih sistemih je smiselno že ob zasnovi beleženja vedeti, kaj posamezen časovni podatek pomeni.
Zapis dogodka je mnogo uporabnejši, če lahko pozneje ugotovimo, kateri sistem je ustvaril časovni žig, ali je ta zapisan v UTC oziroma vsebuje odmik, kakšna je njegova ločljivost ter ali gre za čas dogodka, obdelave ali prejema.
Ni treba, da vsak dnevnik vsebuje vse možne podatke.
Pomembno je, da je semantika časa znana.
Enako velja za centralno zbiranje. Če sistem dodaja svoj čas prejema, je koristno ohraniti tudi izvorni čas. Če čas normalizira v UTC, mora ostati jasno, kako je bila pretvorba izvedena. Če določeni sistemi niso dovolj zanesljivo sinhronizirani, mora biti to znano pred incidentom in ne šele med preiskavo.
NIST-ova zahteva po časovnih žigih v revizijskih zapisih je v tem pogledu precej praktična. Ura ni samo pomožni podatek ob dogodku. Čas je eden od pogojev, da lahko več dogodkov pozneje sploh postavimo v skupen kontekst.
Preden iz zaporedja nastane vzrok
Časovne osi so privlačne, ker zapletene dogodke spremenijo v zaporedje.
Ob 10.14 se je zgodilo A. Ob 10.15 B. Nato C.
Tak zapis hitro ustvari občutek razumevanja. Časovna bližina pa sama ne dokazuje vzročne povezave, napačen čas pa lahko pokvari že osnovno zaporedje.
Zato ima smisel pred sklepanjem preveriti samo merilo.
Katera ura je ustvarila zapis. Kaj časovni žig predstavlja. V katerem časovnem pasu je nastal. Ali poznamo njegov odmik od referenčnega časa. Ali je bil zapis prenesen z zamudo. Ali je bil čas pri normalizaciji spremenjen. Kakšna natančnost je za ta vir sploh upravičena. Šele nato lahko čas uporabimo za povezovanje dogodkov.
Pri rekonstrukciji je pogosto najbolj prepričljiv zapis tisti, ki kaže uro do tisočinke sekunde. Prav tak zapis lahko povzroči največ težav, če podrobnost zamenjamo za zanesljivost.
Časovni žig pove, kaj je zapisala ura.
Da bi vedeli, kdaj se je nekaj zgodilo, moramo poznati tudi uro.
EVIDENCE PROFILE
Dokazni profil članka
Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.
Viri
- 01STANDARDNational Institute of Standards and Technology (NIST)NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, kontrola AU-8, Time Stamps. NIST je 27. avgusta 2025 izdal Release 5.2.0. Kontrola AU-8 zahteva uporabo sistemskih ur za časovne žige revizijskih zapisov ter opredeljuje uporabo UTC oziroma lokalnega odmika in organizacijsko določeno časovno granularnost.Odpri vir ↗
- 02STANDARDNational Institute of Standards and Technology (NIST)NIST SP 800-92, Guide to Computer Security Log Management. Končna izdaja iz leta 2006 ostaja uradno objavljena različica. Dokument med težavami pri analizi dnevnikov izrecno obravnava neusklajene časovne žige in opozarja, da lahko netočne sistemske ure spremenijo navidezno zaporedje dogodkov. NIST trenutno pripravlja Rev. 1.Odpri vir ↗
- 03STANDARDNational Institute of Standards and Technology (NIST)NIST SP 800-92 Rev. 1, Cybersecurity Log Management Planning Guide, Initial Public Draft. Osnutek med načrtovalskimi nalogami posebej vključuje določitev načina sinhronizacije ur ter oblik časovnih žigov in spremljajočih podatkov. Ob pripravi tega članka, 31. avgusta 2026, dokument še nima statusa končne publikacije.Odpri vir ↗
- 04STANDARDInternet Engineering Task Force (IETF)IETF RFC 3339, Date and Time on the Internet: Timestamps. Standard opredeljuje internetni zapis datumov in časa ter povezavo časovnega žiga z UTC. RFC 3339 je leta 2024 delno posodobil RFC 9557.Odpri vir ↗
- 05STANDARDInternet Engineering Task Force (IETF)IETF RFC 9557, Date and Time on the Internet: Timestamps with Additional Information. Dokument iz leta 2024 razširja RFC 3339 z dodatnimi informacijami, med drugim z možnostjo označevanja časovnega pasu.Odpri vir ↗
- 06STANDARDInternet Engineering Task Force (IETF)IETF RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification. RFC opisuje NTPv4 in njegovo vlogo pri usklajevanju sistemskih ur z UTC.Odpri vir ↗