Wprowadzenie
W przerwach w polowaniu na infrastrukturę niebezpiecznych grup jak Lazarus, tudzież analizy ruchu sieciowego wygenerowanego przez narzędzia typu RAT lub wiper, zastanawiamy się jak wyniki naszej pracy mogą zostać wykorzystane.
Prawdopodobnie spora część czytających ten artykuł dojdzie do wniosku, że do konsumpcji wskaźników kompromitacji (IOC), rozszerzonych o artefakty sieciowe, użyty zostanie lub powinien zostać użyty SIEM. Ewentualnie inny system bezpieczeństwa, który potrafi konsumować takie informacje.
Rozmawiamy z różnymi partnerami, klientami oraz osobami z naszej branży na temat sposobów wdrożenia oraz używania systemów typu SIEM. Poniżej kilka wybranych przykładów jak można "zabić" taki system oraz jak sprawić by znów chciało się do niego zaglądać.
Podczas wyborów lub wdrożeń systemów typu SIEM, dość często przechodzi się przez kilka jego faz.
Fazy wyboru i wdrożenia SIEM
Dla wyboru rozwiązania:
- ekscytacji - "wszystko wrzucimy do SIEMa!"
- zdziwienia - "jak to tyle kosztuje dla wszystkich zdarzeń?!"
- racjonalizacji - "ok, potrzebujemy licencje na 50% wszystkich zdarzeń"
- poddenerwowania - "wydaliśmy tyle pieniędzy, SIEM musi robić wszystko, trzeba udowodnić business case!"
Dla wdrożenia systemu:
- ekscytacji - "wow, logujemy się do uruchomionego systemu! zobacz jakie raporty na zarząd będą i to z naszym logo!"
- zdziwienia - "erm, szybciej wyszukiwałem zdarzeń grep'em, a to dopiero 10 źródeł podpiętych do SIEMa"
- racjonalizacji - "ok, nieważne, trzeba dowieźć business case"
- poddenerwowania - "dlaczego parsery nie rozpoznają tych zdarzeń poprawnie (wszystkie ich pola), przecież mają dedykowany parser!"
Brzmi znajomo?
Po przejściu przez te fazy, zazwyczaj mamy wyskalowany i wdrożony SIEM, który zasilany jest częścią zdarzeń docelowo istotnych, parsery rzadko radzą sobie z nowszymi wersjami zasilających je źródeł zdarzeń, nie mówiąc o sytuacji, w której źródła zdarzeń mają format i zawartość zdarzeń zgoła inny niż DOMYŚLNY.
Aby zmiękczyć skalę trudności obcowania z systemem typu SIEM po wdrożeniu i business case szybko został zrealizowany potrzeba sporo pracy kosztującej dużo wysiłku przed rozpoczęciem wdrożenia, na zdefiniowanie oczekiwań (tzw. mierzalne produkty), ale także przygotowanie możliwie dokładnych założeń związanych z tym, czym będziemy system SIEM "karmić".
Każdy może to zrobić sam lub np. z naszą pomocą (zapraszam na kontakt {@} whitecatsec {.} com) - pracujemy z różnymi systemami SIEM od 2008 roku.
Wg relacji osób, z którymi rozmawiamy taki nieco "otyły" i nie spełniający oczekiwań SIEM staje się czasem dowodem na to, że firma posiada SIEM i daje zgodność z np. rekomendacjami, regulacjami lub czymkolwiek innym mogącym dać "spokój".
Nie musi tak być. Jeśli chcesz by Twój SIEM był nieco bardziej fit, czytaj dalej.
Dane:
Żeby właściwie przygotować źródła zdarzeń zasilające SIEM trzeba je odpowiednio skonfigurować.
Odpowiednia konfiguracja w kontekście danych to wybranie właściwych kolumn/pól oraz ich format, które mają się znaleźć w zdarzeniu przesłanym do systemu SIEM.
Co to są te mityczne "właściwe kolumny/pola"?
Właściwe to te, które będą:
- używane w SIEMie do wyszukiwania lub przetwarzania
- używane przez osoby pracujące w SIEM do wyjaśniania zdarzeń (np. alarmów), takie które mogą nadać/dodać kontekst i ułatwić pracę analityka
Jeśli któreś z możliwych do osadzenia kolumn/pól w źródle zdarzeń spełnia powyższe wymagania, rekomenduję je włączyć i poprawnie parsować przez SIEM.
Czy trzeba to zrobić dla wszystkich źródeł zdarzeń podpiętych do SIEM?
Krótka odpowiedź: Nie.
Dłuższa: Najpierw zrób to dla najważniejszych dla Ciebie źródeł zdarzeń (o nich poniżej), a następnie lub równolegle zajmij się resztą. Dlaczego reszta może mieć znaczenie skoro nie są "najważniejsze"? Otóż mogą one stanowić dużą ilość lub wielkość zdarzeń przez co w przypadku komercyjnych systemów SIEM zjadają Ci:
- licencję
- łącza
- wolną przestrzeń dyskową wpływając na retencję
- wydajność źródeł oraz SIEM
a tym samym prawdopodobnie czas Twoich analityków, bo dłużej czekają na rezultaty pracy w SIEM.
Dlatego nie trzymaj "darmozjadów" (zbędnych kolumn w zdarzeniach) i odchudź swój SIEM.
Które źródła zdarzeń są prawdopodobnie najważniejsze? Wg nas te, które biorą udział w realizacji tzw. scenariuszy.
Scenariusze dzielimy na takie, które
wymagają reakcji człowieka:
- alarmy (reguły korelacyjne, wyszukiwania zdarzeń, itp.)
- raporty (zbiory zdarzeń z okresu czasu, agregacje, itp.)
- dashboardy (te, z alarmami i raportami, które mogą zostać przeoczone jak wpadną np. na skrzynkę e-mailową, nie rekomendujemy tutaj dashboardów, które nie wymagają reakcji człowieka i stałej ich obserwacji)
nie wymagają reakcji
- wzbogacające (nadające lub zwiększające kontekst dla alarmów i raportów)
Podsumowanie
Oto mamy cały łańcuch przyczynowo-skutkowy, jak poprawić kondycję narzędzia typu SIEM.
W dietetyce mówi się, że jeśli nowe ferrari zalejesz słabej jakości paliwem, nie dziw się, że "słabo" jeździ. To samo powiedzenie świetnie nadaje się do rozwiązań typu SIEM.
Na dietetyce też sie trochę znamy (potwierdzone certyfikatami!) natomiast w White Cat Security wspieramy klientów tworząc założenia przed wdrożeniem i po wdrożeniu, pomagając dojść do nich, w tym także budując procesy i procedury pracy ze SIEM, aby nie przerosły one możliwości ludzkich osób z nim pracujących.
W przypadku zainteresowania zapraszamy do kontaktu (kontakt {@} whitecatsec {.} com)
