Kupiliśmy SIEM (IBM QRadar) dlaczego i co dalej?

Transkrypt

1 Kupiliśmy SIEM (IBM QRadar) dlaczego i co dalej? Warsaw Michał Żyjewski Santander Bank Polska (BZWBK) menedżer Zespołu Monitorowania Bezpieczeństwa IT

2 Dlaczego kupujemy rozwiązanie typu SIEM? Wymagane przez Regulatorów Wymagania / Rekomendacje Audytowe Chcemy podnieść poziom Cyberbezpieczeństwa Działania naprawcze po Cyberataku Chcemy zbierać Logi Podążamy za trendami np. inni to już mają Sprzedawca nas na to namówił 2

3 Co już zostało Zrobione? Analiza rozwiązań na Rynku np. Gartner Współpraca z firmami Doradczymi Współpraca z znanymi Partnerami/Dostawcami Określenie wymagań funkcjonalnych (formularz oceny) PoC (Proof of Concept) testowanie wybranych rozwiązań Wybór rozwiązania (np. IBM QRadar) Określenie docelowej Architektury SIEM (Produkcja/DR/Test) Określenie liczby i typu Komponentów / Licencji (Hardware/Virtual/Software) 3

4 Dostawa z MX i? Przygotowanie Maszyn Instalacja w Data Center Konfiguracja Dodanie Licencji i? 4

5 Podłączamy pierwsze Źródła Logów Standardowy plan: Rozwiązania Protect (AV/APT/IPS/ ) Serwery Unix/Linux lub Windows Serwery Aplikacyjne (Exchange/Apache/ ) Urządzenia Sieciowe Bazy Danych Logi Aplikacyjne (DNS/DHCP/SMTP/ ) Logi z Własnych Aplikacji Pierwsze Problemy: Auto Discovery dodaje źródła których nie mamy np. 3Com a nie Cisco Brak przewodnika jak skonfigurować Źródło Logów Brak Parsera (DSM/LSX) Brak logów mimo prawidłowej konfiguracji Pierwsze dylematy: Nazewnictwo Źródeł Logów Hierarchia Źródeł Logów 5

6 Podłączamy koleje Źródła Logów Wyzwania: Czy mamy pełną ewidencje wszystkich Serwerów/Urządzeń Sieciowych/Baz Danych/Usług i Aplikacji? Czy mamy plan długofalowy integracji kolejnych Źródeł Logów z SIEM? Czy wiemy co podłączyliśmy a co nie? Czy wykrywamy gdy źródło przestanie przesyłać logi? Na co zwrócić uwagę: Licencja na EPS nie jest nieskończona Koszt licencji na EPS Logi nie używane w korelacji Nie wszystkie informacje z logów są rozpoznawane przez Parser (DSM/LSX) Niektóre logi są obcinane Czy są Procesy/Procedury/Instrukcje? 6

7 Reguły korelacyjne Standardowy plan: Uruchamiamy wybrane Reguły Korelacyjne lub grupy Use Case Stroimy w celu eliminacji najczęściej pojawiających się Fałszywych Alertów Szukamy przyczyn braku Alertów Pierwsze dylematy: Reguły Korelacyjne Wbudowane czy tworzymy Własne Pierwsze Problemy: Zbyt wiele Alertów lub ich Brak Brak osób które mogłyby Analizować wyniki działania Reguł Brak wiedzy czy Alerty są poprawne Brak wiedzy na temat Tworzenia Reguł Korelacyjnych Brak dokumentacji przeprowadzonych testów i analizy wyników 7

8 Dalsza praca z Regułami Korelacyjnymi Wyzwania: Czy prowadzimy dokumentacje zmian w Regułach Korelacyjnych? Czy mamy ustalony przebieg wdrażania zmian oraz ścieżkę aprobat? Czy i jak reagujemy na Burze Alertów? Czy Reguły i ich działanie jest poddawane przeglądowi i analizie? Na co zwrócić uwagę: Licencja na EPS nie jest nieskończona Koszt licencji na EPS Logi nie używane w korelacji Nie wszystkie informacje z logów są rozpoznawane przez Parser (DSM/LSX) Niektóre logi są obcinane Czy tworzone są nowe lub uruchamiane kolejne Reguły Korelacyjne? Czy są Procesy/Procedury/Instrukcje 8

9 Co z Alertami? Standardowy plan: Ktoś musi przeglądać Alerty Wszystkie Alerty powinny być przenalizowane Kady Alert powinien być zamknięte a wykonane akcje powinny być udokumentowane Wykryte incydenty powinny być zaadresowane i rozwiązane a ich wynikiem powinien być raport Pierwsze Problemy: Brak Zespołu Monitorującego i działającego 24/7 Brak Scenariuszy/Procedur Reakcji Brak określonej ścieżki decyzyjnej Długi czas oczekiwania na reakcje np. Administratora na zapytanie Brak wiedzy na temat architektury Sieci/Rozwiązania/Przepływu Danych Pierwsze dylematy: Definicje Incydentu i Fałszywego Alertu 9

10 Dalsza praca z Alertami Wyzwania: Jakość analizy Alertów Logi w SIEM nie wystarczają do Analizy Częste i powtarzalne Alerty Harmonogram pracy w trybie 24/7 Monotonia pracy Na co zwrócić uwagę: Szkolenie i Podnoszenie kompetencji zespołu Talenty członków zespołu i ich wzmacnianie Zadania które są delegowane a nie powinny trafiać do zespołu monitorującego 10

11 Thank you Michał Żyjewski Santander Bank Polska (BZWBK) menedżer Zespołu Monitorowania Bezpieczeństwa IT 11