Monitorowanie integralności plików

Monitorowanie integralności plików odpowiada na jedno pytanie: czy plik, który nie powinien się zmieniać, został zmieniony? Mechanizm zapisuje zaufany stan wybranych plików, katalogów i ustawień, a następnie zgłasza każdą późniejszą różnicę wraz z czasem i kontem, które ją wykonało. Wartość tkwi mniej w samym wykryciu niż w tym, że niewyjaśniona zmiana staje się wpisem, który ktoś musi zamknąć, zamiast cichej edycji, której nikt nie zauważa.

FIM opiera się na sprawdzaniu integralności plików, czyli samej czynności weryfikacji. Różnica polega na ciągłości: jednorazowe sprawdzenie odpowiada na pytanie raz, a FIM zadaje je stale i przechowuje historię każdej odpowiedzi. Ta historia jest potrzebna analitykowi, gdy plik konfiguracyjny został zmieniony na tygodnie przed tym, zanim ktokolwiek to zauważył.

Każda monitorowana ścieżka przechodzi tę samą pętlę. Z zaufanego stanu pobierany jest stan bazowy skrótów i atrybutów. Każde późniejsze zdarzenie jest porównywane z tym stanem, dzięki czemu alert odzwierciedla to, co się faktycznie różni, i wskazuje plik, zmianę, konto i czas. Jakość mechanizmu zależy głównie od stanu bazowego i dyscypliny właściciela alertów, a nie od silnika wykrywania.

Porównanie cykliczne sprawdza stan bazowy w stałych odstępach i zgłasza odchylenia. Jest tanie i łatwe do audytu, ale zmiana wykonana tuż po skanowaniu pozostaje ukryta do następnego. Monitoring w czasie rzeczywistym reaguje na zapisy, przeniesienia i usunięcia od razu, dlatego SOC zwykle chce go dla plików systemowych, skryptów startowych i reguł dostępu.

Tryb w czasie rzeczywistym kosztuje więcej. Wymaga agenta na hoście, generuje więcej zdarzeń i wymaga strojenia od pierwszego dnia. Wiele zespołów stosuje oba: czas rzeczywisty dla kilku najważniejszych ścieżek, a porównanie cykliczne dla reszty zasobów, tak by zdarzenie pominięte przez agenta wyłapał kolejny pełny przebieg. Szerzej o tej praktyce pisze ciągły monitoring.

Sam alert o zmianie pliku jest ubogi. Mówi, że ścieżka różni się od stanu bazowego, ale nic o intencji. FIM zyskuje wartość, gdy alert trafia do tego samego przepływu co wszystkie inne sygnały, więc analityk czyta go obok logowań, procesów i zgłoszenia, które powinno wyjaśniać zmianę. Zespoły, które przekazują zdarzenia do integracji z SIEM, mogą umieścić zmianę pliku na tej samej osi czasu co logowania i połączenia.

FIM należy do najczęściej wymienianych mechanizmów w ramach bezpieczeństwa, dlatego zespoły SOC wdrażają go nawet wtedy, gdy nie doszło do incydentu. Większość audytorów oczekuje tych samych dowodów: zdefiniowanej listy krytycznych plików, alertów o nieautoryzowanej zmianie oraz dowodu, że człowiek przejrzał każdy alert i zamknął go decyzją.

• PCI DSS wymaga mechanizmu wykrywania zmian w systemach przetwarzających dane kart płatniczych, przy czym krytyczne pliki porównuje się co najmniej raz w tygodniu.
• NIST SP 800-53, kontrola SI-7, obejmuje integralność oprogramowania, firmware'u i informacji.
• Zasada integralności w HIPAA oczekuje od podmiotów objętych przepisami mechanizmów elektronicznych, które potwierdzają, że elektroniczne informacje o zdrowiu nie zostały zmienione ani zniszczone bez upoważnienia.
• ISO/IEC 27001, załącznik A, zawiera kontrole zarządzania zmianami i integralności systemów, które udokumentowany proces FIM pomaga udokumentować.
• Audytorzy zwykle proszą o inwentarz chronionych plików, próbki alertów oraz ślad przeglądu pokazujący, że każdy alert został zamknięty decyzją, a nie tylko wygenerowany.

Anexet nie tworzy stanu bazowego dla dowolnych ścieżek systemowych ani nie liczy skrótu każdego pliku na serwerze, więc nie jest klasycznym silnikiem FIM. Konsola rejestruje operacje na plikach na stacjach roboczych i w udziałach sieciowych: dla plików utworzenie, odczyt, zapis, usunięcie, zmianę nazwy, uruchomienie i zmianę uprawnień, a dla katalogów węższy zestaw. Każdy profil agenta wybiera, które operacje są rejestrowane. Udziały sieciowe obejmuje kontrola przesyłania plików i udziałów sieciowych.

Największym ryzykiem operacyjnym FIM nie jest przeoczenie prawdziwej zmiany. Jest nim zalanie SOC szumem, aż każdy alert zostanie zamknięty bez czytania. Kontenery zmieniają obraz: obrazy buduje się od nowa zamiast łatać je w miejscu, więc stan bazowy przenosi się do potoku budowania obrazów. Strojenie przebiega w przewidywalnej kolejności:

1. 1

   Zapisz stan bazowy

   Pobierz go z zaufanej, sprawdzonej wersji systemu.

2. 2

   Uruchom tryb tylko raportowania

   Ustal, co zwykle zmienia się w danej klasie systemów.

3. 3

   Wyklucz ścieżki zmienne

   Pomiń ścieżki, które legalnie się zmieniają, na przykład pamięci podręczne, logi i metadane menedżera pakietów.

4. 4

   Kieruj alerty do właściciela

   Właściciel zamyka każdy alert z zapisanym powodem.

FIM wykrywa, że monitorowany plik się zmienił. Nie ocenia, czy nowa treść jest złośliwa, i nie zapobiega zmianie. Nic nie widzi w działaniach, które nie dotykają monitorowanej ścieżki, na przykład wykonywania w pamięci, nadużycia danych uwierzytelniających czy danych skopiowanych bez zmiany jakiegokolwiek pliku.

Dojrzałe SOC traktuje więc FIM jako jedną z kilku kontroli detektywnych. Łączy go z kontrolami dostępu, które ograniczają, kto może zapisywać w chronionych ścieżkach, z kontrolą integralności plików dziennika, dzięki której zdarzenia integralności przetrwają na infrastrukturze, której atakujący nie kontroluje, oraz z kopiami zapasowymi i odzyskiwaniem, dzięki którym potwierdzoną nieautoryzowaną zmianę można cofnąć.

Zacznij od kilku plików, których ciche zmiany zaszkodziłyby najbardziej: plików binarnych systemu na serwerach, konfiguracji narzędzi bezpieczeństwa i ścieżek przechowujących chronione dane. Kolejne ścieżki dodawaj dopiero wtedy, gdy właściciel wyjaśni każdy alert wygenerowany przez pierwszy zestaw.

Czytaj dalej: Mechanizmy zapewniania bezpieczeństwa systemów informacyjnych; Czym są systemy SIEM w zarządzaniu bezpieczeństwem informacji?.