O tym niedocenianym zagrożeniu mówili 22 października podczas X Forum Bezpieczeństwa IT w Administracji w Jastrzębiej Górze Wiesław Łodzikowski, zastępca dyrektora ds. rozwoju Instytutu Łączności - Państwowego Instytutu Badawczego, oraz Paweł Melon, dyrektor Biura Architektury i Infrastruktury IŁ-PIB. Ich wspólne wystąpienie „Wiarygodny czas - niedoceniony fundament cyberbezpieczeństwa administracji” dotyczyło infrastruktury, której zwykle nie zauważamy, dopóki nie zacznie zawodzić: źródeł czasu i mechanizmów jego synchronizacji.
Cyberbezpieczeństwo zaczyna się […] od infrastruktury
- podkreślał Wiesław Łodzikowski.
Zegary mogą zgodnie pokazywać błędny czas
Wiesław Łodzikowski rozpoczął od demonstracji trzech zegarów. Na pierwszy rzut oka wyglądały tak, jakby wskazywały tę samą godzinę. Dopiero dokładniejsze porównanie ujawniało różnice. Demonstracja prowadziła do pytania znacznie ważniejszego niż to, czy wskazówki są ustawione równo: któremu zegarowi właściwie możemy zaufać?
W systemach informatycznych podobna pułapka bywa trudniejsza do zauważenia. Komputery mogą pobierać czas z jednego serwera i pozostawać ze sobą zgodne. Jeśli jednak sam serwer utraci kontakt z wiarygodnym źródłem, cała organizacja może stopniowo oddalać się od rzeczywistego czasu. Wewnętrzny porządek zostaje zachowany, ale przestaje pasować do zapisów operatora telekomunikacyjnego, innej instytucji czy zewnętrznego systemu bezpieczeństwa.
Właśnie dlatego komunikat o działającej synchronizacji wymaga sprawdzenia, z czym urządzenia są synchronizowane. Trzeba znać źródło odniesienia, drogę dostarczania sygnału oraz zachowanie systemu, gdy sygnał przestanie docierać. Błąd może powstać na każdym z tych etapów.
Logi potrzebują wspólnej osi czasu
Znaczniki czasu pozwalają łączyć zdarzenia z różnych urządzeń w jedną historię. Dzięki nim można ustalić, czy podejrzane logowanie poprzedziło zmianę uprawnień, kiedy nastąpił dostęp do danych i jak te działania wiązały się z ruchem sieciowym. Gdy zegary się rozchodzą, kolejność widoczna w zapisach może być myląca.
Praktyczne konsekwencje błędów synchronizacji przedstawił Paweł Melon. Omówiony przez niego scenariusz pokazywał, jak utrata zewnętrznego źródła czasu może długo pozostać niezauważona. Lokalny zegar nadal pracuje, urządzenia nadal się do niego dostosowują, a urząd wykonuje swoje zadania. Problem ujawnia się dopiero po incydencie, kiedy trzeba porównać własne logi z informacjami spoza organizacji.
Wówczas nawet niewielkie przesunięcie może skierować analizę na niewłaściwe połączenie lub użytkownika. Wyjaśnienie pomyłki wymaga dodatkowej pracy i ustalenia, jak duży był błąd w danym momencie. Z upływem czasu część zapisów może zostać nadpisana, utrudniając rekonstrukcję. Wiarygodny czas wpływa więc na to, czy zgromadzone dane pozwolą rzetelnie wyjaśnić zdarzenie.
Kopia bezpieczeństwa też patrzy na zegar
Drugi scenariusz przedstawiony przez dyrektora Biura Architektury i Infrastruktury IŁ-PIB dotyczył kopii zapasowych. Organizacja wykonuje backupy i zakłada, że po ataku będzie mogła odzyskać dane. Jednak zasady przechowywania kopii również mogą zależeć od czasu: system musi przecież ustalić, kiedy upływa okres ich ochrony i które z nich wolno już usunąć.
W rozwiązaniu podatnym na manipulację zegarem, przy określonej konfiguracji i dostępie napastnika, zmiana czasu może wpłynąć na ocenę wieku kopii. Atakujący może próbować wykorzystać tę zależność do pozbawienia organizacji możliwości odtworzenia danych. Prezentowany przykład zwracał uwagę na potrzebę sprawdzenia, jak system backupu chroni swój zegar i mechanizmy retencji.
Test odzyskiwania danych powinien zatem obejmować także warunki, w których kopie mają pozostać dostępne. Sama informacja, że backup został wykonany, nie odpowiada jeszcze na pytanie, co stanie się z nim po awarii lub naruszeniu infrastruktury czasu.
Kilka odbiorników może mieć jedną słabość
Wiesław Łodzikowski zwracał również uwagę na zależność synchronizacji od satelitarnych systemów nawigacyjnych GNSS. Ich sygnały służą do wyznaczania pozycji, ale dostarczają też precyzyjnej informacji o czasie. Zakłócenia odbioru mogą więc dotyczyć również urządzeń, które przez cały czas stoją w tym samym miejscu.
To istotne przy projektowaniu rozwiązań zapasowych. Kilka serwerów lub odbiorników nie musi oznaczać kilku niezależnych zabezpieczeń. Jeżeli wszystkie korzystają z sygnału podatnego na to samo zakłócenie, wspólna przyczyna może pozbawić je źródła odniesienia jednocześnie. Trzeba sprawdzić rzeczywistą niezależność źródeł i dróg dostarczania czasu.
Z tej perspektywy szczególnego znaczenia nabierało pytanie postawione przez Wiesława Łodzikowskiego:
Na jak długo jesteśmy przygotowani, odcinając się od źródła?
Po utracie synchronizacji zegar lokalny może przez pewien okres podtrzymywać czas z dokładnością wystarczającą dla danej usługi. Jak długo? To zależy od właściwości urządzenia i wymagań systemu. Organizacja powinna znać ten okres, umieć wykryć utratę źródła i wiedzieć, kiedy odchylenie zacznie zagrażać jej procesom.
Sprawdzić czas przed incydentem
Wspólnym wnioskiem z wystąpienia obu ekspertów była potrzeba przeglądu całej architektury synchronizacji. Warto ustalić, skąd urząd pobiera czas, które systemy z niego korzystają, czy źródła zapasowe są niezależne i kto otrzyma alarm o nieprawidłowościach. Potrzebne są też testy zachowania infrastruktury po odłączeniu podstawowego źródła.
Wymagania trzeba przy tym odnieść do konkretnych zastosowań. Innej dokładności może potrzebować system biurowy, a innej infrastruktura realizująca procesy w czasie rzeczywistym. Ocena powinna obejmować zarówno dopuszczalny błąd, jak i konsekwencje jego przekroczenia.
Instytut Łączności - PIB zajmuje się tym zagadnieniem od strony metrologii oraz działania infrastruktury telekomunikacyjnej. Podczas Forum jego przedstawiciele zachęcali do sprawdzenia jakości i odporności synchronizacji, zanim awaria zmusi administratorów do odtwarzania tego, co działo się z zegarami przez poprzednie miesiące.
Po incydencie urząd musi umieć odpowiedzieć na pytania: co się wydarzyło, w jakiej kolejności i kto za tym stał. Każda z tych odpowiedzi zależy również od tego, czy można zaufać godzinie zapisanej w systemie.