Monitorowanie flowów sieciowych - cenne źródło danych dla systemów SIEM

Autor: Jacek Grymuza

O tym dlaczego warto zasilać popularne SIEM-y danymi z protokołu NetFlow i jego pochodnych.

 

SIEM jest centralnym systemem bezpieczeństwa dla większości organizacji…
Głównym systemem analitycznym do wykrywania i analizy zagrożeń bezpieczeństwa w organizacji jest system klasy SIEM. W systemie tym korelowane są logi z wielu źródeł danych, takich jak systemy operacyjne, bazy danych, urządzenia sieciowe, aplikacje czy też systemy bezpieczeństwa, w celu wykrywania potencjalnych zagrożeń i nadużyć bezpieczeństwa. Widoczność zagrożeń w tym systemie uzależniona jest nie tylko od jakości logów monitorowanych źródeł danych, ale i od zaimplementowanych korelacji. Korelacja to nic innego jak sekwencja określonych zdarzeń, które wskazują na wystąpienie określonej nieprawidłowości bezpieczeństwa. Kolekcjonując więc wiele źródeł danych w jednym miejscu, nie można zapominać o projektowaniu korelacji międzysystemowych, a więc korelacjach pomiędzy logami pochodzącymi z różnych systemów, których łączy jedna lub więcej wspólnych cech, np. adres IP.

siem overview

Rysunek 1: Mechanizm działania SIEM1

1 Źródło: https://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf


Monitorowanie flowów sieciowych jest ważnym punktem w projektowaniu defensywy organizacji…

Z jednym istotnych źródeł danych nie tylko dla zespołów NOC/SOC są systemy klasy Network Visibility, do której należy m.in. system FlowControl. Główną zaletą tego systemu jest poprawa widoczności anomalii sieciowych i zagrożeń bezpieczeństwa z poziomu całej organizacji, z racji tego, że monitorowane są flowy sieciowe z wszystkich istotnych urządzeń sieciowych organizacji, a więc widać wszystkie komunikacje sieciowe. Tylko na podstawie samych flowów sieciowych wg framework’u MITRE ATT&CK, o którym pisaliśmy w tym artykule można wykryć ponad 30 technik stosowanych przez cyberprzestępców. Na podstawie kategoryzacji MITRE, w systemie FlowControl zostały stworzone mechanizmy detekcji zagrożeń bezpieczeństwa wykrywające na chwilę obecną zagrożenia z siedmiu taktyk MITRE.

 
 Taktyka ATT&CK MITRE           
 Przykłady wykrywanych zagrożeń przez FlowControl XNS
 Initial Access  Wykrywanie niedozwolonych aktywności sieci P2P
 Credential Access  Wykrywanie ataków typu brute force na różne usługi, np. HTTP(s), FTP, IMAP, SSH, RDP, LDAPS, MS SQL 
 Wykrywanie nieautoryzowanych komunikacji LLMNR/NetBIOS
 Discovery      Wykrywanie anomalii sieciowych mogących mieć związek z bezpieczeństwem
 Wykrywanie nieautoryzowanego dostępu do określonych usług, np. Internet, DHCP, DNS, Mail Server
 Wykrywanie skanowania sieci
 Wykrywanie skanowania portów
 Wykrywanie rozprzestrzeniania się złośliwego oprogramowania
 Lateral Movement  Wykrywanie nieautoryzowanych połączeń RDP
 Command and Control     Wykrywanie aktywności na podejrzanych portach (w oparciu o Black i White-listy)
 Wykrywanie nieszyfrowanych połączeń do krytycznych serwerów/usług
 Wykrywanie komunikacji z podejrzanymi adresami IP, np. Botnet, Malware, C2, Ransomware
 Wykrywanie naruszeń polityk bezpieczeństwa, np. TOR, Open DNS, Open Proxy
 Exfiltration      Wykrywanie anomalii dot. protokołu DNS, np. Abnormal DNS Query Limit, Abnormal DNS Response Limit,   DNS Transfer Limit
 Wykrywanie dużej liczby niechcianych maili (SPAM)
 Wykrywanie prób eksfiltracji danych
 Wykrywanie transferów ogromnej ilości danych w krótkim przedziale czasu do/z organizacji
 Wykrywanie anomalii w protokołach sieciowych
 Impact   Wykrywanie ataków DoS, np. ICMP Flood, TCP Flood, UDP Flood
 Wykrywanie ataków amplifikacyjnych DDoS, np. DNS Amplification

 

 Korelacje międzysystemowe...

W związku z tym, że systemy klasy Network Visibility analizują ruch pochodzący z flowów sieciowych, pojedyncze alarmy z takiego systemu mogą nie być wystarczająco precyzyjne, aby zespół bezpieczeństwa podejmował się obsługi każdego pojedynczego alertu. Oprócz tego, tak jak w każdym systemie do wykrywania anomalii, niepoprawnie stuningowane reguły bezpieczeństwa mogą generować zbyt wiele False Positives, co de facto po pewnym czasie może prowadzić do ignorowania alertów z takich systemów przez zespół SOC. Z kolei „przekręcenie śrubki” w drugą stronę, gdzie systemy bezpieczeństwa wykrywają tylko oczywiste przypadki, może doprowadzić do tego, że zostaną przeoczone prawdziwe alarmy. Jaki jest więc złoty środek?
Jednym z rozwiązań tego problemu może być projektowania w SIEM korelacji międzysystemowych, które będą zwiększały krytyczność, a tam samym priorytety obsługi potencjalnych incydentów bezpieczeństwa. A zatem krytyczność pojedynczego alertu z systemu FlowControl powinna być inna niż cross-korelacja tego alertu z alertami wygenerowanymi przez inne systemy w kontekście określonego atrybutu. Na przykład pojedyńczy alert o nazwie „Brute Force Attack:WS-Management and PowerShell remoting via HTTP” powinien mieć inny priorytet obsługi niż ten sam alert powiązany dodatkowo z sekwencją zdarzeń podejrzanych aktywności wykrytych za pomocą monitorowania Sysmon. Występowanie wielu niepożądanych aktywności w określonym przedziale czasu, często świadczy o tym, że atakujący potrącił kilka „pachołków”, które rozstawiliśmy w różnych miejscach naszej organizacji aby wykrywać niepożądane aktywności, aby zwiększyć prawdopodobieństwo wykrycia rzeczywistego naruszenia procedur bezpieczeństwa organizacji. Tymi pachołkami są dla nas mechanizmy detekcji zagrożeń, które powinny być połączone z procedurami obsługi incydentów bezpieczeństwa.

Przykładowe korelacje międzysystemowe

Use Case FlowControl QRadar Wartość dodana korelacji międzysystemowych
 Wykrycie   podejrzanej   aktywności WinRM • Wykrycie aktywności na podejrzanym   porcie (5985) w danym segmencie   sieci
• Wykrycie ataku brute force na porcie   5985
• Wykrycie anomalii sieciowych
Na podstawie logów Sysmon:
• Wykrycie uruchomiania podejrzanych   aplikacji (Systools)
• Wykrycie uruchamiania aplikacji z katalogów   tymczasowych
• Szybsze wykrycie prawdziwych incydentów bezpieczeństwa
• Możliwość nadania wyższego priorytetu korelacjom międzysystemowym
• Możliwość wykrycia ataku w czasie jego trwania
• Ograniczenie liczby False Positives
 Wykrycie ataku   DDoS na sewerze   webowym  • Wykrycie ataku DDoS na podstawie   mechanizmów detekcji systemu   FlowControl  Na podstawie logów Apache:
• Wykrycie ataku na podstawie ogromnej   liczby kodów odpowiedzi 4xx w krótkim   przedziale czasu
 Wykrycie anomalii w   protokole DNS • Wykrycie anomalii w protokole DNS
• Wykrywanie nieautoryzowanych     serwerów DNS
• Wykrywanie tzw. Open DNS
 Na podstawie logów DNS:
• Wykrycie długich żądań DNS
• Wykrycie wielu żądań TXT z tego samego   adresu IP
• Wykrycie wielu żądań NXDOMAIN

 

 

 

detection of susicious winrm activities in flowcontrol

 Rysunek 2: Wykrycie podejrzanych aktywności dotyczących usługi WinRM w systemie FlowControl

 

correlations of flowcontrol alerts in sysmon logs

 Rysunek 3: Korelacje alertów FlowControl z logami SysMon

 

example of cross system rule in qradar siem system

Rysunek 4: Przykład reguły międzysystemowej w systemie QRadar SIEM

 

Podsumowanie
Korelacje międzysystemowe zwiększają skuteczność wykrywania zagrożeń poprzez generowanie mniejszej liczby False Positives. Systemy klasy Network Visibility są cennym źródeł informacji dla analityków zajmujących się obsługą incydentów bezpieczeństwa, czy też Threat Huntingiem, a także dla systemów klasy SIEM, które korelują logi z różnych systemów. Aby wysłać alerty bezpieczeństwa z systemu FlowControl do SIEM wystarczy podać w konfiguracji adres IP oraz port serwera Syslog. Oczywiście, nic nie stoi na przeszkodzie, ażeby analiza flowów sieciowych odbywała się bezpośrednio na silniku analitycznym systemu SIEM. W takim przypadku musimy rozważyć dodatkowe aspekty dotyczące rozbudowy architektury SIEM umożliwiającej przeanalizowanie miliardów flowów sieciowych dziennie, koszty dodatkowej licencji oraz koszty zasobów potrzebnych do zaprojektowania logiki wykrywającej anomalie i zagrożenia bezpieczeństwa w oparciu o flowy. Bez względu na to, którą drogę wybierzemy, starajmy się projektować reguły bezpieczeństwa w oparciu o możliwie jak największą liczbę źródeł danych, aby liczba pułapek pozostawionych dla atakujących była jak największa i spójna z procesem obsługi incydentów bezpieczeństwa organizacji. Pamiętajmy również o tym, że bezpieczeństwo jest procesem ciągłym, więc nie ma skończonej liczby scenariuszy bezpieczeństwa, które można zaimplementować w poszczególnych systemach security, aby następnie były one korelowane z alertami pochodzącymi z innych systemów w SIEM.

 

Autor: Jacek Grymuza, Senior Security Engineer w Passus S.A, członek Zarządu (ISC)2 Poland Chapter