Laboratorium 3

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów umiejętności przeprowadzania pogłębionej, wieloaspektowej analizy Polityki Bezpieczeństwa Informacji w dużym podmiocie leczniczym o statusie podmiotu kluczowego w rozumieniu dyrektywy NIS2 i ustawy o KSC. Zadanie wymaga identyfikacji luk w regulacjach dotyczących integracji systemów szpitalnych z algorytmami sztucznej inteligencji (AI w analizie tomografii i histopatologii), ochrony telemetrii aparatury podtrzymującej życie (IoMT), przeprowadzenia ilościowo-jakościowej analizy ryzyka w matrycy 3x3 dla zidentyfikowanych luk, sformalizowanej kwalifikacji niezgodności (NC1/NC2/OFI) oraz opracowania Planu Działań Korygujących (CAP) z wykorzystaniem metody analizy przyczyn źródłowych (Root Cause Analysis - 5 Why).

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalna identyfikacja i formalna gradacja niezgodności (NC1 - Niezgodność Duża, NC2 - Niezgodność Mała, OFI - Szansa na doskonalenie) z precyzyjną referencją do normy ISO/IEC 27001:2022 i aktów prawnych.
• U1 Opracowanie zaawansowanych założeń znowelizowanej polityki bezpieczeństwa oraz specjalistycznej procedury zarządzania systemami sztucznej inteligencji i IoMT.
• U3 Przeprowadzenie analizy ryzyka audytowego z użyciem matrycy prawdopodobieństwa i skutku 3x3 dla luk w dokumentacji, z wyznaczeniem ryzyka inherentnego i rezydualnego.
• U4 Skonstruowanie Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych (metoda 5 Why), wyznaczeniem właścicieli procesów i harmonogramu wdrożenia.
• W1W2W3 Biegła znajomość wymogów dyrektywy NIS2, ustawy o KSC, europejskiego aktu o sztucznej inteligencji (AI Act), RODO (art. 9, 22, 32, 35) oraz norm ISO/IEC 27001:2022, ISO/IEC 27002:2022 i ISO/IEC 42001 (system zarządzania AI).
• K1K2K3 Niezależność osądu audytorskiego, wysoka kultura inżynierska i etyczna oraz świadomość krytycznego wpływu spójności polityki na życie i zdrowie pacjentów.
• Powiązanie z wykładem: Wyk1 (ISMS w ochronie zdrowia), Wyk3 (Kontrole A.5, A.8 ISO 27001), Wyk4 (NIS2 i AI Act w audycie zgodności), Wyk5 (Matrycowa analiza ryzyka ISO 27005), Wyk7 (Metodyka CAP i 5 Why).

Wojewódzki Szpital Zespolony i Centrum Onkologii dysponuje 850 łóżkami, 14 salami operacyjnymi, oddziałami chemioterapii, radioterapii, transplantologii oraz lądowiskiem ratunkowym. Szpital zatrudnia 1 600 pracowników personelu medycznego i administracji, hospitalizując rocznie ponad 55 000 pacjentów. Placówka wdrożyła zaawansowane technologie: chmurowy moduł wspomagania diagnozy nowotworów płuc oparty na głębokich sieciach neuronowych (AI), zintegrowany z systemem PACS, oraz sieć 400 telemetrycznych pomp infuzyjnych i kardiomonitorów podłączonych przez sieć Wi-Fi do systemu wczesnego ostrzegania pielęgniarek.

Stan zastałej dokumentacji polityki bezpieczeństwa:

• W szpitalu funkcjonuje "Zintegrowana Polityka Bezpieczeństwa Informacji WSZ", opracowana w 2020 roku w oparciu o normę ISO/IEC 27001:2013. W dokumentacji brak odzwierciedlenia zmian wynikających z wydania normy ISO/IEC 27001:2022 oraz przepisów dyrektywy NIS2.
• W polityce całkowicie brak regulacji dotyczących bezpiecznego korzystania ze sztucznej inteligencji (brak zasad weryfikacji stronniczości algorytmicznej, brak ochrony danych uczących, brak procedur zatwierdzania zmian modeli AI). Anonimizacja danych obrazowych przesyłanych do chmury dostawcy algorytmu AI jest niepełna (metadane DICOM zawierają ukryty numer PESEL pacjenta).
• Rozdział dotyczący urządzeń medycznych odsyła do instrukcji obsługi producentów i nie zawiera wytycznych z zakresu cyberbezpieczeństwa urządzeń IoMT (brak zasad segmentacji sieci VLAN dla pomp infuzyjnych, brak procedury wycofywania urządzeń z podatnościami ze środowiska operacyjnego). Pompy infuzyjne pracują na domyślnych hasłach fabrycznych.
• Zgłaszanie incydentów cyberbezpieczeństwa opisano jako "obowiązek powiadomienia kierownika działu IT w ciągu 3 dni roboczych", co bezpośrednio narusza art. 23 dyrektywy NIS2 i wymogi ustawy o KSC nakazujące przesłanie wczesnego ostrzeżenia do właściwego CSIRT w ciągu 24 godzin od powzięcia wiedzy o incydencie poważnym.

Komitet Audytu i Bezpieczeństwa przy Urzędzie Marszałkowskim zleca zespołowi audytorów przeprowadzenie zaawansowanego audytu polityki bezpieczeństwa, oszacowanie ryzyka zastałych luk w matrycy 3x3 oraz sporządzenie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na realizacji zaawansowanej procedury audytowej:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Dyrekcją i radcą prawnym szpitala, analizę zgodności z dyrektywą NIS2 i KSC, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Zabezpieczeń Technicznych, AI i IoMT): Analizuje rozdziały techniczne polityki, weryfikuje potoki przesyłu danych DICOM do modeli AI, procedury anonimizacji, segmentację sieci pomp infuzyjnych i kontrole ISO 27002:2022 (A.5.7, A.5.23, A.8.9, A.8.12).

  Student 3 (Audytor Zgodności RODO, Ryzyka i Jakości CAP): Przeprowadza ocenę skutków dla ochrony danych (DPIA dla AI wg art. 35 RODO), klasyfikację niezgodności (NC1/NC2/OFI), prowadzi analizę przyczyn źródłowych metodą 5 Why oraz konstruuje tabelę CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk):

  Oceńcie ryzyka dla 4 kluczowych obszarów luki:

  • Skala prawdopodobieństwa (P): 1 - Niskie (mało prawdopodobne), 2 - Średnie (możliwe w ciągu roku), 3 - Wysokie (bardzo prawdopodobne lub ciągłe).
  • Skala skutku (S): 1 - Niski (zakłócenie bez wpływu na pacjenta), 2 - Średni (opóźnienie leczenia, naruszenie poufności pojedynczych osób), 3 - Wysoki (zagrożenie życia pacjentów, wyciek masowy, paraliż szpitala).
  • Poziom ryzyka (R = P x S): 1-2 (Ryzyko Akceptowalne), 3-4 (Ryzyko Średnie - wymagana kontrola), 6-9 (Ryzyko Krytyczne - natychmiastowe działanie).

  Wyliczcie ryzyko inherentne dla: wycieku danych z metadanych DICOM do AI (P=3, S=3 -> R=9), przejęcia kontroli nad pompami infuzyjnymi przez brak segmentacji (P=2, S=3 -> R=6), braku zgłoszenia incydentu do CSIRT w 24h (P=3, S=2 -> R=6).

• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności zawierające: treść uchybienia, dowód audytowy, powołanie na konkretny punkt normy lub artykuł prawa:

  • NC1 (Niezgodność Duża): Przesyłanie niezaanonimizowanych danych medycznych do komercyjnej chmury AI (naruszenie art. 9 i 32 RODO oraz kontroli A.5.23 ISO/IEC 27001:2022).
  • NC1 (Niezgodność Duża): Niezgodny z prawem termin powiadamiania o incydentach (naruszenie dyrektywy NIS2 i ustawy o KSC).
  • NC2 (Niezgodność Mała): Brak udokumentowanej procedury zarządzania poprawkami i konfiguracją dla urządzeń IoMT (kontrola A.8.9 ISO/IEC 27001:2022).
  • OFI (Szansa na doskonalenie): Brak wdrożenia ram normy ISO/IEC 42001 dotyczącej certyfikacji systemów zarządzania sztuczną inteligencją.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (wyciek danych w metadanych DICOM do chmury AI) przeprowadźcie ciąg 5 Why:

  1. Dlaczego dane osobowe pacjentów trafiły do zewnętrznej chmury dostawcy AI? Bo pliki obrazowe nie zostały pozbawione metadanych w nagłówkach DICOM.

  2. Dlaczego nie usunięto metadanych? Bo w szpitalu nie wdrożono bramki anonimizującej przed wysyłką plików do chmury.

  3. Dlaczego nie wdrożono bramki? Bo w Polityce Bezpieczeństwa nie przewidziano wymogów dla systemów algorytmicznych i przetwarzania chmurowego.

  4. Dlaczego polityka nie zawierała takich wymogów? Bo projekt wdrożenia AI był prowadzony przez zespół lekarzy radiologów z pominięciem Działu Bezpieczeństwa IT i IOD (zjawisko Shadow IT).

  5. Dlaczego dopuszczono do zakupu i wdrożenia AI bez udziału IT i IOD? (PRZYCZYNA ŹRÓDŁOWA): Brak w szpitalu nadrzędnej procedury zarządzania zmianą i zakupami technologii, uzależniającej podpisanie umowy od wcześniejszej oceny bezpieczeństwa i zgodności (Security by Design).

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP zawierającą: Nr niezgodności | Działanie korygujące | Właściciel biznesowy | Mierzalny wskaźnik sukcesu (KPI) | Termin realizacji (14-90 dni).

• Krok 6 (Projekt Nowelizacji Polityki):

  Zredagujcie projekt dokumentu: "Polityka Bezpiecznego Wykorzystania Sztucznej Inteligencji i Urządzeń IoMT w Szpitalu Wojewódzkim".

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i kontekst technologiczny szpitala (3 min): Rola AI w radiologii i telemetrii IoMT, wymogi statusu podmiotu kluczowego wg NIS2 (Student 1).
• Prezentacja wyników analizy polityki i matrycy ryzyka 3x3 (4 min): Zestawienie zidentyfikowanych uchybień, omówienie poziomów ryzyka inherentnego dla danych onkologicznych (Student 2).
• Analiza przyczyn źródłowych (5 Why) i karty niezgodności NC1/NC2/OFI (4 min): Przedstawienie ścieżki dochodzenia do pierwotnej przyczyny uchybień oraz kwalifikacja prawno-normatywna (Student 3).
• Plan Działań Korygujących (CAP) i nowa procedura AI/IoMT (4 min): Szczegółowy harmonogram wdrożenia bramki anonimizującej, segmentacji VLAN i procedury NIS2 24h, wady i zalety (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób standard DICOM przechowuje dane pacjenta i dlaczego powierzchowne usunięcie nazwiska z warstwy graficznej obrazu nie chroni przed identyfikacją pacjenta (zagrożenie ze strony ukrytych tagów metadanych)?
• Jakie bezwzględne rygory nakłada europejski Akt o Sztucznej Inteligencji (AI Act) na systemy AI wysokiego ryzyka (klasa High-Risk AI) w medycynie w zakresie jakości danych i nadzoru ludzkiego (Human Oversight)?
• W jaki sposób zorganizować bezpieczną architekturę telemetrii IoMT (pompy infuzyjne) w oparciu o model Zero Trust i mikro-segmentację sieci (VLAN medyczny z zapaporowaniem i kontrolą 802.1X)?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 (analiza 6 kluczowych wektorów zagrożeń przed i po wdrożeniu zabezpieczeń).
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na poprawę (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla procedury anonimizacji DICOM.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie lokalnej bramki dekontaminacyjnej DICOM z automatycznym czyszczeniem tagów wrażliwych przed transferem do chmury AI (Właściciel: Główny Inżynier Systemów Medycznych, Termin: 30 dni, KPI: 100% plików przetestowanych bez metadanych identyfikujących).
  • Zadanie CAP-2: Izolacja sieci bezprzewodowej dla urządzeń IoMT (VLAN 40) z uwierzytelnianiem certyfikatami WPA3-Enterprise i zmianą haseł technicznych (Właściciel: Kierownik Sekcji Sieci IT, Termin: 21 dni, KPI: zero urządzeń na hasłach domyślnych).
  • Zadanie CAP-3: Wdrożenie nowej procedury eskalacji incydentów NIS2 z systemem automatycznego powiadamiania CSIRT w 24h (Właściciel: CISO Szpitala, Termin: 14 dni, KPI: przeprowadzenie pozytywnego testu łączności z CSIRT).
  • Zadanie CAP-4: Nowelizacja nadrzędnej Polityki Zakupowej i Zarządzania Zmianą (Security by Design dla projektów medycznych) (Właściciel: Dyrektor ds. Ekonomiczno-Eksploatacyjnych, Termin: 60 dni, KPI: zatwierdzenie regulaminu przez Zarząd).
• Projekt procedury: "Załącznik nr 4 do PBI: Bezpieczeństwo Systemów Algorytmicznych i Telemetrii Medycznej".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Wyeliminowanie ryzyka gigantycznych kar za naruszenie RODO i NIS2; ochrona pacjentów przed atakami manipulacji dawkami leków na pompach infuzyjnych; pełna zgodność z normami ISO 27001 i ISO 42001; podniesienie prestiżu szpitala jako bezpiecznego ośrodka innowacji onkologicznych.
• Wady i trudności: Wysoki koszt zakupu wyspecjalizowanych bramek anonimizujących DICOM; konieczność rekonfiguracji kilkuset urządzeń telemetrycznych w trakcie ciągłej pracy oddziałów; ryzyko chwilowego oporu części ordynatorów przed sformalizowanym procesem akceptacji innowacji IT.

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji - Wymagania.
• Norma PN-EN ISO/IEC 27002:2022 - Bezpieczeństwo informacji, cyberbezpieczeństwo i ochrona prywatności - Kontrole bezpieczeństwa.
• Norma ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - art. 21, 23.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 ustanawiające zharmonizowane przepisy dotyczące sztucznej inteligencji (Akt o sztucznej inteligencji - AI Act).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 9, 22, 32, 35.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Ministerstwo Cyfryzacji / CSIRT NASK: "Wytyczne dotyczące zabezpieczenia urządzeń medycznych z interfejsami sieciowymi", Warszawa 2023.

• U2 Student profesjonalnie klasyfikuje uchybienia audytowe w gradacji NC1/NC2/OFI z referencją do przepisów i norm międzynarodowych.
• U1 Student projektuje zaawansowane procedury bezpieczeństwa dla innowacyjnych technologii medycznych (AI, IoMT, chmura).
• U3 Student bezbłędnie przeprowadza matrycową analizę ryzyka 3x3 w ujęciu inherentnym i rezydualnym.
• U4 Student realizuje procedurę Root Cause Analysis (5 Why) i sporządza wykonalny Plan Działań Korygujących (CAP).
• W1W2W3 Student wykazuje dogłębną znajomość norm ISO 27001, ISO 42001, rygorów NIS2, AI Act oraz ochrony wrażliwych danych onkologicznych.
• K1K2K3 Student łączy wysokie kompetencje analityczne z bezkompromisową etyką ochrony życia i zdrowia ludzkiego.

Celem zadania na ocenę 4.0 jest opanowanie umiejętności audytu i krytycznej analizy Polityki Bezpieczeństwa Informacji w scentralizowanym, wielopodmiotowym środowisku samorządowym (Centrum Usług Wspólnych IT - CUW), świadczącym usługi chmury prywatnej, poczty, elektronicznego zarządzania dokumentacją (EZD) oraz kopii zapasowych dla Urzędu Marszałkowskiego oraz 30 podległych jednostek organizacyjnych (szpitale wojewódzkie, teatry, zarząd dróg, biblioteki, parki krajobrazowe). Zadanie wymaga zbadania spójności regulacyjnej między jednostką centralną a podmiotami korzystającymi, oszacowania ryzyka w matrycy 3x3, sformalizowania kart niezgodności NC1/NC2/OFI, przeprowadzenia analizy przyczyn źródłowych (5 Why) oraz skonstruowania Planu CAP.

Regionalne Centrum Usług Wspólnych Informatyki (RCUWI) zostało utworzone jako jednostka budżetowa Samorządu Województwa w celu skonsolidowania infrastruktury IT 30 rozproszonych jednostek marszałkowskich. RCUWI zarządza własnym Centrum Danych w stolicy województwa, połączonym dedykowaną siecią światłowodową WAN z jednostkami. Centrum hostuje centralny system EZD, wojewódzki portal geodezyjny, centralną pocztę elektroniczną (ponad 4 500 kont) oraz magazyn kopii zapasowych o pojemności 800 TB.

Stan zastałej dokumentacji i chaosu organizacyjnego:

• W RCUWI obowiązuje "Polityka Bezpieczeństwa Informacji Centrum Danych RCUWI" uchwalona w 2021 r., natomiast każda z 30 jednostek podległych posiada własną, autonomiczną politykę bezpieczeństwa, często niespójną z regulaminem RCUWI.
• W relacjach prawno-organizacyjnych brakuje precyzyjnych umów powierzenia przetwarzania danych osobowych (DPA wg art. 28 RODO) oraz porozumień SLA definiujących podział odpowiedzialności za bezpieczeństwo (np. kto odpowiada za zarządzanie tożsamością i uprawnieniami użytkowników, kto za wgrywanie łatek bezpieczeństwa, a kto za reagowanie na incydenty).
• W centralnym systemie EZD pracownicy teatrów i bibliotek mają wgląd do metadanych spraw prowadzonych przez Wydział Kontroli i Audytu Urzędu Marszałkowskiego z powodu braku właściwego skonfigurowania ról (RBAC) w polityce centralnej.
• W rozdziale dotyczącym kopii zapasowych polityka RCUWI gwarantuje tworzenie kopii maszyn wirtualnych raz na dobę, ale nie przewiduje procedury testowego odtwarzania danych ani audytu nośników archiwalnych, co narusza par. 20 ust. 2 pkt 9 Rozporządzenia KRI.
• W jednostkach terenowych powszechne jest współdzielenie kont administracyjnych do zarządzania stacjami roboczymi przez lokalnych serwisantów bez imiennej rozliczalności.

Marszałek Województwa, w obliczu zbliżającego się corocznego audytu KRI i kontroli NIK, powołuje zespół audytorów do przeprowadzenia analizy spójności polityk, matrycowej oceny ryzyka i przygotowania Planu CAP.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie wielopodmiotowego ekosystemu IT:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert Administracji Publicznej): Bada formalny ład korporacyjny CUW, porozumienia SLA, zakres odpowiedzialności kierowników jednostek i koordynuje wystąpienie referatowe.

  Student 2 (Audytor Architektury Chmurowej i Bezpieczeństwa IT): Analizuje wielodomenową architekturę Active Directory, separację uprawnień w EZD, procedury tworzenia i weryfikacji kopii zapasowych oraz kontrole A.5.23, A.8.13 i A.8.18 normy ISO/IEC 27001:2022.

  Student 3 (Audytor Prawno-Regulacyjny KRI, RODO i Planu CAP): Weryfikuje spełnienie 20 wymogów par. 20 Rozporządzenia KRI, umowy powierzenia art. 28 RODO, prowadzi analizę 5 Why oraz konstruuje Plan Działań Korygujących. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Konsolidacji IT):

  Oceńcie ryzyka w matrycy 3x3 dla:

  • Ryzyko 1: Brak rozgraniczenia dostępu w systemie EZD (wyciek danych kontrolnych do jednostek kontrolowanych) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Brak testów odzyskiwania danych z centralnego backupu (awaria pamięci masowej paraliżuje 30 jednostek) -> P=2, S=3 -> R=6 (Krytyczne).
  • Ryzyko 3: Nieprecyzyjne umowy powierzenia danych RODO między RCUWI a jednostkami -> P=3, S=2 -> R=6 (Wysokie).
  • Ryzyko 4: Używanie kont współdzielonych przez serwisantów lokalnych -> P=3, S=2 -> R=6 (Wysokie).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności:

  • NC1 (Niezgodność Duża): Brak spełnienia wymogu par. 20 ust. 2 pkt 9 KRI w zakresie regularnego testowania odzyskiwania danych z kopii zapasowych w skali całego województwa.
  • NC1 (Niezgodność Duża): Przetwarzanie danych osobowych milionów mieszkańców w Centrum Danych bez prawnie wiążących umów powierzenia regulujących role administratora i procesora (art. 28 RODO).
  • NC2 (Niezgodność Mała): Brak sformalizowanych zasad wycofywania uprawnień użytkowników w podległych instytucjach kultury i oświaty (kontrola A.5.18 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia centralnego systemu Privileged Access Management (PAM) do nadzoru nad sesjami administratorów.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak podziału uprawnień i wyciek metadanych w EZD) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego pracownicy biblioteki widzieli akta audytowe Urzędu Marszałkowskiego? Bo w centralnym EZD zastosowano domyślną konfigurację płaskiego dostępu dla wszystkich jednostek.

  2. Dlaczego wdrożono płaską konfigurację? Bo RCUWI spieszyło się z migracją i nie zdefiniowało macierzy ról i uprawnień.

  3. Dlaczego nie zdefiniowano macierzy ról? Bo kierownicy jednostek podległych nie przesłali wymagań dotyczących poufności swoich danych.

  4. Dlaczego kierownicy nie przesłali wymagań? Bo nikt ich o to formalnie nie poprosił, a w RCUWI uznano, że "wszyscy pracują w jednym samorządzie".

  5. Dlaczego panowało takie błędne przekonanie? (PRZYCZYNA ŹRÓDŁOWA): Brak nadrzędnego Regulaminu Współpracy Bezpieczeństwa Informacji definiującego RCUWI jako dostawcę usług, a jednostki jako autonomicznych właścicieli aktywów informacyjnych.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Sporządźcie tabelę CAP z terminami 14-90 dni i konkretnymi wskaźnikami KPI.

• Krok 6 (Projekt Nowelizacji Zintegrowanej Polityki Bezpieczeństwa):

  Zredagujcie modelową "Politykę Bezpieczeństwa Świadczenia Usług Wspólnych IT w Samorządzie Wojewódzkim".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Geneza CUW w administracji publicznej - korzyści ekonomiczne a pułapki bezpieczeństwa teleinformatycznego (Student 1).
• Wyniki analizy polityk i matryca ryzyka 3x3 (4 min): Zestawienie 30 niespójnych polityk, luki w EZD i ryzyko paraliżu backupu (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Wskazanie pierwotnej przyczyny braku podziału ról w samorządowej chmurze (Student 3).
• Plan CAP i nowa architektura regulacyjna RCUWI (4 min): Przedstawienie ram porozumień SLA, harmonogramu testów DRP i standaryzacji umów powierzenia (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i diagnoza prawno-organizacyjna:

• Czym różni się status prawny Centrum Usług Wspólnych działającego jako podmiot przetwarzający (procesor) od sytuacji, w której CUW wykonuje zadania w imieniu wspólnego administratora i jakie klauzule umowne są tu obligatoryjne?
• Jakie są rygory par. 20 Rozporządzenia w sprawie Krajowych Ram Interoperacyjności w odniesieniu do zapewnienia bezpieczeństwa w chmurach prywatnych administracji publicznej?
• W jaki sposób zaimplementować model wielodomenowy (Multi-Tenant Architecture) w systemie EZD, aby zagwarantować pełną kryptograficzną i logiczną separację danych pomiędzy niezależnymi jednostkami samorządowymi?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Matryca Ryzyka 3x3 dla 6 zidentyfikowanych zagrożeń w samorządowym centrum danych.
• Karty Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - KRI backup, NC1 - brak umów RODO), 1 Niezgodności Małej (NC2 - procedury uprawnień) oraz 1 OFI (wdrożenie PAM).
• Protokół Analizy Przyczyn Źródłowych metodą 5 Why dla incydentu wglądu do akt audytowych w EZD.
• Plan Działań Korygujących (CAP):
  • Zadanie CAP-1: Rekonfiguracja uprawnień i wdrożenie barier organizacyjnych (Security Scopes) w EZD dla 30 jednostek (Właściciel: Kierownik Sekcji Aplikacji RCUWI, Termin: 21 dni, KPI: audyt dostępu wykazujący 0% uprawnień krzyżowych).
  • Zadanie CAP-2: Przeprowadzenie pełnego testu odtworzenia maszyn wirtualnych i baz danych z centralnego backupu w środowisku testowym (Właściciel: Główny Administrator Systemowy RCUWI, Termin: 30 dni, KPI: zatwierdzony protokół odtworzenia z RTO < 8h).
  • Zadanie CAP-3: Podpisanie jednolitych umów powierzenia przetwarzania danych osobowych oraz porozumień SLA ze wszystkimi 30 jednostkami (Właściciel: Radca Prawny i IOD RCUWI, Termin: 60 dni, KPI: 100% podpisanych umów).
  • Zadanie CAP-4: Wdrożenie centralnego systemu IAM z integracją z kartami kryptograficznymi i likwidacją kont współdzielonych (Właściciel: Koordynator Bezpieczeństwa IT, Termin: 90 dni, KPI: 100% imiennych kont z logowaniem MFA).
• Wzorcowy regulamin: "Standard Bezpieczeństwa Informacji i Zasad Korzystania z Usług Centrum Danych RCUWI".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Pełne uzdrowienie ładu prawnego i zgodność z KRI i RODO; usunięcie ryzyka paraliżu województwa w razie awarii; jasny podział odpowiedzialności między RCUWI a jednostkami; wysoka efektywność kosztowa.
• Wady i trudności: Czasochłonne negocjacje porozumień z 30 dyrektorami jednostek; konieczność przeznaczenia zasobów na cykliczne testy odzyskiwania danych z backupu; opór lokalnych informatyków przed utratą uprawnień administracyjnych.

• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (...) (Dz.U. z 2024 r. poz. 773) - par. 20.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.5.18, A.5.23, A.8.13, A.8.18).
• Norma PN-EN ISO/IEC 27018:2020 - Ochrona danych osobowych (PII) w chmurach publicznych dla podmiotów przetwarzających dane.
• Ustawa z dnia 5 czerwca 1998 r. o samorządzie województwa (Dz.U. z 2024 r. poz. 566).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 28, 29, 32.
• Urząd Ochrony Danych Osobowych: "Centra Usług Wspólnych w samorządach a ochrona danych osobowych", Warszawa 2023.
• Ministerstwo Cyfryzacji: "Podręcznik dobrych praktyk cyberbezpieczeństwa dla jednostek samorządu terytorialnego", Warszawa 2023.

• U2 Student potrafi zdiagnozować niespójności regulacyjne w wielopodmiotowych strukturach samorządowych i zaklasyfikować uchybienia do NC1/NC2/OFI.
• U1 Student projektuje ramy zintegrowanej polityki bezpieczeństwa dla Centrum Usług Wspólnych IT.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla centralizacji zasobów teleinformatycznych.
• U4 Student stosuje metodę 5 Why do wykrycia pierwotnych przyczyn chaosu kompetencyjnego i sporządza plan CAP.
• W1W2W3 Student dogłębnie rozumie wymagania KRI, art. 28 RODO oraz kontroli chmurowych ISO 27001/27018.
• K1K2 Student wykazuje dojrzałość organizacyjną i umiejętność budowania mostów pomiędzy zróżnicowanymi interesariuszami w sektorze publicznym.

Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu zgodności (Compliance & Gap Analysis) Polityki Bezpieczeństwa Informacji w banku spółdzielczym zrzeszonym w ogólnopolskiej grupie bankowej, w obliczu wejścia w życie unijnego Rozporządzenia DORA (UE 2022/2554) oraz rygorów Rekomendacji D i M Komisji Nadzoru Finansowego (KNF). Zadanie wymaga zidentyfikowania luk w obszarze testowania odporności operacyjnej (w tym testów penetracyjnych TLPT), zarządzania ryzykiem podwykonawców IT i dostawców chmury (ICT Third-Party Risk), wyliczenia ryzyka w matrycy 3x3, sformułowania kart niezgodności NC1/NC2/OFI, analizy przyczyn źródłowych (5 Why) oraz zaprojektowania Planu CAP.

Bank Spółdzielczy "Ziemia Mazowiecka" zrzeszony jest w banku zrzeszającym, posiada centralę oraz 14 oddziałów, obsługując 42 000 klientów indywidualnych, rolników oraz małych i średnich przedsiębiorstw. Bank prowadzi bankowość internetową i mobilną, przetwarza depozyty o wartości 650 mln zł oraz portfel kredytowy 480 mln zł. Kluczowy system bankowości centralnej (Core Banking) oraz bankowość mobilna dostarczane są w modelu outsourcingu przez wyspecjalizowanego dostawcę technologii bankowej.

Stan zastałej dokumentacji i wyzwania regulacyjne:

• W banku obowiązuje "Księga Polityki Bezpieczeństwa Informacji i Środowiska Teleinformatycznego", zatwierdzona przez Zarząd w 2019 roku, oparta na Rekomendacji D KNF z 2013 roku. Dokument nie odnosi się do wymogów Rozporządzenia DORA, które od stycznia 2025 r. nakłada jednolite rygory operacyjnej odporności cyfrowej.
• W polityce brakuje strategii cyfrowej odporności operacyjnej (art. 5-7 DORA) oraz formalnych zasad ciągłego uczenia się i testowania systemów ICT. Bank nigdy nie przeprowadził zaawansowanych testów penetracyjnych sterowanych zagrożeniami (TLPT), opierając się jedynie na pobieżnym skanowaniu podatności wykonywanym przez dostawcę oprogramowania.
• Relacje z kluczowym dostawcą oprogramowania bankowego nie spełniają wymogów art. 28-30 DORA: umowa outsourcingowa nie gwarantuje bankowi prawa do przeprowadzenia niezależnego audytu w serwerowni dostawcy, nie określa wskaźników jakościowych SLA dla czasu reakcji na incydent krytyczny oraz całkowicie pomija strategię wyjścia (Exit Strategy).
• W rozdziale dotyczącym zarządzania incydentami widnieje archaiczny zapis o zgłaszaniu awarii do UKNF "w terminie do 14 dni", podczas gdy DORA nakazuje przesłanie powiadomienia wstępnego o poważnym incydencie w ciągu maksymalnie 4 godzin od jego zaklasyfikowania (i nie później niż 24 godziny od wykrycia).
• W oddziałach banku stwierdzono brak procedur bezpiecznego korzystania z poczty elektronicznej (brak ochrony przed spoofingiem domenowym - brak SPF/DKIM/DMARC w trybie reject), co doprowadziło do incydentu próby wyłudzenia kredytu na podstawie sfałszowanego e-maila członka zarządu.

Komisja Audytu Rady Nadzorczej zleca zespołowi audytorów pilną analizę zastałej polityki, oszacowanie ryzyka regulacyjnego w matrycy 3x3 oraz stworzenie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na wszechstronnej analizie zgodności dokumentacji z prawem bankowym i unijnym:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Oficer Ryzyka Bankowego): Analizuje zgodność polityki z DORA (Rozdział II - Zarządzanie ryzykiem ICT) oraz Rekomendacjami D i M KNF, kieruje pracami zespołu i prezentacją.

  Student 2 (Audytor Bezpieczeństwa Systemów Bankowych i Usług Trzecich): Bada umowy outsourcingowe (DORA Rozdział V), analizuje bezpieczeństwo interfejsów API bankowości mobilnej, zabezpieczenia kryptograficzne (HSM) oraz program testów penetracyjnych TLPT (DORA Rozdział IV).

  Student 3 (Audytor Zgodności Incydentowej i Jakości CAP): Analizuje procedury raportowania incydentów do KNF i CSIRT (DORA Rozdział III), przeprowadza analizę przyczyn źródłowych metodą 5 Why, opracowuje karty NC1/NC2/OFI oraz tabelę CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 w Banku Spółdzielczym):

  Wyliczcie ryzyko w matrycy 3x3 dla:

  • Ryzyko 1: Brak strategii wyjścia i praw audytowych wobec dostawcy Core Banking (ryzyko Vendor Lock-in i paraliżu operacyjnego) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Brak raportowania poważnych incydentów do KNF w 4h wg DORA (sankcje finansowe do 10% obrotu i odpowiedzialność Zarządu) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 3: Podatność na spoofing poczty i phishing przez brak DMARC reject -> P=3, S=2 -> R=6 (Wysokie).
  • Ryzyko 4: Brak testów TLPT i poleganie wyłącznie na deklaracjach dostawcy -> P=2, S=3 -> R=6 (Wysokie).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Umowy z kluczowym dostawcą ICT nie spełniają minimalnych wymogów art. 30 Rozporządzenia DORA (brak klauzul audytowych, brak gwarancji dostępności danych przy wypowiedzeniu umowy).
  • NC1 (Niezgodność Duża): Procedura incydentowa banku jest sprzeczna z art. 19 Rozporządzenia DORA (niedotrzymanie 4-godzinnego terminu zgłoszenia incydentu poważnego).
  • NC2 (Niezgodność Mała): Brak udokumentowanego rocznego programu testowania operacyjnej odporności cyfrowej (art. 24 DORA).
  • OFI (Szansa na doskonalenie): Brak wdrożenia mechanizmów wymiany informacji o cyberzagrożeniach z innymi bankami spółdzielczymi w ramach sektorowego SOC (art. 45 DORA).
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak uprawnień audytowych i planu wyjścia w umowie outsourcingowej) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego bank nie ma prawa skontrolować serwerowni dostawcy Core Banking? Bo w aneksie do umowy z 2021 roku wykreślono zapis o prawie do bezpośredniego audytu fizycznego.

  2. Dlaczego wykreślono ten zapis? Bo dostawca oświadczył, że posiada certyfikat ISO 27001 i audyt banku jest zbędny.

  3. Dlaczego Zarząd banku zaakceptował takie tłumaczenie? Bo w banku uznano, że sam certyfikat ISO zwalnia instytucję finansową z własnego nadzoru.

  4. Dlaczego osoby odpowiedzialne w banku nie zweryfikowały wymogów prawnych? Bo w zespole ds. bezpieczeństwa nie było specjalisty znającego przepisy unijne i regulacje DORA.

  5. Dlaczego dopuszczono do braku takich kompetencji? (PRZYCZYNA ŹRÓDŁOWA): Brak w banku sformalizowanego procesu ciągłego monitorowania zmian regulacyjnych i szkoleń dla kadry zarządzającej ryzykiem ICT (brak ładu korporacyjnego wymaganego przez art. 5 DORA).

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z terminami 14-90 dni i twardymi miernikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki Bezpieczeństwa):

  Zredagujcie projekt "Ram Zarządzania Ryzykiem ICT i Cyfrowej Odporności Operacyjnej w Banku Spółdzielczym".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Specyfika bankowości spółdzielczej w dobie Rozporządzenia DORA - zderzenie małej skali zasobów z potężnymi wymogami regulacyjnymi (Student 1).
• Diagnoza polityki i matryca ryzyka 3x3 (4 min): Wyniki audytu umów outsourcingowych, luka w procedurze incydentowej 4h oraz ryzyko spoofingu domenowego (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki przyczynowo-skutkowej i wykazanie iluzoryczności polegania na samym certyfikacie dostawcy (Student 3).
• Plan CAP i nowelizacja ram DORA w banku (4 min): Negocjacje aneksów umownych z dostawcą, wdrożenie DMARC reject i harmonogram testów odporności (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i kontekst prawno-finansowy:

• W jaki sposób Rozporządzenie DORA redefiniuje pojęcie odpowiedzialności organu zarządzającego (Zarządu i Rady Nadzorczej) za cyberbezpieczeństwo w małych instytucjach finansowych?
• Jakie konkretne klauzule muszą znaleźć się w umowach z zewnętrznymi dostawcami usług ICT zgodnie z art. 30 DORA, aby umowa nie została zakwestionowana przez KNF?
• Na czym polegają zaawansowane testy penetracyjne sterowane zagrożeniami (Threat-Led Penetration Testing - TLPT) oparte na metodyce TIBER-EU i jakie są warunki zwolnienia z nich instytucji proporcjonalnie mniejszych?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 wektorów ryzyka operacyjnego i technologicznego banku.
• Zestawienie Kart Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - umowy outsourcingowe, NC1 - raportowanie incydentów w 4h), 1 Niezgodności Małej (NC2 - program testów) oraz 1 OFI (sektorowy SOC).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla błędu w umowie outsourcingu bankowego.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Przygotowanie i wysłanie do dostawcy oprogramowania bankowego projektu Aneksu DORA zawierającego prawo do audytu, SLA i Exit Strategy (Właściciel: Radca Prawny i CISO Banku, Termin: 30 dni, KPI: podpisanie wiążącego aneksu).
  • Zadanie CAP-2: Wdrożenie nowej procedury klasyfikacji i zgłaszania incydentów ICT do UKNF i CSIRT KNF w terminie 4 godzin (Właściciel: Oficer Ryzyka Operacyjnego, Termin: 14 dni, KPI: 100% zgodności formularzy z wytycznymi EBA/DORA).
  • Zadanie CAP-3: Konfiguracja zabezpieczeń domenowych poczty wychodzącej i przychodzącej: wymuszenie SPF, DKIM i polityki DMARC p=reject (Właściciel: Administrator Bezpieczeństwa IT, Termin: 14 dni, KPI: wskaźnik DMARC 100% reject dla fałszywych e-maili).
  • Zadanie CAP-4: Opracowanie 3-letniego Programu Testów Odporności Operacyjnej ICT obejmującego coroczne testy penetracyjne infrastruktury krytycznej (Właściciel: CISO Banku, Termin: 60 dni, KPI: zatwierdzenie programu przez Zarząd).
• Projekt dokumentu: "Zasady Zarządzania Ryzykiem ICT Stron Trzecich u Podmiotu Finansowego (DORA)".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Pełna ochrona banku przed dotkliwymi karami KNF i Europejskich Urzędów Nadzoru; odzyskanie realnej kontroli nad kluczowym dostawcą oprogramowania; eliminacja ryzyka oszustw metodą Business Email Compromise (BEC); ochrona depozytów i zaufania klientów.
• Wady i koszty: Koszty negocjacji prawnych i oporu dostawcy IT dysponującego silną pozycją monopolistyczną na rynku banków spółdzielczych; konieczność podniesienia budżetu na niezależne audyty zewnętrzne i testy penetracyjne.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA).
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.5.19, A.5.20, A.5.21, A.5.22, A.5.29, A.5.30).
• Urząd Komisji Nadzoru Finansowego: "Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach", Warszawa.
• Urząd Komisji Nadzoru Finansowego: "Rekomendacja M dotycząca zarządzania ryzykiem operacyjnym w bankach", Warszawa.
• Europejski Bank Centralny (ECB): "TIBER-EU Framework - How to implement the European framework for Threat Intelligence-based Ethical Red Teaming", 2020.
• Ustawa z dnia 29 sierpnia 1997 r. - Prawo bankowe (Dz.U. z 2023 r. poz. 2488 z późn. zm.).

• U2 Student profesjonalnie klasyfikuje uchybienia regulacyjne w sektorze bankowym w formule kart niezgodności NC1/NC2/OFI.
• U1 Student projektuje ramy polityki cyfrowej odporności operacyjnej i procedury nadzoru nad łańcuchem dostaw ICT.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla kluczowych wektorów operacyjnych instytucji finansowej.
• U4 Student przeprowadza analizę przyczyn źródłowych (5 Why) i konstruuje wykonalny Plan Działań Korygujących (CAP).
• W1W2W3 Student wykazuje ekspercką znajomość Rozporządzenia DORA, Rekomendacji KNF oraz norm ISO 27001 i wytycznych TIBER-EU.
• K1K3 Student działa z najwyższą odpowiedzialnością etyczną, dbając o bezpieczeństwo środków powierzonych przez deponentów.

Celem zadania na ocenę 4.0 jest wykształcenie u studentów umiejętności przeprowadzenia kompleksowej, zaawansowanej analizy Polityki Bezpieczeństwa Informacji i Cyberbezpieczeństwa w strategicznym przedsiębiorstwie sektora energetycznego (Operator Systemu Przesyłowego Gazu), stanowiącym element Infrastruktury Krytycznej Państwa oraz podmiot kluczowy w reżimie dyrektywy NIS2 i ustawy o KSC. Zadanie kładzie nacisk na weryfikację separacji stref bezpieczeństwa wg modelu Purdue i normy PN-EN IEC 62443, audyt procedur zdalnego dostępu serwisowego dla zagranicznych producentów turbin tłoczni gazu, analizę ryzyka paraliżu dostaw surowca w matrycy 3x3, formalną gradację uchybień (NC1/NC2/OFI), dochodzenie przyczyn źródłowych metodą 5 Why oraz konstrukcję Planu CAP.

Operator Gazociągów Przesyłowych zarządza siecią ponad 11 000 km gazociągów wysokiego ciśnienia, 14 strategicznymi tłoczniami gazu, podziemnymi magazynami oraz terminalem LNG. Centralny Krajowy Ośrodek Dyspozycji Gazu (KODG) w Warszawie monitoruje i steruje przepływem gazu w czasie rzeczywistym z wykorzystaniem nadrzędnego systemu SCADA. Tłocznie gazu wyposażone są w sterowniki PLC, systemy zabezpieczeń ESD (Emergency Shutdown) oraz turbiny napędzane silnikami gazowymi.

Stan zastałej dokumentacji i wektory zagrożeń:

• W przedsiębiorstwie obowiązuje "Zintegrowana Polityka Bezpieczeństwa Teleinformatycznego i Ochrony Infrastruktury Krytycznej", zatwierdzona 3 lata temu. W polityce brakuje precyzyjnego podziału na strefy i kanały komunikacyjne (Zones and Conduits) wymaganego przez normę IEC 62443.
• Wbrew zapisom o separacji, z powodu presji na optymalizację kosztów, inżynierowie automatycy zestawili bezpośrednie połączenie sieciowe (bypass bez zapory przemysłowej nowej generacji NGFW) między siecią biurową IT w KODG a poziomem 2/3 modelu Purdue w tłoczniach, aby umożliwić przesyłanie danych telemetrycznych bezpośrednio do arkuszy kalkulacyjnych dyrektorów w centrali.
• Zewnętrzny producent turbin kompresorowych z Niemiec posiada wdrożony stały, niekontrolowany tunel VPN typu site-to-site do sterowników PLC tłoczni bez konieczności każdorazowej autoryzacji sesji przez polskiego dyspozytora i bez logowania ruchu na serwerze skoku (Jump Host).
• W rozdziale dotyczącym zarządzania podatnościami polityka nakazuje instalację poprawek systemowych "niezwłocznie po ich wydaniu przez firmę Microsoft", co na jednej z tłoczni doprowadziło do zablokowania sterowników zaworów bezpieczeństwa i fałszywego odcięcia nitki tranzytowej na 4 godziny.
• Zgłaszanie incydentów w strefie przemysłowej nie zostało zintegrowane z procedurą zgłaszania incydentów krytycznych do właściwego CSIRT poziomu krajowego (CSIRT GOV / CSIRT NASK) w rygorze Ustawy o KSC.

Pełnomocnik Rządu ds. Strategicznej Infrastruktury Energetycznej nakazuje przeprowadzenie rygorystycznego audytu polityki bezpieczeństwa, wyliczenie ryzyk w matrycy 3x3 i sformułowanie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie cyberbezpieczeństwa automatyki przemysłowej:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Oficer Bezpieczeństwa Infrastruktury Krytycznej): Bada formalny ład bezpieczeństwa, zgodność z Ustawą o KSC, Ustawą o ochronie infrastruktury krytycznej i dyrektywą NIS2, kieruje pracami.

  Student 2 (Audytor Automatyki Przemysłowej i Sieci OT): Bada model Purdue, reguły separacji przemysłowego DMZ (iDMZ), bezpieczeństwo protokołów SCADA (Modbus TCP, DNP3, IEC 60870-5-104) oraz kontrole IEC 62443 i ISO 27001 (A.8.20, A.8.22).

  Student 3 (Audytor Ryzyka Przemysłowego, Zgodności i Planu CAP): Wylicza ryzyka w matrycy 3x3 dla ciągłości tłoczenia gazu, klasyfikuje niezgodności NC1/NC2/OFI, prowadzi analizę 5 Why oraz konstruuje Plan CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Infrastruktury Gazowej):

  Oceńcie ryzyka w matrycy 3x3 dla:

  • Ryzyko 1: Bezpośrednie połączenie IT-OT (zainfekowanie stacji roboczej w biurze przenika do sterowników PLC i powoduje zatrzymanie tłoczni) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Niekontrolowany dostęp zdalny zagranicznego serwisu turbin (możliwość sabotażu lub przejęcia kontroli nad zaworami) -> P=2, S=3 -> R=6 (Krytyczne).
  • Ryzyko 3: Niekontrolowane instalowanie łatek w OT bez testów w środowisku symulacyjnym -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 4: Brak procedury natychmiastowego powiadamiania CSIRT GOV o incydencie w infrastrukturze krytycznej -> P=2, S=3 -> R=6 (Krytyczne).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Naruszenie integralności stref modelu Purdue poprzez bypass łączący sieć biurową IT bezpośrednio ze sterownikami OT (naruszenie kontroli A.8.22 ISO 27001 oraz wymogów IEC 62443-3-3).
  • NC1 (Niezgodność Duża): Brak procedury autoryzacji, monitorowania i nagrywania sesji zdalnych podwykonawców zewnętrznych na obiektach infrastruktury krytycznej (naruszenie Ustawy o KSC i art. 21 NIS2).
  • NC2 (Niezgodność Mała): Brak procedury weryfikacji sum kontrolnych i integralności oprogramowania układowego (Firmware) przed wgraniem do sterowników ESD.
  • OFI (Szansa na doskonalenie): Brak wdrożenia pasywnego systemu detekcji anomalii w ruchu przemysłowym (Network Detection and Response - NDR) dedykowanego protokołom SCADA.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (ustanowienie niebezpiecznego połączenia bypass IT-OT) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego istnieje bezpośrednie połączenie kablowe między biurem KODG a sterownikami tłoczni? Bo inżynierowie podłączyli dodatkową kartę sieciową, omijając główną zaporę ogniową.

  2. Dlaczego wykonali takie połączenie? Bo dyrekcja zażądała natychmiastowego generowania raportów o ciśnieniu w arkuszu kalkulacyjnym bez opóźnień.

  3. Dlaczego nie wykorzystano bezpiecznej strefy pośredniej iDMZ i serwera replikującego dane? Bo wdrożenie brokera danych w iDMZ wymagało 4 tygodni procedur i zakupu licencji.

  4. Dlaczego inżynierowie mogli samodzielnie ominąć procedury bezpieczeństwa? Bo w przedsiębiorstwie brakowało systemu wykrywania nieautoryzowanych połączeń w strefie OT.

  5. Dlaczego dopuszczono do braku takiego nadzoru? (PRZYCZYNA ŹRÓDŁOWA): Brak w nadrzędnej polityce nadrzędnego prymatu bezpieczeństwa operacyjnego (Safety & Security) nad doraźnymi wymaganiami raportowymi oraz brak formalnego zakazu dokonywania zmian w architekturze OT bez zatwierdzenia przez Zespół Bezpieczeństwa Przemysłowego.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Sporządźcie tabelę CAP z terminami 7-60 dni i rygorystycznymi wskaźnikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki):

  Zredagujcie projekt "Standardu Cyberbezpieczeństwa Przemysłowych Systemów Sterowania (ICS/SCADA) w Krajowej Sieci Przesyłowej Gazu".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Infrastruktura krytyczna gazownicza w warunkach zagrożeń hybrydowych i wojny za wschodnią granicą (Student 1).
• Architektura modelu Purdue i matryca ryzyka 3x3 (4 min): Wykazanie skrajnego zagrożenia wynikającego z bypassu IT-OT i niekontrolowanego VPN serwisu (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do przyczyn źródłowych i błędu prymatu wygody raportowej nad bezpieczeństwem państwa (Student 3).
• Plan CAP i nowa architektura strefowa IEC 62443 (4 min): Przedstawienie przemysłowej strefy iDMZ, serwerów skoku z MFA i procedury zarządzania zmianami w sterownikach (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i diagnoza inżynierska:

• W jaki sposób zdefiniowane są poziomy 0-5 w modelu Purdue (ANSI/ISA-95) i dlaczego bezpośrednia komunikacja z pominięciem strefy iDMZ (poziom 3.5) stanowi naruszenie elementarnych zasad obrony w głąb (Defense in Depth)?
• Czym różni się zarządzanie poprawkami (Patch Management) w systemach automatyki przemysłowej od środowisk biurowych IT i jak zorganizować proces walidacji poprawek na stanowiskach symulacyjnych (Hardware-in-the-Loop)?
• Jakie rygory proceduralne i techniczne nakłada Ustawa o KSC na operatorów infrastruktury krytycznej w zakresie ciągłego monitorowania sieci i natychmiastowego powiadamiania CSIRT GOV o incydentach krytycznych?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 scenariuszy ataków na magistrale gazowe i tłocznie.
• Karty Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - bypass IT-OT, NC1 - nieautoryzowany dostęp zdalny serwisu), 1 Niezgodności Małej (NC2 - integralność firmware) oraz 1 OFI (wdrożenie NDR dla SCADA).
• Protokół Analizy Przyczyn Źródłowych metodą 5 Why dla incydentu z niebezpiecznym połączeniem sieciowym.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Fizyczny i logiczny demontaż nieautoryzowanego bypassu IT-OT oraz wdrożenie przemysłowego DMZ z jednokierunkową replikacją danych (Data Diode / NGFW) (Właściciel: Główny Inżynier Telekomunikacji i Bezpieczeństwa OT, Termin: 7 dni, KPI: audyt portów wykazujący brak bezpośrednich tras routingu).
  • Zadanie CAP-2: Wdrożenie systemu bezpiecznego dostępu zdalnego z serwerem skoku (Jump Host), MFA z kluczami sprzętowymi FIDO2, zatwierdzaniem każdej sesji przez dyspozytora KODG i nagrywaniem wideo sesji RDP/SSH (Właściciel: Kierownik Sekcji Systemów Dyspozytorskich, Termin: 21 dni, KPI: 100% sesji serwisowych zarejestrowanych i autoryzowanych).
  • Zadanie CAP-3: Zbudowanie laboratoryjnego stanowiska testowego PLC/SCADA do testowania poprawek oprogramowania przed ich wdrożeniem na obiekty tłoczni (Właściciel: Dyrektor Pionu Eksploatacji Sieci, Termin: 60 dni, KPI: wdrożenie procedury zatwierdzania zmian z zerem awarii produkcyjnych).
  • Zadanie CAP-4: Zaktualizowanie nadrzędnej Polityki Cyberbezpieczeństwa i zintegrowanie procedury eskalacji incydentów z dyżurem 24/7 CSIRT GOV (Właściciel: Pełnomocnik ds. Bezpieczeństwa Informacji i Ochrony IK, Termin: 14 dni, KPI: podpisanie porozumienia operacyjnego z CSIRT).
• Wzorcowy regulamin: "Procedura Bezpiecznego Zdalnego Dostępu Serwisowego do Urządzeń Automatyki Przemysłowej i Systemów ESD".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Zabezpieczenie ciągłości dostaw gazu ziemnego dla gospodarki narodowej i ludności; wyeliminowanie ryzyka cyberdywersji o charakterze państwowym; pełna zgodność z normą IEC 62443, NIS2 i ustawą o KSC; pełna rozliczalność prac zagranicznych serwisantów.
• Wady i trudności: Wysoki koszt zakupu przemysłowych diod danych i zapór sieciowych klasy przemysłowej; wydłużenie procedury podejmowania interwencji serwisowych przez zewnętrznych inżynierów w stanach awarii mechanicznej turbin.

• Seria norm PN-EN IEC 62443 - Bezpieczeństwo sieci i systemów do celów sterowania procesami przemysłowymi (w szczególności części 2-1, 2-4, 3-2, 3-3).
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.8.20, A.8.22, A.5.19, A.5.20, A.5.21).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077) - obowiązki podmiotów kluczowych i operatorów IK.
• Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (Dz.U. z 2023 r. poz. 122 z późn. zm.) - ochrona infrastruktury krytycznej.
• Rządowe Centrum Bezpieczeństwa (RCB): "Krajowy Program Ochrony Infrastruktury Krytycznej", Warszawa.
• CSIRT GOV / Agencja Bezpieczeństwa Wewnętrznego: "Zalecenia dotyczące bezpieczeństwa przemysłowych systemów sterowania (ICS)", Warszawa 2023.

• U2 Student bezbłędnie klasyfikuje uchybienia w architekturze sieci przemysłowych w formule kart niezgodności NC1/NC2/OFI.
• U1 Student projektuje zaawansowane reguły polityki cyberbezpieczeństwa OT oparte na modelu Purdue i normie IEC 62443.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla scenariuszy paraliżu infrastruktury krytycznej państwa.
• U4 Student przeprowadza analizę 5 Why dochodząc do przyczyn źródłowych i konstruuje wykonalny Plan Działań Korygujących (CAP).
• W2W3 Student łączy znajomość standardu ISO 27001 z normami bezpieczeństwa przemysłowego IEC 62443 i polskim prawem ochrony infrastruktury krytycznej.
• K1K3 Student cechuje się najwyższą odpowiedzialnością za bezpieczeństwo publiczne i obronność państwa.

Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów umiejętności przeprowadzania pogłębionej analizy Polityki Bezpieczeństwa Informacji w dynamicznie skalującej się spółce technologiczno-logistycznej zarządzającej siecią ponad 12 000 inteligentnych automatów paczkowych (IoT), flotą 4 000 kurierów oraz architekturą chmury hybrydowej. Zadanie koncentruje się na weryfikacji luk w zarządzaniu tożsamością urządzeń brzegowych (Edge IoT), ochronie masowych danych geolokalizacyjnych i numerów telefonów odbiorców przesyłek (RODO), oszacowaniu ryzyka w matrycy 3x3, sformułowaniu kart niezgodności NC1/NC2/OFI, analizie przyczyn źródłowych metodą 5 Why oraz opracowaniu Planu CAP.

Spółka "LogiXpress S.A." jest jednym z liderów polskiego rynku logistyki e-commerce. Obsługuje ponad 25 milionów przesyłek miesięcznie. Ekosystem technologiczny spółki obejmuje: 12 000 automatów paczkowych wyposażonych w przemysłowe komputery jednopłytkowe z systemem Linux, modemy LTE, kamery monitoringu i zamki elektromagnetyczne; aplikację mobilną dla klientów (8 mln aktywnych użytkowników); aplikację kurierską na terminale Android oraz chmurę hybrydową (część transakcyjna w AWS, bazy archiwalne w prywatnym centrum danych).

Stan zastałej dokumentacji i luki bezpieczeństwa:

• W spółce funkcjonuje "Globalna Polityka Bezpieczeństwa LogiXpress", uchwalona w 2021 roku. Dokument był tworzony dla tradycyjnej firmy transportowej i nie uwzględnia wyzwań związanych z cyberbezpieczeństwem urządzeń brzegowych IoT ani mikroserwisów chmurowych.
• W polityce całkowicie brak zasad zarządzania tożsamością maszynową (Machine Identity / PKI dla IoT). Wszystkie 12 000 automatów paczkowych łączy się z centralną chmurą za pośrednictwem wspólnego certyfikatu TLS i jednego klucza API zaszytego na stałe w obrazie systemu operacyjnego maszyn. Kradzież jednego modułu komputerowego z automatu pozwala na wyekstrahowanie klucza i podszycie się pod dowolną maszynę paczkową w kraju.
• Zapisy dotyczące prywatności i RODO nie odzwierciedlają faktu zbierania przez aplikację mobilną danych o dokładnej geolokalizacji użytkowników w tle (zgoda na geolokalizację jest wymuszana jako warunek konieczny do odebrania paczki, co stanowi naruszenie art. 7 ust. 4 RODO o dobrowolności zgody).
• W rozdziale dotyczącym zarządzania podatnościami brak jest procedury bezpiecznej aktualizacji oprogramowania układowego przez sieć komórkową (Firmware Over-The-Air - FOTA). Aktualizacje automatów wysyłane są nieszyfrowanym protokołem HTTP bez weryfikacji podpisu cyfrowego producenta, co umożliwia atakującym wstrzyknięcie złośliwego kodu (Man-in-the-Middle) na maszynę paczkową.
• Zgłaszanie naruszeń ochrony danych osobowych do UODO nie posiada formalnego SLA ani procedury szacowania ryzyka naruszenia praw i wolności osób fizycznych wg wytycznych Europejskiej Rady Ochrony Danych (EROD).

Rada Nadzorcza LogiXpress, w związku z planowanym wejściem spółki na giełdę, powołuje zespół audytorów do przeprowadzenia analizy polityki, wyliczenia ryzyk w matrycy 3x3 i sformułowania Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie ekosystemu IoT i chmury:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Architekt Bezpieczeństwa Biznesowego): Bada ład korporacyjny spółki, spójność strategii biznesowej z polityką bezpieczeństwa i kieruje pracami.

  Student 2 (Audytor Architektury IoT i Bezpieczeństwa Chmurowego): Bada infrastrukturę automatów paczkowych, procesy aktualizacji FOTA, tożsamość maszynową (PKI/mTLS), bezpieczeństwo aplikacji mobilnej i chmury AWS (kontrole A.8.1, A.8.5, A.8.24 ISO 27001).

  Student 3 (Audytor Zgodności RODO, Analizy Ryzyka i Jakości CAP): Bada legalność profilowania geolokalizacyjnego (art. 6 i 7 RODO), wylicza ryzyka w matrycy 3x3, przeprowadza dochodzenie 5 Why oraz konstruuje Plan Działań Korygujących. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Ekosystemu IoT LogiXpress):

  Wyliczcie ryzyko w matrycy 3x3 dla:

  • Ryzyko 1: Używanie wspólnego klucza API we wszystkich automatach (kompromitacja jednego urządzenia otwiera dostęp do całej sieci) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Brak podpisu cyfrowego i szyfrowania w aktualizacjach FOTA (możliwość masowego przejęcia automatów i sabotażu otwierania skrytek) -> P=2, S=3 -> R=6 (Krytyczne).
  • Ryzyko 3: Wymuszanie zgody na geolokalizację w aplikacji mobilnej (ryzyko kary UODO do 4% globalnego obrotu za naruszenie RODO) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 4: Brak monitorowania integralności systemu operacyjnego automatów paczkowych w terenie -> P=3, S=2 -> R=6 (Wysokie).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Współdzielenie pojedynczego uwierzytelnienia maszynowego przez 12 000 urządzeń IoT (naruszenie kontroli A.5.15 i A.8.5 normy ISO/IEC 27001:2022 oraz zasady rozliczalności).
  • NC1 (Niezgodność Duża): Naruszenie art. 7 ust. 4 RODO poprzez uzależnienie wykonania usługi doręczenia paczki od wyrażenia zgody na śledzenie geolokalizacji użytkownika.
  • NC2 (Niezgodność Mała): Brak szyfrowania i weryfikacji podpisu kryptograficznego pakietów aktualizacji oprogramowania układowego (FOTA).
  • OFI (Szansa na doskonalenie): Brak wdrożenia układów TPM (Trusted Platform Module) w nowo zamawianych modułach komputerowych automatów paczkowych.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (wspólny klucz API w obrazie systemu wszystkich maszyn) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego we wszystkich automatach paczkowych wgrano ten sam klucz API i certyfikat? Bo dział produkcji klonował identyczny obraz dysku na każdą maszynę schodzącą z taśmy montażowej.

  2. Dlaczego klonowano identyczny obraz? Bo zautomatyzowane generowanie unikalnych certyfikatów dla każdej maszyny opóźniało proces produkcji o 15 minut na maszynę.

  3. Dlaczego priorytetem było tempo montażu, a nie bezpieczeństwo? Bo dyrekcja wyznaczyła premie za osiągnięcie liczby 10 000 automatów przed końcem roku.

  4. Dlaczego zespół ds. bezpieczeństwa nie zawetował takiego sposobu wdrażania maszyn? Bo zespół bezpieczeństwa nie uczestniczył w odbiorach fabrycznych automatów i dowiedział się o architekturze po fakcie.

  5. Dlaczego dopuszczono do wykluczenia bezpieczeństwa z fazy produkcyjnej? (PRZYCZYNA ŹRÓDŁOWA): Brak w przedsiębiorstwie Polityki Bezpieczeństwa Urządzeń IoT i Zasad Security by Design w łańcuchu produkcyjnym urządzeń własnych.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z terminami 14-90 dni i precyzyjnymi miernikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki Bezpieczeństwa):

  Zredagujcie projekt "Standardu Bezpieczeństwa Urządzeń Brzegowych IoT i Aplikacji Mobilnych w LogiXpress".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Wyzwania skali w logistyce e-commerce - ekosystem 12 000 automatów IoT na ulicach polskich miast (Student 1).
• Wyniki analizy polityki i matryca ryzyka 3x3 (4 min): Omówienie wektorów ataku na wspólny klucz API, podatności aktualizacji FOTA oraz wymuszania zgód RODO w aplikacji (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do przyczyn źródłowych i błędu pośpiechu montażowego kosztem cyberbezpieczeństwa (Student 3).
• Plan CAP i nowa architektura PKI/mTLS dla urządzeń brzegowych (4 min): Prezentacja wdrożenia indywidualnych certyfikatów X.509, bezpiecznego kanału FOTA i rozdzielenia zgód w aplikacji (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i uwarunkowania technologiczne:

• W jaki sposób architektura mTLS (Mutual TLS) z indywidualnymi certyfikatami X.509 generowanymi w bezpiecznym elemencie sprzętowym (Secure Element) rozwiązuje problem tożsamości maszynowej w wielotysięcznej sieci urządzeń IoT?
• Jakie kryteria dobrowolności zgody na przetwarzanie danych (art. 7 ust. 4 RODO) sformułowała Europejska Rada Ochrony Danych w odniesieniu do geolokalizacji w aplikacjach mobilnych?
• W jaki sposób zaprojektować bezpieczny, kryptograficznie weryfikowalny mechanizm aktualizacji oprogramowania układowego (FOTA) odporny na ataki typu Man-in-the-Middle i cofanie wersji (Anti-Rollback Protection)?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 scenariuszy zagrożeń ekosystemu logistycznego LogiXpress.
• Zestawienie Kart Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - współdzielony klucz API IoT, NC1 - wymuszanie zgód RODO), 1 Niezgodności Małej (NC2 - nieszyfrowana FOTA) oraz 1 OFI (wdrożenie modułów TPM).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla błędu klonowania certyfikatów maszynowych.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie centralnego urzędu certyfikacji (Private CA) i wygenerowanie unikalnych certyfikatów urządzeń (mTLS) dla 12 000 automatów w procesie zdalnego provisioningu (Właściciel: Główny Architekt IoT, Termin: 45 dni, KPI: 100% maszyn z indywidualnym certyfikatem).
  • Zadanie CAP-2: Modyfikacja aplikacji mobilnej: rozdzielenie zgody na przetwarzanie geolokalizacji od realizacji usługi odbioru paczki oraz wdrożenie alternatywnego odbioru kodem QR (Właściciel: Dyrektor Pionu Cyfrowego / Product Owner Mobile, Termin: 14 dni, KPI: pełna dobrowolność zgód i 0% skarg do UODO).
  • Zadanie CAP-3: Zbudowanie bezpiecznego potoku FOTA z podpisywaniem binariów kluczem prywatnym RSA-4096 i weryfikacją podpisu na automacie przed instalacją (Właściciel: Kierownik Sekcji Oprogramowania Wbudowanego, Termin: 30 dni, KPI: wdrożenie mechanizmu bezpiecznej aktualizacji).
  • Zadanie CAP-4: Nowelizacja nadrzędnej Polityki Bezpieczeństwa Informacji z dodaniem wymagań dla urządzeń IoT i procedur reagowania na fizyczny sabotaż automatu (Właściciel: CISO LogiXpress, Termin: 60 dni, KPI: zatwierdzenie dokumentu przez Zarząd).
• Projekt dokumentu: "Polityka Bezpieczeństwa Urządzeń Brzegowych (IoT) i Cyklu Życia Oprogramowania Wbudowanego".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Wyeliminowanie ryzyka kaskadowego przejęcia tysięcy maszyn paczkowych w kraju; usunięcie bezpośredniego ryzyka wielomilionowej kary od UODO; zabezpieczenie zaufania klientów przed debiutem giełdowym; pełna rozliczalność telemetryczna.
• Wady i trudności: Złożoność operacji zdalnej wymiany certyfikatów na 12 000 działających w terenie maszynach paczkowych; konieczność zarządzania unieważnianiem certyfikatów (CRL/OCSP) w sieciach o niestabilnym zasięgu komórkowym.

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.5.15, A.8.1, A.8.5, A.8.24).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 6, 7, 25 (Privacy by Design), 32.
• Europejska Rada Ochrony Danych (EROD): "Wytyczne 05/2020 dotyczące zgody na mocy rozporządzenia 2016/679", Bruksela 2020.
• Agencja Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA): "Good Practices for Security of Internet of Things (IoT)", 2020.
• NIST Special Publication 800-213: "IoT Device Cybersecurity Guidance for the Federal Government", 2021.
• Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U. z 2019 r. poz. 1781).

• U2 Student potrafi bezbłędnie zdiagnozować luki w ekosystemach IoT i chmury hybrydowej oraz sklasyfikować uchybienia w formacie NC1/NC2/OFI.
• U1 Student projektuje zaawansowane procedury bezpieczeństwa tożsamości maszynowej (PKI/mTLS) i aktualizacji oprogramowania FOTA.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla wielotysięcznej floty urządzeń brzegowych.
• U4 Student realizuje procedurę Root Cause Analysis (5 Why) i buduje Plan Działań Korygujących (CAP) z mierzalnymi KPI.
• W1W2W3 Student łączy znajomość kontroli ISO 27001 z normami cyberbezpieczeństwa IoT (NIST, ENISA) oraz unijnym prawem ochrony prywatności (RODO).
• K1K2 Student wykazuje strategiczne myślenie inżynierskie i dbałość o zaufanie konsumentów w nowoczesnej gospodarce cyfrowej.

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów umiejętności przeprowadzania wysoce specjalistycznego audytu Polityki Bezpieczeństwa Informacji w przedsiębiorstwie wytwarzającym oprogramowanie bankowe w modelu chmurowym (Banking-as-a-Service - BaaS). Zadanie skupia się na identyfikacji zaawansowanych luk w procesie wytwórczym (Secure SDLC), potokach CI/CD, orkiestracji kontenerów Kubernetes, zarządzaniu łańcuchem dostaw oprogramowania open-source (Software Bill of Materials - SBOM), zarządzaniu sekretami oraz zgodności z wymogami Cyber Resilience Act (CRA) i normą ISO/IEC 27034. Wymagane jest przeprowadzenie analizy ryzyka w matrycy 3x3, formalna kwalifikacja uchybień (NC1/NC2/OFI), dochodzenie przyczyn źródłowych (5 Why) oraz skonstruowanie Planu CAP.

Spółka "FinBaaS Solutions S.A." tworzy i dostarcza w modelu chmurowym platformę bankowości transakcyjnej dla 8 banków komercyjnych i instytucji płatniczych w Europie Środkowej. Platforma przetwarza dziennie ponad 6 milionów żądań API. Firma zatrudnia 140 inżynierów oprogramowania, testerów i architektów chmury pracujących w zwinnych zespołach produktowych (Scrum). Kod wdrażany jest na klastry Kubernetes w chmurze AWS za pośrednictwem automatycznych potoków GitLab CI/CD średnio 20 razy na dobę.

Stan zastałej dokumentacji i luki w procesie wytwórczym:

• W spółce obowiązuje "Polityka Bezpieczeństwa Informacji i Rozwoju Systemów FinBaaS", przyjęta 3 lata temu. Polityka powołuje się ogólnie na normę ISO/IEC 27001:2013, całkowicie pomijając nowe kontrole ISO/IEC 27002:2022 dotyczące bezpiecznego kodowania (A.8.28), zarządzania konfiguracją (A.8.9) oraz wywiadu o zagrożeniach (A.5.7).
• W polityce brakuje formalnych bram jakościowych (Quality Gates) w potokach CI/CD. Testy statyczne bezpieczeństwa kodu (SAST) są uruchamiane w trybie ostrzegawczym (Warning Only) i nie blokują scalenia kodu (Merge Request) ani wdrożenia na produkcję w przypadku wykrycia podatności krytycznych (np. podatności SQL Injection lub błędu uwierzytelniania w interfejsie API).
• Firma intensywnie korzysta z zewnętrznych pakietów open-source (pobieranych masowo z publicznych repozytoriów npm i Maven), nie prowadząc żadnego rejestru komponentów (brak SBOM) ani automatycznej analizy podatności w bibliotekach zewnętrznych (SCA). W toku wstępnego skanowania wykryto, że w 4 mikroserwisach produkcyjnych pracują biblioteki ze znanymi podatnościami o statusie Critical (CVSS 9.8) sprzed ponad roku.
• Sekrety aplikacyjne (tokeny dostępu do bazy produkcyjnej, klucze szyfrujące certyfikatów mTLS) przekazywane są do kontenerów jako zmienne środowiskowe w postaci czystego tekstu (brak integracji z centralnym menedżerem sekretów typu HashiCorp Vault).
• Kontenery deweloperskie i produkcyjne w klastrze Kubernetes uruchamiane są w trybie uprzywilejowanym (root / privileged mode) bez ograniczenia uprawnień (SecurityContext), co umożliwia atakującemu ucieczkę z kontenera (Container Escape) do węzła głównego klastra.

Komitet Bezpieczeństwa banku będącego głównym klientem FinBaaS zażądał przeprowadzenia niezależnego audytu polityki Secure SDLC, wyliczenia ryzyka w matrycy 3x3 i przedstawienia Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie inżynierii oprogramowania i środowisk chmurowych:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Inżynier Jakości Procesów IT): Bada proces wytwórczy Scrum/Agile, nadzór nad zmianami (Change Management wg A.8.32) oraz zgodność z unijnym aktem Cyber Resilience Act (CRA).

  Student 2 (Audytor Bezpieczeństwa Aplikacji, DevSecOps i Konteneryzacji): Analizuje skrypty potoków CI/CD, narzędzia SAST/DAST/SCA, konfigurację klastrów Kubernetes (Pod Security Standards), zarządzanie sekretami w Vault oraz kontrole A.8.25-A.8.31 ISO 27001.

  Student 3 (Audytor Ryzyka Łańcucha Dostaw, Zgodności i Planu CAP): Wylicza ryzyka w matrycy 3x3 dla podatności w kodzie, prowadzi dochodzenie przyczyn źródłowych metodą 5 Why, opracowuje karty NC1/NC2/OFI oraz tabelę CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Platformy BaaS):

  Wyliczcie ryzyko w matrycy 3x3 dla:

  • Ryzyko 1: Wdrożenie na produkcję biblioteki ze znaną luką krytyczną CVSS 9.8 (atak na łańcuch dostaw i kompromitacja kont bankowych) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Sekrety produkcyjne przekazywane otwartym tekstem w zmiennych środowiskowych -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 3: Praca kontenerów w trybie privileged w Kubernetes (ryzyko przejęcia całego klastra chmurowego) -> P=2, S=3 -> R=6 (Krytyczne).
  • Ryzyko 4: Brak blokady w potokach CI/CD przy wykryciu podatności SAST -> P=3, S=2 -> R=6 (Wysokie).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Brak kontroli i weryfikacji komponentów zewnętrznych w łańcuchu dostaw oprogramowania (naruszenie kontroli A.8.30 i A.5.21 ISO/IEC 27001:2022 oraz przepisów CRA).
  • NC1 (Niezgodność Duża): Przechowywanie haseł i kluczy szyfrujących do baz bankowych w postaci otwartej w konfiguracjach kontenerów (naruszenie kontroli A.8.24 i A.8.28).
  • NC2 (Niezgodność Mała): Uruchamianie procesów w kontenerach produkcyjnych z uprawnieniami konta root (naruszenie zasady najmniejszych uprawnień - Least Privilege).
  • OFI (Szansa na doskonalenie): Brak wdrożenia mechanizmów podpisywania obrazów kontenerów w potoku (Cosign / Sigstore) przed ich uruchomieniem w klastrze.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak blokowania wdrożeń przy wykryciu luk SAST/SCA) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego kod z podatnościami krytycznymi trafia na produkcję w banku? Bo narzędzia SAST/SCA w potoku GitLab CI/CD działają z flagą "allow_failure: true".

  2. Dlaczego ustawiono flagę "allow_failure"? Bo testy bezpieczeństwa fałszywie zgłaszały alarmy (False Positives) i blokowały pilne wydania poprawek biznesowych.

  3. Dlaczego nie dostrojono reguł skanerów, aby wyeliminować fałszywe alarmy? Bo w zespołach deweloperskich nie było inżyniera DevSecOps odpowiedzialnego za utrzymanie narzędzi bezpieczeństwa.

  4. Dlaczego nie zatrudniono lub nie wyznaczono ról DevSecOps? Bo budżet działu R&D był w 100% alokowany na programistów realizujących nowe funkcje bankowe pod presją klientów.

  5. Dlaczego dopuszczono do braku ról bezpieczeństwa w cyklu wytwórczym? (PRZYCZYNA ŹRÓDŁOWA): Brak w nadrzędnej strategii spółki standardu dojrzałości wytwarzania oprogramowania (np. OWASP SAMM) i uzależnienia sukcesu wdrożenia wyłącznie od szybkości (Time-to-Market) kosztem bezpieczeństwa aplikacji.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z terminami 14-90 dni i twardymi wskaźnikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki Bezpieczeństwa):

  Zredagujcie projekt "Standardu Bezpiecznego Cyklu Wytwarzania Oprogramowania (Secure SDLC) i Bezpieczeństwa Kontenerów w FinBaaS".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Paradygmat Banking-as-a-Service - zaufanie banków do kodu dostawcy oprogramowania w reżimie DORA i CRA (Student 1).
• Diagnoza potoków CI/CD i matryca ryzyka 3x3 (4 min): Wykazanie skrajnych zagrożeń: flaga allow_failure w SAST, luki w bibliotekach open-source i sekrety w kontenerach (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do przyczyn źródłowych i błędu stawiania tempa wydań ponad cyberbezpieczeństwo (Student 3).
• Plan CAP i wdrożenie modelu DevSecOps (4 min): Prezentacja twardych bramek jakościowych (Quality Gates), integracji z Vault, standardu SBOM i bezpiecznych profili Kubernetes (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i kontekst inżynierski:

• W jaki sposób zorganizować automatyczne bramki jakościowe (Quality Gates) w potoku CI/CD, aby bezwzględnie blokować wdrożenia z lukami Critical/High bez paraliżowania pracy programistów (koncepcja triażu i wyjątków bezpieczeństwa)?
• Czym jest format CycloneDX / SPDX w kontekście Software Bill of Materials (SBOM) i jakie obowiązki w zakresie ujawniania podatności w łańcuchu dostaw nakłada unijny akt Cyber Resilience Act?
• W jaki sposób wdrożyć w klastrze Kubernetes standard Pod Security Standards na poziomie 'Restricted' (blokada roota, tylko do odczytu system plików, zakaz eskalacji uprawnień) w połączeniu z menedżerem sekretów Vault?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 wektorów ataku na proces wytwórczy i klastry BaaS.
• Zestawienie Kart Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - brak kontroli łańcucha dostaw open-source, NC1 - sekrety w czystym tekście), 1 Niezgodności Małej (NC2 - uprawnienia kontenerów) oraz 1 OFI (podpisywanie obrazów Cosign).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla incydentu z flagą allow_failure w CI/CD.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie w potoku CI/CD narzędzi do automatycznego generowania SBOM i blokowania bibliotek ze znanymi podatnościami CVE > 7.0 (Właściciel: Główny Architekt Oprogramowania, Termin: 21 dni, KPI: 100% zablokowanych komponentów z lukami krytycznymi).
  • Zadanie CAP-2: Migracja sekretów ze zmiennych środowiskowych do dedykowanego klastra HashiCorp Vault z wstrzykiwaniem sekretów w locie (Vault Agent Sidecar) (Właściciel: Lider Zespołu DevOps / Cloud Infrastructure, Termin: 30 dni, KPI: zero haseł w plikach konfiguracyjnych).
  • Zadanie CAP-3: Wdrożenie restrykcyjnych polityk Pod Security Standards w klastrach Kubernetes i wymuszenie uruchamiania aplikacji jako użytkownik non-root (Właściciel: Administrator Bezpieczeństwa Chmury, Termin: 45 dni, KPI: 100% kontenerów spełniających profil Restricted).
  • Zadanie CAP-4: Nowelizacja nadrzędnej Polityki Wytwarzania Oprogramowania i wdrożenie modelu ról Security Champions w każdym zespole Scrum (Właściciel: CISO FinBaaS, Termin: 60 dni, KPI: certyfikacja przeszkolenia 14 inżynierów).
• Wzorcowy dokument: "Procedura Bezpiecznego Zarządzania Kodem Źródłowym, Zmianą i Wdrożeniami Kontenerowymi".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Spełnienie rygorystycznych wymogów audytowych banków partnerskich; wyeliminowanie ryzyka ataków na łańcuch dostaw; zgodność z unijnym aktem CRA; wysoka dojrzałość inżynierska i odporność na ataki Zero-Day.
• Wady i koszty: Konieczność poświęcenia części sprintów programistycznych na refaktoryzację kodu i aktualizację bibliotek; początkowe spowolnienie tempa dostarczania nowych funkcji biznesowych.

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.8.25-A.8.32).
• Norma PN-EN ISO/IEC 27034:2018 - Bezpieczeństwo aplikacji (Application Security).
• Rozporządzenie Parlamentu Europejskiego i Rady w sprawie zharmonizowanych wymogów cyberbezpieczeństwa dla produktów z elementami cyfrowymi (Cyber Resilience Act - CRA), 2024.
• OWASP: "Software Assurance Maturity Model (SAMM) Version 2.0", 2020.
• Center for Internet Security (CIS): "CIS Kubernetes Benchmark v1.8", 2023.
• Cloud Native Computing Foundation (CNCF): "Software Supply Chain Best Practices", 2022.

• U2 Student potrafi zidentyfikować zaawansowane uchybienia w architekturze potoków CI/CD i orkiestracji kontenerów oraz sklasyfikować je jako NC1/NC2/OFI.
• U1 Student projektuje zaawansowany standard Secure SDLC uwzględniający wymogi SBOM, CRA i normy ISO 27034.
• U3 Student przeprowadza matrycową analizę ryzyka 3x3 dla procesu wytwórczego i łańcucha dostaw oprogramowania.
• U4 Student realizuje procedurę Root Cause Analysis (5 Why) i konstruuje mierzalny Plan Działań Korygujących (CAP).
• W2W3 Student wykazuje dogłębną wiedzę z zakresu DevSecOps, standardów OWASP SAMM, bezpieczeństwa Kubernetes oraz regulacji CRA i DORA.
• K1K3 Student rozwija profesjonalną odpowiedzialność inżynierską za bezpieczeństwo ekosystemu finansowego.

Głównym celem zadania na ocenę 4.0 jest opanowanie umiejętności audytu i krytycznej analizy Polityki Bezpieczeństwa Informacji w prestiżowej politechnice zarządzającej Międzyuczelnianym Centrum Superkomputerowym (klaster High Performance Computing - HPC). Zadanie kładzie szczególny nacisk na rozwiązanie konfliktu między otwartością środowiska naukowego a rygorystycznymi wymaganiami ochrony własności intelektualnej, badań nad technologiami podwójnego zastosowania (Dual-Use - technologie wojskowo-cywilne, kryptografia, badania rakietowe) oraz ochrony przed szpiegostwem naukowym państw trzecich. Zadanie wymaga oszacowania ryzyka w matrycy 3x3, formalnej gradacji uchybień (NC1/NC2/OFI), dochodzenia przyczyn źródłowych metodą 5 Why oraz opracowania Planu CAP.

Centrum Superkomputerowe Politechniki dysponuje klastrem obliczeniowym o mocy 15 PFLOPS, połączonym łączami 100 Gb/s z ogólnopolską siecią optyczną PIONIER oraz siecią eduroam. Z mocy obliczeniowej klastra korzysta ponad 800 naukowców, doktorantów oraz zagranicznych zespołów badawczych realizujących granty naukowe. W klastrze przetwarzane są zarówno jawne projekty astronomiczne i klimatyczne, jak i niejawne badania materiałowe dla przemysłu zbrojeniowego oraz badania nad nowymi cząsteczkami farmaceutycznymi podlegające tajemnicy patentowej.

Stan zastałej dokumentacji i wektory kompromitacji danych:

• W uczelni obowiązuje "Polityka Bezpieczeństwa Informacji i Zasobów Teleinformatycznych Politechniki", uchwalona 4 lata temu. Dokument traktuje superkomputer tak samo jak zwykłe stacje komputerowe w salach studenckich i nie wprowadza żadnych specjalnych stref ochrony danych badawczych.
• W klastrze HPC brak jest logicznej i kryptograficznej izolacji pomiędzy zadaniami obliczeniowymi (brak bezpiecznej konteneryzacji procesów i szyfrowania danych w węzłach obliczeniowych). W toku wstępnego audytu wykazano, że użytkownik realizujący prosty projekt studencki ma możliwość wglądu do katalogów tymczasowych (/tmp i pamięci współdzielonej) innego zespołu prowadzącego badania nad stopami tytanu dla pocisków rakietowych (technologia podwójnego zastosowania Dual-Use).
• Dostęp do klastra z całego świata odbywa się za pośrednictwem pojedynczych kluczy SSH bez wymogu uwierzytelniania wieloskładnikowego (MFA), a konta naukowe są bezterminowe - w systemie aktywnych jest ponad 150 kont zagranicznych stypendystów, którzy ukończyli projekty ponad 2 lata temu i wrócili do krajów podwyższonego ryzyka wywiadowczego.
• Naukowcy masowo przesyłają surowe wyniki badań na zagraniczne darmowe serwery obliczeniowe i publiczne dyski chmurowe bez wiedzy Działu Bezpieczeństwa i bez weryfikacji przepisów Ustawy o kontroli obrotu z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym.
• W uczelni brak jest procedury weryfikacji personelu badawczego i studentów zagranicznych dopuszczanych do infrastruktury krytycznej HPC.

Rektor Politechniki, po ostrzeżeniu przekazanym przez Agencję Bezpieczeństwa Wewnętrznego (ABW) dotyczącym prób penetracji klastra przez obce służby specjalne, zleca audytorom gruntowną analizę polityki, wyliczenie ryzyk w matrycy 3x3 i sformułowanie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie wielkiej infrastruktury obliczeniowej:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Pełnomocnik ds. Bezpieczeństwa Naukowego): Bada zgodność procedur z przepisami o kontroli technologii strategicznych (Dual-Use), tajemnicy patentowej i kieruje wystąpieniem.

  Student 2 (Audytor Architektury HPC i Sieci Akademickich): Bada konfigurację systemu kolejkowego (Slurm/PBS), mechanizmy izolacji węzłów obliczeniowych, zarządzanie kluczami SSH, wdrożenie MFA oraz kontrole A.8.20, A.8.22 i A.8.24 ISO 27001.

  Student 3 (Audytor Zgodności Wywiadowczej, Ryzyka i Jakości CAP): Wylicza ryzyka szpiegostwa naukowego w matrycy 3x3, przeprowadza procedurę 5 Why, formułuje karty niezgodności NC1/NC2/OFI oraz tabelę CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Centrum HPC):

  Wyliczcie ryzyko w matrycy 3x3 dla:

  • Ryzyko 1: Dostęp nieuprawnionych osób do badań Dual-Use przez wspólne zasoby klastra HPC (szpiegostwo naukowe, utrata przewagi militarnej) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Przejęcie konta badacza z dostępem do superkomputera przez brak MFA dla połączeń SSH -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 3: Eksfiltracja danych patentowych do publicznych chmur zagranicznych -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 4: Pozostawianie aktywnych kont byłych stypendystów z państw autorytarnych -> P=3, S=2 -> R=6 (Wysokie).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Brak mechanizmów separacji i kontroli dostępu do danych z projektów o znaczeniu strategicznym i technologii podwójnego zastosowania (naruszenie kontroli A.5.12, A.5.15 i A.8.22 ISO/IEC 27001:2022 oraz przepisów Ustawy o obrocie strategicznym).
  • NC1 (Niezgodność Duża): Dostęp zdalny do węzłów obliczeniowych klastra HPC bez uwierzytelniania wieloskładnikowego (MFA) dla użytkowników zewnętrznych (naruszenie par. 20 KRI i kontroli A.8.5).
  • NC2 (Niezgodność Mała): Brak procedury cyklicznego wygaszania uprawnień i rekoncyliacji kont gościnnych w systemie kolejkowym.
  • OFI (Szansa na doskonalenie): Brak wdrożenia bezpiecznych kontenerów obliczeniowych (np. Apptainer/Singularity) z kryptograficznym podpisywaniem obrazów naukowych.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak separacji projektów Dual-Use w klastrze HPC) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego studenci mogli czytać pliki tymczasowe z projektu badań rakietowych? Bo wszystkie zadania w klastrze uruchamiano we wspólnym, domyślnym węźle pamięci masowej z prawami odczytu dla grupy 'users'.

  2. Dlaczego zastosowano domyślne prawa grupy 'users'? Bo ułatwiało to naukowcom swobodne dzielenie się skryptami obliczeniowymi.

  3. Dlaczego nie wydzielono osobnej bezpiecznej partycji dla badań strategicznych? Bo nikt w Dziale Nauki nie zgłosił administratorom klastra, że realizowany grant ma charakter technologii podwójnego zastosowania.

  4. Dlaczego Dział Nauki nie poinformował administratorów IT? Bo w uczelni procedura składania grantów badawczych nie zawierała etapu oceny ryzyka cyberbezpieczeństwa i klasyfikacji informacji.

  5. Dlaczego dopuszczono do braku takiego etapu? (PRZYCZYNA ŹRÓDŁOWA): Brak w Politechnice Zintegrowanej Polityki Bezpieczeństwa Badań Naukowych i Własności Intelektualnej rozgraniczającej projekty otwartej nauki (Open Science) od projektów chronionych i wrażliwych.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z terminami 14-90 dni i konkretnymi wskaźnikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki Bezpieczeństwa):

  Zredagujcie projekt "Regulaminu Bezpieczeństwa Obliczeń Wielkiej Skali (HPC) i Ochrony Badań Strategicznych w Centrum Superkomputerowym".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Konflikt paradygmatów: idea Open Science a konieczność ochrony badań przed szpiegostwem gospodarczym i wywiadowczym (Student 1).
• Diagnoza klastra HPC i matryca ryzyka 3x3 (4 min): Wykazanie skrajnych luk: brak separacji procesów, klucze SSH bez MFA, aktywne konta zagranicznych rezydentów (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie dochodzenia przyczyn źródłowych i braku klasyfikacji grantów w Dziale Nauki (Student 3).
• Plan CAP i nowa strefowa architektura klastra (4 min): Prezentacja partycji bezpiecznych (Secure Enclaves), wymuszenia MFA z kluczami sprzętowymi i procedur ochrony Dual-Use (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i uwarunkowania prawno-badawcze:

• Jakie konsekwencje prawne i karne (związane z naruszeniem ustawy o obrocie strategicznym) grożą uczelni i naukowcom za nieuprawnione ujawnienie technologii podwójnego zastosowania (Dual-Use) podmiotom z państw objętych embargiem?
• W jaki sposób zaimplementować architekturę bezpiecznych enklaw obliczeniowych (Secure Enclaves) w środowisku HPC z wykorzystaniem szyfrowania pamięci RAM i dysków roboczych (Confidential Computing)?
• Dlaczego wdrożenie uwierzytelniania wieloskładnikowego (MFA) dla sesji konsolowych SSH do superkomputera jest niezbędne i jak zintegrować protokół FIDO2 z demonem OpenSSH?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 wektorów zagrożeń infrastruktury superkomputerowej Politechniki.
• Zestawienie Kart Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - brak separacji Dual-Use, NC1 - brak MFA dla SSH), 1 Niezgodności Małej (NC2 - brak audytu kont gościnnych) oraz 1 OFI (kontenery Apptainer).
• Protokół Analizy Przyczyn Źródłowych metodą 5 Why dla incydentu współdzielenia pamięci procesów strategicznych.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Konfiguracja fizycznie i logicznie odizolowanej partycji obliczeniowej 'HPC-Secure' z szyfrowaniem dysków i izolacją zadań w systemie kolejkowym Slurm (Właściciel: Główny Administrator Klastra HPC, Termin: 21 dni, KPI: wdrożenie izolacji potwierdzone testem penetracyjnym).
  • Zadanie CAP-2: Wdrożenie obowiązkowego uwierzytelniania dwuskładnikowego (klucze sprzętowe FIDO2 / Passkeys) na wszystkich bramkach wejściowych SSH do klastra (Właściciel: Kierownik Sekcji Bezpieczeństwa Sieci PIONIER, Termin: 14 dni, KPI: 100% sesji zabezpieczonych MFA).
  • Zadanie CAP-3: Przegląd i deaktywacja wszystkich kont użytkowników, których projekty zakończyły się przed ponad 30 dniami (Właściciel: Kierownik Biura Obsługi Użytkowników HPC, Termin: 7 dni, KPI: likwidacja 100% nieaktywnych kont).
  • Zadanie CAP-4: Nowelizacja nadrzędnej Polityki Bezpieczeństwa Informacji Politechniki i wdrożenie procedury obowiązkowej klasyfikacji bezpieczeństwa grantów badawczych przed ich uruchomieniem (Właściciel: Prorektor ds. Nauki i Pełnomocnik ds. Bezpieczeństwa Informacji, Termin: 60 dni, KPI: zatwierdzenie regulaminu przez Senat Uczelni).
• Wzorcowy regulamin: "Procedura Bezpieczeństwa Danych Badawczych i Projektów o Strategicznym Znaczeniu Gospodarczym i Obronnym".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Skuteczne zabezpieczenie strategicznych technologii przed kradzieżą i obcym wywiadem; pełna zgodność z polskim prawem obrotu strategicznego i KRI; zachowanie wolności akademickiej w projektach jawnych; ochrona dobrego imienia uczelni.
• Wady i trudności: Dodatkowe procedury weryfikacyjne dla naukowców wnioskujących o dostęp do klastra; konieczność zakupu kluczy sprzętowych FIDO2 dla kilkuset badaczy; opór części środowiska naukowego przed ograniczeniem swobody wymiany plików.

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.5.12, A.5.13, A.5.15, A.8.5, A.8.20, A.8.22).
• 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).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2021/821 ustanawiające unijny system kontroli wywozu produktów podwójnego zastosowania (Dual-Use).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (...) (Dz.U. z 2024 r. poz. 773) - par. 20.
• Ministerstwo Nauki i Szkolnictwa Wyższego / ABW: "Rekomendacje dotyczące bezpieczeństwa badań naukowych i ochrony własności intelektualnej w polskich uczelniach", Warszawa 2023.
• NIST Special Publication 800-223: "High-Performance Computing (HPC) Security: Guidelines for Supercomputing Facilities", 2023.

• U2 Student trafnie diagnozuje uchybienia bezpieczeństwa w architekturze superkomputerowej i kwalifikuje je do kategorii NC1/NC2/OFI.
• U1 Student projektuje zaawansowane procedury bezpieczeństwa dla klastrów HPC i projektów badawczych o znaczeniu obronnym.
• U3 Student szacuje ryzyka szpiegostwa gospodarczego i naukowego w matrycy 3x3 dla środowisk akademickich.
• U4 Student prowadzi dochodzenie przyczyn źródłowych metodą 5 Why i konstruuje realistyczny Plan Działań Korygujących (CAP).
• W1W2W3 Student rozumie zawiłości prawne obrotu towarami podwójnego zastosowania (Dual-Use), tajemnicy patentowej oraz wytycznych NIST dla HPC.
• K1K3 Student cechuje się dojrzałą postawą patriotyczną i odpowiedzialnością za bezpieczeństwo strategicznych aktywów naukowych państwa.

Głównym celem zadania na ocenę 4.0 jest nabycie przez studentów umiejętności przeprowadzenia zaawansowanego audytu zgodności Polityki Bezpieczeństwa Informacji w międzynarodowym koncernie farmaceutycznym posiadającym fabryki leków oraz ośrodki badań klinicznych w Polsce. Zadanie koncentruje się na weryfikacji zapisów dotyczących rygorystycznej zasady integralności danych (Data Integrity wg standardu ALCOA+), walidacji systemów skomputeryzowanych zgodnie z wytycznymi Dobrej Praktyki Wytwarzania (GMP) i przewodnika GAMP 5, zarządzania ścieżkami audytowymi (Audit Trail) oraz ochrony patentowej receptur leków ratujących życie. Wymagane jest przeprowadzenie analizy ryzyka w matrycy 3x3, formalna gradacja uchybień (NC1/NC2/OFI), analiza 5 Why oraz opracowanie Planu CAP.

Koncern "PharmaGlobal Polska S.A." prowadzi w Polsce 2 nowoczesne zakłady produkcyjne (produkcja antybiotyków i leków kardiologicznych) oraz ośrodek fazy II i III badań klinicznych nad terapiami przeciwnowotworowymi. W systemach koncernu przetwarzane są poufne wyniki badań klinicznych ponad 15 000 pacjentów, receptury chemiczne podlegające ochronie patentowej oraz parametry procesowe z 350 maszyn produkcyjnych (reaktory, linie sterylizacji i pakowania). Zakłady podlegają inspekcjom Głównego Inspektoratu Farmaceutycznego (GIF), Europejskiej Agencji Leków (EMA) oraz amerykańskiej agencji FDA (w reżimie 21 CFR Part 11).

Stan zastałej dokumentacji i luki w integralności danych:

• W spółce obowiązuje "Polityka Bezpieczeństwa Informacji i Zgodności Farmaceutycznej", przyjęta w 2020 roku. Dokument powołuje się ogólnie na normę ISO/IEC 27001, ale nie precyzuje technicznych wymagań dotyczących nienaruszalności ścieżek audytowych (Audit Trail) w systemach laboratoryjnych (systemy LIMS i chromatografy).
• W toku inspekcji przedklinicznej wykryto, że analitycy laboratoryjni posiadają uprawnienia administratora lokalnego na stacjach roboczych sterujących spektrometrami masowymi, co pozwala im na modyfikację zegara systemowego oraz usuwanie surowych plików z nieudanymi próbami pomiarowymi (rażące naruszenie zasady ALCOA+ w zakresie kompletności i niezmienności danych).
• W systemie zarządzania produkcją (MES) funkcja rejestrowania Audit Trail została wyłączona przez inżynierów procesu z powodu "braku miejsca na dysku serwera", co oznacza, że zmiany parametrów sterylizacji leków nie są imiennie rejestrowane ani rozliczalne.
• Kopie zapasowe baz danych badań klinicznych wykonywane są bez sprawdzania sum kontrolnych (brak weryfikacji hashy SHA-256), a nośniki kopii nie są szyfrowane w spoczynku, co umożliwia potencjalną modyfikację danych pacjentów przez personel IT.
• Zgłaszanie incydentów naruszenia integralności danych do organów nadzoru farmaceutycznego nie zostało zsynchronizowane z procedurą zgłaszania naruszeń ochrony danych do Prezesa UODO (brak spójności między procedurami GMP a RODO).

Zarząd PharmaGlobal, w obliczu zbliżającej się inspekcji FDA i GIF, której negatywny wynik grozi natychmiastowym wstrzymaniem produkcji leków i stratami rzędu setek milionów złotych, powołuje zespół audytorów do przeprowadzenia analizy polityki, wyliczenia ryzyk w matrycy 3x3 i sformułowania Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie farmaceutycznym:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Inspektor Jakości Farmaceutycznej): Bada spójność polityki z wymogami Dobrej Praktyki Wytwarzania (GMP), przepisami Prawa farmaceutycznego oraz FDA 21 CFR Part 11, kieruje pracami.

  Student 2 (Audytor Systemów Skomputeryzowanych i GAMP 5): Analizuje techniczne aspekty walidacji systemów LIMS/MES, konfigurację nienaruszalnych ścieżek audytowych (Audit Trail), synchronizację czasu (NTP) oraz kontrole A.8.15 i A.8.24 ISO 27001.

  Student 3 (Audytor Integralności Danych ALCOA+, Ryzyka i Jakości CAP): Weryfikuje spełnienie 9 zasad rozszerzonego standardu ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available), wylicza ryzyka w matrycy 3x3, przeprowadza procedurę 5 Why oraz konstruuje Plan CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Środowiska Farmaceutycznego):

  Wyliczcie ryzyko w matrycy 3x3 dla:

  • Ryzyko 1: Możliwość usuwania lub modyfikacji nieudanych wyników badań laboratoryjnych przez brak blokady Audit Trail (sfałszowanie badań leku, cofnięcie pozwolenia na dopuszczenie do obrotu) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Wyłączenie Audit Trail w systemie produkcyjnym MES (brak kontroli nad parametrami sterylizacji i zanieczyszczenia leku) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 3: Nieszyfrowane kopie zapasowe danych badań klinicznych bez sum kontrolnych -> P=2, S=3 -> R=6 (Krytyczne).
  • Ryzyko 4: Brak rozgraniczenia uprawnień serwisowych IT od uprawnień personelu laboratoryjnego -> P=3, S=2 -> R=6 (Wysokie).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Naruszenie fundamentalnej zasady integralności danych ALCOA+ poprzez umożliwienie analitykom edycji zegara systemowego i kasowania plików surowych danych badawczych (naruszenie FDA 21 CFR Part 11, GMP oraz kontroli A.8.15 ISO/IEC 27001:2022).
  • NC1 (Niezgodność Duża): Eksploatacja krytycznego systemu produkcyjnego MES z wyłączonym rejestrowaniem ścieżek audytowych (naruszenie zasad Dobrej Praktyki Wytwarzania i kontroli A.8.15).
  • NC2 (Niezgodność Mała): Brak udokumentowanej procedury okresowego przeglądu logów Audit Trail przez Osoby Wykwalifikowane (Quality Assurance).
  • OFI (Szansa na doskonalenie): Brak wdrożenia centralnego systemu automatycznej archiwizacji danych laboratoryjnych z blokadą zapisu WORM (Write Once, Read Many).
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (posiadanie przez analityków uprawnień administratora na komputerach laboratoryjnych) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego analitycy laboratoryjni posiadają konta z uprawnieniami administratora? Bo oprogramowanie do obsługi chromatografu wymagało uprawnień roota/admina do zapisu danych w katalogu Program Files.

  2. Dlaczego oprogramowanie wymagało takich uprawnień? Bo producent aparatury dostarczył przestarzałą aplikację z 2012 roku, nieprzystosowaną do nowoczesnych zasad uprawnień.

  3. Dlaczego Dział IT nie wdrożył wirtualizacji lub specyficznych uprawnień do folderów (List-only permissions)? Bo Dział IT uznał, że sprzęt laboratoryjny to "aparatura badawcza podlegająca wyłącznie laboratorium".

  4. Dlaczego Dział Bezpieczeństwa nie skontrolował tego oprogramowania? Bo w procedurze walidacji systemów skomputeryzowanych (CSV) nie uczestniczył audytor bezpieczeństwa informacji.

  5. Dlaczego CSV realizowano bez udziału audytora bezpieczeństwa? (PRZYCZYNA ŹRÓDŁOWA): Brak w przedsiębiorstwie integracji Polityki Bezpieczeństwa Informacji ISMS z Systemem Zarządzania Jakością Farmaceutyczną (PQS / GMP) oraz brak wspólnych audytów IT i Działu Zapewnienia Jakości (QA).

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z terminami 14-90 dni i twardymi wskaźnikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki Bezpieczeństwa):

  Zredagujcie projekt "Standardu Integralności Danych (Data Integrity ALCOA+) i Bezpieczeństwa Systemów Skomputeryzowanych w PharmaGlobal".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Rygory przemysłu farmaceutycznego - dlaczego błąd w integralności danych może kosztować zdrowie pacjenta i cofnięcie licencji fabryki (Student 1).
• Wyniki analizy polityki i matryca ryzyka 3x3 (4 min): Przedstawienie rażących luk: uprawnienia admina w laboratoriach, wyłączony Audit Trail w MES, brak hashy w backupie (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do przyczyn źródłowych i błędu braku integracji IT z GMP/QA (Student 3).
• Plan CAP i wdrożenie standardu ALCOA+ oraz GAMP 5 (4 min): Prezentacja odebrania uprawnień admina, konfiguracji bezpiecznego logowania, centralizacji WORM i harmonogramu walidacji (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i uwarunkowania farmaceutyczne:

• W jaki sposób standard ALCOA+ definiuje 9 wymiarów integralności danych i dlaczego możliwość modyfikacji daty systemowej przez operatora jest traktowana przez inspektorów FDA/GIF jako najcięższe przestępstwo regulacyjne (Data Falsification)?
• Czym różni się podejście do walidacji systemów skomputeryzowanych wg przewodnika ISPE GAMP 5 od standardowych testów oprogramowania IT (kategorie oprogramowania 1-5, kwalifikacja instalacyjna IQ, operacyjna OQ i procesowa PQ)?
• W jaki sposób skonstruować procedurę automatycznego przeglądu ścieżek audytowych (Audit Trail Review), aby wykrywać anomalie bez konieczności ręcznego czytania milionów rekordów logów przez personel Jakości (QA)?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 scenariuszy zagrożeń integralności i poufności danych lekowych.
• Zestawienie Kart Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - uprawnienia admina i manipulacje plikami, NC1 - wyłączony Audit Trail w MES), 1 Niezgodności Małej (NC2 - brak procedury przeglądu logów) oraz 1 OFI (archiwizacja WORM).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla incydentu z uprawnieniami administracyjnymi na chromatografach.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Odebranie uprawnień administratora wszystkim analitykom laboratoryjnym i wdrożenie dedykowanych uprawnień folderowych oraz synchronizacji czasu z centralnym serwerem NTP ze znacznikiem GPS (Właściciel: Kierownik Sekcji IT Zakładu Produkcyjnego, Termin: 14 dni, KPI: zero kont lokalnych adminów w laboratoriach).
  • Zadanie CAP-2: Włączenie i zablokowanie możliwości wyłączenia Audit Trail w systemie MES oraz rozszerzenie macierzy dyskowej serwera (Właściciel: Główny Inżynier Automatyki Produkcyjnej, Termin: 7 dni, KPI: 100% transakcji produkcyjnych trwale rejestrowanych).
  • Zadanie CAP-3: Wdrożenie zautomatyzowanego szyfrowania kopii zapasowych (AES-256) oraz generowania sum kontrolnych SHA-256 dla wszystkich surowych danych badań klinicznych (Właściciel: Administrator Baz Danych Badań Klinicznych, Termin: 21 dni, KPI: weryfikacja sum kontrolnych w 100% testów).
  • Zadanie CAP-4: Pełna nowelizacja Polityki Bezpieczeństwa Informacji i zharmonizowanie jej z Procedurami Operacyjnymi (SOP) Działu Zapewnienia Jakości (QA) oraz wytycznymi GAMP 5 (Właściciel: Dyrektor ds. Zapewnienia Jakości i CISO, Termin: 60 dni, KPI: zatwierdzenie zintegrowanych procedur przed inspekcją GIF).
• Wzorcowa procedura operacyjna (SOP): "Zasady Zarządzania, Przeglądu i Ochrony Ścieżek Audytowych (Audit Trail) w Systemach Skomputeryzowanych".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Bezwarunkowe przejście międzynarodowych inspekcji FDA i GIF; ochrona ważności badań klinicznych i patentów na nowe leki; całkowite wyeliminowanie ryzyka fałszowania wyników; ochrona pacjentów przed wadliwymi partiami leków.
• Wady i koszty: Koszty modernizacji oprogramowania laboratoryjnego i zakupu pamięci masowej WORM; konieczność rygorystycznego przeszkolenia setek pracowników laboratoriów i produkcji; wydłużenie procedur odbioru partii leku o czas weryfikacji logów Audit Trail.

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.8.15 Rejestrowanie zdarzeń, A.8.24 Użycie kryptografii).
• ISPE (International Society for Pharmaceutical Engineering): "GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition)", 2022.
• US FDA: "21 CFR Part 11 - Electronic Records; Electronic Signatures - Scope and Application", Waszyngton.
• Europejska Agencja Leków (EMA): "Guideline on computerised systems and electronic data in clinical trials", 2023.
• Główny Inspektorat Farmaceutyczny (GIF): "Wytyczne w zakresie integralności danych w procesach Dobrej Praktyki Wytwarzania (GMP)", Warszawa 2022.
• Ustawa z dnia 6 września 2001 r. - Prawo farmaceutyczne (Dz.U. z 2024 r. poz. 686).

• U2 Student potrafi zdiagnozować uchybienia w integralności danych laboratoryjnych i produkcyjnych oraz zakwalifikować je do NC1/NC2/OFI.
• U1 Student projektuje zaawansowane procedury bezpieczeństwa systemów skomputeryzowanych zgodnie ze standardami ALCOA+ i GAMP 5.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla procesów wytwarzania leków i ochrony badań klinicznych.
• U4 Student przeprowadza analizę przyczyn źródłowych (5 Why) i konstruuje rygorystyczny Plan Działań Korygujących (CAP).
• W1W2W3 Student wykazuje ekspercką wiedzę z zakresu normy ISO 27001, przepisów FDA 21 CFR Part 11, unijnych wytycznych GMP i Prawa farmaceutycznego.
• K1K3 Student rozumie wagę bezkompromisowej uczciwości naukowej i inżynierskiej w procesach produkcji leków dla ludności.

Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej wiedzy i umiejętności audytowania Polityki Bezpieczeństwa Informacji w strategicznym zakładzie przemysłu zbrojeniowego realizującym kontrakty dla Sił Zbrojnych RP i państw NATO. Zadanie koncentruje się na analizie spójności koegzystencji trzech odrębnych reżimów: przetwarzania informacji niejawnych krajowych i NATO (klauzule Poufne, Tajne, Ściśle Tajne), ochrony przed ujawnieniem elektromagnetycznym (profilaktyka TEMPEST / strefy emisji ujawniającej) oraz bezpieczeństwa sieci korporacyjnej IT podlegającej audytom kontrahentów (standard TISAX poziom AL 3). Wymagane jest przeprowadzenie analizy ryzyka w matrycy 3x3, formalna gradacja uchybień (NC1/NC2/OFI), dochodzenie przyczyn źródłowych metodą 5 Why oraz skonstruowanie Planu CAP.

Zakład Produkcji Specjalnej i Optyki Rakietowej zatrudnia 1 200 pracowników (w tym 180 inżynierów konstruktorów, fizyków i optyków). Zakład projektuje i produkuje głowice naprowadzające dla przeciwpancernych pocisków kierowanych oraz optoelektroniczne systemy celownicze dla czołgów. W przedsiębiorstwie funkcjonuje Akredytowany System Teleinformatyczny do przetwarzania informacji niejawnych o klauzuli TAJNE / NATO SECRET, Kancelaria Tajna, a także rozległa sieć korporacyjna CAD/CAM zintegrowana z obrabiarkami CNC.

Stan zastałej dokumentacji i luki bezpieczeństwa obronnego:

• W zakładzie obowiązuje "Szczególna Polityka Bezpieczeństwa Teleinformatycznego (SWB) i Instrukcja Bezpieczeństwa Przemysłowego", zatwierdzona przez Służbę Kontrwywiadu Wojskowego (SKW) 4 lata temu. Od tego czasu w zakładzie wdrożono jednak sieć bezprzewodową Wi-Fi w budynkach biurowych oraz dopuszczono pracę hybrydową części konstruktorów na laptopach korporacyjnych.
• W trakcie wstępnej inspekcji wykryto, że strefa chroniona (Strefa I ochrony elektromagnetycznej, w której przetwarzane są niejawne schematy głowic rakietowych) sąsiaduje przez pojedynczą ścianę z ogólnodostępną salą konferencyjną, w której zainstalowano komercyjny punkt dostępowy Wi-Fi oraz telewizor Smart TV podłączony do Internetu (rażące ryzyko podsłuchu elektromagnetycznego i naruszenie normy ochrony przed ulotem emisji TEMPEST).
• Konstruktorzy, sfrustrowani brakiem możliwości szybkiego przesyłania dużych plików modeli 3D CAD między siecią niejawną a siecią produkcyjną obrabiarek CNC, zaczęli nielegalnie przenosić pliki na prywatnych pamięciach USB, wykorzystując laptopa serwisowego z wyłączoną blokadą portów USB (złamanie zasad akredytacji SKW i izolacji Air-Gap).
• W rozdziale dotyczącym bezpieczeństwa łańcucha dostaw (Supply Chain Security) polityka nie przewiduje procedury weryfikacji pochodzenia komponentów elektronicznych (procesorów FPGA i mikrokomputerów), co stwarza ryzyko montażu w pociskach podzespołów z ukrytymi backdoorami sprzętowymi (Hardware Trojan).
• Procedury reagowania na incydenty nie zawierają bezpośredniego kanału łączności szyfrowanej z Dyżurną Służbą Kontrwywiadu Wojskowego (SKW) w przypadku podejrzenia szpiegostwa przemysłowego lub próby werbunku pracowników.

Zarząd Polskiej Grupy Zbrojeniowej zleca zespołowi audytorów przeprowadzenie rygorystycznego audytu polityki, wyliczenie ryzyk w matrycy 3x3 oraz sporządzenie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie bezpieczeństwa przemysłu obronnego:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Pełnomocnik ds. Ochrony Informacji Niejawnych): Bada Szczególne Wymagania Bezpieczeństwa (SWB), procedury Kancelarii Tajnej, przepisy Ustawy o ochronie informacji niejawnych oraz certyfikację SKW, kieruje zespołem.

  Student 2 (Audytor Bezpieczeństwa Fizycznego, TEMPEST i Sieci Specjalnych): Analizuje strefy ochrony elektromagnetycznej, pomiary tłumienności pomieszczeń ekranowanych, nienaruszalność izolacji fizycznej (Air-Gap), bezpieczeństwo sieci obrabiarek CNC i kontrole ISO 27001 (A.7.1-A.7.4).

  Student 3 (Audytor Łańcucha Dostaw, Ryzyka Kontrwywiadowczego i Planu CAP): Bada procedury TISAX AL 3, ryzyko sprzętowych backdoorów w komponentach rakietowych, wylicza ryzyka w matrycy 3x3, przeprowadza procedurę 5 Why i konstruuje Plan CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Zakładu Zbrojeniowego):

  Wyliczcie ryzyko w matrycy 3x3 dla:

  • Ryzyko 1: Przełamanie izolacji Air-Gap przez przenoszenie niejawnych modeli CAD na pendrive (wyciek tajemnicy wojskowej do sieci korporacyjnej/Internetu) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Ulot elektromagnetyczny ze Strefy I do sali z Wi-Fi/Smart TV (zdalny podsłuch sygnałów wideo ze stacji konstrukcyjnych) -> P=2, S=3 -> R=6 (Krytyczne).
  • Ryzyko 3: Zainstalowanie w głowicy pocisku mikroprocesora z wrogim trojanem sprzętowym (sabotaż działania broni na polu walki) -> P=2, S=3 -> R=6 (Krytyczne).
  • Ryzyko 4: Brak procedury natychmiastowego powiadomienia SKW o incydentach szpiegowskich -> P=2, S=3 -> R=6 (Krytyczne).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Fizyczne naruszenie strefy ochrony elektromagnetycznej (emisji ujawniającej) przez instalację urządzeń łączności bezprzewodowej w bezpośrednim sąsiedztwie systemów przetwarzających informacje niejawne (naruszenie normy TEMPEST i Ustawy o ochronie informacji niejawnych).
  • NC1 (Niezgodność Duża): Przełamanie bariery Air-Gap i nieautoryzowany transfer plików na niezabezpieczonych nośnikach USB (złamanie warunków Akredytacji Bezpieczeństwa Teleinformatycznego SKW).
  • NC2 (Niezgodność Mała): Brak udokumentowanej procedury weryfikacji mikrokodu i sum kontrolnych oprogramowania firmware dla obrabiarek CNC.
  • OFI (Szansa na doskonalenie): Wdrożenie zautomatyzowanej stacji transferu danych przez jednokierunkową fotodiodę (Optical Data Diode) z weryfikacją formatów CAD w izolowanej piaskownicy.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (przenoszenie plików CAD na prywatnych pendrive przez konstruktorów) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego konstruktorzy użyli prywatnego pendrive? Bo musieli przenieść zmodyfikowany plik bryły pocisku do obrabiarki CNC w hali produkcyjnej.

  2. Dlaczego użyli prywatnego nośnika, a nie oficjalnej ścieżki? Bo oficjalna procedura przez Kancelarię Tajną trwała 48 godzin (nagranie płyty CD, rejestracja w dzienniku, podpisanie 4 protokołów).

  3. Dlaczego procedura trwała aż 48 godzin przy pilnej produkcji? Bo Kancelaria Tajna nie posiadała procedury szybkiej ścieżki transferu danych technicznych na produkcję.

  4. Dlaczego Dział IT nie wdrożył bezpiecznego, dedykowanego rozwiązania przesyłania plików? Bo informatycy obawiali się skomplikowanych procedur akredytacyjnych SKW i woleli utrzymać stan całkowitej blokady.

  5. Dlaczego dopuszczono do powstania takiej bariery operacyjnej? (PRZYCZYNA ŹRÓDŁOWA): Brak w przedsiębiorstwie procesu ciągłego doskonalenia procedur bezpieczeństwa (Brak zrównoważenia rygorów ochronnych z realiami nowoczesnego cyfrowego projektowania i produkcji wojennej).

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z terminami 7-60 dni i rygorystycznymi wskaźnikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki Bezpieczeństwa):

  Zredagujcie projekt "Instrukcji Bezpiecznego Transferu Danych Technicznych Pomiędzy Strefą Niejawną a Parkiem Maszynowym CNC".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Bezpieczeństwo przemysłu obronnego państwa frontowego NATO - specyfika reżimu informacji niejawnych i norm TEMPEST (Student 1).
• Diagnoza zakładu i matryca ryzyka 3x3 (4 min): Przedstawienie skrajnych uchybień: Wi-Fi przy strefie niejawnej, łamanie Air-Gap pendrive'ami, ryzyko Hardware Trojan (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Ścieżka dochodzenia do przyczyn źródłowych i błędu paraliżowania produkcji przez nieżyciowe procedury Kancelarii Tajnej (Student 3).
• Plan CAP i nowoczesna architektura transferu danych (4 min): Prezentacja ekranowania klatką Faradaya, diody danych (Data Diode) oraz procedur kontrwywiadowczych z SKW (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i uwarunkowania obronne:

• Na czym polega zjawisko emisji ujawniającej (zjawisko TEMPEST) i jakie są techniczne metody ekranowania elektromagnetycznego pomieszczeń (klatki Faradaya, filtry zasilania, światłowody dielektryczne)?
• W jaki sposób zorganizować bezpieczny transfer danych cyfrowych przez barierę Air-Gap z wykorzystaniem diody optycznej (Data Diode) oraz automatycznej dekontaminacji plików (Content Disarm and Reconstruction - CDR)?
• Jakie bezwzględne obowiązki nakłada Ustawa o ochronie informacji niejawnych na Pełnomocnika ds. Ochrony Informacji Niejawnych w sytuacji wykrycia nieuprawnionego użycia nośnika elektronicznego w strefie akredytowanej?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 wektorów sabotażu i szpiegostwa w zakładzie zbrojeniowym.
• Zestawienie Kart Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - naruszenie strefy elektromagnetycznej, NC1 - złamanie izolacji Air-Gap), 1 Niezgodności Małej (NC2 - brak procedur dla CNC) oraz 1 OFI (wdrożenie diody optycznej).
• Protokół Analizy Przyczyn Źródłowych metodą 5 Why dla incydentu z nielegalnym pendrive konstruktorów.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Natychmiastowy demontaż punktu dostępowego Wi-Fi i telewizora Smart TV ze strefy buforowej oraz wykonanie kontrolnych pomiarów tłumienności elektromagnetycznej przez akredytowane laboratorium (Właściciel: Pełnomocnik ds. Bezpieczeństwa Przemysłowego i Ochrony Informacji Niejawnych, Termin: 7 dni, KPI: certyfikat braku emisji ujawniającej).
  • Zadanie CAP-2: Zakup i wdrożenie certyfikowanej przez SKW stacji transferu danych z jednokierunkową diodą światłowodową i skanowaniem antywirusowym plików CAD (Właściciel: Główny Inżynier Systemów Specjalnych IT, Termin: 30 dni, KPI: skrócenie czasu transferu do 15 minut przy zachowaniu 100% szczelności Air-Gap).
  • Zadanie CAP-3: Zablokowanie portów USB na wszystkich komputerach korporacyjnych i inżynierskich za pomocą oprogramowania Device Control z alarmem w SIEM (Właściciel: Kierownik Sekcji Bezpieczeństwa Teleinformatycznego, Termin: 14 dni, KPI: 100% zablokowanych portów USB bez autoryzacji).
  • Zadanie CAP-4: Opracowanie procedury weryfikacji łańcucha dostaw mikrokontrolerów i scalaków (Supply Chain Hardware Verification) we współpracy z Wojskową Akademią Techniczną (Właściciel: Dyrektor Pionu Badań i Rozwoju, Termin: 60 dni, KPI: wdrożenie testów mikrotomograficznych komponentów).
• Wzorcowa instrukcja: "Zasady Zachowania Szczególnych Środków Ochrony Przed Emisją Ujawniającą w Strefach Kancelarii Tajnej i Ośrodków Konstrukcyjnych".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Całkowite wyeliminowanie ryzyka cofnięcia Akredytacji Bezpieczeństwa Teleinformatycznego przez SKW; ochrona tajemnic wojskowych o znaczeniu strategicznym dla bezpieczeństwa RP; odblokowanie wąskich gardeł w produkcji pocisków; spełnienie standardów NATO i TISAX AL 3.
• Wady i trudności: Wysoki koszt zakupu wojskowych diod danych i profesjonalnych pomiarów elektromagnetycznych; konieczność rygorystycznego nadzoru nad nawykami konstruktorów przyzwyczajonych do wygody komercyjnych narzędzi IT.

• Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. z 2024 r. poz. 632).
• Rozporządzenie Prezesa Rady Ministrów w sprawie podstawowych wymagań bezpieczeństwa teleinformatycznego dla systemów przetwarzających informacje niejawne.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.7.1, A.7.2, A.7.4, A.8.20, A.8.22).
• Standardy Bezpieczeństwa Przemysłowego NATO: AC/35-D/2000 (Protection of Non-Classified and Classified Information).
• Agencja Bezpieczeństwa Wewnętrznego (ABW) / Służba Kontrwywiadu Wojskowego (SKW): "Zalecenia dotyczące ochrony przed ujawnieniem elektromagnetycznym (TEMPEST)", Warszawa.
• ENX Association: "TISAX Assessment Requirements (IT Security, Prototype Protection)", 2023.

• U2 Student profesjonalnie identyfikuje i klasyfikuje uchybienia w reżimach informacji niejawnych i ochrony elektromagnetycznej w formule NC1/NC2/OFI.
• U1 Student projektuje zaawansowane procedury transferu danych przez barierę Air-Gap zgodne z wymaganiami służb kontrwywiadu wojskowego.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla scenariuszy szpiegostwa obcego wywiadu i sabotażu produkcji zbrojeniowej.
• U4 Student przeprowadza dochodzenie 5 Why i konstruuje rygorystyczny Plan Działań Korygujących (CAP).
• W1W2W3 Student dogłębnie zna Ustawę o ochronie informacji niejawnych, normy TEMPEST, rygory NATO oraz standardy przemysłu motoryzacyjno-obronnego TISAX.
• K1K3 Student cechuje się najwyższym honorem zawodowym, etyką i bezkompromisową troską o obronność Rzeczypospolitej Polskiej.

Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanych umiejętności audytu i krytycznej oceny Polityki Bezpieczeństwa Informacji w centralnej instytucji rynku informacji gospodarczej (Biuro Informacji Gospodarczej - BIG), przetwarzającej dane o zadłużeniu milionów obywateli i podmiotów gospodarczych oraz świadczącej usługi zautomatyzowanego scoringu wiarygodności płatniczej. Zadanie kładzie nacisk na analizę legalności i bezpieczeństwa algorytmicznego profilowania (art. 22 RODO), ochrony bramek API przed masowym wyciąganiem danych (Scraping i Credential Stuffing), oszacowanie ryzyka w matrycy 3x3, formalną gradację uchybień (NC1/NC2/OFI), analizę przyczyn źródłowych metodą 5 Why oraz opracowanie Planu CAP.

Spółka "InfoVeritas S.A." jest licencjonowanym Biurem Informacji Gospodarczej działającym na podstawie Ustawy o udostępnianiu informacji gospodarczych i wymianie danych gospodarczych. Prowadzi centralny rejestr dłużników, bazę zapytań kredytowych oraz silnik oceny scoringowej (Scoring Engine) oparty na uczeniu maszynowym. Rejestr zawiera dane o zobowiązaniach ponad 2,8 mln osób fizycznych i 450 tys. spółek. Z bazy korzystają za pośrednictwem interfejsów REST API banki, firmy pożyczkowe, operatorzy telekomunikacyjni oraz firmy windykacyjne, generując ponad 400 000 zapytań dziennie.

Stan zastałej dokumentacji i luki bezpieczeństwa:

• W spółce funkcjonuje "Zintegrowana Polityka Bezpieczeństwa Informacji i Danych Osobowych", certyfikowana na zgodność z ISO/IEC 27001 w 2021 roku. Dokument nie odzwierciedla jednak nowoczesnych zagrożeń związanych z ekspozycją interfejsów programistycznych API ani rygorów zautomatyzowanego podejmowania decyzji.
• W polityce brakuje wytycznych dotyczących bezpieczeństwa interfejsów API wg standardu OWASP API Security Top 10 (brak mechanizmów ograniczania liczby zapytań Rate Limiting na poziomie poszczególnych endpointów, brak wykrywania anomalii behawioralnych). W logach z ostatnich 3 miesięcy odnotowano serię zapytań z zagranicznych adresów IP wskazujących na zorganizowany atak Credential Stuffing i masowe odpytywanie numerów PESEL.
• W obszarze RODO w polityce brakuje procedury realizacji praw osób, których dane dotyczą, w odniesieniu do zautomatyzowanego profilowania i scoringu (art. 22 RODO). Osoby, którym odmówiono kredytu na skutek negatywnej oceny scoringowej, nie mają zagwarantowanego prawa do uzyskania interwencji ludzkiej (Human-in-the-loop), wyjaśnienia logiki algorytmu ani zakwestionowania decyzji.
• Dane historyczne o spłaconych długach przechowywane są w bazie produkcyjnej bezterminowo z powodu braku zautomatyzowanej procedury retencji i bezpiecznego usuwania danych (naruszenie zasady ograniczenia przechowywania - art. 5 ust. 1 lit. e RODO).
• W rozdziale technicznym dotyczącym szyfrowania brak wymogu stosowania protokołu TLS 1.3 dla połączeń z partnerami zewnętrznymi (wciąż dopuszczone jest przestarzałe i podatne szyfrowanie TLS 1.0/1.1).

Prezes Urzędu Ochrony Danych Osobowych (UODO) wszczyna kontrolę po licznych skargach obywateli. Zarząd InfoVeritas zleca zespołowi audytorów pilną analizę zastałej polityki, wyliczenie ryzyk w matrycy 3x3 i sformułowanie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na zaawansowanym audycie centralnego rejestru danych:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Oficer Zgodności Prawnej i RODO): Analizuje przepisy Ustawy o udostępnianiu informacji gospodarczych, art. 22 RODO (profilowanie), zasady retencji danych i koordynuje wystąpienie referatowe.

  Student 2 (Audytor Bezpieczeństwa API i Aplikacji Chmurowych): Bada architekturę bram API (API Gateway), mechanizmy uwierzytelniania OAuth2/mTLS, podatności wg OWASP API Security Top 10 oraz kontrole A.8.24, A.8.26 normy ISO/IEC 27001:2022.

  Student 3 (Audytor Ryzyka Algorytmicznego, Jakości Danych i Planu CAP): Wylicza ryzyka w matrycy 3x3, przeprowadza procedurę 5 Why dla wycieku danych przez API, opracowuje karty niezgodności NC1/NC2/OFI oraz tabelę CAP. W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Opracowanie Matrycy Ryzyka 3x3 dla Rejestru Dłużników):

  Wyliczcie ryzyko w matrycy 3x3 dla:

  • Ryzyko 1: Masowy scraping bazy dłużników i PESEL przez podatność w interfejsie API (nieuprawniony wgląd w finanse obywateli, gigantyczny wyciek danych) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 2: Brak procedury interwencji ludzkiej przy profilowaniu scoringowym (nielegalne zautomatyzowane decyzje, kara UODO do 20 mln euro) -> P=3, S=3 -> R=9 (Krytyczne).
  • Ryzyko 3: Bezterminowe przechowywanie przedawnionych i spłaconych wpisów o długach -> P=3, S=2 -> R=6 (Wysokie).
  • Ryzyko 4: Używanie podatnych protokołów TLS 1.0/1.1 w komunikacji z instytucjami pożyczkowymi -> P=2, S=3 -> R=6 (Wysokie).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Przetwarzanie danych w procesie zautomatyzowanego scoringu kredytowego bez zapewnienia praw osób z art. 22 ust. 3 RODO (brak prawa do wyjaśnienia i interwencji człowieka).
  • NC1 (Niezgodność Duża): Brak odpowiednich środków technicznych zabezpieczających interfejsy API przed masową eksfiltracją danych (naruszenie art. 32 RODO oraz kontroli A.8.26 ISO/IEC 27001:2022).
  • NC2 (Niezgodność Mała): Brak zautomatyzowanego mechanizmu retencji i anonimizacji wpisów gospodarczych po upływie ustawowych terminów przechowywania.
  • OFI (Szansa na doskonalenie): Wdrożenie zaawansowanego systemu API Security klasy WAAP (Web Application and API Protection) z analizą behawioralną ruchu botów.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (podatność API na masowe zapytania scrapingowe) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego zewnętrzny skrypt mógł w ciągu jednej nocy odpytać 50 000 numerów PESEL? Bo na publicznej bramie API nie wdrożono limitu zapytań (Rate Limiting).

  2. Dlaczego nie wdrożono limitu zapytań? Bo klienci korporacyjni (banki) zgłaszali, że restrykcyjne limity spowalniają ich procesy masowej weryfikacji wniosków kredytowych.

  3. Dlaczego nie zróżnicowano limitów dla zaufanych banków i pozostałych klientów? Bo brama API nie posiadała modułu zarządzania politykami opartymi na kontekście i tożsamości klienta.

  4. Dlaczego architektura API nie posiadała takiego modułu? Bo Dział IT wdrożył prosty serwer proxy bez uwzględnienia standardów bezpieczeństwa OWASP API Security.

  5. Dlaczego Dział IT wdrożył niezabezpieczone rozwiązanie? (PRZYCZYNA ŹRÓDŁOWA): Brak w przedsiębiorstwie Polityki Bezpieczeństwa Interfejsów Programistycznych (API Governance) oraz brak obowiązku przeprowadzania testów penetracyjnych API przed ich publikacją.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z terminami 14-90 dni i precyzyjnymi wskaźnikami KPI.

• Krok 6 (Projekt Nowelizacji Polityki Bezpieczeństwa):

  Zredagujcie projekt "Standardu Bezpieczeństwa Interfejsów API oraz Procedury Przejrzystego Profilowania Algorytmicznego w InfoVeritas".

Plan wystąpienia seminaryjnego (15 minut):

• Wprowadzenie (3 min): Rola Biura Informacji Gospodarczej na rynku finansowym - potęga danych o długach a odpowiedzialność za prawa obywatela (Student 1).
• Wyniki analizy polityki i matryca ryzyka 3x3 (4 min): Przedstawienie skrajnych luk: podatność API na scraping, brak ochrony przed botami, bezterminowa retencja (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Ścieżka dochodzenia do przyczyn źródłowych i wykazanie błędu braku ładu korporacyjnego nad API (Student 3).
• Plan CAP i nowa architektura WAAP oraz procedury prawne RODO (4 min): Prezentacja wdrożenia tokenów OAuth2 z mTLS, polityk Rate Limiting, procedury interwencji ludzkiej w scoringu (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Odpowiedzi na pytania problemowe i uwarunkowania prawne:

• W jaki sposób art. 22 RODO reguluje prawo osoby fizycznej do niepodlegania decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu (w tym profilowaniu) i jak w praktyce zapewnić "prawo do interwencji ludzkiej" w procesie scoringu kredytowego?
• Jakie są najczęstsze podatności wg rankingu OWASP API Security Top 10 (np. Broken Object Level Authorization - BOLA, Unrestricted Resource Consumption) i jak skutecznie zabezpieczyć bramę API przed atakami credential stuffing?
• W jaki sposób zaprojektować mechanizm zautomatyzowanej retencji danych w relacyjnej bazie danych, aby zapewnić bezpowrotne i bezpieczne usuwanie lub anonimizację wpisów po upływie ustawowego terminu (zgodnie z normą ISO/IEC 27001 kontrola A.8.10)?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3 dla 6 scenariuszy zagrożeń rejestru informacji gospodarczej.
• Zestawienie Kart Niezgodności: Pełne formularze dla 2 Niezgodności Dużych (NC1 - brak praw z art. 22 RODO przy profilowaniu, NC1 - brak zabezpieczeń API), 1 Niezgodności Małej (NC2 - brak automatycznej retencji) oraz 1 OFI (wdrożenie WAAP).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla incydentu scrapingu danych przez API.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Rekonfiguracja bramy API: wdrożenie ścisłych limitów zapytań (Rate Limiting) per klucz klienta, blokada starych wersji TLS 1.0/1.1 i wymuszenie uwierzytelniania mTLS dla instytucji finansowych (Właściciel: Główny Architekt API i Chmury, Termin: 14 dni, KPI: redukcja anomalnych zapytań o 100%).
  • Zadanie CAP-2: Opracowanie i wdrożenie procedury obsługi żądań klientów dotyczących wyjaśnienia i zakwestionowania decyzji scoringowej (Manual Scoring Review) z powołaniem Zespołu Analityków Ryzyka (Właściciel: Dyrektor Pionu Prawnego i IOD, Termin: 21 dni, KPI: wdrożenie formularza odwoławczego z czasem odpowiedzi < 7 dni).
  • Zadanie CAP-3: Zaimplementowanie zautomatyzowanego skryptu retencji bazy danych z czyszczeniem lub pseudonimizacją rekordów starszych niż terminy ustawowe (Właściciel: Główny Administrator Baz Danych, Termin: 30 dni, KPI: usunięcie 100% przedawnionych wpisów).
  • Zadanie CAP-4: Pełna aktualizacja Polityki Bezpieczeństwa Informacji o Standard API Governance i wytyczne OWASP API Security (Właściciel: CISO InfoVeritas, Termin: 60 dni, KPI: zatwierdzenie dokumentu przez Zarząd).
• Wzorcowy regulamin: "Procedura Bezpiecznego Udostępniania Danych Gospodarczych Poprzez Interfejsy Programistyczne (API Governance)".

C. Wady i zalety proponowanego rozwiązania:

• Zalety: Wyeliminowanie ryzyka gigantycznych kar od Prezesa UODO; skuteczne zablokowanie wycieków danych dłużników i numerów PESEL; podniesienie reputacji InfoVeritas jako bezpiecznego i etycznego partnera sektora bankowego; pełna przejrzystość algorytmiczna.
• Wady i trudności: Konieczność modyfikacji integracji po stronie części mniejszych klientów korzystających z przestarzałych mechanizmów TLS; dodatkowe koszty etatowe związane z zatrudnieniem analityków do manualnej weryfikacji odwołań scoringowych.

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (kontrole A.8.10 Usuwanie informacji, A.8.24 Użycie kryptografii, A.8.26 Wymagania bezpieczeństwa aplikacji).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 1 lit. e, art. 22, art. 32.
• Ustawa z dnia 9 kwietnia 2010 r. o udostępnianiu informacji gospodarczych i wymianie danych gospodarczych (Dz.U. z 2023 r. poz. 2160 z późn. zm.).
• OWASP (Open Web Application Security Project): "OWASP API Security Top 10", 2023.
• Europejska Rada Ochrony Danych (EROD): "Wytyczne w sprawie zautomatyzowanego podejmowania decyzji w indywidualnych przypadkach i profilowania do celów rozporządzenia 2016/679", Bruksela.
• Urząd Ochrony Danych Osobowych: "Zasady bezpiecznego korzystania z interfejsów programistycznych (API) w przetwarzaniu danych osobowych", Warszawa 2023.

• U2 Student bezbłędnie diagnozuje zaawansowane luki w architekturze API oraz w procesach profilowania algorytmicznego i kwalifikuje je do NC1/NC2/OFI.
• U1 Student projektuje kompleksowe procedury API Governance i transparentnego scoringu zgodne z RODO i normami ISO.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla systemów wielkoskalowego przetwarzania danych finansowo-gospodarczych.
• U4 Student realizuje procedurę Root Cause Analysis (5 Why) i konstruuje wykonalny Plan Działań Korygujących (CAP).
• W1W2W3 Student dogłębnie zna rygory prawne dotyczące profilowania RODO, Prawa bankowego, ustawy o BIG oraz standardów bezpieczeństwa OWASP API.
• K1K2 Student wykazuje wysokie poczucie sprawiedliwości społecznej, etyki algorytmicznej i ochrony praw konsumenta w gospodarce cyfrowej.
• ================================================================================