Jednym z absolutnie kluczowych elementów w całym procesie reagowania na incydenty jest oczywiście faza detekcji, czyli zyskiwania świadomości, że “coś” podejrzanego i potencjalnie złośliwego dla naszej organizacji się dzieje.

Uwaga od autora: W trakcie swojej działalności w obszarze cyberbezpieczeństwa, wielokrotnie spotkałem się z podejściem, że wystarczy mieć odpowiednie narzędzia monitoringu, dopasowane pokrycie zasobów tymi narzędziami i to powinno wystarczyć. Niestety, nie jest to właściwe podejście, bowiem to, co jest najistotniejsze to, to co zrobimy ze zdobytą wiedzą, którą dostarczać powinny nam narzędzia.

Aby móc pójść dalej, należy wskazać podstawowe terminy i systemy, które odpowiadają za monitoring, reagowanie oraz korelowanie zdarzeń.

Security and Information Event Management (w skrócie SIEM)

SIEM to rodzaj oprogramowania, które za zadanie ma monitorowanie zasobów, zbieranie z nich logów, szukanie korelacji między nimi oraz, w razie wykrycia niebezpieczeństwa, reagować na podejrzaną działalność.

Jak widać na powyższym rysunku, SIEM posiada kilka bardzo istotnych funkcji takich jak: agregowanie informacji, korelacja, powiadamianie.

Poniżej omówimy te wyszczególnione:

Agregowanie informacji:
Funkcja ta odpowiada za zbieranie informacji z urządzeń, które są “wpięte” do SIEM. Wracając do rysunku poglądowego jako przykładu, informacje byłyby zbierane z Databases, IoT, Firewalls, Endpoints, Applications oraz Printers. W jakim celu się agreguje informacje? Aby mieć je w jednym, centralnym miejscu, celem dalszej analizy.

Korelacja:
Jest to niezwykle istotna funkcja, ponieważ odpowiedzialna jest za szukanie relacji pomiędzy zgromadzonymi zdarzeniami.
Przykład: Przeanalizujmy następujący scenariusz (który był prezentowany na jednym z webinarów o atakach na aplikacje webowe).

Jak widzimy, w tym przypadku mamy do czynienia z wykorzystaniem podatności w aplikacji www, natomiast finalnie złośliwy plik webshell.php wyląduje na serwerze, czyli pod określoną ścieżką na systemie operacyjnym tegoż serwera.

Aby móc zareagować na taki incydent, potrzebowalibyśmy, aby przynajmniej zaatakowana aplikacja oraz serwer, który ją hostuje, były wpięte do SIEM. Wówczas SIEM byłby w stanie zobaczyć, jaka była ścieżka “wędrówki” podejrzanego pliku webshell.php.

Powiadamianie:
Niezależnie od tego czy nasz SIEM wyposażony jest również w mechanizmy przeciwdziałania incydentom czy też nie, powinien on powiadamiać zdefiniowane osoby, które powinny mieć świadomość zagrożenia.

Spodziewajcie się kolejnej części artykułu o procesie obsługi incycentów. W następnym wpisie skupimy się na rozwiązaniach z rodziny SOAR (Security Orchestration, Automation and Response).