Wiarygodny czas to kontrola bezpieczeństwa: dlaczego logi potrzebują dobrego zegara

Instytut Łączności zwrócił uwagę na element infrastruktury, który rzadko trafia na pierwszą stronę programu bezpieczeństwa: wiarygodną synchronizację czasu. Podczas X Forum Bezpieczeństwa IT w Administracji eksperci instytutu pokazali, że zegar jest podstawą analizy logów, rekonstrukcji incydentu i prawidłowego działania części procesów retencji oraz kopii zapasowych.

Systemy mogą być zgodne między sobą, a jednocześnie wskazywać czas błędny względem świata zewnętrznego. Jeżeli nadrzędne źródło zostało odłączone lub podaje nieprawidłowe dane, wewnętrzne logi mogą wyglądać spójnie, lecz nie dać się prawidłowo zestawić z danymi operatora telekomunikacyjnego, dostawcy chmury, partnera albo organów ścigania.

Wniosek Breachroad: synchronizacja czasu nie jest wyłącznie zadaniem administratora. To kontrola bezpieczeństwa z właścicielem, monitoringiem, scenariuszem awarii i testem. Bez niej nawet kosztowny SIEM może tworzyć precyzyjny obraz zdarzeń w niewłaściwej kolejności.

Dlaczego czas decyduje o jakości dowodów

Analiza incydentu polega na zestawieniu zdarzeń z wielu źródeł: logowania użytkownika, zmiany uprawnień, uruchomienia procesu, dostępu do danych, ruchu sieciowego, alarmu EDR i operacji w chmurze. Każdy system zapisuje znacznik czasu, który pozwala ułożyć wspólną oś.

Jeżeli jeden zegar różni się o kilka minut, zespół może uznać skutek za przyczynę. Przy większym odchyleniu może szukać aktywności w złym przedziale i dojść do wniosku, że dostawca nie ma właściwych logów. Problem komplikuje się, gdy aplikacja zapisuje czas lokalny, infrastruktura używa UTC, a raport nie zawiera informacji o strefie i przesunięciu.

Instytut Łączności podkreśla też ryzyko cichej utraty zewnętrznego źródła. System może przez pewien czas pracować na własnym zegarze i stopniowo się rozjeżdżać. Jeśli nikt nie zauważy problemu przed rotacją logów, dokładna rekonstrukcja może stać się niemożliwa wtedy, gdy jest najbardziej potrzebna.

Zgodność urządzeń nie zawsze oznacza prawidłowy czas

Popularny test „wszystkie serwery pokazują to samo” sprawdza spójność, ale nie wiarygodność. Setki urządzeń mogą korzystać z tego samego błędnego źródła. Podobnie dwa odbiorniki GNSS nie tworzą rzeczywistej niezależności, jeżeli oba są podatne na ten sam rodzaj zakłócenia albo znajdują się w tym samym miejscu.

Prawdziwa redundancja wymaga zrozumienia wspólnych zależności. Organizacja powinna wiedzieć:

• skąd pochodzi czas dla kontrolerów domeny, hypervisorów, urządzeń sieciowych, systemów chmurowych i aplikacji;
• które źródła są nadrzędne, a które zapasowe;
• jak długo urządzenie utrzyma akceptowalną dokładność po utracie źródła;
• jak system sygnalizuje przełączenie, degradację albo nadmierne odchylenie;
• kto otrzyma alert i podejmie decyzję o reakcji.

Mapa zależności powinna obejmować nie tylko serwery. Kamery, systemy kontroli dostępu, urządzenia przemysłowe, telefonię, systemy transakcyjne i narzędzia bezpieczeństwa także tworzą dowody, których wartość zależy od czasu.

Wpływ na kopie zapasowe i retencję

Instytut wskazuje, że mechanizmy retencji kopii zapasowych mogą zależeć od znaczników czasu. W określonych konfiguracjach błędny albo zmanipulowany zegar może zmienić to, jak system ocenia wiek kopii i kiedy kwalifikuje ją do usunięcia.

Nie oznacza to, że każda zmiana czasu automatycznie usuwa backup. To zależy od produktu, polityki i implementacji. Firma powinna jednak przetestować zachowanie zamiast zakładać, że system zawsze posługuje się niezależnym, wiarygodnym czasem.

Scenariusz testowy powinien odpowiedzieć, co stanie się po utracie źródła, dużym odchyleniu, restarcie urządzenia i powrocie synchronizacji. Warto sprawdzić osobno harmonogram wykonywania kopii, wiek obiektów, politykę usuwania, niezmienność oraz alarmy. Dobra kopia to nie tylko plik istniejący w konsoli, ale dane możliwe do znalezienia i odtworzenia w warunkach awarii.

Plan kontroli synchronizacji czasu

1. Wskaż właściciela i zakres

Ustal, kto odpowiada za usługę czasu oraz kto używa jej wyników. Zazwyczaj potrzebna jest współpraca infrastruktury, sieci, chmury, SOC, właścicieli aplikacji i zespołu backupu. Bez wspólnego zakresu łatwo zabezpieczyć centrum danych, a pominąć urządzenia brzegowe lub system SaaS.

2. Zbuduj mapę źródeł i zależności

Dla każdej klasy systemów zapisz źródło czasu, ścieżkę sieciową, źródło zapasowe, strefę zapisu logów i oczekiwane maksymalne odchylenie. Uwzględnij usługi zarządzane, dla których czas kontroluje dostawca, oraz sposób uzyskania tej informacji podczas incydentu.

3. Monitoruj stan, nie tylko dostępność

Sama odpowiedź usługi czasu nie dowodzi poprawności. Monitoring powinien zauważyć utratę źródła nadrzędnego, zmianę używanego źródła, wzrost odchylenia i długą pracę w trybie podtrzymania. Progi trzeba dopasować do znaczenia systemu: środowisko transakcyjne może potrzebować ściślejszej tolerancji niż urządzenie biurowe.

4. Przetestuj utratę i odzyskanie źródła

Kontrolowany test pokaże, czy urządzenia przechodzą na zapas, jak szybko dryfują i czy alert dociera do osoby zdolnej podjąć działanie. Sprawdź też powrót do normalnej pracy. Nagła korekta czasu może wpływać na sesje, zadania i kolejność wpisów, dlatego proces odzyskiwania również wymaga obserwacji.

5. Ustandaryzuj pracę podczas incydentu

Analityk powinien zapisywać źródło znacznika czasu, strefę, znane odchylenie i moment pobrania dowodu. Korekty nie należy wykonywać „na oko” bez zachowania wartości oryginalnej. Wspólna oś czasu powinna wskazywać, które zdarzenia przeliczono i na jakiej podstawie.

Pomaga w tym wcześniej przygotowany plan reagowania na incydenty oraz dojrzały proces detection engineering i korelacji w SIEM.

Pytania, które warto zadać dostawcom

W przypadku chmury, centrum danych, systemu backupu lub usługi SOC zapytaj:

• jakie jest autorytatywne źródło czasu i czy istnieje niezależna ścieżka zapasowa;
• jak dostawca wykrywa odchylenie oraz utratę źródła;
• w jakiej strefie są zapisywane i eksportowane logi;
• czy eksport zawiera wystarczającą precyzję i jednoznaczne oznaczenie strefy;
• jak synchronizacja wpływa na retencję, harmonogramy oraz niezmienność kopii;
• jak podczas incydentu otrzymać informację o historycznym odchyleniu.

Odpowiedź „używamy NTP” jest początkiem rozmowy, nie jej zakończeniem. Potrzebna jest wiedza o źródłach, zależnościach, obserwowalności i zachowaniu podczas awarii.

Ćwiczenie dla firmy bez wyłączania produkcji

Nie każdy test musi zaczynać się od odpinania serwera czasu. Zespół może przeprowadzić ćwiczenie stolikowe: otrzymuje logi z czterech systemów, z których jeden ma odchylenie o siedem minut, drugi zapisuje czas lokalny bez strefy, a trzeci utracił synchronizację dzień wcześniej. Zadaniem jest zbudowanie osi incydentu, wskazanie brakujących danych i podjęcie decyzji o eskalacji.

Takie ćwiczenie szybko pokazuje, czy SOC wie, gdzie znaleźć stan synchronizacji, czy infrastruktura przechowuje historię odchylenia i czy właściciel aplikacji rozumie format czasu w swoich logach. Efektem powinna być krótka lista napraw, właścicieli i terminów, nie tylko prezentacja.

Fakty źródłowe i wnioski Breachroad

Instytut Łączności opisuje znaczenie wiarygodnego czasu dla korelacji logowań, zmian uprawnień, dostępu do danych i ruchu sieciowego. Wskazuje ryzyko niezauważonej utraty źródła, wspólnej słabości pozornie redundantnych odbiorników oraz zależności niektórych mechanizmów backupu i retencji od czasu. Rekomenduje znajomość źródła i ścieżki, czasu podtrzymania, detekcję utraty oraz test zachowania po odłączeniu.

Mapa całego środowiska, progi monitoringu, standard dowodowy, pytania do dostawców i ćwiczenie stolikowe są rekomendacjami Breachroad. Organizacje mogą przećwiczyć te role podczas szkoleń cyberbezpieczeństwa dla firm i administracji oraz ocenić wiarygodność logowania, backupu i monitoringu w ramach audytu bezpieczeństwa IT.

Źródło pierwotne: Instytut Łączności — Cyberbezpieczeństwo zaczyna się od właściwej godziny.