Krótko: Oś czasu incydentu IT porządkuje chronologicznie wszystkie obserwacje, decyzje i działania w jednolitej strefie czasowej, najlepiej UTC. Każdy wiersz podaje źródło, obserwację, dowód i ocenę jako udokumentowane, prawdopodobne lub nieznane. W ten sposób powstaje czytelny obraz tego, kiedy atakujący był w systemie, co mógł osiągnąć i kiedy Państwo się o tym dowiedzieli.
Dlaczego na końcu wszyscy pytają o „kiedy”
Po incydencie pytania napływają ze wszystkich stron. Inspektor ochrony danych chce wiedzieć, od kiedy dane osobowe były dostępne. Ubezpieczyciel pyta, kiedy szkodę wykryto i zgłoszono. Zarząd chce wiedzieć, czy luka była otwarta już przed ostatnią aktualizacją. Wszystkie te pytania mają wspólny mianownik: dotyczą momentów w czasie.
Bez osi czasu każdy odpowiada na nie z pamięci, a odpowiedzi sobie przeczą. Przy starannie prowadzonej osi czasu istnieje wspólna podstawa, do której odwołują się wszyscy uczestnicy. Jest ona zarazem szkieletem raportu końcowego.
W przypadku PHP2Shell oś czasu jest szczególnie wymowna, ponieważ publiczne dane ramowe są dobrze udokumentowane. Można je umieścić jako punkty odniesienia obok własnych obserwacji. Pełną sekwencję zdarzeń publicznych opisuje poradnik PHP2Shell: chronologia.
Budowa: jakich kolumn potrzebuje oś czasu
Wystarczy tabela, w arkuszu kalkulacyjnym lub we wspólnym dokumencie. Ważne są stałe kolumny, wypełniane w każdym wierszu. Poniższy wzór pokazuje publiczne dane ramowe PHP2Shell jako punkty odniesienia, a pod nimi typowe własne wpisy w formie szablonu:
| Czas (UTC) | Źródło | Obserwacja | Dowód | Ocena |
|---|---|---|---|---|
| 17.10.2026 | doniesienia medialne | pierwsza zaobserwowana próba ataku na PHP2Shell | artykuł prasowy | udokumentowane jako doniesienie medialne |
| 20.10.2026 | php.net | zapowiedź aktualizacji bezpieczeństwa | komunikat na php.net | udokumentowane |
| 21.10.2026, 14:00 | php.net | publikacja 8.5.12, 8.4.27, 8.3.36, 8.2.35 | komunikat na php.net | udokumentowane |
| czas własny | log dostępu | nagromadzenie błędów 500 na zwykłych stronach | fragment logu, numer wiersza | prawdopodobnie istotne |
| czas własny | system plików | nowy plik PHP w katalogu uploadu | kopia z sumą kontrolną | udokumentowane, czas niepewny |
| czas własny | wewnętrzne | incydent zauważono, poinformowano zarząd | e-mail, notatka z rozmowy | udokumentowane |
| czas własny | wewnętrzne | wgrano aktualizację, zrestartowano wszystkie procesy robocze | log pakietów, lista procesów | udokumentowane |
Kolumna „Ocena” jest najważniejsza. Oddziela to, co udowodnione, od tego, co wydaje się prawdopodobne, i od tego, co pozostaje otwarte. Późniejsi czytelnicy od razu widzą, gdzie oś czasu jest solidna, a gdzie są luki.
Oś czasu incydentu IT: łączenie źródeł
Wpisy pochodzą z wielu źródeł, z których każde ma własne formaty i strefy czasowe. Proszę postępować w tej kolejności:
- Ustalić strefę czasową: wszystko prowadzić w UTC. Zmiana na czas zimowy 25.10.2026 przesuwa niemieckie czasy lokalne o godzinę w środku badanego okresu. Kto miesza czasy lokalne, niepostrzeżenie przesuwa zdarzenia.
- Sprawdzić zegary: czy zegar serwera chodził poprawnie? Porównanie ze znanym zdarzeniem, na przykład z własnym logowaniem, pokazuje odchylenia.
- Najpierw źródła zewnętrzne: logi CDN, WAF, dostawcy hostingu lub zapory leżą poza serwerem i trudno je zmanipulować. Tworzą szkielet.
- Uzupełnić logami serwera: serwer WWW, PHP-FPM, logowania, dziennik systemowy. Metodykę opisuje Analiza logów serwera WWW po ataku.
- Uwzględnić system plików: dopisać znaczniki czasu nowych i zmienionych plików jako wskazówki.
- Wpisać zdarzenia wewnętrzne: kiedy coś zauważono, kto został poinformowany, jaka decyzja zapadła i kiedy?
Co mówią znaczniki czasu plików, a czego nie
Linux zapisuje dla każdego pliku kilka momentów, między innymi ostatnią zmianę zawartości (mtime) i ostatnią zmianę metadanych (ctime). Oba można wyświetlić w trybie do odczytu, tutaj jako listę plików PHP zmienionych od określonego dnia, posortowaną według czasu w UTC:
# Zmiany zawartości od 17.10.2026, posortowane, w UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Wszystkie znaczniki czasu pojedynczego pliku
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Proszę przy tym pracować wyłącznie na kopii lub zabezpieczonym obrazie, jak opisano w artykule Zabezpieczyć dowody, zanim zainstalują Państwo serwer od nowa. Należy pamiętać o dwóch ograniczeniach. Po pierwsze, atakujący może prostymi środkami cofnąć datę modyfikacji pliku; niewyróżniający się mtime nie jest uniewinnieniem. Po drugie, operacje kopiowania i niektóre narzędzia zmieniają znaczniki czasu. Dlatego obowiązuje zasada: czasy plików są wskazówkami, wpisy w logach spoza serwera są dowodami.
Proszę wpisać moment, w którym Państwa firma dowiedziała się o możliwym naruszeniu ochrony danych. Zgodnie z art. 33 RODO 72-godzinny termin zgłoszenia zasadniczo biegnie od uzyskania wiedzy. Ocena należy do Państwa inspektora ochrony danych lub prawnika.
Typowe błędy i jak ich unikać
Najczęstsze błędy są niespektakularne. Oś czasu jest rekonstruowana z pamięci dopiero na końcu, zamiast prowadzona na bieżąco. Wpisy zawierają wnioski zamiast obserwacji, na przykład „atakujący wszedł przez formularz” zamiast „żądanie POST na formularz, potem nowy plik”. A dowodów brakuje, ponieważ nikt nie zanotował, z jakiego pliku logu i z którego wiersza pochodzi wpis.
Dlatego proszę wyznaczyć jedną osobę, która prowadzi oś czasu, i wpisywać zdarzenia, gdy tylko wystąpią. Wnioski należą do osobnej kolumny lub do raportu, nie do obserwacji.
Oś czasu należy ponadto traktować jako dokument poufny. Zawiera często adresy IP, nazwy użytkowników i wskazówki o słabych punktach. Proszę ustalić, kto może ją czytać i zmieniać, oraz zachowywać wcześniejsze wersje. Gdy zmienia się ocena, na przykład dlatego, że pojawił się nowy fragment logu, stary wiersz nie jest nadpisywany, lecz uzupełniany. Dzięki temu można prześledzić, co było wiadome w danym momencie i na jakiej podstawie podjęto decyzję.
Jak konkretnie pomaga PHP SOS?
- Prowadzimy oś czasu od pierwszego kontaktu na bieżąco i w UTC, ze źródłem i dowodem przy każdym wpisie.
- Analizujemy łącznie logi zewnętrzne, logi serwera i system plików oraz oznaczamy każde stwierdzenie jako udokumentowane, prawdopodobne lub nieznane.
- W razie potrzeby wraz ze specjalistycznymi partnerami przejmujemy informatykę śledczą dla analizy nadającej się do użycia przed sądem.
- Przekazujemy oś czasu jako część raportu dla zarządu, ochrony danych i ubezpieczyciela.
Częste pytania
Do czego potrzebuję osi czasu po incydencie bezpieczeństwa?
Porządkuje wszystkie obserwacje w kolejności i pokazuje, kiedy atakujący był w systemie, co mógł osiągnąć i kiedy Państwo się o tym dowiedzieli. Te informacje są potrzebne inspektorowi ochrony danych, ubezpieczycielom, organom i zarządowi do podejmowania decyzji.
W jakiej strefie czasowej powinienem prowadzić oś czasu?
Jednolicie w UTC. Serwery, usługi i komunikaty używają różnych stref czasowych, a zmiana na czas zimowy pod koniec października dodatkowo przesuwa czasy lokalne. Kto przelicza wszystko na UTC, a czas lokalny tylko dopisuje, unika błędów przy porównywaniu.
Czy mogę polegać na znacznikach czasu plików?
Tylko w ograniczonym stopniu. Datę modyfikacji pliku można sfałszować prostymi środkami. Wiarygodniejsze są wpisy w logach, zwłaszcza w logach spoza dotkniętego serwera. Znaczniki czasu plików są wskazówkami, które należy potwierdzić innymi źródłami.
Co poza zdarzeniami technicznymi należy wpisać do osi czasu?
Także decyzje i komunikację: kiedy zauważono incydent, kto został poinformowany, kiedy serwer odłączono od sieci, kiedy wgrano poprawkę. Szczególnie moment uzyskania wiedzy jest ważny dla terminów zgłoszeniowych.