Reagowanie na incydenty

• Przeprowadzisz pełny proces od przygotowania do wniosków po incydencie.
• Wyznaczysz właściciela, role, ważność, zakres i kanały eskalacji.
• Zbudujesz chronologię na podstawie logów, PCAP, konfiguracji i informacji biznesowej.
• Zabezpieczysz artefakty z kontrolą integralności i łańcuchem nadzoru.
• Oddzielisz ograniczenie skutków, usunięcie przyczyny, odtworzenie i monitoring po zmianie.

Wymagania wstępne

• Zagrożenia i ochrona sieci
• Monitoring bezpieczeństwa, IDS/IPS i SIEM
• Analiza pakietów w Wiresharku
• Kopie i odtwarzanie

Jedna osoba może pełnić kilka ról w małej firmie, ale odpowiedzialności nadal powinny być jawne. Właściciel incydentu utrzymuje jeden rejestr decyzji i zapobiega równoległym, sprzecznym zmianom.

• Ważność łączy wpływ na ludzi, dane, usługę, finanse i zgodność z pilnością oraz możliwością rozprzestrzenienia.
• Zakres opisuje dotknięte konta, hosty, segmenty, usługi, lokalizacje, dane i przedział czasu, a także elementy jeszcze niesprawdzone.
• Eskalacja techniczna dostarcza kompetencji, biznesowa zapewnia decyzję o wpływie, a formalna uruchamia wymagane zgłoszenia.
• Kanały awaryjne muszą działać także wtedy, gdy poczta, komunikator lub katalog firmy są częścią incydentu.
• Klasyfikację aktualizuje się wraz z nowymi dowodami; wstępna niska ważność nie zamyka analizy.

Chronologia powinna odróżniać czas wystąpienia, czas zapisany przez źródło, czas odebrania przez kolektor i czas zauważenia przez człowieka. Zapisuj strefę czasową, przesunięcie zegara, źródło oraz poziom pewności.

Dla każdej hipotezy prowadź dane wspierające, przeczące i brakujące. Brak wpisu w jednym logu nie zawsze oznacza brak zdarzenia: źródło mogło nie logować, utracić zapis albo mieć inną retencję.

Zbieraj tylko dane potrzebne do celu i zgodnie z uprawnieniem. Oryginał przechowuj w kontrolowanym miejscu, a analizę wykonuj na kopii roboczej. Dla plików zapisuj kryptograficzny hash, narzędzie, osobę, czas, źródło oraz każdą zmianę posiadacza lub lokalizacji.

Łańcuch nadzoru nad dowodem (chain of custody) dokumentuje, kto i kiedy pozyskał, przekazał, przechowywał i analizował artefakt. Sam hash nie dowodzi, skąd plik pochodzi; wspiera wykrywanie późniejszej zmiany względem zapisanej wartości.

Firewall rejestruje nietypowe próby połączeń z komputera księgowości. Kilka minut później przełącznik pokazuje zmianę mapowania IP–MAC, a DNS zapisuje zapytania do rzadkiej domeny. Żaden sygnał osobno nie przesądza o ataku: możliwy jest skaner administratora, failover bramy i aktualizacja aplikacji.

Właściciel incydentu zabezpiecza logi, konfigurację i ograniczony PCAP zgodnie z uprawnieniem. Analityk w Wiresharku porównuje kolejność ARP, DNS i połączeń, ale nie oczekuje odszyfrowania TLS. Zespół sprawdza port przełącznika, dzierżawę DHCP, proces na końcówce, harmonogram zmian oraz legalność adresów.

Dopiero zgodność kilku źródeł uzasadnia izolację hosta. Izolacja ma właściciela, czas, spodziewany wpływ i sposób cofnięcia. Konto księgowe zostaje zabezpieczone tylko wtedy, gdy analiza wskazuje ryzyko dla tożsamości, a nie automatycznie na podstawie jednego pakietu.

• Streszczenie biznesowe: wpływ, czas, aktualny stan i decyzje.
• Zakres potwierdzony, wykluczony i nadal nieznany.
• Chronologia z odniesieniami do zabezpieczonych źródeł.
• Przyczyna bezpośrednia, czynniki sprzyjające i ograniczenia analizy.
• Działania ograniczające, naprawcze i odtworzeniowe wraz z właścicielami.
• Co zadziałało, co opóźniło reakcję i jakie zadania mają termin oraz kryterium weryfikacji.

• Nie wykonuj masowego restartu lub czyszczenia przed oceną wpływu na dowody i ciągłość.
• Izolacja powinna być proporcjonalna, zatwierdzona, udokumentowana i odwracalna, jeśli sytuacja na to pozwala.
• PCAP i logi mogą zawierać dane wrażliwe; minimalizuj zakres i ogranicz dostęp.
• Kontakt z użytkownikiem lub dostawcą prowadź zaufanym kanałem, zwłaszcza gdy poczta jest częścią incydentu.
• Wnioski trzeba aktualizować; pierwotna hipoteza może okazać się błędna.

• Brak jednego właściciela incydentu i równoległe zmiany bez wspólnego rejestru.
• Uznanie pierwszego alertu za przyczynę zamiast obserwacji wymagającej korelacji.
• Analiza oryginalnego PCAP bez zachowania niezmienionej kopii.
• Przywrócenie usługi bez testu integralności, funkcji i okresu zwiększonego monitoringu.
• Raport bez właścicieli i terminów działań naprawczych.

• Czym różni się zdarzenie od potwierdzonego incydentu?
• Dlaczego ograniczenie skutków nie jest jeszcze usunięciem przyczyny?
• Jakie cztery czasy warto rozróżnić w chronologii?
• Co dokumentuje łańcuch nadzoru nad dowodem i czego nie dowodzi sam hash?
• Jakie warunki muszą być spełnione przed pełnym przywróceniem usługi?

Dla fikcyjnego scenariusza małej firmy przygotuj kartę incydentu: właściciel, role, ważność, zakres, oś czasu, trzy hipotezy, artefakty, kontrola integralności, decyzja o ograniczeniu, kryteria odtworzenia i pięć działań po incydencie. Nie przeprowadzaj ataku ani nie zbieraj danych spoza LAB-CYBER.

1. Uzupełnij chronologię scenariusza firewall–ARP–DNS trzema alternatywnymi wyjaśnieniami oraz danymi rozstrzygającymi.
2. Zaprojektuj formularz przekazania PCAP zawierający identyfikator, źródło, czas, hash, osobę przekazującą i odbierającą.
3. Rozdziel sześć przykładowych działań na ograniczenie, usunięcie przyczyny, odtworzenie i monitoring po przywróceniu.

• Reagowanie rozpoczyna się przed incydentem: od ról, kontaktów, logowania, kopii i ćwiczeń.
• Zakres, ważność i hipotezy zmieniają się wraz z dowodami; pojedynczy sygnał nie przesądza o ataku.
• Ochrona artefaktów obejmuje minimalizację, integralność, kontrolę dostępu i łańcuch nadzoru.
• Bezpieczne zamknięcie wymaga usunięcia przyczyny, zweryfikowanego odtworzenia, monitoringu i działań po incydencie.

• Monitoring bezpieczeństwa, IDS/IPS i SIEM
• Analiza pakietów w Wiresharku
• CYB-02 — Analiza anomalii w Wiresharku
• CYB-05 — Korelacja logów i podstawy SIEM
• CYB-06 — Zabezpieczanie materiału: logi i PCAP
• Odporność i odtwarzanie

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations
• NIST Cybersecurity Framework 2.0
• CISA — Cybersecurity Incident and Vulnerability Response Playbooks
• Wireshark User’s Guide