Security Onion 2 – open source SIEM / SOC

Jakiś czas temu w artykule pt. Security Onion – Monitoring Bezpieczeństwa Sieci opisywałem podstawy systemu Security Onion. Wyjaśniałem w nim czym jest Security Onion, z jakich komponentów się składa i jakie ma możliwości jeśli chodzi o monitorowanie zdarzeń bezpieczeństwa. W niniejszym tekście zajmiemy się natomiast nową jego odsłoną – Security Onion 2.

Security Onion 2 – główne zmiany

Nowa wersja systemu wywarła na mnie naprawdę pozytywne wrażenie. Główne zmiany, które zaszły w stosunku do poprzedniej wersji to:

• Zastosowanie kontenerów – poszczególne komponenty (usługi) systemu stanowią niezależne kontenery, dzięki czemu łatwiej jest je kontrolować i utrzymać spójność całego systemu.
• Zastosowanie jednej, centralnej konsoli webowej (SOC – Security Onion Console) zamiast wielu niezależnych klientów
• Zgromadzenie w jednym miejscu (konsola SOC) zdarzeń ze wszystkich usług monitorujących (IDS, Wazuh, event logi itd.)
• Włączenie dodatkowych narzędzi dających możliwość analizy i tworzenia tzw. IOC oraz zgłaszania i obsługi incydentów bezpieczeństwa.

I to właśnie ta integracja wszystkich zdarzeń i interfejsów w jednej centralnej konsoli jest zmianą, na którą długo czekałem. Wcześniej takie rozwiązanie widziałem w bazującym również na komponentach open source systemie Alien Vault, który był jednak produktem komercyjnym i dosyć kosztownym.

Do tego wszystkiego powstała dość bogata i spójna dokumentacja, która pozwala osobom początkującym szybko zapoznać się z systemem (https://docs.securityonion.net/en/2.3/about.html).

Instalacja Security Onion 2

Najnowszą wersję obrazu ISO pobrałem ze strony https://securityonionsolutions.com/software. W celach testowych postanowiłem zainstalować system w formie maszyny wirtualnej VirtualBox-a. Daje to większą elastyczność w zarządzaniu, ale trzeba pamiętać, że wymogi dla minimalnej nawet (ewaluacyjnej) wersji to:

• 12 GB RAM
• 2-4 rdzenie CPU
• 200 GB przestrzeni dyskowej
• 2 interfejsy sieciowe (jeden do monitorowania ruchu sieciowego, drugi do zarządzania i komunikacji z usługami)

Da się je co prawda jeszcze nieco obciąć, ale może to skutkować niespodziewanym „wykrzaczeniem” się systemu jeśli nagle zabraknie mu zasobów. Na szczęście nawet po takim nagłym restarcie system wstaje bez większych problemów. Jeśli jednak pracujecie na Windowsach, to musicie się liczyć z tym, że nie tylko zrestartuje się maszyna z Security Onion, ale Windows pozdrowi was nieśmiertelnym blue screenem (na warsztatach, które niedawno prowadziłem zdarzyło się to kilku osobom, więc to nie jednostkowy przypadek).

Zaletą instalacji w formie maszyny wirtualnej jest możliwość monitorowania ruchu sieciowego pochodzącego z innych maszyn na tym samym hoście fizycznym bez konieczności stosowania TAP-a lub zarządzalnego switcha, o czym wspominałem w pierwszym tekście o Security Onion.

Po wskazaniu pliku ISO jako napędu CD, maszyna wirtualna startuje i wita nas instalator:

Następnie wybieramy domyślną opcję bootowania lub czekamy kilka sekund aż system sam wystartuje.

Pominę tutaj oczywiste kroki typu potwierdzanie chęci sformatowania dysku, ustawianie hasła administratora czy akceptacja licencji. Skupię się natomiast na krokach, które są najistotniejsze i mogą przysporzyć problemów osobom nie mającym wcześniej styczności z systemem Security Onion.

Pierwszy etap instalacji przebiega automatycznie, po czym system się restartuje i wita nas konsolą logowania do systemu CentOS 7. To kolejna zmiana, ponieważ poprzednia wersja Security Onion domyślnie była dostarczana na Ubuntu. (Możliwość instalacji na Ubuntu dalej pozostała, ale musielibyśmy ją przeprowadzić sami, bez gotowego instalatora w formie obrazu ISO).

Konfiguracja Security Onion 2

Po zalogowaniu się do CentOS-a użytkownikiem stworzonym w procesie instalacji, automatycznie uruchamia się proces konfiguracji z pomocą kreatora.

Pierwszym ważnym wyborem, którego musimy dokonać jest wskazanie trybu instalacji:

• EVAL – instalacja do celów testowych/edukacyjnych – wszystkie usługi będą uruchomione na jednym systemie. Ten tryb instalacji wybieramy w sytuacji gdy chcemy się zapoznać z Security Onion przed jego docelowym wdrożeniem. Ten tryb sugeruję Wam wybrać za pierwszym razem (co i ja czynię na potrzeby tego artykułu).
• STANDALONE – podobnie jak wyżej, wszystkie usługi będą zainstalowane na jednym systemie, ale z przeznaczeniem produkcyjnym. Wiąże się to z większym zapotrzebowaniem na zasoby i nadaje się do monitorowania mniejszych środowisk.
• DISTRIBUTED – instalacja rozproszona, przeznaczona do monitorowania dużych środowisk. Tutaj w kolejnym kroku będziemy musieli wybrać które komponenty chcemy zainstalować na danej stacji oraz czy jest to pierwsze wdrożenie systemu, czy instalacja w ramach już istniejącej infrastruktury. W dużych środowiskach zalecane jest posiadanie wielu sond w różnych segmentach sieci i centralnej bazy oraz konsoli.
• IMPORT – instalacja służąca jedynie do analizy danych pochodzących z zewnątrz. W tym trybie system zamiast monitorować i gromadzić dane z sieci dokonuje analizy zaimportowanych do niego próbek, np. ruchu sieciowego w formie plików PCAP.

Interfejsy i adresacja w Security Onion 2

Kolejnym ważnym krokiem będzie wskazanie, który z interfejsów sieciowych ma być użyty jako „management NIC”. Jest to interfejs, do którego przypisany zostanie adres IP lub nazwa domenowa i na którym uruchomiona będzie główna konsola systemu. Na tym interfejsie będą też nasłuchiwały usługi zbierające dane z zewnętrznych systemów (np. event logi z Windowsów). Pamiętajcie więc aby interfejs ten znajdował się w VLAN-ie, w którym zlokalizowane będą inne serwery mające podlegać monitorowaniu.

W kolejnym kroku instalator zapyta nas czy chcemy zdefiniować statyczny czy dynamiczny adres IP. I tutaj warto się zastanowić, gdyż późniejsza zmiana głównego adresu może być problematyczna. Jeśli chcemy by adres przydzielany był przez serwer DHCP, to warto zadbać o rezerwację stałego adresu IP dla Security Onion. Pamiętajcie, że na ten adres będą wysyłane m.in. logi z agentów, więc jego niekontrolowana zmiana wiązałaby się z koniecznością rekonfiguracji wszystkich końcówek.

Ważnym krokiem jest też ustawienie odpowiedniej nazwy domeny (DNS search domain). Domyślna nazwa „searchdomain.local” powinna być zastąpiona rzeczywistą nazwą domeny używaną w naszym środowisku – taką którą będą w stanie rozwiązać nasze serwery DNS.

Kolejną czynnością na tym etapie konfiguracji będzie wskazanie minimum jednego interfejsu monitorującego ( Monitor Interfaces). Będą to interfejsy sieciowe działające w trybie promiscuous (czyli nasłuchujące cały ruch, a nie tylko ten adresowany na ich własny MAC). Interfejs taki powinien być wpięty do portu w switchu, na którym mamy możliwość obserwacji całego ruchu przechodzącego przez switch. W zależności od producenta będzie on nazywany portem typu SPAN, monitor lub mirror. W przypadku środowisk wirtualnych konieczne może być włączenie opcji nasłuchiwania w ustawieniach switcha lub interfejsu sieciowego maszyny wirtualnej. Poniżej przykład takiego ustawienia na interfejsie maszyny w środowisku VirtualBox:

W kolejnym kroku instalator zapyta nas o adresacje lokalnych sieci sugerując domyślnie wartości sieci prywatnych:

• 10.0.0.0/8
• 192.168.0.0/16
• 172.16.0.0/12

Wybrane podsieci będą automatycznie dodane do wyjątków w lokalnej zaporze, dzięki czemu agenci instalowani na monitorowanych serwerach będą mogli komunikować się z interfejsem naszej konsoli SOC. Te ustawienia można później łatwo zmodyfikować, więc nie przejmujcie się jeśli coś przeoczycie.

Ostatni etap konfiguracji

W ostatnich krokach definiujemy:

• które z usług chcemy zainstalować (domyślnie zaznaczone są wszystkie i tak warto pozostawić jeśli chcemy się zapoznać z systemem)
• czy chcemy zmieniać domyślną adresację IP kontenerów (lepiej tego nie robić bez konkretnych powodów)
• adres e-mail i hasło użytkownika, którym będziemy się logować do centralnej konsoli (SOC)
• tryb wywoływania adresu konsoli w przeglądarce (IP bądź nazwa domenowa) – tutaj bezpieczniej będzie wskazać IP jeśli mamy pewność, że nie ulegnie ono zmianie. W przypadku nazwy domenowej musimy bowiem mieć pewność, że odpowiednio skonfigurowaliśmy wcześniej domenę wyszukiwania oraz że nasz serwer DNS będzie w stanie rozwiązać nazwę, którą przypisaliśmy systemowi Security Onion podczas instalacji.
• serwery czasu NTP (konfigurator domyślnie podpowiada 0.pool.ntp.org oraz 1.pool.ntp.org i tak możemy pozostawić jeśli nie posiadamy własnych serwerów NTP)
• dodatkowe adresy IP lub adresy sieci, z których będziemy się łączyć do naszej konsoli SOC (bez ich zdefiniowania połączenia będą odrzucane przez zaporę, ale można je dodać również później)

Na koniec pozostaje nam się uzbroić w cierpliwość gdyż proces ostatecznej konfiguracji systemu i wszystkich usług może zająć grubo ponad 30 min. Na szczęście nie wymaga on już aktywności z naszej strony.

Przydatne polecenia Security Onion 2

Na co dzień do pracy z Security Onion 2 wystarczy nam konsola webowa. Warto jednak poznać kilka poleceń, które mogą się przydać po zalogowaniu do konsoli systemowej. Pozwolą one na sprawdzenie stanu wszystkich usług lub wprowadzenie drobnych zmian konfiguracyjnych. Poniżej najważniejsze z poleceń, które musiałem poznać podczas wdrożenia i pracy z Security Onion w werji 2:

• so-status – sprawdzenie statusu wszystkich usług (kontenerów). Ich uruchomienie może zająć ładnych parę minut, dlatego zanim zalogujemy się do konsoli webowej warto sprawdzić czy wszystkie zostały prawidłowo wystartowane. Efekt tego polecenia powinien być taki jak na poniższym obrazku (jeśli któraś z usług jest w trybie „starting” musimy po prostu poczekać):

• so-allow – dodanie do wyjątków zapory otwartych portów dla poszczególnych usług oraz klientów (lub całych podsieci). Np. do komunikacji z serwerem zainstalowanych na końcówkach agentów osquery oraz wazuh konieczne jest otwarcie portów 8090, 1514 i 1515. Omówimy to nieco później na konkretnym przykładzie.
• so-wazuh-agent-manage -l – wyświetla listę agentów wazuh zarejestrowanych na serwerze – warto wykonać po konfiguracji agenta na monitorowanym systemie aby upewnić się, że prawidłowo skomunikował się on z serwerem
• so-nazwa_uslugi-start , so-nazwa_uslugi-stop , so-nazwa_uslugi-restart pozwalają włączać, wyłączać i restartować poszczególne komponenty, np.: so-wazuh-stop, so-wazuh-start, so-suricata-restart

Ponadto do zarządzania poszczególnymi usługami przeznaczone są polecenia rozpoczynające się od nazwy so-nazwa_uslugi-* . Możemy więc przykładowo wpisać niepełne polecenie: „so-wazuh-” i naciskając TAB zobaczyć możliwe komendy związane z daną usługą (np. so-wazuh-agent-manage, so-wazuh-user-add itd.)

SOC – Security Onion Console czy Security Operation Center?

Twórcy systemu Security Onion 2 prawdopodobnie celowo zdecydowali się nazwać centralną konsolę webową w taki sposób, by skrót od niej – SOC kojarzył się z Security Operation Center. Security Onion posiada bowiem wszystkie niezbędne komponenty, które pozwolą wdrożyć i utrzymać zespół SOC. Pozwala on m.in. na:

• Rejestrowanie zdarzeń istotnych z punktu widzenia bezpieczeństwa
• Tworzenie na ich podstawie incydentów bezpieczeństwa (ticketów)
• Analizę tych incydentów poprzez poszukiwanie zdarzeń powiązanych (korelacja)
• Identyfikowanie i definiowanie tzw. IOC ( Indicator of Compromise – elementów charakterystycznych dla danego incydentu, np. nazwa złośliwej domeny lub hash pliku)
• Poszukiwanie zdefiniowanych IOC w innych systemach
• Ustawianie powiadomień
• Kategoryzację zdarzeń

A może SIEM?

Jednym z głównych komponentów Security Onion 2 jest IDS sieciowy w postaci systemu Suricata. Rejestruje on zdarzenia, które jest w stanie wyłapać z widzianego przez interfejs monitorujący ruchu sieciowego. Żeby jednak mówić o funkcjonalności zbliżonej do SIEM-a konieczne jest również analizowanie zdarzeń występujących na poziomie monitorowanych systemów. Do tego w Security Onion służą dwa podstawowe rodzaje agentów:

• Wazuh Agent – jest to agent Host IDS-a znanego kiedyś pod nazwą OSSEC. Monitoruje on integralność systemu na którym jest zainstalowany i informuje o zdarzeniach istotnych z punktu widzenia bezpieczeństwa. Powiadomi nas np. o zmianach w istotnych kluczach rejestru Windows lub zmianach w plikach systemowych albo o zalogowaniu się administratora/roota do systemu. Informacje te przesyła do centralnej konsoli Security Onion (SOC).
• Osquery – agent pozwalający odpytywać za pomocą składni zbliżonej do SQL-a zdalne systemy np. o ich konfigurację lub zainstalowane oprogramowanie. Co ważne pozwala on wykonywać zapytania na różnych końcówkach, niezależnie od tego pod kontrolą jakiego systemu operacyjnego pracują. Dzięki niemu jesteśmy w stanie znaleźć np. serwery, na których zainstalowano określoną wersję podatnej aplikacji lub niewspierany system operacyjny.

Security Onion 2 uzbrojony w network IDS-a (Suricata) oraz agentów zainstalowanych na monitorowanych stacjach potrafi naprawdę sprawnie wyłapywać zdarzenia, którym warto się przyjrzeć. Zanim jednak przejdziemy do omawiania tych zdarzeń zajmijmy się instalacją wspomnianych agentów na końcówkach.

Instalacja agentów

Pliki instalacyjne znajdziemy po zalogowaniu się do konsoli webowej (SOC) w zakładce „Downloads”.

Pamiętajcie, że konsola dostępna jest pod adresem IP interfejsu zdefiniowanego przy instalacji jako „management interface”. Odwoływać się do niej powinniśmy stosownie do tego, co podaliśmy podczas instalacji – albo przez adres IP, albo przez nazwę. A dostęp będzie możliwy tylko z adresów lokalnych hostów/sieci podanych podczas instalacji lub dodanych później poleceniem so-allow. I najważniejsze – logujemy się nie nazwą użytkownika będącego administratorem Security Onion 2, a dedykowanym adresem mailowym i hasłem zdefiniowanym podczas instalacji.

Procedura instalacji agenta Wazuh:

1. Dodajemy adres IP klienta na serwerze Security Onion 2 poleceniem so-allow (wybieramy najpierw port 1514 [w], a następnie port 1515 [r])
2. Pobieramy instalkę agenta Wazuh z zakładki 'download’ w konsoli webowej Security Onion (SOC)
3. Instalujemy agenta na końcówce
4. Jeśli agent jest instalowany na systemie Windows uruchamiamy polecenie:
   c:\program files (x86)\ossec-agent\agent-auth.exe -m IP_MANAGERA
   (gdzie IP_MANAGERA to adres ip serwera Security Onion)
5. Jeśli agent jest instalowany na systemie Linuks uruchamiamy polecenie:
   /var/ossec/bin/agent-auth -m IP_MANAGERA (gdzie IP_MANAGERA to adres IP serwera Security Onion)
6. Sprawdzamy na serwerze Security Onion czy agent został prawidłowo dodany uruchamiając polecenie:
   so-wazuh-agent-manage -l
   (powinien być dodany nowy klient z adresem ip: any)
7. Na końcówce gdzie był instalowany agent, w pliku konfiguracyjnym c:\program files (x86)\ossec-agent\ossec.conf (lub /var/ossec/etc/ossec.conf dla Linuksa) ustawiamy IP managera (serwera Security Onion) zastępując zera w sekcji:
   <client><serwer><address>0.0.0.0</address>
8. Restartujemy usługę Wazuh
   na Windowsie: net stop wazuh, net start wazuh
   na Linuksie: systemctl restart wazuh-agent
9. Sprawdzamy w logach (ossec.log) czy nawiązane zostało połączenie z serwerem.
10. W razie problemów w systemie Windows możemy też uruchomić Agent Managera: c:\program files (x86)\ossec-agent\win32ui.exe

Jeśli w okienku widzimy status „Running” odpowiednio ustawiony Manager IP i Authentication key (nie musimy go znać, jest generowany automatycznie), możemy przejść do zakładki View – View Logs. W logach natomiast powinny się znaleźć informacje podobne do poniższych:

...
2022/06/30 16:52:45 ossec-agent: INFO: Started (pid: 2064).
2022/06/30 16:52:45 ossec-agent: INFO: Using AES as encryption method.
2022/06/30 16:52:45 ossec-agent: INFO: Trying to connect to server (192.168.2.175:1514/udp).
2022/06/30 16:52:45 ossec-agent: INFO: (4102): Connected to the server (192.168.2.175:1514/udp).
2022/06/30 16:52:45 ossec-agent: INFO: Windows version is 6.0 or newer. (Microsoft Windows 10 Enterprise [Ver: 10.0.17134] - Wazuh v3.13.1).
2022/06/30 16:52:45 ossec-agent: INFO: (1951): Analyzing event log: 'Application'.
2022/06/30 16:52:45 ossec-agent: INFO: (1951): Analyzing event log: 'Security'.
2022/06/30 16:52:45 ossec-agent: INFO: (1951): Analyzing event log: 'System'.
...

Procedura instalacji agenta osquery:

1. Dodajemy adres IP klienta na serwerze Security Onion 2 poleceniem so-allow (wybieramy port 8090 [o])
2. Pobieramy instalkę agenta (launcher) z zakładki 'download’ w konsoli webowej Security Onion (SOC)
3. Instalujemy launchera na końcówce
4. To wszystko 🙂

Testowanie agentów

W przypadku agenta Wazuh jego działanie będzie można łatwo stwierdzić po obecności w alertach powiadomień dotyczących takich zdarzeń jak np. uruchomienie usługi agenta Wazuh czy zalogowanie się w systemie administratora. Są to zdarzenia występujące dosyć często i łatwo je wyłapiemy.

Nieco inaczej ma się sprawa z agentem osquery. Aby sprawdzić jego działanie i możliwości, które oferuje musimy przejść do głównej konsoli webowej (SOC) i wybrać zakładkę „FleedDM”. Oczom naszym ukaże się panel z ogólnym widokiem zawierającym informacje o monitorowanych systemach. Nie znajdziemy tam raczej nic interesującego, więc od razu przechodzimy do zakładki „Hosts”, gdzie widoczne będą nieco bardziej szczegółowe informacje o systemach, na których zainstalowaliśmy agenta:

Tutaj możemy wybrać któryś z systemów i poznać więcej szczegółów na jego temat:

Prawdziwa potęga tego narzędzia kryje się jednak w zapytaniach, które możemy wykonywać wybierając w prawym górnym rogu link „Query” i przeszukując gotową listę zapytań lub wpisując własne:

Wpiszmy więc przykładowe zapytanie wybierając przycisk „Create custom query:”

Po wybraniu przycisku „Run query” zostaniemy jeszcze zapytani o wybór hostów, na których zapytanie ma zostać wykonane:

Domyślnie na liście będzie tylko host, z którego widoku przeszliśmy do wykonywania zapytania. Możemy jednak dodać kolejne wyszukując ich nazwy w polu wyszukiwania z lupką. Następnie klikamy przycisk „Run” i oczom naszym ukazują się wyniki zapytania wykonanego na poszczególnych końcówkach:

Na powyższym obrazku możemy zauważyć, że zapytanie zwróciło ustawienia Windows Security Center dotyczące komponentów takich jak antywirus, automatyczne aktualizacje czy zapora. W przypadku zapory status „Poor” wskazuje, iż na danym hoście jest ona wyłączona.

Jak widać narzędzie to może się okazać bardzo przydatne w wyszukiwaniu potencjalnych problemów w naszym środowisku.

Przeglądanie alertów

Mając już skonfigurowane wszystkie usługi oraz agentów możemy w końcu przyjrzeć się głównej konsoli zawierającej alerty (konsola webowa SOC -> zakładka „Alerts”). Na pierwszy rzut oka ich ilość może się wydać trochę przytłaczająca. Nie przejmujcie się tym – to samo czuje każdy administrator, każdego SIEM-a 🙂

Dlatego pierwsze co powinniśmy zrobić to z rozwijalnej listy przy lupce, gdzie domyślnie wybrana jest wartość „Ungroup” wybrać „Group by Name, Module”. Dzięki temu zdarzenia tego samego typu zostaną połączone (zgrupowane) a obok alertu w kolumnie „count” będziemy widzieć ilość wystąpień każdego z nich.

W ten sposób liczbę alertów do przejrzenia zredukujemy do mniej przerażających rozmiarów:

Jeśli nadal trudno nam się połapać w ilości alertów, możemy zacząć od tych najbardziej krytycznych. O krytyczności alertu (low/medium/high) informuje nas kolor dzwoneczka oraz kolumna „event.severity_label” (uwaga: kolumna ta czasem chowa się poza widoczny obszar i trzeba wówczas przeskalować zawartość okna przeglądarki przez „CTRL-” , niestety z niewiadomego powodu nie pojawia się poziomy pasek przewijania). Klikając na nagłówek kolumny „event.severity_label” możemy więc ustawić nasze alerty w kolejności od tych najbardziej krytycznych (high) do najmniej krytycznych (low).

Obsługa alertów

Zatwierdzanie alertów

Przyjrzyjmy się teraz bliżej alertom i możliwościom ich obsługi. Weźmy z powyższego obrazka przykładowy alert: „Windows Logon Success”. Widzimy 172 wystąpienia tego zdarzenia. Informuje nas ono o tym, że ktoś zalogował się do systemu Windows. Jeżeli powiadomienie dotyczy standardowych stacji roboczych, na których pracują użytkownicy, to raczej nie będziemy chcieli weryfikować każdego takiego zdarzenia. Możemy zatem zatwierdzić, że zapoznaliśmy się z nimi i nie budzą one naszych podejrzeń. Robimy to klikając symbol dzwoneczka, do którego domyślnie przypisana jest akcja „acknowledge”. Spowoduje to usunięcie tej grupy zdarzeń z listy alertów (ale tylko do momentu ich ponownego wystąpienia). Stałym wyłączaniem reguł zajmiemy się nieco później.

Analiza alertów

Rozważmy teraz nieco inny przypadek. Na liście alertów widzimy zdarzenie o wysokim poziomie zagrożenia „ET POLICY IP Check Domain (myexternalip .com in TLS SNI)” występujące 9 razy. Aby przyjrzeć się mu bliżej musimy kliknąć właśnie w tę dziewiątkę oznaczającą liczbę jego powtórzeń. Zostaniemy wówczas przeniesieni do szczegółowej listy wystąpień tego zdarzenia, na której z kolei każde z tych wystąpień będziemy mogli rozwinąć aby zapoznać się ze szczegółami:

Oprócz podstawowych danych takich jak źródłowy i docelowy adres IP oraz ich geolokalizacja i nazwa organizacji będącej właścicielem (wg WHOIS), w polu „network.data.decoded” znajdziemy zapis ruchu sieciowego, z którego dany alert został wzbudzony. W powyższym przykładzie informacje te nie będą czytelne ponieważ pochodzą z ruchu przechwyconego na porcie 443, czyli zaszyfrowanego TLS-em. Klikając na to pole możemy jednak wykonać kilka przydatnych akcji, m.in. wyeksportować przechwycony ruch do pliku PCAP lub przesłać do zewnętrznego narzędzia (np. Google, VirusTotal lub CyberChef):

W jaki jednak sposób zaszyfrowany ruch został uznany za podejrzany? Otóż w tym wypadku chodziło o domenę „myexternalip.com”. Pod tym adresem znajduje się serwis służący do sprawdzania adresu IP bramy, z której korzystamy podczas połączenia z Internetem. Z adresu tego korzystają m.in. wtyczki do przeglądarek, które wyświetlają aktualny, publiczny adres IP, pod którym się znajdujemy. Czy zdarzenie takie rzeczywiście należy traktować jako poważne? Jest to już kwestia naszego podejścia, ale pokazuje to, że Security Onion w poszukiwaniu potencjalnych zagrożeń może być naprawdę drobiazgowy.

Eskalacja alertów

Poza przeglądaniem, analizą i akceptowaniem alertów możemy też dokonywać ich eskalacji do rangi incydentu bezpieczeństwa. W tym celu należy kliknąć niebieski wykrzyknik przy konkretnym zdarzeniu lub grupie zdarzeń. Weźmy kolejny przykład z naszej listy alertów (3 obrazki wyżej): „ET POLICY Dropbox.com Offsite File Backup in Use”. W tym wypadku już z samej nazwy możemy się domyśleć, że chodzi o korzystanie z serwisu Dropbox.

Załóżmy, że pracujemy w organizacji, w której obowiązuje bardzo restrykcyjna polityka ograniczająca wynoszenie danych poza firmę. Korzystanie z Dropboxa przez któregoś z pracowników stanowiło będzie w tym wypadku poważne naruszenie zasad bezpieczeństwa. Zdarzenie to będziemy więc chcieli potraktować jako incydent wymagający dokładniejszego zbadania.

Klikamy zatem symbol wykrzyknika i wybieramy jedną z dwóch opcji:

• Escalate to new case – jeśli jest to pierwsze wystąpienie danego incydentu
• Attach event to a recently viewed case – jeśli chcemy dodać zdarzenie jako kolejne wystąpienie w ramach już istniejącego incydentu

Po eskalacji zdarzenia zniknie ono z listy alertów, podobnie jak to miało miejsce w przypadku zdarzeń zatwierdzanych (akceptowanych). I tutaj warto wspomnieć o rozwijanej liście opcji, która znajduje się na samej górze okna z alertami:

Pozwoli nam ona włączyć wyświetlanie ukrytych już alertów, zarówno tych zatwierdzonych, jak i tych eskalowanych.

Cases (incydenty)

Wszystkie zgłoszone na podstawie alertów incydenty znajdziemy natomiast łatwo w zakładce Cases:

Rozwijając każdy z incydentów na liście jesteśmy w stanie zapoznać się z jego szczegółami, a klikając symbol lornetki przechodzimy do okna edycji, które pozwala nam na jego obsługę w sposób znany nam z systemów ticketowych:

W oknie tym możemy przypisać osobę odpowiedzialną za obsługę, zmienić status i priorytet zgłoszenia, dodać kategorię lub tagi (menu po prawej), a także dodawać komentarze, załączniki, artefakty IOC (observables) oraz inne, powiązane zdarzenia.

Trochę szkoda, że twórcy Security Onion 2 nie trzymają się tutaj utartego w branży nazewnictwa – security incidents brzmiałoby lepiej niż cases, a Indicator Of Compromise (IOC) zrozumialej niż Observables.

Pozwólcie, że na tym zakończę nasze pierwsze spotkanie z nową odsłoną Security Onion. Przeszliśmy od instalacji do obsługi pierwszych alertów. Jest to niestety tylko wierzchołek góry lodowej, ale mam nadzieję, że te kilkanaście godzin poświęcone na przygotowanie tekstu oszczędzi Wam trudów przy pierwszym kontakcie z monitorowaniem bezpieczeństwa.

Obserwuj

Obserwuj