1/55
Analiza przyczyn i skutków incydentów bezpieczeństwa informacji
Cel slajdu: Przedstawienie celów poznawczych modułu trzeciego, metodyki badania incydentów oraz znaczenia analizy przyczynowo-skutkowej dla odporności organizacji.

Od wykrycia anomalii do eliminacji przyczyn źródłowych

Samo odparcie ataku i przywrócenie systemów do działania to dopiero połowa sukcesu. Prawdziwe bezpieczeństwo buduje się poprzez dogłębne zrozumienie, dlaczego doszło do incydentu i jakie wywołał on skutki, zgodnie z normą ISO/IEC 27035-1:2023 (Incident management principles) oraz wytycznymi NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile.

  • Zakres modułu: Metodyki analizy przyczyn źródłowych (Root Cause Analysis - RCA), technika 5 Why, diagram Ishikawy (fishbone), analiza drzewa błędów (FTA), wskaźniki kompromitacji (IoC), analiza powłamaniowa i informatyka śledcza.
  • Analiza skutków i strat: Kategoryzacja strat finansowych, reputacyjnych, operacyjnych i prawnych, pogłębiona analiza wpływu na biznes (BIA), wyznaczanie parametrów RTO i RPO oraz szacowanie ryzyka dla osób fizycznych wg RODO.
  • Narzędzia analityczne i automatyzacja: Platformy SIEM, SOAR, Threat Intelligence (MISP), narzędzia forensyczne (Autopsy, FTK Imager, Volatility) oraz matryca MITRE ATT&CK.
  • Współpraca z CSIRT i zgodność: Praktyczna wymiana informacji z zespołami reagowania poziomu krajowego (CERT Polska / CSIRT NASK), wdrażanie wniosków instytucjonalnych (lessons learned) oraz spełnienie wymogów art. 23 Dyrektywy NIS2 i ustawy o KSC.
Root Cause Analysis (RCA - analiza przyczyn źródłowych): Systematyczny proces dochodzeniowy mający na celu identyfikację pierwotnych, fundamentalnych przyczyn zaistnienia incydentu, których usunięcie trwale zapobiega jego ponownemu wystąpieniu. Skróty i pojęcia: BIA (Business Impact Analysis, analiza wpływu na biznes); CSIRT (Computer Security Incident Response Team, zespół reagowania); KSC (ustawa o Krajowym Systemie Cyberbezpieczeństwa); NIS2 (dyrektywa w sprawie bezpieczeństwa sieci i informacji).
Proces Badania Przyczyn i Skutków Incydentu 1. Objaw Incydentu • Zaszyfrowane pliki • Alert systemu SIEM • Zgłoszenie klienta 2. Analiza Dowodów • Zrzut RAM i dysków • Oś czasu (Timeline) • Ekstrakcja IoC 3. Przyczyna (RCA) • Metoda 5 Why • Diagram Ishikawy • Luka w procesie 4. Wnioski • Łatka IT • Nowa reguła • Szkolenie Dlaczego powierzchowna reakcja to pułapka? • Usunięcie samego wirusa (objawu) bez zbadania, którędy wszedł napastnik, oznacza, że intruz wróci w 48h • Prawidłowa analiza RCA wskazuje awarie procedur (np. brak wdrożonego MFA, brak nadzoru nad kontem testowym) • Wycena skutków (BIA) pozwala udowodnić zarządowi stopę zwrotu z inwestycji (ROI) w nowe zabezpieczenia • Zgodność z ISO/IEC 27035: organizacja staje się cyberodporna poprzez ciągłą pętlę doskonalenia PDCA
2/55
Spis treści prezentacji
Cel slajdu: Przedstawienie struktury modułu trzeciego i logicznego układu omawianych zagadnień.

Układ materiału i plan wykładu

Wykład prowadzi od procedur zabezpieczania dowodów cyfrowych, przez klasyczne i inżynierskie metody analizy przyczyn (5 Why, Ishikawa, FTA), aż po kwantyfikację strat (BIA, RODO) i nowoczesne narzędzia automatyzacji analizy (SIEM, SOAR, EDR). Oficjalne źródła ramowe: Portal Cyber.gov.pl (Cyberbezpieczeństwo RP) oraz repozytorium wytycznych ENISA Incident Response (materiał w jęz. angielskim – brak polskiego odpowiednika; polskie omówienie: CERT Polska – baza wiedzy o obsłudze incydentów).

  • Blok 1: Wprowadzenie do analizy incydentów (slajdy 3-8): Uzasadnienie analizy, etapy postępowania, łańcuch dowodowy (chain of custody), timeline zdarzeń, kultura blameless oraz narzędzia forensyczne.
  • Blok 2: Metody analizy przyczyn źródłowych (slajdy 9-22): Metodyka RCA, iteracyjna technika 5 Why z przykładami, diagram Ishikawy dla cyberbezpieczeństwa, łączenie metod, analiza drzewa błędów (FTA), zasada Pareto 80/20, wskaźniki IoC i informatyka śledcza.
  • Blok 3: Analiza skutków incydentów (slajdy 23-38): Skutki finansowe, reputacyjne, prawne (RODO/NIS2) i operacyjne; metodyka BIA i parametry RTO/RPO; macierz wpływu, szacowanie kosztów, studium trzech przypadków (case study) oraz raport powłamaniowy.
  • Blok 4: Narzędzia i automatyzacja (slajdy 39-50): Architektura SIEM i SOAR, platformy Threat Intelligence (MISP), narzędzia do pamięci RAM i dysków, analiza malware, EDR, IDS/IPS, matryca MITRE ATT&CK, sztuczna inteligencja i proces lessons learned.
  • Blok 5: Podsumowanie, infografiki i ćwiczenia (slajdy 51-55): Syntetyczna mapa metod analizy, katalog narzędzi, studium przypadku do samodzielnego rozwiązania, pytania kontrolne i bibliografia.
Metodyka badania incydentu: Ustandaryzowany, powtarzalny proces operacyjny obejmujący zbieranie dowodów cyfrowych, badanie przyczyn technicznych i organizacyjnych oraz formalne raportowanie wyników. Skróty i pojęcia: SOC (Security Operations Center, centrum operacji bezpieczeństwa); RAM (pamięć operacyjna), EDR (Endpoint Detection and Response); RP (Rzeczpospolita Polska).
Spis treści prezentacji 3 1. Wprowadzenie do analizy • Slajdy 3-4: Uzasadnienie i proces • Slajdy 5-6: Dowody, Chain of Custody • Slajdy 7-8: Timeline, Blameless, Tools 2. Metody analizy przyczyn (RCA) • Slajdy 9-13: Metoda 5 Why i przykłady • Slajdy 14-18: Diagram Ishikawy • Slajdy 19-22: FTA, Pareto, IoC, Forensics 3. Analiza skutków (BIA) • Slajdy 23-27: Finanse, prawo, operacje • Slajdy 28-32: BIA, RTO/RPO, RODO • Slajdy 33-38: Scenariusze, Case Studies 4. Narzędzia i automatyzacja • Slajdy 39-43: SIEM, SOAR, Threat Intel • Slajdy 44-47: EDR, IDS/IPS, Malware • Slajdy 48-50: ATT&CK, AI, Lessons Learned Blok 5: Podsumowanie, infografiki syntetyczne, pytania kontrolne (slajdy 51-55)
3/55
Po co analizujemy incydenty - perspektywa prawna i inżynierska
Cel slajdu: Uzasadnienie konieczności prowadzenia rzetelnej analizy incydentów z punktu widzenia doskonalenia SZBI, wymogów prawnych oraz redukcji kosztów.

Dlaczego samo usunięcie skutków ataku nie wystarcza?

Zamknięcie zgłoszenia bez ustalenia przyczyn źródłowych to gwarancja, że incydent powtórzy się w najbliższej przyszłości. Rzetelna analiza to fundament cyberodporności organizacji oraz wymóg rozliczalności wynikający z przepisów prawa.

  • Zapobieganie ponownemu wystąpieniu: Identyfikacja i załatanie luki systemowej uniemożliwia temu samemu lub innemu napastnikowi ponowne sforsowanie zabezpieczeń tą samą ścieżką.
  • Etap 5.6 normy ISO/IEC 27035-1:2023 (Learn lessons): Międzynarodowy standard ISO/IEC 27035-1:2023 zaleca po każdym zdarzeniu wyciągnąć wnioski (ang. learn lessons) i wdrożyć je do Systemu Zarządzania Bezpieczeństwem Informacji (SZBI).
  • Wymogi prawne Dyrektywy NIS2 i ustawy o KSC: Zgodnie z ustawą o KSC (tekst jedn. Dz.U. 2026 poz. 20, nowelizacja Dz.U. 2026 poz. 252 wdrażająca Dyrektywę NIS2) podmiot ma obowiązek złożenia sprawozdania końcowego do właściwego zespołu CSIRT w terminie miesiąca od przekazania zgłoszenia incydentu - art. 23 ust. 4 lit. d dyrektywy NIS2 (a jeśli zgłoszenia nie przekazano - miesiąca od uzyskania wiedzy o incydencie). Trzeba odróżnić zgłoszenie incydentu od wczesnego ostrzeżenia: wczesne ostrzeżenie (24 h) i zgłoszenie (72 h) to dwa odrębne terminy, a miesiąc na sprawozdanie końcowe biegnie od zgłoszenia, nie od ostrzeżenia.
  • Rozliczalność przed Prezesem UODO (art. 5 ust. 2 RODO): Wykazanie przed organem nadzorczym (UODO – Zgłaszanie naruszeń i rozliczalność), że administrator podjął wszelkie racjonalne środki w celu zbadania podatności i zabezpieczenia praw osób poszkodowanych.
Wnioski powdrożeniowe (ang. lessons learned): Ustrukturyzowany proces retrospektywny prowadzony po opanowaniu incydentu, którego celem jest modyfikacja polityk, konfiguracji technicznych i procedur na podstawie doświadczeń z zaistniałego zdarzenia. Skróty i pojęcia: SZBI (System Zarządzania Bezpieczeństwem Informacji); MTTR (Mean Time to Repair, średni czas naprawy); PDCA (Plan-Do-Check-Act, cykl Deminga), UODO (Urząd Ochrony Danych Osobowych); KSC (Krajowy System Cyberbezpieczeństwa).
Cztery Filary Celowości Analizy Incydentu Filar Prawny (Compliance) • Raport końcowy 1 mies. do CSIRT • Wykazanie należytej staranności • Ochrona przed karami UODO/KSC Zasada rozliczalności (accountability) Filar Techniczny (Security) • Identyfikacja wektora wejścia • Wykrycie ukrytych backdoorów • Aktualizacja sygnatur i reguł SIEM Trwałe usunięcie podatności Filar Finansowy (Business) • Wyliczenie rzeczywistych strat • Roszczenia z polis cyber-insurance • Uzasadnienie budżetu na obronę Optymalizacja ROI w bezpieczeństwie Filar Organizacyjny (Culture) • Eliminacja błędów w procedurach • Celowane szkolenia pracowników • Wzrost dojrzałości zespołów SOC Ciągłe doskonalenie (pętla PDCA)
4/55
Etapy analizy incydentu - metodyczny proces dochodzeniowy
Cel slajdu: Przedstawienie 5-etapowego cyklu analitycznego od zbierania dowodów cyfrowych po formułowanie zaleceń poincydentowych.

Struktura logiczna badania bezpieczeństwa

Badanie incydentu wymaga rygorystycznego porządku metodologicznego opisanego w normie ISO/IEC 27035-2:2023 (Guidelines to plan and prepare for incident response) oraz przewodniku NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. Chaotyczne działania prowadzą do zatarcia kluczowych śladów.

  • Krok 1: Zbieranie danych i zabezpieczenie dowodów: Pozyskanie surowych danych (logi, pamięć RAM, zrzuty ruchu sieciowego) przy zachowaniu integralności kryptograficznej.
  • Krok 2: Rekonstrukcja osi czasu (Timeline Analysis): Ułożenie wszystkich zaobserwowanych zdarzeń w ścisłym porządku chronologicznym z uwzględnieniem synchronizacji czasu NTP.
  • Krok 3: Analiza przyczyn źródłowych (RCA): Zastosowanie metod analitycznych (5 Why, diagram Ishikawy, FTA) w celu przejścia od bezpośrednich objawów do przyczyn systemowych.
  • Krok 4: Szacowanie skutków i wpływu na biznes (BIA): Wycena strat finansowych, operacyjnych, reputacyjnych oraz ocena ryzyka naruszenia praw osób fizycznych.
  • Krok 5: Formułowanie wniosków i plan naprawczy: Opracowanie oficjalnego raportu powłamaniowego oraz harmonogramu wdrożenia poprawek zabezpieczeń zgodnie z bazą wiedzy SANS Incident Handler's Handbook.
Proces analizy incydentu: Sekwencja powiązanych działań analityczno-badawczych prowadzonych w celu wyjaśnienia genezy, mechanizmu, zasięgu oraz konsekwencji zaistniałego naruszenia bezpieczeństwa informacji. Skróty i pojęcia: NTP (Network Time Protocol, protokół synchronizacji czasu); RAM (pamięć operacyjna); SANS (instytut SANS, baza: SANS White Papers).
Pięć Faz Procesu Analizy Incydentu 1. Dowody • Zrzut RAM • Obrazy dysków • Logi SIEM Hash SHA-256 2. Oś Czasu • Kolejność • Czas UTC • Synchronizacja Super-timeline 3. Przyczyny • Metoda 5 Why • Ishikawa • Drzewo FTA Root Cause 4. Skutki • Analiza BIA • Straty PLN • Ryzyko RODO Wpływ na biznes 5. Wnioski • Raport końcowy • Action items • Zmiany w SZBI Lessons learned Powiązanie etapów analizy z cyklem reagowania wg ISO/IEC 27035 • Etapy 1-2 realizowane są równolegle z działaniami powstrzymującymi (containment) • Etap 3 (RCA) decyduje o doborze skutecznych metod eradykacji (usunięcia przyczyn) • Etap 4 (Skutki) stanowi podstawę do raportowania prawnego (UODO, CSIRT, Zarząd) • Etap 5 zamyka cykl i aktualizuje rejestr ryzyk oraz konfigurację zabezpieczeń
5/55
Zbieranie danych i dowodów cyfrowych - łańcuch dowodowy
Cel slajdu: Zrozumienie zasad zabezpieczania elektronicznego materiału dowodowego zgodnie z normą ISO/IEC 27037 oraz pojęcia nienaruszalności łańcucha dowodowego.

Prawidłowość dowodowa w informatyce śledczej

Materiał dowodowy w cyberprzestrzeni jest niezwykle ulotny. Procedury jego zabezpieczania reguluje norma ISO/IEC 27037:2012 (Guidelines for identification, collection, acquisition and preservation of digital evidence), wytyczne IETF RFC 3227 (Evidence Collection) oraz przepisy prawa dowodowego (Dz.U. 1997 nr 89 poz. 555 – KPK art. 228, art. 393 § 3).

  • Kolejność ulotności danych (zasada Order of Volatility; dokumentem zbiorczym jest RFC 3227 - Guidelines for Evidence Collection and Archiving): Najpierw zabezpieczamy dane najbardziej ulotne: rejestry CPU i cache -> pamięć operacyjna RAM -> stan połączeń sieciowych -> dyski twarde i SSD -> nośniki optyczne i taśmy archiwalne.
  • Kopia binarna (bit-by-bit / forensic image): Wykonywanie kopii lustrzanej dysku sektor po sektorze z użyciem sprzętowych blokerów zapisu (write blockers), aby nie zmodyfikować ani jednego bitu na nośniku źródłowym: dd if=/dev/sdb of=/mnt/forensic/dysk.raw bs=64K status=progress conv=noerror,sync.
  • Kryptograficzne sumy kontrolne (skróty SHA-256): Wyliczanie skrótu kryptograficznego przed i po wykonaniu kopii dowodowej: sha256sum /dev/sdb && sha256sum /mnt/forensic/dysk.raw; zgodność skrótów stanowi formalny dowód integralności.
  • Łańcuch dowodowy (Chain of Custody): Dokument rejestrujący: kto, kiedy, w jakim celu i gdzie pobrał, przekazał, badał lub przechowywał zabezpieczony nośnik dowodowy (wymóg art. 228 KPK i ISO/IEC 27037).
Łańcuch dowodowy (ang. chain of custody): Udokumentowany, nieprzerwany ciąg czynności rejestrujący każdą osobę posiadającą dowód elektroniczny, czas i cel jego przekazania oraz warunki przechowywania, gwarantujący autentyczność dowodu przed sądem. Skróty i pojęcia: CPU (Central Processing Unit, procesor); RAM (pamięć operacyjna); SSD (Solid-State Drive, dysk półprzewodnikowy); IETF (Internet Engineering Task Force); RFC 3227 (wytyczne zbierania dowodów, dokument IETF przywołany w treści); KPK (Kodeks postępowania karnego).
Hierarchia Ulotności Danych (Order of Volatility) 1. Pamięć RAM i rejestry procesora Znika po restarcie! (Najbardziej ulotne) 2. Połączenia sieciowe i tablice routingu Znika po odłączeniu kabla sieciowego 3. Dyski lokalne i partycje systemowe Trwałe (wymaga blokera zapisu write-blocker) 4. Taśmy archiwalne i logi zewnętrzne Najmniej ulotne (zapisane w chmurze / WORM) Wymogi dowodowe procedury Chain of Custody (ISO/IEC 27037) • Każdy zrzut pamięci i obraz dysku musi posiadać wyliczoną sumę SHA-256 w chwili pobrania • Brak formalnego protokołu przekazania dysku wyklucza dowód w procesie karnym (art. 267-269b KK)
6/55
Rekonstrukcja osi czasu (Timeline Analysis) i synchronizacja NTP
Cel slajdu: Przedstawienie metodyki tworzenia jednolitej osi czasu incydentu, korelacji zdarzeń z wielu systemów oraz krytycznej roli synchronizacji czasu.

Odtwarzanie sekwencji działań intruza sekunda po sekundzie

Oś czasu incydentu pozwala powiązać pozornie niepowiązane zdarzenia: pobranie pliku, nieudane logowanie, uruchomienie procesu PowerShell i transfer danych na zewnętrzny adres IP. Wymóg synchronizacji określają norma ISO/IEC 27002:2022 (zabezpieczenie 8.17 Clock synchronization) oraz standard IETF RFC 5905 (Network Time Protocol v4).

  • Korelacja zdarzeń wieloźródłowych: Łączenie logów z kontrolera domeny Active Directory, zapory sieciowej NGFW, bazy danych, serwera WWW, stacji roboczej oraz czujników EDR w jeden spójny ciąg zdarzeń.
  • Kluczowa rola protokołu NTP: Rozbieżność zegarów rzędu kilkudziesięciu sekund między serwerami poważnie utrudnia ustalenie przyczyn i skutków; weryfikacja synchronizacji CLI: chronyc tracking lub timedatectl status.
  • Format czasu UTC i strefy czasowe: Wszystkie logi w zespołach reagowania muszą być ujednolicone do uniwersalnego czasu koordynowanego (UTC), co eliminuje błędy związane ze zmianą czasu letniego/zimowego i pracą w chmurze.
  • Narzędzia generowania super-timeline: Zastosowanie frameworka Plaso / log2timeline: log2timeline.py --storage-file timeline.plaso /mnt/forensic/dysk.raw tworzącego chronologiczną bazę milionów operacji plikowych i systemowych.
Analiza osi czasu (ang. timeline analysis): Metoda analityczna polegająca na chronologicznym uszeregowaniu wszystkich wyekstrahowanych śladów cyfrowych w celu zrekonstruowania dokładnej ścieżki i tempa penetracji sieci przez atakującego. Skróty i pojęcia: UTC (Coordinated Universal Time, czas uniwersalny); NGFW (Next-Generation Firewall, zapora nowej generacji); Active Directory (usługa katalogowa Microsoft), EDR (Endpoint Detection and Response); WWW (World Wide Web).
Korelacja Zdarzeń na Osi Czasu (UTC) 23:14:02 UTC Firewall NGFW Port 443 inbound 23:14:15 UTC EventLog AD Logon ID 4624 23:14:48 UTC Agent EDR powershell -enc 23:15:20 UTC Baza SQL Dump 20k rekord Wymóg precyzyjnej synchronizacji NTP (ISO/IEC 27002 klauzula 8.17) • Bez synchronizacji NTP zdarzenie z bazy mogłoby mieć znacznik 23:13:00 (przed wejściem!) • Wszystkie systemy w organizacji muszą synchronizować się z centralnym, bezpiecznym serwerem NTP • Jednolity format UTC eliminuje błędy stref czasowych podczas korelacji zdarzeń transgranicznych
7/55
Zasady prowadzenia analizy - kultura Blameless i obiektywizm
Cel slajdu: Zapoznanie z zasadami kultury bezpieczeństwa wolnej od szukania kozłów ofiarnych (Blameless Post-Mortem) oraz standardami etycznymi analityka.

Szukanie luk systemowych zamiast winnych pracowników

Jeżeli dochodzenie po incydencie skupia się na znalezieniu i ukaraniu „winnego” pracownika, personel natychmiast zacznie zatajać kolejne pomyłki. Profesjonalne zasady etyki dochodzeniowej definiuje FIRST Ethics SIG (EthicsFIRST Framework) oraz metodyka inżynieryjna Google SRE – Postmortem Culture: Learning from Failure.

  • Koncepcja Blameless Post-Mortem: Podejście wywodzące się z inżynierii niezawodności: zakładamy, że pracownicy działają w dobrej wierze, a błąd człowieka jest bardzo często objawem wadliwego procesu albo braku zabezpieczeń technicznych.
  • Systemowe spojrzenie na incydent: Zamiast pytać: 'Kto kliknął?', pytamy: 'Dlaczego złośliwy e-mail trafił do skrzynki?', 'Dlaczego stacja nie zablokowała makra?', 'Dlaczego użytkownik miał prawa lokalnego administratora?'.
  • Interdyscyplinarność zespołu analitycznego: W składzie zespołu badającego incydent muszą znaleźć się: administratorzy systemów, inżynierowie sieci, analitycy SOC, programiści, radca prawny, Inspektor Ochrony Danych oraz przedstawiciel biznesu.
  • Zasada obiektywizmu i faktografii: Każdy wniosek w raporcie powłamaniowym musi opierać się na twardych dowodach cyfrowych (logach, skrótach, zrzutach), a nie na domysłach czy obietnicach ustnych.
Kultura bez obwiniania (ang. blameless culture): Podejście organizacyjne, w którym awarie i incydenty są traktowane jako okazje do nauki i uszczelnienia procesów, a nie powód do nakładania sankcji dyscyplinarnych na pracowników. Skróty i pojęcia: FIRST (Forum of Incident Response and Security Teams); SIG (Special Interest Group, grupa robocza, tu Ethics SIG); IOD (Inspektor Ochrony Danych), blameless post-mortem (analiza poawaryjna bez obwiniania).
Kultura Obwiniania vs Kultura Blameless Post-Mortem Kultura Obwiniania (Sankcje) • Pytanie: Kto zawinił? • Pracownicy boją się zgłaszać błędy • Ukrywanie incydentów przez dni • Brak usunięcia luki w systemie Skutek: Kolejny atak z tą samą luką! Kultura Blameless (Rozwój) • Pytanie: Jaka luka w systemie zawiodła? • Błyskawiczne zgłoszenie w 5 minut • Bezpieczeństwo psychologiczne zespołu • Automatyzacja blokad i procedur Skutek: Trwałe uszczelnienie organizacji Zasada psychologii bezpieczeństwa w IT • Największym wrogiem szybkiego reagowania na incydenty nie jest haker, lecz strach pracownika • W dojrzałej kulturze pracownik, który kliknął w phishing i natychmiast zadzwonił do SOC, jest chwalony!
8/55
Narzędzia wspierające analizę powłamaniową - przegląd
Cel slajdu: Ogólny przegląd klas oprogramowania wykorzystywanego w dochodzeniach poincydentowych przed szczegółowym omówieniem w bloku 4.

Cyfrowy warsztat pracy analityka incydentów

Współczesna analiza incydentu wymaga przetworzenia gigabajtów logów i zbadania pamięci wielu maszyn. Standardy laboratoryjne określają przewodnik NIST SP 800-86 (2006, Integrating Forensic Techniques into Incident Response) oraz program badawczy NIST CFTT (Computer Forensic Tool Testing).

  • Platformy korelacji zdarzeń (SIEM / Log Management): Zbieranie, normalizacja i indeksowanie logów z całej organizacji w czasie rzeczywistym (Splunk, Microsoft Sentinel, Elastic Stack, Wazuh).
  • Narzędzia informatyki śledczej dysków: Analiza struktury partycji, odzyskiwanie usuniętych plików, badanie rejestrów Windows przy użyciu platformy Autopsy (The Sleuth Kit) i FTK Imager.
  • Analiza pamięci operacyjnej (Memory Forensics): Wykrywanie procesów wstrzykniętych w pamięć RAM, ukrytych bibliotek DLL i aktywnych połączeń C2 przy użyciu frameworka Volatility 3 (The Volatility Foundation).
  • Analiza ruchu sieciowego (Network Forensics): Inspekcja przechwyconych pakietów pcap, rekonstrukcja sesji TCP/HTTP, wykrywanie anomalii protokołów (Wireshark, Zeek, NetworkMiner); polecenie CLI: tshark -r traffic.pcap -Y 'http.request or dns'.
Informatyka śledcza (ang. digital forensics): Dziedzina nauk sądowych i bezpieczeństwa IT zajmująca się prawnie dopuszczalnym pozyskiwaniem, zabezpieczaniem, analizą i prezentacją dowodów cyfrowych pochodzących z urządzeń elektronicznych. Skróty i pojęcia: SIEM (Security Information and Event Management); DLL (Dynamic Link Library, biblioteka dynamiczna); NTFS (New Technology File System); TCP/HTTP (protokoły transmisji i warstwy aplikacji); RAM (pamięć operacyjna).
Cyfrowy Warsztat Pracy Analityka Incydentów Analiza Logów (SIEM) • Agregacja milionów zdarzeń/sek. • Reguły korelacji i alerty • Narzędzia: Splunk, Sentinel, Wazuh Cel: Wykrycie anomalii i ścieżki ataku Pamięć RAM (Volatility) • Wykrywanie złośliwych procesów • Kradzież poświadczeń z LSASS • Narzędzia: Volatility, Rekall, WinPmem Cel: Analiza złośliwego kodu w locie Informatyka Śledcza Dysków • Odzyskiwanie usuniętych plików • Badanie $MFT, Prefetch, Shimcache • Narzędzia: Autopsy, FTK Imager Cel: Rekonstrukcja działań intruza Analiza Sieciowa (PCAP) • Badanie strumienia pakietów • Wykrywanie zapytań do domen C2 • Narzędzia: Wireshark, Zeek, Suricata Cel: Identyfikacja eksfiltracji danych
9/55
Metodyka Root Cause Analysis (RCA) - zasady i cele
Cel slajdu: Przedstawienie założeń metodologicznych analizy przyczyn źródłowych oraz różnicy pomiędzy objawem, przyczyną bezpośrednią a przyczyną źródłową.

Dociekanie sedna problemu zamiast leczenia objawów

Root Cause Analysis (RCA) to ustrukturyzowana metoda badania incydentu, która nie zadowala się stwierdzeniem „komputer został zainfekowany”, lecz dąży do zidentyfikowania wad w procesach zarządczych i architekturze technicznej. Standardy dochodzeniowe definiują wytyczne NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile oraz publikacje ENISA Incident Management (materiał w jęz. angielskim – brak polskiego odpowiednika; polskie omówienie: CERT Polska – baza wiedzy o obsłudze incydentów).

  • Poziom 1: Objaw (Symptom): Widoczny skutek ataku: komunikat z żądaniem okupu na ekranie, niedostępność portalu transakcyjnego, zablokowane konto prezesa.
  • Poziom 2: Przyczyna bezpośrednia (Direct Cause): Zdarzenie techniczne bezpośrednio wywołujące objaw: uruchomienie złośliwego skryptu PowerShell pobranego ze złośliwej domeny.
  • Poziom 3: Przyczyna pośrednia (Contributing Factor): Okoliczności sprzyjające atakowi: brak aktualizacji oprogramowania przez 6 miesięcy, brak blokady makr w plikach z poczty, uprawnienia lokalnego administratora.
  • Poziom 4: Przyczyna źródłowa (Root Cause): Wada systemowa lub organizacyjna: brak polityki zarządzania podatnościami, brak procedur nadzoru nad kontami, brak budżetu na szkolenia z cyberbezpieczeństwa.
  • Zasada trwałego rozwiązania: Tylko usunięcie przyczyny źródłowej gwarantuje, że podobny incydent nie powtórzy się w przyszłości.
Przyczyna źródłowa (ang. root cause): Fundamentalna słabość procesu, technologii lub organizacji, której usunięcie trwale eliminuje możliwość ponownego wystąpienia incydentu tego samego typu. Skróty i pojęcia: RCA (słownik NIST, hasło Root Cause Analysis), CSF (ramy NIST CSF 2.0).
Model Góry Lodowej w Analizie RCA 1. OBJAW (Nad wodą): Zaszyfrowane pliki serwera ERP Poziom widoczny dla użytkownika 2. PRZYCZYNA BEZPOŚREDNIA: Uruchomienie makra w załączniku faktura.docm 3. CZYNNIKI SPRZYJAJĄCE: Brak segmentacji sieci, pracownik z prawami roota Brak filtra antyspamowego z piaskownicą • Kontroler domeny bez łatki od 8 miesięcy 4. PRZYCZYNA ŹRÓDŁOWA (ROOT CAUSE): Brak formalnej procedury zarządzania podatnościami i brak cyklicznych szkoleń Zarząd nie zatwierdził budżetu na wdrożenie MFA i audyt uprawnień domenowych Leczenie objawów (formatowanie) nie naprawia problemu braku procedur w firmie!
10/55
Metoda 5 Why (5 x Dlaczego) - zasady i technika zadawania pytań
Cel slajdu: Opanowanie techniki zadawania pytań w metodzie 5 Why, zrozumienie jej zalet oraz ograniczeń w środowiskach IT.

Iteracyjna ścieżka dochodzenia do sedna awarii

Opracowana w latach 50. XX w. w fabryce Toyoty przez Taiichi Ohno metoda 5 Why jest jedną z najprostszych technik dochodzeniowych. Jej ramy opisuje American Society for Quality (ASQ 5 Whys Analysis) oraz terminologia NIST CSRC Glossary (Root Cause Analysis).

  • Zasada działania: Wychodząc od zaobserwowanego problemu, analityk zadaje pytanie 'Dlaczego?' w odniesieniu do uzyskanej odpowiedzi. Proces powtarza się zazwyczaj 5 razy, aż do osiągnięcia przyczyny procesowej.
  • Zasada faktografii (Unikanie domysłów): Każda odpowiedź musi opierać się na twardych dowodach z logów lub procedur, a nie na przypuszczeniach czy oskarżeniach pracowników.
  • Zalety metody: Intuicyjność, szybkość zastosowania, brak konieczności skomplikowanych obliczeń statystycznych, doskonała do analizy incydentów o liniowym przebiegu.
  • Ograniczenia metody w cyberbezpieczeństwie: Incydenty IT rzadko mają jedną liniową przyczynę. Często dochodzi do splotu wielu równoległych podatności, co wymaga rozgałęzienia analizy (drzewo 5 Why).
Metoda 5 Why (5 x Dlaczego): Iteracyjna technika interrogacyjna służąca do badania relacji przyczynowo-skutkowych leżących u podstaw określonego problemu, polegająca na wielokrotnym zadawaniu pytania 'dlaczego?'. Skróty i pojęcia: ASQ (American Society for Quality, organizacja jakości); CSRC (Computer Security Resource Center, portal NIST).
Mechanizm Iteracyjny Metody 5 Why Problem: Co się stało? 1. Dlaczego? Zaobserwowano wyciek danych bazy SQL 2. Dlaczego? Intruz przesłał złośliwe zapytanie SQL Injection 3. Dlaczego? Aplikacja WWW nie walidowała pól wejściowych 4. Dlaczego? Programiści nie przeszli szkolenia OWASP Top 10 5. Dlaczego? (PRZYCZYNA ŹRÓDŁOWA) Brak procedury bezpiecznego wytwarzania kodu (DevSecOps) w SZBI Pytamy 'Dlaczego?' aż do momentu, gdy odpowiedź wskazuje na lukę w procesie zarządczym.
11/55
Metoda 5 Why - przykład 1: atak ransomware
Cel slajdu: Przedstawienie kompletnej analizy rzeczywistego ataku ransomware przy użyciu techniki 5 Why.

Krok po kroku: od żądania okupu do braku nadzoru

Scenariusz: W poniedziałek rano pracownicy nie mogą otworzyć plików na dyskach sieciowych, a na serwerach wyświetla się żądanie okupu w kryptowalucie. Zalecenia prewencyjne publikuje CERT Polska – Poradnik: ransomware oraz kampania CISA #StopRansomware.

  • 1. Dlaczego serwery zostały zaszyfrowane?: Ponieważ na kontrolerze domeny Active Directory wykonano złośliwy program szyfrujący ransomware rozesłany przez polisę GPO.
  • 2. Dlaczego program uruchomił się na kontrolerze domeny?: Ponieważ napastnik uzyskał dostęp do konta Domain Admina i zdalnie rozpropagował złośliwy ładunek.
  • 3. Dlaczego intruz przejął konto Domain Admina?: Ponieważ wykradł poświadczenia z pamięci procesu LSASS stacji roboczej administratora IT za pomocą narzędzia Mimikatz.
  • 4. Dlaczego administrator logował się na zwykłą stację roboczą kontem domenowym?: Ponieważ organizacja nie wdrożyła dedykowanych stacji uprzywilejowanych (Privileged Access Workstations - PAW) ani poziomów administracji Tier.
  • 5. Dlaczego nie wdrożono stacji PAW ani modelu Tiering?: PRZYCZYNA ŹRÓDŁOWA: Dział IT nie wdrożył standardów architektury bezpiecznego zarządzania tożsamością, a kierownictwo uznało wymóg osobnych kont za „utrudniający pracę”.
Model administracji warstwowej (Active Directory Tiering): Architektura separacji tożsamości, w której konta administratorów najwyższego szczebla (Tier 0) mogą logować się wyłącznie do kontrolerów domeny i nigdy nie stykają się ze stacjami roboczymi użytkowników. Skróty i pojęcia: GPO (Group Policy Object, obiekt zasad grupy); LSASS (Local Security Authority Subsystem Service, podsystem uwierzytelniania Windows); PAW (Privileged Access Workstation, dedykowana stacja uprzywilejowana); Tiering (model warstw administracji).
Studium 5 Why: Atak Ransomware Problem: Serwery plików zaszyfrowane o 03:00 w nocy 1. Dlaczego? Ransomware rozpropagowany przez GPO z kontrolera domeny AD 2. Dlaczego? Intruz posiadał pełne uprawnienia Domain Admina 3. Dlaczego? Hasło admina wykradziono ze zwykłej stacji PC narzędziem Mimikatz 4. Dlaczego? Administratorzy używali jednego konta domenowego do wszystkiego 5. PRZYCZYNA ŹRÓDŁOWA (Decyzja zarządcza): Brak architektury Tiering i stacji PAW z powodu priorytetyzacji „wygody” nad bezpieczeństwem
12/55
Metoda 5 Why - przykład 2: wyciek danych osobowych
Cel slajdu: Przedstawienie analizy incydentu wycieku danych klientów w świetle RODO przy użyciu techniki 5 Why.

Krok po kroku: od zrzutu w darknecie do braku audytu

Scenariusz: Zespół CERT Polska informuje firmę, że baza danych zawierająca 100 000 numerów PESEL i adresów jej klientów została wystawiona na sprzedaż w darknecie. Obowiązek notyfikacji nakłada art. 33-34 RODO, a wytyczne publikuje UODO – Zgłaszanie naruszeń danych osobowych oraz Europejska Rada Ochrony Danych (EDPB, Guidelines 01/2021) (materiał w jęz. angielskim; wersja polska: UODO – Wytyczne 9/2022 dotyczące zgłaszania naruszeń (PL)).

  • 1. Dlaczego baza klientów znalazła się w darknecie?: Ponieważ została pobrana z publicznie dostępnego serwera testowego w chmurze AWS.
  • 2. Dlaczego serwer bazodanowy był publicznie dostępny z Internetu?: Ponieważ reguła Security Group zezwalała na ruch na porcie 3306 z dowolnego adresu IP (0.0.0.0/0).
  • 3. Dlaczego ustawiono otwarty dostęp na porcie 3306?: Ponieważ zewnętrzny programista chciał mieć wygodny dostęp do bazy z domu bez uruchamiania firmowego VPN.
  • 4. Dlaczego na serwerze testowym znajdowały się prawdziwe dane produkcyjne klientów?: Ponieważ programiści skopiowali bazę produkcyjną „do testów wydajnościowych” bez przeprowadzenia anonimizacji lub pseudonimizacji.
  • 5. Dlaczego nie zanonimizowano danych i nie wykryto otwartego portu?: PRZYCZYNA ŹRÓDŁOWA: Całkowity brak procedury bezpiecznego wytwarzania oprogramowania (brak polityki anonimizacji) oraz brak automatycznego skanera konfiguracji chmury (CSPM).
Anonimizacja danych osobowych (wg RODO): Przetworzenie danych osobowych w taki sposób, że osób, których dane dotyczą, nie można już zidentyfikować w sposób bezpośredni ani pośredni, przez co dane te przestają być danymi osobowymi. Skróty i pojęcia: AWS (Amazon Web Services, chmura publiczna); IP (Internet Protocol, adres protokołu internetowego); VPN (Virtual Private Network, wirtualna sieć prywatna); CSPM (Cloud Security Posture Management, zarządzanie postawą bezpieczeństwa chmury); PESEL (Powszechny Elektroniczny System Ewidencji Ludności).
Studium 5 Why: Wyciek Danych RODO Problem: 100 tys. PESEL klientów na sprzedaż w darknecie 1. Dlaczego? Pobrana bezpośrednio z serwera deweloperskiego w chmurze 2. Dlaczego? Baza MySQL była wystawiona na świat na porcie 3306 bez hasła 3. Dlaczego? Podwykonawca programistyczny wyłączył reguły firewall dla wygody 4. Dlaczego? Do środowiska testowego zgrano surową bazę z PESEL bez maskowania 5. PRZYCZYNA ŹRÓDŁOWA (Luka w procesie SZBI): Brak nadzoru nad podwykonawcami (NIS2) i brak procedury anonimizacji danych testowych
13/55
Metoda 5 Why - przykład 3: atak DDoS na serwis publiczny
Cel slajdu: Przedstawienie analizy incydentu odmowy usługi (DDoS) przy użyciu techniki 5 Why.

Krok po kroku: od zawieszenia portalu do wadliwej umowy SLA

Scenariusz: Portal informacyjny urzędu miasta przestał odpowiadać w trakcie ogłaszania kluczowych komunikatów kryzysowych z powodu zmasowanego ataku wolumetrycznego DDoS. Wskazówki mitygacyjne przedstawia CERT Polska – wiedza.cert.pl: obsługa incydentów (DDoS) oraz biuletyn CISA Advisory on Mitigating DDoS Attacks.

  • 1. Dlaczego portal urzędu przestał działać?: Ponieważ łącze internetowe serwerowni zostało w 100% nasycone ruchem 40 Gbps z ataku NTP Amplification.
  • 2. Dlaczego ruch dotarł bezpośrednio do serwerowni urzędu?: Ponieważ domena wskazywała bezpośrednio na publiczny adres IP routera urzędowego zamiast na usługę czyszczenia ruchu.
  • 3. Dlaczego nie wdrożono zewnętrznej ochrony anty-DDoS (np. Scrubbing Center / WAF w chmurze)?: Ponieważ urzędnicy uznali, że wystarczy wbudowany moduł zapory sieciowej w zakupionym firewallu.
  • 4. Dlaczego firewall urzędowy nie zatrzymał ataku?: Ponieważ zapora brzegowa chroni przed atakami protokołowymi, ale nie zapobiega fizycznemu zapchaniu łącza światłowodowego od dostawcy ISP.
  • 5. Dlaczego nie zabezpieczono ochrony na poziomie operatora?: PRZYCZYNA ŹRÓDŁOWA: Błędne założenia w analizie ryzyka BIA oraz brak wymogu ochrony anty-DDoS w umowie przetargowej na łącze telekomunikacyjne.
Scrubbing Center (centrum czyszczenia ruchu): Wyspecjalizowana infrastruktura telekomunikacyjna w chmurze operatora, która filtruje gigabity złośliwych pakietów DDoS, przepuszczając do serwerów ofiary wyłącznie legalne zapytania użytkowników. Skróty i pojęcia: DNS (Domain Name System); IP (adres IP); ISP (Internet Service Provider, dostawca internetu); WAF (Web Application Firewall); NTP Amplification (wzmocnienie przez serwery czasu).
Studium 5 Why: Atak DDoS Problem: Portal urzędowy leży i nie odpowiada obywatelom 1. Dlaczego? Łącze 1 Gbps zablokowane ruchem wolumetrycznym 40 Gbps 2. Dlaczego? Pakiety ataku dotarły bezpośrednio do routera brzegowego urzędu 3. Dlaczego? Ruch nie był filtrowany przez zewnętrzny węzeł Scrubbing Center 4. Dlaczego? Dostawca łącza internetowego ISP nie miał w umowie zapisu o mitygacji DDoS 5. PRZYCZYNA ŹRÓDŁOWA (Luka w przetargu i BIA): Wymagania SIWZ skupiły się na najniższej cenie łącza, ignorując analizę ryzyka dostępności
14/55
Diagram Ishikawy (Fishbone Diagram) - wprowadzenie
Cel slajdu: Przedstawienie metody diagramu przyczynowo-skutkowego Kaoru Ishikawy i adaptacji jej struktury do wielowymiarowej analizy incydentów.

Wizualna dekompozycja złożonych problemów bezpieczeństwa

W przypadku złożonych incydentów bezpieczeństwa metoda 5 Why bywa niewystarczająca, ponieważ skupia się na pojedynczej ścieżce. Diagram Ishikawy (zwany diagramem rybiej ości) pozwala na równoległe zbadanie wielu obszarów. Podstawy inżynierii jakości opisuje ASQ (Fishbone / Cause and Effect Diagram), a powiązanie z ryzykiem IT określa norma ISO/IEC 27005:2022 (Zarządzanie ryzykiem).

  • Struktura diagramu: Głowa ryby reprezentuje zaistniały incydent (np. kompromitacja sieci). Główny kręgosłup łączy się z głównymi ościami reprezentującymi kategorie przyczyn, od których odchodzą mniejsze ości z konkretnymi przyczynami.
  • Klasyczny model 5M+E w przemyśle: Manpower (ludzie), Machine (maszyny), Material (materiały), Method (metody), Measurement (pomiary), Environment (środowisko).
  • Przewaga w dochodzeniach zespołowych: Umożliwia przeprowadzenie burzy mózgów (brainstorming) z udziałem ekspertów z różnych dziedzin (sieciowcy, programiści, prawnicy, audytorzy) bez pominięcia żadnego aspektu.
  • Kolejny krok analityczny: Po zidentyfikowaniu gałęzi przyczyn na diagramie, do każdej z nich można zastosować metodę 5 Why w celu dotarcia do korzeni problemu.
Diagram Ishikawy (diagram przyczynowo-skutkowy / rybia ość): Graficzne narzędzie analityczne służące do systematycznej identyfikacji, kategoryzacji i prezentacji wszystkich potencjalnych przyczyn wywołujących określony problem jakościowy lub incydent bezpieczeństwa. Skróty i pojęcia: ASQ (American Society for Quality, źródło o diagramie rybiej ości, materiał w jęz. angielskim); 5M+E (Manpower, Machine, Material, Method, Measurement plus Environment, klasyczne kategorie Ishikawy), brainstorming (burza mózgów).
Anatomia Diagramu Ishikawy (Rybia Ość) INCIDENT (Problem) LUDZIE TECHNOLOGIA PROCESY POLITYKI ŚRODOWISKO DOSTAWCY Struktura rybiej ości gwarantuje badanie incydentu we wszystkich wymiarach SZBI.
15/55
Diagram Ishikawy w cyberbezpieczeństwie - adaptacja kategorii
Cel slajdu: Dostosowanie kategorii diagramu Ishikawy do realiów teleinformatycznych i systemów zarządzania bezpieczeństwem informacji wg norm ISO/IEC 27001 i 27002.

Kategorie analityczne w incydentach bezpieczeństwa

Przemysłowy model 5M został zaadaptowany do specyfiki środowisk IT, tworząc spójny zestaw kategorii odzwierciedlających zabezpieczenia organizacyjne, techniczne, osobowe i fizyczne zdefiniowane w normie ISO/IEC 27002:2022 (Controls layout) oraz przewodniku ENISA Good Practices for Supply Chain Cybersecurity.

  • Kategoria 1: Czynnik ludzki (People): Brak świadomości zagrożeń, zmęczenie, podatność na socjotechnikę, błędy operatorskie, działanie w pośpiechu, sabotaż wewnętrzny.
  • Kategoria 2: Technologia i oprogramowanie (Technology): Podatności w kodzie (luki CVE), brak aktualizacji systemów (brak patchingu), błędy konfiguracji, brak szyfrowania, awarie sprzętowe.
  • Kategoria 3: Procesy i procedury (Process): Brak procedury weryfikacji zmian (Change Management), nieskuteczny proces onboarding/offboarding, brak procedur tworzenia i testowania kopii zapasowych.
  • Kategoria 4: Polityki i nadzór (Policy & Governance): Brak nadrzędnej polityki haseł, brak formalnej akceptacji ryzyka przez zarząd, brak egzekwowania zasad czystego biurka i ekranu.
  • Kategoria 5: Otoczenie i łańcuch dostaw (Environment & Supply Chain): Podatności u dostawców usług chmurowych i oprogramowania, brak umów powierzenia przetwarzania danych (DPA RODO), zaniedbania ochrony fizycznej serwerowni.
Kategorie przyczyn w cyberbezpieczeństwie: Zestaw zdefiniowanych domen operacyjnych (Ludzie, Technologia, Procesy, Polityki, Łańcuch dostaw), w ramach których analitycy kategoryzują zidentyfikowane słabości obronne organizacji. Skróty i pojęcia: CVE (Common Vulnerabilities and Exposures, publiczne identyfikatory podatności); DPA (Data Processing Agreement, umowa powierzenia przetwarzania danych); VLAN (Virtual Local Area Network, wirtualna sieć lokalna).
Pięć Osi Ishikawy w Cyberbezpieczeństwie 1. Ludzie • Podatność phishing • Zmęczenie i pośpiech • Brak szkoleń 2. Technologia • Luki Zero-Day / CVE • Błędy konfiguracji • Brak MFA i patcha 3. Procesy • Brak procedur SOP • Zły change management • Brak audytu backupu 4. Polityki (Governance) • Brak akceptacji ryzyka • Martwe procedury • Brak wsparcia Zarządu 5. Łańcuch Dostaw • Podwykonawcy bez MFA • Brak klauzul w umowach • Zależność chmurowa Integracja z normą ISO/IEC 27002:2022 Kategorie Ishikawy odpowiadają 4 grupom zabezpieczeń normy: organizacyjnym, osobowym, fizycznym i technicznym.
16/55
Diagram Ishikawy - przykład: kompromitacja serwera produkcyjnego
Cel slajdu: Przedstawienie praktycznego, rozbudowanego diagramu rybiej ości dla incydentu przejęcia kontroli nad kluczowym serwerem aplikacji.

Pełne studium przypadku na diagramie Ishikawy

Scenariusz: Zewnętrzny intruz przejął pełną kontrolę (uprawnienia root) nad głównym serwerem aplikacji webowej e-commerce i zainstalował moduł podsłuchujący transakcje. Oficjalne wpisy podatności prowadzi NIST NVD (CVE-2021-44228 Log4j), a standardy obrony definiuje OWASP Top 10 Web Application Security Risks (materiał w jęz. angielskim – brak polskiego odpowiednika; polskie omówienie: CyberAcademy.pl – OWASP Top 10 dla programistów).

  • Gałąź Ludzie: Programiści zignorowali ostrzeżenie o podatności biblioteki w kodzie; administrator nie zmienił domyślnego portu SSH; brak weryfikacji tożsamości przy zmianie klucza.
  • Gałąź Technologia: Przestarzała wersja systemu operacyjnego (brak łatek od 14 miesięcy); brak agenta EDR na serwerze Linux; podatność Log4j (CVE-2021-44228) w aplikacji.
  • Gałąź Procesy: Brak cyklicznego skanowania podatności; brak procedury testów bezpieczeństwa kodu przed wdrożeniem produkcyjnym (brak SAST/DAST).
  • Gałąź Polityki: Polityka zarządzania łatkami dopuszczała opóźnienie aktualizacji serwerów produkcyjnych „do odwołania” z obawy przed zakłóceniem sprzedaży.
  • Wnioski RCA: Kompromitacja nie była „pechem”, lecz logiczną konsekwencją zaniechań we wszystkich pięciu domenach zarządzania.
Testy statyczne i dynamiczne (SAST / DAST): Zautomatyzowane metody badania bezpieczeństwa oprogramowania: SAST (Static Application Security Testing - analiza kodu źródłowego bez jego uruchamiania) oraz DAST (Dynamic Application Security Testing - badanie działającej aplikacji z zewnątrz). Skróty i pojęcia: CVE i NVD (bazy podatności); HTTP (Hypertext Transfer Protocol); SSH (Secure Shell, szyfrowany dostęp zdalny).
Ishikawa: Kompromitacja Serwera WWW ROOT NA SERWERZE LUDZIE • Zignorowanie alertu CVE • Domyślny port SSH TECHNOLOGIA • Luka Log4j niezałatana • Brak agenta EDR Linux PROCESY • Brak testów SAST/DAST • Brak skanera Nessus POLITYKI • Wyłączenie aktualizacji • „Wygoda ponad security” Wniosek: Napastnik wykorzystał splot luki technicznej (Log4j) i zaniechania procesowego.
17/55
Diagram Ishikawy - przykład: wyciek danych ze środowiska chmurowego
Cel slajdu: Przedstawienie praktycznego zastosowania diagramu Ishikawy do analizy incydentu wycieku danych z publicznego zasobnika chmurowego (Cloud Storage Leak).

Wielowymiarowa analiza incydentu w chmurze

Scenariusz: Dziennikarze śledczy ujawniają, że kopie dokumentów tożsamości klientów firmy ubezpieczeniowej znajdowały się w publicznie dostępnym zasobniku chmurowym AWS S3 / Azure Blob bez hasła. Model podziału odpowiedzialności definiuje NIST SP 800-145 (Cloud Computing) oraz macierz kontrolna Cloud Security Alliance (CSA CCM).

  • Gałąź Ludzie: Brak certyfikowanych architektów cloud security; przeświadczenie programistów, że zasobnik chmurowy jest „domyślnie prywatny”.
  • Gałąź Technologia: Brak wdrożenia polityki „Block Public Access” na poziomie całego konta chmurowego; brak szyfrowania danych po stronie serwera (SSE-KMS).
  • Gałąź Procesy: Brak automatycznych audytów konfiguracji (brak narzędzi CSPM - Cloud Security Posture Management); brak weryfikacji zasobów przy oddawaniu sprintu programistycznego.
  • Gałąź Polityki: Polityka bezpieczeństwa nie uwzględniała specyfiki chmury (skupiała się wyłącznie na tradycyjnej serwerowni on-premise); brak wdrożonych procedur podziału odpowiedzialności (Shared Responsibility).
  • Wnioski RCA: Firma dokonała „szybkiej migracji do chmury” (Lift and Shift) bez przeszkolenia kadr i bez aktualizacji procedur audytowych.
Cloud Security Posture Management (CSPM): Klasa zautomatyzowanych narzędzi bezpieczeństwa służących do ciągłego monitorowania, audytu i wykrywania błędów konfiguracyjnych oraz niezgodności z normami w środowiskach chmury obliczeniowej. Skróty i pojęcia: SSE-KMS (Server-Side Encryption with Key Management Service, szyfrowanie po stronie serwera z KMS); IAM (Identity and Access Management, zarządzanie tożsamością i dostępem); Lift and Shift (szybka migracja bez refaktoryzacji), on-premise (serwerownia własna).
Ishikawa: Wyciek z Zasobnika Chmurowego OTWARTY BUCKET S3 KADRY • Brak szkolenia AWS • Mit „chmura sama chroni” TECHNOLOGIA • Brak Block Public Access • Brak narzędzia CSPM PROCESY • Brak audytu wdrożeń • Szybki sprint bez testu POLITYKI • Brak polityki chmurowej • Przeterminowany SZBI Shared Responsibility Model: Dostawca chmury odpowiada ZA chmurę, klient W chmurze!
18/55
Łączenie metod analitycznych: Diagram Ishikawy i technika 5 Why
Cel slajdu: Przedstawienie synergii pomiędzy diagramem Ishikawy a metodą 5 Why jako kompletnej metodyki analizy przyczyn źródłowych.

Najwyższa skuteczność dochodzenia dzięki połączeniu narzędzi

Samodzielny diagram Ishikawy identyfikuje obszary, ale może zatrzymać się na przyczynach powierzchownych. Samodzielna metoda 5 Why bywa zbyt wąska. Ich połączenie tworzy najpotężniejszą metodykę dochodzeniową powiązaną z klauzulą 10.2 normy ISO/IEC 27001:2022 (Działania korygujące CAPA) oraz praktyką inżynierską Google SRE Workbook (Postmortem Analysis).

  • Faza 1: Rozpięcie wachlarza (Diagram Ishikawy): Identyfikacja wszystkich możliwych hipotez i gałęzi przyczynowych we wszystkich domenach (Ludzie, Technologia, Procesy, Polityki, Dostawcy).
  • Faza 2: Weryfikacja faktograficzna: Odrzucenie hipotez sprzecznych z logami i dowodami cyfrowymi, pozostawienie gałęzi potwierdzonych materiałem dowodowym.
  • Faza 3: Pogłębienie wertykalne (5 Why na każdej gałęzi): Dla każdej potwierdzonej gałęzi zadajemy pięciokrotnie pytanie 'Dlaczego?', schodząc w głąb do luk organizacyjnych i proceduralnych.
  • Faza 4: Synteza i plan działań korygujących (CAPA): Powiązanie przyczyn źródłowych ze wszystkich gałęzi i sformułowanie całościowego planu naprawczego (Corrective and Preventive Actions - CAPA).
Plan CAPA (Corrective and Preventive Actions): Formalny plan działań korygujących (usuwających zaistniałą niezgodność) oraz zapobiegawczych (eliminujących ryzyko pojawienia się potencjalnych niezgodności w przyszłości). Skróty i pojęcia: SRE (Site Reliability Engineering, metodyka Google: SRE Workbook, Postmortem Analysis); ISO/IEC 27001 klauzula 10.2 (doskonalenie i działania korygujące).
Synergia: Ishikawa (Szerokość) + 5 Why (Głębokość) Krok 1: Ishikawa (Horyzontalnie) • Szerokie spojrzenie na problem • Identyfikacja 5 domen ryzyka • Praca warsztatowa zespołu Wynik: Mapa potencjalnych przyczyn Krok 2: 5 Why (Wertykalnie) • Pogłębienie wybranej ości • Drążenie: Dlaczego? x 5 • Zejście do poziomu procedur Wynik: Rzeczywista przyczyna źródłowa Krok 3: Opracowanie Zintegrowanego Planu CAPA • Każda zidentyfikowana przyczyna źródłowa otrzymuje konkretne zadanie naprawcze • Do każdego zadania przypisany jest jednoosobowy właściciel biznesowy (Owner) i data SLA • Plan CAPA podlega formalnemu zatwierdzeniu przez Komitet Bezpieczeństwa i Zarząd • Wykonanie planu jest weryfikowane podczas kolejnego audytu wewnętrznego ISO/IEC 27001
19/55
Inżynierskie metody analizy: Drzewo Błędów (Fault Tree Analysis - FTA)
Cel slajdu: Przedstawienie metody dedukcyjnej analizy drzewa błędów (FTA) z wykorzystaniem bramek logicznych AND oraz OR.

Matematyczno-logiczna dekompozycja awarii systemowych

W złożonych systemach infrastruktury krytycznej (energetyka, bankowość) stosuje się zaawansowaną metodę Fault Tree Analysis (FTA) opisaną w normie IEC 61025:2006 (Fault tree analysis / PN-EN 61025) oraz wytycznych oceny ryzyka NIST SP 800-30 Rev. 1 (Risk Assessment Guide).

  • Podejście dedukcyjne (Top-Down): Zaczynamy od zdarzenia szczytowego (Top Event - np. „Całkowity paraliż sieci transakcyjnej”) i schodzimy w dół, badając jakie kombinacje awarii składowych doprowadziły do tego stanu.
  • Bramka logiczna AND (I): Zdarzenie wyższego rzędu następuje TYLKO wtedy, gdy zaistnieją jednocześnie WSZYSTKIE zdarzenia wejściowe (np. atak DDoS ORAZ awaria zapasowego łącza światłowodowego).
  • Bramka logiczna OR (lub): Zdarzenie wyższego rzędu następuje, gdy zaistnieje CO NAJMNIEJ JEDNO ze zdarzeń wejściowych (np. kradzież hasła LUB luka Zero-Day w usłudze VPN).
  • Zastosowanie w cyberbezpieczeństwie: Umożliwia wyznaczenie tzw. minimalnych przekrojów awarii (Minimal Cut Sets) - najmniejszych zestawów podatności, których zmaterializowanie przełamie obronę.
Fault Tree Analysis (FTA - analiza drzewa błędów): Dedukcyjna, graficzna i matematyczna metoda analizy niezawodności i bezpieczeństwa systemów, polegająca na dekompozycji niepożądanego zdarzenia szczytowego (Top Event) na ciągi zdarzeń elementarnych za pomocą bramek logicznych (AND, OR). Skróty i pojęcia: Top Event (zdarzenie szczytowe), bramki AND/OR (koniunkcja i alternatywa logiczna); SPOF (Single Point of Failure, pojedynczy punkt awarii); VPN (wirtualna sieć prywatna); Zero-Day (podatność dnia zerowego, nieznana producentowi: vulnerability, słownik NIST). Norma IEC 61025 i publikacja NIST SP 800-30 przywołane w treści dostępne są w jęz. angielskim.
Model Drzewa Błędów FTA (Bramki AND / OR) TOP EVENT: Wyciek Bazy AND Dostęp do Sieci Brak Szyfrowania Bazy OR Phishing VPN Luka RDP Logika ochrony Defense in Depth • Bramka AND wymusza podwójną obronę • Nawet przy przełamaniu bramki OR (wejście)... • ...szyfrowanie bazy blokuje wyciek!
20/55
Priorytetyzacja przyczyn incydentów - zasada Pareto (80/20)
Cel slajdu: Przedstawienie metody analizy Pareto w celu wyznaczenia kluczowych przyczyn generujących największą liczbę incydentów i optymalizacji budżetu obronnego.

Kierowanie zasobów na 20% najbardziej krytycznych słabości

Organizacja nie ma nieskończonego budżetu ani zasobów kadrowych, aby załatać wszystkie teoretyczne podatności. Analiza Pareto pozwala wskazać kilka przyczyn generujących większość zdarzeń, a nie jest uniwersalną regułą 80/20. Katalog podstawowych zabezpieczeń porządkowych, które warto wdrożyć w pierwszej kolejności, to CIS Critical Security Controls v8 oraz rocznymi raportami zagrożeń CERT Polska – Raport roczny 2024.

  • Zasada 80/20 Vilfredo Pareto: W odniesieniu do cyberbezpieczeństwa reguła 80/20 służy jako heurystyka priorytetyzacji: w większości analizowanych zbiorów zdarzeń nieliczne powtarzające się przyczyny (np. brak MFA, słabe hasła, brak łatek) odpowiadają za istotną część incydentów. Konkretny udział procentowy zależy od badanej organizacji i okresu, dlatego nie należy traktować stosunku 80/20 jako uniwersalnej reguły empirycznej.
  • Wykres Pareto (Pareto Chart): Połączenie wykresu słupkowego (częstość występowania danej przyczyny) z krzywą skumulowaną (procent łączny).
  • Wskazanie priorytetów inwestycyjnych: Zamiast kupować drogie, egzotyczne systemy ochronne, analiza Pareto wskazuje konieczność wdrożenia podstawowej higieny cybernetycznej (Cyber Hygiene).
  • Zgodność z zaleceniami ENISA i CERT Polska: Raporty CERT Polska i ENISA wskazują, że uwierzytelnianie wieloskładnikowe (MFA) oraz regularne łatanie podatności eliminują największą część wektorów ataków masowych.
Analiza Pareto (zasada 80/20): Technika decyzyjna oparta na regule, że większość skutków (80%) wynika z niewielkiej liczby przyczyn (20%), służąca do optymalnej alokacji zasobów bezpieczeństwa. Skróty i pojęcia: Cyber Hygiene (higiena cybernetyczna, podstawowe zabezpieczenia porządkowe), CIS Critical Security Controls v8 (katalog zabezpieczeń priorytetowych), heurystyka (uproszczona reguła decyzyjna, tu reguła 80/20 Pareto).
Wykres Pareto w Analizie Przyczyn Incydentów 52% Brak MFA 28% Brak łatki 11% Słabe hasło 6% Luki WWW 3% Inne Skumulowane: 80% Wniosek strategiczny: Wdrożenie MFA i patch managementu rozwiązuje 80% problemów!
21/55
Wskaźniki kompromitacji (IoC) i korelacja śladów ataku
Cel slajdu: Przedstawienie typologii wskaźników kompromitacji (IoC) oraz ich roli w dochodzeniu powłamaniowym i wymianie informacji z CSIRT.

Cyfrowe odciski palców sprawcy incydentu

Podczas penetracji systemów napastnik nieuchronnie pozostawia ślady techniczne. Taksonomię wskaźników i technik porządkują matryca MITRE ATT&CK Enterprise oraz międzynarodowy standard wymiany danych CTI OASIS STIX 2.1 Standard.

  • Atomowe IoC (Atomic Indicators): Pojedyncze, niezmienne dane: złośliwe adresy IP, nazwy domen Command and Control (C2), adresy e-mail nadawców phishingu.
  • Obliczone IoC (Computed Indicators): Kryptograficzne skróty plików (MD5, SHA-1, SHA-256) złośliwego oprogramowania i skryptów; weryfikacja CLI: sha256sum payload.bin.
  • Behawioralne IoC (Behavioral / TTP): Wzorce zachowań i procedury napastnika wg MITRE ATT&CK (np. specyficzna modyfikacja kluczy rejestru autostartu, wyczyszczenie logów komendą wevtutil cl); skanowanie regułami YARA: yara -s -r reguly.yar /mnt/forensic/pamiec.raw.
  • Piramida Bólu Davida Bianco (Pyramid of Pain): Koncepcja pokazująca trudność zmiany wskaźników dla przeciwnika: skrót pliku można zmienić w ułamku sekundy (zmiana trywialna), ale zmianę taktyki i zachowania TTP wymusić jest niezwykle trudno (ogromny ból dla atakującego).
Wskaźnik kompromitacji (IoC - Indicator of Compromise): Cyfrowy artefakt w sieci lub na urządzeniu końcowym (adres IP, skrót pliku, klucz rejestru, sygnatura sieciowa), wskazujący z wysokim prawdopodobieństwem na włamanie lub obecność złośliwego kodu. Skróty i pojęcia: IoC (słownik NIST, hasło Indicator of Compromise), C2 (Command and Control), MD5, SHA-1 i SHA-256 (kryptograficzne funkcje skrótu); YARA (język reguł wykrywania wzorców).
Piramida Bólu Napastnika (Pyramid of Pain - D. Bianco) TTP (Taktyki / MITRE) Najtrudniejsze! Narzędzia (Tools / Cobalt Strike) Nazwy Domenowe i Certyfikaty C2 Adresy IP i Porty Sieciowe Hashe Plików (MD5 / SHA-256) Banalne dla hakera Blokowanie samych hashy to za mało; system EDR musi wykrywać zachowania (TTP)!
22/55
Informatyka śledcza (Digital Forensics) i wymogi procesowe
Cel slajdu: Przedstawienie wymogów formalno-prawnych dopuszczalności dowodów elektronicznych w postępowaniu karnym i cywilnym przed polskim sądem.

Kiedy analiza incydentu trafia na salę sądową

Wyniki analizy powłamaniowej często stanowią podstawę zawiadomienia o przestępstwie z art. 267-269b Kodeksu karnego (Dz.U. 1997 nr 88 poz. 553 – Kodeks karny) oraz śledztw prowadzonych przez Centralne Biuro Zwalczania Cyberprzestępczości (CBZC). Dowody muszą spełniać rygorystyczne normy procesowe.

Kopia binarna (ang. forensic image / bit-stream image): Dokładna, posektorowa kopia fizycznego nośnika danych (włącznie z obszarami wolnymi, skasowanymi plikami i partycjami ukrytymi), wykonana z gwarancją niezmienności oryginału. Skróty i pojęcia: KK (Kodeks karny); KPC (Kodeks postępowania cywilnego); VSS (Volume Shadow Copy Service, kopie woluminów w tle).
Standard Postępowania z Dowodem Sądowym (ISO/IEC 27037) 1. Oryginał Nośnika • Sprzętowy bloker zapisu • Plomba i depozyt • Protokół zatrzymania ZAKAZ BADAŃ NA ŻYWO! 2. Kopia Bit-by-Bit • Obraz RAW / E01 • Suma SHA-256 oryginału • Suma SHA-256 kopii Identyczność kryptograficzna 3. Badanie Kopii • Autopsy / EnCase • Odzyskanie plików • Analiza rejestrów Raport biegłego sądowego Wymogi formalne polskiego Kodeksu postępowania karnego • Zgodnie z art. 228 KPK zabezpieczenie urządzeń wymaga sporządzenia protokołu i spisu rzeczy • Brak wyliczenia sumy kontrolnej w chwili zabezpieczenia otwiera obronie drogę do podważenia dowodu • Wszelkie narzędzia forensyczne muszą być powszechnie uznane w środowisku naukowym (test Dauberta) • Prawidłowo zabezpieczony materiał dowodowy umożliwia dochodzenie odszkodowań od sprawców (art. 415 KC)
23/55
Kategoryzacja skutków incydentów bezpieczeństwa informacji
Cel slajdu: Przedstawienie wielowymiarowej taksonomii skutków incydentów z podziałem na skutki bezpośrednie i pośrednie, krótko- i długoterminowe oraz materialne i niematerialne.

Jak mierzyć rzeczywiste straty organizacji?

Wycena skutków incydentu nie może ograniczać się wyłącznie do kosztu wymiany dysków czy zapłaty za godziny nadliczbowe informatyków. Prawdziwe straty mają charakter wielowymiarowy i rozciągają się na wiele miesięcy. Taksonomię kategorii i dotkliwości szkód definiuje norma ISO/IEC 27035-1:2023 oraz unijna klasyfikacja ENISA Reference Incident Classification Taxonomy.

  • Skutki bezpośrednie (Direct Impact): Natychmiastowe straty fizyczne i finansowe: zniszczony sprzęt, koszty zewnętrznej firmy forensycznej, bezpośrednia kradzież środków z konta.
  • Skutki pośrednie (Indirect Impact): Konsekwencje wtórne: spadek produktywności pracowników, kary umowne za niedotrzymanie terminów dostaw, utrata marży ze sprzedaży.
  • Skutki krótkoterminowe vs długoterminowe: Krótkoterminowe to przestoje podczas trwania ataku (dni); długoterminowe to utrata reputacji, odpływ klientów do konkurencji i wzrost składek ubezpieczeniowych (lata).
  • Skutki materialne vs niematerialne: Materialne to konkretne kwoty w bilansie księgowym; niematerialne to utrata zaufania społecznego, spadek morale personelu i utrata tajemnic przedsiębiorstwa.
Wpływ incydentu (ang. incident impact): Całokształt negatywnych konsekwencji natury finansowej, prawnej, operacyjnej i wizerunkowej poniesionych przez organizację oraz podmioty trzecie w wyniku naruszenia bezpieczeństwa informacji. Skróty i pojęcia: BCP (Business Continuity Plan, plan ciągłości działania), Direct i Indirect Impact (skutek bezpośredni i pośredni), ENISA (taksonomia incydentów przywołana w treści), ISO/IEC 27035-1 (zasady zarządzania incydentami).
Taksonomia Skutków Incydentu Bezpieczeństwa Skutki Bezpośrednie • Koszt ekspertów Incident Response • Koszt odtworzenia baz z kopii • Zakup nowych serwerów i dysków Widoczne na fakturach w ciągu 30 dni Skutki Pośrednie • Spadek wartości akcji na giełdzie • Odejście kluczowych klientów • Pozwy odszkodowawcze (art. 82 RODO) Straty rozłożone na lata Cztery Wymiary Wyceny Strat (BIA Framework) 1. Finansowy: Przestoje, utracony obrót, koszty odzyskiwania, utracone kontrakty 2. Prawny: Kary administracyjne UODO (RODO) i CSIRT (NIS2/KSC), koszty procesów cywilnych 3. Operacyjny: Paraliż łańcucha dostaw, brak możliwości fakturowania i wypłaty pensji 4. Reputacyjny: Utrata zaufania rynku, negatywne publikacje w mediach, kryzys marki
24/55
Skutki finansowe incydentów - koszty bezpośrednie i utracony biznes
Cel slajdu: Przedstawienie struktury kosztów incydentu cybernetycznego w oparciu o globalne analizy kosztowe (raport IBM Cost of a Data Breach Report).

Ekonomiczny bilans strat zmaterializowanego ryzyka

Według corocznego raportu IBM/Ponemon – Cost of a Data Breach Report 2026 oraz analiz ENISA Threat Landscape, średni całkowity koszt naruszenia bezpieczeństwa danych na świecie osiągnął w 2026 r. rekordowe 4,99 mln USD (wzrost o 12% rok do roku, wobec 4,44 mln USD w 2025 r.). Dwie kategorie kosztów – wykrycie i eskalacja oraz utracony biznes – odpowiadały za 63% wszystkich wydatków.

  • Koszty wykrycia i opanowania (Detection & Escalation): Opłacenie zewnętrznych zespołów śledczych (forensics), audyty kodu, usługi prawne, dyżury nadliczbowe inżynierów.
  • Koszty powiadomień (Notification Costs): Wysyłka imiennych pism poleconych lub SMS do tysięcy poszkodowanych klientów (art. 34 RODO), uruchomienie infolinii kryzysowej call-center.
  • Koszty utraconego biznesu (Lost Business Cost): Największa składowa strat: odpływ klientów (customer churn), spadek przychodów w okresie awarii, koszty pozyskania nowych kontraktów.
  • Koszty pokryzysowe (Ex-Post Response): Kary regulacyjne nakładane przez UODO i organy sektorowe, koszty darmowego monitorowania BIK dla poszkodowanych, wzrost stawek polis OC cybernetycznego.
Koszt utraconego biznesu (ang. lost business cost): Pośrednia strata finansowa wynikająca z przestoju operacyjnego, rezygnacji klientów z usług firmy, utraty przewagi konkurencyjnej oraz trudności w pozyskiwaniu nowych umów w następstwie ujawnienia incydentu. Skróty i pojęcia: BIK (Biuro Informacji Kredytowej, monitoring kredytowy); OC (ubezpieczenie odpowiedzialności cywilnej, tu polisa cyber); SMS (Short Message Service), call-center (infolinia kryzysowa), customer churn (odpływ klientów), lost business cost (koszt utraconego biznesu).
Struktura Kosztów Wycieku Danych (IBM Report) Utracony Biznes ~38% • Odpływ klientów • Przestoje sprzedaży • Utrata zaufania Detekcja i Śledztwo ~29% • Zewnętrzne IR • Informatyka śledcza • Audyty powłamaniowe Reakcja Pokryzysowa ~20% • Doradztwo prawne • Kary regulacyjne • Zastrzeganie PESEL Powiadomienia ~13% • Listy polecone • Bramki SMS / Call • Raporty do UODO Wpływ czasu detekcji na koszty incydentu • Incydenty zidentyfikowane i powstrzymane w czasie krótszym niż 200 dni kosztują o 30% mniej • Wdrożenie sztucznej inteligencji i automatyzacji w SOC (SOAR) obniża średni koszt wycieku o 1,93 mln USD • Obecność przetestowanego planu IR (Incident Response Plan) redukuje straty finansowe o kolejne 35% • Szybka reakcja to bezpośrednia oszczędność milionów złotych w budżecie firmy!
25/55
Skutki reputacyjne i wizerunkowe - kryzys zaufania marki
Cel slajdu: Przedstawienie mechanizmów rozprzestrzeniania się kryzysu wizerunkowego po incydencie oraz zasad skutecznej komunikacji publicznej.

Jak odbudować reputację po naruszeniu bezpieczeństwa?

Na reputację firma pracuje dekadami, a traci ją w ciągu jednego dnia. Wyciek danych klientów natychmiast trafia na pierwsze strony portali. Dobre praktyki komunikacji kryzysowej formułuje CERT Polska – wiedza.cert.pl: reagowanie na incydent oraz opracowania SANS Reading Room (Crisis Management in Cyber Incidents).

  • Zjawisko utraty zaufania klientów (Brand Damage): Klienci, których dane (PESEL, hasła, numery kart) wyciekły, czują się oszukani i zagrożeni kradzieżą tożsamości, co skutkuje masowym zamykaniem kont.
  • Reakcja rynku kapitałowego: Dla spółek giełdowych ujawnienie poważnego incydentu oznacza natychmiastowy spadek kursu akcji o kilka do kilkunastu procent oraz obniżenie ratingu wiarygodności kredytowej.
  • Zasada transparentności w PR kryzysowym: Próby zamiatania sprawy pod dywan kończą się katastrofą medialną. Dojrzała organizacja wychodzi z kryzysu obronną ręką, gdy komunikuje się szybko, uczciwie i oferuje realną pomoc poszkodowanym.
  • Współpraca z mediami: Wyznaczenie jednego oficjalnego rzecznika prasowego; ścisła koordynacja komunikatów PR z prawnikami i zespołem technicznym IR.
Kryzys reputacyjny w cyberbezpieczeństwie: Gwałtowny spadek zaufania interesariuszy (klientów, partnerów, inwestorów, regulatorów) do zdolności organizacji w zakresie ochrony powierzonych informacji poufnych i danych osobowych. Skróty i pojęcia: PR (Public Relations, komunikacja publiczna); IR (Incident Response, reagowanie na incydenty: słownik NIST); PESEL (identyfikator obywatela); FAQ (Frequently Asked Questions, odpowiedzi na częste pytania).
Dynamika Kryzysu Reputacyjnego po Wycieku Faza 1: Szok Medialny • Nagłówki w mediach • Panika wśród klientów • Przeciążenie infolinii Dni 1-3 po ujawnieniu Faza 2: Śledztwo Rynku • Pytania regulatorów • Spadek wyceny akcji • Presja partnerów B2B Tygodnie 1-4 Faza 3: Odbudowa Marki • Transparentny raport • Nowe inwestycje IT • Darmowy alert BIK Miesiące 2-12 Złota reguła komunikacji kryzysowej • Nigdy nie mów: „Nic się nie stało” ani „Dane są bezpieczne”, dopóki nie masz dowodów forensycznych • Kłamstwo ujawnione przez dziennikarzy niszczy firmę wielokrotnie mocniej niż sam incydent techniczny • Komunikat musi zawierać: Co się stało? Co zrobiliśmy? Co klient POWINIEN teraz zrobić (porady)? • Szybkie i transparentne powiadomienie buduje szacunek i ogranicza kary Prezesa UODO!
26/55
Skutki prawne i regulacyjne - sankcje RODO, NIS2 i odpowiedzialność karna
Cel slajdu: Przedstawienie konsekwencji prawnych incydentu: administracyjnych kar finansowych, odpowiedzialności cywilnej oraz odpowiedzialności karnej na gruncie prawa polskiego i UE.

Kary regulacyjne, pozwy odszkodowawcze i paragrafy karne

Incydent bezpieczeństwa informacji to nie tylko awaria techniczna, lecz zdarzenie o doniosłych skutkach prawnych. Reżim odpowiedzialności wyznacza unijne rozporządzenie RODO (art. 82-83), krajowa ustawa o KSC (Dz.U. 2026 poz. 252) oraz orzecznictwo Prezesa UODO.

  • Kary administracyjne Prezesa UODO (art. 83 RODO): Do 20 000 000 EUR lub do 4% całkowitego rocznego obrotu światowego przedsiębiorstwa za naruszenie zasad ochrony i niezgłoszenie wycieku.
  • Sankcje Dyrektywy NIS2 i polskiej ustawy o KSC: Dla podmiotów kluczowych: kary do 10 000 000 EUR lub 2% obrotu; dla podmiotów ważnych: do 7 000 000 EUR lub 1,4% obrotu za brak wdrożenia zarządzania ryzykiem.
  • Odpowiedzialność osobista członków zarządu: Możliwość nałożenia przez organy nadzorcze czasowego zakazu pełnienia funkcji kierowniczych wobec osób odpowiedzialnych za rażące zaniedbania w cyberbezpieczeństwie.
  • Odpowiedzialność cywilna (art. 82 RODO, art. 415 KC): Każda osoba, która poniosła szkodę majątkową lub niemajątkową (krzywdę z powodu lęku o utratę tożsamości), ma prawo żądać od administratora pełnego odszkodowania przed sądem cywilnym.
  • Kodeks karny (art. 267-269b KK): Ściganie karne sprawców ataków za nieuprawnione uzyskanie informacji, sabotaż komputerowy oraz niszczenie danych.
Odpowiedzialność odszkodowawcza za wyciek (art. 82 RODO): Prawo każdej osoby fizycznej, której dane zostały bezprawnie ujawnione lub utracone, do uzyskania odszkodowania od administratora za doznaną szkodę majątkową lub niemajątkową (krzywdę psychiczną). Skróty i pojęcia: KC (Kodeks cywilny), KK (Kodeks karny), UE (Unia Europejska), obrót światowy (całkowity roczny obrót przedsiębiorstwa, podstawa wymiaru kar RODO i NIS2), art. 82-83 RODO (odszkodowanie i kary administracyjne), art. 415 KC (odpowiedzialność deliktowa).
Reżimy Odpowiedzialności Prawnej za Incydent Kary RODO (UODO) Do 20 mln € lub 4% obrotu rocznego • Brak zgłoszenia w 72h • Brak zawiadomienia osób Kary NIS2 / KSC Do 10 mln € lub 2% obrotu rocznego • Brak wdrożenia SZBI • Zignorowanie CSIRT Pozwy Cywilne Art. 82 RODO Pozwy zbiorowe klientów • Zadośćuczynienie • Szkoda niemajątkowa Odpowiedzialność osobista i karna (KK / KSC) • Członkowie zarządów podmiotów kluczowych podlegają bezpośrednim sankcjom finansowym • Naruszenie tajemnicy przedsiębiorstwa (art. 11 uznk) to kara pozbawienia wolności do lat 2 • Włamanie i niszczenie danych (art. 267, 268a, 269 KK) - kary do 8 lat pozbawienia wolności • Sąd może orzec zakaz zajmowania określonych stanowisk zarządczych w spółkach prawa handlowego
27/55
Skutki operacyjne - paraliż procesów biznesowych i łańcucha dostaw
Cel slajdu: Przedstawienie wpływu incydentu na bieżącą działalność operacyjną przedsiębiorstwa, w tym zjawiska efektu domina w łańcuchu dostaw.

Gdy fabryki stają, a magazyny nie mogą wydać towaru

Najbardziej natychmiastowym i bolesnym skutkiem cyberataku jest paraliż procesów operacyjnych. W świecie zautomatyzowanej logistyki i produkcji zatrzymanie systemów IT oznacza całkowite zamrożenie biznesu. Standardy ciągłości działania określają norma ISO 22301:2019 (Security and resilience – Business continuity management systems – Requirements) oraz wytyczne ENISA Supply Chain Resilience.

  • Zatrzymanie ciągłości operacyjnej: Brak możliwości wystawiania faktur, obsługi zgłoszeń serwisowych, przyjęcia dostaw w magazynach wysokiego składowania (systemy WMS), wstrzymanie linii produkcyjnych.
  • Efekt domina w łańcuchu dostaw (Supply Chain Domino Effect): Przestój w jednej spółce produkującej komponenty blokuje montownie samochodów lub dostawy żywności do sieci handlowych w całym kraju.
  • Przymusowe przejście na procedury awaryjne (Paper-based fallbacks): Ręczne wypisywanie dokumentów WZ, brak wiedzy o stanach magazynowych, ogromny chaos operacyjny i drastyczny wzrost błędów ludzkich.
  • Koszty przestoju pracowników: Setki pracowników fizycznych i biurowych nie mogą wykonywać pracy z powodu zablokowanych komputerów i maszyn sterowanych numerycznie (CNC).
Przestój operacyjny (ang. operational outage): Okres, w którym procesy produkcyjne, usługowe lub logistyczne organizacji nie mogą być realizowane w całości lub w części z powodu niedostępności wspierającej infrastruktury teleinformatycznej. Skróty i pojęcia: WMS (Warehouse Management System, system magazynowy); HIS (Hospital Information System, system szpitalny, por. slajd 53); CNC (Computerized Numerical Control, sterowanie numeryczne); ISO (Międzynarodowa Organizacja Normalizacyjna).
Kaskada Paraliżu Operacyjnego w Firmie Awaria ERP Baza zaszyfrowana Magazyn WMS Brak wydań towaru Linia Produkcji Brak komponentów Klienci B2B Kary za opóźnienia Wymóg planowania awaryjnego (BCP) wg ISO 22301 • Organizacja musi posiadać opracowane procedury „manual fallbacks” dla każdego kluczowego procesu • Magazyn musi być w stanie wydać leki lub żywność na podstawie procedur papierowych • Brak przetestowanych procedur offline zamienia incydent techniczny w katastrofę humanitarną • Wskaźnik MTPD (Maximum Tolerable Period of Disruption) wyznacza absolutny limit przetrwania • Zgodnie z NIS2 odporność łańcucha dostaw jest tak samo ważna jak obrona własnego perymetru!
28/55
Metodyka Business Impact Analysis (BIA) - szczegóły analityczne
Cel slajdu: Przedstawienie procedury prowadzenia analizy wpływu na biznes (BIA) w powiązaniu z procesem zarządzania incydentami i normą ISO 22301.

Kwantyfikacja krytyczności procesów biznesowych

BIA (Business Impact Analysis) pozwala odpowiedzieć na fundamentalne pytanie: 'Które procesy biznesowe w firmie są najważniejsze i jak szybko musimy je przywrócić, aby firma nie zbankrutowała?'. Metodykę tę normalizuje standard ISO 22301:2019 (Ciągłość działania; kl. 8.2.2 Analiza BIA) oraz przewodnik NIST SP 800-34 Rev. 1 (Contingency Planning Guide).

  • Identyfikacja procesów biznesowych: Sporządzenie kompletnego katalogu procesów w organizacji (np. sprzedaż internetowa, logistyka, płace, obsługa reklamacji).
  • Ocena skutków przestoju w czasie: Badanie dynamiki wzrostu strat finansowych i prawnych po 1 godzinie, 4 godzinach, 24 godzinach, 3 dniach i 1 tygodniu niedostępności.
  • Mapowanie zależności technologicznych: Powiązanie każdego procesu biznesowego z aplikacjami, serwerami, bazami danych, łączami sieciowymi i personelem wspierającym.
  • Wyznaczenie wskaźników RTO, RPO i MTPD: Określenie krytycznych progów czasowych dla każdego systemu IT, stanowiących bezpośrednią wytyczną dla zespołów reagowania i Disaster Recovery.
Business Impact Analysis (BIA - analiza wpływu na biznes): Systematyczny proces identyfikacji i oceny potencjalnych skutków (finansowych, operacyjnych, prawnych), jakie zakłócenie krytycznych funkcji biznesowych wywoła w działalności organizacji. Skróty i pojęcia: MTPD (Maximum Tolerable Period of Disruption, maksymalny tolerowany czas przerwy); RTO (Recovery Time Objective) i RPO (Recovery Point Objective), NIST CSF 2.0 (ramy cyberbezpieczeństwa).
Proces Prowadzenia Analizy BIA (ISO 22301) Krok 1: Identyfikacja i klasyfikacja procesów biznesowych Właściciele biznesowi Krok 2: Oszacowanie strat w funkcji czasu przestoju (t) Straty PLN / godzina Krok 3: Wyznaczenie parametrów progowych RTO / RPO / MTPD SLA dla Disaster Recovery Krok 4: Mapowanie zależności systemowych (System Dependency Matrix) Serwery, bazy, sieci Wynik analizy BIA dla Incident Response Inżynierowie IR nie decydują o priorytetach odtwarzania według własnego uznania, lecz ściśle wg tabeli BIA!
29/55
BIA w praktyce - wyznaczanie wskaźników RTO i RPO
Cel slajdu: Przedstawienie zależności matematycznych i ekonomicznych pomiędzy parametrami RTO i RPO a kosztami wdrożenia infrastruktury wysokiej dostępności.

Krzywa optymalizacji kosztów ciągłości działania

Zarząd często stawia nierealistyczne żądania zerowych czasów przestoju. Rolą inżyniera jest wykazanie zależności opisanych w normie ISO 22301:2019 oraz przewodniku NIST SP 800-34 Rev. 1 (RTO and RPO Metrics).

  • Ekonomiczna krzywa optymalizacji BCP: Całkowity koszt incydentu składa się z dwóch przeciwstawnych funkcji: kosztu przestoju biznesu (rośnie w czasie) oraz kosztu zabezpieczeń IT i replikacji (maleje wraz z wydłużaniem RTO).
  • Punkt optimum ekonomicznego: Punkt przecięcia obu krzywych wyznacza optymalne wartości RTO i RPO uzasadnione ekonomicznie dla danego procesu.
  • Przykłady RTO/RPO w bankowości: System transakcji kartowych: RTO < 15 minut, RPO < 1 sekunda (replikacja synchroniczna w czasie rzeczywistym, dwa niezależne ośrodki Active-Active).
  • Przykłady RTO/RPO w systemach pomocniczych: System archiwum faktur: RTO do 48 godzin, RPO do 24 godzin (standardowy backup nocny, odtworzenie z repozytorium chmurowego).
Optimum ekonomiczne RTO/RPO: Punkt równowagi, w którym suma kosztów wdrożenia zabezpieczeń ciągłości działania oraz potencjalnych strat z tytułu przestoju i utraty danych osiąga najniższą możliwą wartość. Skróty i pojęcia: DRP (Disaster Recovery Plan, plan odtwarzania po katastrofie), HA (High Availability, wysoka dostępność), RTO/RPO (docelowy czas i punkt wznowienia), BCP (plan ciągłości działania), optimum ekonomiczne (punkt najniższego kosztu łącznego zabezpieczeń i strat).
Optymalizacja Kosztów: RTO / RPO vs Koszt Odtwarzania Czas odzyskiwania (RTO) → Koszt w PLN ↑ Koszt Zabezpieczeń IT Koszt Przestoju Biznesu OPTIMUM RTO Wymóg BIA: Znalezienie punktu równowagi między kosztami technologii a stratami z przestoju
30/55
Macierz wpływu incydentu - operacyjna kategoryzacja szkód
Cel slajdu: Przedstawienie narzędzia kategoryzacji szkód poincydentowych w oparciu o macierz typu incydentu i poziomu wpływu na triadę CIA.

Syntetyczna ocena dotkliwości naruszenia

Raportowanie do organów nadzorczych (UODO – Ocena naruszeń) oraz CSIRT poziomu krajowego (Ustawa o KSC, tekst jedn. Dz.U. 2026 poz. 20) wymaga jednoznacznego przypisania incydentu do poziomu dotkliwości: od pomijalnego po katastrofalny.

  • Poziom 1: Wpływ pomijalny (Insignificant): Brak zakłóceń procesów, brak wycieku poufnych danych, zablokowanie nieudanej próby ataku na poziomie firewalla.
  • Poziom 2: Wpływ niski (Minor): Krótki przestój pojedynczej usługi pomocniczej (do 30 min), brak wpływu na klientów, koszty naprawy poniżej 10 000 PLN.
  • Poziom 3: Wpływ umiarkowany (Moderate): Przestój kluczowego systemu w granicach dopuszczalnego RTO, wyciek danych niebędących danymi wrażliwymi, zawiadomienie UODO bez konieczności powiadamiania osób.
  • Poziom 4: Wpływ poważny (Major): Przekroczenie RTO, wyciek danych wrażliwych (art. 9 RODO), konieczność zawiadomienia osób fizycznych (art. 34 RODO), kwalifikacja jako incydent poważny wg NIS2.
  • Poziom 5: Wpływ katastrofalny (Catastrophic): Długotrwały paraliż całej infrastruktury, utrata kluczowych baz danych bez możliwości odtworzenia, zagrożenie bytu firmy, kary administracyjne rzędu milionów EUR.
Macierz wpływu incydentu: Znormalizowana tabela analityczna przypisująca obserwowanym skutkom incydentu zdefiniowane kategorie dotkliwości w celu ustalenia właściwego trybu raportowania zewnętrznego. Skróty i pojęcia: CIA (Confidentiality, Integrity, Availability, poufność, integralność, dostępność); PLN (złoty polski); EUR (euro); KSC (Krajowy System Cyberbezpieczeństwa).
Matryca Poziomów Wpływu Incydentu Niski (Minor): Przestój < 30 min • Brak wycieku • Koszt < 10k PLN Średni (Moderate): W granicach RTO • Zgłoszenie UODO 72h • Brak powiadomień osób Poważny (Major): Przekroczenie RTO • Incydent Poważny KSC / NIS2 Wyciek PESEL / haseł • Obowiązek powiadomienia poszkodowanych osób (art. 34 RODO) Katastrofalny (Catastrophic): Paraliż organizacji > 7 dni Nieodwracalna utrata baz • Ryzyko upadłości • Maksymalne kary regulacyjne Znaczenie prawne kwalifikacji poziomu wpływu Poziom „Poważny” wymusza natychmiastowe zawiadomienie CSIRT w 24h oraz UODO w 72h. Błędne zaniżenie poziomu do „Średniego” skutkuje karami za brak powiadomienia osób poszkodowanych!
31/55
Metodyka kalkulacji kosztów incydentu - model analityczny
Cel slajdu: Przedstawienie algorytmu precyzyjnego wyliczania całkowitego kosztu poniesionego przez organizację w następstwie incydentu.

Finansowe rozliczenie incydentu dla audytorów i ubezpieczyciela

Do celów ubezpieczeniowych, postępowań odszkodowawczych oraz audytów zarządczych konieczne jest przedstawienie spójnego arkusza kosztów (Cost Breakdown Sheet) opartego na metodyce IBM Security (Data Breach Cost Framework) oraz analizach ENISA Threat Landscape.

  • Kategoria K1: Koszty personelu własnego: Kalkulacja stawek godzinowych i nadgodzin administratorów IT, programistów, działu prawnego i zarządu zaangażowanych w gaszenie pożaru.
  • Kategoria K2: Koszty usług zewnętrznych: Faktury od firm informatyki śledczej (Incident Response Retainer), audytorów, kancelarii prawnych, agencji PR kryzysowego.
  • Kategoria K3: Koszty sprzętu i licencji: Zakup nowych dysków, wdrożenie awaryjnych instancji chmurowych, przyspieszony zakup licencji EDR/MFA.
  • Kategoria K4: Utracone przychody i kary umowne: Wycena niezrealizowanych zamówień, utraconego ruchu e-commerce oraz kar nałożonych przez kontrahentów B2B za brak dostępności usług.
  • Kategoria K5: Kary administracyjne i rezerwy prawne: Wysokość kar UODO/KSC oraz rezerwy finansowe utworzone na poczet przyszłych pozwów od poszkodowanych osób.
Całkowity koszt incydentu (Total Cost of Incident - TCI): Suma wszystkich udokumentowanych wydatków bezpośrednich, kosztów utraconych korzyści, kar administracyjnych oraz rezerw na roszczenia odszkodowawcze wywołane incydentem: TCI = K1 + K2 + K3 + K4 + K5. Skróty i pojęcia: DFIR (Digital Forensics and Incident Response, informatyka śledcza i reagowanie); TCI (Total Cost of Incident, całkowity koszt incydentu).
Formuła Całkowitego Kosztu Incydentu (TCI) K1: Kadry Nadgodziny IT K2: Eksperci Forensics/Prawnik K3: Sprzęt Nowe zasoby IT K4: Przestój Utrata obrotu K5: Kary UODO / Pozwy TCI = K1 + K2 + K3 + K4 + K5 (Całkowity Koszt Incydentu) Wykorzystanie kalkulacji TCI w ubezpieczeniach cybernetycznych • Towarzystwa ubezpieczeniowe wymagają szczegółowego bilansu TCI przed wypłatą odszkodowania • Brak profesjonalnego raportu forensycznego uniemożliwia udowodnienie związku przyczynowego strat • Większość polis cyber-insurance wyłącza pokrycie kar administracyjnych nakładanych przez UODO • Wskaźnik TCI stanowi ostateczny bilans straty finansowej prezentowany na posiedzeniu Rady Nadzorczej
32/55
Wpływ na osoby, których dane dotyczą - ocena ryzyka wg RODO
Cel slajdu: Przedstawienie kryteriów oceny ryzyka naruszenia praw i wolności osób fizycznych wg motywów 85-87 RODO w celu weryfikacji przesłanki z art. 34 RODO.

Kiedy wyciek danych wymaga powiadomienia obywateli?

Z punktu widzenia RODO kluczowa jest nie strata samej firmy, lecz zagrożenie dla praw i wolności osób poszkodowanych. Wytyczne interpretacyjne publikuje UODO – Ocena ryzyka naruszenia praw i wolności oraz EDPB Guidelines 01/2021 on Data Breach Notification (materiał w jęz. angielskim; wersja polska: UODO – Wytyczne 9/2022 dotyczące zgłaszania naruszeń (PL)).

  • Zagrożenia dla osób fizycznych (motyw 85 RODO): Kradzież tożsamości (wyłudzenie kredytów na PESEL), straty finansowe, dyskryminacja, utrata poufności danych objętych tajemnicą zawodową, uszczerbek na dobrej sławie.
  • Kiedy zachodzi „wysokie ryzyko” (High Risk)?: Wyciek szczególnych kategorii danych (art. 9: dane medyczne, biometria), wyciek numeru PESEL w połączeniu z imieniem, nazwiskiem i serią dowodu osobistego, wyciek haseł i loginów.
  • Obowiązek z art. 34 RODO (Zawiadomienie osób): Administrator musi zawiadomić osoby poszkodowane jasnym i prostym językiem, opisując charakter naruszenia oraz zalecane środki ochronne, np. skorzystanie z rządowej usługi Zastrzeż numer PESEL w serwisie Gov.pl.
  • Zwolnienia z obowiązku powiadamiania: Wyciekłe dane były skutecznie zaszyfrowane kluczem, którego sprawca nie uzyskał, lub administrator podjął natychmiastowe środki eliminujące wysokie ryzyko.
Wysokie ryzyko naruszenia praw lub wolności (RODO): Sytuacja, w której naruszenie bezpieczeństwa danych osobowych może bezpośrednio prowadzić do szkody fizycznej, majątkowej lub niemajątkowej dla osoby fizycznej (np. kradzież tożsamości, oszustwo finansowe, utrata reputacji). Skróty i pojęcia: EDPB (Europejska Rada Ochrony Danych); PESEL (identyfikator), art. 9 RODO (szczególne kategorie danych), art. 33-34 RODO (zgłoszenie do UODO i zawiadomienie osób), UODO (organ nadzorczy).
Ocena Ryzyka dla Osób Fizycznych wg RODO Niskie Ryzyko • Dane zaszyfrowane • Imię i nazwisko bez ID • Szybkie odzyskanie Tylko rejestr naruszeń Średnie Ryzyko • Adres e-mail i telefon • Historia zakupów • Ryzyko spamu Zgłoszenie UODO (72h) Wysokie Ryzyko • PESEL + Seria dowodu • Dane medyczne / krew • Dane kart / bankowość POWIADOMIENIE OSÓB! Wymogi formalne zawiadomienia z art. 34 RODO • Komunikat musi być sformułowany prostym, zrozumiałym językiem (bez żargonu technicznego) • Należy wskazać dane kontaktowe Inspektora Ochrony Danych (IOD) oraz zalecane środki zaradcze • W przypadku wycieku PESEL rekomenduje się bezpłatne zastrzeżenie numeru PESEL w aplikacji mObywatel • Zaniechanie powiadomienia osób przy wysokim ryzyku to najczęstsza przyczyna milionowych kar UODO!
33/55
Analiza scenariuszowa skutków (Scenario-based Impact Analysis)
Cel slajdu: Przedstawienie techniki modelowania skutków incydentu w trzech wariantach: optymistycznym, realistycznym i pesymistycznym na potrzeby sztabu kryzysowego.

Planowanie reakcji na niepewność w trakcie kryzysu

W pierwszych godzinach po wykryciu ataku pełny zakres szkód jest nieznany. Sztab kryzysowy musi podejmować decyzje operacyjne w oparciu o symulacje i analizę scenariuszową wg przewodnika NIST SP 800-84 (IT Testing and Exercise Programs) oraz pakietów ćwiczeń CISA Tabletop Exercise Packages (CTEP).

  • Scenariusz optymistyczny (Best-Case): Atak został powstrzymany w fazie dostarczenia lub wczesnej eksploitacji; brak wycieku danych; odtworzenie systemów w ramach RTO; brak konieczności powiadamiania osób trzecich.
  • Scenariusz realistyczny (Most-Likely): Skompromitowano kilka serwerów; doszło do eksfiltracji ograniczonej liczby rekordów; przestój wynosi 24-48 godzin; zgłoszenie do UODO i CSIRT; koszty w granicach budżetu rezerwowego.
  • Scenariusz pesymistyczny (Worst-Case): Całkowity paraliż sieci (Blackout); usunięcie lub zaszyfrowanie kopii zapasowych; publiczny wyciek bazy klientów w darknecie; maksymalne kary regulacyjne; lawina pozwów cywilnych.
  • Zastosowanie w zarządzaniu kryzysowym: Pozwala zarządowi na wcześniejsze przygotowanie rezerw kapitałowych, uruchomienie umów z kancelariami prawnymi i przygotowanie wariantowych komunikatów PR.
Analiza scenariuszowa incydentu: Metoda analityczna polegająca na symulowaniu różnych trajektorii rozwoju skutków zdarzenia kryzysowego (od wariantu optymistycznego do katastrofalnego) w celu przygotowania adekwatnych środków zaradczych. Skróty i pojęcia: AD (Active Directory, usługa katalogowa); RTO (docelowy czas wznowienia), EDR (telemetria punktu końcowego).
Trzy Scenariusze Rozwoju Incydentu 1. Optymistyczny • Izolacja w 30 min • Brak wycieku baz • Brak kar finansowych Koszt: < 50 tys. PLN 2. Realistyczny • Przestój 48 godzin • Wyciek części danych • Raport UODO i CSIRT Koszt: ~500 tys. PLN 3. Pesymistyczny • Przestój 3 tygodnie • Utrata kopii zapasowych • Maksymalne kary UODO Koszt: > 5 mln PLN Zarządzanie rezerwami kapitałowymi • Przygotowanie na wariant pesymistyczny pozwala zabezpieczyć płynność finansową spółki • Sztab kryzysowy przygotowuje z wyprzedzeniem oświadczenia medialne na wypadek wycieku baz • Sprawdzenie limitów odpowiedzialności (sublimitów) w zawartej polisie cyber-insurance • Scenariusze podlegają regularnemu testowaniu podczas symulacji tabletop dla zarządu
34/55
Studium przypadku 1: Atak ransomware w firmie produkcyjnej
Cel slajdu: Przedstawienie całościowej dekompozycji przyczyn i skutków w rzeczywistym ataku ransomware na przedsiębiorstwo produkcyjne.

Kompleksowa analiza: od wektora do bilansu strat

Scenariusz: Średniej wielkości zakład produkcyjny zatrudniający 400 osób został sparaliżowany przez grupę ransomware BlackCat. Zaszyfrowano 15 serwerów i 80 stacji roboczych. Oficjalne raporty z takich zdarzeń publikuje CERT Polska – Raport roczny 2024 oraz baza wiedzy CISA #StopRansomware Playbooks.

  • Przyczyna bezpośrednia: Pracownik pobrał złośliwy plik z fałszywym zamówieniem od klienta. Luka w niespatchowanym serwerze VPN umożliwiła intruzowi ruch boczny.
  • Przyczyny źródłowe (RCA): Brak segmentacji sieci pomiędzy biurem a halą produkcyjną; brak procedury weryfikacji dostawców; brak kopii offline (kopie NAS zostały zaszyfrowane).
  • Skutki operacyjne: 10 dni całkowitego zatrzymania linii produkcyjnej; utrata danych z 3 dni zamówień (RPO = 72h zamiast planowanych 4h); przestój 400 pracowników.
  • Skutki finansowe: Łączny koszt TCI: 2 400 000 PLN (kary umowne B2B: 1,2 mln PLN, odtworzenie IT: 400 tys. PLN, utracona marża: 800 tys. PLN). Okup nie został zapłacony.
Ransomware w środowisku przemysłowym (OT): Atak złośliwego oprogramowania szyfrującego, który poza tradycyjnymi serwerami biurowymi paraliżuje stacje nadzoru SCADA i serwery sterujące procesami produkcyjnymi. Skróty i pojęcia: OT (Operational Technology, technologie operacyjne); PLC (Programmable Logic Controller, sterownik programowalny); SCADA (Supervisory Control and Data Acquisition, nadzór i sterowanie); NAS (Network Attached Storage, sieciowa macierz dyskowa); FIDO2 (standard kluczy sprzętowych); TCI (całkowity koszt incydentu).
Bilans Case Study 1: Ransomware w Fabryce Analiza Przyczyn (RCA) • Wektor: Phishing + luka VPN • Płaska sieć: brak VLAN dla OT • Backup podłączony na stałe Źródło: Brak ładu i polityki patchingu Bilans Skutków (BIA) • Przestój: 10 dni roboczych • Kary B2B: 1 200 000 PLN • Koszt IR & IT: 400 000 PLN Suma strat: 2,4 mln PLN Wdrożone działania naprawcze (CAPA) 1. Pełna mikrosegmentacja sieci przemysłowej OT od sieci biurowej za pomocą NGFW 2. Wdrożenie repozytorium kopii zapasowych w trybie Immutable (WORM) w chmurze 3. Bezwzględny wymóg kluczy sprzętowych FIDO2 dla każdego logowania do VPN Koszt zabezpieczeń: 180 tys. PLN (mniej niż 8% poniesionych strat!)
35/55
Studium przypadku 2: Wyciek bazy klientów sklepu internetowego
Cel slajdu: Przedstawienie analizy przyczyn i skutków kradzieży danych kart płatniczych i danych osobowych w sektorze e-commerce.

Kradzież danych transakcyjnych przez atak Web Skimming

Scenariusz: W sklepie internetowym intruzi wstrzyknęli złośliwy skrypt JavaScript na podstronie płatności (atak Magecart / Web Skimming), przechwytując dane kart. Standardy ochrony formularzy webowych definiują rekomendacja W3C Content Security Policy Level 3 oraz standard bezpieczeństwa płatności PCI Security Standards Council (PCI DSS).

  • Przyczyny bezpośrednie: Modyfikacja zewnętrznej biblioteki analitycznej ładowanej z zewnętrznego serwera CDN (atak na łańcuch dostaw oprogramowania).
  • Przyczyny źródłowe (RCA): Brak wdrożenia nagłówków bezpieczeństwa Content Security Policy (CSP); brak mechanizmu weryfikacji integralności zasobów (Subresource Integrity - SRI).
  • Skutki dla osób poszkodowanych: Wyłudzenie środków z kart płatniczych u ponad 1 200 klientów; konieczność masowego zastrzegania kart przez banki.
  • Skutki dla administratora: Kara Prezesa UODO w wysokości 850 000 PLN za brak odpowiednich środków technicznych (art. 32 RODO); kary od organizacji płatniczych (Visa/Mastercard) za naruszenie standardu PCI DSS.
Web Skimming (Magecart): Technika ataku polegająca na wstrzyknięciu złośliwego kodu JavaScript do skryptów formularza płatności na stronie WWW w celu niewidocznego przechwytywania numerów kart i kodów CVV w chwili ich wpisywania przez klienta. Skróty i pojęcia: SRI (Subresource Integrity, integralność zasobów podrzędnych); PCI DSS (Payment Card Industry Data Security Standard, standard kart płatniczych); CVV/CVC (kody weryfikacyjne karty); CI/CD (ciągła integracja i wdrażanie); WWW (World Wide Web).
Bilans Case Study 2: Web Skimming E-Commerce Analiza Przyczyn (RCA) • Zainfekowany skrypt JS z CDN • Brak polityki CSP w nagłówkach • Brak hashy SRI w znacznikach Luka: Zaufanie do kodu z sieci Bilans Skutków (BIA) • Skradzione dane 50 000 kart • Kara Prezesa UODO: 850 000 PLN • Kary organizacji PCI: 250 000 USD Spadek sprzedaży o 40% Wdrożone działania naprawcze (CAPA) 1. Wdrożenie rygorystycznych nagłówków Content-Security-Policy blokujących wysyłkę danych do obcych domen 2. Wprowadzenie mechanizmu Subresource Integrity (SRI) weryfikującego hash każdego skryptu JS 3. Pełna certyfikacja środowiska płatności wg normy PCI DSS Level 1 Uruchomienie dedykowanego formularza roszczeniowego dla poszkodowanych klientów
36/55
Studium przypadku 3: Atak DDoS na instytucję administracji publicznej
Cel slajdu: Przedstawienie analizy przyczyn i skutków paraliżu usług cyfrowych administracji państwowej przez zorganizowany atak DDoS.

Kiedy obywatele nie mogą załatwić spraw urzędowych

Scenariusz: W dniu ostatecznego terminu składania wniosków portal e-administracji regionalnej padł ofiarą ataku DDoS o natężeniu 80 Gbps. Procedury przeciwdziałania atakom wolumetrycznym opisuje CERT Polska – wiedza.cert.pl: obsługa incydentów (DDoS) oraz portal rządowy CSIRT GOV (Zespół Reagowania na Incydenty Administracji Rządowej).

  • Przyczyny bezpośrednie: Zmasowany atak wolumetryczny UDP Flood i DNS Amplification wygenerowany z globalnego botnetu urządzeń IoT.
  • Przyczyny źródłowe (RCA): Brak umowy z operatorem telekomunikacyjnym na nielimitowaną ochronę anty-DDoS (BGP Anycast); brak testów obciążeniowych przed kluczowym terminem.
  • Skutki społeczne i prawne: Tysiące obywateli nie mogło złożyć wniosków; konieczność wydania przez Wojewodę rozporządzenia przedłużającego termin naboru; zarzuty niegospodarności w mediach.
  • Skutki operacyjne: Kwalifikacja zdarzenia jako incydent poważny wg ustawy o KSC (Dz.U. 2026 poz. 252); zaangażowanie dyżurnych CSIRT NASK i CSIRT GOV w celu przekierowania tras BGP.
BGP Anycast (routing wielościeżkowy): Technika trasowania sieciowego, w której ten sam adres IP jest rozgłaszany z dziesiątek centrów danych na świecie, co pozwala na rozproszenie i pochłonięcie fali ataku DDoS blisko źródeł infekcji. Skróty i pojęcia: UDP Flood (zalew pakietami UDP); DNS Amplification (wzmocnienie przez DNS); GOV (administracja rządowa), CSIRT GOV i CSIRT NASK (krajowe zespoły reagowania).
Bilans Case Study 3: DDoS na Portal Publiczny Analiza Przyczyn (RCA) • Brak chmurowego Scrubbing Center • Łącze brzegowe nasycone w 100% • Brak testów wydajnościowych Luka: Zły dobór umowy z ISP Bilans Skutków (BIA) • Paraliż usług przez 14 godzin • 12 000 niezłożonych wniosków • Zgłoszenie CSIRT GOV / KSC Konieczność wydłużenia terminu Wdrożone działania naprawcze (CAPA) 1. Podpisanie trójstronnego porozumienia z operatorem krajowym na ochronę BGP Anycast 2. Wdrożenie chmurowej zapory aplikacji webowych (Cloud WAF) filtrującej zapytania HTTP 3. Integracja z systemem S46 w celu natychmiastowej wymiany informacji z CSIRT NASK Audyt odporności na ataki DDoS przeprowadzony we współpracy z ekspertami NASK
37/55
Raport z analizy incydentu powłamaniowego - struktura formalna
Cel slajdu: Przedstawienie standardowej struktury raportu powłamaniowego (Incident Analysis Report) spełniającego wymogi zarządcze, audytowe oraz organów ścigania.

Jak pisać profesjonalny dokument podsumowujący dochodzenie?

Końcowym produktem pracy zespołu analitycznego jest oficjalny raport powłamaniowy. Format i strukturę raportu regulują standard ISO/IEC 27035-1:2023 (Incident reporting) oraz wytyczne NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile.

  • Streszczenie dla kadry zarządzającej (Executive Summary): Zwięzłe, jednostronicowe podsumowanie bez żargonu: co się stało, jakie były straty, co zrobiono i ile kosztowały działania naprawcze.
  • Opis incydentu i chronologia zdarzeń (Timeline): Dokładna oś czasu od pierwszego wektora wejścia przez ruch boczny aż po detekcję i powstrzymanie ze znacznikami UTC.
  • Analiza techniczna i wskaźniki IoC: Szczegółowy opis złośliwego oprogramowania, wykorzystanych podatności CVE, adresów IP i hashy SHA-256.
  • Ustalenia przyczyn źródłowych (Sekcja RCA): Wyniki analizy 5 Why i diagramu Ishikawy wskazujące luki procesowe i organizacyjne w SZBI.
  • Ocena skutków i plan działań korygujących (CAPA): Szacunek strat finansowych oraz tabela konkretnych zadań naprawczych z terminami i nazwiskami odpowiedzialnych.
Executive Summary (streszczenie menedżerskie): Skondensowana część oficjalnego raportu technicznego, przeznaczona dla członków zarządu i dyrekcji, syntetyzująca kluczowe fakty, ryzyka biznesowe i decyzje bez użycia hermetycznego żargonu IT. Skróty i pojęcia: CAPA (działania korygujące i zapobiegawcze); CVE (identyfikatory podatności: CVE.org); IP (adres protokołu internetowego); RAM (pamięć operacyjna); UTC (czas uniwersalny); SHA-256 (funkcja skrótu).
Struktura Raportu Powłamaniowego (Incident Report) 1. Executive Summary Dla Zarządu: Fakty, straty, decyzje 2. Oś Czasu (Timeline) Przebieg zdarzeń w czasie UTC 3. Analiza Techniczna & IoC Luki CVE, hashe, malware, logi 4. Badanie Przyczyn (RCA) 5 Why + Ishikawa (luki procesu) 5. Plan Działań Korygujących i Zapobiegawczych (CAPA) Zadania, właściciele biznesowi, budżet, harmonogram wdrożenia Zasady formalne sporządzania raportu • Raport stanowi oficjalny materiał dowodowy dla organu nadzorczego UODO oraz ubezpieczyciela • Dokument musi być podpisany przez Kierownika Zespołu IR oraz Inspektora Ochrony Danych • Kopia raportu podlega obowiązkowej archiwizacji przez minimum 5 lat w ewidencji SZBI
38/55
Od analizy do działań naprawczych - pętla ciągłego doskonalenia
Cel slajdu: Przedstawienie procedury transferu wniosków z raportu powłamaniowego do bieżącego zarządzania ryzykiem i aktualizacji Systemu Zarządzania Bezpieczeństwem Informacji.

Zamykanie cyklu zarządzania incydentem

Nawet najdoskonalszy raport powłamaniowy jest bezwartościowy, jeśli trafi na półkę i zostanie zapomniany. Ostatnim etapem analizy jest skuteczne wdrożenie zaleceń i audyt ich wykonania w ramach pętli doskonalenia normy ISO/IEC 27001:2022 (Klauzula 10 Doskonalenie) oraz wytycznych Google SRE – Postmortem Actions and Accountability.

  • Zasada jednoosobowej odpowiedzialności (Single Ownership): Każde zalecenie naprawcze z planu CAPA musi mieć przypisane konkretne nazwisko właściciela biznesowego, a nie ogólny „dział IT”.
  • Aktualizacja rejestru ryzyk organizacji: Wystąpienie incydentu unieważnia dotychczasowe szacunki prawdopodobieństwa - w rejestrze ryzyk należy podnieść ocenę podatności i zaktualizować poziom ryzyka rezydualnego.
  • Rewizja polityk i procedur operacyjnych (SOP): Jeśli analiza wykazała, że procedura dopuszczała opóźnienia w łataniu serwerów lub brak weryfikacji tożsamości, dokument musi zostać natychmiast znowelizowany.
  • Weryfikacja skuteczności (Post-Implementation Review): Po 90 dniach od wdrożenia poprawek audytor wewnętrzny przeprowadza test penetracyjny lub kontrolę sprawdzającą, czy zalecenia rzeczywiście usunęły lukę.
Przegląd powdrożeniowy (Post-Implementation Review): Czynność kontrolna prowadzona po wdrożeniu planu naprawczego w celu obiektywnego zweryfikowania, czy zastosowane środki trwale usunęły zidentyfikowaną przyczynę źródłową incydentu. Skróty i pojęcia: SOP (Standard Operating Procedure, standardowa procedura operacyjna); FIDO2 (klucze sprzętowe).
Cykl Doskonalenia Bezpieczeństwa po Incydencie 1. Plan (CAPA) 2. Do 3. Check 4. Act SZBI Etapy Zamykania Incydentu 1. Wpisanie CAPA do Jiry / ServiceNow 2. Przypisanie budżetu i właściciela 3. Wdrożenie zmian technicznych 4. Nowelizacja procedur i szkoleń 5. Retest bezpieczeństwa po 90 dniach 6. Formalne zamknięcie sprawy Podsumowanie modułu analizy incydentów Incydent prawidłowo zbadany i rozliczony czyni organizację silniejszą i bardziej odporną!
39/55
Systemy SIEM - Security Information and Event Management
Cel slajdu: Zrozumienie roli systemów SIEM w agregacji, normalizacji, korelacji zdarzeń oraz detekcji incydentów w czasie zbliżonym do rzeczywistego.

Centralny mózg analityczny współczesnego Security Operations Center (SOC)

Współczesna infrastruktura IT generuje miliardy zdarzeń dziennie. Bez systemu SIEM, który zbiera, przetwarza i koreluje logi z tysięcy rozproszonych źródeł, identyfikacja zaawansowanego ataku byłaby niemożliwa. Standardy zarządzania dziennikami zdarzeń opisuje NIST SP 800-92 (Guide to Computer Security Log Management) oraz międzynarodowa norma ISO/IEC 27001:2022 (Załącznik A.8.15 - Rejestrowanie zdarzeń).

  • Agregacja i normalizacja logów: Pobieranie zdarzeń z zapór sieciowych, kontrolerów domeny Active Directory, serwerów chmurowych i stacji roboczych; unifikacja formatów do wspólnego schematu, np. Elastic Common Schema (ECS) lub CEF (Common Event Format).
  • Reguły korelacji zdarzeń w czasie rzeczywistym: Łączenie z pozoru nieszkodliwych zdarzeń w łańcuch ataku: np. 10 nieudanych prób logowania SSH + natychmiastowe utworzenie konta administratora = alert o ataku brute-force i eskalacji uprawnień.
  • Triada rozwiązań na rynku: Liderzy komercyjni: Splunk Enterprise Security (analityka Big Data), Microsoft Sentinel (natywny chmurowy SIEM z AI) oraz czołowe rozwiązanie open-source Wazuh Open Source SIEM & XDR (oparte o agentów i silnik OpenSearch).
  • Retencja audytowa i wymogi prawne: Długoterminowe, niezmienne przechowywanie logów w technologii WORM (Write Once, Read Many) w celach dowodowych dla organów ścigania oraz spełnienia wymogów art. 32 RODO i ustawy o KSC (Dz.U. 2026 poz. 252).
SIEM (Security Information and Event Management): Zintegrowane rozwiązanie łączące zarządzanie informacjami o bezpieczeństwie (SIM - centralizacja, indeksowanie i bezpieczna retencja logów) oraz zarządzanie zdarzeniami (SEM - wieloźródłowa korelacja regułowa i alertowanie w czasie rzeczywistym). Skróty i pojęcia: SIM (Security Information Management) i SEM (Security Event Management, dwa człony SIEM); SSH (Secure Shell); XDR (Extended Detection and Response, rozszerzona detekcja); UEBA (User and Entity Behavior Analytics, analityka behawioralna).
Architektura Przepływu Danych w Systemie SIEM ŹRÓDŁA Firewalle / NGFW Active Directory Serwery Linux/Win Chmury AWS/Azure AGREGACJA Syslog / WinEvent Logstash / Agenci Normalizacja ECS Wzbogacanie IP/Geo SILNIK SIEM Splunk / Sentinel Wazuh OpenSearch Reguły korelacji Scoring ryzyka REZULTAT Incydent / Alert Eskalacja SOC Pulpit analityka Wyzwalacz SOAR Wymogi Zgodności i Rola w Badaniu Incydentów • Standardy audytowe: Retencja danych min. 12 miesięcy zgodnie z wytycznymi KSC i KNF • Niezaprzeczalność dowodowa: Zabezpieczenie przed modyfikacją logów przez intruza (WORM) • Ograniczenie szumu: Tuning reguł korelacyjnych w celu minimalizacji fałszywych alarmów (FP) • Integracja: Współpraca z EDR i SOAR tworzy zautomatyzowaną machinę obronną SOC
40/55
Platformy SOAR - orkiestracja i automatyzacja reakcji
Cel slajdu: Poznanie zasad działania platform SOAR, konstrukcji playbooków oraz synergii między automatyzacją a pracą analityka bezpieczeństwa.

Od wykrycia do neutralizacji zagrożenia w ułamki sekund

Skala współczesnych alertów generowanych przez SIEM doprowadziła do zjawiska zmęczenia alertami (alert fatigue). Platformy SOAR automatyzują powtarzalne czynności dochodzeniowe i natychmiast blokują wektory ataku. Ramy automatyzacji reakcji definiuje przewodnik NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile oraz otwarta platforma reagowania TheHive Project (Security Incident Response Platform).

  • Trzy filary SOAR: Orkiestracja (integracja dziesiątek API narzędzi IT i Security), Automatyzacja (wykonywanie wieloetapowych skryptów bez udziału człowieka) oraz Reagowanie (zarządzanie sprawami, remediation i audytowalność działań).
  • Zautomatyzowane playbooki: Graficznie lub kodowo zdefiniowane algorytmy postępowania zgodne ze standardami OASIS CTI / Playbooks: np. weryfikacja załącznika pocztowego, sprawdzenie hasha w VirusTotal, izolacja stacji przez EDR i zablokowanie domeny C2 na zaporze.
  • Wiodące rozwiązania: Liderzy komercyjni: Palo Alto Networks Cortex XSOAR i Splunk SOAR oraz otwartoźródłowy ekosystem łączący TheHive (case management) z silnikiem Cortex (automatyczne analizatory i responsery).
  • Drastyczna redukcja MTTD i MTTR: Skrócenie średniego czasu reakcji (Mean Time to Respond) w powtarzalnych, wystandaryzowanych incydentach – np. z kilkudziesięciu minut do kilkudziesięciu sekund; zasada „Human-in-the-loop” gwarantuje autoryzację człowieka przy działaniach niosących ryzyko biznesowe.
SOAR (Security Orchestration, Automation and Response): Kategoria oprogramowania integrująca rozproszone narzędzia bezpieczeństwa w ujednolicony ekosystem zdolny do automatycznego wykonywania wieloetapowych procedur reagowania (playbooków) z minimalnym udziałem człowieka. Skróty i pojęcia: API (Application Programming Interface, interfejs programistyczny); CTI (Cyber Threat Intelligence, wywiad o zagrożeniach); MTTD (Mean Time to Detect) i MTTR (Mean Time to Respond/Resolve, średni czas wykrycia i reakcji).
Cykl Wykonania Playbooka w Platformie SOAR 1. ALERT SIEM Podejrzany plik Zgłoszenie phish Wykrycie IOC Czas: 0 s 2. WZBOGACENIE Odpytanie VT/MISP Sandbox detekcja Weryfikacja tożsamości Czas: 5-15 s 3. DECYZJA AUTO Kryteria playbooka Złośliwy score > 80 Autoryzacja analityka Czas: 1-5 s 4. NEUTRALIZACJA Blokada na NGFW Izolacja w EDR Reset hasła w AD Razem: < 30 s Korzyści Wdrożenia SOAR w Operacjach Bezpieczeństwa • Standaryzacja: Każdy incydent obsłużony według jednolitej, powtarzalnej procedury • Eliminacja błędów: Wyeliminowanie ludzkich pomyłek przy presji czasowej ataku • Zmniejszenie kosztów: Automatyzacja powtarzalnych czynności poziomu L1 w SOC • Pełny ślad audytowy: Zarejestrowana każda wykonana akcja w celach prawnych i RCA
41/55
Platformy Threat Intelligence - MISP, OpenCTI i wymiana IoC
Cel slajdu: Zrozumienie znaczenia wywiadu o zagrożeniach cybernetycznych (CTI) oraz mechanizmów wymiany wskaźników kompromitacji w ramach społeczności CSIRT.

Wiedza o taktykach przeciwnika jako tarcza obronna

Cyber Threat Intelligence (CTI) pozwala organizacji na przewidywanie ataków i rozpoznawanie znanych schematów działania grup cyberprzestępczych. Format wymiany danych definiuje międzynarodowy standard OASIS STIX 2.1 / TAXII 2.1 (Cyber Threat Intelligence) oraz protokół klauzul poufności FIRST TLP v2.0 (Traffic Light Protocol).

  • Platforma MISP (Malware Information Sharing Platform): Wiodący międzynarodowy system wymiany wskaźników IoC (MISP Open Source Threat Intelligence) integrujący instytucje rządowe, sektor finansowy i zespoły CSIRT poziomu krajowego.
  • Platforma OpenCTI: Nowoczesne środowisko analityczne (OpenCTI - Open Cyber Threat Intelligence Platform) łączące dane techniczne (hashe, IP) z wiedzą operacyjną o kampaniach, grupach APT i podatnościach zgodnie z modelem STIX.
  • Strumienie danych (Threat Feeds): Automatyczny import wskaźników z zaufanych źródeł, w tym biuletynów i kanałów CERT Polska – Lista Ostrzeżeń, bezpośrednio do zapór sieciowych, EDR i reguł SIEM.
  • Trzy poziomy wiedzy CTI: Poziom taktyczny (skróty plików, adresy IP serwerów C2), operacyjny (techniki TTP, motywacje i schematy grup APT) oraz strategiczny (trendy geopolityczne i raporty ryzyka dla zarządów spółek).
Cyber Threat Intelligence (CTI): Ustrukturyzowana, zweryfikowana wiedza o istniejących i wyłaniających się zagrożeniach cyfrowych, obejmująca motywy, możliwości oraz wskaźniki techniczne przeciwników, wykorzystywana do podejmowania decyzji obronnych. Skróty i pojęcia: APT (słownik NIST, hasło Advanced Persistent Threat), ISAC (Information Sharing and Analysis Center, centrum wymiany informacji); TLS (Transport Layer Security, szyfrowanie transportu).
Ekosystem Wymiany Cyber Threat Intelligence (CTI) ŹRÓDŁA CTI • CSIRT NASK / GOV • Feedy ISAC / CERT • Komercyjne (Recorded) • Analiza własnych prób PLATFORMA CTI • MISP (Korelacja IOC) • OpenCTI (Wiedza TTP) • Format STIX 2.1 / TAXII • Tagowanie TLP (Amber/Red) KONSUMPCJA • Reguły detekcji SIEM • Blokady DNS / Firewall • Skanowanie hostów EDR • Threat Hunting w SOC Protokół TLP (Traffic Light Protocol) w Dzieleniu Informacją • TLP:RED - Ściśle poufne, wyłącznie dla bezpośrednich uczestników spotkania • TLP:AMBER+STRICT - Ograniczone do organizacji odbiorcy; AMBER: z partnerami • TLP:GREEN - Dozwolone udostępnianie w całej zrzeszonej społeczności sektorowej • TLP:CLEAR - Informacja jawna, dozwolona do nieograniczonej publikacji publicznej
42/55
Narzędzia informatyki śledczej (Digital Forensics)
Cel slajdu: Przegląd specjalistycznego instrumentarium do pozyskiwania i badania cyfrowego materiału dowodowego zgodnie z normą ISO/IEC 27037.

Akwizycja bit-po-bicie, analiza pamięci RAM i rekonstrukcja artefaktów

Prawidłowa analiza incydentu wymaga twardych, nienaruszalnych dowodów. Narzędzia informatyki śledczej pozwalają na odtworzenie każdego kroku intruza bez modyfikacji oryginalnych nośników danych. Zasady zabezpieczania dowodów normuje ISO/IEC 27037:2012 (Guidelines for identification, collection, acquisition and preservation of digital evidence) oraz przewodnik NIST SP 800-86 (2006, Guide to Integrating Forensic Techniques into Incident Response).

  • Akwizycja nośników (Image Acquisition): Tworzenie wiernych kopii bitowych (RAW, E01) przy użyciu programów FTK Imager, dd/dc3dd oraz sprzętowych blokerów zapisu (write-blockers); obowiązkowe generowanie sum kontrolnych SHA-256.
  • Analiza systemów plików i dysków: Środowisko śledcze Autopsy Digital Forensics (The Sleuth Kit) oraz EnCase - ekstrakcja metadanych NTFS ($MFT), analiza rejestru Windows, dzienników zdarzeń EVTX, plików Prefetch i LNK.
  • Analiza pamięci operacyjnej RAM: Framework śledczy Volatility 3 Foundation - ujawnianie ukrytych procesów, wstrzykniętego kodu shellcode i aktywnych połączeń sieciowych:
    vol.py -f memdump.raw windows.pslist (procesy), windows.netscan (gniazda sieciowe), windows.malfind (iniekcje kodu w pamięci).
  • Analiza ruchu sieciowego (Network Forensics): Wireshark i tshark (głęboka inspekcja zrzutów PCAP) oraz Zeek Network Security Monitor (ekstrakcja metadanych sesji, certyfikatów SSL i zapytań DNS).
Informatyka śledcza (Digital Forensics): Zastosowanie naukowo zweryfikowanych metod i rygorystycznych procedur techniczno-prawnych do pozyskiwania, zabezpieczania, badania i prezentacji cyfrowych dowodów w sprawach incydentów bez naruszenia ich integralności. Skróty i pojęcia: RAW i E01 (formaty obrazów dysków); LNK (skróty Windows); MFT (Master File Table, tablica plików NTFS); USN Journal (dziennik zmian NTFS); PCAP (Packet Capture, zrzut ruchu), write-blocker (bloker zapisu).
Cztery Filary Informatyki Śledczej w Reagowaniu na Incydenty AKWIZYCJA FTK Imager Kopia bitowa dd Write-blocker Format E01/RAW DYSK / PLIKI Autopsy / SleuthKit X-Ways Forensics MFT, Prefetch, LNK Ślady uruchomień PAMIĘĆ RAM Volatility 3 Rekall Forensic Zrzut procesów Iniekcje DLL / Kod ŚLEDZTWO SIECI Wireshark (PCAP) Zeek Network Log NetworkMiner Eksfiltracja C2 Zasady Prowadzenia Badań Zgodnie z ISO/IEC 27037 • Zasada nienaruszalności: Nigdy nie pracuj na oryginale dowodu, badaj wyłącznie kopię bitową • Spójność kryptograficzna: Weryfikacja sum kontrolnych MD5/SHA-256 przed i po badaniu • Kolejność ulotności (Order of Volatility): RAM -> sieć -> dyski -> archiwa taśmowe • Powtarzalność wyników: Inny biegły stosujący te same narzędzia musi uzyskać identyczny wniosek
43/55
Narzędzia do analizy złośliwego oprogramowania (Malware)
Cel slajdu: Przedstawienie metodyki statycznej i dynamicznej analizy złośliwego kodu, wykorzystania reguł YARA oraz środowisk sandbox.

Rozpracowanie mechanizmów działania payloadu

Zidentyfikowanie podejrzanego pliku wykonywalnego, makra Office czy skryptu PowerShell wymaga przeprowadzenia bezpiecznej dekompilacji i izolowanego uruchomienia w celu poznania jego zachowania i wskaźników IoC. Wytyczne analityczne definiuje NIST SP 800-83 Rev. 1 (Malware Incident Prevention and Handling) oraz oficjalna dokumentacja YARA Rule Engine (VirusTotal).

  • Analiza statyczna (Static Analysis): Badanie pliku bez jego uruchamiania: analiza nagłówków PE (Portable Executable), importowanych bibliotek DLL, ekstrakcja ciągów znaków (strings) i kalkulacja hashy kontekstowych ssdeep.
  • Reguły YARA: Międzynarodowy standard opisu wzorców binarnych i tekstowych; szybkie skanowanie dysków i pamięci RAM:
    yara -r /rules/malware.yar /mnt/evidence/
    Struktura reguły: rule RansomNote { strings: $s = "All your files" nocase condition: $s }.
  • Analiza dynamiczna w piaskownicy (Sandbox): Izolowane środowiska wirtualne (Cuckoo Sandbox, CAPEv2, serwis Any.Run); automatyczna rejestracja modyfikacji rejestru, tworzonych procesów potomnych i prób nawiązania połączeń C2.
  • Repozytoria i serwisy multi-skanerowe: Platformy VirusTotal i Hybrid-Analysis oraz bazy wskaźników zagrożeń tworzone przez CERT Polska – n6 (system wczesnego ostrzegania).
Piaskownica analityczna (Sandbox): Ściśle kontrolowane, odizolowane środowisko wirtualne przeznaczone do bezpiecznego uruchamiania nieznanego oprogramowania w celu rejestracji i analizy jego złośliwej aktywności bez ryzyka infekcji sieci produkcyjnej. Skróty i pojęcia: PE (Portable Executable, format wykonywalny Windows); DLL (biblioteka dynamiczna); API (interfejs programistyczny); FLOSS (narzędzie do ekstrakcji ukrytych ciągów); IDA (Interactive Disassembler, deasembler).
Ścieżka Badawcza w Laboratorium Analizy Malware PRÓBKA Podejrzany .exe Makro w .docm Skrypt PowerShell Kwarantanna hasha STATYCZNA Hashe SHA256/ssdeep Strings & PEStudio Reguły YARA Ghidra / IDA Pro DYNAMICZNA Cuckoo / Any.Run Detekcja Procmon Ruch DNS / C2 Ewazja sandboxa REZULTAT IOC Adresy IP serwerów C2 Klucze w rejestrze Run Nowa sygnatura YARA Eksport do MISP Zasady Bezpieczeństwa w Laboratorium Malware • Izolacja sieciowa (Air-Gap): Prace wyłącznie w odizolowanym VLAN bez wyjścia na świat • Symulacja usług (INetSim): Fałszowanie odpowiedzi DNS/HTTP w celu zbadania zachowania próbki • Odporność na anty-analizę: Obchodzenie technik detekcji środowisk VM (RDTSC, cpuid) • Szybkie dzielenie się wiedzą: Wzbogacenie reguł EDR i zapór o wyodrębnione wskaźniki IoC
44/55
Systemy EDR - Endpoint Detection and Response
Cel slajdu: Zrozumienie roli systemów ochrony punktów końcowych nowej generacji w detekcji zagrożeń na stacjach roboczych i serwerach.

Ciągła telemetria i natychmiastowa izolacja stacji roboczych

Tradycyjne programy antywirusowe bazujące na prostych sygnaturach są bezradne wobec ataków bezplikowych (fileless malware) i technik Living-off-the-Land (LotL). Rozwiązania EDR monitorują behawioralne zachowania procesów. Standardy telemetrii i konfiguracji definiuje NIST SP 800-128 (Configuration Management & System Telemetry) oraz taksonomia MITRE ATT&CK Framework.

  • Ciągła rejestracja telemetrii na hoście: Agenty EDR rejestrują każde wywołanie procesu, załadowanie biblioteki DLL, modyfikację rejestru oraz nawiązanie połączenia gniazda TCP/UDP w czasie rzeczywistym.
  • Wizualizacja drzewa procesów (Process Tree): Graficzne odwzorowanie łańcucha wykonania: np. proces WINWORD.EXE wywołujący powershell.exe -enc ..., który pobiera plik z sieci i uruchamia narzędzie whoami.exe.
  • Zdalna izolacja hosta jednym kliknięciem: Zdolność analityka SOC do natychmiastowego odcięcia zainfekowanego komputera od sieci lokalnej i Internetu, z zachowaniem wyłącznie szyfrowanego kanału komunikacji z konsolą zarządczą EDR.
  • Rozwiązania rynkowe i architektura: Liderzy rynkowi: CrowdStrike Falcon, Microsoft Defender for Endpoint oraz czołowe rozwiązanie open-source Wazuh Endpoint Agent integrujące mechanizmy detekcji anomalii i kontroli integralności FIM.
EDR (Endpoint Detection and Response): Zintegrowany system bezpieczeństwa punktów końcowych, który w czasie rzeczywistym rejestruje zdarzenia systemowe, wykrywa anomalie behawioralne i umożliwia zdalną izolację zaatakowanej stacji oraz przeprowadzenie analizy śledczej. Skróty i pojęcia: LotL (Living-off-the-Land, ataki legalnymi narzędziami), fileless malware (złośliwe oprogramowanie bezplikowe); WINWORD.EXE i powershell.exe (procesy pakietu biurowego i powłoki); FIM (File Integrity Monitoring, monitorowanie integralności plików).
Model Działania Systemu EDR na Punkcie Końcowym TELEMETRIA HOSTA • Tworzenie procesów • Iniekcje DLL / Wątki • Zmiany w kluczach Run • Połączenia gniazd TCP CHMURA ANALITYCZNA • Analiza behawioralna • Mapowanie MITRE ATT&CK • Modele ML anomalii • Scoring zagrożenia (0-100) REAKCJA REMEDIATION • Izolacja sieciowa hosta • Ubicie procesu (Kill) • Kwarantanna pliku • Zdalna konsola (Live Response) Przewaga EDR nad Tradycyjnym Antywirusem (AV) • Wykrywanie ataków bezplikowych: Detekcja kodu wykonywanego bezpośrednio w pamięci RAM • Ochrona przed Living-off-the-Land: Blokowanie nadużyć PowerShell, WMI, CertUtil i MSBuild • Pełny kontekst zdarzenia: Gotowe drzewo procesu z dokładnymi parametrami wiersza poleceń • Zdalna informatyka śledcza: Pobieranie zrzutów pamięci i plików bez fizycznego dostępu do biura
45/55
Systemy zgłoszeniowe (Ticketing) w obsłudze incydentów
Cel slajdu: Poznanie zasad organizacji pracy zespołów reagowania w oparciu o profesjonalne systemy ticketowe i audytowalne rejestry incydentów.

Rozliczalność, SLA i formalny ślad każdego zgłoszenia

Bez ustrukturyzowanego systemu obsługi spraw żaden proces reagowania nie utrzyma wymogów rozliczalności wynikających z art. 5 ust. 2 RODO (Zasada rozliczalności) ani terminów określonych w dyrektywie NIS2 i ustawie o KSC. Organizację procesu przygotowania i obsługi spraw reguluje norma ISO/IEC 27035-2:2023 (Guidelines to plan and prepare for incident response).

  • Dedykowane platformy zgłoszeniowe: Systemy dedykowane zespołom CSIRT/SOC: RTIR (Request Tracker for Incident Response), platforma TheHive Project oraz rozwiązania korporacyjne ServiceNow Security Operations (SecOps) i Jira Service Management.
  • Integracja z systemami SIEM i SOAR: Automatyczne zakładanie zgłoszenia ze statusem „New” natychmiast po wyzwoleniu skorelowanego alertu w SIEM; eliminacja ręcznego przepisywania danych i błędów ludzkich.
  • Zarządzanie poziomem usług (SLA) i eskalacje: Ścisłe monitorowanie wskaźnika MTTA (Mean Time to Acknowledge) oraz MTTR (Mean Time to Resolve); automatyczna eskalacja do kierownictwa w przypadku zbliżania się do terminów ustawowych (np. 24h wczesnego ostrzeżenia i 72h zgłoszenia pełnego wg KSC).
  • Archiwizacja audytowa i baza dowodowa: Centralne gromadzenie notatek analityków, protokołów zabezpieczenia dowodów, zatwierdzeń decyzyjnych oraz formalnych raportów powłamaniowych w nienaruszalnym rejestrze spraw.
System ticketowy (Incident Management System): Narzędzie informatyczne służące do formalnego rejestrowania, kategoryzowania, przypisywania odpowiedzialności, monitorowania statusów i SLA oraz audytowalnego archiwizowania spraw incydentów. Skróty i pojęcia: Severity (priorytet); SLA (umowa o poziomie usług); MTTA (Mean Time to Acknowledge, średni czas potwierdzenia) i MTTR (średni czas rozwiązania); SecOps (operacje bezpieczeństwa), SOC i CSIRT (zespoły reagowania).
Cykl Życia Zgłoszenia Incydentu w Systemie Ticketingowym REJESTRACJA Alert z SIEM Mail pracownika Zgłoszenie CSIRT Nadanie ID TRIAGE Ocena ważności P1/P2/P3/P4 Przypisanie L2 SLA: 15 min ŚLEDZTWO Analiza RCA Dowody / Logi Containment Zabezpieczenie NAPRAWA Eradication Odtworzenie Testy usług Zgłoszenie UODO ZAMKNIĘCIE Raport końcowy Lessons learned Akcje CAPA Retencja 5 lat Kluczowe Parametry SLA w Obsłudze Spraw (ITIL / NIST) • Priorytet 1 (Krytyczny - paraliż usług kluczowych): Czas reakcji < 15 min, praca 24/7 • Priorytet 2 (Wysoki - kompromitacja konta uprzywilejowanego): Czas reakcji < 1h • Zegar regulacyjny NIS2/KSC: Odliczanie terminów 24h (ostrzeżenie) i 72h (zgłoszenie) • Rozliczalność (art. 5 ust. 2 RODO): Udokumentowanie każdej minuty działań dla UODO
46/55
Skanery podatności w prewencji i analizie powłamaniowej
Cel slajdu: Zrozumienie zastosowania skanerów podatności do identyfikacji słabości systemowych przed atakiem oraz w trakcie weryfikacji powłamaniowej.

Wykrywanie luk w oprogramowaniu i błędnych konfiguracji

Cyberprzestępcy nieustannie skanują przestrzeń adresową w poszukiwaniu niezałatanych podatności (Common Vulnerabilities and Exposures - CVE). Oficjalne rejestry podatności i metodologię ich wyceny prowadzi NIST NVD (National Vulnerability Database) oraz katalog aktywnie wykorzystywanych luk CISA KEV (Known Exploited Vulnerabilities).

  • Zautomatyzowane skanowanie podatności: Sondowanie sieci, otwartych portów i usług w celu wykrycia przestarzałych wersji bibliotek, błędnych konfiguracji i luk umożliwiających zdalne wykonanie kodu (RCE) z kalkulacją punktacji CVSS v3.1 / v4.0.
  • Liderzy technologiczni na rynku: Otwartoźródłowy skaner referencyjny Greenbone Vulnerability Management (GVM / OpenVAS) oraz rozwiązania komercyjne Tenable Nessus, Qualys VMDR i Rapid7 InsightVM.
  • Skanowanie uwierzytelnione vs nieuwierzytelnione: Skan zewnętrzny (black-box) bada podatności widoczne z Internetu; skan z poświadczeniami loguje się na maszynę i bada brakujące łatki (patches) w rejestrze i pakietach operacyjnych.
  • Rola w analizie przyczyn źródłowych (RCA): Po wykryciu włamania skaner weryfikuje, czy wektorem wejścia intruza była konkretna luka CVE obecna w systemie przed incydentem (np. podatność w bramie VPN lub serwerze pocztowym) i dlaczego proces zarządzania poprawkami zawiódł.
Skaner podatności (Vulnerability Scanner): Zautomatyzowane oprogramowanie diagnostyczne badające systemy, sieci i aplikacje w celu wykrycia znanych słabości technicznych i luk w zabezpieczeniach (zgodnie z bazami CVE/NVD) oraz rekomendacji poprawek. Skróty i pojęcia: CVE i NVD (bazy podatności); CVSS (Common Vulnerability Scoring System, punktacja dotkliwości).
Cykl Zarządzania Podatnościami (Vulnerability Management) BAZY WIEDZY • NIST NVD / MITRE CVE • Punktacja CVSS v3.1/v4 • Baza CISA KEV (Known Exploit) • Eksploity 0-day w sieci SKANOWANIE • Nessus / Qualys / OpenVAS • Skanowanie z poświadczeniami • Wykrywanie otwartych portów • Weryfikacja łat systemowych REMEDIATION • Priorytetyzacja ryzyka • Instalacja poprawek (Patch) • Wdrożenie Virtual Patching • Re-skan potwierdzający Klasyfikacja Podatności wg Skali CVSS (Common Vulnerability Scoring System) • CRITICAL (CVSS 9.0 - 10.0): Zdalne wykonanie kodu bez uwierzytelnienia; łatka w 24h • HIGH (CVSS 7.0 - 8.9): Eskalacja uprawnień lub ominięcie zabezpieczeń; łatka w ciągu 7 dni • MEDIUM (CVSS 4.0 - 6.9): Wymaga interakcji użytkownika (np. phishing); łatka w ciągu 30 dni • LOW (CVSS 0.1 - 3.9): Wyciek informacji technicznych; łatka w standardowym cyklu
47/55
Systemy IDS/IPS - sieciowa detekcja i prewencja intruzji
Cel slajdu: Porównanie działania systemów IDS i IPS, mechanizmów sygnaturowych oraz zaawansowanej analizy anomalii w ruchu pakietowym.

Czujniki sieciowe na straży perymetru i segmentów wewnętrznych

Ruch sieciowy to krwioobieg organizacji. Systemy IDS i IPS analizują przepływające pakiety w locie, wykrywając exploity, skanowania portów i transmisje z serwerami dowodzenia C2 (Command and Control). Oficjalne zalecenia IDPS publikuje NIST SP 800-94 (Guide to Intrusion Detection and Prevention Systems) oraz projekt silnika Suricata IDS/IPS/NSM.

  • IDS (Detection) vs IPS (Prevention): IDS działa w trybie pasywnym (podsłuch na porcie SPAN/mirror lub TAP sieciowym) i generuje alerty; IPS pracuje w linii transmisyjnej (inline) i aktywnie odrzuca złośliwe pakiety (drop/reset).
  • Oprogramowanie referencyjne: Suricata (nowoczesny, wielowątkowy silnik z głęboką inspekcją protokołów i automatyczną ekstrakcją plików) oraz Snort 3 (historyczny pionier z olbrzymią bazą reguł społecznościowych).
  • Sygnatury vs detekcja anomalii: Reguły sygnaturowe wykrywają precyzyjne ciągi bajtów znanego exploita; moduły anomalii alarmują o odchyleniach od normy (np. nagły wzrost wolumenu zapytań DNS tunelującego dane na zewnątrz).
  • Praktyczny przykład reguły i weryfikacji CLI: Przykładowa reguła Suricata wykrywająca beaconing:
    alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL C2 BEACONING TO EXTERNAL HOST"; flow:established,to_server; http.uri; content:"/submit.php"; classtype:trojan-activity; sid:4200001; rev:1;)
    Polecenie badania zrzutu ruchu: suricata -c /etc/suricata/suricata.yaml -r dump.pcap -l /var/log/suricata/.
IDS/IPS (Intrusion Detection / Prevention System): Urządzenie lub oprogramowanie monitorujące aktywność sieciową pod kątem złośliwych działań lub naruszeń polityk, generujące alerty (IDS) lub aktywnie blokujące niepożądany ruch w locie (IPS). Skróty i pojęcia: SPAN/TAP (port lustrzany i odgałęźnik sprzętowy, metody podsłuchu ruchu); DPI (Deep Packet Inspection, głęboka inspekcja pakietów); SMB (Server Message Block, protokół plików); VLAN (wirtualna sieć lokalna).
Porównanie Trybów Pracy: IDS (Pasywny) vs IPS (Aktywny) IDS (Tryb Pasywny / Sniffer) • Podłączony do portu SPAN / TAP • Brak wpływu na opóźnienia sieciowe • Generuje alert, pakiet dociera do celu Zastosowanie: Monitoring i audyt IPS (Tryb Aktywny / Inline) • Umieszczony wprost w ścieżce pakietów • Może wprowadzać minimalne opóźnienia • Natychmiast porzuca pakiet (DROP/RESET) Zastosowanie: Aktywna tarcza perymetru Architektura Nowoczesnych Czujników Suricata w SOC • Wielowątkowość (Multi-threading): Przetwarzanie ruchu 10Gbps+ na nowoczesnych procesorach • Inspekcja protokołów: Ekstrakcja metadanych HTTP, TLS/SSL (certyfikaty), DNS, SMTP i SSH • Ekstrakcja plików w locie: Automatyczny zrzut pobieranego pliku i przekazanie do sandboxa • Integracja z SIEM: Eksport logów EVE JSON bezpośrednio do systemów Wazuh, Splunk i Elastic
48/55
Matryca MITRE ATT&CK w analizie incydentów i TTP
Cel slajdu: Nauka posługiwania się taksonomią MITRE ATT&CK do dekonstrukcji ataku, modelowania zachowań przeciwnika oraz identyfikacji braków w systemie obrony.

Uniwersalny język opisu technik i taktyk cyberprzestępców

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) to globalnie uznana, oparta na rzeczywistych obserwacjach baza wiedzy o zachowaniach cyberprzeciwników. Dostęp do pełnej taksonomii zapewnia oficjalna baza MITRE ATT&CK Framework, a komplementarny framework obronny opisuje projekt MITRE D3FEND (Cybersecurity Countermeasures).

  • Taktyki (Tactics - „Dlaczego”): 14 celów pośrednich napastnika ułożonych w sekwencję łańcucha ataku: od Initial Access (uzyskanie dostępu), przez Persistence i Lateral Movement, aż po Exfiltration i Impact.
  • Techniki i Podtechniki (Techniques - „Jak”): Konkretne metody techniczne realizacji celu (np. technika T1059: Command and Scripting Interpreter, podtechnika T1059.001: PowerShell, T1486: Data Encrypted for Impact).
  • Profil behawioralny TTP: Taktyki, Techniki i Procedury pozwalają na atrybucję ataku do konkretnej grupy (np. APT28, Lazarus, LockBit) nawet wtedy, gdy napastnik zmieni adresy IP i sumy kontrolne plików.
  • Piramida Bólu Davida Bianco: Wierzchołek piramidy stanowią techniki TTP; wykrywanie zachowań zmusza przeciwnika do kosztownej modyfikacji całego aparatu ataku, o czym informują raporty analityczne CERT Polska – Raport roczny 2024.
MITRE ATT&CK: Ustrukturyzowana matryca taktyk i technik stosowanych przez cyberprzestępców, stanowiąca globalny standard opisu, kategoryzacji i modelowania działań adwersarza w cyberprzestrzeni. Skróty i pojęcia: TTP (Tactics, Techniques and Procedures); Initial Access, Persistence, Lateral Movement, Exfiltration i Impact (taktyki MITRE ATT&CK: dostęp, trwałość, ruch boczny, eksfiltracja i wpływ); T1059 i T1486 (techniki interpretera poleceń i szyfrowania danych).
Matryca MITRE ATT&CK Enterprise - Główne Fazy Ataku Initial Access • Phishing (T1566) • Podatność CVE (T1190) • Łańcuch dostaw Wejście do sieci Execution • PowerShell (T1059) • WMI / Wql (T1047) • Skrypty VBS Wykonanie kodu Persistence • Zadania cron (T1053) • Rejestr Run (T1547) • Nowe konto AD Utrzymanie dostępu Lateral Move • RDP / SSH (T1021) • SMB / PsExec • Pass-the-Hash Ruch boczny Impact / Exfil • Szyfrowanie (T1486) • Kradzież danych • Kasowanie kopii Skutek końcowy Piramida Bólu Davida Bianco (The Pyramid of Pain) • Hashe plików / IP / Domeny: Trywialne lub proste do zmiany przez atakującego (niski ból) • Narzędzia (Tools): Trudniejsze do modyfikacji (np. zamiana Mimikatz na własny program) • TTPs (Taktyki, Techniki i Procedury): Najwyższy poziom - zmusza wroga do nauki od zera • Wniosek analityczny: Detekcja zachowań behawioralnych (TTP) jest najtrwalszą tarczą SOC
49/55
Automatyzacja i sztuczna inteligencja - UEBA i AIOps
Cel slajdu: Przedstawienie nowoczesnych metod detekcji opartych na sztucznej inteligencji, analityce behawioralnej użytkowników (UEBA) oraz platformach AIOps.

Przejście od prostych reguł if-then do wielowymiarowych modeli uczenia maszynowego

Złożoność współczesnych chmur hybrydowych i ataki z użyciem skradzionych poświadczeń sprawiają, że statyczne reguły korelacyjne zawodzą. Odpowiedzią są ramy zarządzania ryzykiem sztucznej inteligencji NIST AI Risk Management Framework (AI RMF 1.0) oraz unijne przepisy Aktu o Sztucznej Inteligencji (EU AI Act - Rozporządzenie 2024/1689).

  • UEBA - analityka behawioralna użytkowników i zasobów: Budowanie profilu matematycznego normalnego zachowania pracownika (godziny logowania, wolumen pobieranych danych, używane stacje); alertowanie o anomaliach bez sztywnych reguł progowych.
  • Dynamiczny scoring ryzyka tożsamości: Agregacja drobnych anomalii w czasie: logowanie o 03:00 w nocy z zagranicznego adresu IP + zapytanie do bazy wrażliwej + pobranie 10 GB danych = natychmiastowe podniesienie alertu krytycznego.
  • Zastosowanie LLM i asystentów AI w SOC: Generatywne modele językowe wspomagające analityków: automatyczna synteza tysięcy logów, deobfuskacja skryptów i generowanie wstępnych szkiców raportów dochodzeniowych.
  • Bezpieczeństwo modeli i zagrożenia adwersarialne: Ryzyka podatności modeli na halucynacje, manipulację danymi wejściowymi (prompt injection) oraz techniki zatruwania danych opisane w repozytorium MITRE ATLAS (Adversarial Threat Landscape for AI Systems).
UEBA (User and Entity Behavior Analytics): Zaawansowana analityka bezpieczeństwa wykorzystująca uczenie maszynowe do modelowania typowych zachowań użytkowników i urządzeń w celu wykrywania nieautoryzowanych działań i przejętych kont tożsamości. Skróty i pojęcia: LLM (Large Language Model, wielki model językowy); AIOps (Artificial Intelligence for IT Operations, sztuczna inteligencja w operacjach IT); MTTD (Mean Time to Detect, średni czas wykrycia); SQL (Structured Query Language), prompt injection (wstrzyknięcie polecenia do modelu).
Model Analityki Behawioralnej UEBA i Sztucznej Inteligencji PROFILOWANIE BAZOWE • Typowe godziny pracy (8-16) • Standardowe adresy IP / Geo • Zwykły wolumen plików (50MB) • Zwykłe aplikacje biurowe DETEKCJA ANOMALII ML • Logowanie o 03:15 w nocy • Nowa lokalizacja (VPN Azja) • Pobranie 10 GB bazy SQL • Użycie PowerShell / WMI DYNAMICZNY SCORING • Anomalia czasu: +20 pkt • Anomalia lokalizacji: +30 pkt • Wolumen danych: +40 pkt Suma: 90/100 (ALARM KRYTYCZNY) Synergia Ludzkiej Intuicji i Maszynowej Inteligencji • Odszumianie (De-noising): Eliminacja 80% fałszywych alarmów dzięki korelacji kontekstowej • Odpowiedź w języku naturalnym: Generowanie podsumowań dochodzenia dla kierownictwa • Ograniczenia AI: Ryzyko halucynacji i ataków typu adversarial ML na modele klasyfikujące • Człowiek w pętli (Human-in-the-loop): Ostateczna decyzja o blokadzie kluczowych usług
50/55
Podsumowanie metod analizy i proces Lessons Learned
Cel slajdu: Synteza omówionych metod analitycznych oraz wdrożenie systematycznego procesu wyciągania wniosków (Lessons Learned) zgodnie z ISO/IEC 27035.

Zamykanie pętli ciągłego doskonalenia systemu zarządzania bezpieczeństwem

Zakończenie działań technicznych nie kończy obsługi incydentu. Najważniejszym etapem gwarantującym odporność organizacji na przyszłość jest formalny proces wyciągania wniosków opisany w normie ISO/IEC 27035-1:2023 (Etap 5.6 - Learn lessons) oraz przewodniku NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile.

  • Zestawienie metod analizy przyczyn: 5 Why (szybka analiza prostych awarii), Diagram Ishikawy (wieloczynnikowa analiza organizacyjno-techniczna), Drzewo błędów FTA (logiczna weryfikacja kombinacji) oraz MITRE ATT&CK (rekonstrukcja TTP intruza).
  • Spotkanie powłamaniowe (Post-Incident Review): Kluczowe spotkanie z udziałem IT, biznesu, zarządu i prawników zorganizowane w ciągu 5-10 dni od opanowania incydentu w formule wolnej od szukania winnych (Google SRE Blameless Postmortem).
  • Macierz działań korygujących i zapobiegawczych (CAPA): Każdy wniosek przekształcony w zadanie z przypisanym pojedynczym właścicielem (single ownership), budżetem i weryfikowalnym terminem wykonania (np. wdrożenie MFA w ciągu 14 dni).
  • Aktualizacja planów BCP/DR i procedur: Uaktualnienie polityk bezpieczeństwa, reguł w SIEM, procedur playbook w SOAR oraz programów szkoleniowych dla personelu zgodnie z zaleceniami CERT Polska – Poradnik: ransomware.
Wyciąganie wniosków (Lessons Learned): Systematyczny proces identyfikacji, dokumentowania i wdrażania wniosków z zaistniałego incydentu w celu trwałego podniesienia odporności organizacji, usunięcia podatności procesowych i aktualizacji planów BCP/DR. Skróty i pojęcia: BCP/DR (plany ciągłości i odtwarzania), single ownership (jednoosobowa odpowiedzialność), MITRE ATT&CK, SIEM i SOAR (reguły korelacji i playbooki), Google SRE Blameless Postmortem (spotkanie bez obwiniania).
Pętla Ciągłego Doskonalenia Lessons Learned (ISO/IEC 27035) 1. ANALIZA RCA Ishikawa / 5 Why 2. POST-MORTEM Blameless Review 3. PLAN CAPA Zadania i terminy 4. WDROŻENIE Nowe reguły / BCP Cztery Pytania Kanoniczne na Sesji Post-Mortem 1. Co dokładnie się wydarzyło i w jakiej sekwencji czasowej (timeline)? 2. Co zadziałało prawidłowo w naszych procedurach i narzędziach obronnych? 3. Gdzie zawiodły procesy, detekcja technologiczna lub komunikacja zespołowa? 4. Jakie konkretne zmiany wprowadzimy, aby ten scenariusz nigdy się nie powtórzył?
51/55
Kluczowe metody analizy incydentów - infografika syntetyczna
Cel slajdu: Syntetyczne zestawienie i porównanie wszystkich poznanych technik analitycznych (RCA, 5 Why, Ishikawa, FTA, Pareto, IoC, BIA) w czytelnej formule decyzyjnej.

Przewodnik doboru metody w zależności od natury i złożoności incydentu

Żadna pojedyncza metoda analityczna nie jest uniwersalna. Doświadczony oficer bezpieczeństwa dobiera technikę w zależności od skali incydentu, dostępności dowodów i presji czasowej. Ramy reakcji i odzyskiwania operacyjnego definiują standard NIST Cybersecurity Framework 2.0 (CSF 2.0 - Respond & Recover), norma ISO/IEC 27035-1:2023 oraz podręcznik dobrych praktyk inżynierskich Google SRE Incident Response Workbook.

  • Metoda 5 Why (5 x Dlaczego): Najlepsza do szybkiej analizy liniowych awarii i pojedynczych błędów ludzkich (np. ominięcie procedury, brak łatki w oprogramowaniu). Cechuje się niską złożonością i natychmiastowymi rezultatami operacyjnymi.
  • Diagram Ishikawy (Fishbone): Idealny do wieloczynnikowych, złożonych incydentów organizacyjnych; grupowanie przyczyn w pięciu kategoriach modelu zaadaptowanego do cyberbezpieczeństwa (Ludzie, Technologia, Procesy, Polityki i nadzór, Otoczenie i łańcuch dostaw).
  • Drzewo błędów (Fault Tree Analysis - FTA): Podejście dedukcyjne z bramkami logicznymi AND/OR; niezastąpione w analizie systemów krytycznych OT/SCADA oraz awarii zbieżnych o wysokim rygorze formalnym.
  • Matryca MITRE ATT&CK i korelacja IoC: Techniczne rozpracowanie zaawansowanych kampanii APT i ataków ransomware; analiza behawioralna TTP i wskaźników kompromitacji z mapowaniem na taksonomię MITRE ATT&CK.
Komplementarność metod analitycznych: Strategiczne łączenie prostych metod jakościowych (5 Why, Ishikawa) z zaawansowaną analizą techniczną (IoC, ATT&CK) oraz szacowaniem wpływu biznesowego (BIA) w celu uzyskania pełnego obrazu incydentu. Skróty i pojęcia: OT/SCADA (technologie operacyjne i nadzór przemysłowy); Pareto-Lorenza (wykres priorytetyzacji 80/20).
Matryca Doboru Metody Analitycznej w Incydencie 5 WHY • Proste awarie • Zależności liniowe • Czas: 15-30 min Szybka diagnoza ISHIKAWA • Złożone incydenty • Czynnik ludzki/org • Czas: 2-4 godz. 5 kategorii 5M DRZEWO FTA • Systemy krytyczne • Bramki AND / OR • Analiza ilościowa Ścisła logika ATT&CK / IOC • Ataki APT / Malware • Taktyki i procedury • Informatyka śledcza Techniczne TTP Zasada Trójkąta Analitycznego w Reagowaniu na Incydenty • Wierzchołek 1 (Technika): Co intruz zrobił? (IoC, Volatility, Wireshark, ATT&CK) • Wierzchołek 2 (Przyczyna źródłowa): Dlaczego do tego doszło? (Ishikawa, 5 Why, RCA) • Wierzchołek 3 (Wpływ biznesowy): Ile nas to kosztowało? (BIA, RTO/RPO, RODO, NIS2) • Rezultat: Kompletny raport powdrożeniowy z planem CAPA i audytowalnym Lessons Learned
52/55
Architektura narzędziowa SOC - mapa kategorii i przepływu danych
Cel slajdu: Przedstawienie zintegrowanego ekosystemu narzędziowego SOC łączącego SIEM, SOAR, EDR, Threat Intel, Forensics i Ticketing w spójną całość.

Jak współpracują ze sobą poszczególne warstwy oprogramowania obronnego?

Pojedyncze narzędzie nie obroni organizacji. Nowoczesne Security Operations Center (SOC) to orkiestracja wyspecjalizowanych systemów wymieniających się telemetrią w czasie rzeczywistym. Standardy usług i architektury SOC definiuje FIRST CSIRT Services Framework v2.1 oraz wytyczne obronne CISA StopRansomware Defense Architecture.

  • Warstwa Detekcji i Telemetrii (EDR, IDS/IPS, Skanery): Agenty CrowdStrike/Defender na hostach, czujniki sieciowe Suricata oraz skanery podatności Nessus/OpenVAS generujące strumienie zdarzeń i telemetrię.
  • Warstwa Centralizacji i Analityki (SIEM, UEBA): Systemy Splunk, Microsoft Sentinel oraz otwartoźródłowa platforma Wazuh SOC Architecture normalizujące logi, korelujące fakty i podnoszące alerty bezpieczeństwa na podstawie reguł i scoringu AI.
  • Warstwa Wywiadu o Zagrożeniach (CTI - MISP, OpenCTI): Dostarczanie wskaźników IoC, reguł YARA i sygnatur taktycznych ze społeczności CSIRT do bieżącego wzbogacania alertów analitycznych.
  • Warstwa Automatyzacji i Zarządzania Sprawą (SOAR, Ticketing): Platformy Palo Alto XSOAR / TheHive wykonujące playbooki izolujące hosty oraz systemy RTIR/ServiceNow zapewniające pełną rozliczalność SLA.
Ekosystem technologiczny SOC: Zintegrowany zespół powiązanych ze sobą narzędzi informatycznych umożliwiający pełny obieg informacji o zagrożeniu od momentu wykrycia aż po automatyczną remediację, odzyskanie sprawności i raport powdrożeniowy. Skróty i pojęcia: CTI (wywiad o zagrożeniach: MISP); YARA (reguły wykrywania); XSOAR (platforma Palo Alto Cortex XSOAR).
Zintegrowany Stos Technologiczny Nowoczesnego SOC TELEMETRIA EDR (CrowdStrike) IDS (Suricata) Skaner (Nessus) Sensory i logi KORELACJA SIEM (Splunk/Wazuh) UEBA (Analityka ML) Baza BigData Centralny silnik WYWIAD CTI MISP (IoC Feeds) OpenCTI (Taktyki) VirusTotal API Kontekst zagrożeń AUTOMATYZACJA SOAR (XSOAR/Cortex) Playbooki reakcji Ticketing (ServiceNow) Obsługa spraw SLA Automatyczny Przepływ Informacji w Trakcie Incydentu 1. Detekcja: EDR wykrywa podejrzany proces powershell.exe -> wysyłka logu do SIEM 2. Korelacja: SIEM łączy zdarzenie z logiem IDS i odpytuje platformę MISP o hash pliku 3. Orkiestracja: SOAR uruchamia playbook: izoluje hosta przez EDR i blokuje domenę C2 4. Rejestracja: ServiceNow zakłada bilet z kompletem artefaktów dla analityka L2 SOC
53/55
Case study do samodzielnej analizy - atak na szpital miejski
Cel slajdu: Praktyczne zadanie warsztatowe dla studentów: przeprowadzenie pełnej analizy przyczyn i skutków incydentu typu ransomware w placówce ochrony zdrowia.

Warsztat analityczny: od phishingu po paraliż oddziałów ratunkowych

Szpital Miejski (podmiot kluczowy wg Ustawy o KSC - tekst jedn. Dz.U. 2026 poz. 20 oraz Dyrektywy NIS2) padł ofiarą ataku ransomware w piątek o godzinie 23:00. Zaszyfrowano system szpitalny HIS, bazę obrazów PACS i stacje tomografii komputerowej. Doszło do naruszenia danych szczególnej kategorii zgodnie z art. 9, 33 i 34 RODO.

  • Zadanie 1: Rekonstrukcja wektora i analiza 5 Why: Pracownik laboratorium otworzył załącznik „Wyniki_testow.zip” zawierający złośliwy skrypt. Zastosuj metodę 5 Why, aby dojść od uruchomienia złośliwego załącznika do braku uwierzytelniania wieloskładnikowego (MFA) do VPN, braku segmentacji sieci oraz zaniechania szkoleń awareness.
  • Zadanie 2: Diagram Ishikawy dla infrastruktury szpitala: Zidentyfikuj przyczyny w kategoriach: Ludzie (przemęczenie personelu medycznego), Procesy (brak procedur okresowej weryfikacji kopii zapasowych offline), Technologia (serwery Windows Server bez wsparcia, brak VLAN medycznego) i Organizacja.
  • Zadanie 3: Ocena wpływu biznesowego (BIA) i prawnego: Oszacuj przekroczenie parametrów RTO (systemy były niedostępne przez 7 dni) oraz RPO = 48 h. Wskaż obowiązki zgłoszeniowe: wczesne ostrzeżenie w 24h do sektorowego CSIRT CeZ i CSIRT NASK oraz zgłoszenie do Prezesa UODO w 72h.
  • Zadanie 4: Opracowanie 4 działań naprawczych CAPA: Zaproponuj konkretne, mierzalne działania naprawcze z przypisaniem ról: Pełnomocnik ds. Cyberbezpieczeństwa, Kierownik IT, Dyrektor Szpitala. Wykorzystaj rekomendacje z poradników branżowych CERT Polska – Poradnik: ransomware.
Studium przypadku (Case Study): Metoda dydaktyczna polegająca na wieloaspektowej analizie rzeczywistego lub realistycznego incydentu bezpieczeństwa w celu wykształcenia praktycznych umiejętności decyzyjnych, śledczych i organizacyjnych. Skróty i pojęcia: HIS (Hospital Information System, system szpitalny); PACS (Picture Archiving and Communication System, obrazowanie radiologiczne); SOR (Szpitalny Oddział Ratunkowy); ZIP (format archiwum); WORM (zapis jednokrotny, kopie niemodyfikowalne); CeZ (Centrum e-Zdrowia); Zero Trust (model zerowego zaufania).
Scenariusz Warsztatowy: Paraliż Szpitala Miejskiego 1. WEKTOR Phishing w labie Brak MFA do VPN Zadanie: 5 Why Przyczyna bazowa 2. ISHIKAWA Ludzie: stres, brak wiedzy Sieć: brak segmentacji Backup podpięty SAN Diagram 5M 3. SKUTKI & BIA RTO: 7 dni paraliżu RPO: utrata 48h badań Zgłoszenie UODO/CeZ Wycena szkód 4. PLAN CAPA Wdrożenie FIDO2 Kopia WORM Air-Gap VLAN medyczny Działania i SLA Wymagane Elementy Końcowego Raportu Studenckiego • Oś czasu (Timeline) ze wskazaniem momentu przełamania zabezpieczeń (T0) • Kompletny formularz zgłoszeniowy incydentu poważnego do CSIRT CeZ / NASK (24h) • Ocena ryzyka naruszenia praw pacjentów dla Prezesa UODO (art. 33 RODO) • Karta projektu wdrożenia architektury Zero Trust w szpitalu z budżetem CAPEX/OPEX
54/55
Pytania kontrolne do wykładu 3 - sprawdź swoją wiedzę
Cel slajdu: Weryfikacja stopnia przyswojenia wiedzy z zakresu analizy przyczyn źródłowych (RCA), szacowania skutków, wskaźników IoC oraz narzędzi analitycznych.

10 pytań sprawdzających przygotowanie do egzaminu i ćwiczeń laboratoryjnych

Poniższy zestaw 10 pytań przekrojowych pozwoli na weryfikację wiedzy zdobytej podczas wykładu 3 oraz przygotowanie do kolokwium zaliczeniowego. Wyjaśnienia pojęć bazują na oficjalnym glosariuszu NIST CSRC Glossary (Root Cause Analysis), normie przeglądowej ISO/IEC 27000:2026 (wyd. 6) oraz publikacjach edukacyjnych CERT Polska – baza wiedzy wiedza.cert.pl.

  • Pytania 1-3 (Metodyki RCA, 5 Why i Ishikawa): 1. Czym różni się objaw incydentu od jego przyczyny źródłowej? 2. Kiedy metoda 5 Why zawodzi i w jaki sposób rozgałęzienie drzewa pytań eliminuje jej liniowość? 3. Wymień pięć kategorii przyczyn w diagramie Ishikawy zaadaptowanym do cyberbezpieczeństwa (Ludzie, Technologia, Procesy, Polityki i nadzór, Otoczenie i łańcuch dostaw).
  • Pytania 4-6 (Wskaźniki IoC, Forensics i BIA): 4. Na czym polega różnica pomiędzy badaniem obrazu dysku (Autopsy) a analizą zrzutu pamięci RAM (Volatility 3)? 5. Czym są artefakty IoC i na jakiej zasadzie korelujemy je w platformie MISP w formacie STIX? 6. Zdefiniuj parametry RTO, RPO, MTPD i wyjaśnij ich rolę w analizie BIA.
  • Pytania 7-8 (Architektura SIEM, SOAR i EDR): 7. Wyjaśnij różnicę w działaniu systemów SIEM i SOAR w kontekście zjawiska zmęczenia alertami (alert fatigue). 8. Dlaczego tradycyjny antywirus sygnaturowy przegrywa z atakami Living-off-the-Land i w jaki sposób EDR rejestruje telemetrię drzewa procesów?
  • Pytania 9-10 (MITRE ATT&CK i Lessons Learned): 9. Jaką rolę pełni taksonomia MITRE ATT&CK w modelowaniu profilu TTP przeciwnika zgodnie z Piramidą Bólu? 10. Jakie 4 fundamentalne pytania należy zadać podczas sesji Post-Mortem w procesie Lessons Learned zgodnie z zasadą blameless postmortem?
Autotest kompetencji analitycznych: Zdolność do samodzielnego przeprowadzenia analizy przyczynowo-skutkowej incydentu, doboru adekwatnych narzędzi telemetrii oraz sformułowania audytowalnego raportu powłamaniowego z planem CAPA. Skróty i pojęcia: CSRC (Computer Security Resource Center, glosariusz NIST: Root Cause Analysis); MTPD (maksymalny tolerowany czas przerwy).
Zestaw Kontrolny 10 Pytań Egzaminacyjnych 1. Objaw vs Przyczyna Źródłowa RCA 2. Ograniczenia Metody 5 Why Liniowość 3. Kategorie Diagramu Ishikawy 5M w IT 4. Analiza RAM vs Obraz Dysku Forensics 5. Rola Wskaźników IoC i MISP STIX/TAXII 6. BIA: Kalkulacja RTO i RPO ISO 22301 7. Różnica SIEM vs SOAR Playbooki 8. EDR vs Antywirus Tradycyjny Fileless 9. Taktyki w Matrycy ATT&CK TTP wroga 10. Pętla Lessons Learned & CAPA Post-Mortem Znajomość odpowiedzi na te pytania gwarantuje zaliczenie modułu analitycznego.
55/55
Literatura, normy i źródła wiedzy do wykładu 3
Cel slajdu: Wskazanie literatury akademickiej, międzynarodowych standardów (ISO, NIST), oficjalnych wytycznych ENISA i CERT Polska oraz repozytoriów narzędziowych.

Kompleksowa bibliografia i baza wiedzy dla studenta

Analiza przyczyn i skutków incydentów opiera się na międzynarodowych standardach inżynierskich i normatywnych. Poniższe źródła stanowią obowiązkową literaturę rozszerzającą wiedzę z wykładu 3, udostępnioną w zweryfikowanych serwisach branżowych.

Uwaga językowa: Dokumenty ISO, NIST, MITRE ATT&CK, MITRE D3FEND, MITRE ATLAS, RFC IETF, FIRST, OASIS STIX/TAXII, SANS, ASQ, CISA, CSA, YARA, Wazuh, Suricata, Snort i Zeek dostępne są wyłącznie w jęz. angielskim i nie mają polskich odpowiedników. Polskie omówienia i wytyczne praktyczne zawierają serwisy CERT Polska (cert.pl, wiedza.cert.pl), CSIRT GOV (csirt.gov.pl), portal Cyber.gov.pl, UODO (uodo.gov.pl) oraz Gov.pl. Akty prawa UE cytowane są w polskojęzycznej wersji EUR-Lex, a ustawy krajowe w serwisie eli.gov.pl.

  • Międzynarodowe normy ISO/IEC: ISO/IEC 27035-1:2023 (Incident management principles), ISO/IEC 27035-2:2023 (Guidelines to plan and prepare for incident response), ISO/IEC 27037:2012 (Guidelines for identification, collection, acquisition and preservation of digital evidence) oraz ISO 22301:2019 (Security and resilience – Business continuity management systems – Requirements).
  • Standardy i przewodniki NIST (USA): NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, NIST SP 800-86 (2006, Guide to Integrating Forensic Techniques into Incident Response), NIST SP 800-92 (Log Management) oraz NIST CSF 2.0.
  • Taksonomie, repozytoria i portale branżowe: Matryca taktyk i technik MITRE ATT&CK Framework, baza środków zaradczych MITRE D3FEND, platforma wymiany wskaźników MISP Project oraz schemat OASIS STIX/TAXII.
  • Krajowe i unijne ramy regulacyjne oraz wytyczne: Ustawa o KSC (tekst jedn. Dz.U. 2026 poz. 20), Rozporządzenie RODO (art. 33-34), oficjalne poradniki i raporty CERT Polska – Raport roczny 2024 oraz wytyczne Prezesa Urzędu Ochrony Danych Osobowych.
Kanon wiedzy oficera śledczego: Zbiór normatywnych i technicznych wytycznych określających formalne standardy prowadzenia analizy przyczynowo-skutkowej, szacowania strat oraz prawnej dopuszczalności dowodów elektronicznych. Skróty i pojęcia: PN (Polska Norma); RFC (Request for Comments, dokumenty IETF); STIX/TAXII (standardy wymiany CTI: OASIS); SANS (instytut branżowy); ASQ (organizacja jakości); CISA (agencja USA); CSA (Cloud Security Alliance); YARA (reguły), Wazuh, Suricata, Snort i Zeek (narzędzia open source przywołane w treści).
Bibliografia i Źródła Normatywne do Modułu 3 Normy ISO/IEC • ISO/IEC 27035-1/2:2023 (Incydenty) • ISO/IEC 27037:2012 (Dowody cyfrowe) • ISO 22301:2019 (Ciągłość działania; kl. 8.2.2 Analiza BIA) • ISO/IEC 27001:2022 (Załącznik A.8.15) Standardy NIST • NIST SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile • NIST SP 800-86 (Digital Forensics) • NIST CSF 2.0 (Govern, Detect, Respond) • NIST SP 800-92 (Log Management) Repozytoria Techniczne • attack.mitre.org (Matryca ATT&CK) • d3fend.mitre.org (Matryca D3FEND) • misp-project.org (Platforma MISP) • oasis-open.github.io (STIX/TAXII) Wytyczne i Przepisy • Dz.U. 2026 poz. 252 (Ustawa o KSC) • RODO (Dz.Urz. UE L 119 - art. 33/34) • cert.pl – Raport roczny 2024 • uodo.gov.pl (Wytyczne naruszeń)