Zagrożenia i incydenty

Z jakimi zagrożeniami lub incydentami mieliśmy do czynienia w tym cyklu?

Opanowaliśmy kampanię phishingową wymierzoną w dział finansów w ciągu 30 minut od pierwszego zgłoszenia.
Źle skonfigurowany bucket S3 ujawnił wewnętrzne logi, ale dane klientów nie zostały naruszone.
W weekend nasza bramka VPN dostała kilka prób logowania metodą brute force.
Zabezpieczenia i sukcesy

Które zabezpieczenia, narzędzia lub procesy dobrze zadziałały?

Reguły korelacji w SIEM wcześnie wychwyciły próbę ruchu bocznego.
Dzięki dokumentowi przekazania dyżuru eskalacja o 2 w nocy przebiegła sprawnie i szybko.
Automatyczna izolacja w EDR oszczędziła nam wielu godzin ręcznej pracy.
Luki i podatności

Gdzie mieliśmy martwe pola lub słabe punkty?

Nie mieliśmy żadnego wglądu w zewnętrzną aplikację SaaS, która została przejęta.
Przez zmęczenie alertami prawdziwy sygnał przez dwie godziny czekał bez reakcji.
Nasz cykl łatania jest zbyt wolny przy krytycznych CVE.
Działania i hardening

Co zrobimy, aby poprawić nasz poziom bezpieczeństwa?

Dostroić reguły SIEM, żeby do następnego przeglądu ograniczyć fałszywe alarmy o 25%.
Objąć zewnętrzną aplikację SaaS ciągłym monitoringiem.
W tym sprincie przygotować i przetestować playbook na przejęcie konta w chmurze.

Czym jest retrospektywa Cyber Security Ops?

Retrospektywa Cyber Security Ops pozwala zespołowi operacji bezpieczeństwa wspólnie spojrzeć na ostatni cykl: co wykryliście, jak zareagowaliście i jak przywróciliście normalne działanie. Jest przeznaczona dla analityków SOC, osób reagujących na incydenty, threat hunterów i inżynierów bezpieczeństwa, którzy chcą, żeby wnioski z alertów, incydentów i niedoszłych incydentów przekładały się na konkretne poprawki. Tablica ma cztery kolumny. W kolumnie Zagrożenia i incydenty opisujecie, co się wydarzyło. Zabezpieczenia i sukcesy to narzędzia i procesy, które zadziałały. Luki i podatności obejmują martwe pola i słabe punkty, które wyszły na jaw. W kolumnie Działania i hardening ustalacie, co zmienić, i każdemu punktowi przypisujecie właściciela. Jeśli korzystacie już z MITRE ATT&CK lub NIST CSF, mapujcie na nie ustalenia, żeby śledzić postępy z cyklu na cykl. Nie szukajcie winnych. Ludzie opowiedzą o przeoczonym alercie albo o niedoszłym incydencie, który sami spowodowali, tylko wtedy, gdy wiedzą, że rozmowa dotyczy systemów i procesów. Przeprowadzajcie tę retrospektywę po poważnym incydencie, na koniec rotacji dyżurów lub regularnie, a zanim dodacie nowe działania, sprawdźcie te z poprzedniego cyklu.

Format retrospektywy Cyber Security Ops

Zagrożenia i incydenty

Z jakimi zagrożeniami lub incydentami mieliśmy do czynienia w tym cyklu?

Wypiszcie alerty, zdarzenia i incydenty, którymi zespół zajmował się w tym okresie. Poproś uczestników, żeby trzymali się faktów: co się stało, kiedy i na co miało wpływ, bez przypisywania winy. Dzięki temu wszyscy mają te same informacje, zanim zaczniecie rozmawiać o tym, co zadziałało.

Zabezpieczenia i sukcesy

Które zabezpieczenia, narzędzia lub procesy dobrze zadziałały?

Wymieńcie zabezpieczenia, automatyzacje i przekazania, które was ochroniły, i mówcie konkretnie, które narzędzie lub proces wykonał robotę. W zespole bezpieczeństwa łatwo pominąć sukcesy, a ich zapisanie pokazuje, co warto robić dalej.

Luki i podatności

Gdzie mieliśmy martwe pola lub słabe punkty?

Tu wychodzą na jaw luki w wykrywaniu, ograniczenia narzędzi, tarcia w procesach i niezałatane ryzyka. Pilnuj, żeby nikogo nie obwiniać, wtedy ludzie poruszą też niewygodne tematy. To, co tu trafi, zwykle stanowi większość planu działań.

Działania i hardening

Co zrobimy, aby poprawić nasz poziom bezpieczeństwa?

Zamieńcie luki w działania z właścicielem i terminem. Ustalcie priorytety według prawdopodobieństwa i wpływu, a każde działanie powiążcie z luką, którą zamyka, żeby następnym razem sprawdzić postępy.

Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego

  • Po poważnym incydencie bezpieczeństwa lub naruszeniu, aby zebrać wnioski bez szukania winnych.
  • Na koniec rotacji dyżurów lub zmiany w SOC, aby przejrzeć alerty i przekazania.
  • Co miesiąc lub co kwartał, aby śledzić powtarzające się luki i sprawdzać, czy poprawki z poprzedniego cyklu się sprawdziły.
  • Po ćwiczeniu tabletop, działaniach red teamu lub teście penetracyjnym, aby ustalić, co wyniki oznaczają dla zespołu.
  • Gdy wdrożyliście nowe narzędzia lub praktyki SecOps i chcecie sprawdzić, czy działają.

Proponowane pytania lodołamacze

  • Gdyby przyszło ci przez jeden dzień być hakerem, jaka byłaby twoja ulubiona broń i dlaczego?
  • Jaką najbardziej pomysłową próbę phishingu udało ci się zobaczyć i czy prawie zadziałała?

Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →

Pomysły i wskazówki dotyczące spotkania retrospektywnego

  • Nie szukajcie winnych. Rozmawiajcie o systemach i procesach, a nie o osobach, wtedy ludzie przyznają się do błędów i niedoszłych incydentów.
  • Mapujcie ustalenia na framework, np. MITRE ATT&CK lub NIST CSF, żeby łatwo śledzić usprawnienia w czasie.
  • Zaproście analityków, osoby reagujące na incydenty, inżynierów i kogoś z kierownictwa. Każda rola dostrzega martwe pola, których pozostali nie widzą.
  • Niech uczestnicy najpierw dodają notatki prywatnie lub anonimowo, żeby młodsi analitycy mogli zgłaszać problemy bez oglądania się na osoby starsze stażem.
  • Ograniczcie czas na każdą kolumnę, a ostatnią część spotkania zostawcie na zamianę luk w działania z właścicielami i terminami.
  • Śledźcie działania od jednej retrospektywy do następnej, żeby powtarzające się podatności nie przechodziły po cichu na kolejne cykle.

Najczęściej zadawane pytania

Kiedy przeprowadzić retrospektywę Cyber Security Ops?
Po poważnym incydencie, na koniec rotacji dyżurów albo co miesiąc lub co kwartał. Regularny harmonogram pomaga wychwycić powtarzające się luki, zanim zamienią się w incydenty.
Ile trwa retrospektywa Cyber Security Ops?
Zaplanujcie od 45 do 75 minut, w zależności od wielkości zespołu i liczby incydentów do omówienia. Ograniczenie czasu na każdą z czterech kolumn pomaga trzymać się planu.
Czym ta retrospektywa różni się od standardowego postmortemu incydentu?
Postmortem dogłębnie analizuje jeden incydent. Ta retrospektywa obejmuje cały cykl, od obsłużonych alertów, przez zabezpieczenia, które zadziałały, po wykryte luki. Wnioski z postmortemów są dla niej dobrym materiałem wejściowym.
Jak przeprowadzić retrospektywę bez szukania winnych?
Rozmawiajcie o systemach, procesach i narzędziach zamiast o konkretnych osobach i zacznijcie od prywatnego lub anonimowego dodawania notatek. Ludzie chętniej dzielą się niedoszłymi incydentami, gdy nie boją się, że zostaną obwinieni.
Kto powinien brać udział w retrospektywie Cyber Security Ops?
Analitycy SOC, osoby reagujące na incydenty, threat hunterzy, inżynierowie bezpieczeństwa i ktoś z kierownictwa. Połączenie różnych ról ujawnia martwe pola, które jedna grupa by przeoczyła.
Czy można powiązać ustalenia z frameworkami bezpieczeństwa?
Tak. Mapowanie ustaleń na MITRE ATT&CK lub NIST CSF daje wspólny punkt odniesienia i ułatwia mierzenie postępów między cyklami.
Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo