Reagowanie na incydenty i zarządzanie podatnościami dla Security+

Domain 4 w SY0-701 to miejsce, gdzie teoria bezpieczeństwa spotyka się z operacyjną rzeczywistością. Dwa programy działają równolegle w każdej dojrzałej organizacji: zarządzanie podatnościami znajduje i zamyka słabości, zanim atakujący je wykorzystają, a reagowanie na incydenty obsługuje naruszenie, gdy prewencja i tak zawiedzie. Egzamin nie wymaga od ciebie pracy na zmianie w SOC, ale oczekuje, że rozpoznasz, która faza którego procesu pasuje do scenariusza — i unikniesz pułapek mylących skanowanie z testem penetracyjnym albo containment z eradication.

Ten wpis przechodzi przez oba cykle życia z wystarczającą głębią, by odpowiadać na pytania scenariuszowe, plus koncepcje higieny forensics i threat huntingu, które pojawiają się pod tym samym parasolem domeny.

Dlaczego te dwa programy należą do siebie

Zarządzanie podatnościami jest proaktywne i cykliczne. Reagowanie na incydenty jest reaktywne i liniowe (aż do następnego incydentu). W praktyce wzajemnie się zasilają: root cause po incydencie często ujawnia brakującą łatkę, błędną konfigurację lub lukę w detekcji, którą zarządzanie podatnościami powinno było wyłapać. Z drugiej strony krytyczny CVE na serwerze wystawionym do internetu może uruchomić awaryjny workflow IR, jeśli aktywność exploita jest już widoczna w logach.

Pułapka egzaminacyjna: Pytanie opisuje „cotygodniowe skany uwierzytelnione ze SLA remediacji” i pyta, jaki program jest opisywany. To zarządzanie podatnościami, nie reagowanie na incydenty — nawet jeśli w distractorze pojawi się sformułowanie typu „program zapobiegania incydentom”.

Pętla zarządzania podatnościami

Myśl o zarządzaniu podatnościami jako o zamkniętej pętli, nie jednorazowym projekcie. SY0-701 oczekuje znajomości etapów i tego, co dzieje się na każdym.

Odkrywanie i inwentaryzacja

Nie możesz chronić zasobów, których nie znasz. Discovery obejmuje skanowanie sieci, inwentaryzację agentową, API zasobów chmurowych i uzgadnianie z CMDB. Shadow IT — działy uruchamiające SaaS bez review bezpieczeństwa — to powtarzający się scenariusz egzaminacyjny, bo niezinwentaryzowane zasoby nigdy nie trafiają do kolejki skanowania.

Scenariusz: Analityk bezpieczeństwa znajduje bazę danych wystawioną do internetu. CMDB nie ma tego serwera. Pierwszym krokiem remediacji nie jest „załataj bazę”, lecz dodaj ją do inwentaryzacji i przypisz właściciela. Bez ownership łatki i wyjątki nie mają odpowiedzialnej strony.

Skanowanie i ocena

Narzędzia skanujące (Nessus, Qualys, OpenVAS i podobne) identyfikują brakujące łatki, słabe konfiguracje i znane CVE. Skany uwierzytelnione logują się na cel i dają dokładniejsze wyniki niż skany nieuwierzytelnione, które mogą pominąć problemy widoczne dopiero po logowaniu.

Pułapka egzaminacyjna: „Skan zgłosił zero krytycznych usterek na serwerze webowym” nie znaczy, że serwer jest bezpieczny. Skany nieuwierzytelnione często pomijają luki warstwy aplikacji, a skanery nie znajdą zero-day ani błędów logiki.

Ocena dodaje kontekst: wynik CVSS, dostępność exploita, krytyczność zasobu, ekspozycja sieciowa i kontrolki kompensujące. CVSS 9.8 na wewnętrznym VLAN-ie labowym bez trasy do internetu traktuje się inaczej niż ten sam wynik na bramce płatniczej.

Analiza i priorytetyzacja

Priorytetyzacja to moment, w którym zespoły bezpieczeństwa zarabiają pensję. Surowe liczby CVE generują szum; priorytetyzacja oparta na ryzyku generuje działanie.

Scenariusz: Tego samego dnia lądują dwie krytyczne podatności. Jedna dotyczy publicznego API z znanym kodem exploita. Druga dotyczy wewnętrznego serwera drukowania bez znanego exploita i wrażliwych danych. Najpierw łataj API. Egzamin oczekuje uzasadnienia priorytetu wpłyem biznesowym, nie samym CVSS.

Remediacja

Opcje remediacji obejmują łatanie, hardening konfiguracji, wymianę oprogramowania, segmentację sieci lub kontrolki kompensujące, gdy łatanie jest niemożliwe (legacy OT to klasyczne ograniczenie).

Pułapka egzaminacyjna: „Akceptacja ryzyka” jest poprawna, gdy koszt remediacji przewyższa ryzyko, ale wymaga udokumentowanej decyzji, nazwisanego właściciela i daty przeglądu. Wieczna akceptacja bez terminu ważności to failure governance, nie poprawna kontrolka.

Walidacja i raportowanie

Po remediacji przeskanuj ponownie, by potwierdzić fix. Raportuj interesariuszom językiem ryzyka — „zmniejszona zewnętrzna powierzchnia ataku na systemy płatnicze” — a nie arkuszem ID CVE, którego zarząd nie zinterpretuje.

Metryki, które egzamin może przywołać:

• Mean time to remediate (MTTR) wg poziomu severity
• Scan coverage (% zasobów przeskanowanych zgodnie z harmonogramem)
• Recurrence rate (ta sama klasa podatności wraca wielokrotnie — sygnał failure procesu)

Cykl życia reagowania na incydenty

CompTIA definiuje sześciofazowy proces IR. Zapamiętaj kolejność, ale ważniejsze jest zrozumienie, co zmienia się w każdej fazie.

Preparation → Detection & Analysis → Containment → Eradication → Recovery → Lessons Learned

Preparation

Preparation dzieje się przed jakimkolwiek incydentem. Obejmuje udokumentowane playbooki, listy kontaktów (legal, PR, ubezpieczenie, organy ścigania), narzędzia forensics, procedury obsługi dowodów i tabletop exercises, które ujawniają luki, zanim zrobią to prawdziwi atakujący.

Scenariusz: Podczas tabletopu zespół odkrywa, że nikt nie wie, kto może autoryzować wyłączenie produkcyjnego sklepu e-commerce. Ta luka należy do preparation — przypisz decyzyjność teraz, nie o 2 w nocy podczas ransomware.

Detection and Analysis

Detekcja pochodzi z alertów SIEM, telemetrii EDR, zgłoszeń użytkowników, threat intelligence i wykrywania anomalii. Analiza potwierdza, czy alert to prawdziwy incydent, określa zakres oraz dotknięte systemy i dane.

Pułapka egzaminacyjna: „Alert IDS się wystrzelił” to detekcja, nie containment. Następny krok to analiza — skoreluj z innymi logami, ustal czy to false positive, i określ zakres zanim podejmiesz destrukcyjne działanie.

Przydatne źródła danych do analizy:

• SIEM — skorelowane zdarzenia w całym środowisku
• EDR/XDR — telemetria procesów, plików i sieci na endpointach
• Logi tożsamości — sukcesy i porażki uwierzytelniania, zmiany uprawnień
• Logi DNS i proxy — beaconing C2, wzorce exfiltracji
• Cloud audit trails — wywołania API, zmiany konfiguracji
• Logi bramy e-mail — dostarczenie phishingu i kliknięcia

Containment

Containment ogranicza szkody bez koniecznego usunięcia zagrożenia. Strategie obejmują izolację hosta od sieci, blokadę IP lub domeny na firewallu, wyłączenie skompromitowanego konta lub kwarantannę VLAN-u.

Scenariusz: EDR wykrywa lateral movement ze stacji roboczej w dziale finansów. Opcje containment:

1. Izolacja sieciowa stacji (zachowuje pamięć pod forensics)
2. Wyłączenie konta skompromitowanego użytkownika (zatrzymuje nadużycie poświadczeń)
3. Blokada firewall na IP C2 (może zaalarmować atakującego)

Najlepszy wybór zależy od potrzeb zachowania dowodów i wpływu biznesowego. Egzamin często testuje, czy wybierzesz containment (zatrzymaj krwawienie) vs eradication (usuń root cause).

Rozróżnienie w jednym zdaniu:

• Containment: Zatrzymaj rozprzestrzenianie incydentu; zagrożenie może nadal istnieć na izolowanym systemie.
• Eradication: Usuń zagrożenie całkowicie — usuń malware, zamknij wykorzystaną podatność, unieważnij wszystkie mechanizmy persistence.

Eradication

Eradication usuwa zagrożenie ze środowiska. Obejmuje usuwanie malware, łatanie wykorzystanej podatności, usuwanie kont utworzonych przez atakującego i czyszczenie persistence (scheduled tasks, klucze rejestru, web shelle).

Pułapka egzaminacyjna: Reimaging skompromitowanego laptopa to eradication na tym endpoincie, ale jeśli wektor initial access (niezałatwione urządzenie VPN) pozostaje, organizacja nie jest eradicated — tylko contained na jednym urządzeniu.

Recovery

Recovery przywraca systemy do normalnej pracy z znanych dobrych backupów lub czystych rebuildów. Waliduj, że przywrócone systemy są załatane i monitorowane, zanim wrócą do produkcji.

Scenariusz: Ransomware zaszyfrował serwer plików. Zespół przywraca z backupu z poprzedniej nocy. Recovery jest kompletne dopiero po potwierdzeniu, że backup nie został też zaszyfrowany, weryfikacji braku persistence i załataniu wektora wejścia przed ponownym podłączeniem do sieci.

Lessons Learned

Post-incident review dokumentuje timeline, root cause, co zadziałało, co zawiodło oraz action items z właścicielami i datami. To zasila preparation (zaktualizowane playbooki) i zarządzanie podatnościami (nowe cele skanowania, priorytety łatek).

Pominięcie lessons learned gwarantuje powtórkę tego samego incydentu. Egzamin może podać scenariusz, w którym zespół zamyka ticket zaraz po recovery i pyta, co zostało pominięte.

Higiena forensics i obsługa dowodów

SY0-701 nie wymaga przeprowadzenia badania forensics, ale testuje wiedzę koncepcyjną o obsłudze dowodów.

Order of Volatility

Zbieraj dowody od najbardziej lotnych do najmniej lotnych:

1. Rejestry CPU i cache
2. RAM (pamięć)
3. Stan sieci i aktywne połączenia
4. Uruchomione procesy
5. Magazyn dyskowy
6. Zdalne systemy logowania i archiwizacji
7. Konfiguracja fizyczna i dokumentacja

Pułapka egzaminacyjna: „Help desk zrestartował serwer, żeby naprawić wydajność” mogło zniszczyć dowody malware w pamięci. Pytanie dotyczy tego, co zostało naruszone — chain of custody lub order of volatility — a nie tego, czy restart był dobrym krokiem troubleshooting.

Chain of Custody

Każde przekazanie dowodu musi być udokumentowane: kto zebrał, kiedy, gdzie przechowywano i kto miał dostęp. Luki w chain of custody mogą unieważnić dowody w postępowaniu prawnym.

Kluczowe praktyki

• Hashuj dowody (MD5/SHA-256) przed i po zbieraniu, by udowodnić integralność
• Write blockery przy obrazowaniu dysku, by zapobiec modyfikacji
• Dokumentuj wszystko ze znacznikami czasu
• Minimalizuj obsługę — kopiuj do analizy, zachowuj oryginał

Podstawy threat huntingu

Threat hunting jest proaktywny i oparty na hipotezie. Łowca zaczyna od teorii („atakujący mogą używać living-off-the-land binaries w VLAN-ie finansów”) i przeszukuje telemetrię pod kątem wskaźników potwierdzających lub obalających ją.

Różni się od:

• Automatycznego alertingu — reaktywny, oparty na regułach
• Skanowania podatności — znajduje słabości, nie aktywnych adversaries
• Testu penetracyjnego — symuluje atak, ograniczony czasowo engagement

Scenariusz: Reguła SIEM nic nie łapie, ale łowca zauważa powershell.exe uruchamiane z winword.exe na trzech stacjach finansów w tej samej godzinie. To hunting — żaden sygnatura nie zadziałała, ale zachowanie pasuje do znanego TTP.

Threat hunting zasila IR, gdy hipotezy potwierdzają aktywną kompromitację. Zasila zarządzanie podatnościami, gdy root cause analysis ujawnia systemowe luki.

Tabletop: ransomware o 02:15

Serwer plików w VLAN-ie operacyjnym zaczyna szyfrować pliki. EDR alertuje o podejrzanym zachowaniu procesu. Przejdź przez fazy:

Zauważ, jak lessons learned produkuje action items dla zarządzania podatnościami: załataj VPN, segmentuj sieć, przetestuj izolację backupów.

Typowe pułapki egzaminacyjne w Domain 4

1. Skanowanie vs. test penetracyjny — Skanowanie znajduje potencjalne podatności; pen test waliduje exploitability przez symulowany atak.
2. Containment vs. eradication — Containment zatrzymuje rozprzestrzenianie; eradication usuwa zagrożenie.
3. Hot site vs. warm site vs. cold site — Kompromis czasu recovery i kosztu (hot = najszybszy, najdroższy).
4. Full backup vs. incremental vs. differential — Wiedz, co każdy przywraca i ile storage/czasu wymaga.
5. Automatyczna odpowiedź vs. manual approval — SOAR może auto-contain, ale niektóre akcje wymagają autoryzacji człowieka, by uniknąć disruption biznesowego.

Wskazówki do ćwiczeń

1. Narysuj cykl IR na papierze z pamięci. Opisz jedną akcję na fazę.
2. Napisz definicje containment i eradication bez patrzenia. Jeśli się zlewają, stracisz punkty na PBQ z kolejnością.
3. Ćwicz scenariusz priorytetyzacji: Mając trzy podatności z różnym CVSS, ekspozycją i wartością zasobu, ułóż je w kolejności i uzasadnij.
4. Recytuj order of volatility na głos raz dziennie przez tydzień.
5. Łącz IR z VM: Po każdym pytaniu o incydenty zapytaj „jaką zmianę w zarządzaniu podatnościami zapobiegnie powtórce?”

Domain 4 nagradza myślenie operacyjne. Kandydat, który wizualizuje prawdziwą zmianę w SOC — alerty lecą, manager pyta „jak źle”, sysadmin pyta „czy mogę zrestartować” — odpowiada na pytania scenariuszowe szybciej niż ten, który wkuwał definicje w izolacji.