Jak powinien być skonstruowany poprawny alert bezpieczeństwa?

Oczywiście alert powinien być przejrzysty dla zespołu SOC, ale też umożliwiający poprawne wykrycie każdego zagrożenia. Wyzwaniem jest to, że te dwa cele mają tendencję przeszkadzania sobie nawzajem. Inżynier SIEM może pisać scenariusze przez cały dzień, by wykryć każdy możliwy wskaźnik złośliwej aktywności. Rezultatem będzie jednak nierealna liczba zdarzeń wymagająca większego wysiłku niż dostępna przepustowość operatorów i analityków SOC. Jednocześnie niedostateczne wykrywanie powierzchni ataku zwiększy ryzyko zdarzeń false positive i udanych naruszeń.

Jak to zrównoważyć?

Po pierwsze trzeba opracować wykrycia o wysokiej wierności, które skutecznie oddzielą zwykłą aktywność od złośliwej. Łatwiej powiedzieć niż zrobić, ale jest to podstawowa odpowiedzialność inżyniera SIEM. Złe wykonanie tego zadania nadmiernie obciąży zespoły SOC, zniechęci analityków i doprowadzi do zmęczenia i osłabienia czujności.

Po drugie należy podać jak najwięcej szczegółów w informacjach śledczych. Oczywiście będzie to ograniczone do dostępnego rejestrowania zdarzeń, ale warto przeprowadzić dodatkowe wzbogacenie alertów, aby dodać kontekst z innych źródeł lub baz danych reputacji. Ręczne pivoty powinny być ograniczane do minimum.

Jakie szczegóły powinniśmy uwzględnić w scenariuszu wykrywania? Poniżej postaramy się to wyjaśnić.

Kontekst wykrytego zagrożenia

Na początku warto wiedzieć, jaki jest cel i geneza wykrytego zagrożenia oraz dlaczego w ogóle uważamy je za istotne.

Warto zwrócić uwagę na takie aspekty jak:

• Cel wykrycia
• Powiązane techniki MITRE
• Powiązane raporty Threat Intelligence
• Powiązane operacje Red Team
• Powiązane incydenty
• Czy alert był skuteczny w przeszłości?
• Czy przetestowano/sprawdzono go pod kątem true positive lub symulacji ataku?
• Czy jego konfiguracja przechodziła okresowe modyfikacje w celu utrzymania skuteczności?

Kontekst alertu bezpieczeństwa

Dalej musimy sobie odpowiedzieć na pytanie, jakie są szczegóły zdarzenia/zdarzeń, które miały miejsce i mogą wskazywać na złośliwą aktywność?

• Wszystkie pola dostępne w logach, które logika wykrywania ocenia, powinny zostać uwzględnione, chyba że nie dostarczają żadnego przydatnego kontekstu.
• Pola, które odpowiadają na pytania: Kto?, Co?, Gdzie?, Kiedy?, Jak?.
• Wszystkie pola powinny zostać znormalizowane zgodnie ze spójnym modelem danych.

Wzbogacenia

Czyli co wiemy o zaangażowanych zasobach/użytkownikach/miejscach docelowych?

• Niedawne powiązane alerty
• Szczegóły dotyczące dotkniętego użytkownika (np. z Active Directory)
• Szczegóły dotyczące dotkniętego zasobu (np. z CMDB)
• Reputacja publicznych adresów IP
• Reputacja domen/adresów URL
• Reputacja skrótów plików

Kontekst odpowiedzi

Jakie są oczekiwane działania, które analityk powinien podjąć w celu przeprowadzenia triażu?

• Runbook/Playbook/SOP
• Dodatkowe zapytania śledcze
• Przykłady True Positive
• Przykłady False Positive
• Działania naprawcze / postincydentalne

Jeśli powyższych szczegółów nie można uwzględnić w oryginalnym alercie, gdy pojawi się po raz pierwszy, należy je dodać tak szybko, jak to możliwe, za pomocą automatyzacji. Jeżeli istnieją ograniczenia techniczne uniemożliwiające takie działanie, to zasoby i wszelkie odpowiadające im zapytania w celu ręcznego pobrania tych informacji powinny zostać dostarczone w kontekście odpowiedzi, np. w tabelach, plikach CSV.

Dobrą zasadą jest, że jeśli pewne dane są wymagane do ustalenia, czy działanie jest złośliwe czy łagodne, dane te muszą zostać dostarczone lub łatwo dostępne dla analityka. Pamiętajmy, że analitycy są najskuteczniejsi, gdy mogą przeczytać historyczne zdarzenia. Dajmy im niezbędny do tego kontekst.