Spis treści
SIEM: Centralny system bezpieczeństwa dla większości organizacji
Widoczność zagrożeń w systemie zależy nie tylko od jakości logów monitorowanych źródeł danych, ale także od wdrożonych korelacji. Korelacja to nic innego jak sekwencja zdefiniowanych zdarzeń wskazujących na wystąpienie konkretnej nieprawidłowości związanej z bezpieczeństwem. Dlatego gromadząc wiele źródeł danych w jednym miejscu, nie można zapominać o projektowaniu korelacji między systemami, czyli korelacji pomiędzy logami pochodzącymi z różnych systemów, ale posiadającymi jeden lub więcej wspólnych atrybutów, takich jak adres IP.
Zwiększenie zdolności obronnych dzięki monitorowaniu przepływów sieciowych
Kluczowymi źródłami danych, nie tylko dla zespołów NOC/SOC, są systemy klasy Network Visibility, takie jak system FlowControl. Główną zaletą tego systemu jest poprawiona widoczność anomalii sieciowych i zagrożeń bezpieczeństwa na poziomie całej organizacji. Jest to możliwe, ponieważ monitorowane są przepływy sieciowe ze wszystkich istotnych urządzeń sieciowych w organizacji, aby zapewnić wgląd we wszystkie komunikacje sieciowe. Analizując jedynie przepływy sieciowe zdefiniowane w ramach ATT&CK MITRE, jak opisano w naszym artykule: „ATT&CK MITRE jako skuteczna metoda obrony przed cyberzagrożeniami”, można wykryć ponad 30 technik wykorzystywanych przez cyberprzestępców. Na podstawie klasyfikacji MITRE, w systemie FlowControl zostały stworzone mechanizmy wykrywania zagrożeń bezpieczeństwa, które obecnie potrafią wykrywać typowe zagrożenia z siedmiu różnych taktyk MITRE.
Projektowanie skutecznych korelacji między systemami
Ponieważ systemy klasy Network Visibility analizują ruch generowany przez przepływy sieciowe, indywidualne alerty z tych systemów mogą nie być wystarczająco dokładne, by zespół bezpieczeństwa obsługiwał każdy alert z osobna. Dodatkowo, jak w każdym systemie zaprojektowanym do wykrywania anomalii, niepoprawnie dostrojone reguły bezpieczeństwa mogą generować zbyt wiele fałszywych alarmów, co w rzeczywistości może prowadzić do ignorowania alertów z tych systemów przez zespół SOC po pewnym czasie. Z drugiej strony, „poluzowanie śruby”, gdzie systemy bezpieczeństwa wykrywają jedynie oczywiste incydenty, może prowadzić do przeoczenia realnych zagrożeń. Gdzie zatem jest złoty środek?
Jednym z rozwiązań tego problemu może być projektowanie korelacji między systemami w SIEM, które zwiększą krytyczność potencjalnych incydentów bezpieczeństwa, a tym samym ich priorytet do obsługi. Dlatego krytyczność pojedynczego alertu z systemu Sycope powinna być inna niż korelacja tego alertu z alertami generowanymi przez inne systemy w kontekście konkretnego atrybutu. Na przykład, pojedynczy 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ń typową dla podejrzanej aktywności wykrytej za pomocą usługi monitorowania Sysmon. Występowanie wielu niepożądanych aktywności w określonym przedziale czasu często sygnalizuje, że atakujący potrącił pewne „pachołki”, które rozmieszczyliśmy w różnych lokalizacjach organizacji, by wykrywać niepożądane działania i zwiększyć prawdopodobieństwo wykrycia realnych naruszeń procedur bezpieczeństwa organizacji. Dla nas tymi „pachołkami” są mechanizmy wykrywania zagrożeń, które powinny być powiązane z procedurami obsługi incydentów bezpieczeństwa.
Wniosek: wykorzystanie danych z przepływów sieciowych do poprawy wykrywania zagrożeń
Korelacje między systemami zwiększają skuteczność wykrywania zagrożeń, generując mniej fałszywych alarmów. Systemy klasy Network Visibility to źródła cennych informacji dla analityków incydentów bezpieczeństwa, łowców zagrożeń (Threat Hunters), jak i dla systemów SIEM, które korelują logi z różnych systemów. Alerty bezpieczeństwa mogą być łatwo wysyłane z FlowControl do SIEM, ponieważ wystarczy jedynie podać adres IP i port serwera Syslog w kreatorze konfiguracji. Oczywiście nic nie stoi na przeszkodzie, by analiza przepływów sieciowych odbywała się bezpośrednio w silniku analitycznym SIEM. W takim przypadku należy jednak uwzględnić dodatkowe aspekty, w tym rozbudowę architektury SIEM do analizy miliardów przepływów sieciowych dziennie, koszty dodatkowych licencji oraz koszty zasobów potrzebnych do projektowania logiki wykrywania anomalii i zagrożeń bezpieczeństwa na podstawie danych z przepływów. Niezależnie od tego, którą ścieżkę wybierzemy, musimy dążyć do projektowania reguł bezpieczeństwa w oparciu o jak największą liczbę źródeł danych, tak by liczba pułapek pozostawionych dla atakujących była jak największa i spójna z procesem obsługi incydentów bezpieczeństwa w organizacji. Musimy również pamiętać, że bezpieczeństwo to proces ciągły, więc nie istnieje skończona liczba scenariuszy bezpieczeństwa, które można wdrożyć w poszczególnych systemach bezpieczeństwa, by korelować je z alertami z innych systemów w SIEM.
