Laboratorium 2

• U1 Opracowanie zintegrowanego planu audytu ISMS dla hybrydowej infrastruktury badawczo-medycznej z modelami AI.
• U2 Formułowanie i klasyfikacja uchybień w modelu 4C z analizą przyczyn źródłowych Root Cause Analysis (5 Why).
• U3 Przeprowadzenie analizy ryzyka risk-based w 25-stopniowej matrycy 5x5 (IR vs RR) oraz określenie RTO (1h) i RPO (15 min) dla bazy PACS.
• U4 Opracowanie kompletnego Planu Działań Korygujących (CAP) z mierzalnymi wskaźnikami KPI oraz jednostronicowego Executive Summary.
• W1 Ochrona danych szczególnych kategorii (genomika, onkologia, art. 9 RODO) oraz tajemnicy lekarskiej i badawczej.
• W2W3 Wymagania Dyrektywy NIS2, ISO/IEC 27001:2022, ISO 27799 (zdrowie), ISO/IEC 42001 (sztuczna inteligencja) oraz Krajowych Ram Interoperacyjności.
• K1K2K3 Postawa analityczna, odporność na presję autorytetów naukowych, etyka audytorska i obrona planu przed Dyrekcją Instytutu.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole ISO 27001/27002), Wyk4 (RODO i NIS2), Wyk5 (Risk-based audit ISO 27005), Wyk6 (Zaawansowane dowody), Wyk7 (Niezgodności 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego, zaawansowanego planu audytu ISMS w wiodącym instytucie badawczo-klinicznym o statusie Podmiotu Kluczowego Dyrektywy NIS2, przetwarzającym wielkie zbiory danych genetycznych i obrazowych (art. 9 RODO) z wykorzystaniem klastrów High Performance Computing (HPC) oraz zewnętrznych modeli sztucznej inteligencji (AI/ML). Zadanie wymaga zastosowania metodyki Triady Audytorskiej, sformułowania ustaleń w kanonicznym modelu 4C (Condition, Criteria, Cause, Consequence), przeprowadzenia analizy ryzyka w matrycy 5x5 z wyznaczeniem parametrów BCM (RTO/RPO) oraz przygotowania Planu Działań Korygujących (CAP) ze wskaźnikami KPI i Podsumowania Zarządczego (Executive Summary).

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

Złożone incydenty i uchybienia ujawnione w audycie zerowym:

• Incydent w łańcuchu dostaw AI: Zewnętrzny dostawca zintegrowanego modelu AI (brytyjski startup medyczny) posiadał stałe, nienadzorowane połączenie VPN typu Site-to-Site do produkcyjnej bazy PACS. W wyniku kompromitacji repozytorium kodu dostawcy doszło do eksfiltracji ponad 180 000 obrazów diagnostycznych wraz z metadanymi DICOM. Mimo usunięcia nazwisk, w nagłówkach pozostawiono numery PESEL, kody pocztowe i kody aparatów diagnostycznych, co umożliwia re-identyfikację pacjentów w 89% przypadków.
• Podatności klastra HPC i brak szyfrowania: Klaster obliczeniowy HPC wykorzystywany do obróbki genowej działa na współdzielonych kontach root, a obrazy dysków wirtualnych oraz zasobniki S3 zawierające sekwencje genomowe nie mają wymuszonego szyfrowania w spoczynku za pomocą kluczy zarządzanych przez Instytut (Customer Managed Keys).
• Naruszenia w radiologii: Radiolodzy na dyżurach nocnych korzystają ze wspólnego konta serwisowego dyzur_radiologia_noc, a funkcja blokady ekranu została permanentnie wyłączona w rejestrze stacji diagnostycznych.
• Ciągłość działania i brak ochrony przed Ransomware: Kopie bazy PACS trafiają na macierz dyskową w tej samej szafie rackowej (brak kopii niemodyfikowalnej WORM/Air-Gap). Ostatni pełny test odtworzeniowy DRP zakończył się błędem spójności baz danych.

Zespół studentów (2-3 osoby) wciela się w Triadę Audytorską:

• Krok 1 (Podział ról i metodyka Triady Audytorskiej):

Rola A (Lead Auditor / CISO Representative): Kieruje audytem, zarządza zbieżnością regulacyjną (NIS2, RODO art. 9, KRI, ISO 42001), sporządza 1-stronicowe Executive Summary i przewodniczy spotkaniom otwierającym/zamykającym.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt klastra HPC, chmury AWS, bezpieczeństwa API i bazy PACS, szyfrowania KMS/HSM, mechanizmów Zero-Trust i zapór sieciowych.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5, wyznacza parametry RTO/RPO/MTPD dla bazy PACS, formułuje ustalenia w modelu 4C z analizą 5 Why oraz konstruuje Plan CAP ze wskaźnikami KPI.

• Krok 2 (Wyznaczenie granic, zakresu i bezwzględnych ograniczeń):

Zakres: Centrum danych, klaster HPC, chmura AWS, system PACS, stacje radiologii, umowy z dostawcami AI.

Ograniczenia: Bezwzględny zakaz aktywnego skanowania podatności urządzeń PET/CT i akceleratorów liniowych podłączonych do pacjentów; inspekcja wyłącznie metodami pasywnymi (analiza konfiguracji off-line, nasłuch SPAN port).

• Krok 3 (Ustalenie kryteriów audytowych w warunkach zbieżności regulacyjnej):

Kryteria: Dyrektywa NIS2 (art. 21 - środki cyberbezpieczeństwa), Norma PN-EN ISO/IEC 27001:2022 (A.5.19-A.5.22, A.8.11, A.8.12, A.8.20, A.8.24), Norma ISO 27799 (bezpieczeństwo w zdrowiu), Norma ISO/IEC 42001 (system zarządzania AI), RODO (art. 9, 32, 35).

• Krok 4 (Szacowanie ryzyka w zaawansowanej matrycy 5x5):

Oceńcie Prawdopodobieństwo (1-5) i Skutek (1-5) dla 3 wektorów zagrożeń:

• Zagrożenie 1: Eksfiltracja danych genomowych z klastra HPC przez podatność API dostawcy AI. P=4, S=5 (Katastrofalny - ujawnienie profilu genetycznego). Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Izolowane środowisko Data Clean Room, szyfrowanie KMS z HSM, audyt mTLS. Ryzyko rezydualne: P=1, S=3 (3/25 - Akceptowalne).
• Zagrożenie 2: Atak ransomware paraliżujący bazę PACS i proces naświetlań onkologicznych. P=4, S=5. Ryzyko inherentne: 20/25. Kontrole: Niemodyfikowalne kopie WORM w AWS S3 Object Lock, separacja sieci medycznej, mikro-segmentacja. Ryzyko rezydualne: P=1, S=2 (2/25).
• Zagrożenie 3: Manipulacja wynikami diagnostycznymi na stacjach radiologii wskutek kont współdzielonych. P=3, S=4. Ryzyko inherentne: 12/25 (Wysokie). Kontrole: Klucze FIDO2, szybkie przełączanie sesji, EDR. Ryzyko rezydualne: 2/25.

Wyznaczenie BCM: RTO = 1 godzina (dla przywrócenia bazy PACS), RPO = 15 minut (maksymalna utrata danych diagnostycznych), MTPD = 4 godziny.

• Krok 5 (Opracowanie Karty Ustalenia w kanonicznym modelu 4C):

Opracujcie pełną kartę 4C dla uchybienia w łańcuchu dostaw AI (Condition, Criteria, Cause z analizą 5 Why, Consequence).

• Krok 6 (Konstrukcja Planu CAP ze wskaźnikami KPI):

Rozpiszcie tabelę działań naprawczych w horyzontach: natychmiastowe (0-7 dni), krótkoterminowe (30 dni), systemowe (90 dni) z konkretnymi metrykami KPI (np. 100% kluczy w HSM, 0 kont współdzielonych, 100% zanonimizowanych metadanych DICOM).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Rozpisanie równoległych strumieni audytowych: Strumień Chmury/HPC, Strumień Kliniczny/PACS, Strumień Zgodności i BCM.

Struktura 15-minutowego wystąpienia seminaryjnego:

• Pitch to Board - Executive Summary (3 min): Przedstawienie jednostronicowego podsumowania zarządczego: skala ekspozycji prawnej (kary do 10 mln EUR z RODO i NIS2), zagrożenia dla pacjentów, wnioskowany budżet CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (4 min): Prezentacja kwantyfikacji ryzyka 20/25 -> 3/25 oraz parametrów RTO=1h / RPO=15min (BCM Auditor).
• Dekonstrukcja wektorów technicznych (HPC, AI, DICOM, PACS) (4 min): Dowody braku szyfrowania KMS, analiza podatności w VPN dostawcy (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Przedstawienie analizy 5 Why i harmonogramu naprawczego (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedź na zarzuty Dyrekcji dotyczące rzekomego spowolnienia badań naukowych przez audyt (cały zespół).

Raport końcowy (10-14 stron znormalizowanego maszynopisu) musi obejmować:

A. Jednostronicowe Podsumowanie Zarządcze (Executive Summary - Pitch to Board):

• Tytuł: Raport Zarządczy z Audytu ISMS i Cyberodporności w CPD-Onko.
• Kluczowy komunikat: Działalność badawcza i diagnostyczna Instytutu obarczona jest krytycznym ryzykiem (20/25) z powodu niekontrolowanego wycieku danych przez łańcuch dostaw AI oraz braku odporności na ataki ransomware. Ekspozycja prawno-finansowa: do 10 mln EUR kar z RODO i NIS2 oraz ryzyko paraliżu naświetlań onkologicznych. Plan CAP wymaga alokacji 450 tys. PLN w trybie pilnym (zwrot z inwestycji: zachowanie kontraktów badawczych i certyfikacji ISO 27001).

B. Zaawansowany Plan Audytu ISMS i Architektura Zgodności:

• Zleceniodawca: Dyrektor Naczelny Państwowego Instytutu Badawczego Onkologii.
• Zakres: Centrum danych, klaster HPC, infrastruktura AWS, system PACS/RIS, sieć PIONIER, 22 stacje radiologiczne, umowy z dostawcami AI.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Wyciek genomu przez API AI): IR = 4 x 5 = 20/25 (Strefa Krytyczna). Kontrole: Data Clean Room, KMS HSM, mTLS. RR = 1 x 3 = 3/25 (Akceptowalne).
  • Zagrożenie 2 (Ransomware bazy PACS): IR = 4 x 5 = 20/25. Kontrole: S3 Object Lock (WORM), mikrosegmentacja. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Wspólne konta radiologii): IR = 3 x 4 = 12/25. Kontrole: FIDO2, Fast-User-Switching. RR = 1 x 2 = 2/25.
  • Wskaźniki BCM: RTO = 1h, RPO = 15 min, MTPD = 4h.
• Karta Niezgodności w modelu 4C dla Incydentu Łańcucha Dostaw AI:
  • Condition (Stan faktyczny): Zewnętrzny dostawca AI posiadał stały, nielimitowany tunel VPN do bazy PACS. Doszło do eksfiltracji 180 000 obrazów DICOM zawierających numery PESEL i kody pocztowe w nagłówkach metadanych.
  • Criteria (Kryteria): ISO/IEC 27001:2022 A.5.19, A.5.20, A.8.12; Dyrektywa NIS2 art. 21 ust. 2 lit. d; RODO art. 9 ust. 1 i art. 32; ISO/IEC 42001 klauzula 8.
  • Cause (Przyczyna źródłowa - 5 Why):

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

Dlaczego nie usuwał tagów? -> Bo specyfikacja wymagań technicznych dla dostawcy nie została zweryfikowana pod kątem Privacy by Design.

Dlaczego nie zweryfikowano specyfikacji? -> Bo Dział Badań Klinicznych wdrożył integrację z pominięciem procedury nadzoru IT i IOD.

Dlaczego pominięto procedurę? -> Bo w regulaminie projektów naukowych brakowało bramki decyzyjnej Security Gate.

Przyczyna źródłowa (Root Cause): Brak nadrzędnego ładu zarządczego nad projektami badawczymi AI i brak izolowanego środowiska Data Clean Room do trenowania modeli uczenia maszynowego.

• Consequence (Skutki): Zagrożenie karą finansową do 10 mln EUR z RODO i NIS2, ryzyko utraty wiarygodności międzynarodowej i zerwania grantów z National Institutes of Health (NIH), ryzyko szantażu pacjentów.

C. Analiza zalet, wad i kosztów TCO:

• Zalety: Wyeliminowanie krytycznych podatności bez spowalniania diagnostyki ratującej życie; wprowadzenie standardu Data Clean Room budującego pozycję lidera badań onkologicznych w Europie; pełna zgodność z NIS2 i RODO.
• Wady i koszty TCO: Koszt zakupu licencji KMS, kluczy FIDO2 i pamięci S3 Object Lock szacowany na 450 tys. PLN w pierwszym roku; konieczność renegocjacji umów badawczych z partnerami zagranicznymi.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor ochrony zdrowia.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 9, 32, 35, 83.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (Akt o sztucznej inteligencji - AI Act).
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system.
• Norma PN-EN ISO 27799:2016 - Zarządzanie bezpieczeństwem informacji w dziedzinie zdrowia.
• Norma PN-EN ISO 22301:2020 - Bezpieczeństwo i odporność - Systemy zarządzania ciągłością działania.
• European Data Protection Board (EDPB): "Guidelines 05/2021 on the Interplay between the application of Article 3 and the provisions on international transfers".

• U1 Student opracowuje zintegrowany plan audytu ISMS dla hybrydowej infrastruktury medyczno-badawczej z AI.
• U2 Student dokumentuje uchybienia w kanonicznym modelu 4C z dogłębną analizą przyczyn źródłowych 5 Why.
• U3 Student bezbłędnie przeprowadza szacowanie ryzyka w matrycy 5x5 i ustala wskaźniki RTO/RPO dla systemów medycznych.
• U4 Student przygotowuje plan CAP ze wskaźnikami KPI oraz jednostronicowy Pitch to Board dla kierownictwa.
• W1W2W3 Student wykazuje ekspercką wiedzę w zakresie korelacji norm ISO 27001, ISO 42001, NIS2 i RODO.
• K1K2K3 Student demonstruje postawę profesjonalną, etyczną i odporność na presję w dyskusji ze środowiskiem medycznym.

• U1 Opracowanie zintegrowanego planu audytu ISMS dla krytycznego węzła powiadamiania ratunkowego.
• U2 Formułowanie ustaleń audytowych w kanonicznym modelu 4C z analizą 5 Why.
• U3 Szacowanie ryzyka paraliżu dyspozycji ratownictwa w matrycy 5x5 oraz parametry BCM (RTO=0, RPO=0, MTPD=15 min).
• U4 Opracowanie Planu CAP z KPI oraz Executive Summary dla Wojewody.
• W1W3 Znajomość ustawy o systemie powiadamiania ratunkowego, ustawy o KSC, KRI, ustawy o zarządzaniu kryzysowym oraz ustawy o ochronie ludności.
• W2 Normy ISO/IEC 27001:2022, PN-EN ISO 22301 (ciągłość działania) oraz wytyczne NATO w zakresie odporności cywilnej (Civil Resilience).
• K1K2K3 Poczucie misji publicznej, bezkompromisowość w ochronie życia obywateli i etyka zawodowa audytora.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole ciągłości działania i sieci), Wyk4 (KSC i KRI), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 4.0 jest zaprojektowanie zaawansowanego planu audytu ISMS w Wojewódzkim Centrum Powiadamiania Ratunkowego (WCPR) i Wydziale Bezpieczeństwa i Zarządzania Kryzysowego Urzędu Wojewódzkiego, zarządzającym dyspozycją numeru alarmowego 112 oraz regionalnym węzłem łączności radiowej TETRA. Zadanie koncentruje się na audycie odporności teleinformatycznej na ataki hybrydowe (skoordynowany DDoS na łącza SIP Trunk, botnety zatykające linie telefoniczne, dezinformacja), szacowaniu ryzyka w matrycy 5x5 przy rygorze bezwzględnej ciągłości (RTO=0 min dla linii alarmowych), sformułowaniu ustaleń w modelu 4C oraz przygotowaniu Planu Działań Korygujących (CAP) ze wskaźnikami KPI.

Wojewódzkie Centrum Powiadamiania Ratunkowego (WCPR) obsługuje rocznie 3,8 miliona połączeń alarmowych na numer 112, 997, 998 i 999. Centrum zatrudnia 140 operatorów numerów alarmowych pracujących w systemie 12-godzinnym na 48 stanowiskach dyspozytorskich. WCPR zintegrowane jest z Systemem Informatycznym Powiadamiania Ratunkowego (SIPR), ogólnopolską siecią łączności radiowej służb MSWiA (TETRA) oraz Wojewódzkim Centrum Zarządzania Kryzysowego (WCZK).

Złożone incydenty i uchybienia stwierdzone przed audytem:

• Podatność łączy telekomunikacyjnych i atak wolumetryczny: Połączenia przychodzące realizowane są za pośrednictwem dwóch łączy SIP Trunk od komercyjnych operatorów telekomunikacyjnych, wchodzących do budynku tym samym kanałem teletechnicznym. Trzy miesiące temu, w trakcie ćwiczeń obrony cywilnej, nieznana grupa powiązana z obcym wywiadem (APT) przeprowadziła atak DDoS na węzeł operatora połączony ze sztucznym generowaniem 12 000 połączeń telefonicznych na minutę przez botnet VoIP, co doprowadziło do czasowego zablokowania 65% linii alarmowych na 42 minuty.
• Brak redundancji zasilania w stacji bazowej TETRA: Główna stacja bazowa TETRA na dachu gmachu urzędu zasilana jest z jednego pionu energetycznego; baterie akumulatorowe UPS podtrzymują pracę stacji jedynie przez 20 minut, a agregat prądotwórczy nie posiadał automatycznego układu samoczynnego załączenia rezerwy (SZR).
• Uwierzytelnianie na stacjach dyspozytorskich: Ze względu na dużą rotację operatorów i stres operacyjny, na 12 stanowiskach hasła do podsystemu lokalizacji abonenta (PLI CBD) były zapisane w plikach tekstowych na pulpicie wspólnym stacji.
• Wojewoda zarządził natychmiastowy audyt ISMS i odporności kryzysowej z udziałem Triady Audytorskiej.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert Administracji Rządowej): Zarządza audytem, koordynuje relacje z Wojewodą i Komendantami Wojewódzkimi Policji i PSP, sporządza Executive Summary, moderuje spotkania otwierające i zamykające.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt łączy SIP Trunk, konfiguracji Session Border Controller (SBC), ochrony anty-DDoS, sieci radiowej TETRA i stacji dyspozytorskich.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla scenariusza wojny hybrydowej, analizę BCM (RTO=0, RPO=0), formułuje kartę 4C dla łączności alarmowej i konstruuje Plan CAP ze wskaźnikami KPI.

• Krok 2 (Wyznaczenie zakresu i zakazów operacyjnych):

Zakres: Sala operacyjna WCPR, serwerownia centralna, stacja bazowa TETRA, łącza SIP Trunk, węzeł WCZK.

Ograniczenia: Bezwzględny zakaz przeprowadzania testów obciążeniowych na aktywnych liniach 112; testy przełączania realizowane wyłącznie na wydzielonym stanowisku testowym w porozumieniu z operatorem telekomunikacyjnym.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Ustawa o systemie powiadamiania ratunkowego (art. 5-8), Ustawa o KSC (art. 8-15), Rozporządzenie KRI (par. 20), Norma ISO/IEC 27001:2022 (A.5.29, A.5.30 Ciągłość działania, A.8.20, A.8.21), Norma PN-EN ISO 22301:2020.

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Zablokowanie numeru 112 przez skoordynowany atak DDoS na łącza SIP Trunk. P=4, S=5 (Katastrofalny - brak możliwości wezwania pomocy przez setki poszkodowanych). Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Trzy niezależne łącza światłowodowe wprowadzone osobnymi traktami, zaawansowany scrubbing anty-DDoS na poziomie operatora nadrzędnego (NASK), filtrowanie botnetów VoIP na SBC. Ryzyko rezydualne: P=1, S=2 (2/25 - Akceptowalne).
  • Zagrożenie 2: Awaria zasilania stacji bazowej TETRA i utrata łączności ze służbami ratowniczymi. P=3, S=5. Ryzyko inherentne: 15/25 (Wysokie). Kontrole: Nowy zasilacz UPS z podtrzymaniem 4h, automatyka SZR dla agregatu. Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Wyciek danych o zgłaszających i osobach poszkodowanych z bazy PLI CBD. P=3, S=4. Ryzyko inherentne: 12/25. Kontrole: Klucze FIDO2 dla każdego dyspozytora, likwidacja haseł w plikach tekstowych. Ryzyko rezydualne: P=1, S=2 (2/25).

Parametry BCM: RTO = 0 min (natychmiastowe przełączenie ruchu na zapasowe WCPR w innym województwie), RPO = 0 min, MTPD = 15 minut.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla pojedynczego punktu awarii (SPOF) w łączach telekomunikacyjnych SIP Trunk.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Zestawienie działań: natychmiastowa rekonfiguracja Session Border Controllera (0-7 dni), wdrożenie automatyki SZR i akumulatorów (30 dni), budowa drugiego niezależnego traktu światłowodowego z monitoringiem (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległe badanie infrastruktury telekomunikacyjnej, sali operacyjnej i procedur zarządzania kryzysowego.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Wojewody (3 min): Skala zagrożenia paraliżem ratownictwa, wnioski z incydentu DDoS, koszty wdrożenia redundancji (Lead Auditor).
• Matryca ryzyka 5x5 i parametry ciągłości działania RTO=0 / RPO=0 (4 min): Uzasadnienie bezwzględnej redundancji łączy i zasilania (BCM Auditor).
• Dekonstrukcja podatności technicznych (SIP Trunk, TETRA, SBC) (4 min): Przedstawienie wyników inspekcji fizycznej traktów kablowych i konfiguracji sieci (Technical SecOps Auditor).
• Karta 4C i Plan CAP z metrykami KPI (3 min): Prezentacja analizy 5 Why i harmonogramu budowy niezależnych traktów (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania Wojewody o odporność systemu na atak hybrydowy (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Wojewody (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: System powiadamiania ratunkowego 112 w województwie posiada krytyczny pojedynczy punkt awarii (Single Point of Failure) w warstwie telekomunikacyjnej i zasilania stacji TETRA. Ryzyko paraliżu dyspozycji karetek i straży wynosi 20/25. Rekomendacja: Wdrożenie niezależnego traktu światłowodowego od operatora państwowego oraz automatyki SZR w trybie pilnym (inwestycja: 380 tys. PLN).

B. Zaawansowany Plan Audytu ISMS w WCPR:

• Zleceniodawca: Wojewoda. Zakres: Sala operacyjna WCPR, WCZK, stacja bazowa TETRA, serwerownia SIPR, łącza telekomunikacyjne.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (DDoS na SIP Trunk): IR = 4 x 5 = 20/25. Kontrole: Redundantny trakt światłowodowy, anty-DDoS NASK, filtrowanie VoIP. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Awaria zasilania TETRA): IR = 3 x 5 = 15/25. Kontrole: UPS 4h, automatyka SZR. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Pliki z hasłami do PLI CBD): IR = 3 x 4 = 12/25. Kontrole: Klucze FIDO2, skrypty blokujące zapisywanie haseł. RR = 1 x 2 = 2/25.
  • Parametry BCM: RTO = 0 min (przełączenie geo-redundantne do sąsiedniego WCPR), RPO = 0 min, MTPD = 15 min.
• Karta Ustalenia w modelu 4C dla Podatności Łączności SIP Trunk:
  • Condition (Stan faktyczny): Obaj operatorzy dostarczają łącza SIP Trunk tym samym fizycznym kanałem teletechnicznym, a urządzenia Session Border Controller nie posiadają aktywnych reguł ochrony przed atakami typu SIP Flood/Invite Flood.
  • Criteria (Kryteria): Ustawa o systemie powiadamiania ratunkowego art. 5; ISO 27001 A.8.20, A.8.21; ISO 22301 klauzula 8.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego łącza wprowadzono jednym kanałem? -> Bo urząd ogłosił przetarg na dwóch operatorów, nie określając wymogu separacji fizycznej tras kablowych.

Dlaczego nie określono wymogu? -> Bo specyfikacja przetargowa była tworzona bez udziału architekta ds. ciągłości działania.

Dlaczego brakowało architekta? -> W strukturze urzędu zadania BCM traktowano czysto formalnie.

Przyczyna źródłowa (Root Cause): Brak zintegrowanej strategii zarządzania ciągłością działania (BCM) na etapie zamówień publicznych w obszarze infrastruktury krytycznej.

• Consequence (Skutki): Ryzyko całkowitego paraliżu przyjmowania zgłoszeń wypadków i katastrof; bezpośrednie zagrożenie życia i zdrowia obywateli; odpowiedzialność konstytucyjna i karna kierownictwa urzędu.

C. Analiza zalet, wad i kosztów:

• Zalety: Wyeliminowanie pojedynczego punktu awarii w ratownictwie; pełna odporność na ataki hybrydowe; zgodność z wytycznymi NATO w zakresie odporności cywilnej.
• Wady: Konieczność uzyskania zgód budowlanych na nowy przewiert teletechniczny; koszt 380 tys. PLN.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Ustawa z dnia 22 listopada 2013 r. o systemie powiadamiania ratunkowego (Dz.U. z 2023 r. poz. 748).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (Dz.U. z 2023 r. poz. 122).
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO 22301:2020 - Bezpieczeństwo i odporność - Systemy zarządzania ciągłością działania.
• Rządowe Centrum Bezpieczeństwa (RCB): "Narodowy Program Ochrony Infrastruktury Krytycznej", Warszawa.
• NATO Civil Emergency Planning Committee (CEPC): "Baseline Requirements for National Resilience", Bruksela.

• U1 Student umie opracować zaawansowany plan audytu ISMS dla infrastruktury powiadamiania ratunkowego.
• U2 Student bezbłędnie stosuje model 4C do formułowania uchybień w ciągłości działania.
• U3 Student wykonuje kwantyfikację ryzyka w matrycy 5x5 i wyznacza parametry RTO=0 i RPO=0.
• U4 Student przygotowuje Plan CAP z KPI oraz zwięzłe Executive Summary dla najwyższych władz administracji.
• W1W2W3 Student rozumie zbieżność przepisów o powiadamianiu ratunkowym, KSC i norm ISO 27001 / ISO 22301.
• K1K2K3 Student demonstruje odpowiedzialność za bezpieczeństwo obywateli i wysokie standardy etyczne.

• U1 Opracowanie zintegrowanego planu audytu ISMS dla obiektu nuklearnego i badań zbrojeniowych Dual-Use.
• U2 Formułowanie ustaleń w modelu 4C z analizą przyczyn źródłowych Root Cause (5 Why).
• U3 Przeprowadzenie analizy ryzyka sabotażu teleinformatycznego reaktora jądrowego i kradzieży technologii Dual-Use w matrycy 5x5.
• U4 Opracowanie Planu Działań Korygujących (CAP) ze wskaźnikami KPI i Executive Summary.
• W1 Ochrona informacji niejawnych o klauzulach krajowych i międzynarodowych (NATO/UE SECRET) oraz tajemnicy atomowej.
• W2W3 Zbieżność norm ISO 27001:2022, wytycznych IAEA NSS 17 (bezpieczeństwo komputerowe w obiektach jądrowych), Prawa atomowego i WSK.
• K1K2K3 Najwyższy reżim dyskrecji, postawa kontrwywiadowcza, odporność na inwigilację i obrona planu audytu.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole fizyczne i kryptograficzne), Wyk4 (Informacje niejawne i KSC), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego, elitarnego planu audytu ISMS w instytucie atomowym i centrum technologii jądrowych eksploatującym reaktor badawczy oraz prowadzącym prace nad kryptografią postkwantową i materiałami podwójnego zastosowania (Dual-Use). Zadanie integruje normę ISO/IEC 27001:2022 z wymogami Ustawy o ochronie informacji niejawnych (klauzule ŚCIŚLE TAJNE, NATO SECRET), normami ochrony elektromagnetycznej TEMPEST, rygorami Państwowej Agencji Atomistyki (PAA) oraz Międzynarodowej Agencji Energii Atomowej (MAEA/IAEA). Zadanie wymaga zastosowania metodyki Triady Audytorskiej, sformułowania ustaleń w modelu 4C, analizy ryzyka 5x5 oraz przygotowania Planu CAP ze wskaźnikami KPI i Executive Summary dla Dyrektora Instytutu i ABW.

Narodowe Centrum Badań Jądrowych (NCBJ) zarządza jedynym w Polsce działającym jądrowym reaktorem badawczym "Maria" o mocy 30 MW oraz laboratoriami fizyki plazmy, produkcji radiofarmaceutyków i zespołem badawczym nad odpornymi na komputery kwantowe algorytmami kryptograficznymi dla Sił Zbrojnych RP. Instytut podlega stałemu nadzorowi Departamentu Bezpieczeństwa Teleinformatycznego ABW oraz Dozoru Jądrowego PAA.

Infrastruktura techniczna i obieg informacji klauzulowanych:

• System Sterowania i Ochrony Reaktora (SSiOR): Działa w oparciu o sterowniki przemysłowe w dedykowanej, całkowicie odizolowanej sieci (Air-Gap) bez jakichkolwiek fizycznych połączeń z siecią zewnętrzną.
• Kancelaria Tajna Międzynarodowa: Przetwarzanie dokumentacji technicznej i projektów dla NATO w certyfikowanych strefach bezpieczeństwa klasy I z ekranowaniem elektromagnetycznym TEMPEST (poziom A).
• Ośrodek Obliczeniowy Świerk (CIŚ): Superkomputer przetwarzający wielkie zbiory danych fizyki wysokich energii połączony z europejską siecią GRID.

Złożone incydenty i uchybienia ujawnione w audycie zerowym:

• Naruszenie reżimu strefy Air-Gap: Wykryto, że jeden z inżynierów pomiarowych reaktora podłączył do stacji diagnostycznej SSiOR prywatny czytnik e-booków w celu naładowania baterii, co w przeszłości stanowiło wektor infekcji w incydentach klasy Stuxnet.
• Podatności w laboratorium kryptografii postkwantowej: Kody źródłowe algorytmów Dual-Use były testowane na stacjach podłączonych do sieci akademickiej instytutu, a logi połączeń wykazały podejrzany transfer 4 GB danych na serwer w Azji Wschodniej (atak zaawansowanej grupy APT).
• Kontrola dostępu fizycznego do budynku reaktora: Czytniki biometryczne na śluzie wejściowej do hali reaktora były okresowo przełączane w tryb awaryjny (dostęp wyłącznie na kartę RFID bez weryfikacji biometrii żył dłoni) z powodu zacinania się rygli mechanicznych.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Pełnomocnik ds. Ochrony Informacji Niejawnych): Koordynuje audyt, współpracuje z Dyrektorem Instytutu, Oficerem Bezpieczeństwa PAA i delegaturą ABW, przygotowuje Executive Summary.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt systemów sterowania reaktora, pomiarów emisji TEMPEST, izolacji sieci Air-Gap, analizy złośliwego oprogramowania i ataków APT na superkomputer.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla scenariusza awarii reaktora i kradzieży technologii Dual-Use, formułuje kartę 4C dla strefy reaktora i konstruuje Plan CAP ze wskaźnikami KPI.

• Krok 2 (Wyznaczenie zakresu i bezwzględnych ograniczeń bezpieczeństwa jądrowego):

Zakres: Budynek reaktora, system SSiOR, laboratoria kryptografii, Kancelaria Tajna, superkomputer CIŚ.

Ograniczenia: Bezwzględny zakaz jakiejkolwiek ingerencji fizycznej lub programowej w obwody bezpieczeństwa reaktora; weryfikacja wyłącznie w asyście Dyrektora Reaktora; audytorzy posiadają poświadczenia bezpieczeństwa do klauzuli ŚCIŚLE TAJNE.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Ustawa o ochronie informacji niejawnych (art. 43-53), Prawo atomowe (art. 36-39), Standardy IAEA NSS 17, Norma ISO/IEC 27001:2022 (A.5.15, A.7.1-A.7.4, A.8.1, A.8.20), Norma PN-EN ISO 22301.

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Wprowadzenie złośliwego oprogramowania do systemu SSiOR reaktora przez port USB stacji diagnostycznej. P=2, S=5 (Katastrofalny - potencjalne rozszczelnienie rdzenia i skażenie promieniotwórcze). Ryzyko inherentne: 10/25 (Wysokie). Kontrole: Fizyczne zaślepki mechaniczne portów USB z zamkiem kluczowym, programowe blokady jądra systemu, zakaz wnoszenia elektroniki do strefy I. Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 2: Kradzież kodów algorytmów postkwantowych przez grupę APT. P=4, S=5. Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Przeniesienie prac do strefy TEMPEST A, sieć Air-Gap, szyfrowanie HSM. Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Nieuprawnione wejście do hali reaktora wskutek awarii czytników biometrycznych. P=3, S=5. Ryzyko inherentne: 15/25. Kontrole: Wymiana rygli na magnetyczne fail-secure, podwójny posterunek uzbrojonej Straży Ochrony Reaktora. Ryzyko rezydualne: P=1, S=2 (2/25).

Parametry BCM: RTO = 0 min dla systemów bezpieczeństwa reaktora, RPO = 0 min, MTPD = 0 min.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla podłączenia czytnika e-booków do sieci sterowania reaktora.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Natychmiastowa inspekcja antymalware stacji SSiOR (0-7 dni), montaż blokad mechanicznych USB i wymiana rygli biometrycznych (30 dni), budowa certyfikowanego laboratorium Dual-Use w standardzie TEMPEST (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Rozpisanie inspekcji reaktora, stref TEMPEST, superkomputera i Kancelarii Tajnej.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Dyrekcji NCBJ i ABW (3 min): Zagrożenia sabotażem reaktora, wektory szpiegostwa APT w projektach Dual-Use, plan finansowy CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=0 / RPO=0) (4 min): Prezentacja szacowania ryzyka nuklearnego i kradzieży technologii wojskowych (BCM Auditor).
• Dekonstrukcja wektorów technicznych (Air-Gap, USB, TEMPEST, APT) (4 min): Przedstawienie dowodów naruszenia izolacji reaktora (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Analiza 5 Why i harmonogram naprawczy dla dozoru jądrowego (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania Dyrektora Reaktora dotyczące rygorów dyscyplinarnych dla inżynierów (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Dyrekcji NCBJ i ABW (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W reżimie ochrony reaktora jądrowego i projektów kryptograficznych Dual-Use ujawniono krytyczne luki: naruszenie strefy Air-Gap przez urządzenia prywatne oraz eksfiltrację danych do Azji. Zagrożenie sabotażem i szpiegostwem oszacowano na 20/25. Rekomendacja: Natychmiastowa blokada portów USB, przeniesienie badań Dual-Use do strefy TEMPEST A oraz modernizacja śluz biometrycznych (budżet CAP: 620 tys. PLN).

B. Zaawansowany Plan Audytu ISMS w NCBJ:

• Zleceniodawca: Dyrektor Naczelny NCBJ w porozumieniu z ABW i PAA. Zakres: Reaktor "Maria", SSiOR, laboratoria Dual-Use, Kancelaria Tajna, superkomputer CIŚ.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Sabotaż USB w reaktorze): IR = 2 x 5 = 10/25. Kontrole: Blokady fizyczne portów, monitoring kamerami HD, zakaz elektroniki. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Szpiegostwo APT w kryptografii): IR = 4 x 5 = 20/25. Kontrole: Laboratorium TEMPEST A, sieć Air-Gap, HSM. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Awaria biometrii w śluzie): IR = 3 x 5 = 15/25. Kontrole: Rygle magnetyczne, weryfikacja PalmSecure, posterunek uzbrojony. RR = 1 x 2 = 2/25.
  • Wskaźniki BCM: RTO = 0 min, RPO = 0 min, MTPD = 0 min dla reaktora.
• Karta Ustalenia w modelu 4C dla Naruszenia Strefy Air-Gap:
  • Condition (Stan faktyczny): Inżynier pomiarowy podłączył czytnik e-booków do portu USB stacji diagnostycznej systemu SSiOR reaktora w celu ładowania baterii; system operacyjny stacji dokonał automatycznego zamontowania nośnika pamięci masowej.
  • Criteria (Kryteria): Prawo atomowe art. 36; Standard IAEA NSS 17 sekcja 4.3; ISO/IEC 27001:2022 A.7.4, A.8.1; Ustawa o ochronie informacji niejawnych art. 47.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego inżynier podłączył czytnik? -> Bo rozładowała mu się bateria podczas nocnego dyżuru.

Dlaczego do stacji SSiOR? -> Bo w hali sterowni nie było dostępnych gniazd USB ładowania.

Dlaczego port USB stacji był aktywny? -> Bo administrator IT nie zablokował kontrolera USB w BIOS i rejestrze systemu.

Dlaczego nie zablokował? -> Brak procedury Hardeningu (utwardzania) stacji roboczych w strefie jądrowej.

Przyczyna źródłowa (Root Cause): Brak sformalizowanej procedury utwardzania systemów SCADA/SSiOR w strefie jądrowej oraz brak punktów kontroli wnoszenia elektroniki do strefy I ochrony obiektu.

• Consequence (Skutki): Ryzyko infekcji złośliwym oprogramowaniem sabotującym pręty kontrolne reaktora (scenariusz Stuxnet); ryzyko skażenia radiologicznego i ewakuacji aglomeracji warszawskiej; utrata koncesji PAA.

C. Analiza zalet, wad i kosztów:

• Zalety: Wykluczenie ryzyka sabotażu nuklearnego; spełnienie standardów IAEA i NATO; bezwzględna ochrona strategicznego know-how RP przed obcym wywiadem.
• Wady: Bardzo wysoki koszt budowy stref TEMPEST i śluz (620 tys. PLN); rygoryzm procedur utrudniający codzienną pracę naukowców.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Ustawa z dnia 29 listopada 2000 r. - Prawo atomowe (Dz.U. z 2024 r. poz. 1277).
• Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. z 2024 r. poz. 632).
• Międzynarodowa Agencja Energii Atomowej (IAEA): "Computer Security at Nuclear Facilities", IAEA Nuclear Security Series No. 17, Wiedeń.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Agencja Bezpieczeństwa Wewnętrznego (ABW): "Zalecenia dotyczące bezpieczeństwa teleinformatycznego dla podmiotów wykonujących zadania na rzecz obronności państwa", Warszawa.
• Norma SDIP-27 Level A - NATO TEMPEST Requirements and Evaluation Procedures.

• U1 Student projektuje zaawansowany plan audytu ISMS dla obiektu jądrowego i technologii wojskowych Dual-Use.
• U2 Student stosuje kanoniczny model 4C do dokumentowania incydentów w strefach Air-Gap.
• U3 Student wykonuje analizę ryzyka sabotażu i skażenia w 25-stopniowej matrycy 5x5 z parametrami RTO=0.
• U4 Student przygotowuje Plan CAP z KPI oraz Executive Summary dla organów bezpieczeństwa państwa.
• W1W2W3 Student wykazuje ekspercką wiedzę o Prawie atomowym, ochronie informacji niejawnych i normach IAEA/NATO.
• K1K2K3 Student demonstruje postawę najwyższej odpowiedzialności za bezpieczeństwo państwa i obywateli.

• U1 Opracowanie zintegrowanego planu audytu ISMS dla OSP elektroenergetycznego w warunkach zagrożeń hybrydowych.
• U2 Dokumentowanie uchybień w kanonicznym modelu 4C z analizą przyczyn źródłowych Root Cause (5 Why).
• U3 Szacowanie ryzyka blackoutu krajowego w matrycy 5x5 oraz parametry BCM (RTO=0, RPO=0, MTPD=1h).
• U4 Opracowanie Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz Executive Summary dla Zarządu.
• W1W3 Wymogi Dyrektywy NIS2 dla podmiotów kluczowych, Ustawy o KSC, Ustawy o zarządzaniu kryzysowym oraz Rozporządzenia MAR (spółka notowana na rynku energii).
• W2 Normy ISO/IEC 27001:2022, ISO/IEC 27019:2020 (bezpieczeństwo w energetyce), seria PN-EN IEC 62443 oraz PN-EN ISO 22301.
• K1K2K3 Poczucie odpowiedzialności za bezpieczeństwo energetyczne kraju, kultura BHP na stacjach 400 kV i etyka audytorska.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole sieciowe i SCADA), Wyk4 (NIS2 i KSC), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego planu audytu ISMS i cyberodporności w spółce pełniącej funkcję Operatora Systemu Przesyłowego (OSP) elektroenergetycznego najwyższych napięć (400 kV i 220 kV), stanowiącej kluczowy filar infrastruktury krytycznej państwa. Zadanie kładzie szczególny nacisk na wielowarstwowy audyt Krajowej Dyspozycji Mocy (KDM) oraz Obszarowych Dyspozycji Mocy (ODM) w oparciu o model referencyjny Purdue (poziomy 0-4), badanie odporności na zaawansowane ataki państwowych grup APT celujących w protokoły przemysłowe (Industroyer2, BlackEnergy w protokołach IEC 60870-5-104 i IEC 61850), szacowanie ryzyka blackoutu krajowego w matrycy 5x5 (RTO=0 min, RPO=0 min), udokumentowanie ustaleń w modelu 4C oraz przygotowanie Planu CAP ze wskaźnikami KPI i Executive Summary dla Zarządu OSP i RCB.

Polskie Sieci Elektroenergetyczne S.A. (PSE) zarządzają ponad 16 000 km linii najwyższych napięć (400 kV i 220 kV) oraz 110 stacjami węzłowymi przesyłowymi, bilansując popyt i podaż energii elektrycznej w skali całego państwa oraz nadzorując połączenia transgraniczne z Niemcami, Szwecją, Litwą, Czechami i Słowacją.

Architektura dyspozytorska i automatyka stacyjna:

• System EMS/SCADA (Energy Management System): Centralny klaster w Krajowej Dyspozycji Mocy (KDM) z redundantnym, gorącym centrum zapasowym (ZDM) oddalonym o 150 km, zasilany z niezależnych torów energetycznych i akumulatorowni z agregatami prądotwórczymi.
• Automatyka stacyjna i szyna procesowa: Nowoczesne stacje cyfrowe oparte na magistrali procesowej IEC 61850 (komunikacja GOOSE i Sampled Values) oraz sterowniki RTU komunikujące się z KDM protokołem IEC 60870-5-104 przez dedykowany trakt światłowodowy OPGW (światłowód w przewodzie odgromowym).

Złożone incydenty i uchybienia ujawnione przed audytem:

• Naruszenie separacji stref w stacji cyfrowej 400 kV: Wykryto, że nowo wdrożony system monitoringu kamer termowizyjnych transformatorów blokowych został wpięty do tej samej szyny procesowej IEC 61850 co zabezpieczenia różnicowe szyn, a rejestrator kamer posiadał domyślne poświadczenia administratorskie i interfejs chmurowy producenta z Chin.
• Podatność protokołu telemetrycznego IEC 104 na stacjach starszego typu: Komunikacja pomiędzy 14 stacjami węzłowymi 220 kV a KDM nie posiadała implementacji warstwy kryptograficznej IEC 62351-3 (brak certyfikatów TLS i uwierzytelniania HMAC), co stwarza bezpośrednie ryzyko ataku Man-in-the-Middle i fałszowania telemetrii napięciowej.
• Zarządzanie dostępem uprzywilejowanym inżynierów zabezpieczeń: Trzech inżynierów zewnętrznego integratora automatyki posiadało nielimitowany dostęp zdalny do terminali operatorskich SCADA za pośrednictwem modemu LTE zainstalowanego na stacji bez wiedzy administratorów KDM (tzw. Shadow IT / ukryty backdoor serwisowy).

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert OSP): Zarządza audytem, koordynuje relacje z Prezesem PSE, Głównym Dyspozytorem KDM, CSIRT NASK/GOV i RCB, przygotowuje Executive Summary.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt szyny stacyjnej IEC 61850, protokołu IEC 104, diod danych, konfiguracji zapór przemysłowych i systemów detekcji NDR (Nozomi/Claroty).

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla scenariusza kaskadowego blackoutu, analizę BCM (RTO=0 min, RPO=0 min), formułuje kartę 4C dla backdoora LTE i konstruuje Plan CAP ze wskaźnikami KPI.

• Krok 2 (Wyznaczenie zakresu i bezwzględnych ograniczeń bezpieczeństwa):

Zakres: KDM, Zapasowa Dyspozycja Mocy (ZDM), węzły sieci OPGW, 2 reprezentatywne stacje przesyłowe 400 kV.

Ograniczenia: Bezwzględny zakaz aktywnego skanowania i wysyłania komend na szynę stacyjną pod napięciem; inspekcja wyłącznie pasywna (Tap / port lustrzany na przełącznikach Ruggedcom).

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Dyrektywa NIS2 (podmiot kluczowy sektora energii), Ustawa o KSC (art. 8-15), Norma ISO/IEC 27001:2022, ISO/IEC 27019:2020, Standardy PN-EN IEC 62443 (części 2-4, 3-3), Standard IEC 62351, Ustawa - Prawo energetyczne.

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Skoordynowany atak złośliwego oprogramowania klasy Industroyer2 fałszującego ramki IEC 104/IEC 61850 skutkujący rozłączeniem stacji 400 kV i kaskadowym blackoutem kraju. P=3, S=5 (Katastrofalny - paraliż państwa, szpitali, transportu, straty miliardowe). Ryzyko inherentne: 15/25 (Wysokie). Kontrole: Pełna enkapsulacja TLS wg IEC 62351, diody danych jednokierunkowych, monitoring anomalii NDR. Ryzyko rezydualne: P=1, S=2 (2/25 - Akceptowalne).
  • Zagrożenie 2: Przejęcie stacji cyfrowej przez nieautoryzowany modem LTE (backdoor serwisowy). P=4, S=5. Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Natychmiastowy demontaż modemu, systemy Network Access Control (NAC 802.1X) na wszystkich portach szaf telemetrii, wdrożenie bramy PAM z MFA. Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Kompromitacja kamer termowizyjnych na szynie procesowej IEC 61850. P=4, S=4. Ryzyko inherentne: 16/25. Kontrole: Całkowite odseparowanie kamer do dedykowanego VLAN-u w strefie IT z zakazem dostępu do szyny procesowej. Ryzyko rezydualne: 1/25.

Parametry BCM: RTO = 0 min (przełączenie hot-standby pomiędzy KDM a ZDM), RPO = 0 min, MTPD = 1h dla sterowania siecią przesyłową.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla nieautoryzowanego modemu LTE i kamer termowizyjnych na szynie procesowej.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Natychmiastowy demontaż modemu LTE i audyt radiowy wszystkich stacji (0-7 dni), separacja kamer termowizyjnych i wdrożenie NAC (30 dni), modernizacja protokołu IEC 104 o szyfrowanie IEC 62351 i wdrożenie systemu NDR (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległe badanie KDM, ZDM, stacji 400 kV i sieci OPGW.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Zarządu PSE i RCB (3 min): Ryzyko blackoutu krajowego, dekonstrukcja backdoora LTE, koszty modernizacji bezpieczeństwa telemetrii (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=0 / RPO=0) (4 min): Prezentacja szacowania ryzyka kaskadowego rozłączenia systemu przesyłowego (BCM Auditor).
• Dekonstrukcja wektorów technicznych (IEC 61850, IEC 104, Industroyer2, Purdue) (4 min): Przedstawienie dowodów wpięcia kamer do szyny stacyjnej (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Prezentacja analizy 5 Why i planu wdrożenia standardu IEC 62351 (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania Prezesa o ryzyka zakłóceń dostaw energii podczas wdrożenia zaleceń (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Zarządu PSE i RCB (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W infrastrukturze teleinformatycznej stacji przesyłowych wykryto krytyczne uchybienia stwarzające bezpośrednie ryzyko wrogiej ingerencji grup APT i wywołania blackoutu (poziom ryzyka 20/25). Zidentyfikowano nieautoryzowany modem LTE na stacji węzłowej oraz wpięcie niesprawdzonego sprzętu CCTV do szyny procesowej IEC 61850. Rekomendacja: Natychmiastowy demontaż backdoora, separacja stref wg modelu Purdue oraz wdrożenie szyfrowania IEC 62351 (inwestycja CAP: 1,4 mln PLN).

B. Zaawansowany Plan Audytu ISMS w PSE S.A.:

• Zleceniodawca: Zarząd PSE S.A. Zakres: KDM, ZDM, stacje przesyłowe "Ołtarzew" i "Kozienice", sieć OPGW, systemy EMS/SCADA.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Atak Industroyer2 na IEC 104/61850): IR = 3 x 5 = 15/25. Kontrole: IEC 62351, NDR, diody danych. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Backdoor LTE na stacji): IR = 4 x 5 = 20/25. Kontrole: Demontaż modemu, NAC 802.1X, PAM MFA. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Kamery na szynie IEC 61850): IR = 4 x 4 = 16/25. Kontrole: Wydzielenie do VLAN IT, blokada ruchu do szyny procesowej. RR = 1 x 1 = 1/25.
  • Parametry BCM: RTO = 0 min, RPO = 0 min, MTPD = 1h dla nadzoru KDM.
• Karta Ustalenia w modelu 4C dla Backdoora LTE na Stacji Przesyłowej:
  • Condition (Stan faktyczny): Na stacji węzłowej 400 kV zewnętrzny integrator zainstalował komercyjny modem komórkowy LTE w szafie telemetrii, zapewniający nienadzorowany dostęp zdalny z pominięciem zapór sieciowych KDM i bez rejestracji sesji.
  • Criteria (Kryteria): Dyrektywa NIS2 art. 21 ust. 2 lit. d; Ustawa o KSC art. 8; Norma ISO/IEC 27019:2020 pkt 8.20; Standard PN-EN IEC 62443-3-3 wymaganie SR 1.1 i SR 1.13.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego zainstalowano modem LTE? -> Aby inżynierowie integratora mogli szybko wgrywać poprawki konfiguracji bez dojazdu na stację.

Dlaczego bez zgody KDM? -> Bo oficjalna procedura wnioskowania o dostęp VPN trwała zbyt długo.

Dlaczego trwała długo? -> Brak sformalizowanego procesu szybkiego dostępu awaryjnego (Emergency Access / Break-Glass).

Dlaczego brakowało procesu? -> Niedostosowanie procedur korporacyjnych IT do realiów utrzymania stacji elektroenergetycznych.

Przyczyna źródłowa (Root Cause): Brak zintegrowanej architektury bezpiecznego dostępu serwisowego (Secure Remote Access) w środowisku OT i brak inspekcji fizycznej szaf telemetrii.

• Consequence (Skutki): Ryzyko przejęcia stacji przez obce służby specjalne; możliwość celowego rozłączenia wyłączników mocy 400 kV i wywołania rozpadu Krajowego Systemu Elektroenergetycznego; wielomiliardowe straty gospodarki narodowej.

C. Analiza zalet, wad i kosztów:

• Zalety: Wykluczenie ryzyka wrogiego przejęcia stacji przesyłowych; pełna zgodność z Dyrektywą NIS2 i normą ISO 27019; podniesienie odporności państwa na wojnę hybrydową.
• Wady: Koszt 1,4 mln PLN na systemy NDR i modernizację urządzeń IED; konieczność drobiazgowych uzgodnień okien prac na stacjach 400 kV.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor energetyki jako podmiot kluczowy.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Norma PN-EN ISO/IEC 27019:2020 - Bezpieczeństwo informacji w systemach sterowania procesami w branży energetycznej.
• Norma PN-EN IEC 62443 (seria norm) - Bezpieczeństwo przemysłowych systemów automatyki i sterowania.
• Standard PN-EN IEC 62351 - Zarządzanie systemami zasilania i powiązana wymiana informacji - Bezpieczeństwo danych i komunikacji.
• Norma PN-EN ISO 22301:2020 - Systemy zarządzania ciągłością działania.
• CISA / CSIRT NASK: "Analiza zagrożeń APT ukierunkowanych na europejski sektor elektroenergetyczny", Warszawa.

• U1 Student umie zaplanować wielowarstwowy audyt ISMS i cyberodporności dla Operatora Systemu Przesyłowego.
• U2 Student stosuje model 4C do formułowania uchybień w telemetrii i automatyce stacyjnej.
• U3 Student wykonuje analizę ryzyka blackoutu w 25-stopniowej matrycy 5x5 i wyznacza wskaźniki BCM RTO=0.
• U4 Student buduje plan CAP ze wskaźnikami KPI oraz Executive Summary dla Zarządu OSP i RCB.
• W1W2W3 Student wykazuje dogłębną znajomość norm ISO 27019, IEC 62443, NIS2 i KSC.
• K1K2K3 Student demonstruje postawę najwyższej odpowiedzialności za stabilność systemu energetycznego kraju.

• U1 Opracowanie zaawansowanego planu audytu ISMS w wielochmurowym środowisku płatniczym o wysokiej przepustowości.
• U2 Dokumentowanie uchybień w modelu 4C z analizą 5 Why dla transakcji kartowych i interfejsów API.
• U3 Przeprowadzenie analizy ryzyka w matrycy 5x5 (IR vs RR) oraz określenie parametrów BCM (RTO=15 min, RPO=0 min).
• U4 Opracowanie Planu Działań Korygujących (CAP) z KPI oraz jednostronicowego Executive Summary.
• W1 Ochrona tajemnicy bankowej, tajemnicy zawodowej instytucji płatniczych i danych kartowych (PAN/CVV).
• W2W3 Rozporządzenie DORA, Standard PCI DSS v4.0, Norma ISO/IEC 27001:2022, ISO/IEC 27017/27018, Wytyczne KNF i EBA.
• K1K2K3 Obiektywizm audytorski, odporność na presję korporacyjną i etyka w badaniu wrażliwych operacji finansowych.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole kryptograficzne i chmurowe), Wyk4 (DORA i PCI DSS), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego planu audytu ISMS opartego na ryzyku (risk-based audit) w międzynarodowej instytucji płatniczej i operatorze portfeli cyfrowych przetwarzającym 1 500 transakcji na sekundę (TPS) w architekturze wielochmurowej (AWS, Azure, GCP). Zadanie wymaga zastosowania rygorów unijnego Rozporządzenia DORA (zarządzanie ryzykiem ICT, testy odpornościowe TLPT, nadzór nad dostawcami chmurowymi), najnowszego standardu bezpieczeństwa danych kart płatniczych PCI DSS v4.0, triangulacji dowodów ze źródeł SIEM/SOC, szacowania ryzyka w matrycy 5x5, sformułowania ustaleń w modelu 4C oraz przygotowania Planu CAP ze wskaźnikami KPI i Executive Summary dla Zarządu i Europejskiego Urzędu Nadzoru Bankowego (EBA).

Spółka "GlobalPay Solutions S.A." z licencją Krajowej Instytucji Płatniczej i paszportem europejskim świadczy usługi bramki płatniczej, portfela cyfrowego oraz procesowania kart dla 15 000 e-sklepów i 12 milionów użytkowników w całej Unii Europejskiej. Średni wolumen wynosi 1 500 transakcji na sekundę o dziennej wartości przekraczającej 120 mln EUR.

Architektura wielochmurowa i infrastruktura kryptograficzna:

• Środowisko wielochmurowe (Multi-Cloud): Silnik transakcyjny działa w klastrach Kubernetes w AWS (Region Irlandia), analityka anty-fraudowa i bazy historyczne osadzone są w Google Cloud Platform (Region Warszawa), a systemy zarządzania tożsamością i portfelem działają w Microsoft Azure.
• Kryptografia: Sprzętowe moduły HSM (Hardware Security Module) dedykowane do bezpiecznego przechowywania kluczy głównych (Zone Master Keys) i przetwarzania kodów PIN oraz danych PAN.

Złożone incydenty i uchybienia ujawnione w audycie zerowym:

• Podatność w łańcuchu testów TLPT (DORA art. 26): Bank zrealizował testy penetracyjne oparte na profilu zagrożeń (TLPT), lecz wyłączył z zakresu testów środowisko produkcyjne klastrów AWS, testując jedynie środowisko stagingowe, co uniemożliwia spełnienie rygorów TIBER-EU i standardu DORA.
• Naruszenie wymogu 6.4.3 standardu PCI DSS v4.0: Na stronach płatniczych (bramka checkout) skrypty JavaScript ładowane są z zewnętrznych sieci CDN bez wdrożenia mechanizmów Subresource Integrity (SRI) i bez monitorowania integralności skryptów w przeglądarce klienta, co stwarza bezpośrednie ryzyko ataku typu Web Skimming / Magecart i kradzieży danych kartowych.
• Zarządzanie kluczami kryptograficznymi w chmurze hybrydowej: Wykryto, że klucze szyfrujące bazy danych analitycznych w GCP były generowane i zarządzane przez klucze domyślne dostawcy chmury (Google-managed keys), zamiast kluczy zarządzanych przez klienta (Customer-Managed Encryption Keys - CMEK) powiązanych ze sprzętowym modułem HSM.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert FinTech i DORA): Koordynuje audyt, współpracuje z Zarządem, CISO, KNF i EBA, przygotowuje Executive Summary, prowadzi spotkania otwierające i zamykające.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt klastrów Kubernetes w AWS/Azure/GCP, mechanizmów anty-skimmingu (PCI DSS 6.4.3), modułów HSM, szyfrowania CMEK i integracji SIEM/SOC.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5, analizę odporności operacyjnej wg DORA (RTO=15 min, RPO=0 min), formułuje kartę 4C dla ataku Magecart i konstruuje Plan CAP z KPI.

• Krok 2 (Wyznaczenie zakresu i wielochmurowych granic audytu):

Zakres: Środowiska AWS, GCP, Azure, moduły HSM, bramki API, strony płatnicze checkout, centrum SOC.

Metodyka próbkowania: Zastosowanie reprezentatywnego samplingu statystycznego transakcji (n=300, poziom ufności 99%, margines błędu 3%) w celu weryfikacji braku zapisu kodów CVV2 w bazach i logach.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Rozporządzenie DORA (art. 5-16, 26-27), Standard PCI DSS v4.0 (wymogi 3, 6.4.3, 10, 12), Norma ISO/IEC 27001:2022, ISO/IEC 27017, Wytyczne EBA w sprawie zarządzania ryzykiem ICT.

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Wyciek danych kartowych przez atak Web Skimming (podmiana JS na stronie checkout bez SRI). P=4, S=5 (Katastrofalny - masowa kradzież kart, utrata licencji Visa/Mastercard, kary PCI SSC do 500 tys. USD/miesiąc). Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Wdrożenie SRI, nagłówków CSP (Content Security Policy) oraz skanerów integralności skryptów po stronie klienta (Client-Side Protection). Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 2: Zakwestionowanie testów TLPT przez organ nadzoru (KNF/EBA) z powodu pominięcia środowiska produkcyjnego. P=4, S=4. Ryzyko inherentne: 16/25 (Wysokie). Kontrole: Przeprowadzenie pełnego testu Red Team na środowisku produkcyjnym w oknie serwisowym wg ram TIBER-PL. Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Brak kontroli nad kluczami w GCP (brak CMEK). P=3, S=4. Ryzyko inherentne: 12/25. Kontrole: Migracja do Cloud KMS z kluczami generowanymi w sprzętowym HSM Instytucji (BYOK). Ryzyko rezydualne: 1/25.

Parametry BCM: RTO = 15 min, RPO = 0 min, MTPD = 2h dla procesowania transakcji.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla braku ochrony skryptów płatniczych wg wymogu 6.4.3 PCI DSS v4.0.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Natychmiastowe wdrożenie nagłówków CSP i SRI (0-7 dni), wdrożenie CMEK w GCP i rozszerzenie testów TLPT na produkcję (30 dni), certyfikacja PCI DSS v4.0 przez audytora QSA (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległe badanie chmury AWS, GCP, Azure, modułów HSM i zgodności DORA/PCI DSS.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Zarządu i EBA (3 min): Skala ekspozycji finansowej (kary PCI SSC i DORA do 1% dziennego obrotu), podatności na skimming, budżet CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=15 min / RPO=0) (4 min): Uzasadnienie krytyczności zerowej utraty danych transakcyjnych (BCM Auditor).
• Dekonstrukcja wektorów technicznych (Magecart, SRI, CSP, TLPT, CMEK) (4 min): Przedstawienie dowodów podatności skryptów checkout (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Analiza 5 Why i harmonogram naprawczy (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania Dyrektora Operacyjnego o wpływ CSP na konwersję sprzedaży (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi zawierać:

A. Executive Summary dla Zarządu i EBA (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W platformie wielochmurowej przetwarzającej 1 500 TPS wykryto krytyczne luki: brak ochrony skryptów na bramce checkout przed atakami Magecart (naruszenie nowego wymogu PCI DSS v4.0) oraz wyłączenie produkcji z testów TLPT (DORA). Ryzyko operacyjno-prawne oszacowano na 20/25. Rekomendacja: Natychmiastowe wdrożenie CSP/SRI, migracja do kluczy CMEK w GCP oraz zaplanowanie testów produkcyjnych TIBER-PL (inwestycja CAP: 490 tys. PLN).

B. Zaawansowany Plan Audytu ISMS / DORA w GlobalPay Solutions:

• Zleceniodawca: Komitet Audytu Rady Nadzorczej. Zakres: Klastry AWS, GCP, Azure, bramki płatnicze, moduły HSM, centrum SOC.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Web Skimming na checkout): IR = 4 x 5 = 20/25. Kontrole: SRI, CSP, monitoring skryptów w przeglądarce. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Brak produkcyjnego TLPT): IR = 4 x 4 = 16/25. Kontrole: Testy TIBER-PL na produkcji z zespołem Red Team. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Brak CMEK w GCP): IR = 3 x 4 = 12/25. Kontrole: Cloud KMS z HSM BYOK. RR = 1 x 1 = 1/25.
  • Parametry BCM: RTO = 15 min, RPO = 0 min, MTPD = 2h.
• Karta Ustalenia w modelu 4C dla Braku Ochrony Skryptów Płatniczych (PCI DSS 6.4.3):
  • Condition (Stan faktyczny): Strona płatności checkout pobierała 8 zewnętrznych skryptów JavaScript z publicznych sieci CDN bez weryfikacji sum kontrolnych SRI i bez wdrożenia nagłówków Content Security Policy (CSP).
  • Criteria (Kryteria): PCI DSS v4.0 wymóg 6.4.3 i 11.6.1; Rozporządzenie DORA art. 9; ISO/IEC 27001:2022 A.8.26, A.8.28.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego skrypty ładowano z CDN bez SRI? -> Bo zespół marketingu wdrożył narzędzia analityki bez zgody architektów bezpieczeństwa.

Dlaczego bez zgody? -> Bo proces wdrażania zmian na frontendzie nie wymagał akceptacji w potoku CI/CD.

Dlaczego potok nie weryfikował SRI? -> Brak zautomatyzowanych testów sprawdzających wymogi PCI DSS v4.0 w potokach frontendowych.

Przyczyna źródłowa (Root Cause): Brak zintegrowanych bramek bezpieczeństwa dla komponentów frontendowych i brak wdrożenia nowych wymagań PCI DSS v4.0 w cyklu życia aplikacji.

• Consequence (Skutki): Ryzyko ataku Magecart, przechwycenia danych kartowych milionów klientów, kary finansowe od organizacji płatniczych Visa/Mastercard (do 500 tys. USD miesięcznie), sankcje DORA i utrata licencji KIP.

C. Analiza zalet, wad i kosztów:

• Zalety: Wykluczenie ryzyka ataków Magecart na wielką skalę; bezwzględna zgodność ze standardami DORA i PCI DSS v4.0; zabezpieczenie miliardowych obrotów spółki.
• Wady: Koszt 490 tys. PLN na testy Red Team TIBER-PL i narzędzia Client-Side Protection; konieczność rygorystycznego nadzoru nad skryptami marketingowymi.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (Rozporządzenie DORA).
• PCI Security Standards Council: "Payment Card Industry Data Security Standard v4.0", 2022.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma ISO/IEC 27017:2015 - Zabezpieczenia w usługach w chmurze.
• Europejski Bank Centralny / NBP: "Ramy TIBER-EU / TIBER-PL w testowaniu odporności cyfrowej", Frankfurt/Warszawa.
• Open Web Application Security Project (OWASP): "OWASP Client-Side Security Top 10".

• U1 Student umie zaplanować audyt ISMS w wielochmurowym środowisku płatniczym o wielkiej skali transakcyjnej.
• U2 Student stosuje model 4C do formułowania uchybień w standardzie PCI DSS v4.0 i DORA.
• U3 Student wykonuje analizę ryzyka w matrycy 5x5 i wyznacza parametry RTO=15 min / RPO=0 min.
• U4 Student buduje Plan CAP ze wskaźnikami KPI oraz Executive Summary dla organów nadzorczych.
• W1W2W3 Student wykazuje ekspercką wiedzę o standardach DORA, PCI DSS v4.0, ISO 27017 i wytycznych EBA.
• K1K2K3 Student demonstruje najwyższy profesjonalizm i rzetelność w ocenie operacji finansowych.

• U1 Opracowanie zaawansowanego planu audytu ISMS dla procesu wytwarzania oprogramowania bankowego i bramek API.
• U2 Formułowanie i klasyfikacja uchybień w architekturze DevSecOps i API w modelu 4C z analizą 5 Why.
• U3 Przeprowadzenie analizy ryzyka kradzieży danych finansowych przez podatności BOLA/IDOR w matrycy 5x5.
• U4 Opracowanie profesjonalnego Planu CAP z KPI oraz Executive Summary Pitch to Board.
• W1 Ochrona tajemnicy bankowej (art. 104 Prawa bankowego) i danych osobowych klientów banków.
• W2W3 Dyrektywa PSD2/PSD3, Rozporządzenie DORA, Rekomendacja D KNF, standard NIST SP 800-218 (SSDF) i ISO/IEC 27001:2022.
• K1K2K3 Zdolność do konstruktywnego wywierania wpływu na inżynierów oprogramowania i etyka zawodowa audytora.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole rozwoju oprogramowania), Wyk4 (DORA i bankowość), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego planu audytu ISMS procesu bezpiecznego wytwarzania oprogramowania (Secure SDLC) w wyspecjalizowanym bankowym software house dostarczającym rozwiązania Bankowości Otwartej (Open Banking) i portfele API dla 8 banków komercyjnych. Zadanie koncentruje się na audycie potoków DevSecOps, weryfikacji podatności klasy Broken Object Level Authorization (BOLA) i IDOR w interfejsach API wg OWASP API Security Top 10, kontroli łańcucha dostaw oprogramowania i analizie cyfrowej listy składowej (SBOM), szacowaniu ryzyka w matrycy 5x5, sformułowaniu ustaleń w modelu 4C oraz przygotowaniu Planu Działań Korygujących (CAP) ze wskaźnikami KPI i Executive Summary dla Rad Dyrektorów banków zrzeszonych.

Spółka "OpenFinTech Systems Sp. z o.o." tworzy i utrzymuje w modelu Chmury Sektorowej platformę Open Banking API integrującą 8 banków komercyjnych i spółdzielczych z setkami podmiotów trzecich (TPP). Platforma procesuje zapytania o historię rachunków (AIS) oraz inicjowanie płatności (PIS). Spółka zatrudnia 160 inżynierów oprogramowania, architektów chmury i analityków bezpieczeństwa.

Środowisko deweloperskie i architektura API:

• Potoki CI/CD oparte na GitLab CI oraz klastrach Kubernetes w chmurze prywatnej zintegrowanej z AWS.
• Architektura oparta na mikroserwisach Spring Boot / Java 21 komunikujących się przez interfejsy REST API z uwierzytelnianiem OAuth2 i tokenami JWT.

Złożone incydenty i uchybienia ujawnione w audycie zerowym:

• Podatność BOLA (Broken Object Level Authorization) w module AIS: Wykryto, że endpoint API "/api/v2/accounts/{account_id}/transactions" weryfikował poprawność podpisu tokenu JWT, lecz nie sprawdzał, czy identyfikator konta (account_id) w ścieżce URL należy do użytkownika wskazanego w tokenie. Pozwalało to na odczyt historii rachunków dowolnego klienta banku przez prostą zmianę parametru numerycznego w zapytaniu (podatność BOLA / OWASP API1:2023).
• Brak weryfikacji SBOM i podatne zależności: Aplikacja wykorzystywała zewnętrzną bibliotekę do weryfikacji certyfikatów eIDAS z podatnością RCE (CVSS 9.8), która nie została wykryta przez 4 miesiące z powodu braku automatycznego generowania i skanowania SBOM w potokach CI/CD.
• Wyciek sekretów w logach testowych: W klastrze testowym kody PIN i tokeny autoryzacyjne były zapisywane w nieszyfrowanych plikach logów w usłudze Elasticsearch, do której dostęp mieli wszyscy programiści i stażyści.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert DevSecOps i Regulacji Bankowych): Koordynuje audyt, współpracuje z CTO, CISO banków partnerskich i KNF, przygotowuje Executive Summary.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt potoków GitLab CI/CD, narzędzi SAST/DAST, analizy SBOM (CycloneDX), testów API (narzędzia Postman/OWASP ZAP) i weryfikacji tokenów JWT.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla wycieku danych bankowych, formułuje kartę 4C dla podatności BOLA i konstruuje Plan CAP ze wskaźnikami KPI.

• Krok 2 (Wyznaczenie zakresu i granic audytu):

Zakres: Repozytoria GitLab, potoki CI/CD, klastry Kubernetes, bramy API Gateway, procedury generowania SBOM, logi Elasticsearch.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Rozporządzenie DORA art. 9 i 16, Rekomendacja D KNF, Norma ISO/IEC 27001:2022 (A.8.25-A.8.32), Standard NIST SP 800-218 (SSDF), Standard OWASP API Security Top 10 (2023).

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Masowy wyciek historii rachunków klientów przez podatność BOLA w API. P=4, S=5 (Katastrofalny - naruszenie tajemnicy bankowej, kary KNF i UODO do 20 mln EUR, upadłość spółki). Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Wdrożenie walidacji obiektowej na poziomie filtru Spring Security, testy DAST i integracja z bramą API Gateway. Ryzyko rezydualne: P=1, S=2 (2/25 - Akceptowalne).
  • Zagrożenie 2: Wprowadzenie złośliwego kodu przez podatną bibliotekę open-source (brak SBOM). P=4, S=5. Ryzyko inherentne: 20/25. Kontrole: Obowiązkowe generowanie SBOM (CycloneDX) i automatyczna blokada potoku przez narzędzie Dependency-Track. Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Kradzież tokenów i danych logowania z nieszyfrowanych logów Elasticsearch. P=3, S=4. Ryzyko inherentne: 12/25. Kontrole: Maskowanie logów w locie (Log Masking) i kontrola dostępu RBAC. Ryzyko rezydualne: 1/25.

Parametry BCM: RTO = 30 min dla przywrócenia bramki API, RPO = 0 min, MTPD = 2h.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla podatności BOLA w module Open Banking API.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Natychmiastowa łatka w kodzie i wdrożenie reguły WAF blokującej zapytania BOLA (0-7 dni), wdrożenie skanowania SBOM i maskowania logów (30 dni), certyfikacja procesu Secure SDLC wg NIST SSDF (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległe badanie kodu i API, potoków CI/CD i zgodności regulacyjnej DORA/KNF.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Rad Dyrektorów banków partnerskich (3 min): Zagrożenia wyciekiem danych bankowych przez podatność BOLA, ryzyka DORA, budżet CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=30 min / RPO=0) (4 min): Uzasadnienie krytyczności podatności w interfejsach Open Banking (BCM Auditor).
• Dekonstrukcja wektorów technicznych (BOLA, OWASP API, SBOM, JWT) (4 min): Przedstawienie dowodów braku walidacji obiektowej w kodzie (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Analiza 5 Why i harmonogram wdrożenia automatyzacji DevSecOps (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania CTO dotyczące wpływu skanerów na czas budowania aplikacji (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Rad Dyrektorów banków (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W platformie Open Banking API wykryto krytyczną podatność BOLA umożliwiającą nieautoryzowany odczyt historii rachunków dowolnego klienta oraz brak kontroli łańcucha dostaw kodu (brak SBOM). Ryzyko naruszenia tajemnicy bankowej wynosi 20/25. Rekomendacja: Natychmiastowe wdrożenie walidacji obiektowej w bramie API Gateway, automatyzacja generowania SBOM oraz maskowanie logów (inwestycja CAP: 320 tys. PLN).

B. Zaawansowany Plan Audytu ISMS w OpenFinTech Systems:

• Zleceniodawca: Komitet Bezpieczeństwa Zrzeszenia Banków. Zakres: Repozytoria kodu, potoki CI/CD, klastry K8s, platforma API Gateway, logi Elasticsearch.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Podatność BOLA w API): IR = 4 x 5 = 20/25. Kontrole: Walidacja obiektowa, bramka API WAF, testy DAST. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Brak kontroli zależności open-source SBOM): IR = 4 x 5 = 20/25. Kontrole: SBOM CycloneDX, Dependency-Track, blokada CI/CD. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Tokeny w logach testowych): IR = 3 x 4 = 12/25. Kontrole: Filtry Logback Masking, RBAC w Elasticsearch. RR = 1 x 1 = 1/25.
  • Parametry BCM: RTO = 30 min, RPO = 0 min, MTPD = 2h.
• Karta Ustalenia w modelu 4C dla Podatności BOLA w API (OWASP API1:2023):
  • Condition (Stan faktyczny): Endpoint "/api/v2/accounts/{account_id}/transactions" nie weryfikował uprawnień zalogowanego użytkownika do wskazanego w ścieżce URL identyfikatora konta, umożliwiając pobranie historii operacji dowolnego klienta banku.
  • Criteria (Kryteria): OWASP API Security Top 10 (API1:2023 BOLA); Rozporządzenie DORA art. 9 ust. 2; Rekomendacja D KNF; ISO/IEC 27001:2022 A.8.26, A.8.28.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego brakowało walidacji? -> Bo programista założył, że bramka API Gateway sprawdza uprawnienia biznesowe.

Dlaczego bramka nie sprawdzała? -> Bo w konfiguracji bramy wdrożono wyłącznie weryfikację podpisu tokenu JWT (uwierzytelnianie bez autoryzacji zasobu).

Dlaczego testy jednostkowe nie wykryły błędu? -> Bo scenariusze testowe weryfikowały tylko poprawne przypadki (tzw. Happy Path).

Dlaczego zabrakło testów negatywnych? -> Brak sformalizowanego standardu testowania bezpieczeństwa API w metodyce Scrum.

Przyczyna źródłowa (Root Cause): Brak zintegrowanych wytycznych bezpiecznego projektowania API (Security Architecture Guidelines) oraz brak automatycznych testów DAST sprawdzających autoryzację obiektową w potoku CI/CD.

• Consequence (Skutki): Ryzyko masowego ujawnienia tajemnicy bankowej milionów obywateli; utrata koncesji na świadczenie usług AIS/PIS; wielomilionowe kary KNF i UODO; katastrofa reputacyjna banków zrzeszonych.

C. Analiza zalet, wad i kosztów:

• Zalety: Wyeliminowanie najgroźniejszej podatności w nowoczesnym API (BOLA); pełna transparentność komponentów open-source dzięki SBOM; spełnienie rygorów DORA i KNF.
• Wady: Koszt 320 tys. PLN na narzędzia SCA i szkolenia programistów; wydłużenie czasu wykonywania potoku CI/CD o 8 minut z powodu dodatkowych skanów.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Open Web Application Security Project (OWASP): "OWASP API Security Top 10 2023", w szczególności API1:2023 Broken Object Level Authorization.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (Rozporządzenie DORA).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2015/2366 (Dyrektywa PSD2) oraz projekt PSD3.
• Urząd Komisji Nadzoru Finansowego (UKNF): "Rekomendacja D dotycząca zarządzania obszarami IT", Warszawa.
• NIST Special Publication 800-218: "Secure Software Development Framework (SSDF) v1.1", 2022.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.

• U1 Student umie zaplanować zaawansowany audyt procesu Secure SDLC w bankowości otwartej.
• U2 Student stosuje kanoniczny model 4C do dokumentowania uchybień w architekturze API.
• U3 Student wykonuje analizę ryzyka BOLA/IDOR w 25-stopniowej matrycy 5x5 z parametrami BCM.
• U4 Student buduje Plan CAP ze wskaźnikami KPI oraz Executive Summary dla zarządów instytucji finansowych.
• W1W2W3 Student wykazuje ekspercką wiedzę o standardach OWASP API, NIST SSDF, DORA i PSD2.
• K1K2K3 Student demonstruje wysokie kompetencje w dialogu technicznym z zespołami deweloperskimi.

• U1 Opracowanie zaawansowanego planu audytu ISMS dla zakładu zbrojeniowego realizującego kontrakty wojskowe.
• U2 Dokumentowanie uchybień w kanonicznym modelu 4C z analizą przyczyn źródłowych Root Cause (5 Why).
• U3 Przeprowadzenie analizy ryzyka sabotażu i szpiegostwa w matrycy 5x5 oraz parametry BCM (RTO=0, RPO=0 dla systemów sterowania produkcją rakiet).
• U4 Opracowanie Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz Executive Summary dla organów państwa.
• W1 Ochrona tajemnicy państwowej, tajemnic wojskowych i informacji niejawnych NATO/UE.
• W2W3 Wymogi Ustawy o ochronie informacji niejawnych, ustawy o obrocie towarami o znaczeniu strategicznym, normy AQAP 2110 i ISO 27001.
• K1K2K3 Postawa kontrwywiadowcza, bezwzględna dyskrecja, odporność na inwigilację i etyka zawodowa audytora.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole fizyczne i sieciowe), Wyk4 (Informacje niejawne i KSC), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego, elitarnego planu audytu ISMS w przedsiębiorstwie przemysłu zbrojeniowego produkującym zaawansowane systemy obrony przeciwlotniczej i amunicję precyzyjną. Zadanie wymaga pogodzenia rygorów normy ISO/IEC 27001:2022 z wymogami Ustawy o ochronie informacji niejawnych (klauzule ŚCIŚLE TAJNE, NATO SECRET, UE SECRET), Wewnętrznego Systemu Kontroli (WSK w obrocie towarami o znaczeniu strategicznym), natowskiej publikacji zapewnienia jakości AQAP 2110 oraz norm emisji elektromagnetycznej TEMPEST. Zadanie obejmuje szacowanie ryzyka w matrycy 5x5 (sabotaż linii produkcyjnej, szpiegostwo obcych służb wywiadowczych), sformułowanie uchybień w modelu 4C oraz przygotowanie Planu CAP ze wskaźnikami KPI i Executive Summary dla Zarządu i Służby Kontrwywiadu Wojskowego (SKW).

Zakłady Mechaniczno-Precyzyjne "Polska Amunicja i Rakiety S.A." (spółka Polskiej Grupy Zbrojeniowej) realizują kluczowe zamówienia dla Ministerstwa Obrony Narodowej oraz sił zbrojnych państw NATO, produkując naprowadzane laserowo pociski rakietowe i systemy radarowe. Przedsiębiorstwo zatrudnia 1 200 pracowników i posiada Świadectwo Bezpieczeństwa Przemysłowego I stopnia z klauzulą ŚCIŚLE TAJNE, NATO SECRET oraz UE SECRET.

Infrastruktura i obieg danych niejawnych:

• Sieć niejawna "ORZEŁ-MIL": Całkowicie odizolowana fizycznie (Air-Gap) od sieci zewnętrznych, pracująca na certyfikowanych stacjach TEMPEST Level A w kancelarii tajnej i biurze konstrukcyjnym.
• Linie montażowe amunicji: Zautomatyzowane linie montażu ładunków wybuchowych sterowane przez systemy SCADA odcięte od sieci zakładowej.

Złożone incydenty i uchybienia ujawnione w audycie zerowym:

• Nieautoryzowane połączenie telemetryczne w obrabiarce CNC: Dwa miesiące temu dostawca nowoczesnej, 5-osiowej obrabiarki numerycznej do toczenia korpusów rakiet dokonał zdalnej diagnostyki serwisowej, podłączając modem komórkowy 5G zintegrowany z płytą główną obrabiarki (ukryty moduł telemetryczny producenta zagranicznego nieujęty w specyfikacji WSK). Przez 18 dni obrabiarka przesyłała parametry skrawania i geometrię głowic rakietowych na serwery w Szwajcarii.
• Naruszenie reżimu nośników niejawnych: Trzech inżynierów biura konstrukcyjnego przenosiło pliki projektowe CAD z sieci niejawnej "ORZEŁ-MIL" do sieci jawnej za pomocą prywatnych kart microSD wkładanych do zmodyfikowanych czytników kart, aby drukować dokumentację na szybszych drukarkach biurowych.
• Weryfikacja łańcucha kooperantów: Zakład zlecał frezowanie drobnych elementów stateczników rakiet lokalnemu podwykonawcy, który nie posiadał poświadczenia bezpieczeństwa przemysłowego i przechowywał rysunki techniczne na niezabezpieczonym serwerze FTP.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert Ochrony Informacji Niejawnych): Koordynuje audyt, współpracuje z Prezesem Zakładu, Pełnomocnikiem ds. Ochrony i oficerami SKW, przygotowuje Executive Summary.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt sieci "ORZEŁ-MIL", pomiarów emisji ujawniającej TEMPEST, analizy firmware obrabiarek CNC, zabezpieczeń SCADA i blokad sprzętowych USB.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla sabotażu produkcji rakiet, audyt zgodności WSK/AQAP 2110, formułuje kartę 4C dla backdoora w obrabiarce i konstruuje Plan CAP z KPI.

• Krok 2 (Wyznaczenie zakresu i bezwzględnych ograniczeń bezpieczeństwa):

Zakres: Kancelaria Tajna, hale montażu rakiet, biuro konstrukcyjne, sieć "ORZEŁ-MIL", park maszynowy CNC, łańcuch dostawców komponentów.

Ograniczenia: Audytorzy posiadają poświadczenia bezpieczeństwa do klauzuli ŚCIŚLE TAJNE i NATO SECRET; zakaz wnoszenia jakichkolwiek telefonów, zegarków smartwatch i urządzeń radiowych do strefy I; czynności na liniach amunicji wyłącznie w obecności Głównego Pirotechnika.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Ustawa o ochronie informacji niejawnych, Ustawa o obrocie z zagranicą towarami, technologiami o znaczeniu strategicznym (WSK), Publikacja NATO AQAP 2110, Norma PN-EN ISO/IEC 27001:2022 (A.5.19, A.7.1-A.7.4, A.8.1, A.8.20), Norma SDIP-27 Level A.

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Eksfiltracja geometrii głowicy rakietowej przez ukryty modem 5G w obrabiarce CNC do obcych służb. P=4, S=5 (Katastrofalny - utrata przewagi technologicznej Sił Zbrojnych RP i NATO, kompromitacja systemu obrony). Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Fizyczny demontaż modułów radiowych, klatki Faradaya, stały monitoring widma radiowego (RF spectrum analysis). Ryzyko rezydualne: P=1, S=2 (2/25 - Akceptowalne).
  • Zagrożenie 2: Sabotaż cyfrowy linii elaboracji materiałów wybuchowych (zmiana parametrów mieszanki i eksplozja). P=2, S=5. Ryzyko inherentne: 10/25 (Wysokie). Kontrole: Sieć Air-Gap, kontrola sum kontrolnych kodu sterowników PLC, weryfikacja dwuosobowa (Two-Man Rule). Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Wyniesienie planów na kartach microSD przez inżynierów. P=4, S=5. Ryzyko inherentne: 20/25. Kontrole: Bramki detekcji nieliniowej (NLJD) na wejściu, blokady mechaniczne portów, postępowania dyscyplinarne. Ryzyko rezydualne: 1/25.

Parametry BCM: RTO = 0 min, RPO = 0 min, MTPD = 0 min dla linii uzbrojenia.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla ukrytego modułu telemetrycznego 5G w obrabiarce CNC.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Fizyczne odcięcie modemu 5G i skanowanie radiowe parku maszynowego (0-7 dni), wdrożenie bramek detekcji elektroniki NLJD na śluzach (30 dni), certyfikacja wszystkich obrabiarek wg procedury WSK i akredytacja SKW (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległy audyt strefy niejawnej "ORZEŁ-MIL", parku maszynowego CNC i łańcucha dostawców WSK.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Zarządu i SKW (3 min): Zagrożenia szpiegowskie w parku maszynowym CNC, weryfikacja procedur WSK i AQAP 2110, budżet CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=0 / RPO=0) (4 min): Prezentacja szacowania ryzyka sabotażu i wycieku technologii rakietowych (BCM Auditor).
• Dekonstrukcja wektorów technicznych (5G telemetry backdoor, TEMPEST, Air-Gap) (4 min): Przedstawienie dowodów nieautoryzowanej emisji radiowej z obrabiarki (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Analiza 5 Why i plan wdrożenia procedury weryfikacji sprzętu zbrojeniowego (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania Oficera Kontrwywiadu Wojskowego o stan bezpieczeństwa przemysłowego (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Zarządu i SKW (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W strategicznym zakładzie zbrojeniowym ujawniono krytyczny incydent szpiegowski: obecność nienadzorowanego modemu komórkowego 5G w obrabiarce numerycznej CNC produkującej korpusy pocisków rakietowych oraz omijanie strefy niejawnej przez inżynierów. Ryzyko kompromitacji technologii obronnej wynosi 20/25. Rekomendacja: Natychmiastowe odcięcie modułów radiowych, instalacja bramek detekcji złączy nieliniowych NLJD oraz rygorystyczny audyt kooperantów WSK (inwestycja CAP: 750 tys. PLN).

B. Zaawansowany Plan Audytu ISMS w Polska Amunicja i Rakiety S.A.:

• Zleceniodawca: Prezes Zarządu w porozumieniu z SKW. Zakres: Kancelaria Tajna, sieć "ORZEŁ-MIL", biuro konstrukcyjne, hale CNC, linie montażu rakiet, podwykonawcy WSK.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Modem 5G w obrabiarce CNC): IR = 4 x 5 = 20/25. Kontrole: Fizyczny demontaż, audyt RF, klatki Faradaya. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Sabotaż linii amunicji): IR = 2 x 5 = 10/25. Kontrole: Air-Gap, Two-Man Rule, weryfikacja sum kontrolnych PLC. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Wynoszenie danych na microSD): IR = 4 x 5 = 20/25. Kontrole: Bramki NLJD, blokady rejestru, rewizje osobiste. RR = 1 x 1 = 1/25.
  • Parametry BCM: RTO = 0 min, RPO = 0 min, MTPD = 0 min.
• Karta Ustalenia w modelu 4C dla Modułu Telemetrycznego w Maszynie CNC:
  • Condition (Stan faktyczny): 5-osiowa obrabiarka CNC zawierała zintegrowany modem komórkowy 5G z kartą eSIM, który bez wiedzy personelu zakładowego nawiązywał połączenia i przesyłał dane telemetryczne geometrii detali rakietowych na zagraniczny adres IP.
  • Criteria (Kryteria): Ustawa o ochronie informacji niejawnych art. 47; Standard AQAP 2110 sekcja 7.4; Wewnętrzny System Kontroli (WSK); ISO/IEC 27001:2022 A.5.19, A.8.20.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego modem znajdował się w maszynie? -> Bo producent montuje go standardowo do zdalnego serwisu predykcyjnego.

Dlaczego nie został wykryty przy odbiorze? -> Bo komisja odbiorcza sprawdziła wyłącznie parametry mechaniczne i dokładność skrawania.

Dlaczego nie zbadano elektroniki i łączności? -> Dział Cyberbezpieczeństwa nie uczestniczył w odbiorze technicznym obrabiarki.

Dlaczego nie uczestniczył? -> Procedura zakupowa WSK nie przewidywała kontroli kontrwywiadowczej sprzętu technologicznego (Hardware Supply Chain Security).

Przyczyna źródłowa (Root Cause): Brak procedury audytu bezpieczeństwa łańcucha dostaw sprzętu technologicznego (Hardware Security Assessment) i brak procedury skanowania widma radiowego przed wdrożeniem maszyn do strefy niejawnej.

• Consequence (Skutki): Ryzyko odczytania tajemnic państwowych i technologii rakietowych NATO przez obce mocarstwo; możliwość zdalnego unieruchomienia lub rozkalibrowania produkcji amunicji w czasie wojny; utrata Świadectwa Bezpieczeństwa Przemysłowego I stopnia.

C. Analiza zalet, wad i kosztów:

• Zalety: Skuteczne odcięcie wektorów szpiegostwa obcych mocarstw w produkcji rakiet; bezwzględne spełnienie standardów NATO i obronności RP; ochrona wielomiliardowych kontraktów zbrojeniowych.
• Wady: Koszt 750 tys. PLN na bramki NLJD, analizatory widma i procedury odbiorcze; rygoryzm procedur wydłużający proces modernizacji parku maszynowego.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• 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 (Dz.U. z 2023 r. poz. 1582).
• Publikacja Sojusznicza Zapewnienia Jakości NATO AQAP 2110: "Wymagania NATO dotyczące zapewnienia jakości w projektowaniu, pracach rozwojowych i produkcji".
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Standard SDIP-27 Level A: "NATO TEMPEST Requirements and Evaluation Procedures".
• Służba Kontrwywiadu Wojskowego (SKW): "Instrukcja bezpieczeństwa przemysłowego dla przedsiębiorstw sektora zbrojeniowego", Warszawa.

• U1 Student projektuje zaawansowany plan audytu ISMS dla zakładu przemysłu zbrojeniowego.
• U2 Student dokumentuje incydenty w kanonicznym modelu 4C z analizą 5 Why dla sprzętu wojskowego.
• U3 Student szacuje ryzyka szpiegowskie i sabotażowe w matrycy 5x5 z parametrami RTO=0.
• U4 Student przygotowuje Plan CAP z KPI oraz Executive Summary dla organów bezpieczeństwa państwa.
• W1W2W3 Student wykazuje ekspercką wiedzę z zakresu ochrony tajemnicy wojskowej, norm NATO AQAP i ISO 27001.
• K1K2K3 Student demonstruje najwyższą dyscyplinę, czujność kontrwywiadowczą i odpowiedzialność za obronność państwa.

• U1 Opracowanie zaawansowanego planu audytu drugiej strony dla globalnego dostawcy chmury SaaS.
• U2 Dokumentowanie uchybień w architekturze chmurowej w modelu 4C z analizą przyczyn źródłowych Root Cause (5 Why).
• U3 Przeprowadzenie analizy ryzyka naruszenia separacji wielodostępnej (cross-tenant leakage) w matrycy 5x5.
• U4 Opracowanie Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz Executive Summary.
• W1 Ochrona danych osobowych pacjentów i poufnych receptur leków w badaniach klinicznych.
• W2W3 Normy ISO/IEC 27001:2022, ISO/IEC 27017, ISO/IEC 27018, standard SOC 2 Type II, RODO (art. 28) oraz wytyczne amerykańskie HIPAA / HITECH.
• K1K2K3 Niezależność audytorska, profesjonalizm w relacjach z globalnymi korporacjami i bezkompromisowość w ochronie danych wrażliwych.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole chmurowe ISO 27017/27018), Wyk4 (RODO art. 28), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego planu audytu drugiej strony (audyt u kluczowego dostawcy usług chmurowych / Supplier Audit) w globalnej firmie technologicznej dostarczającej platformę chmurową SaaS do zarządzania badaniami klinicznymi i farmakokinetycznymi dla 40 międzynarodowych koncernów farmaceutycznych. Zadanie stawia najwyższe wymagania w zakresie: badania logicznej separacji danych najemców (multi-tenant isolation) w klastrach chmurowych, weryfikacji raportów SOC 2 Type II, audytu zgodności z normami ISO/IEC 27017 (bezpieczeństwo w chmurze) i ISO/IEC 27018 (ochrona PII w chmurze publicznej), szacowania ryzyka w matrycy 5x5, udokumentowania ustaleń w modelu 4C oraz przygotowania Planu CAP z KPI i Executive Summary dla Komitetu Jakości Koncernów Farmaceutycznych.

Spółka "PharmaCloud Global Inc." z siedzibą w Dublinie i oddziałem inżynieryjnym w Warszawie dostarcza platformę chmurową SaaS "ClinicalTrials Cloud" obsługującą procesy 40 największych koncernów biofarmaceutycznych na świecie. Baza platformy zawiera dane z prób klinicznych ponad 600 000 pacjentów z 45 krajów.

Architektura chmurowa i zarządzanie danymi:

• Architektura multi-tenant osadzona w chmurze AWS (Region Irlandia i Niemcy) z wykorzystaniem klastrów Amazon Elastic Kubernetes Service (EKS) i baz PostgreSQL w usłudze Amazon RDS.
• Szyfrowanie: Klienci korporacyjni wymagają stosowania modelu Bring Your Own Key (BYOK) lub Hold Your Own Key (HYOK), w którym klucze szyfrujące znajdują się pod wyłączną kontrolą klienta zewnętrznego (koncernu).

Złożone incydenty i uchybienia ujawnione w toku wstępnego badania:

• Podatność na wyciek między najemcami (Cross-Tenant Data Leakage): W wyniku błędu w oprogramowaniu pośredniczącym (Middleware) filtry izolacji klienta (Tenant-Context) nie były prawidłowo przekazywane w asynchronicznych zapytaniach kolejki Apache Kafka, co doprowadziło do sytuacji, w której analityk koncernu A otrzymał raport z danymi pacjentów z badania klinicznego koncernu B.
• Naruszenie wymogów normy ISO/IEC 27018 (usuwanie danych po zakończeniu umowy): Wykryto, że po rozwiązaniu umowy przez jednego z klientów jego baza została logicznie wyłączona, lecz zrzuty baz (snapshots) w magazynie AWS S3 nie zostały usunięte i przechowywane są w nieszyfrowanych kopiach archiwalnych od 14 miesięcy (brak realizacji procedury Secure Data Deletion).
• Weryfikacja raportu SOC 2 Type II: Raport niezależnego audytora SOC 2 sprzed 8 miesięcy zawierał zastrzeżenie (Qualified Opinion) dotyczące braku weryfikacji uprawnień dostępowych inżynierów operacyjnych chmury, jednak spółka nie wdrożyła działań naprawczych.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert Audytu Dostawców Chmury): Koordynuje audyt drugiej strony z ramienia konsorcjum koncernów farmaceutycznych, weryfikuje raport SOC 2, przygotowuje Executive Summary.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt klastrów EKS, konfiguracji filtrów w Apache Kafka, mechanizmów separacji baz PostgreSQL, szyfrowania BYOK/HYOK i zarządzania uprawnieniami IAM w AWS.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla wycieku danych między najemcami, audyt procedur retencji i niszczenia danych (ISO 27018), formułuje kartę 4C dla błędu Kafki i konstruuje Plan CAP z KPI.

• Krok 2 (Wyznaczenie zakresu i granic audytu u dostawcy):

Zakres: Środowisko AWS PharmaCloud, klastry EKS, kolejki Kafka, magazyny S3, moduły zarządzania kluczami KMS/BYOK, procedury operacyjne wsparcia technicznego.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Norma PN-EN ISO/IEC 27001:2022 (A.5.19, A.8.11, A.8.24), Norma ISO/IEC 27017:2015 (kontrole CLD.6.3, CLD.8.1 dotyczące izolacji najemców), Norma ISO/IEC 27018:2019 (ochrona danych osobowych w chmurze), RODO art. 28, Standard AICPA SOC 2 Trust Services Criteria (Security, Confidentiality, Privacy).

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Naruszenie izolacji między najemcami (Cross-Tenant Leakage) w kolejce Kafka i wyciek poufnych danych badań klinicznych. P=4, S=5 (Katastrofalny - zerwanie kontraktów przez 40 koncernów, pozwy odszkodowawcze na setki milionów EUR, unieważnienie prób lekowych przez FDA/EMA). Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Wdrożenie partycjonowania topiców Kafki z kluczem Tenant_ID, mechanizm mTLS i testy automatyczne weryfikujące izolację w potoku CI/CD. Ryzyko rezydualne: P=1, S=2 (2/25 - Akceptowalne).
  • Zagrożenie 2: Pozostawienie nieszyfrowanych kopii archiwalnych po ustaniu umowy (brak retencji ISO 27018). P=4, S=4. Ryzyko inherentne: 16/25 (Wysokie). Kontrole: Automatyczny cykl życia obiektów w AWS S3 (Lifecycle Rules) z wymuszonym niszczeniem kryptograficznym (Crypto-Shredding). Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Nieuprawniony wgląd inżynierów wsparcia do baz pacjentów (zastrzeżenie SOC 2). P=3, S=4. Ryzyko inherentne: 12/25. Kontrole: Wdrożenie bramy dostępu Just-In-Time z mechanizmem Customer Lockbox (zgoda klienta na wejście inżyniera). Ryzyko rezydualne: 1/25.

Parametry BCM: RTO = 1h, RPO = 0 min, MTPD = 4h dla platformy SaaS.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla braku izolacji najemców w kolejce Kafka.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Natychmiastowa rekonfiguracja kolejek Kafka i wdrożenie filtrów kontekstu (0-7 dni), wdrożenie automatycznego niszczenia kopii S3 (30 dni), wdrożenie Customer Lockbox i re-certyfikacja SOC 2 Type II bez zastrzeżeń (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległe badanie architektury EKS/Kafka, bezpieczeństwa baz danych RDS i zgodności z ISO 27017/27018.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Komitetu Jakości Koncernów Farmaceutycznych (3 min): Skala ekspozycji na naruszenie separacji danych, weryfikacja zastrzeżeń SOC 2, budżet CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=1h / RPO=0) (4 min): Prezentacja szacowania ryzyka utraty badań klinicznych i sankcji FDA/EMA (BCM Auditor).
• Dekonstrukcja wektorów technicznych (Kafka, Tenant-Context, S3 Crypto-Shredding, BYOK) (4 min): Przedstawienie dowodów wycieku danych między najemcami (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Analiza 5 Why i plan wdrożenia mechanizmu Customer Lockbox (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na zarzuty Zarządu PharmaCloud dotyczące rygorystyczności oceny audytowej (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Komitetu Jakości Koncernów Farmaceutycznych (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W platformie chmurowej SaaS ClinicalTrials Cloud zidentyfikowano krytyczną podatność naruszającą logiczną separację danych najemców (Multi-Tenant Isolation) w kolejce Kafka oraz zaniechanie bezpiecznego niszczenia kopii archiwalnych (ISO 27018). Ryzyko kontraktowo-prawne wynosi 20/25. Rekomendacja: Warunkowe utrzymanie kontraktów pod warunkiem natychmiastowej naprawy filtrów Kafki, wdrożenia Crypto-Shredding oraz mechanizmu Customer Lockbox w terminie 60 dni (inwestycja CAP: 420 tys. EUR).

B. Zaawansowany Plan Audytu Drugiej Strony ISMS w PharmaCloud Global:

• Zleceniodawca: Konsorcjum Koncernów Farmaceutycznych. Zakres: Klastry EKS w AWS, kolejki Kafka, bazy RDS, zasobniki S3, platforma zarządzania tożsamością, procedury SOC 2.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Wyciek Cross-Tenant w Kafka): IR = 4 x 5 = 20/25. Kontrole: Partycjonowanie topiców, mTLS, testy integracyjne w CI/CD. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Brak usuwania kopii S3): IR = 4 x 4 = 16/25. Kontrole: S3 Lifecycle, Crypto-Shredding z kasowaniem klucza KMS. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Nieautoryzowany dostęp inżynierów wsparcia): IR = 3 x 4 = 12/25. Kontrole: Customer Lockbox z zatwierdzaniem przez klienta. RR = 1 x 1 = 1/25.
  • Parametry BCM: RTO = 1h, RPO = 0 min, MTPD = 4h.
• Karta Ustalenia w modelu 4C dla Naruszenia Separacji Wielodostępnej w Apache Kafka:
  • Condition (Stan faktyczny): Komponent kolejkowy Apache Kafka przetwarzał zdarzenia asynchroniczne bez walidacji parametru Tenant_ID w nagłówkach wiadomości, co spowodowało wysłanie raportu z danymi pacjentów koncernu A do subskrybenta koncernu B.
  • Criteria (Kryteria): Norma ISO/IEC 27017:2015 kontrola CLD.6.3 (Izolacja zasobów w chmurze); SOC 2 Trust Services Criteria CC6.1, CC6.3; RODO art. 28 ust. 3 lit. c i art. 32.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego nagłówek Tenant_ID nie był walidowany? -> Bo nowy mikroserwis analityczny pomijał filtr kontekstowy przy deserializacji obiektów JSON.

Dlaczego pomijał filtr? -> Bo programista użył standardowego deserializatora zamiast bezpiecznej biblioteki firmowej (Custom Secure Deserializer).

Dlaczego testy nie wykryły błędu? -> Bo w środowisku testowym przeprowadzano testy wyłącznie na danych jednego syntetycznego najemcy.

Dlaczego brakowało testów wielonajemnych? -> Brak sformalizowanego standardu testów Cross-Tenant Isolation w procesie QA.

Przyczyna źródłowa (Root Cause): Brak zautomatyzowanych testów naruszenia separacji najemców w potoku CI/CD oraz brak wymuszenia architektury izolacji na poziomie infrastruktury kolejkowej.

• Consequence (Skutki): Naruszenie tajemnicy handlowej i danych wrażliwych pacjentów; ryzyko gigantycznych pozwów odszkodowawczych od koncernów farmaceutycznych; zablokowanie badań klinicznych przez Europejską Agencję Leków (EMA) i amerykańską FDA.

C. Analiza zalet, wad i kosztów:

• Zalety: Odzyskanie pełnej wiarygodności przed globalnymi koncernami; eliminacja ryzyka pozwów odszkodowawczych; wzmocnienie pozycji rynkowej dostawcy SaaS w sektorze medycznym.
• Wady: Koszt 420 tys. EUR na re-architekturę kolejek i audyt SOC 2; konieczność zaangażowania zespołów inżynierskich w audyty klientów.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma ISO/IEC 27017:2015 - Zabezpieczenia w usługach w chmurze.
• Norma ISO/IEC 27018:2019 - Ochrona danych osobowych (PII) w chmurach publicznych dla dostawców chmurowych.
• American Institute of CPAs (AICPA): "SOC 2 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy".
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 28, art. 32.
• U.S. Department of Health and Human Services (HHS): "Health Insurance Portability and Accountability Act (HIPAA) Security Rule".

• U1 Student umie zaplanować zaawansowany audyt drugiej strony u globalnego dostawcy chmury SaaS.
• U2 Student dokumentuje uchybienia w architekturze wielodostępnej w modelu 4C z analizą 5 Why.
• U3 Student wykonuje analizę ryzyka wycieku między najemcami w matrycy 5x5 i ustala parametry BCM.
• U4 Student buduje Plan CAP ze wskaźnikami KPI oraz Executive Summary dla komitetów jakości korporacji.
• W1W2W3 Student wykazuje dogłębną znajomość norm ISO 27017, ISO 27018, SOC 2 oraz regulacji farmaceutycznych.
• K1K2K3 Student demonstruje niezależność, odporność na presję korporacyjną i najwyższe standardy etyczne.

• U1 Opracowanie zaawansowanego planu audytu ISMS dla węzła rdzeniowego Internetu i operatora Tier-1.
• U2 Dokumentowanie uchybień w architekturze sieci szkieletowej w modelu 4C z analizą przyczyn źródłowych (5 Why).
• U3 Przeprowadzenie analizy ryzyka paraliżu krajowego Internetu i ataków BGP Hijacking w matrycy 5x5.
• U4 Opracowanie Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz Executive Summary dla organów cyberbezpieczeństwa.
• W1W3 Dyrektywa NIS2 (sektor infrastruktury cyfrowej), Prawo komunikacji elektronicznej, Ustawa o KSC i ochrona infrastruktury krytycznej.
• W2 Norma ISO/IEC 27001:2022, norma branżowa ISO/IEC 27011 (bezpieczeństwo w telekomunikacji), wytyczne MANRS (Mutually Agreed Norms for Routing Security) i ISO 22301.
• K1K2K3 Świadomość wagi cyberodporności rdzenia sieciowego państwa, profesjonalizm inżynierski i etyka audytorska.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole telekomunikacyjne ISO 27011), Wyk4 (NIS2 i KSC), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego planu audytu ISMS i cyberodporności w strategicznym węźle wymiany ruchu internetowego (Internet Exchange Point - IXP) oraz u operatora sieci światłowodowej klasy Tier-1 stanowiącego rdzeń krajowej łączności cyfrowej. Jednostka ma status podmiotu kluczowego Dyrektywy NIS2 i operatora infrastruktury krytycznej państwa, wymieniając ruch o przepustowości przekraczającej 4,5 Tbps pomiędzy setkami operatorów telekomunikacyjnych, platform chmurowych i sieci rządowych. Zadanie wymaga zaplanowania audytu bezpieczeństwa routingu międzysystemowego BGP (Border Gateway Protocol), weryfikacji wdrożenia kryptograficznej autoryzacji tras RPKI (Resource Public Key Infrastructure), audytu wieloterabitowych systemów mitygacji ataków DDoS (BGP Flowspec), szacowania ryzyka w matrycy 5x5 (RTO=0 min dla rdzenia IP), sformułowania ustaleń w modelu 4C oraz przygotowania Planu CAP ze wskaźnikami KPI i Executive Summary dla Zarządu IXP, NASK i CSIRT GOV.

Spółka "Polska Wymiana Ruchu Internetowego IXP S.A." zarządza największym krajowym węzłem wymiany ruchu IP, łączącym 420 operatorów telekomunikacyjnych, dostawców treści (Google, Meta, Netflix, Microsoft) oraz sieci państwowe. Szczytowy transfer przekracza 4,8 Tbps. Spółka eksploatuje 4 niezależne kolokacje w Warszawie, Katowicach i Poznaniu połączone własnym pierścieniem światłowodowym DWDM.

Infrastruktura techniczna i routing międzysystemowy:

• Przełączniki rdzeniowe Ethernet o architekturze Spine-Leaf i przepustowości portów 100G/400G.
• Serwery tras (Route Servers) oparte na demonach BIRD/BGP zarządzające rozgłaszaniem prefiksów IP pomiędzy uczestnikami węzła.
• Wdrożona infrastruktura walidacji pochodzenia tras RPKI (ROA - Route Origin Authorization).

Złożone incydenty i uchybienia ujawnione w audycie zerowym:

• Naruszenie reżimu walidacji RPKI na serwerach tras: Wykryto, że Route Serwery w węźle warszawskim akceptowały prefiksy o statusie RPKI "Invalid" (błędne lub sfałszowane rozgłoszenie AS), ponieważ w konfiguracji demona BIRD wyłączono regułę odrzucania (Reject Invalid) po skargach mniejszego operatora, który błędnie skonfigurował swoje rekordy ROA. Stworzyło to możliwość ataku BGP Hijacking i podsłuchiwania lub przekierowania ruchu rządowego przez obcy podmiot.
• Podatność systemu mitygacji ataków DDoS: W trakcie ostatniego zmasowanego ataku DDoS (o wolumenie 1,8 Tbps z wykorzystaniem wzmocnienia DNS Amplification) automatyczny mechanizm BGP Flowspec spowodował błędne zablokowanie całego ruchu do serwerów państwowego rejestru domen .pl na 26 minut (błąd reguły filtracji w filtrze warstwy 4).
• Bezpieczeństwo fizyczne i zasilanie węzła kolokacyjnego: W jednym z węzłów zapasowych w Katowicach system klimatyzacji precyzyjnej nie posiadał zasilania awaryjnego z agregatu (podłączony był jedynie do zasilacza UPS), co groziło przegrzaniem przełączników 400G w ciągu 20 minut od awarii sieci miejskiej.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert Cyberodporności Telekomunikacyjnej): Koordynuje audyt, współpracuje z Zarządem IXP, Pełnomocnikiem ds. Cyberbezpieczeństwa w NASK i CSIRT GOV, przygotowuje Executive Summary.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt konfiguracji BGP Route Serverów (BIRD), walidacji RPKI, reguł BGP Flowspec, przełączników Spine-Leaf, łącz DWDM i systemów anty-DDoS.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla scenariusza ataku BGP Hijacking i paraliżu Internetu, parametry BCM (RTO=0 min, RPO=0 min), formułuje kartę 4C dla błędu RPKI i konstruuje Plan CAP z KPI.

• Krok 2 (Wyznaczenie zakresu i bezwzględnych ograniczeń technicznych):

Zakres: 4 węzły kolokacyjne (Warszawa, Katowice, Poznań), Route Serwery, przełączniki 100G/400G, trakt DWDM, systemy zasilania i chłodzenia.

Ograniczenia: Bezwzględny zakaz restartowania procesów BGP na produkcyjnych Route Serwerach w godzinach szczytu telekomunikacyjnego (08:00-24:00); weryfikacja wyłącznie na serwerach zapasowych lub w trybie pasywnej analizy konfiguracji i logów.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Dyrektywa NIS2 (podmiot kluczowy infrastruktury cyfrowej), Ustawa - Prawo komunikacji elektronicznej, Norma PN-EN ISO/IEC 27001:2022, Norma ISO/IEC 27011:2024 (zabezpieczenia w telekomunikacji), Wytyczne MANRS (Mutually Agreed Norms for Routing Security) dla IXP, RFC 6811 i RFC 8210 (RPKI).

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Przechwycenie ruchu bankowego i rządowego przez atak BGP Hijacking wskutek akceptacji prefiksów RPKI Invalid. P=4, S=5 (Katastrofalny - masowy podsłuch ruchu cyfrowego państwa, paraliż usług zaufania). Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Bezwzględne wymuszenie filtrowania RPKI Drop Invalid na wszystkich Route Serwerach zgodnie z wytycznymi MANRS. Ryzyko rezydualne: P=1, S=2 (2/25 - Akceptowalne).
  • Zagrożenie 2: Paraliż węzła przez atak terabitowy DDoS wskutek błędnych reguł BGP Flowspec. P=4, S=5. Ryzyko inherentne: 20/25. Kontrole: Wdrożenie zautomatyzowanego systemu inspekcji reguł Flowspec w piaskownicy (Canary Testing) przed propagacją do sieci. Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Przegrzanie i wyłączenie przełączników 400G w węźle Katowice przy awarii zasilania miejskiego. P=3, S=4. Ryzyko inherentne: 12/25. Kontrole: Podłączenie klimatyzacji precyzyjnej do automatyki SZR agregatu prądotwórczego. Ryzyko rezydualne: 1/25.

Parametry BCM: RTO = 0 min dla szkieletu routingu (przełączenie tras < 50 ms), RPO = 0 min, MTPD = 15 min.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla akceptowania prefiksów BGP RPKI Invalid na Route Serwerach.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Natychmiastowe przywrócenie polityki Drop Invalid dla RPKI (0-7 dni), modyfikacja procedur BGP Flowspec i podłączenie klimatyzacji do agregatu (30 dni), pełna certyfikacja zgodności z MANRS i ISO 27011 (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległe badanie konfiguracji BGP/RPKI, infrastruktury fizycznej i systemów anty-DDoS.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Zarządu IXP i NASK (3 min): Zagrożenia bezpieczeństwa routingu państwowego, ekspozycja na ataki BGP Hijacking, budżet CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=0 / RPO=0) (4 min): Uzasadnienie krytyczności stabilności BGP w skali kraju (BCM Auditor).
• Dekonstrukcja wektorów technicznych (BGP, RPKI ROA, BIRD, Flowspec, DDoS) (4 min): Przedstawienie dowodów wyłączenia filtrowania RPKI (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Analiza 5 Why i plan wdrożenia standardu MANRS (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania Zarządu o ryzyko niezadowolenia małych operatorów po zablokowaniu błędnych prefiksów (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Zarządu IXP i NASK (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W strategicznym węźle wymiany ruchu internetowego wykryto krytyczną lukę: wyłączenie automatycznego odrzucania błędnych i sfałszowanych tras BGP (brak wymuszenia RPKI Drop Invalid), co otwiera krajowy Internet na ataki BGP Hijacking obcych wywiadów. Poziom ryzyka wynosi 20/25. Rekomendacja: Natychmiastowe przywrócenie filtracji RPKI, testowanie reguł Flowspec w piaskownicy oraz podłączenie klimatyzacji węzła w Katowicach do zasilania awaryjnego (inwestycja CAP: 260 tys. PLN).

B. Zaawansowany Plan Audytu ISMS w Polska Wymiana Ruchu Internetowego IXP:

• Zleceniodawca: Zarząd IXP w porozumieniu z CSIRT NASK. Zakres: Węzły kolokacyjne (Warszawa, Katowice, Poznań), Route Serwery BIRD, klastry DWDM, systemy BGP Flowspec.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (BGP Hijacking przez brak RPKI Drop): IR = 4 x 5 = 20/25. Kontrole: MANRS, RPKI Drop Invalid, monitoring ROA. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Błąd reguły Flowspec przy ataku DDoS): IR = 4 x 5 = 20/25. Kontrole: Canary Testing, walidacja reguł L4, telemetria sFlow. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Awaria chłodzenia węzła Katowice): IR = 3 x 4 = 12/25. Kontrole: Automatyka SZR dla klimatyzacji, agregat diesel. RR = 1 x 1 = 1/25.
  • Parametry BCM: RTO = 0 min, RPO = 0 min, MTPD = 15 min.
• Karta Ustalenia w modelu 4C dla Wyłączenia Filtracji RPKI na Route Serwerach:
  • Condition (Stan faktyczny): Na Route Serwerach węzła warszawskiego reguła odrzucania tras oznaczonych jako RPKI Invalid została zakomentowana w pliku konfiguracyjnym demona BIRD, co pozwalało na rozgłaszanie nieautoryzowanych prefiksów IP do wszystkich 420 uczestników węzła.
  • Criteria (Kryteria): Standard RFC 6811 i RFC 8210; Wytyczne MANRS dla IXP (Działanie 1: Filtrowanie routingu); Norma ISO/IEC 27011:2024 punkt 8.20; Dyrektywa NIS2 art. 21 ust. 2 lit. c.
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego zakomentowano regułę? -> Bo lokalny dostawca usług zgłosił awarię rozgłaszania swoich adresów IP.

Dlaczego zgłosił awarię? -> Bo sam błędnie wygenerował rekord ROA w rejestrze RIPE NCC.

Dlaczego inżynier IXP wyłączył filtrowanie dla wszystkich zamiast pomóc operatorowi? -> Bo procedury operacyjne wsparcia (NOC) dopuszczały szybkie obejścia konfiguracji w celu zamknięcia zgłoszenia serwisowego.

Dlaczego brakowało nadzoru nad zmianami konfiguracji BGP? -> Brak procedury Peer-Review i testów regresyjnych dla zmian w plikach konfiguracyjnych serwerów tras.

Przyczyna źródłowa (Root Cause): Brak zintegrowanego procesu Change Management dla krytycznych serwerów routingu międzysystemowego oraz przedkładanie wygody pojedynczych uczestników nad globalne bezpieczeństwo cybernetyczne węzła.

• Consequence (Skutki): Ryzyko przejęcia ruchu banków, instytucji rządowych i szpitali przez wrogie podmioty; ryzyko blackoutu informacyjnego w skali kraju; odpowiedzialność regulacyjna OIK i utrata reputacji międzynarodowej.

C. Analiza zalet, wad i kosztów:

• Zalety: Zabezpieczenie rdzenia polskiego Internetu przed atakami BGP Hijacking; pełna zgodność z międzynarodowymi normami MANRS i Dyrektywą NIS2; podniesienie odporności infrastruktury krytycznej państwa.
• Wady: Koszt 260 tys. PLN na automatykę zasilania i narzędzia GitOps; konieczność rygorystycznej edukacji mniejszych operatorów telekomunikacyjnych w zakresie poprawnej konfiguracji rekordów ROA.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - infrastruktura cyfrowa (IXP, DNS, TLD).
• Ustawa z dnia 12 lipca 2024 r. - Prawo komunikacji elektronicznej (Dz.U. z 2024 r. poz. 1221).
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma ISO/IEC 27011:2024 - Information technology - Security techniques - Information security controls based on ISO/IEC 27002 for telecommunications organizations.
• Internet Society / MANRS: "MANRS IXP Programme - Mutually Agreed Norms for Routing Security", 2023.
• IETF RFC 6811: "BGP Prefix Origin Validation" oraz RFC 8210: "The Resource Public Key Infrastructure (RPKI) to Router Protocol".

• U1 Student umie zaplanować zaawansowany audyt ISMS i cyberodporności węzła wymiany ruchu internetowego i operatora Tier-1.
• U2 Student stosuje model 4C do formułowania uchybień w routingu międzysystemowym BGP i walidacji RPKI.
• U3 Student wykonuje analizę ryzyka paraliżu Internetu w matrycy 5x5 i wyznacza wskaźniki BCM RTO=0.
• U4 Student przygotowuje Plan CAP z KPI oraz Executive Summary dla organów nadzorczych cyberbezpieczeństwa.
• W1W2W3 Student wykazuje ekspercką wiedzę z zakresu protokołów telekomunikacyjnych BGP/RPKI, normy ISO 27011 i dyrektywy NIS2.
• K1K2K3 Student demonstruje najwyższy poziom odpowiedzialności za stabilność cyfrową państwa.

• U1 Opracowanie zaawansowanego planu audytu ISMS dla zautomatyzowanego zakładu biotechnologicznego i produkcji leków.
• U2 Dokumentowanie uchybień w integralności danych farmaceutycznych w modelu 4C z analizą przyczyn źródłowych (5 Why).
• U3 Przeprowadzenie analizy ryzyka sabotażu procesu fermentacji biologicznej w matrycy 5x5 oraz parametry BCM.
• U4 Opracowanie Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz Executive Summary dla organów inspekcji farmaceutycznej.
• W1 Ochrona tajemnicy receptur lekowych, danych pacjentów w badaniach oraz rygorów Prawa farmaceutycznego.
• W2W3 Wymogi FDA 21 CFR Part 11, EU GMP Annex 11, wytyczne GAMP 5, ISO/IEC 27001:2022 i Dyrektywa NIS2.
• K1K2K3 Bezwzględne poszanowanie reżimu sanitarnego i technologicznego, etyka zawodowa i ochrona życia pacjentów.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole integralności danych i SCADA), Wyk4 (NIS2 i prawo sektorowe), Wyk5 (Risk-based audit), Wyk7 (Model 4C i CAP).

Celem zadania na ocenę 5.0 jest opracowanie zintegrowanego, wysoce wyspecjalizowanego planu audytu ISMS w wielozakładowym koncernie biofarmaceutycznym produkującym leki biologiczne, przeciwciała monoklonalne i szczepionki. Zadanie wymaga unikalnego połączenia wymagań normy ISO/IEC 27001:2022 z rygorystycznymi regulacjami walidacji systemów skomputeryzowanych amerykańskiej Agencji ds. Żywności i Leków (FDA 21 CFR Part 11), wytycznymi Dobrej Praktyki Wytwarzania (EU GMP Annex 11), zasadami integralności danych badawczo-produkcyjnych (zasada ALCOA+) oraz normami bezpieczeństwa automatyki przemysłowej (SCADA/DCS w strefach czystych Cleanroom klasy A/B). Zadanie obejmuje szacowanie ryzyka skażenia partii leków w matrycy 5x5 (RTO=0 min dla procesów hodowli komórkowej), sformułowanie ustaleń w modelu 4C oraz przygotowanie Planu CAP ze wskaźnikami KPI i Executive Summary dla Zarządu i Głównego Inspektora Farmaceutycznego (GIF).

Koncern "Biogenix Pharma Poland Sp. z o.o." produkuje w zakładzie pod Warszawą szczepionki przeciwwirusowe oraz rekombinowane białka terapeutyczne dla odbiorców w Europie i USA. Zakład zatrudnia 850 pracowników i posiada akredytację GIF oraz amerykańskiej FDA.

Infrastruktura techniczna i automatyka procesowa:

• System Sterowania Procesem Rozproszonym (DCS / Emerson DeltaV): Nadzoruje pracę 24 bioreaktorów o pojemności 2 000 litrów każdy, kontrolując temperaturę, pH, natlenienie i stężenie glukozy w hodowlach komórek ssaczych.
• System Zarządzania Informacją Laboratoryjną (LIMS): Zintegrowany ze spektrometrami masowymi i chromatografami cieczowymi (HPLC) w laboratoriach kontroli jakości (QC).

Złożone incydenty i uchybienia ujawnione w audycie zerowym:

• Naruszenie ścieżki audytowej (Audit Trail) w systemie DCS bioreaktorów: Wykryto, że funkcja śledzenia zmian (Audit Trail) w oprogramowaniu sterującym bioreaktorami została wyłączona przez operatorów podczas weekendowej awarii czujnika temperatury, co uniemożliwia weryfikację, kto i kiedy dokonał korekty parametrów procesu (rażące naruszenie FDA 21 CFR Part 11 i zasady ALCOA+ Attributable/Legible).
• Dostęp uprzywilejowany w laboratoriach QC: Analitycy w laboratorium kontroli jakości logowali się do stacji roboczych podłączonych do chromatografów HPLC na wspólne konto "lab_analyst_1" z uprawnieniami do kasowania nieudanych prób analitycznych przed ich oficjalnym zapisaniem w systemie LIMS (praktyka tzw. Test-into-Compliance / ukrywanie prób niespełniających norm czystości leku).
• Naruszenie separacji strefy cleanroom: Sterowniki PLC zautomatyzowanego systemu wentylacji i różnicy ciśnień w strefach czystych (HVAC) były połączone z siecią biurową IT bez zapory ogniowej, co w przypadku infekcji ransomware groziło odwróceniem kierunku przepływu powietrza i biologicznym skażeniem partii leku.

• Krok 1 (Podział ról w Triadzie Audytorskiej):

Rola A (Lead Auditor / Ekspert Zgodności Farmaceutycznej GxP): Koordynuje audyt, współpracuje z Prezesem Zakładu, Osobą Wykwalifikowaną (Qualified Person), inspektorami GIF i FDA, przygotowuje Executive Summary.

Rola B (Technical SecOps Auditor): Planuje techniczny audyt systemów DCS DeltaV, chromatografów HPLC, ścieżek Audit Trail, podpisów elektronicznych, separacji sieci HVAC i ochrony kryptograficznej danych LIMS.

Rola C (BCM & Compliance Auditor): Opracowuje matrycę ryzyka 5x5 dla skażenia partii leków, audyt integralności danych ALCOA+ i walidacji GAMP 5, formułuje kartę 4C dla wyłączenia Audit Trail i konstruuje Plan CAP z KPI.

• Krok 2 (Wyznaczenie zakresu i bezwzględnych rygorów sanitarnych):

Zakres: Hale bioreaktorów, strefy czyste Cleanroom A/B, laboratoria QC, system DCS DeltaV, system LIMS, serwerownia centralna.

Rygory sanitarne: Czynności audytowe w strefie cleanroom wymagają sterylnego ubioru barierowego, dekontaminacji sprzętu pomiarowego oraz asysty Osoby Wykwalifikowanej; bezwzględny zakaz wstrzymywania pracy bioreaktorów w trakcie cyklu produkcyjnego.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: FDA 21 CFR Part 11 (Electronic Records; Electronic Signatures), Rozporządzenie Ministra Zdrowia w sprawie Dobrej Praktyki Wytwarzania (EU GMP Annex 11 Computerised Systems), Wytyczne ISPE GAMP 5, Norma PN-EN ISO/IEC 27001:2022 (A.8.15, A.8.18, A.8.20), Dyrektywa NIS2 (podmiot kluczowy).

• Krok 4 (Szacowanie ryzyka w matrycy 5x5):
  • Zagrożenie 1: Niewykryta zmiana parametrów sterylizacji bioreaktora wskutek wyłączenia Audit Trail i wprowadzenie do obrotu skażonej partii szczepionki. P=3, S=5 (Katastrofalny - zgony pacjentów, cofnięcie licencji produkcyjnej, odpowiedzialność karna zarządu). Ryzyko inherentne: 15/25 (Wysokie). Kontrole: Trwałe, sprzętowe zablokowanie możliwości wyłączenia Audit Trail w DCS, automatyczny eksport ścieżek audytowych do nienaruszalnego repozytorium WORM. Ryzyko rezydualne: P=1, S=2 (2/25 - Akceptowalne).
  • Zagrożenie 2: Kasowanie nieudanych wyników badań czystości leku na chromatografach HPLC (konta wspólne). P=4, S=5. Ryzyko inherentne: 20/25 (Strefa Krytyczna). Kontrole: Wdrożenie unikalnych kont imiennych zintegrowanych z kartami RFID, zablokowanie uprawnień do usuwania plików pomiarowych surowych (Raw Data). Ryzyko rezydualne: P=1, S=2 (2/25).
  • Zagrożenie 3: Zatrzymanie lub odwrócenie ciśnień w strefie HVAC przez atak ransomware z sieci biurowej. P=3, S=5. Ryzyko inherentne: 15/25. Kontrole: Wdrożenie przemysłowej zapory sieciowej i izolacja sieci HVAC w strefie OT Level 2 wg Purdue. Ryzyko rezydualne: 1/25.

Parametry BCM: RTO = 0 min dla systemów kontroli parametrów krytycznych CPP w bioreaktorach (brak możliwości przerwania zasilania hodowli komórkowej), RPO = 0 min, MTPD = 2h.

• Krok 5 (Karta Ustalenia w modelu 4C):

Opracowanie karty 4C dla możliwości wyłączenia i modyfikacji ścieżek audytowych (Audit Trail) w systemie DCS bioreaktorów.

• Krok 6 (Plan CAP ze wskaźnikami KPI):

Działania: Zablokowanie uprawnień wyłączania Audit Trail i natychmiastowa wymiana haseł na chromatografach (0-7 dni), wdrożenie kart RFID w laboratoriach i separacja sieci HVAC (30 dni), pełna re-walidacja skomputeryzowanych systemów laboratoryjnych wg GAMP 5 (90 dni).

• Krok 7 (Wielostrumieniowy harmonogram 4-dniowy):

Równoległe badanie systemu DCS w cleanroomach, laboratoriów kontroli jakości i walidacji GAMP 5.

Układ 15-minutowego wystąpienia seminaryjnego:

• Executive Summary dla Zarządu i Osoby Wykwalifikowanej (3 min): Zagrożenia wstrzymaniem dystrybucji leków przez FDA/GIF, naruszenia zasad integralności danych ALCOA+, budżet CAP (Lead Auditor).
• Matryca ryzyka 5x5 i parametry BCM (RTO=0 / RPO=0) (4 min): Uzasadnienie krytyczności ciągłości parametrów procesu biologicznego w bioreaktorach (BCM Auditor).
• Dekonstrukcja wektorów technicznych (Audit Trail, Part 11, GAMP 5, DCS DeltaV, HPLC) (4 min): Przedstawienie dowodów kasowania prób analitycznych (Technical SecOps Auditor).
• Karta 4C i Plan CAP ze wskaźnikami KPI (3 min): Analiza 5 Why i harmonogram dostosowania zakładu do re-inspekcji FDA (Lead i BCM Auditor).
• Symulacja spotkania zamykającego i obrona ustaleń (1 min): Odpowiedzi na pytania Dyrektora Produkcji o minimalizację przestojów przy re-walidacji systemów (cały zespół).

Raport seminaryjny (10-14 stron maszynopisu) musi obejmować:

A. Executive Summary dla Zarządu i Osoby Wykwalifikowanej (Pitch to Board - 1 strona A4):

• Kluczowy komunikat: W procesie wytwarzania leków biologicznych i kontroli jakości wykryto rażące uchybienia w integralności danych: możliwość wyłączania ścieżek audytowych (Audit Trail) w bioreaktorach oraz kasowanie nieudanych wyników badań na chromatografach HPLC. Poziom ryzyka regulacyjnego i zdrowotnego wynosi 20/25. Rekomendacja: Natychmiastowe zablokowanie uprawnień administratorskich dla operatorów, wdrożenie repozytorium WORM dla Audit Trails oraz re-walidacja oprogramowania HPLC wg GAMP 5 (inwestycja CAP: 350 tys. EUR).

B. Zaawansowany Plan Audytu ISMS w Biogenix Pharma Poland:

• Zleceniodawca: Zarząd Biogenix Pharma w porozumieniu z Osobą Wykwalifikowaną. Zakres: System DCS Emerson DeltaV, system LIMS, aparatura HPLC, sterowniki HVAC, serwerownia walidowana.
• Matryca szacowania ryzyka (5x5):
  • Zagrożenie 1 (Wyłączenie Audit Trail w bioreaktorze): IR = 3 x 5 = 15/25. Kontrole: Blokada programowa, eksport WORM, alarm w czasie rzeczywistym. RR = 1 x 2 = 2/25.
  • Zagrożenie 2 (Kasowanie wyników prób na HPLC): IR = 4 x 5 = 20/25. Kontrole: Imienne konta RFID, zakaz kasowania Raw Data, nadzór LIMS. RR = 1 x 2 = 2/25.
  • Zagrożenie 3 (Infekcja sieci HVAC ze strefy IT): IR = 3 x 5 = 15/25. Kontrole: Przemysłowy firewall, segmentacja strefy OT. RR = 1 x 1 = 1/25.
  • Parametry BCM: RTO = 0 min dla monitoringu bioreaktorów, RPO = 0 min, MTPD = 2h.
• Karta Ustalenia w modelu 4C dla Wyłączenia Ścieżki Audytowej w Systemie DCS Bioreaktorów:
  • Condition (Stan faktyczny): Funkcja rejestrowania zmian parametrów procesowych (Audit Trail) w systemie DCS DeltaV mogła być wyłączana z poziomu konsoli operatorskiej przez użytkowników o profilu "Shift_Supervisor" bez konieczności zatwierdzenia przez Dział Zapewnienia Jakości (QA).
  • Criteria (Kryteria): FDA 21 CFR Part 11 sekcja 11.10(e); EU GMP Annex 11 punkt 9 (Audit Trails); Norma ISO/IEC 27001:2022 A.8.15; Zasady WHO dotyczące Integralności Danych (ALCOA+).
  • Cause (Przyczyna źródłowa - 5 Why):

Dlaczego operatorzy mogli wyłączyć Audit Trail? -> Bo profil uprawnień kierownika zmiany posiadał pełne prawa konfiguracyjne.

Dlaczego nadano takie prawa? -> Aby inżynierowie mogli szybko rekonfigurować pętle pomiarowe w razie awarii bez wzywania automatyka.

Dlaczego automatyk nie był dostępny na dyżurze? -> Dział Utrzymania Ruchu nie zapewnił wsparcia 24/7 dla systemów walidowanych.

Dlaczego QA nie zablokowało profilu przy walidacji? -> Walidacja komputerowa skupiła się na funkcjonalności chemicznej, a nie na bezpieczeństwie teleinformatycznym.

Przyczyna źródłowa (Root Cause): Brak integracji procedur Dobrej Praktyki Wytwarzania (GMP) z normą ISO/IEC 27001 oraz brak zasady najmniejszych uprawnień (Least Privilege) w systemach automatyki procesowej.

• Consequence (Skutki): Brak możliwości udowodnienia przed FDA i GIF nienaruszalności parametrów sterylizacji i temperatury hodowli komórek; ryzyko natychmiastowego wstrzymania dystrybucji leków (Warning Letter / Import Alert); wycofanie serii leków o wartości kilkudziesięciu milionów euro z rynku globalnego.

C. Analiza zalet, wad i kosztów:

• Zalety: Wyeliminowanie ryzyka zablokowania eksportu leków przez FDA i GIF; zagwarantowanie najwyższego bezpieczeństwa biologicznego wytwarzanych szczepionek; integracja ładu ISO 27001 z rygorami farmaceutycznymi GMP.
• Wady: Koszt 350 tys. EUR na re-walidację systemów i licencje bezpiecznego LIMS; konieczność rygorystycznego zdyscyplinowania personelu laboratoryjnego.

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 pokazują przejście od ryzyka inherentnego (IR) przed kontrolami do ryzyka rezydualnego (RR) po wdrożeniu mitygacji.

Karty ryzyka (P x S) dla kluczowych wektorów zagrożeń:

Realne działania naprawcze w horyzontach 0-7 dni, 30 dni i 90 dni, z właścicielami, miermymi wskaźnikami KPI oraz weryfikacją spadku ryzyka z poziomu IR do RR.

A – Accountable (zatwierdza i odpowiada za efekt), R – Responsible (wykonuje), C – Consulted (opiniuje przed decyzją), I – Informed (informowany o postępie).

• U.S. Food and Drug Administration (FDA): "Title 21 Code of Federal Regulations Part 11: Electronic Records; Electronic Signatures", Waszyngton.
• EudraLex - Volume 4 - Good Manufacturing Practice (GMP) Guidelines: "Annex 11: Computerised Systems", Komisja Europejska, Bruksela.
• International Society for Pharmaceutical Engineering (ISPE): "GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems", 2nd Edition, 2022.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• World Health Organization (WHO): "Guideline on Data Integrity", WHO Technical Report Series No. 1033, Genewa.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor farmaceutyczny jako podmiot kluczowy.

• U1 Student umie zaplanować zaawansowany audyt ISMS w zautomatyzowanym zakładzie biofarmaceutycznym.
• U2 Student stosuje kanoniczny model 4C do formułowania uchybień w integralności danych ALCOA+ i Audit Trail.
• U3 Student wykonuje analizę ryzyka biologicznego i regulacyjnego w matrycy 5x5 z parametrami BCM.
• U4 Student przygotowuje Plan CAP ze wskaźnikami KPI oraz Executive Summary dla organów inspekcji farmaceutycznej (GIF/FDA).
• W1W2W3 Student wykazuje ekspercką wiedzę o standardach FDA 21 CFR Part 11, EU GMP Annex 11, GAMP 5 i ISO 27001.
• K1K2K3 Student demonstruje najwyższą odpowiedzialność za bezpieczeństwo i zdrowie pacjentów na całym świecie.