Wymagania dotyczące rejestrowania zdarzeń dla

Załącznik nr 3 do OPZ - Wymagania dotyczące rejestrowania zdarzeń
Wymagania dotyczące rejestrowania zdarzeń dla poszczególnych
technologii/platform stosowanych w BGK
1. Sposób rejestrowania zdarzeń w poszczególnych systemach operacyjnych czy aplikacjach
zależy od zastosowanej konfiguracji logowania. Dlatego istotne jest przeanalizowanie takiej
konfiguracji i wybranie optymalnego logowania, tak aby logowane były istotne zdarzenia
mogące mieć wpływ na bezpieczeństwo, natomiast należy unikać logowania zdarzeń, które nie
wnoszą dodatkowej informacji o pracy systemu.
2. Logi zapisywane są najczęściej w pewien określony sposób i w określonych, domyślnych
miejscach systemów – jednak zależy to od konkretnej konfiguracji, która decyduje, które
informacje zapisywane są w jakich logach w poszczególnych lokalizacjach w systemie. Dlatego
oprócz wymogu analizy i przesyłania logów konfigurowanych standardowo/domyślnie
w systemie, należy zweryfikować, czy nie należy uwzględnić także innych logów z innych
lokalizacji w systemie, szczególnie w przypadku funkcjonowania specyficznych,
niestandardowych rozwiązań i usług. Logi ważne do analizy, często występują poza
standardowymi lokalizacjami. W czasie ich wdrażania powinna być przeprowadzona
inwentaryzacja tych logów z ich miejscami występowania, sposobem zapisu pliku i formatem
zapisu poszczególnych zdarzeń w logu. Dużym utrudnieniem w poprawnej analizie logów,
szczególnie automatycznie wykonywanej przez system SIEM lub przez inne narzędzia, może
być unikalny sposób rejestrowania zdarzeń, narzucony przez dostawcę. Dlatego istotne jest
uwzględnienie tych wymagań w dokumentach przetargowych i egzekwowanie ich w czasie
wdrożenia aplikacji.
3. Dla poszczególnych technologii/platform stosowanych w Banku określa się następujące
wymogi:
1) logi systemów Windows
W systemach Windows standardowo występuje podział logów na logi Security, Application
i System. Wszystkie z tych logów powinny być gromadzone i analizowanie (nie zaś
wyłącznie logi Security) ponieważ istotne pod względem bezpieczeństwa informacje
pojawiają się we wszystkich logach.
Punktem wyjścia dla konfiguracji logowania powinny być Audit Policy rekomendowane
przez Microsoft i uwzględniające dobre praktyki bezpieczeństwa IT dla poszczególnych
wersji serwerów i ich funkcji w infrastrukturze IT. Konfiguracja logowania zdarzeń
powinna obejmować rejestrowanie uruchamianych procesów, w szczególności przez
użytkowników o wysokich uprawnieniach.
Dla szczególnie wrażliwych informacji powinien być rejestrowany dostęp do obiektów,
które je zawierają (pliki/katalogi). W systemach Windows szczególnie istotne jest, aby
spełnić wymagania opisane w § 7 ust. 2 dotyczące logów dedykowanych aplikacji
bankowych, gdyż aktualnie najczęściej buduje się je właśnie w oparciu o ten system
a jednocześnie w praktyce w niewystarczającym zakresie uwzględnia kwestie logowania
zdarzeń;
2) logi systemów Unix (HP-UX, Solaris, Linux i inne):
W systemach Unix najczęściej domyślnymi logami, które powinny być monitorowane są
messages i syslog, zwykle w katalogach /var/log i /var/adm. Dodatkowo powinien być
1/3
logowany sulog logujący użycie komendy su oraz log z działania usługi cron. Należy
rozważyć monitorowanie logów powstających w momencie bootowania systemu.
Dodatkowo należy monitorować komendy wykonywane przez osoby o wysokich
uprawnieniach w systemie, w szczególności w systemach Solaris należy wykorzystywać
moduł Solaris Auditing/BSM (Basic Security Module), w systemie Linux auditd.
Również istotne jest rejestrowanie uruchamiania i zamykania procesów/usług w systemie,
szczególnie jeśli związane to jest z otwieraniem dostępu sieciowego do systemu;
3) logi firewalli (zapór sieciowych):
Powinny być gromadzone i analizowane logi z zadziałania poszczególnych reguł
składających się na politykę bezpieczeństwa skonfigurowaną na firewallu. Ruch taki
zawiera informację o adresie źródłowym, docelowym, wykorzystywanej usłudze/porcie
oraz czy ruch był przepuszczony czy zablokowany. Na firewallu powinno być ustawione
logowanie zadziałania poszczególnych reguł, jeśli te informacje mogą być przydatne dla
celów analizy.
Szczególnie istotne są logi z firewalli dla ruchu wchodzącego z Internetu do wnętrza sieci
Banku oraz logi wychodzące do Internetu, jak również logi dotyczące ruchu w strefie
DMZ.
Należy rejestrować logi dotyczące instalacji kolejnych polityk bezpieczeństwa na
firewallach, zawierających zestaw reguł dla ruchu sieciowego, w celu zachowania
rozliczalności działań osób o wysokich uprawnieniach.
Umieszczenie danego ZI w strefie DMZ nie zwalnia od konieczności weryfikacji logów ZI
przez Administratora ZI oraz ich przesyłania do centralnego systemu SIEM, zgodnie
z Wymogami, gdyż strefa DMZ jest szczególnie narażona na ataki z zewnątrz sieci Banku.
Z tego względu istotna jest analiza logów w celu wychwycenia takich ataków i możliwości
wystąpienia incydentów przełamania zabezpieczeń.
Konfiguracja przesyłania logów ze strefy DMZ do wnętrza sieci Banku powiązana
nieuchronnie z wprowadzeniem dodatkowych reguł na firewallach powinna uwzględniać
zwiększone zagrożenia dla tej strefy i minimalizować ryzyko wykorzystania tej
konfiguracji do przeprowadzenia skutecznego ataku do wnętrza sieci;
4) logi serwerów WWW i aplikacji webowych:
Powinny być gromadzone i analizowane logi serwerów aplikacyjnych i WWW, zarówno
związanych z udanymi dostępami do zasobów, jak i z błędami i niepoprawnymi dostępami,
w celu wykrywania nieprawidłowości i możliwych ataków.
Konieczne jest rejestrowanie i analiza logowania użytkowników do aplikacji webowych,
zarówno lokalnie przez osoby odpowiedzialne za pracę tych aplikacji, jak i poprzez
wysyłanie tych logów do centralnego systemu SIEM i analizę w DB pod kątem możliwości
wystąpienia incydentów naruszenia bezpieczeństwa środowiska teleinformatycznego.
W tym celu w czasie wdrażania takich aplikacji należy uzgodnić z dostawcą poprawny
format zapisu logów, który umożliwi poprawną ich analizę przez system SIEM.
W sytuacji wykorzystywania centralnego systemu SSO (SingleSignOn) umożliwiającego
jednokrotne logowanie do wielu systemów Banku, szczególnie istotnie jest zapewnienie
poprawnego rejestrowania logowania użytkowników, zarówno w celu lokalnej weryfikacji,
jak i niezależnej analizy po przesłaniu do systemu SIEM;
5) logi serwerów pocztowych:
Należy gromadzić i analizować logi serwerów pocztowych zawierające informacje
o nadawcy i odbiorcy wiadomości, temacie i rozmiarze. Powinny być również gromadzone
informacje z tzw. koperty wiadomości o drodze, jaką przebyła dana wiadomość
przechodząc pomiędzy serwerami pocztowymi;
2/3
6) logi baz danych:
Współcześnie najczęściej w bazach danych zgromadzone są najbardziej istotne i wrażliwe
dane. Czynności bankowe są w rzeczywistości operacjami na rekordach tych baz. Dlatego
należy monitorować takie operacje w bazach danych, w szczególności w celu weryfikacji
nieuprawnionych działań użytkowników uprzywilejowanych, którzy mogą mieć lub
uzyskać bezpośredni dostęp do bazy z ominięciem standardowego dostępu dla
użytkowników.
Należy monitorować zmiany związane z zarządzaniem kontami w bazie danych
(w szczególności tworzenie/modyfikacja/usunięcie kont), zmiany konfiguracji, uprawnień
do poszczególnych tabel).
Należy monitorować takie operacje jak SET, DROP, UPDATE, GRANT, jak również
monitorować modyfikacje procedur składowanych, widoków (view) i zmiany właścicieli
schematów (schema).
Należy również monitorować zdarzenia obejmujące dużą, niestandardową ilość rekordów,
np. usunięcie lub odczyt całych tabel zawierających dane klientów Banku;
7) logi szyny ESB (Enterprise Service Bus):
Zdarzenia związane z uwierzytelnianiem dostępu do usług szyny ESB oraz
nieprawidłowości w operacjach kryptograficznych (podpisywanie i szyfrowanie
przekazywanych komunikatów) powinny być rejestrowane i przesyłane do centralnego
systemu SIEM gromadzącego i analizującego logi.
W szczególności, należy monitorować udane i nieudane uwierzytelnianie i dostępy do
usług (WebServices), nadawanie/modyfikację/usuwanie uprawnień do takiego dostępu oraz
fakt nieudanej weryfikacji autentyczności podpisu komunikatu, a także inne zdarzenia
raportowane przez rozszerzenia bezpieczeństwa szyny ESB (np. WS-Security).
Należy również monitorować zdarzenia zachodzące w systemach operacyjnych
i pozostałych ZI, na których zbudowana jest szyna ESB;
8) logi narzędzi bezpieczeństwa ochrony przed atakami i szkodliwym oprogramowaniem:
Zdarzenia raportowane przez te narzędzia powinny podlegać przeglądowi przez osoby
odpowiedzialne za administrację i poprawne funkcjonowanie tych narzędzi.
Oprócz codziennej analizy zdarzeń przez tych pracowników, raportowane zdarzenia
w zakresie wykrytych ataków i szkodliwego kodu powinny być przesyłane do centralnego
systemu SIEM i analizowane przez inny, niezależny od departamentów z obszaru IT
zespół zajmujący się bezpieczeństwem IT;
9) logi urządzeń sieciowych i telekomunikacyjnych:
Należy rejestrować i analizować zdarzenia zachodzące w tych urządzeniach, zarówno
dotyczące przesyłanego ruchu sieciowego, jak i związane z ich obsługą administracyjną, tj.
z nadawaniem uprawnień, konfiguracją poszczególnych portów i dołączaniem do nich
kolejnych urządzeń, zmianami polityk bezpieczeństwa/access list, zdalnego dostępu, itd.
3/3