Laboratorium 4

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie kompleksowego, symulowanego audytu cyberodporności i architektury zarządzania tożsamością i dostępem (IAM) w wielospecjalistycznym szpitalu klinicznym o statusie Podmiotu Kluczowego w rozumieniu Dyrektywy NIS2 oraz operatora infrastruktury krytycznej ochrony zdrowia. Placówka łączy przetwarzanie wielomilionowych zbiorów danych onkologicznych i genetycznych (art. 9 RODO) z wdrożeniem algorytmów AI wysokiego ryzyka (diagnostyka histopatologiczna w chmurze) oraz rozległą siecią aparatury podtrzymującej życie (IoMT). Zadanie stawia studentów w roli audytorów badających krytyczny incydent medyczny wywołany brakiem rozliczalności i błędem dawkowania chemioterapii na wspólnej sesji HIS, brak procedury ratunkowej Break-Glass oraz brak MFA. Zadanie rozwija biegłość w realizacji audytu w formule Triady Audytorskiej, sformułowania ustaleń w kanonicznym modelu 4C, kwantyfikacji ryzyka w 25-stopniowej matrycy 5x5 skorelowanej ze wskaźnikami ciągłości działania (RTO/RPO/MTPD), skonstruowania trójfazowego Planu CAP oraz przygotowania Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Dyrekcji Szpitala.

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

• W1 Zaawansowana ochrona danych szczególnej kategorii (onkologia, genomika, art. 9 RODO), tajemnicy lekarskiej i farmaceutycznej oraz odpowiedzialności karnej za błędy medyczne.
• W2W3 Rygorystyczna korelacja wymagań Dyrektywy NIS2 (art. 21, 23), Aktu o Sztucznej Inteligencji (AI Act - systemy medyczne High-Risk), normy PN-EN ISO/IEC 27001:2022 (A.5.15-A.5.18, A.8.2, A.8.5), ISO 27799 oraz standardów Centrum Monitorowania Jakości (CMJ).
• U1 Opracowanie zintegrowanego Standardu Architektury IAM dla szpitala onkologicznego opartego na modelu Zero Trust, kartach zbliżeniowych PKI/RFID, technologii Fast User Switching oraz bezpiecznej procedurze Break-Glass.
• U2 Profesjonalna identyfikacja i formalna gradacja niezgodności w modelu 4C (Condition, Criteria, Cause, Consequence) z analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka risk-based w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących, wyznaczenie parametrów BCM: RTO (15 minut) i RPO (0 minut) dla dostępu do danych ratujących życie.
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Podsumowania Zarządczego w formacie Pitch to Board.
• K1K2K3 Niezależność osądu audytorskiego, bezkompromisowa ochrona życia i prywatności pacjentów, odporność na presję kliniczną i obrona ustaleń przed Komitetem Bezpieczeństwa Szpitala.
• Powiązanie z wykładem: Wyk1 (Ład SZBI w ochronie zdrowia), Wyk3 (Kontrole dostępowe ISO 27001), Wyk4 (Zbieżność NIS2, RODO art. 9 i AI Act), Wyk5 (Risk-based audit ISO 27005 i BCM), Wyk6 (Analiza logów zdarzeń logowania Event 4624/4672 w AD i HIS), Wyk7 (Model 4C, 5 Why i trójfazowy CAP).

Wojewódzki Szpital Zespolony i Centrum Onkologii dysponuje bazą 950 łóżek, 16 salami operacyjnymi, oddziałami transplantologii szpiku, chemioterapii dziennej i radioterapii oraz lądowiskiem ratunkowym. Szpital zatrudnia 1 850 pracowników personelu medycznego (380 lekarzy, 850 pielęgniarek, 140 diagnostów, 200 ratowników medycznych) oraz ponad 120 lekarzy dyżurnych na kontraktach cywilnoprawnych. W ciągu roku placówka hospitalizuje 65 000 pacjentów onkologicznych i podaje ponad 90 000 wlewów cytostatyków.

Infrastruktura teleinformatyczna i stan krytyczny zarządzania dostępem:

• Podstawowym środowiskiem pracy jest Szpitalny System Informacyjny (HIS) zintegrowany z bazą PACS (obrazy PET/CT o wolumenie 1,4 PB), systemem LIS oraz klastrem diagnostyki AI w chmurze AWS wspomagającym wykrywanie zmian nowotworowych.
• Przebieg incydentu kryzysowego: Na oddziale onkologii doszło do podania pacjentce potrójnej dawki leku cytostatycznego o wysokiej toksyczności, co wywołało wstrząs kardiogenny i konieczność natychmiastowej reanimacji na OIOM. Dochodzenie wewnętrzne wykazało, że modyfikacji zlecenia w systemie HIS dokonano z terminala pielęgniarskiego zalogowanego na konto oddziałowej pielęgniarki, która w tym czasie przebywała poza szpitalem na urlopie. Na oddziale powszechną praktyką było logowanie stacji roboczych na jedno wspólne konto domenowe "onkologia_dyzur", a w aplikacji HIS lekarze i pielęgniarki pracowali na permanentnie otwartej sesji pierwszej osoby rozpoczynającej zmianę (ze względu na czas logowania trwający 65 sekund).
• W trakcie reanimacji pacjentki lekarz anestezjolog z SOR nie mógł uzyskać wglądu do historii leczenia kardiologicznego pacjentki w systemie HIS z powodu braku uprawnień do bazy innego oddziału. Szpital nie posiadał technicznej procedury Break-Glass (dostęp awaryjny), a uzyskanie zgody telefonicznej ordynatora trwało 18 minut, stwarzając bezpośrednie zagrożenie zgonu chorej.
• Audyt kontrolerów Active Directory i chmury AWS wykazał, że zewnętrzny model AI posiada stałe uprawnienia odczytu bazy PACS przez nieszyfrowany tunel VPN bez MFA, a 54 byłych lekarzy rezydentów zachowało aktywne konta domenowe z uprawnieniami zdalnego logowania przez portal webowy szpitala.
• Rejestry logów Event Log kontrolerów domeny (Event ID 4624 - Logon Type 2/10, Event ID 4672) nie rejestrują unikalnego identyfikatora użytkownika fizycznego, uniemożliwiając prokuraturze ustalenie sprawcy sfałszowania dawki leku.

Rzecznik Praw Pacjenta, Prokuratura Okręgowa oraz Ministerstwo Zdrowia wszczęły postępowania wyjaśniające. Dyrekcja Szpitala powołuje zespół audytorów do przeprowadzenia natychmiastowego audytu strategicznego IAM w formule 90 minut, wyliczenia ryzyka 5x5, sformułowania ustaleń w modelu 4C i przygotowania trójfazowego Planu CAP.

Zadanie laboratoryjne realizowane jest w 2-3 osobowej Triadzie Audytorskiej w ściśle kontrolowanym reżimie czasowym:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (reprezentuje kierownictwo audytu, odpowiada za spójność z NIS2/RODO/AI Act, redaguje Executive Summary, moderuje obronę przed Dyrekcją).
    • Rola B: Technical SecOps Auditor (analizuje logi AD Event 4624/4672, architekturę HIS/PACS, projektuje middleware Fast User Switching, karty PKI/RFID i protokół FIDO2).
    • Rola C: BCM & Compliance Auditor (konstruuje matrycę ryzyka 5x5, wyznacza metryki RTO/RPO, prowadzi analizę 5 Why dla błędu lekowego, opracowuje trójfazowy Plan CAP).
  • Błyskawiczna analiza dowodów: Zestawienie dowodów ze stacji dyżurnych, logów bazy HIS i wykazów kadrowych; identyfikacja naruszeń art. 5 ust. 2 RODO (rozliczalność), art. 21 NIS2 oraz standardów akredytacyjnych CMJ.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla zniesienia rozliczalności i błędu w chemioterapii.
  • Przeprowadzenie pełnego dochodzenia 5 Why dochodzącego do braku zintegrowanej strategii technologiczno-klinicznej.
  • Skonstruowanie zaawansowanej matrycy ryzyka 5x5 dla 4 kluczowych wektorów (błąd lekowy na wspólnej sesji, brak Break-Glass w reanimacji, kompromitacja kont rezydentów, niekontrolowany dostęp modelu AI do PACS).
  • Wyznaczenie parametrów ciągłości działania BCM: RTO = 15 minut dla przywrócenia tożsamości, RTO = 0 sekund dla trybu Break-Glass, RPO = 0 minut dla wpisów lekowych.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa IAM i Trójfazowy Plan CAP.
  • Opracowanie Standardu Architektury Bezpiecznego Logowania Klinicznego: technologia "Tap-in / Tap-out" z kartami mikroprocesorowymi PKI/RFID (czas przełączenia sesji < 2 sekundy), eliminacja haseł manualnych na rzecz PIN + karta.
  • Projekt Procedury "Dostęp Awaryjny Break-Glass do Danych Medycznych w Stanach Nagłych": jednoklikowe otwarcie pełnego rekordu medycznego z natychmiastowym sygnałem alarmowym do IOD/CISO i rejestracją wideo sesji.
  • Zestawienie Trójfazowego Planu Działań Korygujących (CAP): Faza 1 (0-7 dni - natychmiastowe mitygacje), Faza 2 (30 dni - wdrożenie kart i Break-Glass), Faza 3 (90 dni - pełny ład IGA/NIS2).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Dyrekcją.
  • Opracowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") w formacie: Ekspozycja na ryzyko, Zagrożenia sankcjami (do 10 mln EUR z NIS2 i 20 mln EUR z RODO), Wnioskowany budżet CAP, Matryca korzyści (Quick Wins vs Inwestycje Strategiczne).
  • 5-minutowa obrona ustna przed prowadzącym laboratorium wcielającym się w rolę Dyrektora Szpitala.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, klauzule poufności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza, ekspozycja finansowo-prawna, wnioskowane środki, macierz priorytetów).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zbieżności regulacyjnej (korelacja wymogów: NIS2 Podmiot Kluczowy, RODO art. 9 i 32, AI Act dla wyrobów medycznych, standardy CMJ, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania:
  • Skala prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Analiza ryzyka inherentnego (IR) oraz rezydualnego (RR) wraz z metrykami BCM (RTO, RPO, MTPD).
• Rozdział 4: Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa Informacji: "Standard Kontroli Dostępu Klinicznego, Ergonomii Uwierzytelniania i Procedury Ratunkowej Break-Glass".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz bilansu korzyści wdrożenia architektury IAM w realiach szpitalnych.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Błędu Lekowego na Wspólnej Sesji HIS:

• Condition (Stan faktyczny): Stacje robocze na oddziale onkologii pracują na wspólnym koncie domenowym "onkologia_dyzur", a sesje aplikacji HIS pozostają otwarte przez 12 godzin na koncie jednej pielęgniarki. W wyniku braku rozliczalności wprowadzono nieprawidłową dawkę cytostatyku, doprowadzając do zapaści pacjentki, a brak procedury Break-Glass opóźnił reanimację o 18 minut.
• Criteria (Kryterium): ISO/IEC 27001:2022 Załącznik A.5.15, A.5.16, A.5.18, A.8.5 (Bezpieczne uwierzytelnianie i rozliczalność), art. 5 ust. 2 i art. 32 RODO, Dyrektywa NIS2 art. 21 ust. 2 lit. a i e, Ustawa o prawach pacjenta art. 26.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego personel pracował na sesji nieobecnej pielęgniarki? Bo ponowne logowanie do HIS trwało ponad 60 sekund i blokowało obsługę kolejnych pacjentów.

  2. Dlaczego logowanie trwało tak długo i wymagało manualnego wpisywania 14-znakowego hasła? Bo Dział IT wdrożył restrykcyjną politykę haseł domenowych bez zapewnienia narzędzi szybkiej autoryzacji zbliżeniowej.

  3. Dlaczego nie wdrożono kart zbliżeniowych i technologii Fast User Switching? Bo kierownictwo IT uznało, że zakup czytników RFID i licencji middleware jest zbędnym wydatkiem.

  4. Dlaczego Dyrekcja Szpitala nie wymusiła ergonomicznych narzędzi IAM na styku z systemami ratującymi życie? Bo kwestie bezpieczeństwa informacji były traktowane jako biurokratyczny narzut, a nie element jakości procedur medycznych.

  5. Dlaczego dopuszczono do rozbieżności między ergonomią kliniczną a bezpieczeństwem? (PRZYCZYNA ŹRÓDŁOWA): Brak w szpitalu Zintegrowanego Systemu Zarządzania Bezpieczeństwem Informacji (ISMS) łączącego analizę ryzyka klinicznego z budżetowaniem technologii ochronnych, co doprowadziło do wykształcenia się powszechnego zjawiska obchodzenia zabezpieczeń (opór ergonomiczny) zagrażającego życiu chorych.

• Consequence (Wielowymiarowy skutek): Zagrożenie życia pacjentki i zapaść krążeniowa; postępowanie prokuratorskie o narażenie na bezpośrednie niebezpieczeństwo utraty życia (art. 160 KK); ryzyko administracyjnej kary pieniężnej od Prezesa UODO (do 20 mln EUR) oraz sankcji z Dyrektywy NIS2 (do 10 mln EUR lub 2% obrotu); utrata akredytacji CMJ i kontraktu z NFZ na leczenie onkologiczne o wartości 85 mln PLN rocznie.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

(IR = Ryzyko Inherentne w skali 1-25; RR = Ryzyko Rezydualne w skali 1-25).

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 4 do Polityki Bezpieczeństwa Informacji: Standard Zarządzania Dostępem Klinicznym, Szybkiej Autoryzacji i Trybu Ratunkowego Break-Glass w Wojewódzkim Szpitalu Zespolonym":

• Par. 1: Bezwzględny zakaz stosowania kont generycznych i współdzielonych na stacjach roboczych w dyżurkach i salach zabiegowych pod rygorem odpowiedzialności dyscyplinarnej.
• Par. 2: Wdrożenie uwierzytelniania dwuskładnikowego w technologii zbliżeniowej (karta mikroprocesorowa PKI + 4-cyfrowy kod PIN). Czas przełączenia sesji klinicznej HIS nie może przekraczać 3 sekund.
• Par. 3: Procedura Break-Glass: w sytuacji nagłego zagrożenia życia pacjenta każdy lekarz dyżurny ma prawo aktywować tryb dostępu ratunkowego za pomocą pojedynczego kliknięcia. Aktywacja powoduje: (a) natychmiastowe odblokowanie pełnej historii choroby, (b) wygenerowanie powiadomienia SMS/e-mail do CISO i IOD w czasie rzeczywistym, (c) rejestrację wideo sesji ekranowej, (d) obowiązek złożenia pisemnego raportu klinicznego w ciągu 12 godzin od zakończenia akcji ratunkowej.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Krytyczna (25/25) w obszarze odpowiedzialności karnej i odszkodowawczej za błędy w sztuce medycznej na anonimowych sesjach.
• Zagrożenia regulacyjne: Kary finansowe UODO (do 20 mln EUR), kary z NIS2 (do 10 mln EUR), utrata kontraktu onkologicznego NFZ (85 mln PLN).
• Wnioskowany budżet CAP: 420 000 PLN (zakup czytników RFID, kart PKI, wdrożenie middleware Fast User Switching i modułu Break-Glass).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Zablokowanie martwych kont rezydentów, awaryjna instrukcja Break-Glass, wymuszenie MFA na VPN (koszt: 0 PLN).
  • Projekty Strategiczne (30-90 dni): Wdrożenie kart zbliżeniowych, integracja IGA z kadrami, pełna zgodność z NIS2 (koszt: 420 000 PLN, TCO 3-letnie: 580 000 PLN).

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

• Zalety: Pełna, bezsporna rozliczalność każdego zlecenia lekarskiego; skrócenie czasu uwierzytelniania personelu o 95%, co likwiduje opór personelu; zagwarantowanie ciągłości ratowania życia przez kontrolowany tryb Break-Glass; ochrona szpitala przed wielomilionowymi odszkodowaniami i karami UODO/NIS2.
• Wady i trudności: Nakłady finansowe na infrastrukturę czytników i kart; konieczność bezwzględnego egzekwowania zakazu pożyczania kart identyfikacyjnych; konieczność stałego monitorowania i wyjaśniania incydentów Break-Glass.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.5.15 (Zarządzanie tożsamością), A.5.16 (Uwierzytelnianie tożsamości), A.5.18 (Prawa dostępu), A.8.5 (Bezpieczne uwierzytelnianie).
• Norma ISO 27799:2016: Health informatics - Information security management in health using ISO/IEC 27002.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - art. 21, 23.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (Akt o sztucznej inteligencji - AI Act) - systemy wysokiego ryzyka w diagnostyce.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 2, art. 9, art. 32.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. z 2023 r. poz. 1545 z późn. zm.).
• Centrum Monitorowania Jakości w Ochronie Zdrowia (CMJ): "Zestaw standardów akredytacyjnych dla szpitali", Kraków.
• NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management.

• U1 Student projektuje zaawansowaną architekturę IAM dla placówki medycznej łączącą karty PKI, Fast User Switching i procedurę Break-Glass.
• U2 Student dokumentuje uchybienia w kanonicznym modelu 4C i przeprowadza pełne dochodzenie 5 Why.
• U3 Student wykonuje analizę ryzyka w matrycy 5x5 i wyznacza metryki ciągłości działania (RTO/RPO/MTPD).
• U4 Student sporządza trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student wykazuje ekspercką wiedzę z zakresu NIS2, RODO art. 9, AI Act, ISO 27001 oraz prawa medycznego.
• K1K2K3 Student cechuje się bezkompromisowością w ochronie życia ludzkiego, etyką lekarsko-inżynierską i zdolnością obrony ustaleń przed zarządem.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu kontroli wewnętrznej, rozdziału obowiązków (Segregation of Duties - SoD) oraz architektury autoryzacji transakcyjnej w banku komercyjnym o znaczeniu systemowym, podlegającym rygorom Rozporządzenia DORA, Rekomendacji D Komisji Nadzoru Finansowego (KNF) oraz standardu PCI DSS v4.0. Studenci wcielają się w zespół audytu śledczego badającego udaną próbę wewnętrznego wyprowadzenia środków finansowych (insider fraud) na kwotę 18 mln PLN za pośrednictwem węzła SWIFT Alliance i systemu bankowości centralnej (Oracle FLEXCUBE). Zadanie wymaga zbadania mechanizmów obchodzenia zasady czterech oczu, braku blokad programistycznych Self-Approval, dekompozycji ról transakcyjnych, kwantyfikacji ryzyka w matrycy 5x5 z powiązaniem ze wskaźnikami BCM (RTO=15m, RPO=0), sformułowania ustaleń w modelu 4C z dochodzeniem 5 Why, opracowania trójfazowego Planu CAP oraz sporządzenia Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Komitetu Audytu Rady Nadzorczej.

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

• W1 Ekspercka znajomość Prawa bankowego (tajemnica bankowa art. 104), przepisów o przeciwdziałaniu praniu pieniędzy (AML/CFT) oraz odpowiedzialności zarządu za stabilność finansową.
• W2W3 Precyzyjna korelacja wymagań Rozporządzenia DORA (art. 9, 10, 11), Rekomendacji D KNF (Rekomendacje 9, 10, 11), normy ISO/IEC 27001:2022 (A.5.3, A.5.15, A.5.17, A.8.5), standardu SWIFT CSP v2024 oraz PCI DSS v4.0.
• U1 Opracowanie zintegrowanego Standardu Architektury SoD i Podwójnej Autoryzacji Transakcyjnej z centralnym silnikiem dynamicznego poolingu zadań i tokenami sprzętowymi FIDO2.
• U2 Identyfikacja i dokumentowanie uchybień w kanonicznym modelu 4C z dogłębną analizą przyczyn źródłowych (Root Cause Analysis - 5 Why).
• U3 Przeprowadzenie analizy ryzyka operacyjnego i fraudu w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formule Pitch to Board.
• K1K2K3 Bezwzględna dociekliwość audytorska, bezstronność wobec presji biznesowej banku, najwyższa etyka zawodowa i odporność w relacjach z kadrą C-Level.
• Powiązanie z wykładem: Wyk1 (Audyt w sektorze finansowym), Wyk3 (Kontrola A.5.3 SoD i kontrole kryptograficzne), Wyk4 (DORA i Rekomendacja D KNF), Wyk5 (Risk-based audit i matryca 5x5), Wyk6 (Sampling transakcji SWIFT i analiza logów finansowych), Wyk7 (Model 4C, 5 Why i raportowanie do Komitetu Audytu).

Bank Komercyjny "Vistula Bank S.A." obsługuje 1,8 miliona klientów detalicznych i korporacyjnych, przetwarza dziennie ponad 1,2 miliona transakcji płatniczych oraz rozlicza transakcje skarbowe w walutach obcych o wolumenie przekraczającym 2 miliardy PLN na dobę. Węzeł komunikacji międzybankowej SWIFT Alliance Access jest połączony bezpośrednio z systemem bankowości centralnej Oracle FLEXCUBE.

Przebieg incydentu i krytyczne ustalenia audytu śledczego:

• Zespół audytu wewnętrznego i Departament Bezpieczeństwa zidentyfikowały nieautoryzowany transfer wychodzący SWIFT MT103 na kwotę 4,2 miliona EUR (ok. 18 mln PLN) do banku w jurysdykcji podwyższonego ryzyka w Azji Południowo-Wschodniej.
• Dochodzenie wykazało, że transakcję przygotował starszy specjalista ds. rozliczeń walutowych, który wykorzystał fakt, że w systemie FLEXCUBE nie wdrożono bezwzględnej blokady Self-Approval: pracownik wprowadził fikcyjną dyspozycję płatniczą, a następnie za pomocą pożyczonego tokena autoryzacyjnego kierownika wydziału (który wyszedł na przerwę obiadową, pozostawiając odblokowaną stację roboczą) dokonał drugiego zatwierdzenia dyspozycji w odstępie 4 sekund.
• W trakcie analizy profili uprawnień w całym banku wykryto, że w 48 placówkach partnerskich dyrektorzy oddziałów posiadają tzw. super-profile placówkowe, łączące uprawnienia do: (1) modyfikacji danych klienta w CRM, (2) otwierania linii kredytowych, (3) wprowadzania przelewów, oraz (4) ostatecznego zatwierdzania wypłat.
• W module komunikacji SWIFT czterech dealerów walutowych posiadało jednocześnie uprawnienia do edycji szablonów komunikatów (RMA Message Author) oraz ich podpisywania kluczem kryptograficznym HSM (SWIFT Release Signer).
• W logach transakcyjnych i bazodanowych Oracle DBA posiada bezpośrednie uprawnienia zapisu do tabeli `GL_BALANCES` (księga główna), a zapytania SQL nie są przekazywane do systemu DAM ani SIEM w SOC.

Urząd Komisji Nadzoru Finansowego (UKNF) wszczął doraźną kontrolę z rygorem zawieszenia licencji bankowej w zakresie rozliczeń międzynarodowych, nakazując pilne wdrożenie Planu CAP i usunięcie zidentyfikowanych luk SoD.

Zadanie laboratoryjne realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (odpowiada za relacje z Komitetem Audytu i UKNF, analizę DORA/KNF, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje konfigurację ról w Oracle FLEXCUBE, SWIFT Alliance, bada tokeny HSM, projektuje blokady kodowe Self-Approval i centralny pooling autoryzacji).
    • Rola C: BCM & Compliance Auditor (konstruuje matrycę ryzyka 5x5, wyznacza wskaźniki RTO/RPO dla transakcji płatniczych, prowadzi analizę 5 Why dla incydentu SWIFT, tworzy trójfazowy Plan CAP).
  • Analiza dowodów: Badanie logów transakcyjnych SWIFT, czasów zatwierdzeń, adresów IP/MAC oraz rejestrów uprawnień użytkowników w FLEXCUBE.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla obejścia zasady czterech oczu i kradzieży 18 mln PLN.
  • Przeprowadzenie analizy 5 Why wskazującej na przedkładanie celów operacyjnych nad kontrolę wewnętrzną.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych wektorów (insider fraud w placówce, manipulacja komunikatami SWIFT, ręczna zmiana salda w bazie Oracle przez DBA, sankcje UKNF/DORA).
  • Wyznaczenie metryk BCM: RTO = 15 minut dla przywrócenia integralności bazy transakcyjnej, RPO = 0 transakcji (zero tolerancji dla utraty danych finansowych), MTPD = 2 godziny.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa SoD i Trójfazowy Plan CAP.
  • Opracowanie Standardu Matrycy Konfliktów SoD oraz Architektury Centralnego Poolingu Autoryzacji: dyspozycje powyżej 50 000 PLN z małych oddziałów są losowo kolejkowane do zatwierdzenia przez pracowników centrali, wykluczając zmowę lokalną.
  • Projekt blokady Self-Approval na poziomie jądra bazy i aplikacji (mechanizm kryptograficznej walidacji unikalności tożsamości z użyciem kluczy sprzętowych FIDO2).
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - twarde blokady i cofnięcie super-profili), Faza 2 (30 dni - centralny pooling i DAM dla DBA), Faza 3 (90 dni - pełne wdrożenie platformy IGA i audyt SWIFT CSP).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Komitetem Audytu.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z kalkulacją wskaźnika zwrotu z inwestycji bezpieczeństwa (ROSI) i matrycą priorytetów.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Przewodniczącego Rady Nadzorczej.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o braku konfliktu interesów).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: ekspozycja na ryzyko fraudu, straty bilansowe, wnioskowany budżet CAP, rekomendacje natychmiastowe).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności bankowej (DORA art. 9-11, Rekomendacja D KNF, PCI DSS v4.0 Wymóg 7/8, SWIFT CSP v2024, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Obliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=15m, RPO=0, MTPD=2h.
• Rozdział 4: Projekt Załącznika Wykonawczego do Polityki Bezpieczeństwa: "Matryca Rozdziału Obowiązków (SoD Matrix) oraz Standard Podwójnej Autoryzacji i Centralnego Poolingu Zadań Transakcyjnych".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz ograniczeń wdrożeniowych proponowanych rozwiązań.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Obejścia Zasady 4 Oczu i Wyłudzenia 18 mln PLN:

• Condition (Stan faktyczny): Brak programistycznej blokady Self-Approval w systemie Core Banking oraz pozostawienie odblokowanej sesji kierownika pozwoliło specjaliście na samodzielne wprowadzenie i zatwierdzenie przelewu SWIFT na kwotę 4,2 mln EUR w odstępie 4 sekund. W 48 oddziałach dyrektorzy posiadają super-profile łączące uprawnienia wprowadzania i akceptacji.
• Criteria (Kryterium): ISO/IEC 27001:2022 Załącznik A.5.3 (Rozdział obowiązków), A.5.15, A.8.5, Rozporządzenie DORA art. 9 i 10, Rekomendacja D KNF (Rekomendacje 9.1, 10.2, 11.1), SWIFT CSP v2024 kontrola 1.2 i 5.1.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego pracownik mógł zatwierdzić własną dyspozycję? Bo zalogował się z odblokowanej stacji kierownika za pomocą pożyczonego tokena.

  2. Dlaczego system pozwolił na zatwierdzenie transakcji z tego samego adresu IP i w tak krótkim czasie? Bo mechanizm walidacji sesji nie sprawdzał tożsamości biometrycznej ani nie blokował zatwierdzeń z tego samego hosta.

  3. Dlaczego w parametrach FLEXCUBE wyłączono blokadę Self-Approval? Bo wdrożenie blokady powodowało zatory w małych placówkach partnerskich podczas urlopów pracowników.

  4. Dlaczego bank nie wdrożył centralnego poolingu autoryzacji dla oddziałów? Bo Departament Sprzedaży obawiał się wydłużenia czasu obsługi klienta i utraty prowizji transakcyjnych.

  5. Dlaczego cele sprzedażowe przeważyły nad kontrolą wewnętrzną? (PRZYCZYNA ŹRÓDŁOWA): Brak w banku nadrzędnego ładu zarządzania tożsamością i ryzykiem operacyjnym (IAM Governance) posiadającego prawo weta wobec procesów biznesowych oraz brak formalnej polityki SoD sankcjonującej nadrzędność Rekomendacji D nad celami komercyjnymi.

• Consequence (Wielowymiarowy skutek): Bezpośrednia strata finansowa 18 mln PLN; ryzyko sankcji administracyjnej UKNF (kara do 10% przychodu banku lub cofnięcie zgody na pełnienie funkcji przez członków Zarządu); utrata certyfikacji SWIFT CSP i wykluczenie z sieci rozliczeń międzynarodowych; spadek kursu akcji banku na GPW o 8,5% w dniu ujawnienia incydentu.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do Polityki Bezpieczeństwa:

"Załącznik nr 7 do Polityki Bezpieczeństwa Informacji: Standard Rozdziału Obowiązków (SoD), Zapobiegania Konfliktom Ról oraz Autoryzacji Czterech Oczu w Vistula Bank S.A.":

• Par. 1: Zasada bezwzględnego rozdziału ról wprowadzającego (Maker) i zatwierdzającego (Checker). Żadna dyspozycja transakcyjna powyżej 0,01 PLN nie może zostać sfinalizowana jednoosobowo.
• Par. 2: Bezwzględna blokada systemowa Self-Approval: system Core Banking uniemożliwia zatwierdzenie dyspozycji przez użytkownika o tym samym identyfikatorze cyfrowym, adresie IP stacji roboczej lub numerze seryjnym tokena FIDO2.
• Par. 3: Procedura Centralnego Poolingu Zadań: w placówkach zatrudniających poniżej 4 osób zadania zatwierdzające są automatycznie kierowane do ogólnobankowej kolejki w Departamencie Operacji Centralnych i losowo przydzielane dyżurnym autoryzatorom.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Ekstremalna (25/25) - wyłudzenie 18 mln PLN ujawniło systemowe luki w kontroli wewnętrznej.
• Zagrożenia regulacyjne: Sankcje UKNF, utrata dostępu do sieci SWIFT, utrata reputacji i zaufania deponentów.
• Wnioskowany budżet CAP: 1 150 000 PLN (wdrożenie modułu DAM, klucze FIDO2, silnik poolingu i wdrożenie platformy IGA).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Twarda blokada Self-Approval, likwidacja super-profili w oddziałach (koszt: 25 000 PLN).
  • Projekty Strategiczne (30-90 dni): Centralny pooling zadań, monitorowanie baz DAM, platforma IGA (koszt: 1 125 000 PLN, TCO 3-letnie: 1 650 000 PLN).

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

• Zalety: Całkowita eliminacja ryzyka nadużyć wewnętrznych; 100% zgodność z DORA, Rekomendacją D KNF i SWIFT CSP; pełna rozliczalność transakcji; ochrona licencji bankowej i reputacji instytucji zaufania publicznego.
• Wady i trudności: Niewielkie wydłużenie czasu autoryzacji w placówkach filialnych (o ok. 45-60 sekund); konieczność przeszkolenia personelu sprzedaży; wysoki koszt licencyjny zaawansowanych systemów DAM i IGA.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.3, A.5.15, A.5.17, A.8.5.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) - art. 9, 10, 11.
• Komisja Nadzoru Finansowego: Rekomendacja D dotycząca zarządzania obszarami IT i teleinformatyki w bankach (Rekomendacje 9, 10, 11).
• SWIFT Customer Security Programme (CSP) - Customer Security Controls Framework v2024.
• Payment Card Industry Data Security Standard (PCI DSS) v4.0 - Requirements 7 and 8.
• Ustawa z dnia 29 sierpnia 1997 r. - Prawo bankowe (Dz.U. z 2023 r. poz. 2488 z późn. zm.).
• ISACA: Segregation of Duties Control Matrix and Guidelines for Banking Applications, 2023.

• U1 Student projektuje zaawansowaną matrycę SoD, silnik poolingu autoryzacji oraz bezpieczne reguły podwójnej kontroli transakcyjnej.
• U2 Student dokumentuje uchybienia w modelu 4C i prowadzi wieloetapowe dochodzenie przyczyn źródłowych 5 Why.
• U3 Student wykonuje analizę ryzyka nadużyć w matrycy 5x5 i wyznacza metryki ciągłości działania (RTO/RPO/MTPD).
• U4 Student opracowuje trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna regulacje DORA, Rekomendację D KNF, standardy SWIFT CSP i PCI DSS v4.0.
• K1K2K3 Student cechuje się bezkompromisowością wobec naruszeń kontroli wewnętrznej, dociekliwością śledczą i etyką bankową.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu strategicznego i operacyjnego procesów zarządzania cyklem życia tożsamości (Joiner, Mover, Leaver - JML) oraz federacji tożsamości w wielopodmiotowej administracji samorządowej szczebla wojewódzkiego. Samorządowe Centrum Usług Wspólnych Informatyki (SCUWI) świadczy usługi centralnej poczty, hostingu oraz systemu EZD RP dla Urzędu Marszałkowskiego i 35 jednostek podległych (szpitale, teatry, zarząd dróg, biblioteki, ośrodki polityki społecznej). Zadanie stawia studentów w roli audytorów badających masowy incydent wycieku danych z postępowań przetargowych i planów zagospodarowania przestrzennego przez aktywne konta byłych urzędników ("konta widma"), brak synchronizacji systemów kadrowych z Active Directory, niekontrolowane tokeny federacyjne SAML 2.0 oraz zjawisko akumulacji ról (privilege creep). Zadanie wymaga zastosowania metodyki Triady Audytorskiej, modelu 4C, matrycy ryzyka 5x5 skorelowanej ze wskaźnikami BCM, procedury 5 Why, trójfazowego Planu CAP oraz opracowania Executive Summary dla Marszałka Województwa.

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

• W1 Ekspercka znajomość tajemnic prawnie chronionych w administracji (tajemnica skarbowa, ochrona danych obywateli, tajemnica przetargowa).
• W2W3 Wyczerpująca znajomość Rozporządzenia w sprawie Krajowych Ram Interoperacyjności (par. 20 KRI), RODO (art. 5 ust. 1 lit. f, art. 5 ust. 2, art. 32), Ustawy o KSC, Dyrektywy NIS2 oraz normy ISO/IEC 27001:2022 (A.5.15, A.5.18, A.8.2, A.8.5).
• U1 Opracowanie zintegrowanego modelu zautomatyzowanego cyklu życia tożsamości (JML) opartego na protokole SCIM i PowerShell oraz bezpiecznej architektury federacji SAML/OIDC dla EZD RP.
• U2 Identyfikacja i dokumentowanie uchybień w kanonicznym modelu 4C z analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka wycieku rejestrów publicznych w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formacie Pitch to Board.
• K1K2K3 Obiektywizm, poszanowanie praworządności, odporność na inercję urzędniczą i skuteczność w egzekwowaniu ładu bezpieczeństwa w skali regionu.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji), Wyk3 (Kontrole A.5.18 i A.8.5 ISO 27001), Wyk4 (KRI, RODO i KSC w samorządzie), Wyk5 (Risk-based audit i matryca 5x5), Wyk6 (Konfrontacja rejestrów HR z Active Directory i logami SAML), Wyk7 (Model 4C, 5 Why i raportowanie do Marszałka).

Samorządowe Centrum Usług Wspólnych Informatyki (SCUWI) zarządza centralnym węzłem teleinformatycznym obsługującym 4 200 urzędników i pracowników samorządowych w 36 jednostkach budżetowych województwa. W centralnym repozytorium Active Directory oraz chmurze Microsoft Entra ID zarejestrowanych jest 5 800 tożsamości, a system Elektronicznego Zarządzania Dokumentacją (EZD RP) przetwarza rocznie 1,4 miliona pism i decyzji administracyjnych.

Krytyczne ustalenia audytu i wektory naruszeń:

• Wyciek danych o przetargach infrastrukturalnych: W lokalnych mediach opublikowano poufne oferty przetargowe na budowę obwodnicy wojewódzkiej o wartości 340 mln PLN wraz z arkuszami kalkulacyjnymi zawierającymi dane chronione prawem zamówień publicznych. Analiza śledcza logów EZD RP i serwera ADFS wykazała, że pobrania dokumentów dokonano z adresu IP komercyjnego operatora w godzinach nocnych z użyciem konta byłego zastępcy dyrektora departamentu infrastruktury, który odszedł z pracy 7 miesięcy wcześniej i podjął zatrudnienie u jednego z oferentów przetargu.
• Masowa obecność kont widm (Zombie Accounts): Zespół audytorów przeprowadził automatyczną konfrontację baz kadrowo-płacowych 36 jednostek z bazą obiektów Active Directory. Wyniki analizy:
  • Wykryto 84 aktywne konta osób, które nie figurują na listach płac od co najmniej 90 dni (w tym 14 osób zwolnionych dyscyplinarnie).
  • Z 84 kont widm aż 19 wykazało udane logowania przez serwer VPN lub portal SAML EZD RP w okresie po dacie rozwiązania umowy o pracę.
• Zjawisko niekontrolowanych tokenów federacyjnych SAML 2.0: Czas życia tokenów sesyjnych ADFS został skonfigurowany na 30 dni bez wymuszenia okresowej walidacji statusu konta w AD. W efekcie nawet zablokowanie konta w domenie pozwalało na dalsze korzystanie z aktywnej sesji webowej w EZD RP na prywatnym laptopie urzędnika.
• Zjawisko privilege creep: W toku wywiadów stwierdzono, że pracownicy przenoszeni między wydziałami (Mover) nie tracili starych ról. Kierownik referatu ochrony środowiska posiadał wciąż pełne uprawnienia do akt wydziału kontroli finansowej i postępowań dyscyplinarnych.

Marszałek Województwa, w obliczu kontroli NIK, UODO oraz postępowania CBA, powołuje zespół audytorów do pilnego zbadania ładu tożsamości w formule 90 minut, wyliczenia ryzyka 5x5 i sporządzenia Planu CAP.

Zadanie realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (odpowiada za relacje z Marszałkiem i IOD, zgodność z KRI/RODO/KSC, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje konfigurację AD, skrypty PowerShell, tokeny ADFS/SAML, projektuje automatyzację SCIM i unieważnianie sesji).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza wskaźniki RTO/RPO, prowadzi analizę 5 Why dla wycieku przetargu, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Konfrontacja wykazów kadrowych z logami AD (Event ID 4720, 4726, 4738) oraz logami żądań tokenów SAML w ADFS.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla wycieku danych przez konto widmo i długożyjące tokeny SAML.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why obnażającej brak centralnego ładu JML w samorządzie.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (wyciek przetargów, dostęp byłych pracowników przez SAML, akumulacja uprawnień po awansach, kary Prezesa UODO).
  • Wyznaczenie parametrów BCM: RTO = 1 godzina dla zablokowania konta od momentu odejścia, RPO = 0 minut dla logów audytowych, MTPD = 4 godziny.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa JML i Trójfazowy Plan CAP.
  • Opracowanie Standardu Automatyzacji Cyklu Życia Tożsamości (JML): integracja systemów kadrowych przez API SCIM / skrypty PowerShell, natychmiastowe wygaszanie kont w dniu zwolnienia o godz. 16:00.
  • Rekonfiguracja ADFS: skrócenie czasu życia tokena SAML do 8 godzin, wdrożenie mechanizmu natychmiastowego unieważniania tokenów (Token Revocation) przy zmianie statusu konta w AD.
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - blokada 84 kont widm i skrócenie tokenów), Faza 2 (30 dni - automatyzacja skryptowa HR-AD i wdrożenie MFA), Faza 3 (90 dni - Zarządzenie Marszałka i wdrożenie platformy IGA).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i obrona przed Marszałkiem.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z oceną ekspozycji prawnej i matrycą priorytetów.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Marszałka Województwa.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza luk tożsamości, ryzyka kar UODO, plan naprawczy CAP).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności samorządowej (par. 20 KRI, RODO art. 5 ust. 2 i art. 32, Ustawa o KSC, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=1h, RPO=0, MTPD=4h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Regulamin Zarządzania Cyklem Życia Tożsamości Urzędniczych (JML) oraz Bezpieczeństwa Federacji Tożsamości SAML/OIDC w Samorządowym CUW".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz barier wdrożeniowych integracji wielopodmiotowej.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Wycieku Ofert Przetargowych przez Konto Widmo:

• Condition (Stan faktyczny): Obecność 84 aktywnych kont byłych urzędników w Active Directory oraz 30-dniowe tokeny SAML w systemie EZD RP umożliwiły byłemu dyrektorowi pobranie ofert przetargowych o wartości 340 mln PLN 7 miesięcy po zwolnieniu z pracy.
• Criteria (Kryterium): Rozporządzenie KRI par. 20 ust. 2 pkt 7, 8, 14, art. 5 ust. 1 lit. f oraz art. 32 RODO, ISO/IEC 27001:2022 Załącznik A.5.15, A.5.18, A.8.5, Ustawa o zwalczaniu nieuczciwej konkurencji art. 11.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego konto byłego dyrektora pozostawało aktywne? Bo Dział Kadr jednostki podległej nie powiadomił SCUWI o rozwiązaniu umowy o pracę.

  2. Dlaczego kadry nie powiadomiły SCUWI? Bo obieg dokumentów opierał się na papierowej obiegówce zanoszonej przez pracownika, której odchodzący urzędnik nie oddał.

  3. Dlaczego SCUWI polegało na papierowych obiegówkach w ekosystemie 36 jednostek? Bo brak było zautomatyzowanej integracji systemów kadrowych z Active Directory.

  4. Dlaczego nie wdrożono integracji technicznej? Bo każda z 36 jednostek posiada autonomiczne oprogramowanie kadrowe różnych dostawców i SCUWI nie posiadało budżetu ani uprawnień do wymuszenia standardu.

  5. Dlaczego brakowało centralnych standardów integracji? (PRZYCZYNA ŹRÓDŁOWA): Brak nadrzędnego Zarządzenia Marszałka Województwa powołującego jednolity ład zarządzania tożsamością (Identity Governance) i nakładającego na kierowników jednostek osobistą odpowiedzialność za terminowe wygaszanie tożsamości cyfrowych.

• Consequence (Wielowymiarowy skutek): Unieważnienie postępowania przetargowego na obwodnicę i opóźnienie inwestycji o 18 miesięcy; roszczenia odszkodowawcze oferentów na kwotę kilkunastu milionów złotych; postępowanie prokuratorskie i CBA; kara finansowa Prezesa UODO za naruszenie zasady integralności i poufności (art. 5 ust. 1 lit. f RODO).

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 5 do Regulaminu Bezpieczeństwa Informacji: Standard Zarządzania Cyklem Życia Tożsamości Urzędniczych (JML) oraz Bezpieczeństwa Federacji Tożsamości SAML w Samorządowym CUW":

• Par. 1: Obowiązek natychmiastowego zgłaszania zmian kadrowych: Kierownik Kadr każdej z 36 jednostek ma bezwzględny obowiązek zarejestrowania faktu odejścia pracownika w centralnym portalu kadrowym najpóźniej na 24 godziny przed terminem rozwiązania umowy.
• Par. 2: Automatyczna blokada tożsamości cyfrowej: Skrypt SCIM/PowerShell automatycznie blokuje konto domenowe w Active Directory, unieważnia certyfikaty VPN oraz certyfikaty federacyjne w dniu rozwiązania umowy o godzinie 16:00.
• Par. 3: Standard tokenów federacyjnych SAML 2.0: Czas ważności tokena sesyjnego nie może przekraczać 8 godzin. Brama ADFS ma obowiązek weryfikacji atrybutu `AccountDisabled` w AD w czasie rzeczywistym przed wydaniem każdego kolejnego biletu.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Krytyczna (25/25) - wyciek przetargowy o wartości 340 mln PLN i 84 aktywne konta widma byłych pracowników.
• Zagrożenia regulacyjne: Kary Prezesa UODO, unieważnienie przetargów, odpowiedzialność odszkodowawcza, utrata zaufania publicznego.
• Wnioskowany budżet CAP: 380 000 PLN (automatyzacja łączników HR, wdrożenie platformy Open Source IGA MidPoint, licencje MFA).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Zablokowanie 84 kont widm, skrócenie tokenów SAML w ADFS, audyt uprawnień dyrektorów (koszt: 0 PLN).
  • Projekty Strategiczne (30-90 dni): Wdrożenie platformy IGA, Zarządzenie Marszałka, integracja API ze wszystkimi jednostkami (koszt: 380 000 PLN, TCO 3-letnie: 520 000 PLN).

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

• Zalety: Całkowita likwidacja nieuprawnionego dostępu byłych urzędników do rejestrów publicznych; automatyzacja cyklu życia kont oszczędzająca setki godzin pracy kadr i IT; pełna zgodność z KRI i RODO; przywrócenie transparentności procedur przetargowych.
• Wady i trudności: Konieczność narzucenia dyscypliny kadrowej 36 autonomicznym dyrektorom jednostek; koszty integracji różnorodnych baz kadrowych; ryzyko błędnych blokad w przypadku opóźnień w aneksowaniu umów terminowych.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15, A.5.18, A.8.2, A.8.5.
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (KRI) - par. 20 (Dz.U. z 2024 r. poz. 773).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 1 lit. f, art. 5 ust. 2, art. 32.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Ustawa z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz.U. z 2023 r. poz. 1605 z późn. zm.).
• Evolveum MidPoint: "Identity Governance and Administration in Public Sector - Architectural Guidelines", 2023.

• U1 Student projektuje zintegrowany model automatyzacji cyklu życia tożsamości JML oraz architekturę federacji SAML dla sektora publicznego.
• U2 Student dokumentuje uchybienia w modelu 4C i prowadzi wieloetapowe dochodzenie 5 Why.
• U3 Student szacuje ryzyka kompromitacji rejestrów publicznych w matrycy 5x5 i wyznacza metryki ciągłości działania (RTO/RPO/MTPD).
• U4 Student sporządza trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna przepisy KRI, RODO, ustawy o KSC oraz standardy federacji tożsamości cyfrowej.
• K1K2K3 Student wykazuje determinację w egzekwowaniu ładu bezpieczeństwa w administracji publicznej i odpowiedzialność za dane obywateli.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu cyberodporności oraz zarządzania dostępem uprzywilejowanym (PAM) i tożsamościami maszynowymi w chmurowej instytucji płatniczej (FinTech Cloud Software House) przetwarzającej dane kart płatniczych w reżimie normy PCI DSS v4.0, raportu SOC 2 Type II oraz Rozporządzenia DORA. Studenci wcielają się w rolę audytorów badających krytyczny incydent kompromitacji stałych poświadczeń administratorskich (Standing Privileges) i wycieku tokenów dostępowych AWS IAM, który doprowadził do nieautoryzowanego zrzutu produkcyjnej bazy danych transakcji kartowych z Amazon RDS oraz podsłuchu klastrów Kubernetes (Amazon EKS). Zadanie wymaga dekompozycji architektury tożsamości chmurowej, zbadania podatności statycznych kluczy SSH i sekretów API, kwantyfikacji ryzyka w matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=15m, RPO=0), sformułowania ustaleń w modelu 4C z analizą 5 Why, opracowania trójfazowego Planu CAP wprowadzającego paradygmat Zero Standing Privileges (ZSP) i sesje Just-In-Time (JIT) z sejfem HashiCorp Vault, oraz sporządzenia Podsumowania Zarządczego (Executive Summary - "Pitch to Board") dla Rady Nadzorczej.

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

• W1 Ekspercka znajomość rygorów ochrony danych posiadaczy kart płatniczych (PAN, dane uwierzytelniające SAD), tajemnicy przedsiębiorstwa i tajemnicy płatniczej.
• W2W3 Biegła znajomość PCI DSS v4.0 (Wymagania 7, 8), SOC 2 Type II (Security and Confidentiality Criteria), Rozporządzenia DORA (art. 9, 10), normy ISO/IEC 27001:2022 (A.8.2, A.8.5, A.8.24) oraz NIST SP 800-207 (Zero Trust Architecture).
• U1 Opracowanie zintegrowanego Standardu Architektury Zero Standing Privileges (ZSP) opartego na dynamicznych certyfikatach SSH/K8s, sesjach Just-In-Time z sejfem HashiCorp Vault oraz sprzętowym uwierzytelnianiu FIDO2.
• U2 Identyfikacja i dokumentowanie uchybień w kanonicznym modelu 4C z wieloetapową analizą przyczyn źródłowych (Root Cause Analysis - 5 Why).
• U3 Przeprowadzenie analizy ryzyka kompromitacji infrastruktury chmurowej w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie parametrów BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formacie Pitch to Board.
• K1K2K3 Wysoka kultura inżynierska, bezkompromisowość wobec praktyk "skrótów administratorskich", zdolność do dialogu technologiczno-biznesowego i obrona ustaleń przed CTO i Zarządem.
• Powiązanie z wykładem: Wyk1 (Audyt w FinTech), Wyk3 (Kontrole A.8.2 i A.8.5 ISO 27001), Wyk4 (PCI DSS v4.0, SOC 2 i DORA), Wyk5 (Risk-based audit w chmurze i matryca 5x5), Wyk6 (Analiza logów AWS CloudTrail, VPC Flow Logs i Kubernetes Audit Logs), Wyk7 (Model 4C, 5 Why i raportowanie zarządcze).

FinTech "PayCloud Solutions Sp. z o.o." obsługuje międzynarodową bramkę płatniczą dla 6 500 sklepów internetowych w UE, przetwarzając 25 milionów transakcji kartowych miesięcznie o łącznej wartości 1,2 miliarda EUR. Środowisko produkcyjne działa w modelu AWS Multi-Account (architektura AWS Organizations obejmująca 14 połączonych kont AWS), wykorzystując 12 klastrów Kubernetes (Amazon EKS) oraz bazy Amazon Aurora Serverless PostgreSQL.

Przebieg incydentu i krytyczne ustalenia audytu:

• Naruszenie bezpieczeństwa danych kartowych (Data Breach): Na podziemnym forum cyberprzestępczym wystawiono na sprzedaż bazę zawierającą 320 000 rekordów kart płatniczych (numery PAN, daty ważności, zaszyfrowane skróty PIN) pochodzących z bazy produkcyjnej PayCloud.
• Analiza śledcza logów AWS CloudTrail i Amazon GuardDuty wykazała, że do eksfiltracji danych doszło za pośrednictwem skradzionego stałego klucza API (`AWS_ACCESS_KEY_ID`), należącego do starszego inżyniera DevOps. Klucz posiadał uprawnienia `AdministratorAccess` na koncie produkcyjnym, został wygenerowany 480 dni wcześniej i znajdował się w pliku konfiguracyjnym `.aws/credentials` na prywatnym laptopie pracownika, który został zainfekowany złośliwym oprogramowaniem typu infostealer (RedLine Stealer).
• Powszechne zjawisko Standing Privileges: W organizacji 28 programistów i inżynierów DevOps posiadało stałe, permanentne uprawnienia roota lub administratora do produkcyjnych klastrów EKS i baz RDS.
• Współdzielone klucze SSH: Dostęp do węzłów roboczych Kubernetes odbywał się za pomocą jednego statycznego klucza prywatnego RSA (`prod-eks-key.pem`), którego kopie krążyły na wewnętrznym komunikatorze firmowym oraz w niezabezpieczonych kopiach zapasowych.
• Brak rejestracji sesji powłoki: W środowisku produkcyjnym komendy wpisywane przez inżynierów w powłoce terminalowej (kubectl exec, SSH) nie były nagrywane ani monitorowane w czasie rzeczywistym.
• Konto Root w organizacji AWS nie posiadało wymuszonego sprzętowego tokena MFA i logowano się na nie bezpośrednio z sieci publicznej.

Organizacje płatnicze Visa i Mastercard wszczęły procedurę nałożenia kar finansowych (grożących zawieszeniem licencji procesora płatniczego), a audytor QSA odmówił recertyfikacji PCI DSS v4.0. Zarząd Spółki powołuje zespół audytorów do przeprowadzenia audytu PAM w formule 90 minut, wyliczenia ryzyka 5x5 i przygotowania Planu CAP.

Zadanie laboratoryjne realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (reprezentuje audyt przed Zarządem i QSA, odpowiada za spójność z PCI DSS v4.0/SOC 2/DORA, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje logi CloudTrail, bada konfigurację IAM Identity Center, klastry EKS, projektuje sejf HashiCorp Vault, sesje JIT i integrację FIDO2).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza metryki RTO/RPO dla transakcji kartowych, prowadzi analizę 5 Why dla wycieku kluczy API, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Analiza logów CloudTrail (Event `GetObject`, `DescribeDBInstances`, `AuthorizeSecurityGroupIngress`), weryfikacja wieku kluczy IAM oraz uprawnień kontenerów EKS.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla stałych uprawnień administratorskich, wycieku kluczy API i kradzieży danych kartowych.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why obnażającej kulturę przedkładania szybkości wdrożeń (Speed-to-Market) nad architekturę Zero Trust.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (wyciek bazy kart przez klucz API inżyniera, kompromitacja klastra K8s przez wspólny klucz SSH, przejęcie konta Root w AWS, utrata certyfikacji PCI DSS v4.0).
  • Wyznaczenie wskaźników BCM: RTO = 15 minut dla unieważnienia poświadczeń, RPO = 0 transakcji (zero utraty danych kartowych), MTPD = 1 godzina.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa PAM i Trójfazowy Plan CAP.
  • Opracowanie Standardu Zero Standing Privileges (ZSP) i Sesji Just-In-Time (JIT): całkowita likwidacja stałych kluczy IAM; autoryzacja inżynierów przez AWS IAM Identity Center z wymuszeniem kluczy FIDO2; dynamiczne przyznawanie ról IAM Role z czasem życia tokena maks. 60 minut na wniosek w Slack/Jira.
  • Wdrożenie sejfu HashiCorp Vault z modułem SSH Secrets Engine: generowanie jednorazowych, podpisanych certyfikatów SSH ważnych 15 minut; nagrywanie sesji powłoki przez Teleport / AWS Session Manager.
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - unieważnienie stałych kluczy i zabezpieczenie konta Root kluczem FIDO2 w sejfie pancernym), Faza 2 (30 dni - wdrożenie Vault, sesji JIT i Teleport), Faza 3 (90 dni - pełna automatyzacja ZSP i audyt PCI DSS).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Zarządem.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z kalkulacją strat z kar Visa/Mastercard i zwrotu z inwestycji PAM.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Prezesa Zarządu PayCloud.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza wycieku, ekspozycja na kary Visa/Mastercard, plan wdrożenia ZSP).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności płatniczo-chmurowej (PCI DSS v4.0 Wymogi 7 i 8, SOC 2 Type II, DORA, AWS Well-Architected Security Pillar, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=15m, RPO=0, MTPD=1h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Standard Architektury Zero Standing Privileges (ZSP), Zarządzania Dostępem Uprzywilejowanym (PAM) i Dynamicznych Poświadczeń Just-In-Time w Chmurze PayCloud".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz wpływu na tempo potoków DevSecOps.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Kradzieży Kluczy API i Eksfiltracji Danych Kartowych:

• Condition (Stan faktyczny): Stosowanie stałych uprawnień administracyjnych (Standing Privileges), brak rotacji kluczy API (wiek 480 dni) oraz przechowywanie ich otwartym tekstem na prywatnym laptopie inżyniera doprowadziło do eksfiltracji 320 000 rekordów kart płatniczych z bazy Amazon RDS. Dostęp do Kubernetes odbywał się przez wspólny klucz SSH bez nagrywania sesji powłoki.
• Criteria (Kryterium): PCI DSS v4.0 Wymogi 7.2, 7.3, 8.2, 8.3, 8.6, SOC 2 Trust Services Criteria CC6.1, CC6.2, CC6.3, Rozporządzenie DORA art. 9 i 10, ISO/IEC 27001:2022 Załącznik A.8.2, A.8.5, A.8.15.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego klucz API inżyniera wyciekł do cyberprzestępców? Bo był przechowywany w pliku tekstowym na prywatnym laptopie zainfekowanym infostealerem.

  2. Dlaczego inżynier posiadał stały klucz z uprawnieniami administratora na laptopie? Bo potrzebował bezpośredniego dostępu do produkcyjnej bazy RDS do celów szybkiego debugowania awarii.

  3. Dlaczego nie wdrożono dostępu czasowego przez bezpieczną bramę bastionową PAM? Bo zespół inżynierów sprzeciwił się temu, twierdząc, że bramy PAM spowalniają rozwiązywanie incydentów produkcyjnych.

  4. Dlaczego Dział Bezpieczeństwa ugiął się pod presją programistów? Bo priorytetem spółki było utrzymanie tempa wdrażania nowych integracji e-commerce (Time-to-Market).

  5. Dlaczego cele biznesowe wdrożeń zdominowały architekturę bezpieczeństwa? (PRZYCZYNA ŹRÓDŁOWA): Brak w Spółce sformalizowanego Ładu Bezpieczeństwa Chmurowego (Cloud Governance) oraz komitetu CISO z prawem weta wobec niebezpiecznych praktyk DevOps, co skutkowało tolerowaniem skrajnego długu technologicznego w zarządzaniu tożsamościami uprzywilejowanymi.

• Consequence (Wielowymiarowy skutek): Eksfiltracja 320 000 danych kart płatniczych; kary finansowe od Visa i Mastercard w wysokości do 50 USD za każdą skompromitowaną kartę (łącznie do 16 mln USD); utrata certyfikacji PCI DSS v4.0 i zerwanie umów przez 6 500 sklepów internetowych; koszty śledztwa powłamaniowego PFI (PCI Forensic Investigator) szacowane na 850 000 USD; pozwy zbiorowe poszkodowanych konsumentów.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 6 do Polityki Bezpieczeństwa Informacji: Standard Zarządzania Dostępem Uprzywilejowanym (PAM), Zero Standing Privileges i Dynamicznych Poświadczeń Just-In-Time w Ekosystemie Chmurowym PayCloud Solutions":

• Par. 1: Bezwzględny zakaz generowania stałych kluczy dostępowych API (`AWS_ACCESS_KEY_ID`) dla użytkowników ludzkich. Wszelki dostęp inżynierski odbywa się przez AWS IAM Identity Center z logowaniem federacyjnym i sprzętowym kluczem FIDO2 (YubiKey).
• Par. 2: Architektura Zero Standing Privileges: konta inżynierskie posiadają domyślnie zerowe uprawnienia w środowiskach produkcyjnych. Dostęp administratorski przydzielany jest wyłącznie na wniosek w trybie Just-In-Time (JIT) na czas nieprzekraczający 60 minut, z automatycznym wygaśnięciem roli.
• Par. 3: Rejestracja sesji powłoki: dostęp do kontenerów EKS i maszyn produkcyjnych jest realizowany wyłącznie za pośrednictwem serwera bastionowego Teleport. Każda komenda powłoki (Bash/kubectl) jest rejestrowana w postaci nienaruszalnego strumienia logów oraz nagrania wideo przesyłanego do SIEM.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Krytyczna (25/25) - wyciek 320 000 kart płatniczych i wstrzymanie certyfikacji PCI DSS v4.0.
• Zagrożenia regulacyjne: Kary finansowe Visa/Mastercard (do 16 mln USD), utrata klientów i ryzyko upadłości FinTechu.
• Wnioskowany budżet CAP: 620 000 PLN (licencje HashiCorp Vault Enterprise, Teleport, klucze YubiKey dla wszystkich inżynierów, audyt QSA).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Unieważnienie kluczy statycznych, fizyczne zabezpieczenie konta Root, wdrożenie Identity Center (koszt: 15 000 PLN).
  • Projekty Strategiczne (30-90 dni): Wdrożenie pełnego ekosystemu Vault + Teleport, audyt certyfikacyjny PCI DSS (koszt: 605 000 PLN, TCO 3-letnie: 890 000 PLN).

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

• Zalety: Całkowite uodpornienie infrastruktury na kradzież statycznych poświadczeń; odzyskanie zgodności z PCI DSS v4.0 i SOC 2; pełna audytowalność każdej czynności administratorskiej; zachowanie pozycji rynkowej w sektorze płatniczym.
• Wady i trudności: Konieczność zmiany kultury pracy programistów i odejścia od bezpośredniego dostępu SSH; konieczność wnioskowania o uprawnienia JIT w trakcie awarii produkcyjnych; koszty utrzymania klastra sejfu sekretów w trybie Multi-AZ.

• Payment Card Industry Data Security Standard (PCI DSS) v4.0 - Requirements 7 and 8.
• American Institute of CPAs (AICPA): SOC 2 - Trust Services Criteria for Security and Confidentiality.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) - art. 9 i 10.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.8.2, A.8.5, A.8.15, A.8.24.
• NIST Special Publication 800-207: Zero Trust Architecture, 2020.
• Center for Internet Security (CIS): CIS Amazon Web Services Foundations Benchmark v2.0.0.
• HashiCorp: "Zero Standing Privileges: Architecture and Implementation Guide", 2023.

• U1 Student projektuje architekturę Zero Standing Privileges, sesje Just-In-Time oraz sejf dynamicznych sekretów dla chmury AWS i Kubernetes.
• U2 Student dokumentuje naruszenia bezpieczeństwa w modelu 4C i prowadzi wieloetapowe dochodzenie przyczyn źródłowych 5 Why.
• U3 Student wykonuje analizę ryzyka kompromitacji tożsamości uprzywilejowanych w matrycy 5x5 i wyznacza metryki BCM (RTO/RPO/MTPD).
• U4 Student opracowuje trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna regulacje PCI DSS v4.0, SOC 2, DORA, ISO 27001 oraz paradygmaty Zero Trust i DevSecOps.
• K1K2K3 Student wykazuje najwyższą kulturę inżynierską, bezkompromisowość wobec skrótów administratorskich i zdolność merytorycznej obrony decyzji przed Zarządem.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu strategicznego architektury tożsamości i kontroli dostępu w instytucji szkolnictwa wyższego i ośrodku obliczeń wielkiej skali (Regionalne Centrum Superkomputerowo-Sieciowe), prowadzącej strategiczne projekty badawczo-rozwojowe (R&D) objęte unijnym i krajowym reżimem kontroli obrotu towarami i technologiami o znaczeniu strategicznym (produkty podwójnego zastosowania - Dual-Use). Jednostka podlega pod wymogi Dyrektywy NIS2 w sektorze badań naukowych i edukacji wyższej oraz Krajowe Ramy Interoperacyjności. Zadanie stawia studentów w roli audytorów badających krytyczny incydent szpiegostwa naukowo-technicznego i sabotażu klastra obliczeniowego (HPC o mocy 6 PFLOPS), wywołany brakiem separacji ról wielokrotnych (doktorant-student-badacz), powszechnym stosowaniem statycznych kluczy SSH bez MFA, niekontrolowanym dostępem z akademickiej sieci bezprzewodowej Eduroam oraz brakiem izolacji zadań w zarządcy kolejkowym Slurm. Zadanie wymaga zastosowania metodyki Triady Audytorskiej, modelu 4C, matrycy ryzyka 5x5 skorelowanej ze wskaźnikami BCM, procedury 5 Why, trójfazowego Planu CAP oraz opracowania Executive Summary dla Kolegium Rektorskiego Politechniki.

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

• W1 Ekspercka znajomość przepisów o ochronie własności intelektualnej, tajemnicy badań naukowych, technologiach podwójnego zastosowania (Rozporządzenie UE 2021/821 - Dual-Use) oraz RODO.
• W2W3 Wyczerpująca znajomość Dyrektywy NIS2 dla sektora badań, Prawa o szkolnictwie wyższym i nauce, par. 20 KRI, normy PN-EN ISO/IEC 27001:2022 (A.5.15, A.5.17, A.8.5, A.8.20) oraz standardów bezpieczeństwa sieci naukowych GÉANT/Eduroam.
• U1 Opracowanie zintegrowanego Modelu Tożsamości Wielokontekstowej dla środowiska akademickiego, rozdzielającego tożsamość studencką od pracowniczej i badawczej, wraz z architekturą bezpiecznego dostępu MFA/FIDO2 do klastrów HPC.
• U2 Identyfikacja i dokumentowanie uchybień w kanonicznym modelu 4C z wieloetapową analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka kradzieży strategicznego know-how państwa i sabotażu obliczeń w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formule Pitch to Board.
• K1K2K3 Zdolność do wyważenia tradycyjnej kultury otwartości akademickiej z rygorami bezpieczeństwa państwa, wysoka etyka naukowa i odwaga w prezentowaniu ustaleń przed władzami uczelni.
• Powiązanie z wykładem: Wyk1 (Audyt w sektorze akademicko-badawczym), Wyk3 (Kontrole A.5.15 i A.8.5 ISO 27001), Wyk4 (NIS2 w badaniach naukowych i KRI), Wyk5 (Risk-based audit i matryca 5x5), Wyk6 (Analiza logów FreeRADIUS, OpenLDAP i menedżera zadań Slurm), Wyk7 (Model 4C, 5 Why i raportowanie rektorskie).

Politechnika kształci 16 000 studentów i zatrudnia 2 400 pracowników naukowych i dydaktycznych. Przy uczelni funkcjonuje Regionalne Centrum Superkomputerowo-Sieciowe dysponujące klastrem HPC o mocy 6 PFLOPS (800 węzłów z akceleratorami GPU Nvidia H100), połączonym z siecią PIONIER. W klastrze przetwarzane są symulacje aerodynamiki hipersonicznej dla przemysłu lotniczego, algorytmy kryptografii postkwantowej oraz zaawansowane syntezy polimerów zbrojeniowych (technologie Dual-Use objęte ścisłym nadzorem ABW i Ministerstwa Rozwoju).

Przebieg incydentu i krytyczne ustalenia audytu:

• Próba transferu technologii strategicznych: Służba Kontrwywiadu Wojskowego (SKW) przekazała Rektorowi notę informacyjną o wykryciu nieautoryzowanego transferu 4 TB danych zawierających kody źródłowe modeli aerodynamiki rakietowej na serwer zlokalizowany w państwie spoza UE i NATO.
• Dochodzenie wykazało, że eksfiltracji dokonano za pomocą konta doktoranta z zagranicy, który brał udział w zajęciach dydaktycznych z programowania równoległego, a jednocześnie został dopisany do projektu badawczego Dual-Use przez promotora bez wymaganej weryfikacji bezpieczeństwa.
• W uczelnianym systemie katalogowym OpenLDAP każdy użytkownik posiada tylko jedno konto UID oparte na numerze PESEL/paszportu. W rezultacie doktoranci posiadają te same poświadczenia do systemu USOSweb (jako studenci), do poczty służbowej (jako dydaktycy oceniający innych) oraz do węzłów klastra HPC. W trakcie audytu wykryto, że 18 doktorantów miało techniczny wgląd do protokołów egzaminacyjnych z przedmiotów, których sami byli słuchaczami.
• Dostęp do klastra HPC odbywa się przez protokół SSH za pomocą haseł lub nieszyfrowanych kluczy prywatnych RSA bez wymuszenia uwierzytelniania wieloskładnikowego (MFA). W menedżerze kolejkowym Slurm nie wdrożono strefowania zasobów: zadania dydaktyczne studentów uruchamiane były na tych samych węzłach fizycznych co symulacje Dual-Use, dzieląc wspólną pamięć RAM i magistralę InfiniBand (podatność na ataki typu Side-Channel i Rowhammer).
• W akademickiej sieci bezprzewodowej Eduroam (protokół 802.1X) brak jest dynamicznej segmentacji VLAN: każdy zalogowany student posiada bezpośrednią widoczność sieciową do interfejsów zarządzających BMC/IPMI węzłów superkomputera oraz stacji dziekanatów.
• Audyt wykrył 420 aktywnych kont byłych pracowników i doktorantów, z których 14 regularnie wykorzystywało moce obliczeniowe klastra do wydobywania kryptowaluty Monero (cryptojacking).

Kolegium Rektorskie, w obliczu kontroli ABW i ryzyka utraty grantów strategicznych, nakazuje pilny audyt tożsamości i kontroli dostępu w formule 90 minut, wyliczenie ryzyka 5x5 i sporządzenie Planu CAP.

Zadanie realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (odpowiada za relacje z Rektorem, ABW/SKW, zgodność z NIS2/Dual-Use/KRI, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje strukturę OpenLDAP, konfigurację Slurm, logi FreeRADIUS, bada brak segmentacji VLAN i projektuje bramę Bastion SSH z FIDO2).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza wskaźniki RTO/RPO dla klastra badawczego, prowadzi analizę 5 Why dla wycieku technologii, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Analiza logów kolejkowania Slurm, konfiguracji kont OpenLDAP z rolami wielokrotnymi oraz logów logowań SSH z obcych adresów IP.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla wycieku danych Dual-Use i braku separacji tożsamości wielorolowych.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why obnażającej zaniechania architektoniczne i brak nadzoru nad tożsamościami badawczymi.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (szpiegostwo naukowe Dual-Use, manipulacja ocenami w USOS, atak na węzły HPC z sieci Eduroam, nielegalny cryptojacking na klastrze).
  • Wyznaczenie parametrów BCM: RTO = 30 minut dla odcięcia skompromitowanego węzła, RPO = 1 godzina dla checkpointów obliczeń naukowych, MTPD = 24 godziny.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa IAM i Trójfazowy Plan CAP.
  • Opracowanie Standardu Tożsamości Wielokontekstowej: bezwzględne rozdzielenie konta studenta (`s12345@student.politechnika.pl`) od konta badacza/dydaktyka (`j.kowalski@politechnika.pl`) z odrębnymi poświadczeniami i profilami uprawnień.
  • Architektura Bezpiecznego Klastra HPC: brama Bastion SSH z wymuszeniem uwierzytelniania sprzętowego FIDO2 (YubiKey); izolacja zadań Dual-Use w dedykowanej partycji Slurm z szyfrowaniem pamięci RAM (AMD SEV / Intel SGX); dynamiczny VLAN w Eduroam odcinający ruch studencki od strefy zarządzania.
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - odcięcie 420 martwych kont, blokada dostępu do HPC bez MFA), Faza 2 (30 dni - rozdzielenie kont w LDAP/USOS i segmentacja Eduroam), Faza 3 (90 dni - pełne wdrożenie IGA i atestacja ABW).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Kolegium Rektorskim.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z kalkulacją strat z utraty grantów strategicznych i matrycą priorytetów.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Rektora Politechniki.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza szpiegostwa naukowego, ryzyka sankcji Dual-Use, plan naprawczy).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności naukowo-badawczej (Dyrektywa NIS2 dla badań, Rozporządzenie UE 2021/821 Dual-Use, Prawo o szkolnictwie wyższym, par. 20 KRI, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=30m, RPO=1h, MTPD=24h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Polityka Bezpieczeństwa Tożsamości Wielorolowych, Dostępów do Klastra Obliczeniowego HPC oraz Ochrony Badań Strategicznych i Technologii Podwójnego Zastosowania".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz bilansu otwartości badawczej i cyberodporności.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Kradzieży Danych Badań Dual-Use z Klastra HPC:

• Condition (Stan faktyczny): Pojedyncze konto w OpenLDAP łączące uprawnienia studenta i badacza, brak uwierzytelniania wieloskładnikowego (MFA) do klastra superkomputerowego oraz brak izolacji zadań w zarządcy Slurm umożliwiły doktorantowi nieautoryzowany transfer 4 TB kodów źródłowych symulacji rakietowych Dual-Use na serwer zagraniczny.
• Criteria (Kryterium): Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2021/821 (kontrola obrotu produktami podwójnego zastosowania - Dual-Use), Dyrektywa NIS2 dla sektora badań naukowych, ISO/IEC 27001:2022 Załącznik A.5.15, A.5.17, A.8.5, A.8.20, par. 20 KRI.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego doktorant mógł pobrać dane strategicznego projektu rakietowego? Bo posiadał uprawnienia do wspólnego katalogu projektu w klastrze HPC.

  2. Dlaczego przyznano mu uprawnienia bez weryfikacji kontrwywiadowczej? Bo promotor dopisał go do projektu w portalu uczelnianym jednym kliknięciem bez konsultacji z Pełnomocnikiem ds. Ochrony Informacji Niejawnych.

  3. Dlaczego w systemie brakowało blokad uniemożliwiających dostęp do projektów strategicznych? Bo uczelniany system IAM nie rozróżniał projektów ogólnych od badań objętych reżimem technologii podwójnego zastosowania.

  4. Dlaczego infrastruktura HPC nie posiadała dedykowanej strefy bezpiecznej z wymuszonym MFA? Bo społeczność akademicka sprzeciwiała się jakimkolwiek barierom dostępowym, argumentując to "tradycyjną wolnością badań naukowych".

  5. Dlaczego wolność akademicka przeważyła nad rygorami ochrony bezpieczeństwa państwa? (PRZYCZYNA ŹRÓDŁOWA): Brak na uczelni sformalizowanego ładu zarządzania bezpieczeństwem informacji (ISMS Governance) oraz brak świadomości władz rektorskich co do odpowiedzialności karnej i sankcji międzynarodowych za niekontrolowany transfer technologii Dual-Use.

• Consequence (Wielowymiarowy skutek): Utrata strategicznego know-how militarnego państwa na rzecz obcego wywiadu; cofnięcie przez Narodowe Centrum Badań i Rozwoju (NCBR) dotacji o wartości 45 mln PLN; sankcje międzynarodowe i embargo technologiczne na zakup nowoczesnych procesorów GPU dla uczelni; odpowiedzialność karna kierowników projektu z art. 33 Ustawy o obrocie z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 8 do Polityki Bezpieczeństwa Informacji: Standard Zarządzania Tożsamościami Wielorolowymi, Bezpieczeństwa Obliczeń HPC i Kontroli Badań Dual-Use":

• Par. 1: Zasada separacji kontekstów tożsamości: każda osoba łącząca status studenta i pracownika dydaktycznego/badawczego otrzymuje dwa niezależne konta cyfrowe o różnych identyfikatorach UID i hasłach. Zabrania się agregowania uprawnień studenckich i pracowniczych w jednym rekordzie katalogowym.
• Par. 2: Dostęp do klastra superkomputerowego HPC: logowanie inżynierskie i badawcze realizowane jest wyłącznie przez serwer bastionowy z wymuszeniem uwierzytelniania sprzętowego FIDO2.
• Par. 3: Reżim ochrony badań strategicznych i Dual-Use: projekty objęte Rozporządzeniem 2021/821 są uruchamiane w wyizolowanej strefie klastra z szyfrowaniem pamięci RAM, bez dostępu do Internetu i z zakazem dołączania badaczy bez pisemnej autoryzacji Pełnomocnika ds. Bezpieczeństwa Uczelni.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Ekstremalna (25/25) - wyciek tajemnic technologii rakietowych Dual-Use do obcego państwa i ryzyko sankcji międzynarodowych.
• Zagrożenia regulacyjne: Embargo technologiczne, utrata dotacji NCBR (45 mln PLN), odpowiedzialność karna z ustawy o obrocie strategicznym.
• Wnioskowany budżet CAP: 480 000 PLN (serwer bastionowy PAM, moduły szyfrowania AMD SEV dla węzłów, klucze YubiKey dla badaczy, platforma IGA).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Zablokowanie 420 martwych kont, wyłączenie bezpośredniego SSH, wymuszenie MFA (koszt: 10 000 PLN).
  • Projekty Strategiczne (30-90 dni): Rozdzielenie kont w USOS/LDAP, partycjonowanie klastra Slurm, certyfikacja ISO 27001 (koszt: 470 000 PLN, TCO 3-letnie: 690 000 PLN).

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

• Zalety: Całkowite zabezpieczenie strategicznego know-how militarnego RP; wyeliminowanie ryzyka manipulacji ocenami w USOS; likwidacja zjawiska cryptojackingu i odzyskanie 15% mocy obliczeniowej klastra; zgodność z NIS2 i reżimem Dual-Use.
• Wady i trudności: Konieczność posługiwania się przez doktorantów dwoma zestawami poświadczeń; opór części profesorów przed sformalizowanym zatwierdzaniem członków zespołów badawczych; nakłady na licencje i sprzęt PAM/FIDO2.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2021/821 z dnia 20 maja 2021 r. ustanawiające unijny system kontroli wywozu, transferu, pośrednictwa i pomocy technicznej w odniesieniu do produktów podwójnego zastosowania (Dual-Use).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) - sektor badań naukowych.
• Ustawa z dnia 29 listopada 2000 r. o obrocie z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym dla bezpieczeństwa państwa (Dz.U. z 2023 r. poz. 1582).
• Ustawa z dnia 20 lipca 2018 r. - Prawo o szkolnictwie wyższym i nauce (Dz.U. z 2023 r. poz. 742 z późn. zm.).
• Rozporządzenie Rady Ministrów w sprawie Krajowych Ram Interoperacyjności (KRI) - par. 20.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15, A.5.17, A.8.5, A.8.20.
• SchedMD: "Slurm Workload Manager - Security Guide and Resource Isolation", 2023.

• U1 Student projektuje zaawansowany model tożsamości wielokontekstowej oraz bezpieczny dostęp FIDO2 do klastrów superkomputerowych HPC.
• U2 Student dokumentuje uchybienia w kanonicznym modelu 4C i prowadzi wieloetapowe dochodzenie 5 Why.
• U3 Student wykonuje analizę ryzyka transferu technologii Dual-Use w matrycy 5x5 i wyznacza wskaźniki BCM (RTO/RPO/MTPD).
• U4 Student sporządza trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna regulacje Dual-Use, Dyrektywę NIS2 dla badań, Prawo o szkolnictwie wyższym i standardy ISO 27001.
• K1K2K3 Student łączy poszanowanie otwartości naukowej z bezkompromisowością w ochronie bezpieczeństwa państwa i etyką badawczą.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu cyberodporności oraz zarządzania tożsamością i dostępem (IAM) w wielkim przedsiębiorstwie logistycznym o statusie Podmiotu Kluczowego w rozumieniu Dyrektywy NIS2 (sektor usług pocztowych i łańcucha dostaw) oraz operatora infrastruktury krytycznej. Studenci wcielają się w rolę audytorów śledczych badających zorganizowany proceder kradzieży przesyłek o wysokiej wartości (elektronika, farmaceutyki) oraz masowego wycieku danych osobowych odbiorców paczek z centralnego systemu zarządzania magazynem (WMS). Zadanie stawia w centrum uwagi problematykę masowej rotacji pracowników agencyjnych (pracownicy tymczasowi z 4 agencji pracy), powszechność stosowania anonimowych kont generycznych na terminalach skanujących (Android Enterprise), brak geofencingu sieci bezprzewodowej oraz naruszenie zasady Privacy by Design (art. 25 RODO). Zadanie rozwija umiejętności realizacji audytu w formule Triady Audytorskiej, sformułowania ustaleń w kanonicznym modelu 4C, kwantyfikacji ryzyka w matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=30m, RPO=0), opracowania trójfazowego Planu CAP wprowadzającego automatyczny provisioning tożsamości przez API, logowanie dynamicznym kodem QR/PIN i maskowanie danych adresowych, oraz sporządzenia Executive Summary dla Zarządu LogiXpress S.A.

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

• W1 Ekspercka znajomość tajemnicy pocztowej (Prawo pocztowe art. 41), ochrony danych osobowych i adresowych (RODO art. 5 ust. 2, art. 25, art. 32) oraz odpowiedzialności odszkodowawczej za kradzieże ładunków.
• W2W3 Rygorystyczna znajomość Dyrektywy NIS2 dla sektora logistycznego, normy PN-EN ISO/IEC 27001:2022 (A.5.15, A.5.16, A.7.4, A.8.5), ISO 27701 (zarządzanie prywatnością) oraz standardów bezpieczeństwa Android Enterprise.
• U1 Opracowanie zintegrowanego Standardu Architektury Bezpiecznej Identyfikacji Pracowników Tymczasowych, provisioningu API z agencjami pracy, geofencingu Wi-Fi oraz maskowania danych w WMS.
• U2 Identyfikacja i dokumentowanie uchybień w kanonicznym modelu 4C z analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka kradzieży ładunków i wycieku danych w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formacie Pitch to Board.
• K1K2K3 Zdolność do demaskowania zaniechań bezpieczeństwa maskowanych presją operacyjną wydajności magazynu, etyka zawodowa i skuteczność w dialogu z Zarządem.
• Powiązanie z wykładem: Wyk1 (Audyt w logistyce i łańcuchu dostaw), Wyk3 (Kontrole dostępowe i ochrona fizyczna ISO 27001), Wyk4 (NIS2 i RODO w operacjach masowych), Wyk5 (Risk-based audit i matryca 5x5), Wyk6 (Analiza logów skanowania terminali WMS i transmisji radiowej AP), Wyk7 (Model 4C, 5 Why i raportowanie zarządcze).

LogiXpress S.A. zarządza siecią 18 000 automatycznych maszyn paczkowych oraz 14 wielkimi centrami dystrybucyjnymi, przetwarzając w szczycie przedświątecznym ponad 1,8 miliona przesyłek na dobę. W głównym hubie logistycznym pod Łodzią o powierzchni 85 000 m2 pracuje na 3 zmianach 1 400 pracowników magazynowych, z czego 75% stanowią obcokrajowcy zatrudniani przez 4 agencje pracy tymczasowej o miesięcznej rotacji kadr rzędu 45%.

Przebieg incydentu i krytyczne ustalenia audytu śledczego:

• Zorganizowana kradzież ładunków i wyciek danych: Wydział do Walki z Cyberprzestępczością KWP zatrzymał członków zorganizowanej grupy przestępczej, którzy dysponowali precyzyjną listą przesyłek zawierających drogi sprzęt komputerowy i smartfony o wartości 3,8 mln PLN. Złodzieje znali numery paczek, zawartość, dokładne nazwiska odbiorców oraz godziny, w których przesyłki trafiały na konkretne linie sortownicze w hubie pod Łodzią.
• Dochodzenie audytorskie ujawniło, że na terminalach mobilnych Zebra z systemem Android Enterprise wszyscy pracownicy agencyjni logują się za pomocą jednego, wspólnego konta domenowego "wms_sort_ogolny".
• W aplikacji WMS uwierzytelnianie odbywa się za pomocą kart zbliżeniowych przypisanych do numeru skanera (np. karta "Skaner_67"), które leżą w otwartych skrzynkach przy szatni. Z jednego skanera w ciągu 12-godzinnej zmiany korzystało od 4 do 8 różnych pracowników tymczasowych.
• Na ekranach skanerów WMS wyświetlane są w sposób całkowicie jawny pełne dane osobowe odbiorcy (imię, nazwisko, ulica, numer domu, telefon komórkowy oraz zadeklarowana wartość ubezpieczenia paczki), co pozwalało podstawionym pracownikom agencyjnym na fotografowanie ekranów i typowanie przesyłek do zaboru.
• Brak geofencingu i wycieki sieciowe Wi-Fi: Anteny punktów dostępowych Wi-Fi Cisco na ścianach hali emitują silny sygnał sieci magazynowej na odległość 120 metrów poza ogrodzenie centrum dystrybucyjnego. Poświadczenia sieci WPA2-Enterprise były współdzielone i powszechnie znane, co umożliwiło przestępcom podgląd ruchu WMS z zaparkowanego busa przed bramą wjazdową.

Urząd Ochrony Danych Osobowych (UODO) wszczął postępowanie w sprawie naruszenia zasady rozliczalności i poufności (art. 5 ust. 1 lit. f RODO), a ubezpieczyciel odmówił wypłaty odszkodowania z polisy cargo. Zarząd LogiXpress S.A. powołuje zespół audytorów do przeprowadzenia natychmiastowego audytu IAM w formule 90 minut, wyliczenia ryzyka 5x5 i sporządzenia Planu CAP.

Zadanie realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (odpowiada za relacje z Zarządem, UODO, ubezpieczycielem, zgodność z NIS2/Prawem pocztowym, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje konfigurację MDM terminali Zebra, logi systemu WMS, kontrolery Wi-Fi, projektuje logowanie kodem QR/PIN, geofencing i maskowanie danych).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza metryki RTO/RPO dla sortowni, prowadzi analizę 5 Why dla kradzieży towarów, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Badanie logów skanowania paczek w WMS, zestawienie godzin pracy agencji z czasem rejestracji statusów oraz analiza zasięgu radiowego Wi-Fi.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla anonimowości pracy magazynierów, braku rozliczalności i wycieku danych odbiorców.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why obnażającej przedkładanie wskaźnika wydajności paczek na godzinę nad bezpieczeństwo i prawo.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (masowa kradzież przesyłek luksusowych, wyciek danych osobowych klientów, podsłuch sieci Wi-Fi poza terenem hubu, kary Prezesa UODO).
  • Wyznaczenie parametrów BCM: RTO = 30 minut dla odcięcia skompromitowanego terminala, RPO = 0 transakcji (brak utraty zdarzeń skanowania), MTPD = 2 godziny.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa IAM i Trójfazowy Plan CAP.
  • Opracowanie Standardu Szybkiej Identyfikacji Personelu Agencyjnego: provisioning tożsamości przez API REST z 4 agencjami pracy; imienny kod QR na identyfikatorze drukowany przy wejściu + 4-cyfrowy PIN ustalany przez pracownika; czas logowania < 2 sekundy.
  • Modyfikacja interfejsu WMS w duchu Privacy by Design: maskowanie danych osobowych (widoczne tylko miasto doręczenia i kod sortowniczy, dane adresowe odblokowywane dopiero w punkcie pakowania).
  • Optymalizacja sieci Wi-Fi: redukcja mocy nadajników AP przy ścianach hali, wdrożenie certyfikatów maszynowych 802.1X (brak statycznych haseł WPA2) oraz blokada logowań spoza geofence.
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - zmiana haseł Wi-Fi, maskowanie danych w UI WMS), Faza 2 (30 dni - bramka API z agencjami i logowanie QR/PIN), Faza 3 (90 dni - integracja MDM i pełna certyfikacja NIS2).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Zarządem.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z bilansem strat z kradzieży (3,8 mln PLN) i zwrotem z inwestycji IAM.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Prezesa Zarządu LogiXpress S.A.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza procederu kradzieży, ekspozycja na kary UODO, plan likwidacji anonimowości).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności logistycznej (Dyrektywa NIS2 dla usług pocztowych, RODO art. 5, 25 i 32, Prawo pocztowe art. 41, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=30m, RPO=0, MTPD=2h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Standard Identyfikacji Personelu Tymczasowego, Ergonomii Uwierzytelniania w Systemie WMS oraz Maskowania Danych w Magazynach LogiXpress S.A.".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz bilansu wydajności operacyjnej i bezpieczeństwa danych.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Kradzieży Towarów i Wycieku Danych z Systemu WMS:

• Condition (Stan faktyczny): Stosowanie wspólnego konta domenowego i anonimowych kart przypisanych do skanerów uniemożliwiło identyfikację sprawców kradzieży przesyłek o wartości 3,8 mln PLN. Wyświetlanie pełnych danych adresowych i wartości ubezpieczenia na terminalach WMS doprowadziło do typowania paczek przez grupę przestępczą. Sygnał Wi-Fi z hasłem statycznym wykraczał 120 m poza ogrodzenie.
• Criteria (Kryterium): ISO/IEC 27001:2022 Załącznik A.5.15, A.5.16, A.7.4, A.8.5, art. 5 ust. 1 lit. c i f, art. 5 ust. 2, art. 25, art. 32 RODO, Dyrektywa NIS2 dla sektora pocztowego, Ustawa - Prawo pocztowe art. 41.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego pracownicy magazynu używali anonimowych kart skanerów? Bo agencje pracy przysyłały listy pracowników rano w dniu zmiany i IT nie miało czasu na manualne zakładanie kont.

  2. Dlaczego nie wdrożono zautomatyzowanego provisioningu tożsamości przez API? Bo uznano, że koszt integracji z 4 agencjami jest zbyt wysoki przy 45% rotacji kadr.

  3. Dlaczego na ekranach skanerów wyświetlano pełne dane odbiorców z wartością przesyłki? Bo domyślny szablon aplikacji WMS nie został dostosowany do zasady minimalizacji danych.

  4. Dlaczego Dział Bezpieczeństwa nie zweryfikował aplikacji przed wdrożeniem? Bo kierownictwo operacyjne magazynu wymusiło natychmiastowe uruchomienie systemu przed szczytem paczkowym bez audytu Security by Design.

  5. Dlaczego dopuszczono do pierwszeństwa celów logistycznych nad bezpieczeństwem? (PRZYCZYNA ŹRÓDŁOWA): Brak w Spółce dojrzałego ładu cyberbezpieczeństwa (Security Governance) uzależniającego uruchomienie procesów masowych od spełnienia wymagań rozliczalności i normy ISO 27001.

• Consequence (Wielowymiarowy skutek): Bezpośrednie straty z tytułu skradzionych przesyłek w wysokości 3,8 mln PLN; odmowa wypłaty odszkodowania przez ubezpieczyciela z winy rażącego niedbalstwa; postępowanie prokuratorskie wobec członków grupy przestępczej i personelu; ryzyko kary Prezesa UODO (do 20 mln EUR lub 4% obrotu); utrata reputacji wiodącego operatora paczkowego w Europie.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 9 do Regulaminu Bezpieczeństwa Informacji: Standard Identyfikacji Personelu Tymczasowego, Bezpieczeństwa Terminali Mobilnych i Prywatności w Systemie WMS w Hubach LogiXpress S.A.":

• Par. 1: Zasada imiennej rozliczalności: Zabrania się dopuszczenia pracownika agencyjnego do obsługi terminala skanującego bez zarejestrowanej tożsamości cyfrowej w centralnym rejestrze IAM. Logowanie odbywa się poprzez zeskanowanie kodu QR z identyfikatora pracowniczego i wprowadzenie 4-cyfrowego kodu PIN.
• Par. 2: Maskowanie danych osobowych w systemie WMS: Interfejs aplikacji mobilnej wyświetla wyłącznie numer zlecenia, miasto doręczenia i kod kreskowy skrytki. Pełne dane adresowe podlegają automatycznemu zamaskowaniu (np. Jan K[XXX], ul. M[XXX] 12/4) i mogą być odsłonięte wyłącznie przez brygadzistę w przypadku uszkodzenia etykiety adresowej.
• Par. 3: Bezpieczeństwo radiowe i geofencing: Sieć Wi-Fi WMS działa wyłącznie w standardzie 802.1X z uwierzytelnianiem certyfikatami urządzenia. Każda próba logowania z terminala znajdującego się poza strefą operacyjną hali powoduje natychmiastowe zablokowanie urządzenia i alert w SOC.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Ekstremalna (25/25) - kradzieże na 3,8 mln PLN, wyciek danych milionów klientów i odmowa wypłaty odszkodowania przez ubezpieczyciela.
• Zagrożenia regulacyjne: Kary Prezesa UODO (do 4% globalnego obrotu), sankcje z Dyrektywy NIS2, utrata zaufania kluczowych platform e-commerce (Amazon, Allegro).
• Wnioskowany budżet CAP: 490 000 PLN (integracja API z agencjami, licencje MDM, modyfikacja UI WMS, rekonfiguracja Wi-Fi).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Maskowanie danych w WMS, strojenie anten Wi-Fi, audyt fizyczny szatni (koszt: 12 000 PLN).
  • Projekty Strategiczne (30-90 dni): Bramka API z agencjami pracy, logowanie QR/PIN, geofencing MDM (koszt: 478 000 PLN, TCO 3-letnie: 690 000 PLN).

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

• Zalety: Całkowita likwidacja anonimowości kradzieży towarów na sortowni; redukcja strat cargo o ponad 95%; odzyskanie ochrony ubezpieczeniowej; zgodność z RODO i NIS2; ochrona danych osobowych obywateli.
• Wady i trudności: Nakłady na integrację API z wieloma agencjami; konieczność drukowania identyfikatorów z kodami QR przy każdej zmianie; narzut czasowy przy szkoleniu rotujących pracowników w obsłudze PIN-u.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15, A.5.16, A.7.4, A.8.5.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) - sektor usług pocztowych i kurierskich.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 1 lit. c, art. 5 ust. 2, art. 25, art. 32.
• Ustawa z dnia 23 listopada 2012 r. - Prawo pocztowe (Dz.U. z 2023 r. poz. 1640 z późn. zm.) - art. 41 (tajemnica pocztowa).
• Ustawa z dnia 9 lipca 2003 r. o zatrudnianiu pracowników tymczasowych (Dz.U. z 2023 r. poz. 1110 z późn. zm.).
• Zebra Technologies: "Securing Android Enterprise Mobile Devices in Logistics and Warehouse Operations", 2023.

• U1 Student projektuje nowoczesną architekturę IAM dla personelu agencyjnego, łączącą provisioning API, logowanie QR/PIN, geofencing i maskowanie danych.
• U2 Student dokumentuje naruszenia w modelu 4C i prowadzi wieloetapowe dochodzenie przyczyn źródłowych 5 Why.
• U3 Student wykonuje analizę ryzyka kradzieży towarów i wycieku danych w matrycy 5x5 i wyznacza metryki BCM (RTO/RPO/MTPD).
• U4 Student sporządza trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna regulacje NIS2, RODO, Prawa pocztowego oraz standardy bezpieczeństwa mobilnego Android Enterprise.
• K1K2K3 Student cechuje się obiektywizmem, asertywnością wobec presji wydajnościowej magazynu i etyką w ochronie prywatności.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu strategicznego architektury kontroli dostępu, ochrony informacji niejawnych oraz tajemnic procesowych w jednostce wymiaru sprawiedliwości szczebla apelacyjnego (Sąd Apelacyjny wraz z podległymi 4 Sądami Okręgowymi i 24 Sądami Rejonowymi). Placówka przetwarza akta spraw o najwyższym ciężarze gatunkowym (sprawy o przestępczość zorganizowaną, świadkowie koronni, terroryzm, tajemnice przedsiębiorstw w sporach gospodarczych, rozwody z wyłączeniem jawności). Zadanie stawia studentów w roli audytorów śledczych badających krytyczny incydent korupcyjnego wycieku projektu orzeczenia w sporze gospodarczym o wartości 850 mln PLN na kilka dni przed jego publikacją oraz masowego nocnego pobierania akt spraw karnych przez pracowników sekretariatów za pośrednictwem serwera dostępu zdalnego. Zadanie wymaga dekompozycji płaskiego modelu RBAC, zaprojektowania hybrydowej architektury kontroli opartej na atrybutach (Attribute-Based Access Control - ABAC), wdrożenia kryptograficznego "Skarbca Orzeczeń" chroniącego tajemnicę narady sędziowskiej (art. 108 KPK), kwantyfikacji ryzyka w matrycy 5x5 skorelowanej ze wskaźnikami BCM, procedury 5 Why, trójfazowego Planu CAP oraz opracowania Executive Summary dla Kolegium Sądu Apelacyjnego.

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

• W1 Ekspercka znajomość przepisów ustroju sądów powszechnych, procedur cywilnych i karnych (tajemnica narady sędziowskiej KPK art. 108, KPC art. 325), ochrony informacji niejawnych i tajemnic zawodowych.
• W2W3 Biegła znajomość Rozporządzenia w sprawie Krajowych Ram Interoperacyjności (par. 20 KRI), RODO (art. 32), Ustawy o ochronie informacji niejawnych, normy ISO/IEC 27001:2022 (A.5.15, A.5.18, A.8.2, A.8.16) oraz standardów NIST SP 800-162 (ABAC).
• U1 Opracowanie zintegrowanego Standardu Architektury ABAC dla wymiaru sprawiedliwości, Skarbca Orzeczeń z szyfrowaniem asymetrycznym oraz modułu detekcji anomalii UEBA.
• U2 Identyfikacja i dokumentowanie uchybień w kanonicznym modelu 4C z wieloetapową analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka wycieku tajemnic orzeczniczych i dekonspiracji świadków koronnych w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formacie Pitch to Board.
• K1K2K3 Bezwzględna dbałość o niezawisłość sędziowską, praworządność, dyskrecję procesową i najwyższą etykę prawniczą.
• Powiązanie z wykładem: Wyk1 (Audyt w wymiarze sprawiedliwości), Wyk3 (Kontrole A.5.18 i A.8.2 ISO 27001), Wyk4 (KRI i ochrona informacji niejawnych), Wyk5 (Risk-based audit w sądownictwie i matryca 5x5), Wyk6 (Analiza logów dostępu do repertoriów sądowych Currenda/Sędzia2), Wyk7 (Model 4C, 5 Why i raportowanie do Prezesa Sądu).

Sąd Apelacyjny wraz z podległym okręgiem sądowniczym zatrudnia 520 sędziów i asesorów, 410 asystentów sędziów oraz 1 250 urzędników sądowych i protokolantów. W systemie teleinformatycznym biurowości sądowej (Currenda / Sędzia2) zarejestrowanych jest rocznie ponad 380 000 spraw.

Przebieg incydentu i krytyczne ustalenia audytu:

• Korupcyjny wyciek orzeczenia gospodarczego: Centralne Biuro Antykorupcyjne (CBA) zatrzymało asystenta sędziego z Wydziału Gospodarczego, który za kwotę 250 000 PLN przekazał przedstawicielowi międzynarodowego konsorcjum projekt wyroku zasądzającego odszkodowanie w wysokości 850 mln PLN na 4 dni przed jego publicznym ogłoszeniem na sali rozpraw. Informacja ta posłużyła do spekulacji akcjami konsorcjum na giełdzie w Londynie (insider trading).
• Płaski model uprawnień RBAC: Analiza konfiguracji uprawnień w systemie biurowości sądowej wykazała, że profil "Asystent" posiadał domyślny wgląd do wszystkich spraw we wszystkich wydziałach sądu (karnym, cywilnym, gospodarczym, pracy, rodzinnym). Co więcej, w katalogu sieciowym wydziału projekty orzeczeń i protokoły narad sędziowskich były zapisywane w nieszyfrowanych plikach Word, do których dostęp mieli wszyscy asystenci i stażyści.
• Brak ochrony spraw niejawnych i świadków koronnych: W sprawach karnych dotyczących mafii paliwowej akta zawierające zeznania świadków koronnych i dane operacyjne CBŚP były przetwarzane w ogólnodostępnym module biurowości bez oznaczania klauzulami tajności, a dostęp do nich posiadało ponad 90 urzędników bez poświadczeń bezpieczeństwa ABW.
• Nocna eksfiltracja danych i brak reguł UEBA: Analiza logów zapory sieciowej serwera VPN wykazała, że z kont 8 pracowników sekretariatu pobrano w ciągu ostatnich 3 miesięcy ponad 12 000 plików dokumentów procesowych w godzinach między 01:00 a 04:30 w nocy z prywatnych adresów IP. System nie wygenerował żadnego alertu z powodu braku narzędzi analizy behawioralnej użytkowników (UEBA).

Prezes Sądu Apelacyjnego oraz Ministerstwo Sprawiedliwości zarządzają natychmiastowy audyt kontroli dostępu w formule 90 minut, wyliczenie ryzyka 5x5 i przygotowanie trójfazowego Planu CAP.

Zadanie realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (reprezentuje audyt przed Prezesem Sądu i CBA, odpowiada za zgodność z KRI/KPK/KPC/informacjami niejawnymi, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje bazę systemu Currenda, logi dostępu, bada konfigurację RBAC, projektuje model ABAC, Skarbiec Orzeczeń i reguły UEBA).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza metryki RTO/RPO dla akt procesowych, prowadzi analizę 5 Why dla wycieku orzeczenia, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Analiza logów otwarcia plików projektów wyroków, korelacja sygnatur spraw ze składami orzekającymi oraz logi nocnych sesji VPN.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla wycieku projektu orzeczenia, naruszenia tajemnicy narady i płaskiego modelu RBAC.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why obnażającej brak standardów bezpieczeństwa teleinformatycznego w przetargach na oprogramowanie sądowe.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (wyciek wyroku przed ogłoszeniem, dekonspiracja świadka koronnego, wgląd asystentów w akta rodzinne, masowa nocna kradzież akt przez VPN).
  • Wyznaczenie parametrów BCM: RTO = 15 minut dla zablokowania nieuprawnionego wglądu, RPO = 0 minut dla śladu rewizyjnego logów, MTPD = 2 godziny.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa ABAC i Trójfazowy Plan CAP.
  • Opracowanie Standardu Modelu ABAC: reguły dopuszczające dostęp do akt wyłącznie na podstawie wielowymiarowych atrybutów: `User.Court == Case.Court AND User.Division == Case.Division AND (User.ID IN Case.Judges OR User.ID == Case.AssignedAssistant)`.
  • Projekt "Kryptograficznego Skarbca Orzeczeń": moduł izolowany szyfrujący projekty wyroków kluczem asymetrycznym składu orzekającego; deszyfrowanie i udostępnienie do sekretariatu następuje automatycznie dopiero w chwili podpisania orzeczenia na sali rozpraw.
  • Wdrożenie reguł UEBA: automatyczne blokowanie sesji i alert do Pełnomocnika ds. Bezpieczeństwa przy próbie pobrania ponad 5 akt w nocy lub z obcej geolokalizacji.
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - izolacja projektów orzeczeń, blokada nocnego VPN), Faza 2 (30 dni - wdrożenie silnika ABAC i reguł UEBA), Faza 3 (90 dni - pełne wdrożenie strefy niejawnej i certyfikacja ISO 27001).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Prezesem Sądu.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z oceną kompromitacji wymiaru sprawiedliwości i matrycą priorytetów.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Prezesa Sądu Apelacyjnego.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza korupcji w IAM, zagrożenia procesowe, plan naprawczy ABAC).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności sądowniczej (Prawo o ustroju sądów, KPK art. 108, KPC art. 325, par. 20 KRI, Ustawa o ochronie informacji niejawnych, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=15m, RPO=0, MTPD=2h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Regulamin Ochrony Tajemnicy Narady Sędziowskiej, Architektury ABAC i Nadzoru nad Pobieraniem Akt Procesowych w Sądzie Apelacyjnym".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz bilansu niezawisłości sędziowskiej i cyberbezpieczeństwa.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Wycieku Projektu Wyroku i Naruszenia Tajemnicy Narady Sędziowskiej:

• Condition (Stan faktyczny): Płaski model uprawnień RBAC w systemie biurowości oraz przechowywanie projektów wyroków w nieszyfrowanych plikach Word pozwoliły asystentowi na kradzież i sprzedaż projektu orzeczenia o wartości 850 mln PLN na 4 dni przed ogłoszeniem. W systemie brakowało izolacji spraw ze świadkami koronnymi, a w nocy pobrano 12 000 akt przez VPN bez alertu.
• Criteria (Kryterium): Kodeks postępowania karnego art. 108, Kodeks postępowania cywilnego art. 325 (bezwzględna tajemnica narady sędziowskiej), Rozporządzenie KRI par. 20 ust. 2 pkt 7 i 14, ISO/IEC 27001:2022 Załącznik A.5.15, A.5.18, A.8.2, A.8.16, Ustawa o ochronie informacji niejawnych.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego asystent miał dostęp do projektu wyroku z innego referatu? Bo posiadał ogólną rolę "Asystent" dającą wgląd do wszystkich spraw w wydziale.

  2. Dlaczego system nie ograniczał uprawnień wyłącznie do spraw przypisanych danemu asystentowi? Bo oprogramowanie biurowości sądowej zostało zaprojektowane w architekturze RBAC opartej na funkcjach ogólnych, a nie na przypisaniu referatowym (brak ABAC).

  3. Dlaczego Sądowe Centrum Informatyki nie wdrożyło modelu ABAC? Bo obawiano się, że przy częstych zastępstwach sędziów skomplikowany model uprawnień sparaliżuje pracę sekretariatów.

  4. Dlaczego nie zaimplementowano kryptograficznej strefy ochronnej dla projektów wyroków? Bo w specyfikacji zamówienia publicznego na system teleinformatyczny nie uwzględniono technicznych wymogów ochrony tajemnicy narady sędziowskiej.

  5. Dlaczego dopuszczono do odbioru systemu bez zabezpieczeń konstytucyjnych tajemnic sądownictwa? (PRZYCZYNA ŹRÓDŁOWA): Brak w wymiarze sprawiedliwości jednolitych Standardów Architektury Cyberbezpieczeństwa Sądów Powszechnych wymuszających zasadę Security by Design i ochronę kryptograficzną fazy orzekania.

• Consequence (Wielowymiarowy skutek): Poważny kryzys wizerunkowy i podważenie zaufania do bezstronności polskiego wymiaru sprawiedliwości; unieważnienie procesu gospodarczego i konieczność powtórzenia postępowania od początku; aresztowanie urzędnika sądowego przez CBA; spekulacje giełdowe i roszczenia odszkodowawcze spółek giełdowych; bezpośrednie zagrożenie życia świadków koronnych.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 10 do Polityki Bezpieczeństwa Informacji: Standard Ochrony Tajemnicy Narady Sędziowskiej, Kontroli ABAC i Nadzoru nad Aktami w Sądzie Apelacyjnym":

• Par. 1: Bezwzględna ochrona fazy orzekania (Skarbiec Orzeczeń): Projekty orzeczeń i protokoły narad sędziowskich podlegają obligatoryjnemu szyfrowaniu asymetrycznemu za pomocą kluczy kryptograficznych członków składu orzekającego. Zabrania się ich udostępniania pracownikom sekretariatu przed oficjalnym ogłoszeniem wyroku.
• Par. 2: Model ABAC dla akt sądowych: Dostęp do akt sprawy przysługuje wyłącznie sędziom wchodzącym w skład orzekający, asystentowi wyznaczonemu zarządzeniem przewodniczącego wydziału oraz kierownikowi właściwego sekretariatu. Każda próba otwarcia akt spoza referatu jest blokowana i rejestrowana.
• Par. 3: Nadzór behawioralny UEBA: Wszelkie transfery plików akt sądowych podlegają monitoringowi. Próba pobrania więcej niż 5 akt w ciągu godziny poza godzinami 07:00-19:00 skutkuje natychmiastowym zablokowaniem sesji i powiadomieniem oficera dyżurnego bezpieczeństwa.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Ekstremalna (25/25) - aresztowanie asystenta, wyciek wyroku na 850 mln PLN i niekontrolowane pobieranie akt przez VPN.
• Zagrożenia regulacyjne: Odpowiedzialność dyscyplinarna i karna, podważenie bezstronności sądu, utrata akredytacji ABW dla strefy niejawnej.
• Wnioskowany budżet CAP: 440 000 PLN (moduł ABAC dla Currendy, moduł kryptograficzny Skarbca Orzeczeń, silnik UEBA).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Zablokowanie nocnego VPN, zabezpieczenie folderów orzeczeń, wdrożenie rejestracji dostępu (koszt: 0 PLN).
  • Projekty Strategiczne (30-90 dni): Wdrożenie silnika ABAC, Skarbiec Orzeczeń, strefa niejawna dla świadków koronnych (koszt: 440 000 PLN, TCO 3-letnie: 610 000 PLN).

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

• Zalety: Całkowita eliminacja ryzyka przecieku orzeczeń przed publikacją; szczelna ochrona świadków koronnych; likwidacja ciekawości urzędniczej w sprawach rodzinnych; pełna zgodność z KRI i przepisami KPK/KPC.
• Wady i trudności: Konieczność bieżącego aktualizowania składów orzekających w atrybutach ABAC przy nagłych zastępstwach sędziowskich; opór części urzędników przed stałym monitoringiem UEBA; koszty modyfikacji oprogramowania u dostawcy zewnętrznego.

• Ustawa z dnia 27 lipca 2001 r. - Prawo o ustroju sądów powszechnych (Dz.U. z 2024 r. poz. 334 z późn. zm.).
• Kodeks postępowania karnego - art. 108 (tajemnica narady sędziowskiej).
• Kodeks postępowania cywilnego - art. 325 (tajemnica narady).
• Rozporządzenie Ministra Sprawiedliwości w sprawie Regulaminu urzędowania sądów powszechnych (Dz.U. z 2024 r. poz. 867).
• Rozporządzenie Rady Ministrów w sprawie Krajowych Ram Interoperacyjności (KRI) - par. 20.
• Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. z 2023 r. poz. 756 z późn. zm.).
• NIST Special Publication 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations.

• U1 Student projektuje zaawansowany model ABAC, kryptograficzny Skarbiec Orzeczeń oraz reguły behawioralne UEBA dla wymiaru sprawiedliwości.
• U2 Student dokumentuje uchybienia w modelu 4C i prowadzi wieloetapowe dochodzenie przyczyn źródłowych 5 Why.
• U3 Student wykonuje analizę ryzyka wycieku tajemnic orzeczniczych w matrycy 5x5 i wyznacza metryki BCM (RTO/RPO/MTPD).
• U4 Student opracowuje trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna przepisy ustroju sądów, procedur cywilnych i karnych, KRI oraz standardy ABAC i ochrony informacji niejawnych.
• K1K2K3 Student cechuje się najwyższą etyką prawniczą, dbałością o praworządność i odpornością na presję korporacyjną.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu strategicznego i inżynierskiego architektury zarządzania tożsamością, kontroli dostępu zdalnego oraz uwierzytelniania w strategicznym przedsiębiorstwie przesyłu gazu ziemnego o statusie Operatora Infrastruktury Krytycznej państwa, Podmiotu Kluczowego Dyrektywy NIS2 oraz podmiotu podlegającego Dyrektywie CER (odporność podmiotów krytycznych). Studenci wcielają się w rolę audytorów badających udaremnioną w ostatniej chwili próbę sabotażu tłoczni gazu ziemnego przez wrogą grupę państwową (Advanced Persistent Threat - APT), która przełamała statyczne hasła dostępowe do sieci zakładowej VPN i podjęła próbę modyfikacji parametrów ciśnienia w sterownikach PLC tłoczni (Siemens S7-1500) połączonych bezpośrednio z siecią biurową IT. Zadanie wymaga zbadania zgodności architektury z modelem Purdue (poziomy 3.5, 3 i 2), wyeliminowania pomostów IT/OT, wdrożenia uwierzytelniania wieloskładnikowego odpornego na phishing (FIDO2/WebAuthn), bramy bastionowej PAM ze skakaniem protokołowym (protocol break), kwantyfikacji ryzyka w matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=0s dla systemów ESD, RTO=15m dla SCADA), sformułowania ustaleń w modelu 4C z analizą 5 Why, opracowania trójfazowego Planu CAP oraz Executive Summary dla Komitetu Bezpieczeństwa Energetycznego Rządu.

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

• W1 Ekspercka znajomość zagrożeń sabotażem hybrydowym, terroryzmem teleinformatycznym, rygorów Ustawy o stanie klęski żywiołowej oraz przepisów o ochronie infrastruktury krytycznej.
• W2W3 Wyczerpująca znajomość Ustawy o krajowym systemie cyberbezpieczeństwa (art. 8-16 KSC), Dyrektywy NIS2 (sektor energetyki), Dyrektywy CER, normy PN-EN IEC 62443-3-3 (poziom Security Level SL-3/SL-4), normy ISO/IEC 27001:2022 (A.5.15, A.8.5, A.8.20) oraz wytycznych NIST SP 800-82.
• U1 Opracowanie zintegrowanego Standardu Architektury Secure Remote Access dla środowiska SCADA/OT opartego na modelu Purdue (strefa IDMZ Poziom 3.5), serwerze bastionowym PAM z inspekcją RDP/SSH oraz sprzętowym MFA FIDO2.
• U2 Identyfikacja i dokumentowanie krytycznych podatności w kanonicznym modelu 4C z dogłębną analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka katastrofy przemysłowej i paraliżu dostaw energii w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formacie Pitch to Board.
• K1K2K3 Najwyższa odpowiedzialność inżynierska za bezpieczeństwo publiczne i życie obywateli, odporność na argumenty optymalizacji kosztowej dostawców i bezkompromisowość audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w infrastrukturze krytycznej), Wyk3 (Kontrole dostępowe i sieciowe ISO 27001), Wyk4 (KSC, NIS2 i CER w energetyce), Wyk5 (Risk-based audit ISO 27005 i BCM), Wyk6 (Analiza logów VPN, firewalli przemysłowych i zapytań Modbus/ISO-TSAP), Wyk7 (Model 4C, 5 Why i raportowanie do CSIRT GOV).

Operator Gazociągów Przesyłowych "PolGaz Przesył S.A." zarządza 11 500 km gazociągów wysokiego ciśnienia, 14 tłoczniami gazu, 64 węzłami przesyłowymi oraz 7 podziemnymi magazynami gazu o pojemności 3,2 mld m3. Sterowanie siecią odbywa się z Krajowej Dyspozycji Gazu (KDG) w Warszawie za pośrednictwem rozproszonego systemu SCADA (Telvent OASyS) połączonego ze stacjami operatorskimi HMI, sterownikami PLC (Siemens S7-1500) oraz niezależnymi systemami awaryjnego wyłączenia ESD (Triconex).

Przebieg incydentu i krytyczne ustalenia audytu powłamaniowego:

• Udaremniony sabotaż tłoczni gazu: Zespół CSIRT GOV powiadomił Zarząd PolGaz o wykryciu w sieci przemysłowej tłoczni gazu aktywności grupy APT powiązanej z obcym wywiadem wojskowym. Napastnicy uzyskali dostęp za pośrednictwem skradzionego hasła do konta VPN inżyniera zewnętrznego integratora automatyki. Po zestawieniu tunelu VPN napastnicy połączyli się bezpośrednio z adresem IP sterownika PLC odpowiadającego za regulację ciśnienia gazu na wlocie do tłoczni i podjęli próbę wgrania zmodyfikowanego bloku funkcyjnego (OB1), mającego wywołać niekontrolowany wzrost ciśnienia powyżej limitu wytrzymałości rur (8,4 MPa).
• Brak strefowania Purdue i IDMZ: Audyt architektury sieciowej wykazał, że tunele VPN zewnętrzne łączyły się bezpośrednio z podsiecią automatyki tłoczni (brak Przemysłowej DMZ na poziomie 3.5). Między siecią IT a sterownikami PLC (Poziom 2) nie wdrożono zapory przemysłowej blokującej protokoły automatyki (porty 102/TCP ISO-TSAP i 502/TCP Modbus).
• Przestarzałe uwierzytelnianie bez MFA: Zdalny dostęp dla 18 zewnętrznych firm serwisowych opierał się na statycznych loginach i hasłach zapisanych w plikach tekstowych na komputerach serwisantów. W organizacji nie wdrożono wymuszenia kluczy FIDO2 ani nawet kodów jednorazowych TOTP.
• Brak nadzoru nad sesjami RDP: Połączenia zdalne inżynierów do stacji dyspozytorskich SCADA realizowane były przez standardowy pulpit zdalny RDP bez rejestracji wideo, bez zatwierdzania sesji przez Dyspozytora Mocy i bez rejestracji komend powłoki (brak rozliczalności zmian nastaw technologicznych).
• Brak korelacji logów w SOC: Logi uwierzytelniania VPN i logi zdarzeń sterowników PLC nie były przesyłane do centralnego systemu SIEM, co uniemożliwiło wykrycie połączeń z nietypowych geolokalizacji w godzinach nocnych.

Pełnomocnik Rządu ds. Strategicznej Infrastruktury Energetycznej oraz CSIRT GOV nakazują pilne przeprowadzenie strategicznego audytu IAM w formule 90 minut, wyliczenie ryzyka 5x5 i wdrożenie Planu CAP.

Zadanie realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (odpowiada za relacje z Zarządem, CSIRT GOV, ABW, zgodność z KSC/NIS2/CER, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje architekturę Purdue, konfigurację bram VPN, firewalli przemysłowych, projektuje strefę IDMZ 3.5, bramę PAM i sprzętowe MFA FIDO2).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza metryki RTO/RPO dla przesyłu gazu, prowadzi analizę 5 Why dla incydentu sabotażu, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Analiza logów połączeń VPN, logów zapytań PLC Siemens oraz weryfikacja architektury stref sieciowych pod kątem IEC 62443.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla bezpośredniego dostępu VPN do sterowników PLC bez MFA i próby sabotażu ciśnienia.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why wskazującej na izolację silosową pionów IT i OT w spółce.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (katastrofa przemysłowa i wybuch gazu, atak ransomware na stacje HMI, niekontrolowane zmiany nastaw przez integratorów, sankcje administracyjne KSC).
  • Wyznaczenie wskaźników BCM: RTO = 0 sekund dla systemów ESD, RTO = 15 minut dla stacji dyspozytorskich SCADA, RPO = 0 sekund dla telemetrii ciśnień, MTPD = 1 godzina.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa Secure Remote Access i Trójfazowy Plan CAP.
  • Opracowanie Standardu Bezpiecznego Zdalnego Dostępu Serwisowego (Secure Remote Access): wdrożenie Przemysłowej DMZ (IDMZ Poziom 3.5); całkowity zakaz tuneli VPN do Poziomu 2/3; ruch serwisowy terminowany na serwerze bastionowym PAM w IDMZ ze skakaniem protokołowym (protocol break).
  • Wdrożenie uwierzytelniania odpornego na phishing: wymuszenie sprzętowych kluczy FIDO2 (YubiKey) dla 100% inżynierów i wykonawców zewnętrznych; podwójna autoryzacja sesji (zatwierdzenie przez Dyspozytora Mocy w systemie czterech oczu); nagrywanie wideo i logowanie komend RDP/SSH.
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - natychmiastowe odcięcie bezpośrednich tuneli VPN, tymczasowy dyżur inżyniera przy stacji), Faza 2 (30 dni - wdrożenie bramy PAM w IDMZ i kluczy FIDO2), Faza 3 (90 dni - pełna mikro-segmentacja Purdue i certyfikacja IEC 62443).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Zarządem.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z oceną ryzyka katastrofy i matrycą priorytetów.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Prezesa Zarządu PolGaz Przesył S.A.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza próby sabotażu, ryzyko katastrofy, plan budowy IDMZ i PAM).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności infrastruktury krytycznej (Ustawa o KSC, Dyrektywa NIS2, Dyrektywa CER, norma PN-EN IEC 62443-3-3 poziom SL-3, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=0s (ESD) / RTO=15m (SCADA), RPO=0s, MTPD=1h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Standard Architektury Bezpiecznego Dostępu Zdalnego (Secure Remote Access), Strefowania IDMZ oraz Uwierzytelniania FIDO2 w Środowisku Automatyki Przemysłowej SCADA".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz bilansu ciągłości przesyłu gazu i rygorów obronnych.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Przełamania Dostępu VPN i Próby Sabotażu Ciśnienia Gazu:

• Condition (Stan faktyczny): Bezpośrednie tunele VPN z sieci zewnętrznej do sterowników PLC tłoczni gazu, brak uwierzytelniania wieloskładnikowego (MFA) oraz brak przemysłowej strefy demilitaryzowanej (IDMZ) umożliwiły grupie APT logowanie na skradzionym haśle serwisanta i próbę wgrania złośliwego kodu do sterownika PLC w celu wywołania katastrofalnego wzrostu ciśnienia.
• Criteria (Kryterium): Ustawa o KSC art. 8, 9, 10, Dyrektywa NIS2 art. 21 ust. 2 lit. e, norma PN-EN IEC 62443-3-3 wymagania SR 1.1, SR 1.2, SR 1.13, SR 5.1 (poziom SL-3), ISO/IEC 27001:2022 Załącznik A.5.15, A.8.5, A.8.20.
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego napastnicy mogli połączyć się ze sterownikiem PLC tłoczni? Bo tunel VPN pozwalał na bezpośredni routing pakietów IP do podsieci przemysłowej.

  2. Dlaczego nie wdrożono serwera pośredniczącego w strefie IDMZ? Bo inżynierowie automatyki skonfigurowali tunele w trybie transparentnym, aby umożliwić działanie oprogramowania inżynierskiego Siemensa.

  3. Dlaczego nie wymuszono uwierzytelniania wieloskładnikowego MFA? Bo dostawca oprogramowania SCADA twierdził, że jego moduły nie wspierają protokołów MFA.

  4. Dlaczego Dział Cyberbezpieczeństwa nie narzucił wymagań bezpieczeństwa dla sieci OT? Bo w strukturze spółki pion automatyki przemysłowej (OT) funkcjonował w całkowitej izolacji od pionu bezpieczeństwa IT i nie podlegał procedurom audytowym ISMS.

  5. Dlaczego dopuszczono do braku jednolitego ładu IT/OT? (PRZYCZYNA ŹRÓDŁOWA): Brak w Spółce Zintegrowanego Systemu Zarządzania Bezpieczeństwem Informacji obejmującego środowisko OT (zgodnie z normą IEC 62443 i KSC) oraz brak formalnego umocowania CISO z prawem weta wobec niebezpiecznych rozwiązań teleinformatycznych w infrastrukturze krytycznej.

• Consequence (Wielowymiarowy skutek): Zagrożenie wybuchem gazociągu wysokiego ciśnienia, ofiary śmiertelne wśród załogi tłoczni i ludności okolicznych miejscowości; paraliż dostaw gazu dla 4 milionów odbiorców w kraju; straty materialne liczone w setkach milionów złotych; sankcje administracyjne organu właściwego ds. cyberbezpieczeństwa (do 20 mln PLN); powołanie Rządowego Zespołu Zarządzania Kryzysowego.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 11 do Polityki Bezpieczeństwa Informacji: Standard Bezpiecznego Dostępu Zdalnego (Secure Remote Access) i Strefowania Przemysłowego IDMZ w Systemach SCADA/OT PolGaz Przesył S.A.":

• Par. 1: Bezwzględny zakaz bezpośredniej łączności sieciowej między strefą IT/Internet a poziomem sterowania przemysłowego (Poziom 2 i 3 modelu Purdue). Wszelki ruch z zewnątrz musi być zatrzymany na serwerze bastionowym PAM w Przemysłowej Strefie Demilitaryzowanej (IDMZ Poziom 3.5).
• Par. 2: Standard uwierzytelniania wieloskładnikowego: Wszyscy inżynierowie i integratorzy zewnętrzni uzyskują dostęp do strefy IDMZ wyłącznie za pomocą imiennych, sprzętowych kluczy kryptograficznych FIDO2 (YubiKey). Uwierzytelnianie za pomocą kodów SMS lub aplikacji Push na smartfony jest bezwzględnie zabronione.
• Par. 3: Podwójna autoryzacja sesji serwisowej (Zasada 4 Oczu w OT): Rozpoczęcie sesji zdalnej na serwerze bastionowym wymaga każdorazowej autoryzacji w czasie rzeczywistym przez Dyżurnego Dyspozytora Mocy w KDG. Każda sesja podlega obowiązkowemu nagrywaniu wideo oraz rejestracji przesyłanych komend, a dyspozytor ma możliwość natychmiastowego zerwania sesji jednym przyciskiem.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Ekstremalna (25/25) - bezpośrednia próba sabotażu tłoczni gazu przez wrogą grupę APT i ryzyko wybuchu.
• Zagrożenia regulacyjne: Kary finansowe z ustawy o KSC (do 20 mln PLN), odpowiedzialność karna członków Zarządu, wyłączenie sieci przesyłowej.
• Wnioskowany budżet CAP: 950 000 PLN (zapory przemysłowe IDMZ, klaster serwerów bastionowych PAM dla OT, klucze FIDO2, inspekcja DPI).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Odcięcie tuneli VPN, fizyczna asysta dyspozytora, zmiana poświadczeń (koszt: 10 000 PLN).
  • Projekty Strategiczne (30-90 dni): Budowa IDMZ, wdrożenie klastra PAM, certyfikacja IEC 62443 SL-3 (koszt: 940 000 PLN, TCO 3-letnie: 1 350 000 PLN).

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

• Zalety: Całkowite wyeliminowanie możliwości bezpośredniego ataku z sieci zewnętrznej na sterowniki PLC; odporność uwierzytelniania na zaawansowany phishing i socjotechnikę APT; pełna kontrola dyspozytorska nad każdym ruchem serwisantów; 100% zgodność z KSC, NIS2, CER i normą IEC 62443.
• Wady i trudności: Wysokie koszty zakupu zaawansowanych firewalli przemysłowych i licencji PAM; konieczność asysty dyspozytora przy każdej sesji serwisowej; opór zewnętrznych wykonawców przed koniecznością logowania przez barierę bastionową.

• Norma PN-EN IEC 62443-3-3: Security for industrial automation and control systems - System security requirements and security levels.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077) - art. 8-16.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) - sektor energii i infrastruktury krytycznej.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2557 (Dyrektywa CER) w sprawie odporności podmiotów krytycznych.
• NIST Special Publication 800-82 Rev. 3: Guide to Operational Technology (OT) Security, 2023.
• FIDO Alliance: "High-Assurance Authentication in Critical Infrastructure", Biała Księga, 2023.
• Rządowe Centrum Bezpieczeństwa (RCB): "Krajowy Program Ochrony Infrastruktury Krytycznej", Warszawa.

• U1 Student projektuje zaawansowaną architekturę Secure Remote Access dla sieci przemysłowych w modelu Purdue IDMZ 3.5 z bastionem PAM i FIDO2.
• U2 Student dokumentuje podatności w modelu 4C i prowadzi wieloetapowe dochodzenie przyczyn źródłowych 5 Why.
• U3 Student wykonuje analizę ryzyka sabotażu przemysłowego w matrycy 5x5 i wyznacza metryki ciągłości działania (RTO/RPO/MTPD).
• U4 Student sporządza trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna regulacje KSC, NIS2, CER, normę IEC 62443, wytyczne NIST SP 800-82 i standardy FIDO2.
• K1K2K3 Student cechuje się najwyższą odpowiedzialnością za bezpieczeństwo państwa, bezkompromisowością inżynierską i odpornością na presję dostawców automatyki.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego, symulowanego audytu kontroli wewnętrznej nad procesami recertyfikacji dostępu użytkowników (User Access Review - UAR / Access Certification) w międzynarodowym Centrum Usług Wspólnych (BPO/SSC) przetwarzającym transakcje finansowo-księgowe dla globalnych korporacji notowanych na nowojorskiej giełdzie papierów wartościowych (NYSE). Spółka podlega pod rygor sekcji 404 amerykańskiej ustawy Sarbanes-Oxley Act (SOX 404), międzynarodowy standard atestacyjny ISAE 3402 / SOC 1 Type II oraz wytyczne COSO. Studenci wcielają się w rolę audytorów śledczych badających krytyczne ustalenie niezależnego audytora finansowego, który stwierdził "Istotną Słabość Kontroli Wewnętrznej" (Material Weakness) wywołaną powszechnym zjawiskiem fikcyjnego zatwierdzania uprawnień (rubber-stamping) w arkuszach Excel, drastyczną akumulacją uprawnień transakcyjnych (privilege creep) w systemie SAP S/4HANA Finance oraz występowaniem toksycznych kombinacji ról umożliwiających dokonanie oszustw bilansowych. Zadanie wymaga dekompozycji ról SAP PFCG, wdrożenia platformy Identity Governance and Administration (IGA) opartej na rolach biznesowych i analizie anomalii (Outlier Analysis), kwantyfikacji ryzyka w matrycy 5x5 skorelowanej ze wskaźnikami BCM, procedury 5 Why, trójfazowego Planu CAP oraz przygotowania Executive Summary dla Globalnego Komitetu Audytu.

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

• W1 Ekspercka znajomość rygorów odpowiedzialności karnej i cywilnej zarządów spółek giełdowych za fałszowanie sprawozdań finansowych (SOX Section 906/404), zasad kontroli wewnętrznej COSO i tajemnicy handlowej.
• W2W3 Wyczerpująca znajomość ustawy Sarbanes-Oxley Act (SOX 404), standardu ISAE 3402 / SSAE 18, normy PN-EN ISO/IEC 27001:2022 (A.5.18 - Przegląd praw dostępu, A.5.3), standardów ISACA oraz architektury uprawnień SAP S/4HANA.
• U1 Opracowanie zintegrowanego Standardu Kampanii Recertyfikacji Uprawnień w systemach ERP, opartego na narzędziach IGA, rolach biznesowych, analizie czasu przeglądu i blokadach anty-rubber-stamping.
• U2 Identyfikacja i dokumentowanie uchybień kontroli wewnętrznej w kanonicznym modelu 4C z dogłębną analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka zniekształcenia sprawozdań finansowych i utraty klientów w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formacie Pitch to Board.
• K1K2K3 Bezwzględna dociekliwość, demaskowanie pozornych procedur kontrolnych, etyka zawodowa i odporność na presję kadry menedżerskiej.
• Powiązanie z wykładem: Wyk1 (Audyt w korporacjach międzynarodowych), Wyk3 (Kontrola A.5.18 ISO 27001), Wyk4 (SOX i ISAE 3402 w compliance), Wyk5 (Risk-based audit i matryca 5x5), Wyk6 (Analiza logów kampanii UAR i tabel SAP AGR_USERS / USR02), Wyk7 (Model 4C, 5 Why i raportowanie do Komitetu Audytu).

Centrum Usług Wspólnych "Apex Financial Services SSC" w Krakowie zatrudnia 950 analityków finansowych i księgowych, obsługując procesy księgi głównej (GL), rozrachunków z dostawcami (AP), odbiorcami (AR) oraz płatności masowych dla 18 globalnych koncernów giełdowych z USA i Europy. Prace realizowane są na dedykowanej instancji chmurowej SAP S/4HANA Cloud.

Przebieg incydentu i krytyczne ustalenia audytu kontroli wewnętrznej:

• Wydanie negatywnej opinii audytorskiej (Material Weakness): Czołowa firma audytorska badająca sprawozdania finansowe klientów odmówiła wydania czystej opinii SOX 404 i zawiesiła atestację ISAE 3402 Typ II dla Apex SSC z powodu załamania kontroli nad uprawnieniami w systemie SAP.
• Powszechne zjawisko rubber-stampingu w Excelu: Kampanie rocznego przeglądu uprawnień były realizowane manualnie za pomocą arkuszy kalkulacyjnych generowanych z SAP Basis rozsyłanych pocztą elektroniczną. Analiza metadanych wykazała, że 38 z 45 menedżerów zatwierdziło komplety uprawnień dla swoich zespołów (arkusze liczące po 300-500 wierszy technicznych ról SAP, np. `Z_FI_AP_PAYMENT_RUN`) w czasie poniżej 4 minut od otrzymania pliku, zaznaczając bezrefleksyjnie opcję "Zatwierdź wszystko".
• Zjawisko privilege creep i toksyczne kumulacje ról: Audyt próbki 50 pracowników o stażu pracy powyżej 3 lat wykazał, że 41 osób (82% próby) posiadało aktywne role transakcyjne ze swoich poprzednich stanowisk. U 16 starszych księgowych wykryto krytyczną kumulację ról SoD: możliwość założenia fikcyjnego dostawcy (transakcja `FK01`), zaksięgowania fałszywej faktury (transakcja `FB60`) oraz wygenerowania i uwalniania zlecenia płatniczego do banku (transakcja `F110`).
• Aktywne konta osób na urlopach długoterminowych: Zidentyfikowano 12 aktywnych kont pracowników przebywających na urlopach macierzyńskich lub bezpłatnych powyżej 180 dni, z których na 3 kontach odnotowano logowania i księgowania dokumentów w godzinach nocnych.

Klienci z USA zagrozili natychmiastowym zerwaniem kontraktów o rocznej wartości 42 mln USD. Globalny Komitet Audytu powołuje zespół audytorów do przeprowadzenia śledztwa w formule 90 minut, wyliczenia ryzyka 5x5 i sporządzenia Planu CAP.

Zadanie realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (odpowiada za relacje z Komitetem Audytu, klientami z USA, zgodność z SOX 404/ISAE 3402, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje tabele SAP PFCG, bada transakcje SU01/SUIM, projektuje integrację platformy IGA SailPoint / SAP GRC, role biznesowe i analizę anomalii Outlier Analysis).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza metryki RTO/RPO dla transakcji księgowych, prowadzi analizę 5 Why dla rubber-stampingu, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Analiza czasów modyfikacji arkuszy Excel UAR, ekstrakcja ról z SAP Basis i konfrontacja z bazą HR Workday.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla fikcyjnego procesu recertyfikacji, rubber-stampingu i statusu Material Weakness w SOX 404.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why obnażającej kulturę "odhaczania audytu" (Check-the-box Compliance) i brak narzędzi IGA.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (oszustwo bilansowe przez kumulację ról, zerwanie umów przez klientów giełdowych, utrata atestacji ISAE 3402, błędy księgowe przez privilege creep).
  • Wyznaczenie parametrów BCM: RTO = 1 godzina dla zablokowania ról toksycznych, RPO = 0 minut dla śladu rewizyjnego SAP, MTPD = 4 godziny.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa IGA i Trójfazowy Plan CAP.
  • Opracowanie Standardu Zautomatyzowanej Recertyfikacji Uprawnień: odejście od Excela na rzecz platformy IGA (SailPoint / SAP GRC); tłumaczenie technicznych ról SAP na zrozumiałe role biznesowe (Business Roles); automatyczne oznaczanie ról nieużywanych przez 60 dni z domyślną decyzją "Odbierz".
  • Wdrożenie mechanizmów blokad anty-rubber-stamping: blokada zatwierdzenia masowego dla ról wysokiego ryzyka; wymóg potwierdzenia każdego konfliktu SoD; śledzenie czasu spędzonego przez menedżera nad każdą pozycją.
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - natychmiastowe odebranie uprawnień SoD u 16 księgowych i blokada kont na długich urlopach), Faza 2 (30 dni - wdrożenie portalu IGA i kwartalnej certyfikacji), Faza 3 (90 dni - powiązanie KPI menedżerów z jakością UAR i reaudyt SOX 404).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Komitetem Audytu.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z kalkulacją zagrożeń finansowych i zwrotu z inwestycji IGA.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Przewodniczącego Globalnego Komitetu Audytu.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: diagnoza Material Weakness, ekspozycja na utratę kontraktów na 42 mln USD, plan wdrożenia IGA).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności finansowo-korporacyjnej (SOX Section 404, ISAE 3402 / SOC 1 Type II, ramy COSO, ISO/IEC 27001:2022 A.5.18, standardy ISACA).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=1h, RPO=0, MTPD=4h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Standard Okresowego Przeglądu i Atestacji Uprawnień Użytkowników (User Access Review Policy) oraz Zarządzania Rolami Biznesowymi w SAP S/4HANA".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz bilansu obciążenia menedżerów i redukcji ryzyka nadużyć.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Zjawiska Rubber-Stampingu i Material Weakness w SOX 404:

• Condition (Stan faktyczny): Proces recertyfikacji dostępu oparty na arkuszach Excel był fikcyjny (38 menedżerów zatwierdziło setki ról w czasie < 4 minut). U 82% pracowników stwierdzono privilege creep, a 16 księgowych posiadało pełne uprawnienia do tworzenia dostawców i zlecania płatności (konflikt SoD). Audytor finansowy wydał opinię Material Weakness w SOX 404.
• Criteria (Kryterium): Sarbanes-Oxley Act of 2002 Section 404, ISAE 3402 Type II, COSO Internal Control Framework, ISO/IEC 27001:2022 Załącznik A.5.18 (Przegląd praw dostępu), A.5.3 (Rozdział obowiązków).
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego menedżerowie zatwierdzali uprawnienia bez weryfikacji? Bo arkusze Excel zawierały setki niezrozumiałych nazw technicznych ról SAP.

  2. Dlaczego Dział IT przekazywał surowe nazwy techniczne zamiast ról biznesowych? Bo spółka nie wdrożyła narzędzia IGA/GRC mapującego uprawnienia na procesy księgowe.

  3. Dlaczego nie zakupiono oprogramowania IGA? Bo Zarząd SSC uznał zakup licencji za zbędny koszt, twierdząc, że manualny Excel wystarczy do spełnienia formalnych wymogów audytu.

  4. Dlaczego Dział Kontroli Wewnętrznej tolerował manualny proces? Bo kampanie UAR były traktowane przez kierownictwo jako coroczna formalność biurokratyczna pod audytorów, a nie realna kontrola ryzyka nadużyć.

  5. Dlaczego wykształciła się kultura pozornej zgodności (Check-the-box Compliance)? (PRZYCZYNA ŹRÓDŁOWA): Brak powiązania wskaźników jakości kontroli wewnętrznej i bezpieczeństwa informacji z celami premiowymi (KPI) kadry zarządzającej, co skutkowało priorytetyzacją bieżącej produkcji księgowej nad ładem korporacyjnym.

• Consequence (Wielowymiarowy skutek): Wydanie opinii Material Weakness i zerwanie kontraktów przez klientów z USA o wartości 42 mln USD; spadek wyceny rynkowej grupy kapitałowej; ryzyko dochodzenia amerykańskiej komisji SEC wobec zarządu; bezpośrednie narażenie na wielomilionowe straty z tytułu wewnętrznych oszustw finansowych.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 12 do Polityki Bezpieczeństwa Informacji: Standard Okresowego Przeglądu i Atestacji Uprawnień Użytkowników (User Access Review) oraz Zarządzania Rolami Biznesowymi w Apex Financial Services SSC":

• Par. 1: Zasada obligatoryjnej kwartalnej atestacji uprawnień: Każdy menedżer zespołu operacyjnego ma bezwzględny obowiązek przeprowadzenia kwartalnego przeglądu uprawnień podległych pracowników za pośrednictwem dedykowanego portalu IGA. Zabrania się stosowania arkuszy kalkulacyjnych Excel.
• Par. 2: Standard prezentacji ról biznesowych: Uprawnienia prezentowane są menedżerom w języku procesów biznesowych (np. "Księgowy Zobowiązań - Poziom 2") wraz z wykazem powiązanych uprawnień transakcyjnych i wskaźnikiem ryzyka SoD. Role nieużywane przez użytkownika przez ponad 60 dni są automatycznie oznaczane do odebrania.
• Par. 3: Mechanizmy anty-rubber-stamping: Portal IGA blokuje możliwość zatwierdzenia hurtowego ("Approve All") w przypadku ról zawierających konflikty SoD lub uprawnienia krytyczne. System rejestruje czas analizy każdej pozycji przez menedżera, a atestacje przeprowadzone w czasie poniżej progu minimalnego są automatycznie unieważniane i kierowane do audytu wewnętrznego.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Ekstremalna (25/25) - status Material Weakness w SOX 404 i groźba utraty kontraktów na 42 mln USD.
• Zagrożenia regulacyjne: Sankcje amerykańskiej komisji SEC, utrata reputacji globalnego centrum SSC, odpowiedzialność odszkodowawcza.
• Wnioskowany budżet CAP: 750 000 PLN (wdrożenie modułu IGA SailPoint IdentityIQ, integracja z SAP S/4HANA i Workday, reaudyt SOX).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Odebranie ról toksycznych u 16 księgowych, blokada kont urlopowych (koszt: 0 PLN).
  • Projekty Strategiczne (30-90 dni): Wdrożenie platformy IGA, role biznesowe, usunięcie Material Weakness (koszt: 750 000 PLN, TCO 3-letnie: 1 100 000 PLN).

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

• Zalety: Odzyskanie czystej opinii SOX 404 i atestu ISAE 3402; ocalenie kluczowych kontraktów korporacyjnych; wyeliminowanie ryzyka nadużyć bilansowych; automatyzacja recertyfikacji oszczędzająca ponad 1 200 godzin pracy menedżerów rocznie.
• Wady i trudności: Wysokie koszty zakupu licencji oprogramowania IGA klasy korporacyjnej; konieczność zaangażowania ekspertów biznesowych do zdefiniowania ról biznesowych; początkowy opór menedżerów przed likwidacją prostego zatwierdzania.

• Sarbanes-Oxley Act of 2002 (SOX): Section 404 - Management Assessment of Internal Controls.
• International Auditing and Assurance Standards Board: ISAE 3402 - Assurance Reports on Controls at a Service Organization.
• Committee of Sponsoring Organizations of the Treadway Commission (COSO): Internal Control - Integrated Framework, 2013.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.3, A.5.18, A.8.2.
• ISACA: "Auditing Access Rights and User Access Reviews in Enterprise Applications", 2023.
• SAP SE: "Role-Based Access Control and Compliance in SAP S/4HANA", Walldorf.

• U1 Student projektuje zaawansowany proces recertyfikacji dostępu IGA, role biznesowe oraz mechanizmy blokad anty-rubber-stamping.
• U2 Student dokumentuje uchybienia kontroli wewnętrznej w modelu 4C i prowadzi wieloetapowe dochodzenie 5 Why.
• U3 Student wykonuje analizę ryzyka defraudacji finansowych w matrycy 5x5 i wyznacza metryki BCM (RTO/RPO/MTPD).
• U4 Student sporządza trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna regulacje SOX 404, ISAE 3402, normę ISO 27001 oraz architekturę uprawnień SAP ERP.
• K1K2K3 Student cechuje się bezkompromisowością wobec fikcyjnych procedur korporacyjnych, dociekliwością i najwyższą etyką zawodową.

Celem zadania laboratoryjnego na ocenę 5.0 jest przeprowadzenie zaawansowanego audytu strategicznego i inżynierskiego tożsamości maszynowych (Non-Human Identities - NHI), kont technicznych, serwisowych oraz botów robotyzacji procesów (Robotic Process Automation - RPA) w wiodącej instytucji ubezpieczeniowo-finansowej podlegającej nadzorowi Komisji Nadzoru Finansowego (KNF) oraz reżimowi Rozporządzenia DORA. Studenci wcielają się w rolę audytorów śledczych badających udaną demonstrację przejęcia uprawnień administratora domeny Active Directory (Domain Admins) przeprowadzoną przez zespół Red Team w ataku typu Kerberoasting, który wykorzystał słabe hasła domenowych kont serwisowych z atrybutem Service Principal Name (SPN) powiązanych z botami likwidacji szkód UiPath. Zadanie wymaga przeprowadzenia inwentaryzacji tożsamości maszynowych, wykrycia haseł zapisanych jawnym tekstem w konfiguracjach botów, migracji na konta zarządzane grupowo (Group Managed Service Accounts - gMSA) z automatyczną rotacją 128-bitowych haseł, wdrożenia sejfu sekretów PAM, kwantyfikacji ryzyka w matrycy 5x5 skorelowanej ze wskaźnikami BCM (RTO=15m, RPO=0), sformułowania ustaleń w modelu 4C z analizą 5 Why, opracowania trójfazowego Planu CAP oraz sporządzenia Executive Summary dla Zarządu i UKNF.

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

• W1 Ekspercka znajomość tajemnicy ubezpieczeniowej (Ustawa o działalności ubezpieczeniowej art. 35), tajemnicy przedsiębiorstwa oraz odpowiedzialności zarządu za stabilność operacyjną.
• W2W3 Wyczerpująca znajomość Rozporządzenia DORA (art. 9, 10), Rekomendacji D KNF (Rekomendacje 9, 10, 11), normy PN-EN ISO/IEC 27001:2022 (A.5.15, A.8.2, A.8.5) oraz mechanizmów protokołu uwierzytelniania Kerberos (RFC 4120).
• U1 Opracowanie zintegrowanego Standardu Zarządzania Tożsamościami Nieludzkimi (NHI Governance), architektury migracji na konta gMSA oraz bezpiecznej integracji botów RPA z sejfem poświadczeń HashiCorp Vault / CyberArk.
• U2 Identyfikacja i dokumentowanie uchybiń technicznych w kanonicznym modelu 4C z analizą przyczyn źródłowych Root Cause Analysis (ciąg 5 Why).
• U3 Przeprowadzenie analizy ryzyka całkowitej kompromitacji kontrolera domeny w matrycy 5x5 przed i po zastosowaniu kontroli mitygujących oraz wyznaczenie wskaźników BCM (RTO, RPO, MTPD).
• U4 Opracowanie trójfazowego Planu Działań Korygujących (CAP) ze wskaźnikami KPI i KRI oraz Executive Summary w formacie Pitch to Board.
• K1K2K3 Dociekliwość techniczna w badaniu ukrytych wektorów ataku, bezkompromisowość wobec długu technologicznego tożsamości maszynowych i etyka audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w ubezpieczeniach), Wyk3 (Kontrole A.5.15 i A.8.2 ISO 27001), Wyk4 (DORA i Rekomendacja D KNF), Wyk5 (Risk-based audit i matryca 5x5), Wyk6 (Ekstrakcja kont SPN przez PowerShell i analiza zdarzeń Kerberos Event 4769/4768), Wyk7 (Model 4C, 5 Why i raportowanie zarządcze).

Grupa Finansowo-Ubezpieczeniowa "Aegis Polska S.A." obsługuje 4 miliony ubezpieczonych w segmencie polis majątkowych i na życie, zarządzając aktywami o wartości 14 miliardów PLN. Ekosystem informatyczny obejmuje 140 wirtualnych botów robotyzacji procesów (UiPath RPA), które automatyzują likwidację szkód komunikacyjnych, komunikują się z bazami Ubezpieczeniowego Funduszu Gwarancyjnego (UFG) oraz zlecają przelewy odszkodowań przez interfejsy bankowe.

Przebieg incydentu i krytyczne ustalenia audytu technicznego:

• Udany atak Kerberoasting i przejęcie kontrolera domeny: W trakcie planowanego testu odporności cyfrowej zespół Red Team uzyskał uprawnienia zwykłego użytkownika domeny na jednej ze stacji roboczych, a następnie zażądał biletu Kerberos TGS dla konta serwisowego `svc_uipath_claims`, które posiadało zarejestrowaną główną nazwę usługi (SPN: `MSSQLSvc/db-claims.aegis.local:1433`). Ponieważ konto to posiadało hasło o długości zaledwie 9 znaków z przestarzałym szyfrowaniem RC4-HMAC, audytorzy odzyskali hasło w trybie offline w ciągu 14 minut. Konto to należało do wbudowanej grupy `Domain Admins`, co pozwoliło na natychmiastowe wygenerowanie biletu Golden Ticket i przejęcie kontroli nad wszystkimi serwerami grupy ubezpieczeniowej.
• Masowe naruszenia w zarządzaniu kontami serwisowymi: W domenie Active Directory wykryto 210 domenowych kont użytkowników wykorzystywanych jako konta usługowe. Z nich aż 64 konta posiadały członkostwo w grupie Domain Admins, a wszystkie 210 miało permanentnie włączony atrybut `PasswordNeverExpires` (średni wiek haseł wynosił 6 lat).
• Hasła jawne w konfiguracjach RPA: W skryptach i plikach konfiguracyjnych `.config` 140 botów UiPath hasła dostępowe do produkcyjnych baz danych SQL oraz klucze API do bram płatności były zapisane otwartym tekstem na ogólnodostępnym zasobie sieciowym `\\nas-shares\rpa_configs`.
• Brak monitorowania zdarzeń Kerberos: W systemie SIEM w SOC nie wdrożono reguł korelacyjnych dla zdarzeń Event ID 4769 (żądanie biletu Kerberos z typem szyfrowania 0x17 - RC4), co oznacza, że realny cyberatak Kerberoasting mógł trwać tygodniami całkowicie niewykryty przez analityków bezpieczeństwa.

Urząd Komisji Nadzoru Finansowego (UKNF) zapowiedział inspekcję doraźną pod kątem spełnienia wytycznych Rekomendacji D oraz Rozporządzenia DORA. Zarząd Aegis Polska S.A. powołuje zespół audytorów do przeprowadzenia śledztwa w formule 90 minut, wyliczenia ryzyka 5x5 i sporządzenia Planu CAP.

Zadanie realizowane jest w 2-3 osobowej Triadzie Audytorskiej:

• Faza 1 (Minuty 00-15): Triada audytorska, podział ról i triage dowodowy.
  • Wyznaczenie ról w zespole:
    • Rola A: Lead Auditor / CISO Representative (reprezentuje audyt przed Zarządem i UKNF, odpowiada za zgodność z DORA/KNF, redaguje Executive Summary).
    • Rola B: Technical SecOps Auditor (analizuje atrybuty SPN, logi Event 4769/4768, bada podatności RC4 vs AES-256, projektuje migrację na konta gMSA i integrację sejfu HashiCorp Vault z UiPath).
    • Rola C: BCM & Compliance Auditor (tworzy matrycę ryzyka 5x5, wyznacza metryki RTO/RPO dla bazy likwidacji szkód, prowadzi analizę 5 Why dla przejęcia kontrolera domeny, tworzy trójfazowy Plan CAP).
  • Triage dowodowy: Ekstrakcja kont SPN skryptem PowerShell (`Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties *`), analiza logów Security Event Log kontrolera domeny.
• Faza 2 (Minuty 15-40): Opracowanie Karty Ustalenia 4C, Analiza Ryzyka 5x5 i Root Cause Analysis.
  • Sformułowanie Karty Niezgodności Dużej (NC1) w modelu 4C dla podatności Kerberoasting, kont serwisowych w Domain Admins i jawnych haseł w botach RPA.
  • Przeprowadzenie analizy przyczyn źródłowych 5 Why obnażającej ignorowanie tożsamości maszynowych i brak strategii NHI Governance.
  • Skonstruowanie matrycy ryzyka 5x5 dla 4 kluczowych zagrożeń (przejęcie domeny w ataku Kerberoasting, kradzież haseł z plików botów RPA, wyciek bazy 4 mln polis ubezpieczeniowych, sankcje finansowe KNF i DORA).
  • Wyznaczenie wskaźników BCM: RTO = 15 minut dla unieważnienia biletów Kerberos (Kerberos Armoring / krbtgt reset), RPO = 0 transakcji (brak utraty danych polisowych), MTPD = 2 godziny.
• Faza 3 (Minuty 40-70): Architektura bezpieczeństwa gMSA i Trójfazowy Plan CAP.
  • Opracowanie Standardu Zarządzania Tożsamościami Nieludzkimi (NHI Policy): całkowity zakaz członkostwa kont serwisowych w Domain Admins; program migracji 180 usług na Group Managed Service Accounts (gMSA) z automatyczną rotacją 128-bitowych haseł co 30 dni; wymuszenie szyfrowania Kerberos AES-256.
  • Bezpieczna architektura RPA: integracja botów UiPath z sejfem HashiCorp Vault przez API z użyciem certyfikatów maszynowych; całkowite usunięcie haseł otwartym tekstem z plików konfiguracyjnych.
  • Konfiguracja SIEM w SOC: wdrożenie reguły czasu rzeczywistego dla Event ID 4769 z typem szyfrowania 0x17 (RC4).
  • Zestawienie Trójfazowego Planu CAP: Faza 1 (0-7 dni - odebranie Domain Admins kontom serwisowym, zmiana haseł SPN na 30-znakowe), Faza 2 (30 dni - wdrożenie gMSA i sejfu Vault dla RPA), Faza 3 (90 dni - likwidacja RC4 i pełna zgodność z DORA).
• Faza 4 (Minuty 70-90): Synteza Executive Summary i ustna obrona przed Zarządem.
  • Przygotowanie 1-stronicowego Podsumowania Zarządczego (Executive Summary - "Pitch to Board") z oceną kompromitacji tożsamości maszynowych i matrycą priorytetów.
  • 5-minutowa obrona ustna przed prowadzącym laboratorium pełniącym rolę Prezesa Zarządu Aegis Polska S.A.

Końcowy raport z audytu (objętość 12-16 stron A4) musi zawierać następujące rozdziały:

• Strona tytułowa i Metryka Audytu (skład Triady Audytorskiej, role A/B/C, data audytu, oświadczenie o bezstronności).
• Rozdział 1: Podsumowanie Zarządcze (Executive Summary - 1 strona A4: syntetyczna diagnoza ataku Kerberoasting, ekspozycja na sankcje KNF, plan migracji na gMSA).
• Rozdział 2: Profil podmiotu i wielowymiarowa matryca zgodności ubezpieczeniowej (DORA art. 9 i 10, Rekomendacja D KNF Rekomendacje 9-11, Tajemnica ubezpieczeniowa, ISO/IEC 27001:2022).
• Rozdział 3: Zaawansowana Analiza Ryzyka w Matrycy 5x5 i Wskaźniki BCM:
  • Tabela prawdopodobieństwa (1-5) i skutku (1-5) w skali 25-punktowej.
  • Wyliczenie ryzyka inherentnego (IR) i rezydualnego (RR) wraz ze wskaźnikami RTO=15m, RPO=0, MTPD=2h.
• Rozdział 4: Projekt Załącznika Wykonawczego do PBI: "Polityka Zarządzania Tożsamościami Nieludzkimi (NHI), Kontami Serwisowymi gMSA oraz Bezpieczeństwa Botów RPA w Aegis Polska S.A.".
• Rozdział 5: Rejestr Ustaleń w Modelu 4C z Analizą Przyczyn Źródłowych 5 Why oraz Trójfazowy Plan CAP ze wskaźnikami KPI i KRI.
• Rozdział 6: Analiza wad, zalet, kosztów TCO oraz bilansu ciągłości procesów automatyzacji i cyberodporności.

Wzorcowe rozwiązanie poziomu 5.0 obejmuje:

A. Karta Niezgodności Dużej (NC1) w kanonicznym modelu 4C dla Incydentu Ataku Kerberoasting i Przejęcia Kontrolera Domeny:

• Condition (Stan faktyczny): 64 konta serwisowe posiadały uprawnienia Domain Admins, 210 miało niewygasające hasła (wiek 6 lat), a 38 kont SPN korzystało ze słabych haseł i szyfrowania RC4, co pozwoliło na przełamanie hasła w 14 minut i przejęcie kontrolera domeny w ataku Kerberoasting. Hasła 140 botów RPA były zapisane jawnym tekstem na zasobie sieciowym.
• Criteria (Kryterium): Rozporządzenie DORA art. 9 i 10, Rekomendacja D KNF (Rekomendacje 9, 10, 11), ISO/IEC 27001:2022 Załącznik A.5.15, A.8.2, A.8.5, Ustawa o działalności ubezpieczeniowej art. 35 (tajemnica ubezpieczeniowa).
• Cause (Przyczyna źródłowa - analiza 5 Why):

  1. Dlaczego konto bota likwidacji szkód należało do Domain Admins? Bo podczas instalacji aplikacji dochodziło do błędów uprawnień i administrator nadał najwyższe uprawnienia, aby usługa działała.

  2. Dlaczego nikt nie zredukował uprawnień po uruchomieniu aplikacji? Bo Dział IT obawiał się, że zmiana uprawnień spowoduje awarię wypłat odszkodowań.

  3. Dlaczego nie wdrożono kont zarządzanych grupowo gMSA? Bo administratorzy nie znali procedury wdrażania gMSA w środowisku klastrowym Windows Server.

  4. Dlaczego Dział Cyberbezpieczeństwa nie audytował kont maszynowych? Bo polityki bezpieczeństwa w firmie koncentrowały się wyłącznie na kontach pracowników, całkowicie ignorując tożsamości nieludzkie (NHI).

  5. Dlaczego ignorowano tożsamości maszynowe? (PRZYCZYNA ŹRÓDŁOWA): Brak w Spółce kompleksowej Strategii Zarządzania Tożsamościami Nieludzkimi (NHI Governance) oraz brak narzędzi klasy PAM/Secrets Management dedykowanych dla zautomatyzowanych potoków RPA.

• Consequence (Wielowymiarowy skutek): Całkowita kompromitacja domeny Active Directory i możliwość kradzieży bazy 4 milionów polis; ryzyko paraliżu wypłat odszkodowań; dotkliwe kary finansowe od KNF i z tytułu Rozporządzenia DORA (do 10 mln EUR lub 5% obrotu); utrata zaufania klientów i spadek sprzedaży polis.

B. Zaawansowana Matryca Ryzyka 5x5 i Metryki Ciągłości Działania (BCM):

C. Trójfazowy Plan Działań Korygujących (CAP):

D. Sformalizowany Projekt Załącznika do PBI:

"Załącznik nr 13 do Polityki Bezpieczeństwa Informacji: Standard Zarządzania Tożsamościami Maszynowymi (NHI), Kontami Serwisowymi gMSA oraz Bezpieczeństwa Botów RPA w Aegis Polska S.A.":

• Par. 1: Bezwzględny zakaz członkostwa tożsamości nieludzkich (kont serwisowych, kont maszynowych, botów) w grupach podwyższonych uprawnień domenowych (`Domain Admins`, `Enterprise Admins`, `Schema Admins`, `Account Operators`). Wszelkie uprawnienia muszą wynikać z zasady najmniejszych uprawnień (Least Privilege).
• Par. 2: Standard kont zarządzanych grupowo (gMSA): Usługi Windows, pule aplikacji IIS oraz zadania harmonogramu muszą być uruchamiane wyłącznie na kontach typu Group Managed Service Accounts (gMSA). Hasła tych kont są generowane kryptograficznie (128 znaków) i automatycznie rotowane przez kontrolery domeny co 30 dni.
• Par. 3: Reżim poświadczeń dla automatyzacji RPA: Boty UiPath pobierają poświadczenia do systemów zewnętrznych wyłącznie w czasie wykonywania zadania (in-memory) za pośrednictwem API sejfu HashiCorp Vault. Zabrania się przechowywania haseł w plikach konfiguracyjnych, skryptach, repozytoriach kodu lub bazach danych pod rygorem odpowiedzialności dyscyplinarnej.

E. Podsumowanie Zarządcze (Executive Summary - "Pitch to Board"):

• Ekspozycja na ryzyko: Ekstremalna (25/25) - przejęcie kontrolera domeny w 14 minut w ataku Kerberoasting i jawne hasła 140 botów RPA.
• Zagrożenia regulacyjne: Kary finansowe KNF i DORA (do 10 mln EUR), utrata reputacji, ryzyko paraliżu likwidacji szkód.
• Wnioskowany budżet CAP: 580 000 PLN (sejf HashiCorp Vault Enterprise, narzędzia audytu kont gMSA, reguły analityczne w SIEM).
• Matryca Priorytetów:
  • Quick Wins (0-7 dni): Odebranie uprawnień Domain Admins, zmiana haseł kont SPN na 32 znaki, reguła SIEM (koszt: 0 PLN).
  • Projekty Strategiczne (30-90 dni): Wdrożenie gMSA dla 180 usług, integracja sejfu z botami RPA, wyłączenie RC4 (koszt: 580 000 PLN, TCO 3-letnie: 820 000 PLN).

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

• Zalety: Całkowita eliminacja podatności Kerberoasting; automatyzacja zarządzania hasłami eliminująca błędy ludzkie; pełna ochrona tajemnicy ubezpieczeniowej i danych klientów; 100% zgodność z Rekomendacją D KNF i Rozporządzeniem DORA.
• Wady i trudności: Złożoność techniczna wdrożenia kont gMSA w architekturze rozproszonej; konieczność przepisania modułów logowania w 140 botach RPA pod kątem API sejfu; ryzyko chwilowych przestojów aplikacji podczas migracji kont serwisowych.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) - art. 9 i 10.
• Komisja Nadzoru Finansowego: Rekomendacja D dotycząca zarządzania obszarami IT w bankach i zakładach ubezpieczeń (Rekomendacje 9, 10, 11).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15, A.8.2, A.8.5.
• Ustawa z dnia 11 września 2015 r. o działalności ubezpieczeniowej i reasekuracyjnej (Dz.U. z 2023 r. poz. 656 z późn. zm.) - art. 35.
• IETF RFC 4120: The Kerberos Network Authentication Service (V5).
• Microsoft Corporation: "Active Directory Kerberoasting Defense and gMSA Deployment Guide", 2023.
• Center for Internet Security (CIS): CIS Microsoft Windows Server Benchmark - Service Account Hardening.

• U1 Student projektuje zaawansowany model zarządzania tożsamościami maszynowymi NHI, migrację na konta gMSA oraz integrację sejfu poświadczeń z botami RPA.
• U2 Student dokumentuje krytyczne uchybienia domenowe w modelu 4C i prowadzi wieloetapowe dochodzenie 5 Why.
• U3 Student wykonuje analizę ryzyka kompromitacji tożsamości nieludzkich w matrycy 5x5 i wyznacza metryki BCM (RTO/RPO/MTPD).
• U4 Student sporządza trójfazowy Plan CAP z metrykami KPI/KRI oraz Executive Summary w formacie Pitch to Board.
• W1W2W3 Student zna regulacje DORA, Rekomendację D KNF, protokół Kerberos oraz standardy bezpieczeństwa kont serwisowych.
• K1K2K3 Student cechuje się techniczną dociekliwością, bezkompromisowością wobec długu technologicznego i dbałością o odporność cyfrową sektora finansowego.