Tag: SIEM

W tym artykule, poznasz kompleksowe podejście do tematu monitorowania bezpieczeństwa usług biznesowych oraz infrastruktury krytycznej, a co za tym idzie – podłączania systemów źródłowych do systemu SIEM (ang. Security Information and Event Management System). Co to oznacza?

Podczas planowania polityki monitorowania systemów i usług powinniśmy pamiętać, by obejmowało ono  całą ścieżkę przetwarzania informacji. Tylko kompleksowe, wielopoziomowe podejście może odpowiednio wspomóc nas w monitorowaniu i wykrywaniu incydentów.  

Oczywiście, żaden system nie zagwarantuje nam 100% bezpieczeństwa. Rozwój zagrożeń jest obecnie tak szybki, że potrafią one ewoluować już z dnia na dzień. Dobrze przemyślane wdrożenie – w szczególności podłączenie właściwych systemów źródłowych (z odpowiednim poziomem logowania zdarzeń) zwiększy prawdopodobieństwo na detekcję niepożądanych zdarzeń. Wyznacznikiem do monitorowania usług są obowiązujące przepisy prawa, normy czy standardy. Należy również pamiętać, że najlepsze praktyki w zakresie wdrożenia polityki bezpieczeństwa w organizacjach, zobowiązują do monitorowania i wykrywania incydentów bezpieczeństwa, jak również ich późniejszej obsługi.

W tym artykule znajdziesz informacje na temat podejścia do podłączania systemów źródłowych z punktu widzenia zespołu planującego wdrożenie monitorowania usługi biznesowej:

Jak przeprowadzić proces podłączenia systemów?
Na jakie elementy warto zwrócić uwagę podczas konfigurowania systemu SIEM?

Proces podłączania systemów źródłowych do systemu SIEM

Załóżmy, że posiadamy już zamkniętą listę usług biznesowych, z podziałem na ich krytyczność, przypisanych właścicieli oraz osoby merytoryczne (czytaj – użytkownicy oraz administratorzy aplikacji). Nasze prace związane z monitorowaniem usługi biznesowej powinniśmy rozpocząć od inwentaryzacji systemów biorących udział w przetwarzaniu informacji przez tą usługę. Zależnie od organizacji, możemy je podzielić zgodnie z poniższą tabelą:

Jest to tylko przykład. Generalnie chodzi o to, abyśmy mieli pełną świadomość, jakie elementy naszej infrastruktury „biorą” udział w przetwarzaniu informacji.

Z punktu widzenia bezpieczeństwa wszystkie elementy (rodzaje systemów) mogą mieć wpływ na działanie takiej usługi. Dlatego istotne jest, aby zbierać/przesyłać zdarzenia do systemu SIEM, ze wszystkich warstw systemu, nie punktowo lub jednowymiarowo. Mając „pod ręką” zdarzenia z różnych systemów mamy możliwość ich korelacji co pozwoli na szybsze wykrycie zdarzenia/incydentu bezpieczeństwa oraz adekwatną reakcję. Jednocześnie należy pamiętać o właściwym zabezpieczeniu tych systemów przed zagrożeniami zewnętrznymi oraz wewnętrznymi (np. regularne aktualizacje, hardening). Niniejszy artykuł nie obejmuje swoim zakresem sposobów zabezpieczenia systemów. Patrząc na powyższą tabelę, łatwo dojść do wniosku, że systemy Infrastrukturalne oraz Bezpieczeństwa należy podłączyć do systemu SIEM, ponieważ należą do części wspólnej dla większości monitorowanych aplikacji (systemów biznesowych). Oczywiście wspominam w tym miejscu o klasycznej infrastrukturze, niewchodzącej w skład infrastruktury OT, która powinna być w jakiś sposób odizolowana.

Zatem, w pierwszej kolejności powinniśmy nasze prace rozpocząć od podłączenia systemów Infrastrukturalnych oraz Bezpieczeństwa. Podłączając każdy system powinniśmy się kierować co najmniej następującymi wytycznymi:

Ustalić z administratorem i skonfigurować właściwy poziom logowania. Właściwy, to znaczy taki, który pozwoli nam stworzyć potrzebne reguły bezpieczeństwa. Można zacząć od standardowych polityk. W kolejnym etapie wdrożenia można zmodyfikować niniejszy zakres.

Przykłady:

– Podłączając systemy Windows na początek przekazujemy dzienniki security. Już w oparciu o te zdarzenia jesteśmy w stanie stworzyć wiele reguł bezpieczeństwa, które podwyższą poziom bezpieczeństwa w organizacji;-

– Podłączając systemy Firewall zwróćmy uwagę, które połączenia mają włączone logowanie. Czy będziemy mieć informacje na temat wszystkich połączeń przychodzących od strony sieci Internet, czy tylko te, które są blokowane? Wszystko musimy dokładnie przeanalizować wspólnie z administratorem systemu i wspólnie powinniśmy podjąć decyzję, zgodną z naszą Polityką Bezpieczeństwa. Musimy „wyważyć” przede wszystkim dwie kwestie, tj. ilość odbieranych EPS (zdarzeń na sekundę) przez system SIEM a wykorzystanie tych zdarzeń dla stworzenia tzw. Use Cases (przypadków użycia/scenariuszy bezpieczeństwa).  Przecież nie sposób jest włączyć logowanie dla wszystkich lub większości połączeń. Należy sobie również postawić pytanie,  czy wykorzystamy takie zdarzenia na etapie tworzenia przypadków użycia? Druga kwestia to ograniczenie w postaci licencji, która pozwala na przetwarzanie określonej ilości zdarzeń np. w ciągu doby.

Podłączając systemy Windows na początek przekazujemy dzienniki security. Już w oparciu o te zdarzenia jesteśmy w stanie stworzyć wiele reguł bezpieczeństwa, które podwyższą poziom bezpieczeństwa w organizacji;
Podłączając systemy Firewall zwróćmy uwagę, które połączenia mają włączone logowanie. Czy będziemy mieć informacje na temat wszystkich połączeń przychodzących od strony sieci Internet, czy tylko te, które są blokowane? Wszystko musimy dokładnie przeanalizować wspólnie z administratorem systemu i wspólnie powinniśmy podjąć decyzję, zgodną z naszą Polityką Bezpieczeństwa. Musimy „wyważyć” przede wszystkim dwie kwestie, tj. ilość odbieranych EPS (zdarzeń na sekundę) przez system SIEM a wykorzystanie tych zdarzeń dla stworzenia tzw. Use Cases (przypadków użycia/scenariuszy bezpieczeństwa).  Przecież nie sposób jest włączyć logowanie dla wszystkich lub większości połączeń. Należy sobie również postawić pytanie,  czy wykorzystamy takie zdarzenia na etapie tworzenia przypadków użycia? Druga kwestia to ograniczenie w postaci licencji, która pozwala na przetwarzanie określonej ilości zdarzeń np. w ciągu doby.
Połączenia z systemów źródłowych do systemu SIEM i z powrotem, na potrzeby przekazania zdarzeń powinny być szyfrowane przy wykorzystaniu protokołów oraz algorytmów uznanych powszechnie za bezpieczne.
W warstwie transportowej zdarzenia powinny być przesyłane za pomocą protokołu TCP. Zapewni to wyższą niezawodność w transporcie logów do systemu SIEM, niż protokół UDP. Podejmując decyzję wysyłania logów za pomocą protokołu UDP (czytaj – mniejszy narzut ruchu sieciowego), akceptujemy większe ryzyko niedostarczenia pewnej ilości logów, chociażby z powodu krótkiej przerwy w działaniu sieci.
Dla systemów zlokalizowanych w strefach „mniej zaufanych”, np. DMZ, system SIEM powinien być tak skonfigurowany, aby zdarzenia z tych segmentów były pobierane z sieci LAN (czytaj z LAN do DMZ). Nigdy w odwrotną stronę, czyli ruch sieciowy z DMZ do LAN, ponieważ w ten sposób możemy sami ułatwić „ścieżkę” dostępu do systemów zlokalizowanych wewnątrz naszej sieci potencjalnemu atakującemu.
Należy stosować różne, dedykowane konta serwisowe na potrzeby pobierania zdarzeń, z poszczególnych typów systemów. Jeżeli jesteśmy zmuszeni zapisać poświadczenia w pliku w postaci niezaszyfrowanej, należy ograniczyć uprawnienia do niezbędnego minimum.
Przeanalizować logi pod kątem anonimizacji wybranych kategorii zdarzeń. Wiele systemów potrafi zanonimizować wybrane wartości pola w zdarzeniu. Jeżeli istnieje uzasadniona potrzeba „ukrycia” pewnych informacji w myśl zasady minimalizacji przetwarzanych informacji, system SIEM powinien być w ten sposób skonfigurowany. Przykładowymi informacjami, które mogłyby być poddane zanonimizowaniu będą: numery kart kredytowych, dane osobowe, hasła. Wszystko zależy od kontekstu przetwarzanych informacji i potrzeby utworzenia scenariuszy bezpieczeństwa.
Skonfigurować system SIEM w zakresie monitorowania systemów źródłowych pod kątem odbierania logów. Administratorzy systemu powinni być powiadamiani w sytuacji gdy system źródłowy przestał przesyłać zdarzenia.

Posiadając „podłączone” do SIEM-a (skonfigurowane do przekazywania logów) systemy infrastrukturalne oraz bezpieczeństwa, możemy rozpocząć konfigurację podłączeniową systemów aplikacyjnych. Oczywiście proces podłączenia systemu aplikacyjnego zależy od jego możliwości oraz zdolności jakie daje system SIEM.

Ważnym elementem jest rozmowa z osobą z ramienia właściciela systemu. To zazwyczaj użytkownik/administrator ma największą wiedzę w organizacji, zarówno od strony możliwości podłączeniowej aplikacji, ale również, co w systemie można nazwać normalnym zachowaniem, a co anomalią/zdarzeniem/incydentem. Na tej podstawie administrator systemu SIEM powinien wybrać optymalną metodę podłączenia systemu.

W kolejnej fazie wdrożenia, analityk we współpracy z administratorem i/lub użytkownikiem aplikacji powinni uzgodnić scenariusze bezpieczeństwa.

Kolejnym istotnym elementem naszych czynności powinno być upewnienie się, że systemy bezpieczeństwa służące do wykrywania incydentów (takie jak IPS/IDS, WAF) poddają inspekcji cały ruch sieciowy (czytaj – istnieje potrzeba deszyfracji ruchu) kierowany z/do aplikacji. Tylko w ten sposób możemy przekazać z systemów bezpieczeństwa do systemu SIEM, wszystkie informacje o wykrytych incydentach.

Na jakie elementy warto zwrócić uwagę podczas konfigurowania systemu SIEM?

               W początkowej fazie wdrożenia systemu warto wziąć pod uwagę kilka istotnych elementów, które powinny zostać przeanalizowane, następnie wykonane w systemie. Chodzi przede wszystkim o właściwą konfigurację, która zapewni odpowiednie działanie systemu, które przełożyć możemy na główne korzyści funkcjonowania naszego SIEM-a.

Integracja z innymi systemami

Poniższa lista systemów ma charakter przykładowy. Każda organizacja zależnie od potrzeb powinna przeanalizować to indywidualnie i podjąć właściwą decyzję w zakresie integracji. Spora część poniższych zaleceń może wydawać się oczywista. Jednak dosyć często można zauważyć, integrację z systemami z pominięciem pewnych czynności. To właśnie kompleksowe podejście zwiększa bezpieczeństwo naszego systemu/organizacji.

Dla wysyłania powiadomień, potrzebna jest integracja z systemem pocztowym. Do tego celu warto wykorzystać uwierzytelnianie dedykowanym użytkownikiem. Pamiętajmy aby nie pozostawić serwerów tzw. Open Relay (niezabezpieczony serwer przed nieautoryzowanym wykorzystaniem). Ważne jest, aby komunikacja z takim systemem była szyfrowana.
Do uwierzytelniania warto wykorzystać usługę katalogową (np. Active Directory), z zaimplementowanym szyfrowaniem komunikacji.
Synchronizacja czasu to podstawowy element działania każdego systemu, dlatego SIEM powinien być zintegrowany z serwerem czasu w każdej organizacji.
Zależnie od naszej polityki backupu może być konieczna integracja z systemem backupu. Zatem takie wymaganie może wiązać się z instalacją agenta na każdym z systemów operacyjnych naszego SIEM-a. Odnośnie instalacji na wirtualnych hostach, raczej nie powinniśmy mieć większych problemów, ale z instalacją na tzw. fizycznych appliance-ach powinniśmy być ostrożni. Taki „gotowy”, fizyczny appliance, posiada system operacyjny przygotowany przez producenta. Agent backupu może wymagać instalacji dodatkowych pakietów. Pamiętajmy, że podczas procesu aktualizacji SIEM-a, będziemy zmuszeni przeanalizować tą zależność, aby nie mieć problemów z przeprowadzeniem aktualizacji systemu. Może być potrzeba podmontowania dodatkowego repozytorium, z którego system będzie musiał pobrać nowsze wersje pakietów dla agenta backup. Inne rozwiązanie to odinstalowanie wcześniej zainstalowanych dodatkowych pakietów, aktualizacja systemu i finalnie zainstalowanie nowych pakietów agenta.
Posiadając system Help Desk, który pełni rolę systemu zgłoszeń/incydentów, warto wykonać integrację z systemem SIEM, który przekaże informacje w zakresie wystąpienia określonego incydentu. Niniejsza integracja pozwoli nam zautomatyzować pewną część procesu zarządzania incydentami (np. zgłoszenie będzie utworzone w trybie automatycznym oraz przydzielone właściwej grupie na 1. linii wsparcia).
Wiele organizacji integruje swoje SIEM-y z platformami, które dostarczają informacje na temat wskaźników włamań tzw. IOC (ang. Indicator of compromise). Systematycznie aktualizowane i pobierane przez system SIEM, są porównywane z wartościami tej samej kategorii, znajdujących się w zdarzeniach z systemów źródłowych. W ten sposób można znaleźć np. potwierdzenie komunikacji hosta z naszej sieci, który komunikował się z adresem sklasyfikowanym jako „niebezpieczny”.

Retencja przechowywanych zdarzeń bezpieczeństwa

Długość okresu przechowywania zdarzeń bezpieczeństwa powinien zależeć przede wszystkich od wymagań prawnych oraz do jakich zadań wykorzystujemy nasze logi. Wyjaśniając: możemy podzielić zdarzenia przetwarzane w systemie SIEM na co najmniej dwie kategorie (bieżące – to te które wyzwalają nam nowe incydenty, archiwalne – to zdarzenia, które wykorzystujemy do analizy, weryfikacji, potwierdzenia incydentów/zdarzeń, które wystąpiły jakiś czas temu). Jak się zapewne domyślacie, taki podział generuje nam konkretne wymagania, które powinniśmy uwzględnić.

Dla zdarzeń bieżących proponuję maksymalnie 1 miesiąc przechowywanych zdarzeń. Nic nie stoi na przeszkodzie aby było to również 14 dni. Tego typu logi powinny być przechowywane na szybszych dyskach (np. SSD), ze względu na potrzebę szybkiego dostępu do danych oraz jak najszybszą potrzebę przetwarzania danych, finalnie utworzenia właściwych incydentów. Przydzielając zasoby dyskowe, powinniśmy odpowiedzieć na kluczowe pytanie: W jakim okresie czasowym będziemy potrzebowali przeszukiwać tego typu zdarzenia według przyjętych kryteriów?
Dla zdarzeń archiwalnych zalecane są wolniejsze dyski, ponieważ nie potrzebujemy aż tak szybkiego dostępu do wyników wyszukiwania. Akceptujemy dłuższy okres oczekiwania na rezultaty przeszukiwania logów. Rozmiar przestrzeni powinniśmy określać przede wszystkim w oparciu o obowiązujące przepisy prawa. Bardzo często, wiele organizacji jest zobligowanych do przechowywania zdarzeń ze względu np. na potrzebę rozliczalności użytkowników lub potwierdzenia komunikacji z adresami zidentyfikowanymi jako niebezpieczne.
Spora część rozwiązań daje możliwość ustawienia retencji zależnie od rodzaju logów. Załóżmy, że zdarzenia z Firewall-i, z jakiegoś powodu musimy przechowywać 2 lata, a zdarzenia z systemów operacyjnych 1 rok.

Wykorzystanie najlepszych baz wiedzy na potrzeby stworzenia scenariuszy bezpieczeństwa

Aktualnie znaną i polecaną bazą wiedzy w tym zakresie jest MITRE ATT&CK (https://attack.mitre.org/), która bazuje na najlepszej wiedzy i doświadczeniu ekspertów bezpieczeństwa. Podstawą wyżej wymienionego framework-u są tzw. taktyki oraz techniki. Zależnie od stosowanej technologii mamy możliwość szybkiego zapoznania się z atakami oraz zaleceniami ochrony przed nimi. W odniesieniu do szczegółowych informacji publikowanych w MITRE ATTA&CK, można utworzyć bardzo dużo scenariuszy, które znacząco podniosą dojrzałość organizacji w zakresie wykrywania incydentów bezpieczeństwa.

Minimalizacja uprawnień

Bardzo często pomijany element całej układanki.  Powinniśmy zadbać o to, aby system albo usługa były uruchamiane i pracowały z uprawnieniami, które wystarczą do prawidłowej pracy. W tym przypadku powinniśmy kierować się zasadą minimalizacji. Jeśli producent wspiera taką konfigurację, to tak należy zrobić, czyli uruchamiać usługi z uprawnieniami dedykowanego użytkownika (nieposiadającego uprawnień administracyjnych). Nie konfigurujmy/uruchamiajmy usług naszego systemu z wykorzystaniem użytkowników typu root/Administrator. W przypadku ataku, wykorzystanie błędu w takiej usłudze o wiele bardziej narazi system na włamanie. Oczywiście tę czynność zazwyczaj wykonujemy na etapie instalacji lub początkowej konfiguracji. Możemy jednak to zrobić, nawet gdy „zastaliśmy” w taki sposób skonfigurowany system.

Lokalny Firewall

Po pierwsze, nie wyłączaj lokalnego Firewall-a! Dodawaj reguły tylko dla skonfigurowanych usług na potrzeby prawidłowej pracy systemu. Filtracja ruchu przez lokalny firewall to również ważna kwestia bezpieczeństwa systemu. Nie zapominajmy o tym. W pewnych okolicznościach może się okazać, że to była ostatnia deska ratunku.

Podsumowanie

               Temat monitorowania usługi biznesowej to dosyć złożony proces. W mojej ocenie najważniejsze elementy tego procesu to podłączenie właściwych systemów oraz integracja z właściwymi elementami infrastruktury organizacji. Tylko kompleksowe podejście do tematu zapewni nam odpowiedni poziom monitorowania usługi biznesowej za pomocą systemu SIEM. Z punktu widzenia zespołów bezpieczeństwa tego typu system, jest głównym narzędziem w codziennej pracy. Mając zdarzenia bezpieczeństwa w jednym systemie, zespoły wszystkich linii wsparcia mogą czerpać z niego wiele korzyści.

Wychodząc naprzeciw oczekiwaniom naszych Klientów, świadczymy wsparcie na każdym etapie wdrożenia systemów SIEM. Rozpoczynając od planowania samego wdrożenia, kończąc na implementacji scenariuszy bezpieczeństwa oraz integracji z systemami typu SOAR, aby zautomatyzować pewne procesy dla całej organizacji.

Reagowanie na incydenty bezpieczeństwa, czyli jak wdrożyć systemy klasy SIEM i SOAR?
W dzisiejszych czasach każda organizacja mierzy się z wyzwaniem zapewnienia bezpieczeństwa informacji, przede wszystkim w zakresie poufności, dostępności oraz integralności danych i systemów, które zapewniają możliwość świadczenia usług biznesowych, czy też kluczowych. Co więcej część organizacji jest zobligowana do przestrzegania regulacji i zaleceń wynikających z rodzaju świadczonych usług np. wytyczne Komisji Nadzoru Finansowego dla spółek finansowych oraz ustawy o krajowym systemie cyberbezpieczeństwa dla operatorów usług kluczowych.
Każda z wymieniowych wcześniej regulacji, zakłada konieczność monitorowania i raportowania incydentów bezpieczeństwa. Dla organizacji, których regulacje nie dotyczą, monitorowanie incydentów jest równie ważne m.in. z uwagi na możliwość świadczenia usług biznesowych czy też utrzymania wysokiego poziomu zadowolenia i zaufania klientów.
Zbudowanie procesu monitorowania i reagowania na incydenty bezpieczeństwa jest zagadnieniem złożonym, do którego należy się odpowiednio przygotować i realizować krok po kroku. Niestety nie ma złotego środka w postaci rozwiązania technologicznego, które pozwoli na kompleksowe uruchomienie procesu.
Należy również pamiętać, że cały proces to nie tylko technologia, ale również kwestie organizacyjne np. polityka i procedury bezpieczeństwa, jak również ludzie, czyli odpowiednio zwymiarowany zespół, składających się ze specjalistów i ekspertów o odpowiednich kompetencjach. W opracowaniu skupię się przede wszystkim na rozwiązaniach technologicznych.
W ramach przygotowania do wdrożenia procesu można posiłkować się modelem dojrzałości monitorowania i reagowania na incydenty bezpieczeństwa.

 
Jak przygotować się do wdrożenia procesu w oparciu o technologię?
Pierwszym krokiem przygotowania się do wdrożenia procesu monitorowania i reagowania na incydenty bezpieczeństwa w kontekście technologicznym jest analiza środowiska IT w zakresie:

Wykorzystywanych rozwiązań bezpieczeństwa
Usług podstawowych np. serwer poczty
Systemów świadczących najważniejsze usługi biznesowe
Systemów wspierających

Idealna sytuacja, która jednak wymaga znaczącego nakładu pracy, to inwentaryzacja wszystkich zasobów IT w organizacji, co pozwala na przygotowanie się do pierwszego etapu, czyli wdrożenia rozwiązania zapewniającego widoczność zdarzeń bezpieczeństwa.
Na podstawie przeprowadzonych analiz możemy wyspecyfikować nie tylko obszary, które powinniśmy i możemy objąć monitorowaniem, ale również obszary, w których występują braki technologiczne czy funkcjonalne, które należy uzupełnić.
Analiza stanu obecnego infrastruktury oraz rozwiązań bezpieczeństwa pozwoli na opracowanie docelowych funkcjonalności rozwiązań log management, SIEM i SOAR, które będą możliwe do implementacji. Przykładowo brak rozwiązania klasy EDR uniemożliwi wykrywanie zdarzeń dotyczących uruchamiania podejrzanych plików czy procesów na stacjach roboczych.
Widoczność zdarzeń bezpieczeństwa
Widoczność zdarzeń bezpieczeństwa jest kluczowym elementem całego procesu. Nie można w efektywny sposób wdrożyć procesu, jeśli nie mamy odpowiedniej widoczności tego, co dzieje się w naszej infrastrukturze.
Jako pierwszy element modelu powinien zostać wdrożony system klasy zarządzania zdarzeniami (log management). Technologia będzie pobierać lub odbierać zdarzenia z monitorowanych systemów (źródeł danych) i przechowywać je przez określony czas, dając możliwość analizy zdarzeń, jak również wykonywania szczegółowych analiz czy raportowania na potrzeby zgodności.
Analizując rozwiązania dostępne na rynku warto rozważyć Producentów, którzy dostarczają zarówno rozwiązania log management jak i rozwiązania SIEM. Zapewnienie homogenicznych rozwiązań od jednego Producenta, w przyszłości może zaoszczędzić czas niezbędny do wdrożenia kolejnych rozwiązań technologicznych, w kolejnych krokach modelu dojrzałości. Dotyczy to przede wszystkim sposobu normalizacji zdarzeń, który jest odmienny dla różnych systemów log management i SIEM.
Podczas wyboru rozwiązania należy zwrócić uwagę w szczególności na:

Stopień kompresji zdarzeń przy ich długoterminowym przechowywaniu.
Funkcjonalność konfiguracji różnych okresów przechowywania zdarzeń dla poszczególnych rodzajów systemów/zdarzeń.
Stopnień skomplikowania funkcjonalności podłączania źródeł logów.
Stopień skomplikowania przygotowywania dedykowanych reguł normalizujących zdarzenia.
Sposób przekazywania zdarzeń do zewnętrznych systemów SIEM oraz SOAR.

Na podstawie zdarzeń zebranych w systemach zarządzania logami można wykonać analizę tego, co dzieje się w naszej infrastrukturze, a przede wszystkim potwierdzić możliwość realizacji docelowych funkcjonalności SIEM i SOAR w ramach rozwoju modelu dojrzałości.
Z dobrych praktyk wynika, że z modułu zarządzania logami do modułu SIEM powinno trafiać maksymalnie 50%, a zwykle ok. 30% zebranych zdarzeń, które będą wykorzystane dalej do monitorowania incydentów bezpieczeństwa w czasie zbliżonym do rzeczywistego. Z tego wynika, że wdrożenie odrębnego modułu zarządzania logami oraz odrębnego modułu SIEM pozwoli na znaczne zoptymalizowanie budżetu niezbędnego na licencje oraz zasoby sprzętowe czy też wirtualne. Należy mieć na uwadze, że koszt modułu zarządzania logami jest znacznie niższy niż koszt wdrożenia systemów SIEM.
Monitorowanie reaktywne incydentów bezpieczeństwa
Na potrzeby przejścia do kolejnego punktu modelu dojrzałości niezbędne jest wdrożenie systemu klasy SIEM w podstawowej funkcjonalności. Zakres wdrożenia jak również funkcjonalności analityczne, które będą implementowane w ramach etapu, mamy już określone w poprzednim etapie, dzięki wykonanej analizie zarówno infrastruktury, jak i zdarzeń bezpieczeństwa.
Monitorowanie reaktywne z wykorzystaniem systemu klasy SIEM polega na reagowaniu na incydenty bezpieczeństwa w momencie ich wykrycia przez silnik korelacyjny. Jednak jest to monitorowanie post factum i w obecnym etapie polega na wykonywaniu analiz już zaistniałych incydentów bezpieczeństwa.
Etap dotyczy nie tylko wdrożenia samej technologii, ale również edukacji zespołów w ramach wdrożonego rozwiązania. Poznawanie funkcjonalności i zasady działania pozwala użytkownikom na znalezienie dodatkowych sposobów wykorzystania systemu. Co więcej budowanie kompetencji operatorów, analityków i osób odpowiedzialnych za bezpieczeństwo organizacji pozwala na rozpoczęcie procesu monitorowania incydentów bezpieczeństwa. Osoby odpowiedzialne za proces mają okazję poznać specyfikę incydentów, a co za tym idzie konkretnych zagrożeń i ataków, z którymi boryka się organizacja.
Monitorowanie proaktywne incydentów bezpieczeństwa
Monitorowanie proaktywne z wykorzystaniem systemu SIEM to przesunięcie ciężaru działania z wykrywania zaistniałych incydentów bezpieczeństwa na monitorowanie potencjalnie niestandardowego i groźnego zachowania infrastruktury IT.
Z pomocą przychodzi szereg funkcjonalności udostępnionych przez producentów poszczególnych rozwiązań SIEM np.:

Integracja rozwiązań z feedami IoC, IoA oraz Threat Intelligence.
Badanie zachowania użytkowników wewnętrznych i zewnętrznych z wykorzystaniem modułów klasy user behavior analytics.
Moduły wykorzystujące machine learning i artificial intelligence do badania anomalii w infrastrukturze.

Wspomniane funkcjonalności w znakomity sposób zwiększają widoczność zdarzeń bezpieczeństwa w organizacji w bardzo szerokim zakresie. Monitorowanie proaktywne wykorzystuje przede wszystkim dynamiczne elementy i funkcjonalności, a nie bazuje już tylko na zebranych zdarzeniach i ich statycznej analizie.
Większość systemów SIEM posiada wbudowany moduł do obsługi incydentów bezpieczeństwa. Zazwyczaj działa on świetnie w obrębie danego systemu jednak posiada ograniczenia w możliwości integracji z innymi systemami, zarówno na potrzeby wykonania akcji, jak i procesowania incydentów w systemach zewnętrznych. Incydenty mogą być wzbogacane o dodatkowe informacje pochodzące ze zdarzeń ze źródeł danych, które są podłączone do SIEM. Wykonanie akcji np. blokowanie użytkownika, jest teoretycznie możliwe, ale wymaga prac developerskich. Sytuacja wygląda podobnie jeśli chodzi o możliwość współpracy pracowników zespołów bezpieczeństwa. Każdy członek zespołu musi mieć skonfigurowane odpowiednie uprawnienia w głównej konsoli systemu SIEM.
Automatyzacja
Ostatnim etapem dojrzałości modelu monitorowania i reagowania na incydenty bezpieczeństwa jest wdrożenie systemu klasy Security Orchestration Automation and Response. Systemy SOAR to uniwersalne platformy, które zapewniają jeden punkt wspólny pracy dla zespołów cyberbezpieczeństwa przy obsłudze incydentów bezpieczeństwa.
Najważniejszą zaletą systemów SOAR jest możliwość automatyzacji częściowej lub całościowej procesu obsługi incydentu bezpieczeństwa w ramach tzw. Playbooka czyli przepływów procesu. W znaczący sposób wpływa to na wzrost efektywności procesu, co skutkuje znaczącym spadkiem kosztów obsługi procesu
Docelowo system klasy SOAR powinien być wdrożony na bazie funkcjonalności, które zostały określone w poprzednich etapach modelu i rozwijać je do wysokiego poziomu dojrzałości. Przy procesie specyfikacji wspomnianych funkcjonalności należy wziąć pod uwagę następujące kwestie:

Jakie mogą być źródła informacji o danym incydencie. Jaki system oprócz SIEM może wzbogacić analizowany incydent?
Jakie integracje z zewnętrznymi systemami powinny zostać wykorzystane?
Czy system SOAR ma wykonywać akcje na innych systemach np. automatyczne blokowanie użytkownika?

Dojrzały model monitorowania i reagowania na incydenty bezpieczeństwa nie będzie oczywiście opierał się jedynie na rozwiązaniu SIEM. Tak naprawdę źródłem incydentu może być dowolny system np. EDR, czy też system backupowy. Podobnie akcją SOAR-a nie musi być tylko akcja związana z cyberbezpieczeństwem.
Dla lepszego zobrazowania podejścia do wykorzystania systemu SOAR w organizacji w bogatym zakresie, który wykorzysta wzbogacanie incydentów i wykonywanie akcji, przedstawię przykładowe playbooki: 1. 
1. Wielokrotne nieudane logowania

Zdarzenie ze SIEM uruchamia playbook.
Z Active Directory pobierane są informacje o użytkowniku – wzbogacanie incydentu.
Playbook automatycznie wysyła do użytkownika wiadomość e-mail z pytaniem, czy jest świadom zaistniałego zdarzenia i czy potwierdza ten fakt.
Jeśli użytkownik potwierdzi fakt, playbook zostaje zamknięty.
Jeśli użytkownik nie potwierdzi faktu konto użytkownika jest blokowane w Active Directory i powiadamiany jest przełożony pracownika, za pomocą wiadomości e-mail.
Priorytet incydentu jest ustawiany na wysoki.

2. Zarządzanie kontem pracownika na wypowiedzeniu

System SOAR otrzymuje informację z systemu kadrowego o pracowniku, który kończy współpracę z firmą w konkretnym terminie. Uruchamiany jest playbook, który ustawia harmonogram uruchomienia kolejnego playbooka na podstawie terminu przesłanego przez system kadrowy.
W podanym terminie uruchamiany jest playbook, który wykonuje akcje w postaci blokowania użytkownika w Active Directory, innych usługach, do których pracownik miał dostęp oraz blokuje kartę pracownika, za pomocą której wchodził on do firmy.

Przygotowane w poprzednich etapach funkcjonalności, szczególnie w etapie monitorowania proaktywnego, dobrze jest zaimplementować w SOAR, dodając procedury automatyzujące częściowo lub całościowo ich obsługę.
Efektem dojrzałego procesu monitorowania i reagowania na incydenty bezpieczeństwa jest kompleksowo wdrożony system zarządzania logami, wykrywania podejrzanych zdarzeń i anomalii, jak również system obsługi incydentów. Punktem obsługi incydentów i pracy użytkowników będzie konsola systemu SOAR, jako najwyższa warstwa procesu.
Co dalej?
Trzeba mieć na uwadze, że osiągnięcie dojrzałości procesu monitorowania i reagowania na incydenty bezpieczeństwa nie sprawia, że organizacja jest w 100% zdolna do przeciwdziałania wszystkim zagrożeniom. W sieci praktycznie codziennie pojawiają się nowe zagrożenia i ataki, często zero-day lub APT, co wymusza ciągłe doskonalenie procesu. Dlatego ważne jest, aby w sposób cykliczny przeglądać proces i dostosowywać go do obecnych warunków.
Podsumowanie
Zastosowanie modelu dojrzałości procesu monitorowania i reagowania na incydenty bezpieczeństwa ma wiele zalet. Przede wszystkim umożliwia przygotowanie roadmapy, na podstawie której proces będzie wdrażany od początku lub od momentu, w którym znajduje się obecnie w organizacji. Model daje możliwość zaplanowania nie tylko działań, ale też docelowej funkcjonalności inicjalnej, bazującej na wykonanej w fazie przygotowawczej analizie. Jest to niezwykle ważne, gdyż pozwala na określenie kryteriów sukcesu dla każdego etapu.
Wykorzystanie etapów modelu pozwala na zwiększenie efektywności budowania całego procesu, co w efekcie przekłada się na oszczędność czasu podczas wdrożeń. Podział modelu na poszczególne fazy sprzyja również rozwojowi pracowników, którzy sukcesywnie nabywają wiedzę i kompetencje, wraz z rozwojem procesu.
 
Jesteś zainteresowany naszym wsparciem w obszarze Cyber Security? Napisz do nas, wypełniając formularz kontaktowy poniżej.