Laboratorium 1

• W1 Zaawansowana ochrona danych szczególnej kategorii (genomika, onkologia, art. 9 RODO) oraz tajemnicy lekarskiej i badawczej.
• W2W3 Rygorystyczna korelacja wymagań NIS2 (art. 21 środki techniczne i organizacyjne), normy ISO/IEC 27001:2022, ISO 27799, ISO/IEC 42001 (zarządzanie AI) oraz KRI.
• U1 Opracowanie zintegrowanej Polityki Bezpieczeństwa Informacji dla hybrydowego środowiska medycznego z modelami AI i klastrem HPC.
• U2 Profesjonalna identyfikacja i formalna gradacja niezgodności w modelu 4C (Condition, Criteria, Cause, Consequence) z analizą przyczyn źródłowych Root Cause Analysis (5 Why).
• U3 Przeprowadzenie analizy ryzyka risk-based w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących, wyznaczenie parametrów RTO (1 godzina) i RPO (15 minut).
• U4 Opracowanie formalnego Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz Podsumowania Zarządczego w formacie Pitch to Board.
• K1K2K3 Etyka, krytyczne myślenie analityczne, profesjonalizm w ochronie życia ludzkiego oraz obrona ustaleń przed zarządem jednostki.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie kompleksowego, symulowanego audytu cyberodporności i zgodności Systemu Zarządzania Bezpieczeństwem Informacji (SZBI) w Państwowym Instytucie Badawczym i Centrum Przetwarzania Danych Onkologicznych. Jednostka podlega pod rygor Dyrektywy NIS2 jako Podmiot Kluczowy sektora ochrony zdrowia, przetwarza wielomilionowe zbiory danych medycznych i genetycznych szczególnej kategorii (art. 9 RODO), podlega Krajowym Ramom Interoperacyjności oraz wdraża algorytmy sztucznej inteligencji (AI/ML) do analizy badań obrazowych PET/CT i histopatologii w chmurze hybrydowej High Performance Computing (HPC). Zadanie ma na celu rozwinięcie umiejętności błyskawicznej triady audytorskiej, sformułowania ustaleń w modelu 4C, kwantyfikacji ryzyka w matrycy 5x5 oraz przygotowania zwięzłego Podsumowania Zarządczego (Executive Summary) dla Dyrekcji Instytutu.

Państwowy Instytut Badawczy Onkologii i Centrum Przetwarzania Danych Klinicznych (CPD-Onko) przetwarza rocznie dane ponad 250 000 pacjentów onkologicznych z całego kraju, w tym pełne sekwencjonowanie DNA, trójwymiarowe skany rezonansu magnetycznego (MRI), tomografii pozytonowej (PET/CT) oraz cyfrową patomorfologię. Instytut posiada własne centrum danych o mocy 1,2 MW połączone z siecią PIONIER oraz dzierżawi zasoby obliczeniowe w chmurze publicznej AWS (Region Frankfurt) w celu trenowania modeli głębokich sieci neuronowych wykrywających wczesne markery nowotworowe.

W ramach przygotowania do certyfikacji ISO 27001 oraz audytu zgodności z Dyrektywą NIS2 zespół audytorski przeprowadził symulowaną inspekcję i ujawnił następujące uchybienia krytyczne:

1. Incydent łańcucha dostaw i wyciek danych pseudoanonimizowanych: Zewnętrzny dostawca zintegrowanego modelu AI (startup medyczny z Cambridge) posiadał stałe, nienadzorowane połączenie VPN typu Site-to-Site do bazy PACS (Picture Archiving and Communication System). W wyniku ataku na repozytorium kodu dostawcy doszło do eksfiltracji ponad 150 000 obrazów diagnostycznych wraz z metadanymi DICOM. Choć usunięto z nagłówków imiona i nazwiska, w metadanych pozostawiono numery PESEL, kody pocztowe oraz sygnatury aparatury, co w świetle wytycznych dotyczących pseudonimizacji Europejskiej Rady Ochrony Danych (ang. EDPB) oraz art. 4 pkt 1 i motywu 26 rozporządzenia (UE) 2016/679 (RODO) stwarza wysokie ryzyko re-identyfikacji pacjentów. Wartość procentowa nie została podana z uwagi na brak wiarygodnych danych źródłowych dla takiego wskaźnika; ocenę należy oprzeć na teście ryzyka ponownej identyfikacji.

2. Brak separacji i podatności w klastrze HPC oraz chmurze hybrydowej: Klaster obliczeniowy HPC wykorzystywany do obróbki genowej działa na współdzielonych uprawnieniach administracyjnych root, a obrazy dysków wirtualnych oraz zasobniki S3 zawierające sekwencjonowanie genomowe nie mają wymuszonego szyfrowania w spoczynku (Encryption at Rest) za pomocą dedykowanych kluczy KMS zarządzanych przez Instytut (Customer Managed Keys).

3. Reżim czasu pracy lekarzy radiologów a polityka uwierzytelniania: Lekarze radiolodzy opisujący badania na dyżurach nocnych korzystają ze stacji roboczych z kartami graficznymi wysokiej rozdzielczości, logując się wspólnym kontem serwisowym dyzur_radiologia_noc, aby uniknąć konieczności ponownego ładowania 40-gigabajtowych plików badań po wylogowaniu poprzednika. Funkcja automatycznego wygaszania ekranu została permanentnie wyłączona w rejestrze systemu Windows.

4. Nieweryfikowana ciągłość działania i brak ochrony przed Ransomware: Kopie zapasowe bazy PACS i systemu HIS wykonywane są codziennie, lecz trafiają na macierz dyskową w tej samej szafie RACK co serwery produkcyjne. Brak jest odizolowanej kopii niemodyfikowalnej (WORM / Air-Gap). Ostatni pełny test odtworzeniowy środowiska (Disaster Recovery Test) przeprowadzono 28 miesięcy temu i zakończył się on błędem spójności baz danych.

Zadanie laboratoryjne realizowane jest w 2-3 osobowych zespołach audytorskich w ściśle zdefiniowanym reżimie czasowym odpowiadającym standardom audytu w warunkach kryzysowych:

• Faza 1 (Minuty 00-15): Triada audytorska i podział ról.
  • Wyznaczenie ról w zespole: Audytor Wiodący (Lead Auditor - koordynacja, compliance NIS2/RODO, Executive Summary), Audytor Techniczny / SecOps (analiza klastra HPC, chmury, sieci PACS, kryptografii), Audytor Procesowy / BCM (analiza ciągłości działania, procedury radiologii, plan CAP).
  • Błyskawiczna analiza dowodów: Identyfikacja kluczowych wektorów ataku i naruszeń regulacyjnych (NIS2 art. 21 ust. 2, RODO art. 9 i art. 32, ISO 27001 Załącznik A.5.19, A.8.12, A.8.20).
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Opracowanie formalnej Karty Niezgodności dla incydentu z modelem AI w schemacie 4C: Condition (Stan faktyczny), Criteria (Kryteria prawne i normatywne), Cause (Przyczyna źródłowa - analiza 5 Why), Consequence (Skutki biznesowe, prawne i zdrowotne).
  • Wykonanie matrycowej analizy ryzyka 5x5 dla 3 kluczowych aktywów (baza PACS, klaster HPC, stacje radiologiczne) z wyliczeniem Ryzyka Inherentnego (IR) oraz Rezydualnego (RR).
  • Wyznaczenie dopuszczalnych wskaźników RTO (Recovery Time Objective) oraz RPO (Recovery Point Objective) dla ratowania życia pacjentów.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa, polityka PBI i Plan CAP.
  • Opracowanie ram nowej Polityki Bezpieczeństwa Informacji i Ochrony Danych Genetycznych: zasady anonimizacji k-anonymity/l-diversity, wdrożenie szyfrowania kopertowego z kluczami HSM, mechanizm Fast-User-Switching i klucze FIDO2 dla radiologów.
  • Sformułowanie Planu Działań Korygujących (CAP) z podziałem na działania natychmiastowe (do 7 dni), krótkoterminowe (do 30 dni) i średnioterminowe (do 90 dni) wraz ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Synteza Executive Summary i obrona przed Zarządem.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary) w układzie: Skala zagrożenia, Ekspozycja prawno-finansowa (kary RODO i NIS2), Wnioskowany budżet CAP, Matryca korzyści (Quick Wins vs Inwestycje Strategiczne).
  • Krótka ustna obrona ustaleń przed prowadzącym laboratorium pełniącym rolę Dyrektora Naczelnego Instytutu. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Końcowy raport z audytu przygotowany przez zespół musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład zespołu audytorskiego, role, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze dla Dyrekcji Instytutu (Executive Summary - 1 strona A4: synteza ryzyka, kluczowe niezgodności, macierz priorytetów zarządczych).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności prawnej (korelacja wymogów: NIS2 Podmiot Kluczowy, RODO art. 9 i 35, KRI, ISO/IEC 27001:2022, ISO 27799).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5:
  • Tabela szacowania prawdopodobieństwa (1-5) i skutku (1-5).
  • Analiza ryzyka inherentnego (IR) oraz rezydualnego (RR) dla: wycieku danych genomowych z klastra HPC, paraliżu bazy PACS przez ransomware, ataku na model AI przez dostawcę.
  • Zdefiniowanie wskaźników BCM: RTO = 1h dla PACS, RPO = 15 min, MTPD = 4h dla diagnostyki onkologicznej.
• Rozdział 4: Projekt Zintegrowanej Polityki Bezpieczeństwa Informacji i Danych Genetycznych:
  • Standard bezpiecznej współpracy z dostawcami AI i zewnętrznymi klastrami HPC (rygor umów DPA i NIS2 art. 21 ust. 2 lit. d).
  • Architektura Zero-Trust dla stacji roboczych radiologii (klucze sprzętowe FIDO2, szybkie przełączanie sesji, separacja mikrosegmentacyjna).
  • Polityka niezmiennych kopii zapasowych (Immutable WORM Backup) i procedury Disaster Recovery.
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Plan Działań Korygujących (CAP) ze wskaźnikami KPI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz ograniczeń wdrożeniowych zaproponowanych rozwiązań.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C dla Incydentu Łańcucha Dostaw AI:
  • Condition (Stan faktyczny): Zewnętrzny dostawca startupu AI posiadał stały, nielimitowany tunel VPN do produkcyjnej bazy PACS. Doszło do eksfiltracji 150 000 skanów DICOM zawierających numery PESEL i kody pocztowe w nagłówkach metadanych.
  • Criteria (Kryterium): ISO/IEC 27001:2022 Załącznik A.5.19, A.5.20, A.8.12 (Zapobieganie wyciekowi danych), Dyrektywa NIS2 art. 21 ust. 2 lit. d (bezpieczeństwo łańcucha dostaw), art. 9 ust. 1 i art. 32 RODO.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego dostawca pobrał dane z PESEL? Bo skrypt anonimizacyjny nie usuwał tagów prywatnych DICOM.

Dlaczego nie usuwał tagów prywatnych? Bo specyfikacja wymagań dla dostawcy nie została zweryfikowana przez IOD.

Dlaczego IOD nie weryfikował integracji? Bo w Instytucie brak procedury weryfikacji projektów B+R pod kątem Privacy by Design.

Dlaczego brak takiej procedury? Bo projekty naukowe traktowano priorytetowo z pominięciem procedur SZBI.

Przyczyna źródłowa: Brak nadrzędnego nadzoru komitetu bezpieczeństwa nad projektami badawczo-rozwojowymi AI i brak izolowanego środowiska Data Clean Room.

• Consequence (Skutki): Ryzyko kary finansowej do 20 mln EUR albo do 4% światowego rocznego obrotu na podstawie art. 83 ust. 5 RODO (przetwarzanie danych szczególnych kategorii, w tym danych genetycznych i zdrowotnych z art. 9 RODO; limit 10 mln EUR lub 2% z art. 83 ust. 4 dotyczy naruszeń innych), sankcje administracyjne z tytułu istotnych naruszeń NIS2 do 10 mln EUR albo 2% światowego rocznego obrotu, a w przypadku utrzymywania naruszenia, zgodnie z art. 34 ust. 5 dyrektywy 2022/2555, do 5 mln EUR albo 2% światowego rocznego obrotu, utrata reputacji naukowej, możliwość szantażu pacjentów danymi o nowotworach.

Prawdopodobieństwo Inherentne: 4 (Częste), Skutek Inherentny: 5 (Katastrofalny - naruszenie tajemnicy genetycznej). Ryzyko Inherentne: 20/25 (Strefa Krytyczna).

Kontrole mitygujące: Szyfrowanie KMS z HSM, mikrosegmentacja klastra, uwierzytelnianie mTLS, audyt uprawnień RBAC.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 3. Ryzyko Rezydualne: 3/25 (Strefa Akceptowalna).

• Zagrożenie 2: Atak ransomware paraliżujący bazę PACS i proces naświetlań onkologicznych.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5. Ryzyko Inherentne: 20/25.

Kontrole mitygujące: Kopie niemodyfikowalne WORM w chmurze AWS S3 Object Lock, separacja sieci medycznej VLAN, EDR z blokadą behawioralną.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Strefa Akceptowalna).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Natychmiastowe zablokowanie tunelu VPN dostawcy i wdrożenie kontrolowanego środowiska Data Clean Room (Termin: 48h, Właściciel: CISO / SecOps, KPI: 0 bezpośrednich połączeń VPN do PACS).
  • CAP-02: Wdrożenie modułu de-identyfikacji DICOM usuwającego wszelkie identyfikatory pośrednie zgodnie z normą DICOM PS 3.15 Aneks E (Termin: 14 dni, Właściciel: Inspektor Ochrony Danych, KPI: 100% zanonimizowanych rekordów poddanych testom re-identyfikacji).
  • CAP-03: Wdrożenie kluczy FIDO2 i szybkiego przełączania sesji Windows Fast User Switching na stacjach radiologicznych (Termin: 30 dni, Właściciel: Kierownik IT, KPI: Likwidacja konta współdzielonego, czas logowania poniżej 3 sekund).
  • CAP-04: Wdrożenie niemodyfikowalnych kopii zapasowych WORM oraz przeprowadzenie pełnego testu Disaster Recovery dla PACS/HIS (Termin: 60 dni, Właściciel: Inżynier Backup / BCM, KPI: Osiągnięcie RTO poniżej 45 minut, RPO poniżej 10 minut).

Zalety rozwiązania:

• Zapewnienie pełnej odporności na ataki ransomware i spełnienie rygorystycznych norm NIS2 dla sektora zdrowia.
• Umożliwienie bezpiecznego rozwoju innowacji medycznych AI dzięki zastosowaniu środowiska Data Clean Room i zaawansowanej de-identyfikacji.
• Wyeliminowanie ryzyk prawnych związanych z wyciekiem danych genomowych i onkologicznych (art. 9 RODO).

Wady i ograniczenia:

• Wysoki koszt infrastrukturalny wdrożenia technologii Data Clean Room i macierzy WORM (szacowany koszt CAPEX: 450 000 PLN).
• Zwiększenie narzutu administracyjnego na zespoły badawcze przy wdrażaniu nowych modeli uczenia maszynowego.
• Konieczność przeszkolenia personelu medycznego w zakresie obsługi kluczy FIDO2 i nowych procedur autoryzacji.

• Źródło internetowe: Dziennik Ustaw 2026 r. poz. 20 (tekst jednolity ustawy o KSC).
• Źródło internetowe: Dziennik Ustaw 2024 r. poz. 632 (tekst jednolity ustawy o ochronie informacji niejawnych).
• Źródło internetowe: RODO (Dz. Urz. UE L 119 z 4.5.2016, tekst skonsolidowany L 127 z 23.5.2018).
• Źródło internetowe: Wytyczne 05/2020 EDPB w sprawie zgody.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii (NIS2), Dz. Urz. UE L 333 z 27.12.2022 – sektor ochrony zdrowia, podmioty kluczowe. Zob. też ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (t.j. Dz.U. z 2026 r. poz. 20) oraz rozporządzenie Komisji (UE) 2022/2446 (Dz. Urz. UE L 333 z 27.12.2022).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO), Dz. Urz. UE L 119 z 4.5.2016, tekst skonsolidowany Dz. Urz. UE L 127 z 23.5.2018 – art. 9 (przetwarzanie szczególnych kategorii danych), art. 32 (bezpieczeństwo przetwarzania), art. 33 (zgłaszanie naruszeń), art. 35 (ocena skutków), art. 83 ust. 5 (sankcje).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.19, A.5.20, A.8.10, A.8.12, A.8.20, A.8.24.
• Norma ISO/IEC 42001:2023 – Information technology – Artificial intelligence – Management system.
• Norma ISO 27799:2016 – Health informatics – Information security management in health using ISO/IEC 27002.
• Wytyczne 05/2020 Europejskiej Rady Ochrony Danych (EDPB) w sprawie zgody na gruncie rozporządzenia (UE) 2016/679, wersja 1.1 z 4 maja 2020 r. Uwaga: w pierwotnej wersji materiału wskazano „Wytyczne EROD 05/2020”, co jest skrótem niewystępującym w aktualnym nazewnictwie; właściwa jest Rada Ochrony Danych Unii Europejskiej (EDPB).
• Standard DICOM Part 15: Security and System Management Profiles (Aneks E – Attribute Confidentiality Profiles).

• W1 Ochrona tajemnic państwowych i informacji o stanie bezpieczeństwa powszechnego oraz infrastruktury krytycznej.
• W2W3 Wymogi Ustawy o KSC, Ustawy o ochronie informacji niejawnych, Rozporządzenia KRI oraz normy ISO 22301 (ciągłość działania) i ISO 27001:2022.
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Informacji dla Centrum Powiadamiania Ratunkowego 112 z procedurami natychmiastowego przełączenia awaryjnego (Failover).
• U2 Klasyfikacja incydentów krytycznych w modelu 4C z analizą 5 Why dla wektora ataku APT.
• U3 Przeprowadzenie analizy ryzyka 5x5 uwzględniającej sabotaż telekomunikacyjny, wyliczenie RTO (15 minut) i RPO (0 minut - synchroniczna replikacja).
• U4 Opracowanie zwięzłego Podsumowania Zarządczego dla Wojewody i Dyrektora Generalnego z precyzyjną hierarchizacją CAP.
• K1K2K3 Zdolność do podejmowania decyzji w warunkach presji czasowej, obrona rekomendacji audytowych przed kierownictwem administracji publicznej.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie audytu bezpieczeństwa teleinformatycznego i procedur zarządzania ciągłością działania (BCM) w Wydziale Bezpieczeństwa i Zarządzania Kryzysowego Urzędu Wojewódzkiego. Wydział koordynuje Wojewódzkie Centrum Powiadamiania Ratunkowego (WCPR - System Obsługi Numerów Alarmowych 112), zarządza systemami ostrzegania ludności oraz przetwarza informacje niejawne o klauzuli Zastrzeżone i Poufne. Jednostka podlega pod rygor Ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), Krajowych Ram Interoperacyjności (KRI) oraz stanowi cel zaawansowanych kampanii szpiegowskich i dezinformacyjnych państwowych grup APT (Advanced Persistent Threat). Zadanie wymaga opracowania procedury odporności na sabotaż teleinformatyczny, karty ustaleń w modelu 4C oraz planu testów Disaster Recovery w 90-minutowym limicie czasowym.

Urząd Wojewódzki obsługuje 3,2 miliona mieszkańców województwa. Wojewódzkie Centrum Powiadamiania Ratunkowego (WCPR) rejestruje średnio 6 500 zgłoszeń alarmowych na dobę, dysponując zintegrowanymi konsolami dyspozytorskimi połączonymi światłowodami z Policją, Państwową Strażą Pożarną oraz Państwowym Ratownictwem Medycznym. W budynku urzędu funkcjonuje również Kancelaria Niejawna oraz Wojewódzkie Centrum Zarządzania Kryzysowego (WCZK).

Podczas doraźnego audytu bezpieczeństwa zainicjowanego po incydentach w regionie ujawniono:

1. Kampania Spear-Phishingowa i brak segmentacji sieci CPR: Dwa tygodnie temu trzej operatorzy numeru 112 otrzymali wiadomości e-mail imitujące wytyczne Ministerstwa Spraw Wewnętrznych i Administracji dotyczące procedur ewakuacyjnych. Jeden z operatorów uruchomił załącznik makro (.docm), co doprowadziło do instalacji złośliwego oprogramowania typu Cobalt Strike Beacon. Ponieważ stacje dyspozytorskie CPR znajdowały się w tej samej logicznej podsieci co ogólny intranet urzędu i serwery pocztowe, intruz uzyskał możliwość nasłuchu ruchu VoIP oraz próbował manipulować tabelami routingu centrali SIP Trunk.

2. Podatności łączy operatorskich i brak zasilania gwarantowanego w węźle BGP: Główny węzeł komunikacyjny CPR podłączony jest do dwóch komercyjnych operatorów telekomunikacyjnych, jednak trasy światłowodowe obu operatorów biegną przez ten sam fizyczny kanał teletechniczny pod ulicą przylegającą do urzędu. Dodatkowo, przełącznik rdzeniowy w węźle zapasowym zasilany jest z pojedynczego UPS-a, którego akumulatory utraciły pojemność (podczas symulacji zaniku napięcia węzeł wyłączył się po 4 minutach).

3. Praca w reżimie niejawnym i procedury nośników: W WCZK do przesyłania meldunków operacyjnych o podwyższonej gotowości wykorzystywane są nieszyfrowane pamięci pendrive, które są na przemian wpinane do stacji z dostępem do Internetu oraz do wydzielonej stacji przetwarzającej meldunki Zastrzeżone, z naruszeniem Ustawy o ochronie informacji niejawnych.

4. Brak aktualizacji i monitorowania SOC: Urząd nie posiada własnego Security Operations Center (SOC) ani podpisanej umowy z CSIRT NASK/GOV na całodobowy monitoring EDR. Zdarzenia z firewalli i kontrolerów domen trafiają do lokalnych plików tekstowych, które są nadpisywane co 7 dni.

• Faza 1 (Minuty 00-15): Triada audytorska i rozpoznanie kryzysowe.
  • Role: Audytor Wiodący (KSC, KRI, raport dla Wojewody), SecOps Auditor (analiza Cobalt Strike, sieci VoIP, segmentacja firewalla), BCM Auditor (procedury CPR 112, zasilanie, redundancja światłowodów).
  • Triage wektora APT: Ustalenie ścieżki eskalacji uprawnień ze stacji operatora do infrastruktury krytycznej 112.
• Faza 2 (Minuty 15-40): Model 4C, Analiza Ryzyka 5x5 i Analiza Przyczyn Źródłowych.
  • Sporządzenie Karty Niezgodności 4C dla ataku na stację dyspozytorską i braku separacji sieci.
  • Przeprowadzenie analizy 5 Why wskazującej, dlaczego stacja obsługi zgłoszeń alarmowych posiadała dostęp do internetowej poczty pracowniczej.
  • Matryca ryzyka 5x5: Oszacowanie prawdopodobieństwa i skutku dla paraliżu linii 112, wycieku meldunków niejawnych i awarii węzła teletechnicznego.
  • Zdefiniowanie celów odporności: RTO = 15 minut dla konsoli dyspozytorskiej, RPO = 0 (zero utraconych połączeń ratunkowych).
• Faza 3 (Minuty 40-70): Projektowanie Polityki Odporności i Plan CAP.
  • Opracowanie Polityki Bezpieczeństwa Systemu 112: Całkowita fizyczna i logiczna izolacja konsol CPR (Air-Gap od intranetu urzędowego), wdrożenie architektury EDR/SIEM zintegrowanej z CSIRT GOV (z Agencji Bezpieczeństwa Wewnętrznego; zgłoszenia przekazuje się przez kanał CSIRT GOV.PL), rygorystyczna polityka USB (sprzętowa blokada portów).
  • Sporządzenie Planu CAP z kamieniami milowymi (48h, 30 dni, 90 dni) i wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i symulacja obrony raportu.
  • Sformułowanie jednostronicowego dokumentu Executive Summary dla Wojewody z rekomendacją wniosku o rezerwę celową budżetu państwa na cyberbezpieczeństwo.
  • Ustna prezentacja wyników i obrona planu mitygacji przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytu państwowego i zawierać:

• Strona tytułowa i Metryka Audytu (zespół, akredytacja wewnętrzna, klauzula poufności).
• Rozdział 1: Executive Summary dla Wojewody i Dyrektora Generalnego Urzędu Wojewódzkiego (1 strona A4: ocena gotowości obronnej, krytyczne luki, bilans nakładów do korzyści).
• Rozdział 2: Ramy prawne i specyfikacja wymagań (Ustawa o KSC, KRI, Ustawa o ochronie informacji niejawnych, ISO 27001, ISO 22301).
• Rozdział 3: Matryca Analizy Ryzyka 5x5 (przed i po mitygacji) wraz z kalkulacją parametrów RTO/RPO i wskaźnika MTPD dla dyspozytorni ratunkowej.
• Rozdział 4: Projekt Zintegrowanej Polityki Bezpieczeństwa Teleinformatycznego WCPR i Urzędu:
  • Architektura bezpiecznej dyspozytorni: odseparowana sieć zamknięta OT-112, dedykowane serwery SIP bez dostępu do Internetu.
  • Procedura bezpiecznego przetwarzania meldunków operacyjnych i obsługa stacji bezpiecznych Kancelarii Niejawnej.
  • Plan Ciągłości Działania (BCP) i procedura natychmiastowego przełączenia ruchu na zapasowe CPR w sąsiednim województwie (Inter-WCPR Failover).
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Ocena ograniczeń technicznych, finansowych (prawo zamówień publicznych) oraz harmonogram wdrożenia.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Konsola dyspozytorska numeru 112 miała bezpośredni dostęp do Internetu i poczty elektronicznej urzędu; infekcja Cobalt Strike doprowadziła do infiltracji stacji i prób modyfikacji routingu SIP.
  • Criteria: Ustawa o KSC art. 8-10, KRI (rozporządzenie Rady Ministrów z 21 maja 2024 r., Dz.U. z 2024 r. poz. 773) par. 19 ust. 2 pkt 3, 7, 9 i 12, w zakresie ochrony przed złośliwym oprogramowaniem, aktualizacji, zarządzania podatnościami i kontroli dostępu; separację sieci opracowuje się na podstawie PN-EN ISO/IEC 27001:2022 (A.8.22). Uwaga: par. 20 ust. 2 rozporządzenia obejmuje wyłącznie punkty 1-3 i dotyczy rozliczalności oraz logowania zdarzeń, ISO 27001 Załącznik A.8.20, A.8.22.
  • Cause (5 Why):

Dlaczego doszło do infekcji? Operator otworzył złośliwy załącznik w poczcie.

Dlaczego poczta była odbierana na konsoli 112? Bo operatorzy używali stacji ratunkowej do celów administracyjnych.

Dlaczego stacja miała dostęp do poczty? Bo wdrożono wspólną sieć LAN dla oszczędności na okablowaniu.

Dlaczego kierownictwo zaakceptowało wspólną sieć? Bo nie przeprowadzono analizy ryzyka dla infrastruktury krytycznej WCPR.

Przyczyna źródłowa: Brak sformalizowanych zasad separacji systemów krytycznych życia i zdrowia od infrastruktury biurowej urzędu oraz brak nadzoru CISO.

• Consequence: Ryzyko całkowitej blokady numeru alarmowego 112 dla 3,2 mln obywateli, opóźnienia w dysponowaniu karetek pogotowia i straży pożarnej, utrata zaufania do organów państwa, naruszenie bezpieczeństwa narodowego.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5. Ryzyko Inherentne: 20/25 (Krytyczne).

Kontrole: Fizyczny Air-Gap dla sieci konsol operatorskich, proxy SIP z inspekcją DPI, wdrożenie agentów EDR zintegrowanych z CSIRT GOV (z Agencji Bezpieczeństwa Wewnętrznego; zgłoszenia przekazuje się przez kanał CSIRT GOV.PL).

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 3. Ryzyko Rezydualne: 3/25 (Akceptowalne).

• Zagrożenie 2: Równoczesne przerwanie kabli światłowodowych we wspólnym wykopie teletechnicznym.

Prawdopodobieństwo Inherentne: 3, Skutek Inherentny: 5. Ryzyko Inherentne: 15/25 (Wysokie).

Kontrole: Budowa drugiego, niezależnego przyłącza światłowodowego z przeciwległej strony kwartału ulicznego oraz zapasowe łącze radioliniowe w paśmie chronionym 80 GHz.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Izolacja konsol dyspozytorskich WCPR do wydzielonego VLAN z całkowitą blokadą dostępu do WWW i poczty zewnętrznej (Termin: 24h, Właściciel: Dyrektor Wydziału IT, KPI: 0 pakietów z konsoli 112 do Internetu).
  • CAP-02: Wymiana baterii UPS w węźle BGP oraz instalacja dedykowanego agregatu prądotwórczego z automatyką SZR (Termin: 30 dni, Właściciel: Wydział Administracyjno-Gospodarczy, KPI: Czas podtrzymania min. 72 godziny).
  • CAP-03: Wdrożenie stacji roboczych z dwoma fizycznie odseparowanymi środowiskami (stacja dwusieciowa z przełącznikiem KVM dla Internetu i sieci 112) (Termin: 45 dni, Właściciel: Kierownik WCPR, KPI: 100% stanowisk spełniających wymóg separacji).
  • CAP-04: Przeprowadzenie pełnego testu awaryjnego przełączenia zgłoszeń 112 do sąsiedniego województwa w czasie poniżej 10 minut (Termin: 60 dni, Właściciel: Wojewódzki Koordynator Ratownictwa, KPI: 0 utraconych połączeń w trakcie testu przełączenia).

Zalety rozwiązania:

• Bezwzględne zapewnienie ciągłości działania numeru 112 i odporności na ataki APT.
• Zgodność z wymogami Ustawy o KSC, Ustawy o ochronie informacji niejawnych oraz KRI.
• Zapewnienie pełnej redundancji infrastruktury zasilania i telekomunikacji.

Wady i ograniczenia:

• Konieczność wygospodarowania dodatkowych środków budżetowych w procedurze zamówień publicznych (szacunek: 850 000 PLN).
• Utrudnienie pracy operatorów zmuszonych do korzystania z dwóch odrębnych monitorów/klawiatur (rozwiązane przez certyfikowane przełączniki Secure KVM).
• Długi czas oczekiwania na formalne zgody budowlane dotyczące wykonania niezależnego przekopu teletechnicznego.

• Źródło internetowe: Wytyczne 9/2022 EDPB dotyczące zgłaszania naruszeń ochrony danych (wersja 2.0).
• Źródło internetowe: Krajowe Ramy Interoperacyjności (Dz.U. z 2024 r. poz. 773).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (t.j. Dz.U. z 2026 r. poz. 20).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2024 r. poz. 773).
• Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. z 2024 r. poz. 632).
• Ustawa z dnia 22 listopada 2013 r. o systemie powiadamiania ratunkowego (Dz.U. z 2023 r. poz. 748).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.20, A.8.22, A.8.24, A.8.31.
• Norma PN-EN ISO 22301:2020-04 – Bezpieczeństwo i odporność – Systemy zarządzania ciągłością działania – Wymagania.
• Wytyczne 9/2022 Europejskiej Rady Ochrony Danych (EDPB) dotyczące zgłaszania naruszeń ochrony danych osobowych na podstawie RODO, wersja 2.0 przyjęta 28 marca 2023 r. (obowiązek zgłoszenia bez zbędnej zwłoki, a gdy nie jest to możliwe, w terminie do 72 godzin od momentu stwierdzenia naruszenia, na podstawie art. 33 ust. 1 RODO). Uwaga: dokument ten zastępuje wytyczne WP250 rev.01 Grupy Roboczej Art. 29 z 2017 r. oraz wytyczne 01/2022, które nie są aktualne.
• Uwaga o weryfikacji źródeł: w pierwotnej wersji materiału wskazano „Wytyczne Pełnomocnika Rządu ds. Cyberbezpieczeństwa, Standardy cyberbezpieczeństwa dla jednostek samorządu terytorialnego, Warszawa 2023”. Dokument ten nie został zidentyfikowany w dostępnych źródłach i wymaga weryfikacji w Kancelarii Prezesa Rady Ministrów przed powołaniem się na niego w pracy.

• W1 Ochrona własności przemysłowej, patentów, tajemnic przedsiębiorstwa oraz technologii Dual-Use podlegających kontroli eksportowej.
• W2W3 Wymogi Ustawy Prawo o szkolnictwie wyższym i nauce, Ustawy o kontroli obrotu z zagranicą towarami o znaczeniu strategicznym (WSK), ISO/IEC 27001:2022 oraz KRI.
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Informacji Badawczej łączącej otwarte środowisko kampusowe z laboratoryjną strefą bezpieczną (SCIF/Cleanroom).
• U2 Formułowanie kart niezgodności w modelu 4C dla wektorów eksfiltracji danych badawczych.
• U3 Szacowanie ryzyka w matrycy 5x5 dla kradzieży własności intelektualnej przez obcy wywiad gospodarczy.
• U4 Opracowanie zwięzłego Podsumowania Zarządczego dla Rektora i Prorektora ds. Nauki z planem CAP.
• K1K2K3 Zdolność do wyważenia rygorów bezpieczeństwa państwa i wolności akademickiej, postawa etyczna i krytyczna ocena procedur uniwersyteckich.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie audytu bezpieczeństwa informacji i ochrony własności intelektualnej w Międzywydziałowym Centrum Zaawansowanych Badań Kwantowych i Półprzewodnikowych czołowej uczelni technicznej. Centrum realizuje strategiczne granty finansowane przez Europejską Radę ds. Badań (ERC), Europejską Agencję Obrony (EDA) oraz Narodowe Centrum Badań i Rozwoju (NCBR) w obszarze kryptografii postkwantowej oraz technologii wytwarzania układów scalonych GaN. Projekty te podlegają przepisom o technologiach podwójnego zastosowania (Dual-Use), a uczelnia jako całość charakteryzuje się tradycyjnie otwartą kulturą akademicką (sieć Eduroam, publiczne serwery repozytoriów, rotacja stażystów zagranicznych). Zadanie wymaga zaprojektowania hybrydowej architektury bezpieczeństwa, która zapewni bezwzględną ochronę tajemnicy badawczej i patentowej przed szpiegostwem technologicznym, zachowując jednocześnie swobodę dydaktyczną uczelni.

Centrum Badawcze zatrudnia 85 naukowców, w tym 30 doktorantów i stażystów zagranicznych z całego świata. Centrum posiada laboratorium czystej przestrzeni (Cleanroom ISO 5) ze skanerem litograficznym oraz klaster superkomputerowy symulujący łamanie algorytmów kryptograficznych RSA i ECC przez komputery kwantowe.

Audytorzy zewnętrzni powołani w związku z przygotowaniem do audytu certyfikacyjnego ujawnili:

1. Eksfiltracja danych przez otwarte repozytoria i chmury publiczne: Badacze powszechnie używali publicznego serwisu GitHub oraz prywatnych dysków Google Drive do wymiany kodów źródłowych algorytmów postkwantowych. W jednym z publicznych repozytoriów doktorant umieścił pliki konfiguracyjne zawierające klucze dostępu do laboratoryjnego serwera obliczeniowego. Repozytorium zostało zaindeksowane przez roboty sieciowe i pobrane przez nieznany adres IP zlokalizowany w Azji Wschodniej.

2. Niekontrolowana aparatura badawcza i routery cieni (Shadow IT): W komorze Cleanroom aparatura pomiarowa (oscyloskopy cyfrowe i spektrometry masowe) działa pod kontrolą przestarzałych systemów operacyjnych Windows XP Embedded, których producent nie wspiera od lat. Ponieważ uczelniane IT odmówiło podłączenia tych maszyn do sieci kampusowej, jeden z profesorów zainstalował w Cleanroomie prywatny bezprzewodowy router komórkowy 5G/LTE podpięty bezpośrednio do portu Ethernet spektrometru, tworząc niekontrolowane przejście omijające firewall uczelni.

3. Brak procedur weryfikacji personelu i rotacji gości (Background Screening): Zagraniczni naukowcy wizytujący otrzymywali bezterminowe karty zbliżeniowe dające pełny dostęp do wszystkich laboratoriów Centrum 24/7, bez weryfikacji w ramach Wewnętrznego Systemu Kontroli (WSK) i bez podpisywania umów o poufności (NDA) z klauzulami kar umownych. Po zakończeniu pobytu karty dostępowe nie były dezaktywowane w systemie KD.

4. Niezabezpieczone stacje robocze i brak polityki czystego ekranu: W laboratoriach stacje podłączone do mikroskopów elektronowych pozostawały zalogowane na uprawnieniach administratora lokalnego. Na biurkach obok stacji odnaleziono niezabezpieczone nośniki USB zawierające pliki projektowe masek fotolitograficznych dla układów scalonych.

• Faza 1 (Minuty 00-15): Triada audytorska i mapowanie wektorów ryzyka.
  • Role: Lead Auditor (audyt zgodności z WSK, KRI, raport dla Rektora), SecOps Auditor (analiza Shadow IT, router 5G, Windows XP, GitHub), Compliance/HR Auditor (badanie umów NDA, rotacja naukowców, kontrola dostępu fizycznego).
  • Mapowanie regulacji: Rozporządzenie UE 2021/821 (kontrola towarów podwójnego zastosowania), ISO 27001 Załącznik A.5.10, A.8.1, A.8.12, A.8.20.
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Opracowanie Karty Niezgodności 4C dla wycieku kodu na publiczny GitHub oraz instalacji routera 5G w Cleanroomie.
  • Przeprowadzenie analizy 5 Why wyjaśniającej, dlaczego profesor zainstalował nieautoryzowany router (zderzenie potrzeb badawczych z restrykcjami IT).
  • Oszacowanie ryzyka w matrycy 5x5: Utrata praw patentowych na skutek przedwczesnego ujawnienia, sankcje karne za naruszenie przepisów o obrocie z zagranicą towarami o znaczeniu strategicznym (art. 33 ust. 1 ustawy z 29 listopada 2000 r. o obrocie z zagranicą, grożba pozbawienia wolności od roku do lat 10, oraz art. 37-39 w zakresie kar pieniężnych) oraz odpowiedzialność karna z art. 340 § 1 Kodeksu karnego za handel technologiami wojskowymi (podwójnego zastosowania), infekcja sieci laboratoryjnej przez podatności Windows XP.
• Faza 3 (Minuty 40-70): Projekt Polityki Bezpieczeństwa Badań i Plan CAP.
  • Projekt procedur: Wdrożenie uczelnianego, lokalnego repozytorium GitLab z funkcją Secret Scanning i Data Loss Prevention (DLP), koncepcja enklawy laboratoryjnej z wirtualną siecią odizolowaną (VLAN z inspekcją NGFW i wirtualnym łataniem Virtual Patching dla Windows XP), procedura Offboardingu i weryfikacji WSK.
  • Tabela Planu Działań Korygujących (CAP) ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i symulacja obrony przed Senatem Uczelni.
  • Opracowanie 1-stronicowej noty dla Kolegium Rektorskiego uzasadniającej konieczność zbalansowania otwartości akademickiej i ochrony tajemnic państwowych.
  • Obrona ustaleń w symulacji przed prowadzącym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Brak danych.

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy powinien zawierać:

• Strona tytułowa i Metryka Audytu (zespół, role, data, zakres audytu).
• Rozdział 1: Executive Summary dla Rektora i Dziekanów (1 strona A4: bilans strat wizerunkowych i finansowych w razie utraty patentów, rekomendacje priorytetowe).
• Rozdział 2: Profil prawny technologii podwójnego zastosowania (Dual-Use) i reżim WSK (Ustawa o kontroli obrotu, ISO 27001, KRI).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 (identyfikacja aktywów badawczych, wektory szpiegostwa naukowego, wyliczenie IR i RR).
• Rozdział 4: Projekt Zintegrowanej Polityki Bezpieczeństwa Informacji Badań Naukowych:
  • Standard Bezpiecznego Cyklu Wytwarzania Oprogramowania Naukowego (Secure SDLC, kontrola kodu, brak publicznych repozytoriów dla projektów grantowych).
  • Zasady izolacji i bezpiecznego podłączania aparatury legacy (Windows XP w strefie DMZ aparatury z mikro-firewallem przemysłowym).
  • Procedura weryfikacji personelu naukowego, obowiązkowe szkolenia Security Awareness i procedury zdawania uprawnień.
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet i kompromisów pomiędzy otwartością naukową a cyberodpornością.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C dla Incydentu Shadow IT i Ujawnienia Kodu:
  • Condition: Kody źródłowe algorytmów kryptograficznych Dual-Use publikowane na publicznym GitHubie z kluczami API; w Cleanroomie zainstalowano nieautoryzowany router komórkowy 5G omijający firewall.
  • Criteria: Ustawa z dnia 29 listopada 2000 r. o obrocie z zagranicą towarami o znaczeniu strategicznym (art. 6 i 11), ISO/IEC 27001:2022 Załącznik A.8.1, A.8.12, A.8.20, A.8.24.
  • Cause (5 Why):

Dlaczego router 5G znalazł się w Cleanroomie? Bo naukowiec musiał przesyłać dane z aparatury, a uczelniane IT zablokowało porty dla Windows XP.

Dlaczego IT zablokowało porty bez rozwiązania alternatywnego? Bo brakowało procedury dedykowanej dla urządzeń aparatury medyczno-badawczej.

Dlaczego naukowcy użyli publicznego GitHuba? Bo uczelnia nie zapewniała oficjalnej, wygodnej platformy wymiany kodu z zewnętrznymi partnerami naukowymi.

Dlaczego nie zapewniła? Bo zarząd uczelni postrzegał IT wyłącznie jako wsparcie dydaktyki, a nie strategiczny zasób ochrony badań.

Przyczyna źródłowa: Brak strategii zarządzania cyberbezpieczeństwem badań naukowych i brak dialogu pomiędzy działem IT a zespołami badawczymi.

• Consequence: Ryzyko bezpowrotnej utraty nowości patentowej (brak możliwości uzyskania patentu w EPO/UPRP), zerwanie kontraktów badawczych z EDA i NCBR, sankcje karne dla kierownika grantu z ustawy o WSK (kara pozbawienia wolności do lat 10).

Prawdopodobieństwo Inherentne: 5, Skutek Inherentny: 5. Ryzyko Inherentne: 25/25 (Maksymalne).

Kontrole: Usunięcie routera 5G, fizyczne zablokowanie portów USB (zaślepki Smart-Kee), mikro-segmentacja aparatury Windows XP za zaporą sprzętową z Virtual Patching, system DLP na stacjach roboczych.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 3. Ryzyko Rezydualne: 3/25 (Akceptowalne).

• Zagrożenie 2: Przypadkowy wyciek kluczy i patentów przez publiczne repozytoria kodu.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5. Ryzyko Inherentne: 20/25.

Kontrole: Wdrożenie uczelnianego GitLab Enterprise z blokadą pushów zawierających sekrety, szkolenia dla doktorantów.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Bezwzględny demontaż prywatnego routera 5G i wdrożenie dedykowanego VLAN aparatury badawczej zabezpieczonego firewallem przemysłowym z inspekcją IPS (Termin: 24h, Właściciel: Kierownik Sekcji Sieci IT, KPI: 0 urządzeń Shadow IT wykrytych w audycie radiowym).
  • CAP-02: Uruchomienie uczelnianej platformy GitLab On-Premise zintegrowanej z uczelnianym Active Directory oraz automatycznym skanerem wycieków (Termin: 14 dni, Właściciel: Główny Architekt IT, KPI: Migracja 100% projektów grantowych z GitHuba).
  • CAP-03: Wdrożenie procedury akredytacji gości naukowych i audytu kart zbliżeniowych powiązanego z automatyczną dezaktywacją po wygaśnięciu kontraktu (Termin: 30 dni, Właściciel: Pełnomocnik ds. Ochrony Informacji Niejawnych / HR, KPI: 0 aktywnych kart dla byłych pracowników).
  • CAP-04: Wprowadzenie obligatoryjnego kursu e-learningowego z bezpieczeństwa własności intelektualnej i WSK dla wszystkich pracowników naukowych i doktorantów (Termin: 60 dni, Właściciel: Prorektor ds. Nauki, KPI: 100% przeszkolonego personelu).

Zalety rozwiązania:

• Skuteczna ochrona wielomilionowych grantów i praw własności przemysłowej przed kradzieżą.
• Spełnienie restrykcyjnych wymogów prawa międzynarodowego w zakresie towarów podwójnego zastosowania (Dual-Use).
• Wzrost zaufania międzynarodowych agencji badawczych (EDA, ERC, DARPA) do uczelni jako bezpiecznego partnera technologicznego.

Wady i ograniczenia:

• Początkowy opór części kadry profesorskiej przyzwyczajonej do całkowitej swobody instalacji własnego sprzętu.
• Koszty licencyjne oprogramowania klasy GitLab Enterprise oraz zapór przemysłowych dla aparatury badawczej (szacunek: 280 000 PLN).
• Konieczność stałego nadzoru nad procedurami WSK i corocznej re-akredytacji uprawnień.

• Źródło internetowe: Rozporządzenie (UE) 2021/821 (system kontroli wywozu).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2021/821 z dnia 20 maja 2021 r. ustanawiające unijny system kontroli wywozu, pośrednictwa, pomocy technicznej, tranzytu i transferu produktów podwójnego zastosowania (Dual-Use) (Dz. Urz. UE L 206 z 30.6.2021, s. 1). Uwaga: jest to rozporządzenie Parlamentu Europejskiego i Rady, a nie rozporządzenie delegowane Komisji.
• Ustawa z dnia 29 listopada 2000 r. o obrocie z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym dla bezpieczeństwa państwa, a także dla utrzymania międzynarodowego pokoju i bezpieczeństwa (Dz.U. z 2023 r. poz. 1582).
• Ustawa z dnia 30 czerwca 2000 r. – Prawo własności przemysłowej (Dz.U. z 2023 r. poz. 1170).
• Ustawa z dnia 20 lipca 2018 r. – Prawo o szkolnictwie wyższym i nauce (Dz.U. z 2023 r. poz. 742).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.10, A.5.14, A.8.1, A.8.12, A.8.20, A.8.24.
• Ustawa z dnia 10 sierpnia 2010 r. o ochronie informacji niejawnych (t.j. Dz.U. z 2024 r. poz. 632) – w zakresie ochrony wyników badań niejawnych oraz ochrony informacji niejawnych w systemach teleinformatycznych (art. 1 ust. 1 pkt 7). Uwaga: wskazane w pierwotnej wersji materiału „Wytyczne ABW, Bezpieczeństwo badań naukowych i transferu wiedzy w realiach zagrożeń obcym wywiadem gospodarczym, Warszawa 2023” nie zostały zidentyfikowane w dostępnych źródłach i wymagają weryfikacji w ABW.

• W1 Ochrona infrastruktury krytycznej państwa, tajemnic przedsiębiorstwa oraz informacji poufnych w rozumieniu Rozporządzenia MAR.
• W2W3 Wymogi Ustawy o KSC, Dyrektywy NIS2, normy ISO/IEC 27001:2022, normy PN-EN ISO 22301 oraz standardu ISA/IEC 62443 (bezpieczeństwo systemów automatyki przemysłowej).
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Systemów OT/SCADA uwzględniającej model Purdue i strefy bezpieczeństwa (Conduits & Zones).
• U2 Dokumentowanie krytycznych ustaleń audytowych w modelu 4C z analizą 5 Why dla wektora ataku przez zewnętrzny serwis turbin i transformatorów.
• U3 Przeprowadzenie analizy ryzyka 5x5 uwzględniającej blackout regionalny, wyliczenie parametrów RTO (30 minut) i RPO (0 minut dla telemechaniki).
• U4 Opracowanie profesjonalnego Planu Działań Korygujących (CAP) oraz wystąpienia przed Komitetem Audytu Rady Nadzorczej.
• K1K2K3 Profesjonalizm inżynierski, bezkompromisowość w ochronie życia obywateli i stabilności sieci przesyłowej państwa.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie audytu bezpieczeństwa i odporności cybernetycznej systemów sterowania przemysłowego (OT/SCADA) w spółce giełdowej będącej Operatorem Usługi Kluczowej (OUK) w sektorze elektroenergetycznym. Przedsiębiorstwo zarządza regionalnymi Głównymi Punktami Zasilania (GPZ), podstacjami wysokiego napięcia (110kV/15kV) oraz zautomatyzowanym systemem dyspozytorskim SCADA. Spółka podlega pod rygor Dyrektywy NIS2, Ustawy o Krajowym Systemie Cyberbezpieczeństwa, standardu przemysłowego ISA/IEC 62443 oraz Rozporządzenia MAR (Market Abuse Regulation) ze względu na notowanie akcji na Giełdzie Papierów Wartościowych. Zadanie wymaga przeanalizowania incydentu wprowadzenia złośliwego kodu do sieci stacyjnej, sformułowania ustaleń w modelu 4C, wyliczenia ryzyka katastrofy energetycznej w matrycy 5x5 oraz przygotowania Planu CAP i wystąpienia przed Radą Nadzorczą.

Spółka EnergoDystrybucja S.A. zarządza siecią dystrybucyjną zasilającą 1,8 miliona odbiorców indywidualnych oraz 45 strategicznych zakładów przemysłowych. Centralny System Dyspozytorski SCADA komunikuje się z 80 stacjami GPZ za pośrednictwem protokołów IEC 60870-5-104 oraz DNP3.

Podczas niezależnego audytu bezpieczeństwa przeprowadzonego na zlecenie Komitetu Audytu Rady Nadzorczej stwierdzono:

1. Złamanie strefy IDMZ i infekcja w sieci OT: Inżynier zewnętrznego producenta turbin i zabezpieczeń elektroenergetycznych podłączył swój serwisowy laptop bezpośrednio do magistrali stacyjnej GPZ w celu rekonfiguracji sterownika PLC (Programmable Logic Controller). Laptop inżyniera był wcześniej zainfekowany złośliwym oprogramowaniem typu Wiper/Ransomware ukierunkowanym na protokoły przemysłowe. Ze względu na brak demilitaryzowanej strefy przemysłowej (Industrial DMZ wg modelu Purdue) oraz brak inspekcji pakietów w sieci stacyjnej doszło do rozprzestrzenienia szkodliwego kodu na trzy sterowniki polowe, powodując okresowe samoczynne rozłączanie wyłączników mocy 110kV.

2. Brak szyfrowania i uwierzytelniania w protokołach telemechaniki: Komunikacja pomiędzy nadrzędnym systemem SCADA a sterownikami stacyjnymi prowadzona jest w postaci otwartego tekstu (plain-text) z wykorzystaniem protokołu IEC 60870-5-104, bez implementacji standardu IEC 62351 (kryptografia i uwierzytelnianie w automatyce elektroenergetycznej). Umożliwia to przeprowadzenie ataku typu Man-in-the-Middle i fałszowanie wskazań telemetrii napięć i prądów.

3. Zdalny dostęp serwisowy bez MFA: 12 zewnętrznych podwykonawców posiadało stały dostęp zdalny do stacji inżynierskich SCADA za pośrednictwem nieskonfigurowanych modemów komórkowych LTE zainstalowanych w szafach telemechaniki, z pominięciem centralnego tunelu VPN spółki i bez wymogu uwierzytelniania wieloskładnikowego (MFA). Hasła dostępowe do routerów komórkowych nie były zmieniane od 4 lat.

4. Presja regulacyjna MAR i brak procedury komunikacji incydentu: W związku z okresowymi wyłączeniami mocy pojawiło się ryzyko nałożenia kar przez Urząd Regulacji Energetyki (URE) oraz konieczności opublikowania raportu bieżącego na GPW zgodnie z art. 17 Rozporządzenia MAR (opóźnienie informacji poufnej). Zarząd spółki nie posiadał zdefiniowanej ścieżki eskalacji incydentu cybernetycznego do Departamentu Relacji Inwestorskich.

• Faza 1 (Minuty 00-15): Triada audytorska i model Purdue.
  • Role: Lead Auditor (koordynacja, NIS2, MAR, raport dla Rady Nadzorczej), Industrial SecOps Auditor (analiza IEC 62443, protokołów IEC 60870-5-104, modelu Purdue, laptopa serwisowego), Compliance/Legal Auditor (wymogi URE, KSC, zgłaszanie incydentów do CSIRT sektorowego z zachowaniem terminów z art. 11 ust. 1 pkt 4, 4a i 4c ustawy o KSC: 24 godziny na wczesne ostrzeżenie, 72 godziny na zgłoszenie incydentu poważnego, miesiąc na sprawozdanie końcowe).
  • Analiza naruszenia modelu Purdue: Wyznaczenie poziomów 0-3 (proces fizyczny, sterowniki, SCADA) oraz zbadanie nieautoryzowanych mostków LTE i braku IDMZ (Poziom 3.5).
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Sformułowanie Karty Niezgodności 4C dla bezpośredniego wpięcia laptopa serwisowego i braku strefy IDMZ.
  • Analiza 5 Why: Dlaczego zewnętrzny serwisant mógł wpiąć zainfekowany laptop bez kontroli?
  • Matryca ryzyka 5x5: Oszacowanie skutków awarii kaskadowej sieci (blackout regionalny) oraz manipulacji wskazaniami telemetrii.
  • Wyznaczenie krytycznych wskaźników ciągłości: RTO = 30 minut dla odzyskania widoczności SCADA, RPO = 0 minut dla rejestracji zdarzeń zakłóceniowych.
• Faza 3 (Minuty 40-70): Projekt Polityki Bezpieczeństwa OT i Plan CAP.
  • Projekt Zintegrowanej Polityki Cyberbezpieczeństwa Automatyki Elektroenergetycznej: Wdrożenie stref i kanałów (Zones & Conduits) wg IEC 62443, demontaż modemów LTE na korzyść centralnego rozwiązania Secure Remote Access (SRA) z bastionem PAM i sesją nagrywaną, wdrożenie stacji czyszczących (Sheep-Dip Station) dla nośników i laptopów zewnętrznych.
  • Plan Działań Korygujących (CAP) ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i symulacja przed Radą Nadzorczą.
  • Przygotowanie zwięzłego Executive Summary dla Komitetu Audytu Rady Nadzorczej z uwzględnieniem skutków giełdowych (MAR) i kar URE/KSC.
  • Ustna prezentacja i obrona ustaleń przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytu przemysłowego i zawierać:

• Strona tytułowa i Metryka Audytu (skład zespołu, certyfikaty audytorów, zakres audytu).
• Rozdział 1: Executive Summary dla Komitetu Audytu Rady Nadzorczej (1 strona A4: syntetyczna ocena ryzyka blackoutu, ekspozycja MAR, plan finansowy CAP).
• Rozdział 2: Ramy regulacyjne i standardy przemysłowe (NIS2, Ustawa o KSC, ISA/IEC 62443, ISO 27001:2022, Rozporządzenie MAR).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 dla stacji elektroenergetycznych GPZ (analiza scenariusza ataku typu Cyber-Blackout, wyliczenie IR i RR).
• Rozdział 4: Projekt Polityki Bezpieczeństwa Informacji i Systemów OT/SCADA:
  • Segmentacja sieci przemysłowej zgodnie z modelem Purdue (separacja Poziomów 0-3 od Poziomu 4 IT przez rygorystyczne IDMZ).
  • Procedura bezpiecznego dostępu serwisowego firm trzecich (koncepcja stacji pośredniczącej PAM, brak bezpośrednich łączy komórkowych).
  • Polityka wprowadzania urządzeń i nośników zewnętrznych (stacja sterylizacji i skanowania antymalware przed wpięciem do magistrali).
  • Procedura raportowania incydentów do CSIRT sektorowego oraz koordynacja z rynkiem kapitałowym (komitet MAR).
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet, barier technologicznych (aparatury starszej generacji) oraz kosztów wdrożenia.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Inżynier zewnętrznego serwisu podłączył zainfekowany laptop bezpośrednio do sieci stacyjnej GPZ bez weryfikacji; w szafach telemechaniki wykryto nieautoryzowane modemy LTE ze stałymi hasłami fabrycznymi.
  • Criteria: Dyrektywa NIS2 art. 21 ust. 2 lit. d (bezpieczeństwo łańcucha dostaw), Ustawa o KSC art. 10 (odporność systemów teleinformatycznych OUK), standard ISA/IEC 62443-3-3 (wymogi kontroli bezpieczeństwa systemu), ISO 27001 Załącznik A.8.20, A.8.22.
  • Cause (5 Why):

Dlaczego doszło do infekcji sterowników PLC? Bo laptop serwisanta miał bezpośredni dostęp do sieci procesowej.

Dlaczego miał bezpośredni dostęp? Bo w stacji GPZ brakowało strefy IDMZ i punktu kontroli dostępu.

Dlaczego serwisanci używali modemów LTE? Bo oficjalny proces wnioskowania o dostęp VPN przez centralne IT trwał 3 tygodnie.

Dlaczego proces trwał tak długo? Bo IT nie rozumiało specyfiki pracy dyspozytury i awarii w ruchu ciągłym.

Przyczyna źródłowa: Brak zintegrowanego ładu zarządczego IT/OT (brak strategii konwergencji IT/OT) oraz brak procedury awaryjnego dostępu uprzywilejowanego (Break-Glass PAM) dla technologii przemysłowych.

• Consequence: Ryzyko rozległego blackoutu w regionie (brak zasilania szpitali, transportu, przemysłu), kary URE i KSC do wysokości 10 mln EUR albo 2% światowego rocznego obrotu, a w przypadku utrzymywania naruszenia zgodnie z art. 34 ust. 5 dyrektywy NIS2 do 5 mln EUR albo 2% światowego rocznego obrotu, oraz kary Prezesa Urzędu Regulacji Energetyki z tytułu naruszeń z art. 11 lub art. 15 ustawy o KSC, odpowiedzialność osobista członków Zarządu na mocy NIS2, spadek kursu akcji na GPW i zarzuty zatajenia informacji poufnej (MAR).

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5 (Katastrofalny). Ryzyko Inherentne: 20/25 (Krytyczne).

Kontrole: Implementacja zapory sieciowej nowej generacji OT (Deep Packet Inspection dla protokołów przemysłowych), wdrożenie standardu IEC 62351 (szyfrowanie TLS dla telemechaniki), system wykrywania anomalii przemysłowych (OT IDS).

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 3. Ryzyko Rezydualne: 3/25 (Akceptowalne).

• Zagrożenie 2: Wprowadzenie ransomware przez zainfekowane laptopy podwykonawców.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 4. Ryzyko Inherentne: 16/25 (Wysokie).

Kontrole: Zakaz wpinania obcych laptopów, udostępnienie dedykowanych stacji serwisowych w stacji GPZ, procedura stacji czyszczącej Sheep-Dip.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Bezzwłoczny demontaż wszystkich 12 nieautoryzowanych modemów komórkowych LTE w szafach telemechaniki i zablokowanie fizycznych portów Ethernet (Termin: 48h, Właściciel: Główny Inżynier Automatyki, KPI: 0 aktywnych nieautoryzowanych łączy bezprzewodowych).
  • CAP-02: Wdrożenie systemu Privileged Access Management (PAM) z bramą pośredniczącą dla wszystkich sesji serwisowych z rejestracją wideo i MFA (Termin: 30 dni, Właściciel: Dyrektor Cyberbezpieczeństwa OT, KPI: 100% sesji zewnętrznych autoryzowanych przez PAM).
  • CAP-03: Implementacja strefy IDMZ oraz wdrożenie przemysłowych sond IDS monitorujących ruch IEC 60870-5-104 i DNP3 (Termin: 60 dni, Właściciel: Kierownik Sekcji Teleinformatyki, KPI: Pełna widoczność anomalii telemechaniki w czasie rzeczywistym).
  • CAP-04: Opracowanie i wdrożenie procedury zgłaszania incydentów do CSIRT sektorowego oraz procedury MAR opóźniania/ujawniania informacji poufnych (Termin: 30 dni, Właściciel: Dyrektor Departamentu Prawnego i Relacji Inwestorskich, KPI: Czas powiadomienia komitetu kryzysowego poniżej 30 minut od potwierdzenia incydentu).

Zalety rozwiązania:

• Zabezpieczenie ciągłości dostaw energii elektrycznej dla 1,8 mln odbiorców i infrastruktury krytycznej państwa.
• Zgodność z rygorystycznymi wymogami NIS2, Ustawy o KSC oraz standardu IEC 62443.
• Eliminacja osobistej odpowiedzialności prawnej i finansowej Zarządu spółki za zaniedbania w cyberbezpieczeństwie.

Wady i ograniczenia:

• Bardzo wysokie nakłady inwestycyjne (CAPEX) na zmodernizowanie zapór przemysłowych i wdrożenie sond IDS (szacunek: 3 400 000 PLN).
• Konieczność planowania prac modernizacyjnych podczas planowych okien wyłączeniowych stacji GPZ.
• Ograniczenia sprzętowe najstarszych sterowników PLC nieobsługujących kryptografii IEC 62351 (wymóg zabezpieczenia kompensacyjnego przez firewalle tunelujące).

• Źródło internetowe: NIS2 (Dz. Urz. UE L 333 z 27.12.2022).
• Źródło internetowe: Rozporządzenie Komisji (UE) 2022/2446 (wdrożenie NIS2).
• Źródło internetowe: Rozporządzenie MAR (UE) nr 596/2014.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) – sektor energii jako sektor o wysokiej krytyczności (podmiot kluczowy).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (t.j. Dz.U. z 2026 r. poz. 20) – art. 11 ust. 1 (terminy zgłoszeń podmiotu kluczowego: 24 godziny od powzięcia informacji o incydencie, 72 godziny od zgłoszenia wstępnego, miesiąc od zgłoszenia ostatecznego) oraz art. 15 (prowadzenie audytu bezpieczeństwa nie rzadziej niż raz na trzy lata).
• Standard ISA/IEC 62443 (części 2-1, 3-2, 3-3) – Security for industrial automation and control systems.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.19, A.8.20, A.8.22, A.8.24.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 596/2014 z dnia 16 kwietnia 2014 r. w sprawie nadużyć na rynku (Rozporządzenie MAR), Dz. Urz. UE L 173 z 30.6.2014, tekst skonsolidowany Dz. Urz. UE L 2020/1129 z 2.7.2020 – art. 17 (przesunięcie informacji poufnej do fazy publicznej).
• Standard IEC 62351 – Power systems management and associated information exchange – Data and communications security.
• Rozporządzenie Komisji (UE) 2022/2446 z dnia 12 października 2022 r. ustanawiające szczegółowe zasady wdrażania rozporządzenia Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dz. Urz. UE L 333 z 27.12.2022) – obowiązki podmiotów kluczowych z sektora energii, w tym terminy zgłaszania incydentów poważnych. Uwaga: wskazane w pierwotnej wersji materiału „Rekomendacje PTPiREE w zakresie cyberbezpieczeństwa sieci dystrybucyjnych, Poznań 2023” nie zostały zidentyfikowane w dostępnych źródłach; dokumenty branżowe o takim charakterze mogą nie być jawnie publikowane.

• W1 Ochrona tajemnicy bankowej, danych posiadaczy kart płatniczych (PAN, CVV) oraz wrażliwych danych finansowych.
• W2W3 Wymogi Rozporządzenia DORA, standardu PCI DSS v4.0.1.1 oraz ISO/IEC 27001:2022 i ISO/IEC 27017/27018. Rekomendacja D (uchwała KNF nr 7/2013) i Komunikat Chmurowy KNF z 23 stycznia 2020 r. zostały uchylone i odwołane z dniem 17 stycznia 2025 r. w związku ze stosowaniem DORA; w ich miejsce stosuje się ustawę z 25 czerwca 2025 r. o zapewnieniu operacyjnej odporności cyfrowego sektora finansowego oraz akty wykonawcze DORA.
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Informacji i Odporności Cyfrowej w architekturze Multi-Cloud z modelem Zero-Trust i szyfrowaniem HSM/KMS.
• U2 Dokumentacja uchybień w modelu 4C z analizą 5 Why dla podatności Server-Side Request Forgery (SSRF) w API gateway.
• U3 Szacowanie ryzyka w matrycy 5x5 z uwzględnieniem strat finansowych (fraud) i kar KNF/DORA, parametry RTO (5 minut) i RPO (0 transakcji utraconych).
• U4 Sformułowanie Planu Działań Korygujących (CAP) oraz obrona planu mitygacji w formacie Pitch to Board.
• K1K2K3 Profesjonalizm, zrozumienie mechanizmów inżynierii finansowej, wysoka dyscyplina w obronie ustaleń przed kierownictwem fintechu.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu bezpieczeństwa, odporności cyfrowej oraz zgodności regulacyjnej w Krajowej Instytucji Płatniczej (KIP) działającej jako międzynarodowy fintech płatniczy. Podmiot przetwarza 15 milionów transakcji kartowych i natychmiastowych przelewów B2B/P2P miesięcznie, działając w architekturze hybrydowej multi-cloud (AWS i Google Cloud Platform). Instytucja podlega bezpośrednio pod rygorystyczne Rozporządzenie DORA (Digital Operational Resilience Act), standard branżowy PCI DSS v4.0.1 (Payment Card Industry Data Security Standard) na najwyższym poziomie Level 1 Service Provider oraz nadzór Komisji Nadzoru Finansowego (KNF). Zadanie wymaga zbadania podatności chmurowej w mikroserwisach płatniczych, formalizacji ustaleń w modelu 4C, wyliczenia ryzyka finansowego i regulacyjnego w matrycy 5x5 oraz przygotowania wystąpienia przed Zarządem.

FinTech "PayGlobal KIP S.A." oferuje bramkę płatniczą dla ponad 4 000 sklepów internetowych w Europie Środkowo-Wschodniej. Środowisko produkcyjne fintechu funkcjonuje w architekturze mikrousługowej opartej na klastrach Kubernetes w chmurze AWS (Region Frankfurt) z zapasowym środowiskiem autoryzacji transakcji w chmurze GCP (Region Warszawa). Wszystkie dane kart płatniczych podlegają tokenizacji z wykorzystaniem sprzętowego modułu bezpieczeństwa HSM (Hardware Security Module).

W ramach przygotowań do obligatoryjnego audytu odporności DORA oraz corocznej re-certyfikacji PCI DSS QSA ujawniono następujące usterki krytyczne:

1. Podatność SSRF w API Gateway i wyciek metadanych chmurowych: W publicznie dostępnym mikroserwisie generowania linków płatniczych wykryto podatność Server-Side Request Forgery (SSRF). Pozwoliła ona badaczowi penetracyjnemu na odpytanie wewnętrznego serwisu metadanych chmury (AWS IMDSv1), co doprowadziło do przechwycenia tymczasowych tokenów roli IAM o nadmiernych uprawnieniach (AdministratorAccess zamiast zawężonej roli Least Privilege). Tokeny te umożliwiały bezpośredni odczyt parametrów konfiguracyjnych z bazy DynamoDB oraz podsłuch zdarzeń autoryzacyjnych.

2. Naruszenie wymogów PCI DSS v4.0.1 dotyczących skryptów po stronie klienta (Client-Side Security): Na stronach płatniczych bramki zewnętrzny skrypt analityczny i marketingowy ładowany był bezpośrednio z zewnętrznej sieci CDN bez weryfikacji integralności skrótem kryptograficznym (brak nagłówków Subresource Integrity - SRI) oraz bez monitorowania zachowania skryptów (wymóg PCI DSS v4.0.1 wymóg 6.4.3 i 11.6.1). Stwarzało to bezpośrednie ryzyko ataku typu e-Skimming / Magecart i kradzieży danych kart w locie.

3. Niedostateczne testowanie odporności i brak testów TLPT (DORA): Mimo że fintech kwalifikuje się jako wiodąca instytucja płatnicza, spółka nigdy nie przeprowadziła zaawansowanych testów penetracyjnych w oparciu o scenariusze zagrożeń (Threat-Led Penetration Testing - TLPT / TIBER-EU). Testy ciągłości działania ograniczały się do wybiórczego restartu maszyn wirtualnych w AWS bez symulacji całkowitego odcięcia regionu chmurowego i przełączenia na zapasowe klastry w GCP.

4. Zarządzanie ryzykiem dostawców ICT firm trzecich: Fintech korzysta z 28 zewnętrznych dostawców usług cyfrowych (w tym systemów weryfikacji KYC, baz scoringowych i narzędzi telemetrycznych). Dla 14 z nich fintech nie posiadał podpisanych umów powierzenia i gwarancji SLA spełniających art. 30 Rozporządzenia DORA (m.in. prawo do nieograniczonego audytu, plan wyjścia Exit Strategy).

• Faza 1 (Minuty 00-15): Triada audytorska i podział ról.
  • Role: Lead Auditor (DORA, KNF, raport dla Zarządu), Cloud SecOps Auditor (analiza SSRF, IMDSv2, Kubernetes, Zero-Trust, HSM), Compliance Auditor (PCI DSS v4.0.1, ocena ryzyka dostawców ICT, Exit Strategy).
  • Błyskawiczny audyt konfiguracji chmury: Wskazanie błędów architektonicznych w AWS (brak IMDSv2, zbyt szerokie role IAM, brak WAF).
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Karta Niezgodności 4C dla podatności SSRF i nadmiernych ról IAM oraz braku SRI dla ochrony przed Magecart.
  • Analiza 5 Why: Dlaczego w mikroserwisie produkcyjnym używano przestarzałego serwisu IMDSv1 i nadmiernej roli IAM?
  • Matryca ryzyka 5x5: Oszacowanie ekspozycji na kradzież środków, kary finansowe KNF/DORA oraz utratę certyfikacji PCI DSS (paraliż biznesowy).
  • Wyznaczenie parametrów odporności cyfrowej: RTO = 5 minut, RPO = 0 transakcji (synchroniczna replikacja i transakcyjność idempotentna).
• Faza 3 (Minuty 40-70): Architektura Bezpieczeństwa Chmurowego i Plan CAP.
  • Projekt Zintegrowanej Polityki Odporności FinTechu: Wymuszenie AWS IMDSv2 z limitem przeskoków (Hop Limit=1), polityka Least Privilege z audytem IAM Access Analyzer, wdrożenie Content Security Policy (CSP) i SRI dla PCI DSS v4.0.1, procedura zarządzania umowami z dostawcami ICT wg DORA.
  • Opracowanie Planu CAP z kamieniami milowymi (48h, 30 dni, 90 dni) i wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i Pitch to Board.
  • Przygotowanie 1-stronicowej noty dla Zarządu i Rady Nadzorczej w układzie: Ryzyko utraty licencji KIP, Koszty wdrożenia zabezpieczeń chmurowych vs potencjalne straty, Harmonogram naprawczy.
  • Ustna obrona ustaleń przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytowe instytucji finansowej i zawierać:

• Strona tytułowa i Metryka Audytu (zespół, role, data audytu, oświadczenie o braku konfliktu interesów).
• Rozdział 1: Executive Summary dla Zarządu i Rady Nadzorczej (1 strona A4: syntetyczna diagnoza dojrzałości DORA/PCI DSS, ekspozycja na kary KNF, plan naprawczy).
• Rozdział 2: Ramy regulacyjne sektora finansowego i płatniczego (Rozporządzenie DORA, standard PCI DSS v4.0.1.1, ustawa z 25 czerwca 2025 r. o zapewnieniu operacyjnej odporności cyfrowego sektora finansowego, ISO/IEC 27001:2022, ISO/IEC 27017).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 dla środowiska multi-cloud (szacowanie skutków kradzieży danych kartowych i utraty licencji KIP, ocena IR i RR).
• Rozdział 4: Projekt Polityki Bezpieczeństwa Informacji i Odporności Operacyjnej:
  • Standard bezpiecznej konfiguracji chmury AWS/GCP (Zero-Trust, mTLS, wymuszenie IMDSv2, KMS z kluczami zarządzanymi w HSM).
  • Standard Bezpieczeństwa Aplikacji Webowych i Ochrony Przed e-Skimmingiem (wymogi 6.4.3 i 11.6.1 PCI DSS v4.0.1).
  • Ramy Zarządzania Ryzykiem Dostawców Usług ICT (strategia wyjścia Exit Strategy, rejestr powierzeń wg DORA art. 28-30).
  • Strategia zaawansowanych testów odporności cyfrowej TLPT (Threat-Led Penetration Testing).
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet, kosztów (TCO narzędzi Cloud Security Posture Management - CSPM) oraz harmonogram wdrożenia.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Podatność SSRF w bramce płatniczej umożliwiała odczyt metadanych AWS IMDSv1 i przechwycenie tokenu IAM z uprawnieniem AdministratorAccess; na stronie płatności brak nagłówków SRI i polityki monitorowania skryptów zewnętrznych.
  • Criteria: Rozporządzenie DORA art. 9 i 10 (zarządzanie podatnościami i ochrona systemów teleinformatycznych), PCI DSS v4.0.1 Wymóg 6.2, 6.4.3, 7.2 (Least Privilege), ISO 27001 Załącznik A.8.2, A.8.8, A.8.24.
  • Cause (5 Why):

Dlaczego API było podatne na SSRF? Bo parametry adresu URL w webhooku nie były filtrowane przez listę dozwolonych domen (Allow-list).

Dlaczego nie były filtrowane? Bo programiści chcieli zachować kompatybilność z nowymi sklepami bez zmian w kodzie.

Dlaczego rola IAM miała pełne uprawnienia administratora? Bo podczas wdrożenia w klastrze dev nadano uprawnienia nielimitowane i przekopiowano je na produkcję.

Dlaczego przeszło to przez testy? Bo proces CI/CD nie posiadał automatycznego skanera infrastruktury jako kodu (IaC Security Scan / SAST).

Przyczyna źródłowa: Brak ładu DevSecOps i brak egzekwowania architektury Zero-Trust w zarządzaniu uprawnieniami chmurowymi.

• Consequence: Ryzyko masowego wycieku danych posiadaczy kart płatniczych (PAN/CVV), cofnięcie certyfikacji PCI DSS (paraliż operacji procesowania kart), sankcje administracyjne KNF wynikające z ustawy z 25 czerwca 2025 r. o zapewnieniu operacyjnej odporności cyfrowego sektora finansowego (DORA samo nie przewiduje kar w wysokości 5 mln EUR ani 10% rocznego obrotu), natychmiastowe rozwiązanie umów przez Visa i Mastercard.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5 (Katastrofalny). Ryzyko Inherentne: 20/25 (Krytyczne).

Kontrole: Wymuszenie IMDSv2 z tokenem sesyjnym, wdrożenie dedykowanych ról IAM z minimalnymi uprawnieniami (Least Privilege), izolacja kluczy w HSM, wdrożenie narzędzia CSPM.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Zagrożenie 2: Atak Magecart i kradzież numerów kart z formularza płatności przez skompromitowany skrypt z zewnętrznego CDN.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5. Ryzyko Inherentne: 20/25.

Kontrole: Implementacja nagłówków Content-Security-Policy (CSP) z dyrektywą script-src, Subresource Integrity (SRI), system automatycznego monitorowania integralności DOM (Client-Side Protection).

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Wymuszenie konfiguracji AWS IMDSv2 na wszystkich instancjach EC2 i nodach Kubernetes oraz zablokowanie IMDSv1 na poziomie AWS Organizations SCP (Termin: 24h, Właściciel: Główny Architekt Chmury, KPI: 100% instancji z wymuszonym IMDSv2).
  • CAP-02: Przegląd i restrykcyjne zawężenie wszystkich ról IAM w klastrach produkcyjnych do zasady najmniejszych uprawnień (Least Privilege) przy użyciu AWS IAM Access Analyzer (Termin: 7 dni, Właściciel: DevSecOps Lead, KPI: 0 ról o uprawnieniach * na produkcji).
  • CAP-03: Wdrożenie nagłówków SRI i mechanizmu monitorowania skryptów po stronie klienta na formatce płatniczej zgodnie z wymogiem 6.4.3 i 11.6.1 PCI DSS v4.0.1 (Termin: 14 dni, Właściciel: Frontend Security Lead, KPI: 100% zewnętrznych bibliotek zabezpieczonych hashem SRI).
  • CAP-04: Opracowanie i zatwierdzenie przez Zarząd ram Zarządzania Ryzykiem Dostawców ICT wg DORA oraz harmonogramu testów TLPT (Termin: 45 dni, Właściciel: CISO / Compliance Director, KPI: Podpisanie aneksów DORA z 100% kluczowych dostawców ICT).

Zalety rozwiązania:

• Pełne zabezpieczenie bramki płatniczej przed wyrafinowanymi atakami chmurowymi (SSRF) i aplikacyjnymi (Magecart).
• Pełna zgodność ze standardem PCI DSS v4.0.1 oraz unijnym rozporządzeniem DORA, co chroni licencję KIP.
• Osiągnięcie najwyższego poziomu odporności operacyjnej i zaufania międzynarodowych schematów płatniczych.

Wady i ograniczenia:

• Koszty wdrożenia profesjonalnych narzędzi Cloud Security Posture Management (CSPM) oraz opłat za certyfikowane testy TLPT (szacunek: 420 000 PLN rocznie).
• Wymóg ścisłej dyscypliny w zespole deweloperskim i wydłużenie procesu wdrażania zmian (dodatkowe bramki bezpieczeństwa w CI/CD).
• Złożoność renegocjacji umów z globalnymi dostawcami chmurowymi i telekomunikacyjnymi w zakresie klauzul audytowych DORA.

• Źródło internetowe: Rozporządzenie DORA (UE) 2022/2554.
• Źródło internetowe: Standard PCI DSS.
• Źródło internetowe: Strona KNF dotycząca stosowania DORA.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (Rozporządzenie DORA).
• Payment Card Industry Data Security Standard (PCI DSS) – Requirements and Testing Procedures v4.0 (Wymogi 6.4.3, 7.2, 11.6.1).
• Ustawa z dnia 25 czerwca 2025 r. o zapewnieniu operacyjnej odporności cyfrowego sektora finansowego wraz z rozporządzeniem DORA (UE) 2022/2554 i aktami wykonawczymi. Komunikat UKNF dotyczący przetwarzania przez podmioty nadzorowane informacji w chmurze obliczeniowej publicznej lub hybrydnej z 23 stycznia 2020 r. został odwołany z dniem 17 stycznia 2025 r. w związku ze stosowaniem DORA.
• Ustawa z dnia 19 sierpnia 2011 r. o usługach płatniczych (Dz.U. z 2024 r. poz. 30).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.2, A.8.8, A.8.20, A.8.24.
• Norma ISO/IEC 27017:2015 – Information technology – Security techniques – Code of practice for information security controls based on ISO/IEC 27002 for cloud services.
• Wytyczne Europejskiego Urzędu Nadzoru Bankowego (EBA) w sprawie zarządzania ryzykiem technologii informacyjno-komunikacyjnych (ICT) i ryzykiem bezpieczeństwa (EBA/GL/2019/04).

• W1 Ochrona tajemnicy bankowej (art. 104 Prawa bankowego), tajemnicy zawodowej oraz danych finansowych klientów.
• W2W3 Rygorystyczna integracja przepisów DORA, Dyrektywy PSD2/PSD3, Standardów Technicznych EBA (RTS on SCA & CSC) oraz normy ISO/IEC 27001:2022. Rekomendacja D i Komunikat Chmurowy KNF zostały uchylone 17 stycznia 2025 r. w związku z DORA.
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa API i Architektury Zero-Trust dla usług Open Banking z bramami API Security Gateway.
• U2 Dokumentowanie uchybień w modelu 4C z analizą 5 Why dla podatności autoryzacji obiektowej BOLA/IDOR i braku limitowania zapytań (Rate Limiting).
• U3 Przeprowadzenie analizy ryzyka 5x5 uwzględniającej masowy wyciek historii rachunków i paraliż interfejsów B2B, parametry RTO (15 minut) i RPO (0 transakcji).
• U4 Sformułowanie Planu Działań Korygujących (CAP) ze wskaźnikami KPI i obrona rekomendacji przed Zarządem Banku.
• K1K2K3 Postawa etyczna, bezkompromisowa ochrona stabilności systemu finansowego i zaufania publicznego do banku.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu bezpieczeństwa teleinformatycznego i architektury interfejsów programistycznych (API) w banku komercyjnym realizującym usługi otwartej bankowości (Open Banking). Bank udostępnia API dla zewnętrznych dostawców usług płatniczych (TPP – Third Party Providers) na mocy dyrektywy PSD2/PSD3, przetwarza rachunki 2,4 miliona klientów oraz podlega pod rygor Rozporządzenia DORA, Rekomendacji M Komisji Nadzoru Finansowego (KNF) oraz normy ISO/IEC 27001:2022. Zadanie wymaga przeanalizowania incydentu z grupy OWASP API Security Top 10 (Broken Object Level Authorization - BOLA), sporządzenia karty niezgodności 4C, wyliczenia ryzyka fraudu i sankcji KNF w matrycy 5x5 oraz obrony Planu CAP przed Zarządem Banku w formule 90 minut.

Bank "Vistula Bank S.A." obsługuje 2,4 mln klientów detalicznych i korporacyjnych. W ramach usług Open Banking bank udostępnia interfejsy API zgodne ze standardem PolishAPI w wersji 3.0.1 dla 45 licencjonowanych podmiotów TPP (dostawców AISP - dostęp do informacji o rachunku oraz PISP - inicjowanie płatności). Dziennie bramy API banku przetwarzają ponad 18 milionów wywołań.

W wyniku incydentu zgłoszonego przez zaufanego partnera fintechowego oraz wewnętrznego audytu doraźnego ujawniono:

1. Podatność BOLA (Broken Object Level Authorization) w module AISP: W nowo wdrożonym mikrousługowym punkcie końcowym API `/api/v2/accounts/{accountNumber}/transactions` wykryto krytyczny błąd logiki autoryzacyjnej. Choć token OAuth 2.0 (mTLS) poprawnie uwierzytelniał podmiot TPP i zgodę klienta (Consent ID), to backend mikrousługi nie weryfikował, czy przekazany w ścieżce URL numer rachunku `{accountNumber}` jest powiązany z tożsamością klienta zawartą w tokenie. Zezwalało to złośliwemu lub skompromitowanemu podmiotowi TPP na pobranie pełnej historii transakcji dowolnego klienta banku poprzez sekwencyjną iterację numerów IBAN.

2. Brak mechanizmów Rate Limitingu i wykrywania anomalii behawioralnych: Brama API (API Gateway) nie posiadała dynamicznych limitów wywołań na poziomie pojedynczego tokenu ani adresu IP. Podmiot TPP zdołał w ciągu 4 godzin wykonać ponad 1 200 000 zapytań o różne numery rachunków bez wyzwolenia jakiegokolwiek alarmu w bankowym Security Operations Center (SOC).

3. Przechowywanie kluczy prywatnych i certyfikatów eIDAS na serwerach aplikacyjnych: Certyfikaty QWAC (Qualified Website Authentication Certificate) oraz QSealC wykorzystywane do wzajemnego uwierzytelniania mTLS i podpisywania ładunków JSON były przechowywane w postaci plików PEM w systemie plików maszyn wirtualnych bez ochrony w sprzętowych modułach HSM.

4. Zarządzanie podatnościami w cyklu CI/CD: Audyt kodu wykazał, że podatność BOLA została wprowadzona podczas poprawki typu "hotfix" 3 miesiące temu. Zespół deweloperski pominął testy bezpieczeństwa DAST/SAST z powodu presji terminowej narzuconej przez harmonogram wdrożenia nowej wersji aplikacji mobilnej.

• Faza 1 (Minuty 00-15): Triada audytorska i model zagrożeń API.
  • Role: Lead Auditor (DORA, PSD2, standard PolishAPI, raport dla Zarządu), API SecOps Auditor (analiza BOLA, OWASP API Security, OAuth2, WAF/API Gateway), BCM/Compliance Auditor (analiza logów SOC, certyfikaty eIDAS, procedury CI/CD).
  • Identyfikacja luki w oparciu o specyfikację PolishAPI i OWASP API1:2023 (Broken Object Level Authorization).
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Karta Niezgodności 4C dla podatności BOLA i braku Rate Limitingu.
  • Analiza 5 Why: Dlaczego kod podatny na BOLA trafił na środowisko produkcyjne?
  • Matryca ryzyka 5x5: Oszacowanie skutków masowego wycieku tajemnicy bankowej, kar finansowych KNF i EBA oraz utraty zaufania inwestorów.
  • Wyznaczenie parametrów odporności: RTO = 15 minut dla bramy API, RPO = 0 transakcji.
• Faza 3 (Minuty 40-70): Polityka Bezpieczeństwa API i Plan CAP.
  • Projekt Zintegrowanej Polityki Bezpieczeństwa API Bankowego: Obowiązkowa walidacja relacji podmiot-zasób w warstwie API Policy Engine (Open Policy Agent - OPA), integracja certyfikatów eIDAS ze sprzętowym HSM, wdrożenie dedykowanego rozwiązania Web Application and API Protection (WAAP) z analizą behawioralną AI.
  • Tabela Planu Działań Korygujących (CAP) ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i obrona przed Zarządem.
  • Sporządzenie 1-stronicowego Executive Summary dla Wiceprezesa Zarządu ds. Ryzyka (CRO) i Wiceprezesa ds. IT (CIO).
  • Ustna prezentacja i symulacja obrony raportu przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytu bankowego i zawierać:

• Strona tytułowa i Metryka Audytu (skład zespołu, certyfikaty audytorów, zakres audytu).
• Rozdział 1: Executive Summary dla Zarządu i Komitetu Ryzyka Banku (1 strona A4: syntetyczna diagnoza naruszenia tajemnicy bankowej, ekspozycja na kary KNF/UODO, plan CAP).
• Rozdział 2: Ramy regulacyjne sektora bankowego (Rozporządzenie DORA, Dyrektywa PSD2, RTS on SCA, ustawa z 25 czerwca 2025 r., ISO/IEC 27001:2022).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 dla środowiska interfejsów programistycznych Open Banking (szacowanie IR i RR dla wektora ataku BOLA i DDoS na API).
• Rozdział 4: Projekt Polityki Bezpieczeństwa Interfejsów API i Usług Otwartych:
  • Standard bezpiecznej autoryzacji obiektowej (Zero-Trust API: powiązanie Token Subject ID z Resource Owner ID w OPA).
  • Standard ochrony kryptograficznej i zarządzania certyfikatami eIDAS QWAC/QSealC w modułach HSM.
  • Zasady limitowania ruchu, ochrony anty-DDoS i behawioralnej detekcji anomalii w bramie API.
  • Rygor bramek bezpieczeństwa DevSecOps w potoku CI/CD (automatyczne testy kontraktowe i skanery podatności API).
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet, kosztów (TCO platformy WAAP) i ograniczeń wdrożeniowych.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Mikrousługa historii transakcji API `/api/v2/accounts/{accountNumber}/transactions` nie weryfikowała uprawnień właściciela rachunku, pozwalając na pobranie historii operacji dowolnego klienta; brak limitowania wywołań umożliwił wykonanie 1,2 mln zapytań w 4 godziny bez reakcji SOC.
  • Criteria: Ustawa Prawo bankowe art. 104 i art. 105 (tajemnica bankowa), Rozporządzenie DORA art. 9 ust. 2 i art. 10, DORA art. 5-6 i 8-9 wraz z ustawą z 25 czerwca 2025 r. o zapewnieniu operacyjnej odporności cyfrowego sektora finansowego, standard OWASP API Security Top 10 (API1:2023 BOLA), ISO 27001 Załącznik A.8.2, A.8.20, A.8.24.
  • Cause (5 Why):

Dlaczego wystąpiła podatność BOLA? Programista założył, że poprawny token OAuth2 gwarantuje uprawnienie do całego zapytania i pominął sprawdzenie prawa do numeru konta w bazie.

Dlaczego pominął sprawdzenie? Bo w bibliotece współdzielonej mikrousług brakowało uniwersalnego mechanizmu autoryzacji kontekstowej.

Dlaczego brakowało takiego mechanizmu? Ponieważ architektura API nie zawierała scentralizowanego silnika reguł (Policy Enforcement Point).

Dlaczego podatność trafiła na produkcję? Zmiana została wdrożona w trybie pilnym "hotfix" z pominięciem testów bezpieczeństwa API.

Przyczyna źródłowa: Niedojrzałość procesu zarządzania zmianami awaryjnymi (Emergency Change Management) oraz brak zautomatyzowanej weryfikacji autoryzacji obiektowej w testach CI/CD.

• Consequence: Masowy wyciek tajemnicy bankowej i danych osobowych, ryzyko kary od Prezesa Urzędu Ochrony Danych Osobowych (UODO) (do 20 mln EUR) oraz od KNF (sankcje z ustawy o nadzorze nad rynkiem finansowym oraz z ustawy z 25 czerwca 2025 r. wdrażającej DORA, a także cofnięcie zgody na określone czynności bankowe), a w przypadku realizacji zadań z zakresu zarządzania kryzysowego także z art. 21a ustawy z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym, pozwy zbiorowe klientów, kompromitacja wizerunku banku jako instytucji zaufania publicznego.

Prawdopodobieństwo Inherentne: 5, Skutek Inherentny: 5 (Katastrofalny). Ryzyko Inherentne: 25/25 (Maksymalne).

Kontrole: Wdrożenie scentralizowanej weryfikacji autoryzacji w silniku OPA, inspekcja zapytań przez barierę WAAP, automatyczne blokowanie IP po wykryciu anomalii numerycznych parametrów.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Zagrożenie 2: Przejęcie kluczy eIDAS i fałszowanie odpowiedzi banku przez kompromitację serwera aplikacyjnego.

Prawdopodobieństwo Inherentne: 3, Skutek Inherentny: 5. Ryzyko Inherentne: 15/25 (Wysokie).

Kontrole: Przeniesienie wszystkich kluczy prywatnych eIDAS do sieciowych modułów Hardware Security Module (HSM) z certyfikatem FIPS 140-2 Level 3.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Natychmiastowe wdrożenie reguły wirtualnego łatania (Virtual Patch) na bramie WAAP weryfikującej zgodność rachunku z tokenem oraz natychmiastowe zablokowanie podmiotu TPP (Termin: 2h, Właściciel: CISO / SecOps, KPI: 0 zapytań o obce rachunki przepuszczonych przez bramę).
  • CAP-02: Wdrożenie scentralizowanego silnika autoryzacji kontekstowej Open Policy Agent (OPA) w klastrze mikrousług bankowych (Termin: 14 dni, Właściciel: Główny Architekt Oprogramowania, KPI: 100% endpointów z walidacją BOLA).
  • CAP-03: Implementacja sprzętowej ochrony kluczy eIDAS w modułach HSM i wycofanie plików PEM z serwerów aplikacyjnych (Termin: 30 dni, Właściciel: Dyrektor Departamentu Infrastruktury IT, KPI: 0 nieszyfrowanych kluczy prywatnych w systemie plików).
  • CAP-04: Wdrożenie automatycznych testów bezpieczeństwa API (Dynamic Application Security Testing dla API) w potoku CI/CD oraz obowiązkowego podpisu audytora bezpieczeństwa dla wydań hotfix (Termin: 45 dni, Właściciel: DevSecOps Lead, KPI: 100% wydań kodu z raportem bezpieczeństwa).

Zalety rozwiązania:

• Całkowite wyeliminowanie najbardziej krytycznej luki API (BOLA) i ochrona tajemnicy bankowej.
• Zgodność z wymogami DORA, polskiej ustawy z 25 czerwca 2025 r. i standardami bezpieczeństwa PolishAPI.
• Wzrost cyberodporności banku na zaawansowane ataki zautomatyzowane (botnety, scraping).

Wady i ograniczenia:

• Koszty licencyjne i operacyjne wdrożenia platformy WAAP i dedykowanych modułów HSM (szacunek: 650 000 PLN).
• Minimalny wzrost opóźnień (latencji) odpowiedzi API o około 4-8 ms wynikający z dodatkowej weryfikacji w OPA i inspekcji WAAP.
• Wymóg ścisłej koordynacji zmian technicznych z certyfikowanymi podmiotami TPP.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) – operacyjna odporność cyfrowa sektora finansowego.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2015/2366 (PSD2) oraz projekt Dyrektywy PSD3 – usługi płatnicze w ramach rynku wewnętrznego.
• Ustawa z dnia 29 sierpnia 1997 r. – Prawo bankowe (Dz.U. z 2023 r. poz. 2488) – art. 104 (tajemnica bankowa).
• Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach (uchwała KNF nr 7/2013 z 8 stycznia 2013 r., Dz. Urz. KNF z 2013 r. poz. 5) – uchylona z dniem 17 stycznia 2025 r. uchwałą KNF nr 6/2025 w związku ze stosowaniem DORA. Obecnie obowiązują DORA oraz ustawa z 25 czerwca 2025 r. o zapewnieniu operacyjnej odporności cyfrowego sektora finansowego.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.2, A.8.8, A.8.20, A.8.24, A.8.28.
• OWASP API Security Top 10 2023 (ze szczególnym uwzględnieniem API1:2023 Broken Object Level Authorization).
• Standard PolishAPI – Specyfikacja interfejsu na potrzeby usług świadczonych przez osoby trzecie w oparciu o dostęp do rachunków płatniczych, Związek Banków Polskich. Wersja 3.0 opublikowana 12 grudnia 2019 r.; wersja 3.0.1 z 17 czerwca 2025 r. (wersje wspierane: 3.0.1 oraz 2.1.4). Źródło internetowe: polishapi.org/dokumentacja-standardu.

• W1 Ochrona tajemnic państwowych, informacji niejawnych RP, NATO i UE oraz dokumentacji konstrukcyjnej uzbrojenia.
• W2W3 Rygory Ustawy o ochronie informacji niejawnych, WSK, wymogi akredytacji środków ochrony informacji niejawnych, normy ISO/IEC 27001:2022 oraz wymagań NATO AQAP dotyczących zapewniania jakości (dokumenty o klauzuli ograniczonego rozeszania, niedostępne dla podmiotu zewnętrznego; w zakresie ochrony informacji niejawnych właściwą jawną podstawą jest ustawa z 10 sierpnia 2010 r. i ustawa o WSK).
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Informacji Przemysłu Obronnego z procedurami stref bezpieczeństwa SCIF i ochrony kryptograficznej.
• U2 Dokumentacja uchybień w modelu 4C z analizą 5 Why dla incydentu eksfiltracji danych projektowych przez tunelowanie DNS i naruszenia dyscypliny nośników.
• U3 Przeprowadzenie analizy ryzyka 5x5 dla sabotażu i szpiegostwa, parametry RTO (2 godziny) i RPO (0 minut dla dokumentacji CAD/CAM).
• U4 Sformułowanie Planu Działań Korygujących (CAP) i Executive Summary dla Prezesa Zarządu oraz Pełnomocnika ds. Ochrony Informacji Niejawnych.
• K1K2K3 Poczucie odpowiedzialności za obronność Rzeczypospolitej, etyka zawodowa, bezkompromisowość w przestrzeganiu dyscypliny wojskowej.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie audytu bezpieczeństwa informacji niejawnych, ochrony tajemnicy przedsiębiorstwa oraz cyberodporności na zaawansowane ataki państwowe (APT) w strategicznym zakładzie przemysłu obronnego wytwarzającym bezzałogowe systemy powietrzne (drony bojowe i rozpoznawcze). Przedsiębiorstwo przetwarza informacje niejawne krajowe (Zastrzeżone, Poufne) oraz międzynarodowe (NATO RESTRICTED, RESTREINT UE), podlega pod rygor Ustawy o ochronie informacji niejawnych, Ustawy o Wewnętrznym Systemie Kontroli (WSK), posiada Świadectwo Bezpieczeństwa Przemysłowego I stopnia oraz podlega nadzorowi Służby Kontrwywiadu Wojskowego (SKW) i Agencji Bezpieczeństwa Wewnętrznego (ABW). Zadanie polega na analizie incydentu szpiegowskiego z wykorzystaniem tunelowania DNS, sformułowaniu ustaleń w modelu 4C, wyliczeniu ryzyka utraty przewagi militarnej w matrycy 5x5 oraz przygotowaniu Planu CAP w reżimie 90 minut.

Zakłady Lotniczo-Zbrojeniowe "Orzeł S.A." zatrudniają 1 200 pracowników, w tym 180 konstruktorów i inżynierów awioniki w Ośrodku Badawczo-Rozwojowym (OBR). OBR realizuje strategiczny kontrakt na dostawę rojów dronów uderzeniowych ze sztuczną inteligencją i łącznością odporną na walkę radioelektroniczną (EW) dla Sił Zbrojnych RP.

W trakcie wspólnej kontroli audytorów wewnętrznych oraz oficerów kontrwywiadu ujawniono:

1. Wykrycie złośliwego oprogramowania szpiegowskiego i eksfiltracji przez DNS: Na stacji roboczej głównego konstruktora napędów dronów wykryto aktywność modułu szpiegowskiego powiązanego z obcą grupą państwową APT. Moduł działał w pamięci RAM, zbierając pliki projektowe 3D w formacie STEP z oprogramowania CAD/CAM. Eksfiltracja danych odbywała się za pośrednictwem techniki DNS Tunneling (rekordy TXT zapytujące fałszywy autorytatywny serwer DNS), co skutecznie omijało korporacyjny firewall analizujący wyłącznie ruch HTTP/HTTPS.

2. Naruszenie procedur podróży służbowych i wynoszenia sprzętu: Zastępca dyrektora ds. rozwoju zabrał służbowy laptop zawierający pliki o klauzuli "Zastrzeżone" oraz rysunki techniczne głowic optoelektronicznych na międzynarodowe targi zbrojeniowe w państwie podwyższonego ryzyka wywiadowczego. Na lotnisku laptop został poddany "kontroli technicznej" przez miejscowe służby celne w odrębnym pomieszczeniu bez obecności pracownika przez 25 minut. Pracownik po powrocie nie zgłosił tego faktu Pełnomocnikowi ds. Ochrony Informacji Niejawnych i podłączył laptop do sieci zakładowej.

3. Niewłaściwe zarządzanie strefami bezpieczeństwa i nośnikami: Do Kancelarii Tajnej i strefy SCIF (Sensitive Compartmented Information Facility), gdzie przetwarzane są dane NATO RESTRICTED, wnoszone były prywatne smartfony i smartwatche konstruktorów (brak bramek detekcji sygnałów radiowych i skrytek depozytowych przed wejściem). Nośniki SSD z danymi projektowymi były przechowywane w zwykłych biurkach zamiast w sejfach klasy co najmniej S2.

4. Brak segmentacji sieci produkcyjnej maszyn CNC: Precyzyjne 5-osiowe obrabiarki CNC frezujące tytanowe kadłuby dronów były wpięte do ogólnej sieci komputerowej zakładu, posiadając domyślne hasła serwisowe i zdalny dostęp serwisowy dla producenta obrabiarek.

• Faza 1 (Minuty 00-15): Triada audytorska i rozpoznanie wektorów kontrwywiadowczych.
  • Role: Lead Auditor (ochrona informacji niejawnych, WSK, raport dla Prezesa i SKW), SecOps/Cyber Auditor (analiza DNS Tunneling, złośliwego kodu APT, maszyn CNC), Physical/Security Auditor (analiza stref SCIF, depozytów, kontroli podróży zagranicznych).
  • Identyfikacja naruszeń reżimu bezpieczeństwa przemysłowego i wymogów NATO Security Policy (C-M(2002)49).
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Karta Niezgodności 4C dla eksfiltracji danych przez DNS Tunneling oraz incydentu z laptopem na lotnisku.
  • Analiza 5 Why: Dlaczego serwery DNS w zakładzie zbrojeniowym pozwalały na swobodny ruch do niezaufanych domen zewnętrznych?
  • Matryca ryzyka 5x5: Oszacowanie skutków skopiowania technologii dronowej przez państwo wrogie, utraty Świadectwa Bezpieczeństwa Przemysłowego i zerwania kontraktu MON.
  • Wyznaczenie kryteriów ciągłości: RTO = 2h dla odtworzenia środowiska CAD/CAM, RPO = 0 minut.
• Faza 3 (Minuty 40-70): Architektura Ochrony Informacji Niejawnych i Plan CAP.
  • Projekt Zintegrowanej Polityki Bezpieczeństwa Zakładów Zbrojeniowych: Wdrożenie stref SCIF z pełnym ekranowaniem elektromagnetycznym (ochrona TEMPEST), serwery DNS Sinkhole z inspekcją zapytań i blokadą tunelowania, procedura kontroli urządzeń po powrocie z zagranicy (kwarantanna i reinstalacja sprzętu), odizolowanie sieci maszyn CNC (Air-Gap).
  • Tabela Planu Działań Korygujących (CAP) ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i obrona przed Zarządem.
  • Przygotowanie 1-stronicowego tajnego Executive Summary dla Prezesa Zarządu i Pełnomocnika ds. Ochrony Informacji Niejawnych.
  • Ustna prezentacja i obrona ustaleń przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytu wojskowego i przemysłu obronnego:

• Strona tytułowa i Metryka Audytu (zespół, poświadczenia bezpieczeństwa, numer ewidencyjny kancelarii).
• Rozdział 1: Executive Summary dla Prezesa Zarządu i Pełnomocnika OIN (1 strona A4: syntetyczna diagnoza naruszenia tajemnicy obronnej, ekspozycja na utratę koncesji MSWiA, plan CAP).
• Rozdział 2: Ramy regulacyjne obronności i ochrony informacji niejawnych (Ustawa z dnia 10 sierpnia 2010 r. o ochronie informacji niejawnych, Ustawa o WSK, norma PN-EN ISO/IEC 27001:2022 oraz wymagania jakościowe serii AQAP, traktowane w tym zadaniu wyłącznie jako kryterium oceny dostawcy, a nie jako źródło jawne ani jako podstawa prawna ochrony informacji niejawnych).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 dla wektorów szpiegostwa militarnego i sabotażu produkcji CNC (wyliczenie IR i RR).
• Rozdział 4: Projekt Zintegrowanej Polityki Ochrony Informacji Niejawnych i Technologii Wojskowych:
  • Standard fizyczny i teleinformatyczny stref SCIF (procedury depozytu urządzeń, bramki detekcji sygnałów, tłumienie radiowe).
  • Standard Bezpieczeństwa Sieci Teleinformatycznej OBR (DNS Security / DNS RPZ, ochrona przed tunelowaniem, blokada portów USB).
  • Procedura zagranicznych podróży służbowych personelu kluczowego (zasada czystego laptopa "Burner Laptop", kwarantanna i reinstalacja po powrocie).
  • Zasady izolacji i cyberbezpieczeństwa parku maszynowego CNC.
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet, kosztów i barier organizacyjnych (dyscyplina wojskowa vs wygoda inżynierów).

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Dane projektowe dronów bojowych były eksfiltrowane przez stację CAD za pomocą techniki DNS Tunneling; laptop z dokumentacją Zastrzeżoną został przejęty przez zagraniczne służby celne i włączony po powrocie do sieci wewnętrznej bez kontroli.
  • Criteria: Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (przepisy o ochronie teleinformatycznej, art. 1 ust. 1 pkt 7), Ustawa o WSK (art. 33 ust. 1 w zakresie odpowiedzialności karnej za obrót bez zezwolenia; art. 37-39 w zakresie kar pieniężnych), norma PN-EN ISO/IEC 27001:2022 Załącznik A.8.20, A.8.23, A.8.24, A.7.1, A.7.2.
  • Cause (5 Why):

Dlaczego dane wyciekły przez DNS? Bo serwer DNS zezwalał na bezpośrednie rozwiązywanie zapytań zewnętrznych bez inspekcji głębokiej.

Dlaczego nie było inspekcji? Bo firewall traktował ruch DNS na porcie 53 jako zaufany ruch infrastrukturalny.

Dlaczego dyrektor zabrał laptop z danymi Zastrzeżonymi za granicę? Bo zakład nie posiadał floty dedykowanych laptopów delegacyjnych bez twardych dysków (tzw. burner laptops).

Dlaczego nie zgłosił incydentu na lotnisku? Bo obawiał się konsekwencji służbowych i nie znał procedury alarmowej.

Przyczyna źródłowa: Brak kultury bezpieczeństwa kontrwywiadowczego (Security Awareness) oraz brak technicznych barier egzekwowania separacji danych niejawnych od sieci otwartej.

• Consequence: Kradzież strategicznej myśli technicznej przez obcy wywiad, możliwość opracowania przez przeciwnika skutecznych środków przeciwdziałania radioelektronicznego (jammerów), utrata Świadectwa Bezpieczeństwa Przemysłowego (zamknięcie zakładu), odpowiedzialność karna z art. 130 Kodeksu karnego (szpiegostwo).

Prawdopodobieństwo Inherentne: 5, Skutek Inherentny: 5 (Katastrofalny - utrata przewagi na polu walki). Ryzyko Inherentne: 25/25 (Maksymalne).

Kontrole: Wdrożenie dedykowanych resolverów DNS z Response Policy Zones (DNS RPZ) i detekcją tunelowania, odcięcie stacji projektowych od bezpośredniego wyjścia do Internetu, wdrożenie EDR z analizą behawioralną procesów.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Zagrożenie 2: Zainfekowanie sieci zakładowej przez laptop przejęty podczas podróży zagranicznej.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5. Ryzyko Inherentne: 20/25.

Kontrole: Wdrożenie floty laptopów delegacyjnych "Burner Laptops" z jednorazowym obrazem systemu, obowiązkowa kwarantanna i weryfikacja w laboratorium kontrwywiadowczym przed ponownym wpięciem.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 1. Ryzyko Rezydualne: 1/25 (Znikome).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Natychmiastowa izolacja fizyczna zainfekowanej stacji CAD i zablokowanie na firewallu zapytań DNS wychodzących bezpośrednio ze stacji roboczych (Termin: 1h, Właściciel: CISO / SecOps, KPI: 100% zapytań DNS kierowanych przez autoryzowany DNS Sinkhole).
  • CAP-02: Wdrożenie strefy depozytu urządzeń mobilnych (szafki ekranowane elektromagnetycznie) przed wejściem do Ośrodka Badań i Rozwoju oraz instalacja bramek wykrywających telefony komórkowe (Termin: 14 dni, Właściciel: Szef Ochrony Fizycznej / Pełnomocnik OIN, KPI: 0 urządzeń bezprzewodowych w strefie SCIF).
  • CAP-03: Wdrożenie procedury zagranicznych podróży służbowych z flotą 15 czystych laptopów delegacyjnych z dyskami samoszyfrującymi i procedurą bezpiecznego niszczenia obrazu po powrocie (Termin: 21 dni, Właściciel: Dyrektor Logistyki i IT, KPI: 100% wyjazdów zagranicznych z certyfikowanym sprzętem tymczasowym).
  • CAP-04: Odizolowanie maszyn CNC do wydzielonej sieci Air-Gap z fizycznym brakiem połączenia z siecią korporacyjną i wdrożenie stacji skanowania nośników programów obróbczych (Termin: 30 dni, Właściciel: Dyrektor Produkcji Uzbrojenia, KPI: 0 portów sieciowych łączących sieć CNC z siecią IT).

Zalety rozwiązania:

• Zagwarantowanie ochrony strategicznych tajemnic państwowych i wojskowych Rzeczypospolitej Polskiej oraz sojuszników z NATO.
• Spełnienie warunków zachowania Świadectwa Bezpieczeństwa Przemysłowego I stopnia.
• Skuteczna ochrona przed najbardziej wyrafinowanymi państwowymi grupami szpiegowskimi APT.

Wady i ograniczenia:

• Duże utrudnienia organizacyjne dla personelu inżynieryjnego (brak możliwości korzystania z telefonów i Internetu na stanowiskach pracy).
• Koszty inwestycyjne budowy bezpiecznych stref ekranowanych SCIF oraz zakupu aparatury kontrolnej (szacunek: 950 000 PLN).
• Rygorystyczny i czasochłonny proces akredytacji teleinformatycznej przez oficerów SKW/ABW.

• Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. z 2024 r. poz. 632).
• Ustawa z dnia 29 listopada 2000 r. o obrocie z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym dla bezpieczeństwa państwa (WSK).
• Dokument NATO C-M(2002)49 „Protection of Classified Information within NATO” oraz publikacje serii AQAP (m.in. AQAP 2110 i AQAP 2210) – dokumenty o klauzuli ograniczonego rozeszania, przywoływane wyłącznie wskazowo; w pracy należy posługiwać się jawnymi podstawami prawnymi.
• Publikacje NATO Allied Quality Assurance Publications oraz dokument NATO C-M(2002)49 „Protection of Classified Information within NATO” mają klauzulę ograniczonego rozeszania i nie mogą być wskazane jako źródła jawne. Uwaga merytoryczna: AQAP 2110 dotyczy wymagań zapewniania jakości w projektowaniu, wytwarzaniu i produkcji (NATO Quality Assurance Requirements for Design, Development and Production), a AQAP 2210 – uzupełniających wymagań zapewniania jakości oprogramowania; żadna z tych publikacji nie jest przepisem o ochronie informacji niejawnych, dlatego w niniejszym zadaniu traktowane są one wyłącznie jako kryterium oceny dostawcy, a nie jako podstawa prawna. Zastępującą podstawą prawną i jawną pozostaje ustawa z dnia 10 sierpnia 2010 r. o ochronie informacji niejawnych (t.j. Dz.U. z 2024 r. poz. 632) wraz z rozporządzeniem Prezesa Rady Ministrów z dnia 29 września 2011 r. w sprawie procedur bezpieczeństwa teleinformatycznego (Dz.U. z 2011 r. poz. 1562).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.10, A.7.1, A.7.2, A.7.3, A.8.20, A.8.23.
• Ustawa z dnia 10 sierpnia 2010 r. o ochronie informacji niejawnych (t.j. Dz.U. z 2024 r. poz. 632) – w zakresie postępowania bezpieczeństwa przemysłowego oraz ochrony informacji niejawnych w systemach teleinformatycznych. Uwaga: wskazane w pierwotnej wersji materiału „Wytyczne SKW, Warszawa 2023” nie zostały zidentyfikowane w dostępnych źródłach i wymagają weryfikacji w SKW.

• W1 Ochrona danych medycznych pacjentów w środowiskach multi-tenant, tajemnica przedsiębiorstwa, ramy powierzenia danych (art. 28 RODO).
• W2W3 Wymogi norm ISO/IEC 27001:2022, ISO/IEC 27017, ISO/IEC 27018, kryteriów SOC 2 Trust Services Criteria (AICPA) oraz RODO.
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Chmury Multi-Tenant z rygorystyczną izolacją danych (Row-Level Security, szyfrowanie BYOK).
• U2 Dokumentacja uchybienia w modelu 4C z analizą 5 Why dla błędu separacji logicznej danych pacjentów pomiędzy szpitalami.
• U3 Przeprowadzenie analizy ryzyka 5x5 uwzględniającej zerwanie kontraktów B2B i kary RODO, parametry RTO (1 godzina) i RPO (5 minut).
• U4 Sformułowanie Planu Działań Korygujących (CAP) i Executive Summary w formule Pitch to Board.
• K1K2K3 Profesjonalizm inżynierski, transparentność wobec klientów B2B oraz etyka w zarządzaniu incydentem wycieku danych.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu bezpieczeństwa, separacji danych oraz zgodności kontraktowej w firmie technologicznej dostarczającej globalną platformę oprogramowania jako usługi (SaaS) dla ponad 200 szpitali i sieci laboratoriów diagnostycznych w Unii Europejskiej. Platforma przetwarza dane medyczne i telemetryczne milionów pacjentów w architekturze wielodostępnej (Multi-Tenant Architecture) w chmurze publicznej. Spółka podlega przepisom RODO (w roli podmiotu przetwarzającego – art. 28), standardom chmurowym ISO/IEC 27017 i ISO/IEC 27018 (ochrona danych osobowych w chmurze) oraz przechodzi coroczne audyty poświadczeniowe SOC 2 Type II (kryteria bezpieczeństwa, poufności i dostępności AICPA). Zadanie wymaga zbadania błędu izolacji dzierżawców (Tenant Isolation Breach), opracowania karty 4C, wyliczenia ryzyka w matrycy 5x5 oraz przygotowania wystąpienia przed Zarządem spółki.

Firma "MedCloud Solutions Sp. z o.o." świadczy usługę SaaS do zarządzania dokumentacją kliniczną i wynikami badań laboratoryjnych dla 210 podmiotów leczniczych w 6 krajach UE. Baza danych platformy oparta jest na relacyjnym silniku PostgreSQL z mechanizmem Row-Level Security (RLS) w chmurze AWS, gdzie identyfikator klienta `tenant_id` filtruje rekordy na poziomie zapytań SQL.

Podczas rutynowego testu regresyjnego oraz zgłoszenia od głównego klienta (konsorcjum 15 szpitali uniwersyteckich) ujawniono:

1. Złamanie izolacji dzierżawców (Tenant Isolation Failure): W wyniku błędu w procedurze migracyjnej bazy danych i modyfikacji widoku zmaterializowanego `v_patient_records` klauzula filtrująca `WHERE tenant_id = current_setting('app.current_tenant')` została omyłkowo usunięta dla nowo dodanych endpointów raportowych. Przez 11 dni użytkownicy Szpitala A generujący raporty statystyczne otrzymywali w zestawieniach dane pacjentów onkologicznych i zakaźnych ze Szpitala B i C (obejmujące imiona, nazwiska, numery PESEL, diagnozy ICD-10 i wyniki biopsji).

2. Brak szyfrowania z kluczami klienta (Bring Your Own Key - BYOK): Mimo że umowy powierzenia przetwarzania danych (DPA) ze szpitalami gwarantowały dedykowaną kryptograficzną izolację każdego tenanta z wykorzystaniem unikalnych kluczy KMS zarządzanych przez klienta (BYOK), platforma w rzeczywistości używała jednego wspólnego klucza symetrycznego AWS KMS dla całej bazy danych produkcyjnej.

3. Opóźnienie eskalacji incydentu i naruszenie RODO: Zespół wsparcia technicznego dowiedział się o błędzie 4 dni przed zgłoszeniem go do Inspektora Ochrony Danych i Zarządu spółki, próbując po cichu cofnąć błędną migrację bazy. W rezultacie spółka jako podmiot przetwarzający nie powiadomiła szpitali (administratorów danych) "bez zbędnej zwłoki", jak nakazuje art. 33 ust. 2 RODO, a szpitale jako administratorzy nie zgłosiły naruszenia organowi nadzorczemu w terminie do 72 godzin od jego stwierdzenia, o którym mowa w art. 33 ust. 1 RODO (przekroczono 72 godziny).

4. Nieważność raportu SOC 2 Type II: Ostatni raport SOC 2 Type II wystawiony przez biegłego rewidenta nie obejmował nowo utworzonych mikroserwisów analitycznych, które zostały wdrożone bez formalnego przeglądu zmian (Change Management Review), co stawia pod znakiem zapytania ważność całego poświadczenia audytowego.

• Faza 1 (Minuty 00-15): Triada audytorska i rozpoznanie błędu izolacji.
  • Role: Lead Auditor (RODO art. 28 i 33, raport dla Zarządu, umowy DPA), Cloud Database SecOps Auditor (analiza Row-Level Security, PostgreSQL, AWS KMS, BYOK), Compliance/SOC Auditor (weryfikacja kryteriów SOC 2 Type II, ISO 27017/27018, audyt procedury Change Management).
  • Błyskawiczny audyt kodu migracji SQL i weryfikacja naruszenia izolacji danych.
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Opracowanie Karty Niezgodności 4C dla błędu RLS oraz ukrycia incydentu przez zespół wsparcia.
  • Analiza 5 Why: Dlaczego skrypt migracyjny z pominięciem klauzuli RLS trafił na bazę produkcyjną bez wykrycia?
  • Matryca ryzyka 5x5: Oszacowanie ekspozycji na kary UODO, pozwy regresowe ze strony 200 szpitali oraz utratę reputacji rynkowej.
  • Wyznaczenie krytycznych parametrów: RTO = 1 godzina, RPO = 5 minut.
• Faza 3 (Minuty 40-70): Architektura Separacji Chmurowej i Plan CAP.
  • Projekt Zintegrowanej Polityki Bezpieczeństwa Chmury Medycznej: Wymuszenie architektury "Silo Model" dla danych wrażliwych lub mechanizmu Tenant Isolation Enforcer w API Gateway, wdrożenie rzeczywistego szyfrowania per-tenant z obsługą AWS KMS BYOK, sformalizowana procedura powiadamiania o incydentach RODO (ścieżka 24h dla klientów B2B).
  • Tabela Planu Działań Korygujących (CAP) ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i obrona przed Zarządem.
  • Opracowanie 1-stronicowej noty dla Zarządu i Inwestorów (funduszu VC) z planem kryzysowym ratowania kontraktów szpitalnych.
  • Ustna prezentacja i obrona raportu przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytu dostawców chmurowych (Cloud Service Provider):

• Strona tytułowa i Metryka Audytu (zespół, akredytacje, zakres audytu chmurowego).
• Rozdział 1: Executive Summary dla Zarządu MedCloud Solutions (1 strona A4: syntetyczna diagnoza naruszenia poufności, ekspozycja finansowa i prawna, plan CAP).
• Rozdział 2: Ramy regulacyjne i standardy poświadczeniowe (RODO art. 28 i 33, ISO/IEC 27001:2022, ISO/IEC 27017, ISO/IEC 27018, standard SOC 2 AICPA).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 dla środowiska chmury multi-tenant (szacowanie skutków kompromitacji danych wielu klientów, ocena IR i RR).
• Rozdział 4: Projekt Zintegrowanej Polityki Bezpieczeństwa Chmurowej Platformy Medycznej:
  • Architektura izolacji dzierżawców (Tenant Isolation Framework: logiczna separacja na poziomie zapytań z automatycznymi testami integracyjnymi).
  • Standard zarządzania kluczami kryptograficznymi BYOK (indywidualne klucze AWS KMS powiązane z ID tenanta).
  • Procedura zarządzania zmianą w chmurze (Change Management i automatyczne testy regresyjne bezpieczeństwa bazy danych).
  • Procedura zarządzania incydentami bezpieczeństwa danych i notyfikacji administratorów danych (SLA powiadomienia do 12h).
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet, kosztów infrastrukturalnych oraz plan wdrożenia.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Awaria polityki Row-Level Security w widoku `v_patient_records` spowodowała ujawnienie danych medycznych pacjentów onkologicznych Szpitala B i C użytkownikom Szpitala A przez 11 dni; incydent został zatajony przez zespół wsparcia przez 4 dni; platforma używała wspólnego klucza KMS wbrew umowom BYOK.
  • Criteria: RODO art. 28 ust. 3 lit. c, art. 32 i art. 33 (bezpieczeństwo i obowiązek notyfikacji), norma ISO/IEC 27017 klauzula CLD.8.1.5 (izolacja środowisk wielodostępnych), ISO/IEC 27018 klauzula 10.1 (szyfrowanie danych PII), kryteria SOC 2 Trust Services CC6.1, CC6.6, CC7.3.
  • Cause (5 Why):

Dlaczego zmaterializowany widok nie posiadał klauzuli RLS? Programista bazodanowy zoptymalizował zapytanie pod kątem wydajności i zapomniał dołączyć polityki bezpieczeństwa do nowego widoku.

Dlaczego nie wykryły tego testy? W środowisku testowym używano bazy danych z jednym testowym tenantem, więc testy zawsze przechodziły.

Dlaczego nie było testów wielodostępnych? W metodyce testowej brakowało scenariuszy weryfikacji izolacji międzytenantowej (Cross-Tenant Leakage Tests).

Dlaczego zespół wsparcia zataił błąd? Obawiali się paniki klientów i kar przewidzianych w wewnętrznym regulaminie premiowania za incydenty P1.

Przyczyna źródłowa: Wadliwa kultura organizacyjna karząca za zgłaszanie błędów oraz brak automatycznych testów bezpieczeństwa izolacji dzierżawców w potoku CI/CD.

• Consequence: Odpowiedzialność odszkodowawcza wobec 210 szpitali, natychmiastowe wypowiedzenie umów przez kluczowych klientów, utrata poświadczenia SOC 2 Type II, sankcje Prezesa Urzędu Ochrony Danych Osobowych do kwoty 20 mln EUR albo 4% światowego rocznego obrotu (art. 83 ust. 5 RODO, ponieważ naruszenie dotyczy danych o stanie zdrowia, czyli szczególnej kategorii danych z art. 9 RODO), utrata zaufania inwestorów.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5 (Katastrofalny). Ryzyko Inherentne: 20/25 (Krytyczne).

Kontrole: Implementacja architektury Tenant Context Enforcer na poziomie frameworka aplikacji (brak możliwości wykonania zapytania bez aktywnego filtru tenanta), automatyczne testy Cross-Tenant w CI/CD, szyfrowanie rekordów per-tenant z unikalnym kluczem KMS.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Zagrożenie 2: Opóźnienie w zgłoszeniu naruszenia skutkujące karami UODO i zerwaniem kontraktów B2B.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 4. Ryzyko Inherentne: 16/25 (Wysokie).

Kontrole: Wdrożenie zautomatyzowanego systemu zgłaszania incydentów zintegrowanego z PagerDuty, szkolenia "No-Blame Culture" dla wsparcia IT, powołanie dedykowanego oficera dyżurnego RODO.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Bezzwłoczne wdrożenie poprawki RLS na bazie produkcyjnej oraz uruchomienie audytu wstecznego logów zapytań w celu precyzyjnego ustalenia, które rekordy zostały pobrane (Termin: 12h, Właściciel: Główny Architekt Bazy Danych, KPI: 100% zapytań zweryfikowanych pod kątem naruszenia).
  • CAP-02: Oficjalne powiadomienie administratorów danych (dyrektorów szpitali) o zaistniałym incydencie zgodnie z art. 33 RODO wraz z raportem technicznym i zaleceniami (Termin: 24h, Właściciel: IOD / Radca Prawny, KPI: Dostarczenie kompletnego pakietu informacyjnego do poszkodowanych podmiotów).
  • CAP-03: Implementacja rzeczywistego mechanizmu AWS KMS Multi-Tenant Encryption (klucze BYOK zarządzane przez klientów) (Termin: 30 dni, Właściciel: Dyrektor Bezpieczeństwa Chmury, KPI: 100% baz klientów zaszyfrowanych unikalnymi kluczami).
  • CAP-04: Wdrożenie zautomatyzowanych testów Cross-Tenant Leakage w pipeline CI/CD oraz zlecenie ponownego audytu SOC 2 Type II przez niezależnego audytora (Termin: 60 dni, Właściciel: QA Security Lead / CISO, KPI: Uzyskanie czystej opinii audytorskiej SOC 2).

Zalety rozwiązania:

• Odzyskanie zaufania szpitali i partnerów medycznych dzięki transparentnemu załatwieniu incydentu.
• Zapewnienie trwałej, kryptograficznej i logicznej separacji danych pacjentów w architekturze multi-tenant.
• Pełna zgodność z normami ISO 27017, ISO 27018 oraz kryteriami SOC 2 Type II.

Wady i ograniczenia:

• Znaczny wzrost złożoności zarządzania kluczami kryptograficznymi AWS KMS dla ponad 200 klientów (konieczność automatyzacji procesów rotacji).
• Ryzyko krótkoterminowych pozwów cywilnych lub roszczeń odszkodowawczych od klientów za naruszenie SLA.
• Koszty ponownego przeprowadzenia audytu poświadczeniowego SOC 2 Type II (szacunek: 180 000 PLN).

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) – art. 28 (podmiot przetwarzający), art. 32, art. 33, art. 34.
• Norma ISO/IEC 27017:2015 – Security controls for cloud services.
• Norma ISO/IEC 27018:2019 – Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors.
• AICPA Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (SOC 2).
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.5.19, A.5.20, A.8.11, A.8.12, A.8.24.
• Cloud Security Alliance (CSA) – Cloud Controls Matrix (CCM v4) oraz Security Guidance for Critical Areas of Focus in Cloud Computing.

• W1 Ochrona tajemnicy telekomunikacyjnej, bezpieczeństwo integralności publicznych sieci łączności i infrastruktury krytycznej.
• W2W3 Wymogi Dyrektywy NIS2, Prawa komunikacji elektronicznej, normy PN-EN ISO/IEC 27001:2022 oraz wytycznych sektorowych ISO/IEC 27011:2016 (zarządzanie incydentami bezpieczeństwa informacji) oraz inicjatywy MANRS (Mutually Agreed Norms for Routing Security). Uwaga: MANRS to inicjatywa Internet Society, a nie dokument RFC.
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Sieci Telekomunikacyjnej z architekturą bezpiecznego routingu (RPKI, ROA, BGP Flowspec) i anty-DDoS.
• U2 Dokumentacja uchybień w modelu 4C z analizą 5 Why dla incydentu przejęcia prefiksów BGP i paraliżu węzła filtracji ruchu (Scrubbing Center).
• U3 Przeprowadzenie analizy ryzyka 5x5 dla globalnego odcięcia usług cyfrowych w państwie, parametry RTO (5 minut) i RPO (0 pakietów krytycznych).
• U4 Sformułowanie Planu Działań Korygujących (CAP) i Executive Summary w formule Pitch to Board.
• K1K2K3 Zrozumienie wagi stabilności globalnej sieci Internet dla bezpieczeństwa narodowego, etyka i bezkompromisowość audytorska.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie specjalistycznego audytu bezpieczeństwa, odporności routingowej oraz ciągłości usług u wiodącego operatora telekomunikacyjnego zarządzającego krajowym węzłem wymiany ruchu internetowego (Internet Exchange Point - IXP / Tier-1). Przedsiębiorstwo jest wpisane do jednolitego wykazu obiektów Infrastruktury Krytycznej Państwa, jest Podmiotem Kluczowym w rozumieniu Dyrektywy NIS2 oraz podlega pod rygor Ustawy Prawo telekomunikacyjne / Prawo komunikacji elektronicznej (PKE) i wytyczne Urzędu Komunikacji Elektronicznej (UKE). Węzeł pośredniczy w wymianie 40% ruchu internetowego w kraju, w tym w obsłudze systemów rządowych, bankowych i ratunkowych. Zadanie wymaga przeanalizowania incydentu zmasowanego ataku wolumetrycznego DDoS (1,8 Tbps) skorelowanego z incydentem BGP Route Leak / Hijacking, sporządzenia karty niezgodności 4C, wyliczenia ryzyka w matrycy 5x5 oraz obrony Planu CAP przed Zarządem w formule 90 minut.

Spółka "TelcoPol IXP S.A." zarządza dwoma centrami kolokacyjnymi połączonymi pierścieniem DWDM o przepustowości 16 Tbps, zapewniając peering dla 340 operatorów internetowych, dostawców treści (CDN) oraz instytucji rządowych.

W trakcie skoordynowanego incydentu cybernetycznego o zasięgu międzynarodowym doszło do:

1. Incydent BGP Hijacking / Route Leak: Zagraniczny operator tranzytowy wyemitował błędne anonse routingowe BGP (Autonomous System BGP Route Leak), w wyniku których ruch kierowany do rządowych portali e-administracji (gov.pl) oraz trzech głównych banków został przekierowany przez infrastrukturę zlokalizowaną w państwie autorytarnym. Operator TelcoPol nie posiadał wdrożonej walidacji pochodzenia tras RPKI (Resource Public Key Infrastructure Route Origin Validation - ROV) z polityką odrzucania tras nieprawidłowych (Invalid Drop), co spowodowało automatyczne zainstalowanie fałszywych tras w tablicach FIB routerów brzegowych.

2. Zmasowany atak DDoS o wolumenie 1,8 Tbps i przeciążenie Scrubbing Center: Równolegle z anonsami BGP węzeł został zaatakowany zmasowanym atakiem DDoS łączącym amplifikację DNS/NTP z powodzią pakietów TCP SYN (1,8 Tbps, 420 milionów pakietów na sekundę). Własne centrum czyszczenia ruchu (Scrubbing Center) operatora posiadało łączną wydajność 800 Gbps, w wyniku czego doszło do wysycenia łącz wejściowych, degradacji działania całego węzła i niedostępności usług dla 4 milionów użytkowników końcowych przez 45 minut.

3. Brak mechanizmów BGP Flowspec i automatycznego Remote Triggered Blackholing (RTBH): Operator nie posiadał zautomatyzowanego systemu wykrywania ataków powiązanego z mechanizmem RTBH lub regułami BGP Flowspec, które pozwoliłyby na selektywne odcinanie atakowanego ruchu na poziomie sieci dostawców nadrzędnych (Upstream Tier-1 Providers). Konfiguracja reguł filtracyjnych wymagała manualnej interwencji inżyniera dyżurnego NOC.

4. Niezapewniona retencja i bezpieczeństwo logów NetFlow: Zgodnie z Prawem telekomunikacyjnym operator jest zobowiązany do retencji metadanych telekomunikacyjnych przez okres 12 miesięcy. Serwery kolektorów NetFlow uległy awarii pod wpływem wolumenu pakietów ataku, co doprowadziło do utraty logów teletransmisyjnych z okresu 6 godzin, uniemożliwiając organom ścigania analizę ataku.

• Faza 1 (Minuty 00-15): Triada audytorska i model zagrożeń BGP/DDoS.
  • Role: Lead Auditor (NIS2, PKE, Infrastruktura Krytyczna, raport dla Zarządu), Telco SecOps Auditor (analiza BGP, RPKI ROV, Flowspec, Scrubbing Center, peering), BCM/Legal Auditor (retencja danych, SLA operatorskie, CSIRT NASK/GOV).
  • Diagnoza wektora BGP: Weryfikacja braku walidacji ROV i identyfikacja asymetrii pojemności centrum anty-DDoS.
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Sporządzenie Karty Niezgodności 4C dla braku wdrożenia RPKI ROV i manualnego procesu mitygacji DDoS.
  • Analiza 5 Why: Dlaczego operator Tier-1 nie zaimplementował automatycznego odrzucania tras niepoprawnych w RPKI?
  • Matryca ryzyka 5x5: Oszacowanie skutków kaskadowej awarii łączności w kraju, kar UKE oraz odpowiedzialności za paraliż usług ratunkowych.
  • Wyznaczenie parametrów: RTO = 5 minut dla automatycznej mitygacji ataku, RPO = 0 pakietów krytycznych (QoS).
• Faza 3 (Minuty 40-70): Polityka Bezpieczeństwa Sieci Telekomunikacyjnej i Plan CAP.
  • Projekt Zintegrowanej Polityki Bezpieczeństwa Telekomunikacyjnego: Wymuszenie RPKI ROV (zgodnie z inicjatywą MANRS - Mutually Agreed Norms for Routing Security), hybrydowe centrum anty-DDoS (przełączenie Cloud-Scrubbing powyżej 600 Gbps), automatyzacja BGP Flowspec/RTBH przez API, klastrowanie kolektorów NetFlow.
  • Tabela Planu Działań Korygujących (CAP) ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i obrona przed Zarządem.
  • Opracowanie 1-stronicowej noty dla Prezesa Zarządu i Dyrektora Technicznego (CTO) z planem inwestycji w cyberodporność.
  • Ustna prezentacja i obrona ustaleń przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytu operatora telekomunikacyjnego:

• Strona tytułowa i Metryka Audytu (zespół, akredytacje, zakres audytu infrastruktury krytycznej).
• Rozdział 1: Executive Summary dla Zarządu TelcoPol IXP (1 strona A4: syntetyczna diagnoza załamania ciągłości usług, ekspozycja na kary UKE i NIS2, plan CAP).
• Rozdział 2: Ramy regulacyjne sektora telekomunikacyjnego (Dyrektywa NIS2 Podmiot Kluczowy, Prawo komunikacji elektronicznej, wytyczne UKE, standard ISO/IEC 27011:2016, inicjatywa MANRS oraz dokumentacja RPKI ROV opublikowana przez Internet Society).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 dla wektorów sabotażu routingowego i ataków wolumetrycznych (wyliczenie IR i RR).
• Rozdział 4: Projekt Zintegrowanej Polityki Cyberodporności Sieci Rdzeniowej:
  • Standard Bezpiecznego Routingu BGP (wdrożenie RPKI ROV, filtry prefiksów IRR, limity prefiksów Max-Prefix).
  • Architektura Wielopoziomowej Ochrony Przed Atakami DDoS (lokalne Scrubbing Center + automatyczny Cloud Signaling do globalnych dostawców mitygacji).
  • Standard automatyzacji BGP Flowspec i Remote Triggered Blackholing (RTBH).
  • Procedura wysokiej dostępności i retencji logów ruchu NetFlow/IPFIX.
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet, kosztów i harmonogram wdrożenia.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Brak wdrożenia walidacji pochodzenia tras RPKI ROV doprowadził do zainstalowania fałszywych anonsów BGP i przekierowania ruchu rządowego i bankowego do obcej infrastruktury; atak DDoS 1,8 Tbps sparaliżował węzeł z powodu manualnego procesu aktywacji filtrów i niewystarczającej przepustowości lokalnego Scrubbing Center; utracono 6 godzin logów NetFlow.
  • Criteria: Dyrektywa NIS2 art. 21 ust. 2 lit. c (ciągłość działania i zarządzanie kryzysowe), Prawo komunikacji elektronicznej (art. 42-45 obowiązki bezpieczeństwa sieci), standard RFC 6811 (BGP Prefix Origin Validation) oraz RFC 8529 (RPKI-RTR), PN-EN ISO/IEC 27011:2016 (wytyczne zarządzania incydentami), PN-EN ISO/IEC 27001:2022 Załącznik A.8.20, A.8.22.
  • Cause (5 Why):

Dlaczego doszło do akceptacji fałszywych tras? Bo na sesjach BGP z operatorami peeringowymi nie włączono polityki odrzucania tras niepoprawnych w RPKI.

Dlaczego jej nie włączono? Obawiano się przypadkowego zablokowania legalnego ruchu w przypadku błędów w konfiguracji certyfikatów ROA u partnerów.

Dlaczego atak DDoS wysycił węzeł? Bo lokalne Scrubbing Center miało wydajność 800 Gbps, a proces przekierowania do chmury partnerskiej wymagał zgody zarządu.

Dlaczego logi NetFlow zostały utracone? Bo kolektory nie miały buforowania kolejkowego na wypadek skrajnego przeciążenia.

Przyczyna źródłowa: Brak sformalizowanej strategii cyberodporności dla zagrożeń skrajnych (Black Swan Events) oraz brak wdrożenia standardów MANRS dla operatorów Tier-1.

• Consequence: Paraliż łączności dla 4 milionów obywateli i instytucji państwowych, podsłuch i potencjalna modyfikacja nieszyfrowanego ruchu przez obce służby specjalne (BGP Hijack), kara pieniężna od Prezesa Urzędu Komunikacji Elektronicznej do wysokości 3% przychodu podmiotu osiągniętego w poprzednim roku kalendarzowym (art. 446 ustawy z 12 lipca 2024 r. Prawo komunikacji elektronicznej, w zw. z art. 21a ust. 3 ustawy o zarządzaniu kryzysowym) oraz obowiązek obrony cywilnej wynikający z Prawa o obronie Ojczyzny, utrata statusu zaufanego operatora węzła wymiany ruchu.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5 (Katastrofalny). Ryzyko Inherentne: 20/25 (Krytyczne).

Kontrole: Wymuszenie walidacji RPKI Route Origin Validation (ROV) z regułą Invalid Drop na wszystkich sesjach eBGP, weryfikacja baz IRR i filtracja as-path.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Zagrożenie 2: Całkowity paraliż węzła wymiany ruchu przez atak wolumetryczny DDoS przekraczający wydajność lokalnych łącz.

Prawdopodobieństwo Inherentne: 5, Skutek Inherentny: 5. Ryzyko Inherentne: 25/25 (Maksymalne).

Kontrole: Wdrożenie zautomatyzowanego protokołu Cloud Signaling do zewnętrznej chmury anty-DDoS (o pojemności 15 Tbps), automatyczne reguły BGP Flowspec mitygujące ruch amplifikacyjny na brzegu sieci dostawców.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 3. Ryzyko Rezydualne: 3/25 (Akceptowalne).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Wdrożenie reguły "Invalid Drop" dla walidacji pochodzenia tras RPKI na wszystkich sesjach stykowych eBGP (Termin: 48h, Właściciel: Główny Inżynier Routingowy BGP, KPI: 100% nieprawidłowych anonsów odrzucanych w locie).
  • CAP-02: Podpisanie umowy i wdrożenie automatycznego Cloud Signalingu z globalnym dostawcą anty-DDoS aktywowanego automatycznie przy wysyceniu łącz powyżej 70% (Termin: 14 dni, Właściciel: Dyrektor Bezpieczeństwa Sieci, KPI: Czas reakcji na atak powyżej 1 Tbps poniżej 30 sekund).
  • CAP-03: Implementacja zautomatyzowanego systemu wykrywania anomalii powiązanego z automatyczną dystrybucją reguł BGP Flowspec do routerów brzegowych (Termin: 30 dni, Właściciel: Kierownik NOC/SOC, KPI: Likwidacja manualnego tworzenia reguł w trakcie incydentu).
  • CAP-04: Rozbudowa klastra kolektorów NetFlow w architekturze odpornej na przeciążenia z buforem kolejkowym Apache Kafka (Termin: 45 dni, Właściciel: Kierownik Działu Systemów IT, KPI: 0 utraconych rekordów NetFlow przy natężeniu ruchu do 500 mln pps).

Zalety rozwiązania:

• Zagwarantowanie stabilności i ciągłości funkcjonowania kluczowego węzła internetowego dla gospodarki państwa.
• Zgodność z Dyrektywą NIS2, zaleceniami UKE oraz międzynarodową inicjatywą MANRS.
• Eliminacja podatności na manipulacje trasami BGP i podsłuch strategicznego ruchu sieciowego.

Wady i ograniczenia:

• Znaczny koszt abonamentowy zewnętrznej usługi Cloud Scrubbing o przepustowości terabitowej (szacunek: 45 000 EUR miesięcznie).
• Ryzyko odrzucenia poprawnego ruchu nielicznych partnerów posiadających błędne wpisy ROA w bazach RIR (wymóg wsparcia technicznego dla peerów).
• Złożoność koordynacji procedur awaryjnych z dziesiątkami niezależnych operatorów telekomunikacyjnych.

• Źródło internetowe: RFC 6811 (BGP Prefix Origin Validation).
• Źródło internetowe: RFC 8529 (RPKI-RTR).
• Źródło internetowe: RFC 8210 (RPKI Trust Anchor Locator).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) – sektor infrastruktury cyfrowej (podmioty kluczowe).
• Ustawa z dnia 12 lipca 2024 r. – Prawo komunikacji elektronicznej (Dz.U. z 2024 r. poz. 1221).
• Norma ISO/IEC 27011:2016 (Information technology – Security techniques – Information security incident management guidelines; wytyczne zarządzania incydentami bezpieczeństwa informacji). Uwaga: zestawu wskaźników dla organizacji telekomunikacyjnych nie zawiera norma ISO/IEC 27011, lecz PN-EN ISO/IEC 27019:2017 oraz seria PN-EN IEC 62443.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.20, A.8.21, A.8.22, A.8.24.
• RFC 6811 – BGP Prefix Origin Validation oraz RFC 8529 – Resource Public Key Infrastructure (RPKI) to Router Protocol (RPKI-RTR). Uwaga: RFC 8210 dotyczy lokalizatora kotwicy zaufania RPKI (RPKI Trust Anchor Locator, TAL), a nie protokołu RPKI-RTR.
• Inicjatywa MANRS (Mutually Agreed Norms for Routing Security) – Dobre praktyki bezpieczeństwa dla operatorów sieci i IXP, Internet Society 2023.

• W1 Ochrona tajemnicy patentowej, danych medycznych uczestników badań klinicznych (RODO art. 9) oraz integralności badań farmaceutycznych.
• W2W3 Rygory regulacji farmaceutycznych (przepisy FDA 21 CFR Part 11, załącznik 11 do wytycznych Good Manufacturing Practice (GMP) w zakresie komputerowych systemów sterowanych elektronicznie, oraz zasady ALCOA+), NIS2, ustawy z dnia 6 września 2001 r. Prawo farmaceutyczne (Dz.U. z 2008 r. Nr 45 poz. 271) oraz ISO/IEC 27001:2022.
• U1 Opracowanie Zintegrowanej Polityki Bezpieczeństwa Informacji i Integralności Danych Farmaceutycznych (Data Integrity Governance).
• U2 Dokumentacja uchybień w modelu 4C z analizą 5 Why dla incydentu manipulacji ścieżką audytową (Audit Trail) i sfałszowania pomiarów stabilności leków.
• U3 Przeprowadzenie analizy ryzyka 5x5 uwzględniającej utratę licencji wytwórczej i dyskwalifikację badań klinicznych, parametry RTO (1 godzina) i RPO (0 pomiarów utraconych).
• U4 Sformułowanie Planu Działań Korygujących (CAP) i Executive Summary dla Zarządu i Osoby Wykwalifikowanej (Qualified Person).
• K1K2K3 Bezwzględna etyka naukowa, ochrona zdrowia i życia pacjentów przyjmujących leki, wysoki profesjonalizm audytorski.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu integralności danych (Data Integrity wg zasad ALCOA+), bezpieczeństwa teleinformatycznego oraz ciągłości działania w międzynarodowym koncernie farmaceutycznym. Koncern prowadzi badania kliniczne fazy III nad innowacyjnymi lekami onkologicznymi oraz zarządza zautomatyzowanym zakładem sterylnej produkcji leków z wykorzystaniem systemów SCADA, systemów LIMS (Laboratory Information Management System) i inteligentnych czujników IoT w łańcuchu chłodniczym (-80 st. C). Przedsiębiorstwo podlega pod rygorystyczne przepisy amerykańskiej Agencji ds. Żywności i Leków (FDA 21 CFR Part 11 – podpisy elektroniczne i ścieżki audytowe), unijnych Dobrych Praktyk Wytwarzania (GMP EudraLex Tom 4 Aneks 11 – systemy skomputeryzowane), Dyrektywy NIS2 oraz RODO. Zadanie wymaga zbadania incydentu manipulacji logami audytowymi w systemie LIMS i sabotażu IoT w chłodniach, sporządzenia karty niezgodności 4C, wyliczenia ryzyka wstrzymania rejestracji leku w matrycy 5x5 oraz obrony Planu CAP przed Zarządem.

Koncern "BioPharm Global S.A." zatrudnia 1 500 pracowników i finalizuje 7-letnie badania kliniczne fazy III nad przełomowym lekiem immunologicznym. Szacowana wartość rynkowa patentu wynosi 1,2 miliarda EUR. Wniosek rejestracyjny został złożony równolegle do Europejskiej Agencji Leków (EMA) oraz amerykańskiej FDA.

W trakcie audytu przed-inspekcyjnego przeprowadzonego przez międzynarodowy zespół audytorów ujawniono krytyczne usterki:

1. Manipulacja ścieżką audytową (Audit Trail) i naruszenie zasad ALCOA+ w systemie LIMS: W systemie zarządzania informacją laboratoryjną LIMS stwierdzono, że konta użytkowników o uprawnieniach administratora bazy danych (DBA) posiadały techniczną możliwość bezpośredniej edycji tabel z surowymi wynikami chromatografii cieczowej (HPLC) z pominięciem rejestracji w ścieżce audytowej (Audit Trail). Wykryto, że 3 tygodnie temu dokonano ręcznej korekty stężenia zanieczyszczeń w serii próbnej leku, aby spełnić rygorystyczne normy stabilności chemicznej, a wpis w logu systemowym został usunięty za pomocą skryptu SQL.

2. Podatność czujników IoT w chłodniach i sabotaż łańcucha chłodniczego: W magazynie próbek klinicznych i substancji czynnych (API) temperatura musi być stale utrzymywana na poziomie -80 st. C (+/- 2 st. C). Przemysłowe czujniki temperatury IoT komunikowały się z systemem SCADA bezprzewodowo za pomocą nieszyfrowanego protokołu Modbus TCP/Zigbee. Podczas testów penetracyjnych audytorzy zdołali przechwycić transmisję i podmienić odczyty temperatury na konsoli dyspozytora, podczas gdy rzeczywista temperatura w komorze wzrosła do -65 st. C, co doprowadziło do bezpowrotnej degradacji termicznej 400 fiolek substancji wzorcowej.

3. Współdzielone konta operatorów na liniach produkcyjnych: Przy tabletkarkach i sterylnych liniach nalewania operatorzy logowali się na panelach HMI wspólnym kontem `operator_linia_1`, a hasło było zapisane markerem na obudowie maszyny. Uniemożliwia to przypisanie odpowiedzialności za zatwierdzanie poszczególnych etapów szarży produkcyjnej (brak atrybucji - naruszenie zasady Attributable w ALCOA+).

4. Brak walidacji skomputeryzowanego środowiska chmurowego (CSV): Platforma wymiany danych z ośrodkami klinicznymi (eCRF) została zmigrowana do chmury publicznej bez formalnej walidacji systemów skomputeryzowanych (Computerized System Validation - CSV wg wytycznych GAMP 5), co stanowi naruszenie Aneksu 11 GMP i automatycznie dyskwalifikuje dane w oczach inspektorów FDA.

• Faza 1 (Minuty 00-15): Triada audytorska i model ALCOA+.
  • Role: Lead Auditor (FDA 21 CFR Part 11, GMP Aneks 11, raport dla Zarządu i Osoby Wykwalifikowanej), Pharma SecOps Auditor (analiza LIMS, SCADA chłodni, IoT Modbus, kryptografia), Compliance/CSV Auditor (walidacja GAMP 5, RODO art. 9, procedury szarży produkcyjnej).
  • Diagnoza naruszenia ALCOA+: Sprawdzenie kryteriów: Attributable, Legible, Contemporaneous, Original, Accurate.
• Faza 2 (Minuty 15-40): Model 4C, Matryca 5x5 i Analiza Przyczyn Źródłowych.
  • Karta Niezgodności 4C dla modyfikacji surowych danych w LIMS oraz podatności czujników chłodniczych IoT.
  • Analiza 5 Why: Dlaczego administrator bazy danych miał bezpośredni dostęp do tabel produkcyjnych LIMS bez rejestracji w Audit Trail?
  • Matryca ryzyka 5x5: Oszacowanie skutków wydania ostrzeżenia FDA Warning Letter, wstrzymania rejestracji leku i utraty patentu o wartości 1,2 mld EUR.
  • Wyznaczenie parametrów odporności: RTO = 1h dla SCADA chłodnictwa, RPO = 0 pomiarów (ciągła archiwizacja WORM).
• Faza 3 (Minuty 40-70): Polityka Bezpieczeństwa Informacji Farmaceutycznej i Plan CAP.
  • Projekt Zintegrowanej Polityki Bezpieczeństwa i Integralności Danych (Data Integrity Governance): Zabezpieczenie Audit Trail w bazie LIMS (technologia Write-Once-Read-Many z podpisem cyfrowym), szyfrowanie transmisji IoT w protokołach SCADA (TLS dla Modbus / IEEE 802.15.4), indywidualne karty RFID dla operatorów HMI, ramy walidacji CSV wg GAMP 5.
  • Tabela Planu Działań Korygujących (CAP) ze wskaźnikami KPI.
• Faza 4 (Minuty 70-90): Executive Summary i obrona przed Zarządem.
  • Przygotowanie 1-stronicowego kryzysowego Executive Summary dla Zarządu i Osoby Wykwalifikowanej z oceną ryzyka inspekcji FDA/EMA.
  • Ustna prezentacja i symulacja obrony raportu przed prowadzącym. W wariancie 90-minutowym obrona trwa około 5 minut; wariant rozszerzony (20 minut) realizowany jest poza zegarem 90-minutowym.

Uwaga metodologiczna: poniższa tabela zawiera dwa przykładowe wiersze i stanowi wzorzec sposobu oceny, a nie kompletny rejestr ryzyka. W pracy należy uzupełnić rejestr o co najmniej cztery aktywa krytyczne zidentyfikowane dla badanego podmiotu, dla każdego wpisując zagrożenie, prawdopodobieństwo i skutek w skali 1-5, ryzyko inherentne, stosowane i planowane kontrole oraz ryzyko rezydualne. Kryterium doboru aktywu krytycznego stanowi kluczowy wpływ na świadczenie usługi krytycznej, udokumentowany w analizie wpływu na bezpieczeństwo.

Zaawansowana matryca ryzyka 5x5 (P: 1-5, S: 1-5) w skali 1-25. Prawdopodobieństwo: 1 – rzadkie, 2 – mało prawdopodobne, 3 – możliwe, 4 – prawdopodobne, 5 – częste. Skutek: 1 – znikomy, 2 – mały, 3 – średni, 4 – poważny, 5 – katastrofalny. Poziom ryzyka to iloczyn P x S. Strefa czerwona (13-25) – ryzyko niedopuszczalne, wymaga natychmiastowych kontroli, strefa żółta (5-12) – ryzyko warunkowo akceptowalne, strefa zielona (1-4) – ryzyko akceptowalne. Tabele zawierają ryzyko inherentne (IR) przed kontrolami oraz rezydualne (RR) po wdrożeniu zabezpieczeń.

Karty ryzyka (P x S) dla kluczowych aktywów jednostki:

Wiążący Plan Działań Korygujących z właścicielami, terminami (horyzont do 7 dni, do 30 dni, do 90 dni) oraz mierzalnymi wskaźnikami KPI/KRI.

Raport zespołowy musi spełniać standardy audytu farmaceutycznego (GxP):

• Strona tytułowa i Metryka Audytu (zespół, certyfikaty audytorów GxP, zakres audytu).
• Rozdział 1: Executive Summary dla Zarządu BioPharm Global i Osoby Wykwalifikowanej (1 strona A4: syntetyczna diagnoza naruszeń integralności danych, ekspozycja na FDA Warning Letter, plan CAP).
• Rozdział 2: Ramy regulacyjne sektora farmaceutycznego (FDA 21 CFR Part 11, EudraLex Tom 4 Aneks 11, zasady ALCOA+, Dyrektywa NIS2, ISO/IEC 27001:2022).
• Rozdział 3: Analiza Ryzyka w Matrycy 5x5 dla procesów laboratoryjnych LIMS i magazynowania próbek SCADA (wyliczenie IR i RR).
• Rozdział 4: Projekt Polityki Bezpieczeństwa Informacji i Ładu Integralności Danych (Data Integrity Governance):
  • Standard Ochrony Ścieżek Audytowych (Audit Trail: niemodyfikowalne logi, zakaz bezpośredniego dostępu SQL dla DBA, cykliczny przegląd logów).
  • Standard Bezpieczeństwa Automatyki i IoT w Łańcuchu Chłodniczym (szyfrowanie protokołów, redundantne czujniki przewodowe, systemy alarmowania out-of-band).
  • Polityka Uwierzytelniania na Liniach Produkcyjnych HMI (karty zbliżeniowe, automatyczna blokada, zakaz kont grupowych).
  • Standard Walidacji Systemów Skomputeryzowanych (CSV wg GAMP 5 dla środowisk chmurowych eCRF).
• Rozdział 5: Rejestr Ustaleń 4C z analizą 5 Why oraz Plan Działań Korygujących (CAP).
• Rozdział 6: Analiza wad, zalet, kosztów i planu wdrożenia.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

• Karta Niezgodności Dużej (NC1) w modelu 4C:
  • Condition: Administrator DBA posiadał możliwość bezpośredniej modyfikacji danych wyników HPLC w bazie LIMS z pominięciem Audit Trail, co doprowadziło do sfałszowania danych stabilności leku; czujniki temperatury w chłodniach -80 st. C działały na nieszyfrowanym protokole Modbus, co umożliwiło manipulację odczytami i zniszczenie 400 fiolek próbek klinicznych.
  • Criteria: FDA 21 CFR Part 11 (sekcja 11.10 kontrole systemów zamkniętych, podpisy i ścieżki audytu), EudraLex Tom 4 Aneks 11 (punkty 4, 9, 12 dotyczące bezpieczeństwa i integralności), wytyczne WHO i EMA dotyczące Data Integrity (ALCOA+), ISO 27001 Załącznik A.8.15, A.8.20, A.8.24.
  • Cause (5 Why):

Dlaczego administrator mógł edytować bazę bez wpisu w Audit Trail? Ponieważ mechanizm Audit Trail zaimplementowano na poziomie aplikacji, a nie na poziomie silnika bazodanowego (brak triggerów bazodanowych i braku odrębnego schematu tylko do odczytu).

Dlaczego administrator wykonał edycję? Otrzymał nieformalne polecenie od kierownika laboratorium, aby skorygować pojedynczy wynik przed audytem FDA.

Dlaczego czujniki IoT nie były szyfrowane? Zakupiono najtańsze czujniki komercyjne bez uwzględnienia wymagań walidacji CSV.

Dlaczego wdrożono chmurę eCRF bez walidacji? Zespół IT potraktował chmurę jako infrastrukturę ogólną, nie podlegającą pod rygory farmaceutyczne.

Przyczyna źródłowa: Brak nadrzędnego nadzoru Działu Zapewnienia Jakości (QA) nad projektami IT oraz brak kultury integralności danych (Quality Culture).

• Consequence: Wydanie decyzji FDA Warning Letter i Import Alert (zakaz sprzedaży produktów w USA), natychmiastowe wstrzymanie procesu rejestracji leku przez EMA, utrata 1,2 mld EUR wartości rynkowej patentu, cofnięcie certyfikatu GMP dla zakładu produkcyjnego, odpowiedzialność karna kierownictwa za fałszowanie dokumentacji leku.

Prawdopodobieństwo Inherentne: 5, Skutek Inherentny: 5 (Katastrofalny). Ryzyko Inherentne: 25/25 (Maksymalne).

Kontrole: Implementacja kryptograficznie zabezpieczonego Audit Trail na poziomie bazy danych z replikacją do niemodyfikowalnego zasobnika WORM, odebranie uprawnień bezpośredniego zapisu SQL dla DBA, wdrożenie procedury Dual-Control dla zmian w konfiguracji.

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 2. Ryzyko Rezydualne: 2/25 (Niskie).

• Zagrożenie 2: Zniszczenie próbek klinicznych przez sabotaż lub awarię nieszyfrowanych czujników IoT w chłodniach -80 st. C.

Prawdopodobieństwo Inherentne: 4, Skutek Inherentny: 5. Ryzyko Inherentne: 20/25.

Kontrole: Wymiana czujników na przemysłowe urządzenia z szyfrowaniem TLS/AES-128, instalacja niezależnego, przewodowego systemu monitorowania temperatury z certyfikatem kalibracji PCA oraz alarmowaniem SMS/telefonicznym poza pasmem (Out-of-Band).

Prawdopodobieństwo Rezydualne: 1, Skutek Rezydualny: 1. Ryzyko Rezydualne: 1/25 (Znikome).

• Tabela Planu Działań Korygujących (CAP):
  • CAP-01: Bezwzględna blokada bezpośredniego dostępu do bazy produkcyjnej LIMS przez odebranie konta sa/root dla personelu i wymuszenie dostępu wyłącznie przez zweryfikowaną aplikację LIMS (Termin: 24h, Właściciel: CISO / QA IT Manager, KPI: 0 bezpośrednich sesji SQL do bazy LIMS).
  • CAP-02: Zgłoszenie incydentu zniszczenia 400 fiolek do Działu Jakości i powołanie zespołu śledczego ds. Data Integrity w celu zbadania skali fałszowania wyników (Termin: 48h, Właściciel: Osoba Wykwalifikowana / Dyrektor QA, KPI: Kompletny raport z dochodzenia wewnętrznego).
  • CAP-03: Wymiana bezprzewodowych czujników IoT w chłodniach na system zwalidowany wg GAMP 5 z redundantnym pomiarem przewodowym i szyfrowaniem transmisji (Termin: 30 dni, Właściciel: Główny Inżynier Automatyki, KPI: 100% komór chłodniczych z podwójnym, niezależnym pomiarem).
  • CAP-04: Przeprowadzenie pełnej walidacji CSV środowiska chmurowego eCRF oraz wdrożenie kart RFID na panelach HMI linii produkcyjnych (Termin: 60 dni, Właściciel: Kierownik Walidacji CSV / Dyrektor Produkcji, KPI: Likwidacja kont grupowych, uzyskanie zatwierdzonego raportu walidacyjnego CSV).

Zalety rozwiązania:

• Uratowanie strategicznego projektu leku onkologicznego przed dyskwalifikacją przez regulatorów (FDA i EMA).
• Zapewnienie pełnej zgodności z FDA 21 CFR Part 11, GMP Aneks 11 oraz zasadami ALCOA+.
• Wdrożenie najwyższych standardów integralności danych w produkcji leków ratujących życie.

Wady i ograniczenia:

• Znaczny koszt walidacji systemów skomputeryzowanych (CSV) oraz wymiany aparatury pomiarowej w chłodniach (szacunek: 780 000 PLN).
• Wydłużenie czasu procedur laboratoryjnych o około 10-15% z powodu konieczności podwójnego podpisu elektronicznego przy zatwierdzaniu prób.
• Ryzyko konieczności powtórzenia części testów stabilności chemicznej dla skompromitowanych serii leku.

• US FDA Title 21 Code of Federal Regulations Part 11 (21 CFR Part 11) – Electronic Records; Electronic Signatures.
• EudraLex The Rules Governing Medicinal Products in the European Union – Volume 4, Good Manufacturing Practice, Annex 11: Computerised Systems.
• ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition, 2022).
• WHO Technical Report Series, No. 996, Annex 5: Guidance on good data and record management practices (ALCOA+ Framework).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) – sektor produkcji farmaceutycznej.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) – art. 9 i art. 32.
• Norma PN-EN ISO/IEC 27001:2022 – Załącznik A: A.8.15, A.8.20, A.8.24, A.8.28.

4. Kryteria weryfikacji i zaliczenia raportów przez prowadzącego (ocena 5.0)

Zgodnie z punktem 8 sylabusa przedmiotu Audyt bezpieczeństwa informacji, uzyskanie oceny 5.0 (bardzo dobry) wymaga wykazania się wyczerpującym opanowaniem materiału, samodzielnością myślenia analitycznego oraz zdolnością do syntezy skomplikowanych problemów techniczno-prawnych pod presją czasu.

Wymogi formalne zaliczenia na ocenę 5.0:

1. Kompletny Raport Audytowy i Projekt Architektury Bezpieczeństwa:

• Objętość: 10-15 stron znormalizowanego maszynopisu w formacie PDF. Uwaga o wykonalności: w wariancie 90-minutowym objętość 10-15 stron jest osiągalna wyłącznie przy wykorzystaniu przygotowanych w szkoleniu wzorców (metryka, matryca mapowania regulacji, rejestr ryzyka, karta 4C, tabela CAP, Podsumowanie Zarządcze), które należy uzupełniać, a nie tworzyć od zera. Przy wariancie 180-minutowym objętość tę można osiągnąć bez wzorców.
• Obowiązkowe artefakty:
  • Jednostronicowe Executive Summary w formacie "Pitch to Board" (zawierające syntetyczny opis kryzysu, bilans ryzyk finansowych i prawnych, macierz Quick Wins vs Inwestycje Strategiczne oraz rekomendację budżetową).
  • Matryca mapowania wielo-regulacyjnego (korelacja NIS2/DORA, RODO, norm branżowych i przepisów krajowych).
  • Karty Niezgodności Dużych i Małych opracowane w pełnym modelu 4C (Condition, Criteria, Cause, Consequence).
  • Sformalizowana Analiza Przyczyn Źródłowych metodą 5 Why dla każdego kluczowego uchybienia.
  • Zaawansowana Matryca Szacowania Ryzyka 5x5 (P: 1-5, S: 1-5) z wyliczeniem Ryzyka Inherentnego (IR) i Ryzyka Rezydualnego (RR) oraz określeniem parametrów RTO, RPO i MTPD.
  • Projekt Polityki Bezpieczeństwa Informacji z procedurami wykonawczymi operującymi na kontrolach ISO/IEC 27001:2022 (A.5, A.6, A.7, A.8).
  • Wiążący Plan Działań Korygujących (CAP) ze zdefiniowanymi właścicielami, horyzontem czasowym (do 7 dni, do 30 dni, do 90 dni) i mierzalnymi wskaźnikami KPI/KRI.

2. Zespołowa Obrona Raportu w Formule "Pitch to Board":

• Czas trwania w wariancie 180-minutowym: 10 minut wystąpienia + 10 minut pytań krzyżowych, w trakcie ostatnich 20 minut zajęć. W wariancie 90-minutowym obrona trwa około 5 minut i jest realizowana poza zegarem 90-minutowym, jako końcowy etap prezentacji ustaleń przed prowadzącym; wersja 10 + 10 minut wymaga wariantu rozszerzonego.
• Prowadzący zajęcia wciela się w rolę Prezesa Zarządu / Dyrektora Generalnego badanej organizacji, testując odporność audytorów na trudne pytania biznesowe, zarzuty o "paraliżowanie operacji" oraz kwestionowanie kosztów proponowanych zabezpieczeń.
• Każdy członek zespołu musi aktywnie obronić swoją część raportu (Lead Auditor – zgodność i ramy zarządcze; SecOps – architekturę technologiczną; BCM – parametry RTO/RPO i analizę ryzyka).

Macierz wagowa oceny 5.0:

• Metodyka 4C i Analiza Przyczyn Źródłowych 5 Why (waga: 25%): Poprawność konstrukcji zarzutów audytowych, odróżnienie symptomu od przyczyny rdzennej, precyzja powołań normatywnych i prawnych.
• Zaawansowana Analiza Ryzyka i Parametry Ciągłości (waga: 25%): Realizm wag prawdopodobieństwa i skutku w matrycy 5x5, adekwatność redukcji ryzyka po kontrolach kompensacyjnych, poprawne wyliczenie RTO/RPO.
• Projekt Architektury Bezpieczeństwa i Plan CAP (waga: 25%): Spójność technologiczna (Zero-Trust, mikrosegmentacja, kryptografia, WORM), wykonalność operacyjna oraz mierzalność wskaźników KPI.
• Poziom Podsumowania Zarządczego i Profesjonalizm Obrony Ustnej (waga: 25%): Siła perswazji, posługiwanie się językiem korzyści biznesowej i ryzyka zarządczego, kultura słowa, brak potocyzmów i precyzja argumentacji.

Tabela porównawcza poziomów ocen: