Laboratorium 2

Celem zadania na ocenę 4.0 jest wykształcenie umiejętności opracowania zaawansowanego, wieloaspektowego planu audytu ISMS w szpitalu wielospecjalistycznym posiadającym status Operatora Usługi Kluczowej w rozumieniu dyrektywy NIS2 i ustawy o KSC. Zadanie wymaga skonstruowania planu audytu, który obejmuje aparaturę medyczną zintegrowaną z siecią (Internet of Medical Things - IoMT), przeprowadzenia formalnego szacowania ryzyka w matrycy 3x3, sklasyfikowania wykrytych uchybień w gradacji NC1/NC2/OFI oraz zaprojektowania Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych (Root Cause Analysis - metoda 5 Why).

• U1 Opracowanie zaawansowanego planu audytu ISMS w podmiocie leczniczym o statusie podmiotu kluczowego.
• U2 Bezbłędna gradacja niezgodności (NC1 - Niezgodność Duża, NC2 - Niezgodność Mała, OFI - Szansa na poprawę).
• U3 Przeprowadzenie analizy ryzyka (risk-based audit) w matrycy 3x3 dla systemów ratujących życie i bazy danych pacjentów.
• U4 Opracowanie profesjonalnego Planu Działań Korygujących (CAP) z przypisaniem właścicieli i harmonogramu naprawczego.
• W1 Znajomość przepisów o ochronie tajemnicy medycznej, danych wrażliwych (art. 9 RODO) i rygorów ustawy o prawach pacjenta.
• W2W3 Wymagania normy ISO/IEC 27001:2022, wytyczne normy branżowej ISO 27799 (bezpieczeństwo w zdrowiu), dyrektywy NIS2 i ustawy o KSC.
• K1K2K3 Etyka audytorska, odporność na presję ordynatorów, zachowanie tajemnicy zawodowej oraz kultura konstruktywnego dialogu.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole ISO 27001/27002), Wyk4 (RODO i NIS2), Wyk5 (ISO 27005), Wyk7 (Niezgodności i CAP).

Wojewódzki Szpital Zespolony im. dr. Władysława Biegańskiego w mieście wojewódzkim jest jednym z największych podmiotów leczniczych w regionie (720 łóżek, 22 oddziały, w tym Centrum Urazowe SOR, Kardiochirurgia, OIOM, Onkologia, Blok Operacyjny z 14 salami zabiegowymi). Szpital zatrudnia 1 450 pracowników.

Architektura teleinformatyczna i infrastruktura biomedyczna:

• Szpitalny System Informacyjny (HIS/EDM) pracujący w oparciu o klaster bazodanowy Oracle w centralnej serwerowni szpitala.
• System archiwizacji i dystrybucji obrazów PACS/RIS o wolumenie ponad 60 TB danych diagnostycznych (rezonanse, tomografy, angiografy).
• Sieć IoMT (Internet of Medical Things): ponad 400 urządzeń medycznych posiadających interfejsy IP (kardiomonitory, pompy infuzyjne, respiratory, systemy telemetrii kardiologicznej).

W toku audytu zerowego ujawniono następujące złożone incydenty i uchybienia:

• Zagrożenie w strefie IoMT: Kardiomonitory na oddziale kardiologii inwazyjnej oraz tomograf w zakładzie radiologii pracują na niemodyfikowalnym systemie Windows 7 Embedded. Urządzenia te znajdują się w tej samej podsieci co komputery biurowe lekarzy, a serwis zagraniczny łączy się z nimi przez nieszyfrowane sesje AnyDesk bez autoryzacji działu IT szpitala.
• Blok operacyjny i uwierzytelnianie: Chirurdzy i anestezjolodzy logują się na salach operacyjnych za pomocą jednego konta "blok_sala_5" bez hasła, tłumacząc to koniecznością natychmiastowego podejrzenia skanów tomograficznych podczas operacji bez zanieczyszczania sterylnych rękawic.
• Incydent ransomware: Trzy miesiące temu doszło do próby zaszyfrowania serwera archiwum PACS w wyniku otwarcia złośliwego załącznika przez sekretarkę medyczną; atak odparto, lecz kopie zapasowe PACS wykonywane są wyłącznie na lokalną macierz dyskową w tej samej szafie rackowej (brak zasady 3-2-1 i braku izolacji air-gap).
• Szpital został formalnie uznany za podmiot kluczowy dyrektywy NIS2. Dyrekcja oczekuje od zespołu audytorskiego kompleksowego planu audytu, który pozwoli na audyt risk-based, wskazanie niezgodności i przygotowanie planu CAP.

Zespół audytorów (2-3 studentów) opracowuje zaawansowany plan audytu:

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

Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Dyrekcją i Naczelną Pielęgniarką, protokół spotkania otwierającego i zamykającego, ustalenie zakresu, granic i uzasadnionych wyłączeń, spójność metodologiczną planu audytu.

Student 2 (Audytor Bezpieczeństwa IT, Sieci i IoMT): Projektuje metody badania segmentacji sieci szpitalnej, konfiguracji zapór ogniowych, analizy logów w systemie HIS/PACS, bezpieczeństwa urządzeń biomedycznych i polityki kopii zapasowych.

Student 3 (Audytor Ryzyka, Zgodności i Działań Korygujących): Odpowiada za konstrukcję matrycy szacowania ryzyka 3x3, gradację zidentyfikowanych uchybień (NC1/NC2/OFI), przygotowanie tabeli CAP z analizą Root Cause oraz audyt procedur RODO i NIS2.

• Krok 2 (Wytyczenie granic, zakresu i rygorów bezpieczeństwa pacjenta):

Zdefiniujcie:

• Zakres podmiotowy: Budynek główny, pawilon zabiegowy, zakłady diagnostyczne, centralna serwerownia, stacje robocze, flota IoMT.
• Bezwzględny zakaz inwazyjnych testów: Zakaz aktywnego skanowania podatności urządzeń podtrzymujących życie i monitorujących pacjentów w czasie rzeczywistym. Wszelkie weryfikacje IoMT odbywają się metodą inspekcji konfiguracji, wywiadu i analizy ruchu sieciowego w trybie nasłuchu (SPAN/mirror port).

Kryteria: Norma PN-EN ISO/IEC 27001:2022 (wymagania 6.1, 8.1 oraz Załącznik A: kontrole A.5.15, A.7.1, A.8.13, A.8.20, A.8.22), norma PN-EN ISO 27799 (bezpieczeństwo informacji w zdrowiu), Rozporządzenie RODO (art. 9, 32), Ustawa o KSC / Dyrektywa NIS2.

• Krok 4 (Szacowanie ryzyka audytowego - matryca 3x3):

Przeprowadźcie ocenę ryzyka dla 3 newralgicznych procesów:

• Ryzyko 1: Przejęcie kontroli nad kardiomonitorem lub tomografem przez otwarty pulpit zdalny AnyDesk.
• Ryzyko 2: Nieuprawniony dostęp i manipulacja danymi w systemie EDM wskutek konta bez hasła na bloku operacyjnym.
• Ryzyko 3: Całkowita utrata bazy obrazowej PACS wskutek ataku ransomware przy braku kopii offline.

Obliczcie poziom ryzyka inherentnego (Prawdopodobieństwo 1-3 x Skutek 1-3) i wskażcie planowane kontrole redukujące ryzyko rezydualne do poziomu akceptowalnego.

• Krok 5 (Klasyfikacja niezgodności - NC1/NC2/OFI):

Sklasyfikujcie uchybienia:

• NC1 (Niezgodność Duża): Brak izolacji i kontroli dostępu do aparatury IoMT zagrażający życiu pacjentów (naruszenie Załącznika A.8.20 i A.8.22 ISO 27001 oraz art. 32 RODO).
• NC2 (Niezgodność Mała): Współdzielone konto bez hasła na bloku operacyjnym (naruszenie Załącznika A.5.15 i A.8.5).
• OFI (Szansa na poprawę): Brak wdrożenia bezprzewodowych kart zbliżeniowych RFID/NFC dla chirurgów w celu bezdotykowego uwierzytelniania.

Sporządźcie tabelę CAP z analizą przyczyny źródłowej (5 Why), działaniem korygującym, przypisaniem osoby odpowiedzialnej (Właściciela) oraz terminem realizacji (np. 14 dni dla odcięcia AnyDesk, 60 dni dla zakupu zapory NGFW i kart RFID).

• Krok 7 (Harmonogram wielostrumieniowy - 4 dni audytu):

Rozpiszcie harmonogram uwzględniający równoległą pracę audytora technicznego i audytora zgodności.

Struktura 15-minutowego wystąpienia seminaryjnego przed komisją:

• Wprowadzenie i kontekst podmiotu kluczowego NIS2 (2 min): Specyfika szpitala wojewódzkiego i wyzwania ochrony danych medycznych (Student 1).
• Matryca ryzyka risk-based audit i granice audytu IoMT (4 min): Prezentacja szacowania ryzyka 3x3 oraz uzasadnienie wyłączeń i metod bezinwazyjnych (Student 3).
• Przebieg audytu technicznego i weryfikacji architektury (4 min): Przedstawienie wyników analizy AnyDesk, sieci PACS i uwierzytelniania na salach operacyjnych (Student 2).
• Rejestr niezgodności NC1/NC2/OFI oraz Plan Działań Korygujących CAP (3 min): Omówienie analizy przyczyn źródłowych i harmonogramu naprawczego (Student 3 i 1).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania komisji dotyczące radzenia sobie z oporem ordynatorów i konfliktami audytowymi (cały zespół).

Raport składany na zaliczenie (8-12 stron znormalizowanego maszynopisu) musi obejmować:

A. Wyczerpujący opis uwarunkowań prawno-organizacyjnych Wojewódzkiego Szpitala Zespolonego.

B. Zaawansowany Plan Audytu ISMS (Program i Metodyka):

• Tytuł: Zintegrowany Plan Audytu Bezpieczeństwa Informacji i Cyberodporności w Wojewódzkim Szpitalu Zespolonym.
• Cel nadrzędny: Weryfikacja zgodności SZBI z normą ISO/IEC 27001:2022, wytycznymi ISO 27799 oraz rygorami dyrektywy NIS2 dla podmiotów kluczowych.
• Zakres audytu: System HIS/EDM, system PACS/RIS, sieć IoMT, blok operacyjny, SOR, serwerownia główna, procedury kopii zapasowych, umowy z dostawcami aparatury medycznej.
• Wyłączenia: Bezpośrednie oprogramowanie układowe (firmware) pomp infuzyjnych i respiratorów podczas pracy przy pacjencie (badanie wyłącznie na stoisku serwisowym).
• Matryca szacowania ryzyka (Risk-Based Matrix 3x3):
  • Aktyw 1: Sieć aparatury IoMT (tomograf, kardiomonitory). Zagrożenie: Zdalne przejęcie przez nieszyfrowany AnyDesk. P=3 (Wysokie), S=3 (Krytyczne - zagrożenie życia pacjenta). Ryzyko inherentne: 9/9 (Niedopuszczalne). Planowana kontrola: Mikro-segmentacja sieci, firewall NGFW, VPN na żądanie. Ryzyko rezydualne: P=1, S=2 (Poziom 2/9 - Akceptowalne).
  • Aktyw 2: Baza obrazowa PACS (45 TB badań). Zagrożenie: Infekcja ransomware i brak kopii offline. P=3, S=3. Ryzyko inherentne: 9/9. Planowana kontrola: Wdrożenie kopii niemodyfikowalnej WORM i procedury 3-2-1 z nośnikiem poza szpitalem. Ryzyko rezydualne: P=1, S=1 (Poziom 1/9 - Akceptowalne).
  • Aktyw 3: Stacje robocze na Bloku Operacyjnym. Zagrożenie: Niekontrolowana zmiana lub usunięcie historii leczenia przez brak haseł. P=2, S=3. Ryzyko inherentne: 6/9 (Wysokie). Planowana kontrola: Karty zbliżeniowe RFID z kodem PIN. Ryzyko rezydualne: P=1, S=2 (Poziom 2/9 - Akceptowalne).
• Rejestr Niezgodności (NC1/NC2/OFI):
  • Ustalenie 1 (NC1 - Niezgodność Duża): Otwarty dostęp zdalny AnyDesk do aparatury IoMT z systemem Windows 7 bez nadzoru IT. Podstawa: ISO 27001 A.8.20, A.8.22; NIS2 art. 21 ust. 2 lit. c; RODO art. 32. Dowód: Zrzut konfiguracji adaptera sieciowego tomografu i logi połączeń AnyDesk.
  • Ustalenie 2 (NC2 - Niezgodność Mała): Współdzielone konto "blok_sala_5" bez hasła na bloku operacyjnym. Podstawa: ISO 27001 A.5.15, A.8.5. Dowód: Bezpośrednia obserwacja audytora podczas wizytacji bloku operacyjnego.
  • Ustalenie 3 (OFI - Szansa na Poprawę): Brak automatycznej weryfikacji integralności kopii zapasowych PACS w środowisku piaskownicy (sandbox). Podstawa: ISO 27001 A.8.13. Dowód: Wywiad z administratorem macierzy dyskowych.
• Plan Działań Korygujących (CAP) - Analiza Przyczyn Źródłowych:
  • Dla Ustalenia 1 (NC1):
    • Analiza 5 Why: Dlaczego AnyDesk był otwarty? -> Bo serwisant producenta musiał szybko usuwać awarie. Dlaczego bez wiedzy IT? -> Bo dział zamówień kupił tomograf bez konsultacji wymagań cyberbezpieczeństwa z IT. Dlaczego bez konsultacji? -> Brak procedury Security by Design w zakupach szpitala. Przyczyna źródłowa (Root Cause): Brak zintegrowanej procedury zakupowej uwzględniającej wymagania bezpieczeństwa teleinformatycznego przy kontraktowaniu aparatury medycznej.
    • Działanie naprawcze: Natychmiastowe zablokowanie ruchu AnyDesk na brzegu sieci, konfiguracja dedykowanego VLAN-u z inspekcją ruchu, aneksowanie umowy z serwisem na zestawianie tunelu IPsec VPN na żądanie z rejestracją sesji.
    • Właściciel: Kierownik Działu IT we współpracy z Działem Aparatury Medycznej.
    • Termin: 14 dni na blokadę i VPN; 45 dni na aneks do umowy.
  • Dla Ustalenia 2 (NC2):
    • Działanie naprawcze: Wdrożenie czytników kart RFID zintegrowanych z odzieżą chirurgiczną i szybkim kodem PIN.
    • Właściciel: Główny Informatyk i Naczelna Pielęgniarka.
    • Termin: 60 dni.
• Harmonogram wielostrumieniowy audytu (4 dni robocze):
  • Dzień 1: Spotkanie otwierające z Dyrekcją, przegląd polityk ISMS i procedur NIS2; weryfikacja architektury serwerowni i kopii zapasowych.
  • Dzień 2 (równolegle): Strumień A (Audytor 2) - pasywna analiza sieci IoMT i stacji diagnostycznych; Strumień B (Audytor 3) - audyt procedur przyjęć pacjentów, SOR i archiwum papierowego.
  • Dzień 3 (równolegle): Strumień A (Audytor 2) - inspekcja bloku operacyjnego i weryfikacja logowań; Strumień B (Audytor 3) - audyt umów z dostawcami aparatury i weryfikacja zgłoszeń incydentów do CSIRT.
  • Dzień 4: Triangulacja dowodów, narada zespołu, opracowanie kart niezgodności, formalne spotkanie zamykające z Zarządem Szpitala.

C. Analiza zalet i wad przyjętego rozwiązania:

• Zalety: Wyeliminowanie wektorów ataków bezpośrednio zagrażających życiu pacjentów; wdrożenie podejścia Root Cause Analysis zapobiegające powrotowi problemu; spełnienie standardów certyfikacji ISO 27001 i NIS2.
• Wady i trudności: Wysokie nakłady finansowe na wymianę oprogramowania i czytniki zbliżeniowe; konieczność przełamania wieloletnich nawyków personelu lekarskiego.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) - podmioty kluczowe w sektorze ochrony zdrowia.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji - Wymagania.
• Norma PN-EN ISO 27799:2016 - Zarządzanie bezpieczeństwem informacji w dziedzinie zdrowia przy użyciu ISO/IEC 27002.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania (punkt 6.4: Przeprowadzanie audytu, gradacja ustaleń).
• Norma PN-EN ISO/IEC 27005:2022 - Zarządzanie ryzykiem w bezpieczeństwie informacji.
• Centrum e-Zdrowia (CeZ): "Standardy cyberbezpieczeństwa dla szpitali i podmiotów leczniczych w Polsce", Warszawa 2023.

• U1 Student konstruuje zaawansowany plan audytu ISMS dla złożonego podmiotu leczniczego.
• U2 Student bezbłędnie klasyfikuje uchybienia na NC1, NC2 i OFI, wskazując precyzyjne punkty normy ISO 27001 i przepisów.
• U3 Student przeprowadza szacowanie ryzyka w matrycy 3x3 w ujęciu risk-based audit.
• U4 Student opracowuje profesjonalny plan CAP z analizą 5 Why i mierzalnymi terminami.
• W1W2W3 Student łączy standardy ISO 27001 i ISO 27799 z wymaganiami dyrektywy NIS2 i RODO.
• K1K2K3 Student demonstruje wysokie standardy etyczne i umiejętność rozwiązywania problemów w zespole audytowym.

Celem zadania na ocenę 4.0 jest opanowanie umiejętności zaplanowania zintegrowanego audytu ISMS i Krajowych Ram Interoperacyjności (KRI) w urzędzie miasta na prawach powiatu, w którym usługi IT zostały scentralizowane w dedykowanej jednostce budżetowej (Centrum Usług Informatycznych - CUI). Zadanie stawia przed studentami wymóg przeprowadzenia audytu relacji pomiędzy jednostką centralną a 40 jednostkami podległymi (szkoły, domy pomocy społecznej, zarząd dróg), zaplanowania samplingu statystycznego kont i uprawnień w domenie Active Directory, sklasyfikowania niezgodności według par. 20 KRI i ISO 27001 oraz opracowania Planu CAP z analizą przyczyn źródłowych.

• U1 Opracowanie zintegrowanego planu audytu ISMS/KRI dla scentralizowanej architektury samorządowej.
• U2 Profesjonalne formułowanie i kwalifikacja niezgodności NC1/NC2/OFI na styku urząd-jednostki podległe.
• U3 Zastosowanie podejścia opartego na ryzyku (risk-based audit) do alokacji zasobów kontrolnych w 40 rozproszonych jednostkach.
• U4 Opracowanie Planu Działań Korygujących (CAP) dla ładu informatycznego w samorządzie.
• W1W3 Biegła znajomość Rozporządzenia w sprawie KRI (Dz.U. z 2024 r. poz. 773), ustawy o informatyzacji, RODO oraz ustawy o samorządzie gminnym i powiatowym.
• W2 Wymagania normy ISO/IEC 27001:2022 oraz wytyczne audytowe ISO 19011:2018.
• K1K2K3 Profesjonalizm audytorski, zrozumienie zasad służby publicznej i transparentności procedur.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole ISO 27001), Wyk4 (Audyt zgodności z KRI i RODO), Wyk5 (ISO 27005), Wyk7 (Niezgodności i CAP).

Miasto na prawach powiatu "Wielkopole" liczy 190 000 mieszkańców. Dwa lata temu uchwałą Rady Miasta utworzono Miejskie Centrum Usług Informatycznych (MCUI), które przejęło zarządzanie całą infrastrukturą IT Urzędu Miasta oraz 40 jednostek organizacyjnych gminy (25 szkół, 4 domy pomocy społecznej, Zarząd Dróg i Transportu Miejskiego, Miejski Ośrodek Pomocy Rodzinie, Zarząd Budynków Komunalnych).

Struktura techniczno-operacyjna:

• MCUI zarządza centralną serwerownią miejską, siecią miejską MAN opartą na 120 km światłowodów, centralną domeną Active Directory oraz wspólną platformą Elektronicznego Zarządzania Dokumentacją (EZD PUW).
• W urzędzie i jednostkach funkcjonuje łącznie ponad 1 800 stacji roboczych oraz kilkadziesiąt baz danych (rejestr mieszkańców PESEL, system podatków lokalnych, ewidencja nieruchomości, system pomocy społecznej POMOST, systemy kadrowo-płacowe).

Sygnały ostrzegawcze i złożone problemy zidentyfikowane przed audytem:

• Brak formalnych umów powierzenia przetwarzania danych (art. 28 RODO) lub porozumień o współadministrowaniu pomiędzy MCUI a częścią podległych jednostek (np. szkołami i domami pomocy społecznej).
• W domenie Active Directory wykryto ponad 350 kont pracowników, którzy zakończyli pracę w magistracie lub szkołach w ciągu ostatnich 3 lat; konta te nadal mają aktywne uprawnienia do sieci miejskiej.
• Dyrektorzy szkół i MOPS skarżą się, że informatycy MCUI mają nieograniczony dostęp administracyjny do baz zawierających wywiady środowiskowe i dane wrażliwe podopiecznych pomocy społecznej bez imiennych upoważnień.
• Zgodnie z par. 20 KRI Prezydent Miasta zarządził coroczny audyt bezpieczeństwa informacji. Zespół audytorów ma 4 dni na zbadanie zarówno centrali MCUI, jak i reprezentatywnej próby jednostek podległych.

Zespół audytorów (2-3 studentów) projektuje kompleksowy plan audytu:

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

Student 1 (Audytor Wiodący / Koordynator Samorządowy): Formułuje ramy prawne audytu, procedurę komunikacji z Prezydentem Miasta, Dyrektorem MCUI i kierownikami jednostek, opracowuje harmonogram i prowadzi spotkania otwierające/zamykające.

Student 2 (Audytor Infrastruktury Centralnej i Domeny): Planuje techniczny audyt serwerowni miejskiej, centralnej domeny Active Directory, zarządzania uprawnieniami uprzywilejowanymi (PAM), kopii zapasowych i bezpieczeństwa sieci MAN.

Student 3 (Audytor Zgodności KRI, RODO i Planu CAP): Opracowuje matrycę ryzyka 3x3 dla procesu centralizacji, checklistę 20 wymogów par. 20 KRI, procedurę samplingu statystycznego jednostek i kont oraz projektuje tabelę CAP z analizą Root Cause.

• Krok 2 (Dobór próby jednostek i kont - sampling):

Zastosujcie dwustopniowy dobór próby:

• Krok A (Sampling jednostek): Z 40 jednostek podległych wybierzcie do bezpośredniej inspekcji 4 podmioty reprezentujące różne profile ryzyka: Urząd Miasta (Wydział Finansowy i Spraw Obywatelskich), Miejski Ośrodek Pomocy Rodzinie (wysokie ryzyko danych wrażliwych), 1 duży Zespół Szkół Technicznych, Zarząd Dróg i Transportu Miejskiego.
• Krok B (Sampling statystyczny kont): Z puli 1 800 kont w domenie zaplanujcie losowe pobranie próby 100 kont do weryfikacji ich statusu z rejestrem kadrowym (kontrola kont sierocych/nieaktywnych).

Kryteria: Rozporządzenie Rady Ministrów w sprawie KRI (Dz.U. z 2024 r. poz. 773, w szczególności par. 20 ust. 2), Norma PN-EN ISO/IEC 27001:2022 (kontrole: A.5.15 Prawa dostępu, A.5.18 Prawa dostępu do sieci, A.6.5 Zakończenie zatrudnienia, A.8.2 Uprzywilejowane prawa dostępu), art. 28, 32 RODO.

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):

Oceńcie ryzyka inherentne i rezydualne dla:

• Ryzyko 1: Dostęp do danych wrażliwych MOPS przez nieuprawnionych informatyków MCUI.
• Ryzyko 2: Przejęcie tożsamości byłego urzędnika poprzez nieusunięte konto w Active Directory (ponad 350 kont sierocych).
• Ryzyko 3: Paraliż usług miejskich wskutek awarii węzła sieci światłowodowej MAN bez łączy redundantnych.

Sklasyfikujcie uchybienia:

• NC1 (Niezgodność Duża): Setki aktywnych kont byłych pracowników w domenie Active Directory stwarzające ryzyko nieautoryzowanego dostępu do rejestrów państwowych (naruszenie ISO 27001 A.6.5, A.5.18 oraz par. 20 ust. 2 pkt 5 KRI).
• NC2 (Niezgodność Mała): Brak formalnych umów powierzenia przetwarzania danych między MCUI a 15 szkołami (naruszenie art. 28 RODO).
• OFI (Szansa na poprawę): Brak zautomatyzowanego narzędzia klasy Identity Governance and Administration (IGA) integrującego system kadrowy z domeną AD.

Zaprojektujcie tabelę CAP zawierającą analizę przyczyn źródłowych (Root Cause) w oparciu o metodę 5 Why oraz harmonogram działań naprawczych (od 7 do 90 dni).

• Krok 7 (Harmonogram 4-dniowego audytu):

Dzień 1: Spotkanie otwierające, audyt centrali MCUI i serwerowni miejskiej. Dzień 2: Audyt domeny Active Directory i systemu EZD, sampling kont. Dzień 3: Wyjazdy audytowe do MOPR, Urzędu Miasta i szkoły. Dzień 4: Triangulacja ustaleń, narada zespołu, spotkanie zamykające z Prezydentem Miasta i Dyrektorem MCUI.

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Koncepcja centralizacji IT w samorządzie (CUI) a rygory prawne KRI i KSC (Student 1).
• Metodyka samplingu i szacowanie ryzyka 3x3 (4 min): Prezentacja doboru próby kont i jednostek oraz hierarchizacji ryzyk w sieci miejskiej (Student 3).
• Przebieg audytu technicznego domeny i węzłów sieciowych (4 min): Przedstawienie wyników badania kont sierocych, praw uprzywilejowanych i backupów (Student 2).
• Kwalifikacja ustaleń (NC1/NC2/OFI) oraz Plan Działań Korygujących CAP (3 min): Analiza 5 Why i plan naprawczy dla Prezydenta Miasta (Student 3 i 1).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania dotyczące odpowiedzialności prawnej kierowników jednostek i CUI (cały zespół).

Raport składany na zaliczenie (8-12 stron A4) musi zawierać:

A. Kontekst organizacyjny i model centralizacji usług teleinformatycznych w mieście.

B. Wzorcowy Zintegrowany Plan Audytu ISMS/KRI:

• Zleceniodawca: Prezydent Miasta Wielkopole.
• Cel audytu: Ocena zgodności funkcjonowania Miejskiego Centrum Usług Informatycznych oraz jednostek podległych z wymogami par. 20 Rozporządzenia w sprawie KRI i normą ISO/IEC 27001:2022.
• Zakres audytu: Centrala MCUI, serwerownia miejska, sieć światłowodowa MAN, system EZD PUW, bazy podatkowe, domena Active Directory, próba 4 jednostek (Urząd Miasta, MOPR, Zespół Szkół Technicznych, ZDiTM).
• Matryca szacowania ryzyka (3x3):
  • Aktyw 1: Konta w domenie Active Directory. Zagrożenie: Logowanie na konta byłych pracowników i kradzież tożsamości. P=3 (Wysokie), S=3 (Krytyczne - nieuprawniony dostęp do PESEL). Ryzyko inherentne: 9/9. Kontrola: Automatyczna synchronizacja HR-AD, blokada po 30 dniach nieaktywności. Ryzyko rezydualne: 2/9 (Akceptowalne).
  • Aktyw 2: Bazy danych MOPR (dane wrażliwe podopiecznych). Zagrożenie: Wgląd administratorów MCUI bez upoważnienia. P=2, S=3. Ryzyko inherentne: 6/9. Kontrola: Wdrożenie systemu rejestracji sesji uprzywilejowanych PAM i imiennych upoważnień RODO. Ryzyko rezydualne: 2/9.
  • Aktyw 3: Sieć miejska MAN. Zagrożenie: Przerwanie kabla światłowodowego i odcięcie urzędu od e-usług. P=2, S=2. Ryzyko inherentne: 4/9. Kontrola: Zaprojektowanie pierścienia światłowodowego z automatyczną rekonfiguracją łączy. Ryzyko rezydualne: 1/9.
• Rejestr Ustalonych Niezgodności:
  • NC1 (Niezgodność Duża): Obecność 350 nieaktywnych kont byłych pracowników w centralnej domenie AD. Podstawa: ISO 27001 A.6.5, A.5.18; par. 20 ust. 2 pkt 5 KRI. Dowód: Wykaz użytkowników wygenerowany z AD skorelowany z ewidencją zwolnień Działu Kadr.
  • NC2 (Niezgodność Mała): Brak formalnych umów powierzenia przetwarzania danych między MCUI a 15 jednostkami oświatowymi. Podstawa: art. 28 RODO. Dowód: Przegląd rejestru umów w Dziale Prawnym MCUI.
  • OFI (Szansa na poprawę): Brak procedury cyklicznego przeglądu uprawnień administracyjnych (recertyfikacja kont co 6 miesięcy). Podstawa: ISO 27001 A.5.18.
• Plan Działań Korygujących (CAP) z analizą przyczyn źródłowych (Root Cause):
  • Dla Ustalenia NC1 (Konta sieroce w AD):
    • Analiza 5 Why: Dlaczego konta były aktywne? -> Bo administratorzy nie dostali informacji o odejściu pracowników. Dlaczego nie dostali? -> Bo kadry jednostek wysyłały maile nieregularnie na ogólny adres helpdesk. Dlaczego nieregularnie? -> Brak sformalizowanego i wymuszonego obiegu karty obiegowej. Dlaczego brak? -> Brak procedury łączącej system kadrowy z systemem zarządzania tożsamością. Przyczyna źródłowa (Root Cause): Brak zintegrowanej procedury Offboardingu i automatycznej integracji bazy kadrowej z domeną Active Directory.
    • Działanie naprawcze: Natychmiastowe zablokowanie zidentyfikowanych 350 kont; wdrożenie skryptu wyłączającego konta nieużywane przez 30 dni; opracowanie Zarządzenia Prezydenta o obowiązkowej elektronicznej karcie obiegowej w systemie EZD.
    • Właściciel: Dyrektor MCUI i Kierownik Wydziału Organizacyjnego UM.
    • Termin: 7 dni na blokadę kont; 30 dni na procedurę i zarządzenie.
• Tabela harmonogramu audytu (4 dni):
  • Dzień 1: Spotkanie otwierające z Prezydentem Miasta, audyt polityk SZBI i KRI w MCUI, inspekcja serwerowni centralnej.
  • Dzień 2: Audyt domeny Active Directory, analiza procedur tworzenia kopii zapasowych, pobranie i badanie próby 100 kont.
  • Dzień 3: Inspekcja terenowa: MOPR (dane wrażliwe), Zespół Szkół (sieć szkolna a sieć miejska), Wydział Finansowy UM (bazy podatkowe).
  • Dzień 4: Triangulacja dowodów, przygotowanie kart niezgodności, formalne spotkanie zamykające z Prezydentem i kadrą kierowniczą.

C. Analiza zalet i ograniczeń planu:

• Zalety: Kompleksowe uporządkowanie ładu informatycznego w skali całego miasta; usunięcie krytycznych luk w zarządzaniu tożsamością; pełna zgodność z KRI.
• Ograniczenia: Konieczność koordynacji działań z 40 niezależnymi dyrektorami jednostek; czasochłonność wdrożenia automatyzacji HR-AD.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (...) (Dz.U. z 2024 r. poz. 773) - par. 20.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania.
• Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. z 2024 r. poz. 307).
• Ministerstwo Cyfryzacji: "Rekomendacje dotyczące organizacji i bezpieczeństwa samorządowych centrów usług wspólnych IT", Warszawa 2022.

• U1 Student umie zaplanować audyt zintegrowany ISMS i KRI dla rozproszonej struktury samorządowej.
• U2 Student precyzyjnie klasyfikuje uchybienia na NC1, NC2 i OFI zgodnie z ISO 27001 i KRI.
• U3 Student stosuje zaawansowany sampling statystyczny i szacowanie ryzyka w matrycy 3x3.
• U4 Student buduje plan CAP oparty na analizie 5 Why dla administracji publicznej.
• W2W3 Student rozumie specyfikę przepisów samorządowych i prawa teleinformatycznego.
• K1K2 Student wykazuje postawę etyczną i umiejętność pracy w środowisku instytucji publicznych.

Celem zadania na ocenę 4.0 jest opanowanie umiejętności zaprojektowania zaawansowanego planu audytu ISMS opartego na ryzyku (risk-based audit) w dużej instytucji sektora finansowego podlegającej rygorom Rozporządzenia Parlamentu Europejskiego i Rady w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA), Rekomendacji D Komisji Nadzoru Finansowego (KNF) oraz standardu PCI DSS v4.0. Zadanie kładzie szczególny nacisk na audyt odporności kanałów cyfrowych (bankowość mobilna, API dla FinTechów), weryfikację testów penetracyjnych prowadzonych z użyciem wektorów zagrożeń (TLPT), matrycową analizę ryzyka 3x3, gradację uchybień (NC1/NC2/OFI) oraz plan CAP.

• U1 Opracowanie zaawansowanego planu audytu ISMS dla banku komercyjnego spełniającego wymogi DORA i KNF.
• U2 Identyfikacja i klasyfikacja niezgodności w architekturze krytycznych systemów transakcyjnych.
• U3 Praktyczne zastosowanie metodyki risk-based audit (ISO 27005) do hierarchizacji celów audytu.
• U4 Konstrukcja Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych (Root Cause).
• W2W3 Biegła znajomość ISO/IEC 27001:2022, ISO/IEC 27005:2022, Rozporządzenia DORA, Rekomendacji D KNF i standardu PCI DSS v4.0.
• W1 Ochrona tajemnicy bankowej (art. 104 Prawa bankowego) i danych kartowych.
• K1K3 Niezależność, obiektywizm i bezwzględne zachowanie poufności informacji o architekturze bankowej.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole ISO 27001), Wyk4 (DORA i KNF), Wyk5 (Risk-based audit), Wyk7 (Niezgodności i CAP).

Bank "Silesia Commerce S.A." obsługuje 1,4 miliona klientów detalicznych i 80 000 klientów korporacyjnych. Bank prowadzi 95 oddziałów własnych oraz zaawansowaną platformę bankowości elektronicznej i mobilnej (ponad 900 000 aktywnych użytkowników aplikacji na iOS i Android). Bank zatrudnia 2 200 pracowników (w tym 250 specjalistów w pionie IT i Bezpieczeństwa).

Architektura i otoczenie technologiczne:

• Środowisko hybrydowe: Centralny system bankowy (Core Banking) działa na klastrze serwerów mainframe i bazach IBM DB2 w dwóch własnych centrach danych (Active-Active) w Warszawie i Katowicach. Systemy bankowości mobilnej i mikroserwisy frontendowe osadzone są w chmurze prywatnej oraz AWS.
• Otwarta bankowość (Open Banking): Bank udostępnia interfejsy API zgodne ze standardem PolishAPI dla ponad 40 zewnętrznych podmiotów trzecich (TPP / FinTech).

Incydenty i złożone wyzwania ujawnione przed audytem:

• W ciągu ostatnich 6 miesięcy odnotowano zmasowane ataki socjotechniczne (vishing i spoofing numerów infolinii banku), które doprowadziły do wyłudzenia poświadczeń i środków z kont kilkudziesięciu klientów.
• Weryfikacja procedur wykazała, że testy odpornościowe oparte na zaawansowanym profilowaniu zagrożeń (Threat-Led Penetration Testing - TLPT) wymagane przez art. 26 DORA nie były przeprowadzane w środowisku produkcyjnym z obawy przed zakłóceniem działania systemów transakcyjnych.
• Zewnętrzny dostawca usług analityki chmurowej posiadał wgląd w niespseudonimizowane numery rachunków IBAN i kwoty transakcji.
• Komitet Audytu Rady Nadzorczej zażądał przedstawienia rocznego planu audytu ISMS opartego na ryzyku, uwzględniającego pełną zgodność z DORA i normą ISO/IEC 27001.

Zespół audytorów (2-3 studentów) opracowuje plan audytu risk-based:

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

Student 1 (Audytor Wiodący / Ekspert Nadzoru Bankowego): Koordynuje audyt, współpracuje z Zarządem, CISO i Compliance, przygotowuje protokoły spotkań otwierających/zamykających, zarządza harmonogramem i procedurą eskalacji ryzyk.

Student 2 (Audytor Architektury IT, Chmury i Cyberbezpieczeństwa): Planuje techniczny audyt systemów chmurowych AWS, interfejsów API, modułów kryptograficznych HSM, procedur zarządzania kluczami oraz weryfikacji architektury odpornościowej DRP/BCP.

Student 3 (Audytor Regulacji DORA, KNF i Planu CAP): Opracowuje matrycę ryzyka 3x3, bada zgodność z wymogami DORA (zarządzanie ryzykiem ICT, testowanie, zarządzanie incydentami, ryzyko stron trzecich), klasyfikuje niezgodności NC1/NC2/OFI i projektuje plan CAP.

• Krok 2 (Wyznaczenie zakresu i podejście risk-based):

Zakres: System Core Banking, bankowość mobilna, platforma Open Banking API, moduły HSM, centrum SOC, dostawcy chmurowi ICT.

Alokacja zasobów w oparciu o ryzyko: 45% czasu na kanały cyfrowe, API i chmurę; 30% na odporność operacyjną (DORA i testy TLPT); 15% na bezpieczeństwo dostawców ICT; 10% na procesy ogólne i audyt oddziałów.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Rozporządzenie DORA (UE 2022/2554, art. 5-16, art. 26-27), Norma PN-EN ISO/IEC 27001:2022 (wymagania klauzul 6 i 8 oraz Załącznik A: A.5.19-A.5.23, A.8.24, A.8.26), Rekomendacja D KNF, standard PCI DSS v4.0, Ustawa - Prawo bankowe.

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):

Przeprowadźcie ocenę ryzyka dla 3 procesów bankowych:

• Ryzyko 1: Podatność w interfejsie PolishAPI umożliwiająca kradzież środków z rachunków klientów. P=2, S=3 (Krytyczny). Ryzyko inherentne: 6/9 (Wysokie). Kontrola: Wdrożenie testów TLPT i dynamicznej analizy behawioralnej API. Ryzyko rezydualne: 2/9.
• Ryzyko 2: Brak spełnienia wymogów art. 26 DORA (brak regularnych zaawansowanych testów penetracyjnych TLPT). P=3, S=3. Ryzyko inherentne: 9/9. Kontrola: Zakontraktowanie certyfikowanego zespołu Red Team. Ryzyko rezydualne: 1/9.
• Ryzyko 3: Wyciek danych finansowych u zewnętrznego dostawcy chmury analitycznej. P=2, S=3. Ryzyko inherentne: 6/9. Kontrola: Wymóg tokenizacji i pseudonimizacji przed wysyłką do chmury. Ryzyko rezydualne: 2/9.

Zaprojektujcie tabelę CAP z analizą przyczyn źródłowych, działaniem naprawczym, wyznaczeniem właściciela (Dyrektor Bezpieczeństwa IT) i horyzontem czasowym (30-90 dni).

• Krok 7 (Harmonogram wielostrumieniowy audytu - 4 dni robocze):

Szczegółowy plan z podziałem na audyt techniczny, audyt zgodności regulacyjnej i audyt dostawców zewnętrznych.

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Ramy prawne Rozporządzenia DORA i Rekomendacji D KNF w sektorze bankowym (Student 1).
• Metodyka risk-based audit i matryca ryzyka 3x3 (4 min): Hierarchizacja obszarów audytowych i uzasadnienie alokacji zasobów (Student 3).
• Przebieg badań technicznych: API, HSM, chmura hybrydowa i testy TLPT (4 min): Prezentacja ustaleń technicznych (Student 2).
• Rejestr niezgodności i Plan Działań Korygujących CAP (3 min): Analiza przyczyn źródłowych (Root Cause) i zalecenia dla Komitetu Audytu (Student 3 i 1).
• Podsumowanie i dyskusja (2 min): Obrona planu audytu przed komisją (cały zespół).

Raport seminaryjny (8-12 stron maszynopisu) musi zawierać:

A. Charakterystyka uwarunkowań biznesowych i regulacyjnych banku komercyjnego.

B. Wzorcowy Plan Audytu ISMS w Banku Silesia Commerce S.A.:

• Metryka: Zleceniodawca (Komitet Audytu Rady Nadzorczej), Czas: 4 dni robocze, 3 audytorów.
• Cel: Ocena spełnienia wymagań normy ISO/IEC 27001:2022 oraz przepisów Rozporządzenia DORA w zakresie cyfrowej odporności operacyjnej i zarządzania ryzykiem ICT.
• Zakres: Środowisko Core Banking, platforma bankowości mobilnej, PolishAPI, chmura AWS, moduły HSM, procedury ciągłości działania (BCP/DRP), dostawcy kluczowi ICT.
• Matryca szacowania ryzyka (3x3):
  • Ustalenie priorytetów wg wag ryzyka: Kanały cyfrowe i API (Waga: 45%), Odporność operacyjna i testy DORA (Waga: 30%), Zarządzanie dostawcami ICT (Waga: 15%), Ład korporacyjny ISMS (Waga: 10%).
• Rejestr Niezgodności:
  • NC1 (Niezgodność Duża): Brak przeprowadzania testów TLPT na środowiskach wspierających krytyczne funkcje banku. Podstawa: DORA art. 26-27; ISO 27001 A.8.29.
  • NC2 (Niezgodność Mała): Brak pseudonimizacji danych transakcyjnych wysyłanych do chmury analitycznej. Podstawa: ISO 27001 A.8.11; Rekomendacja D KNF.
  • OFI (Szansa na poprawę): Brak wdrożenia mechanizmów uwierzytelniania biometrycznego FIDO2 dla personelu operacji skarbowych.
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Brak testów TLPT):
    • Analiza 5 Why: Dlaczego nie przeprowadzono TLPT? -> Pion IT obawiał się zakłócenia systemów transakcyjnych. Dlaczego się obawiał? -> Brak procedur bezpiecznego testowania w oparciu o ramy TIBER-EU/TIBER-PL. Dlaczego brak procedur? -> Dział Bezpieczeństwa nie posiadał budżetu i wytycznych zarządczych dla DORA. Przyczyna źródłowa (Root Cause): Brak strategicznego programu wdrożenia wymogów odporności operacyjnej DORA na szczeblu Zarządu Banku.
    • Działanie naprawcze: Opracowanie i zatwierdzenie przez Zarząd ram testów TLPT zgodnych z TIBER-PL; rozpisanie przetargu na certyfikowany zespół Red Team / Threat Intelligence; wyznaczenie okien testowych.
    • Właściciel: Dyrektor Pionu Bezpieczeństwa i Ryzyka Operacyjnego.
    • Termin: 60 dni na ramy i przetarg; 120 dni na realizację testów.
• Harmonogram wielostrumieniowy audytu (4 dni):
  • Dzień 1: Spotkanie otwierające z Zarządem i CISO, audyt ram zarządzania ryzykiem ICT wg DORA i ISO 27001, przegląd polityk bezpieczeństwa.
  • Dzień 2 (równolegle): Strumień A (Audytor 2) - audyt techniczny infrastruktury PolishAPI, zarządzania kluczami w HSM, konfiguracji chmury AWS; Strumień B (Audytor 3) - audyt procedur klasyfikacji i zgłaszania incydentów do CSIRT KNF.
  • Dzień 3 (równolegle): Strumień A (Audytor 2) - weryfikacja planów DRP, testów przełączania centrów danych Warszawa-Katowice; Strumień B (Audytor 3) - audyt umów z dostawcami zewnętrznymi ICT (art. 28-30 DORA).
  • Dzień 4: Triangulacja dowodów, spotkanie robocze z audytorami wewnętrznymi banku, formalne spotkanie zamykające z Komitetem Audytu.

C. Analiza wad i zalet rozwiązania:

• Zalety: Bezpośrednie przygotowanie banku do kontroli KNF i EBA z zakresu DORA; usunięcie ryzyk kar regulacyjnych (do 1% dziennego obrotu); uodpornienie kanałów mobilnych na nowoczesne cyberataki.
• Ograniczenia: Wysoki koszt zakupu usług testów TLPT i narzędzi monitoringu API; złożoność koordynacji audytu z zewnętrznymi dostawcami chmurowymi (AWS).

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (Rozporządzenie DORA) w sprawie operacyjnej odporności cyfrowej sektora finansowego.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO/IEC 27005:2022 - Zarządzanie ryzykiem w bezpieczeństwie informacji.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania.
• Urząd Komisji Nadzoru Finansowego (UKNF): "Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach", Warszawa.
• PCI Security Standards Council: "Payment Card Industry Data Security Standard v4.0", 2022.
• Narodowy Bank Polski / Europejski Bank Centralny: "Ramy testowania odporności na cyberataki TIBER-PL", Warszawa.

• U1 Student umie skonstruować zaawansowany plan audytu banku komercyjnego uwzględniający standardy DORA i KNF.
• U2 Student bezbłędnie klasyfikuje uchybienia regulacyjne sektora finansowego (NC1/NC2/OFI).
• U3 Student wdraża zasady risk-based audit w oparciu o normę ISO 27005.
• U4 Student przygotowuje profesjonalny plan CAP z analizą przyczyn źródłowych metodą 5 Why.
• W2W3 Student dogłębnie zna regulacje unijne DORA oraz polskie wytyczne bankowe KNF.
• K1K3 Student zachowuje najwyższe rygory poufności i niezależności zawodowej.

Celem zadania na ocenę 4.0 jest nauczenie studentów projektowania wielopoziomowego, bezpiecznego planu audytu ISMS w przedsiębiorstwie energetycznym będącym Operatorem Systemu Dystrybucyjnego (OSD) oraz operatorem infrastruktury krytycznej państwa. Kluczowym wyzwaniem jest metodyczne rozgraniczenie stref sieci korporacyjnej (IT) od strefy dyspozytorskiej automatyki elektroenergetycznej (OT/SCADA/EMS) w oparciu o model referencyjny Purdue i standard IEC 62443. Zadanie wymaga przeprowadzenia szacowania ryzyka w matrycy 3x3, zdefiniowania bezwzględnych zakazów inwazyjnego skanowania sieci wysokiego napięcia, sklasyfikowania niezgodności (NC1/NC2/OFI) oraz opracowania Planu Działań Korygujących (CAP).

• U1 Opracowanie zaawansowanego planu audytu ISMS dla infrastruktury krytycznej elektroenergetyki.
• U2 Poprawne kwalifikowanie niezgodności dla protokołów przemysłowych (IEC 60870-5-104, DNP3, Modbus TCP).
• U3 Przeprowadzenie analizy ryzyka sabotażu teleinformatycznego i blackoutu aglomeracji.
• U4 Konstrukcja Planu Działań Korygujących (CAP) uwzględniającego specyfikę ciągłości zasilania.
• W1W3 Znajomość ustawy o KSC, dyrektywy NIS2, ustawy o zarządzaniu kryzysowym oraz przepisów Prawa energetycznego.
• W2 Standardy bezpieczeństwa ISO/IEC 27001:2022, ISO/IEC 27019 (bezpieczeństwo w energetyce) oraz seria norm PN-EN IEC 62443.
• K1K3 Świadomość odpowiedzialności za bezpieczeństwo narodowe i niezawodność dostaw energii.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole sieciowe ISO 27001), Wyk4 (KSC i NIS2), Wyk5 (ISO 27005), Wyk7 (Niezgodności i CAP).

Spółka "EnergoDystrybucja S.A." dostarcza energię elektryczną do 850 000 odbiorców indywidualnych i przemysłowych na obszarze dwóch województw. Spółka zarządza 110 Głównymi Punktami Zasilania (stacjami GPZ 110/15 kV), tysiącami stacji transformatorowych SN/nn oraz siecią światłowodową i radiową łączącą obiekty z Centralną Dyspozycją Mocy (CDM).

Architektura teleinformatyczna i automatyka stacyjna:

• Środowisko IT (Corporate): System bilingowy CIS, SAP ERP, system GIS majątku sieciowego, poczta, stacje robocze 1 100 pracowników biurowych.
• Środowisko OT (SCADA/EMS): System dyspozytorski SCADA/EMS z redundantnymi serwerami w CDM, sterowniki polowe RTU i zabezpieczenia cyfrowe (IED) na stacjach GPZ, komunikujące się po protokole IEC 60870-5-104 przez wydzieloną sieć APN w telefonii komórkowej oraz radiolinie.

Złożone incydenty i ryzyka stwierdzone w audycie zerowym:

• Naruszenie modelu strefowego Purdue: Rok temu wdrożono bezpośrednie połączenie pomiędzy serwerem bazodanowym SCADA a systemem GIS w sieci biurowej w celu automatycznego nanoszenia awarii na mapę dla klientów. Połączenie zestawiono z pominięciem strefy DMZ (Industrial DMZ), a na firewallu otwarto szeroki zakres portów TCP.
• Brak uwierzytelniania w protokole telemetrycznym: Komunikacja pomiędzy sterownikami RTU na bezzałogowych stacjach GPZ a centralą SCADA realizowana jest protokołem IEC 104 w postaci tekstu jawnego bez szyfrowania TLS i bez uwierzytelniania kryptograficznego (zgodnie z IEC 62351), co stwarza ryzyko ataku Man-in-the-Middle i fałszowania poleceń otwarcia wyłączników mocy.
• Dostęp serwisowy podwykonawców: Zewnętrzna firma modernizująca zabezpieczenia stacyjne posiada stały dostęp VPN ze swoich biur do sterowników na 20 stacjach GPZ, bez uwierzytelniania wieloskładnikowego (MFA) i bez rejestrowania sesji przez system PAM.

Zespół audytorów (2-3 studentów) projektuje zaawansowany plan audytu:

• Krok 1 (Podział ról i metodyka badania OT/IT):

Student 1 (Audytor Wiodący / Ekspert Infrastruktury Krytycznej): Ustala cele, ramy formalne z Zarządem i Głównym Dyspozytorem Mocy, protokoły BHP na stacjach elektroenergetycznych, zarządza harmonogramem i spotkaniami otwierającymi/zamykającymi.

Student 2 (Audytor Systemów SCADA i Bezpieczeństwa Sieci Przemysłowych): Odpowiada za plan weryfikacji separacji stref (IT, IDMZ, OT poziom 3, 2, 1 wg Purdue), analizę reguł firewalli przemysłowych, bezpieczeństwa łączy telemetrycznych APN i protokołu IEC 104.

Student 3 (Audytor Ryzyka, KSC i Planu Działań Korygujących): Opracowuje matrycę szacowania ryzyka 3x3 dla scenariusza blackoutu, checklistę wymagań ustawy o KSC dla OUK, gradację niezgodności NC1/NC2/OFI oraz tabelę CAP z analizą 5 Why.

• Krok 2 (Wyznaczenie zakresu i bezwzględnych zakazów technicznych):

Zakres: Budynek Centralnej Dyspozycji Mocy (CDM), strefa biurowa IT, węzły sieci telemetrii, inspekcja 3 stacji GPZ.

Zakazy operacyjne: Bezwzględny zakaz wstrzykiwania pakietów testowych, skanowania portów narzędziami typu Nmap/Nessus na aktywnych magistralach stacyjnych oraz jakiejkolwiek ingerencji w stan łączników elektroenergetycznych pod rygorem przerwania audytu i odpowiedzialności karnej.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Norma PN-EN ISO/IEC 27001:2022 (A.8.20, A.8.22), norma PN-EN ISO/IEC 27019:2020 (zarządzanie bezpieczeństwem informacji w sektorze energetycznym), seria PN-EN IEC 62443 (bezpieczeństwo systemów automatyki i sterowania), Ustawa o KSC (art. 8-15).

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):
  • Ryzyko 1: Wstrzyknięcie fałszywych telegramów sterujących IEC 104 i wyłączenie zasilania miasta (blackout). P=2, S=3 (Krytyczny). Ryzyko inherentne: 6/9 (Wysokie). Kontrola: Wdrożenie tuneli IPsec z certyfikatami i standardu IEC 62351. Ryzyko rezydualne: 2/9.
  • Ryzyko 2: Przeniknięcie ataku ransomware z sieci biurowej do serwerów SCADA przez bezpośrednie łącze GIS-SCADA. P=3, S=3. Ryzyko inherentne: 9/9 (Niedopuszczalne). Kontrola: Wdrożenie strefy IDMZ i diody danych (ang. data diode) do jednokierunkowej replikacji danych ze SCADA do GIS. Ryzyko rezydualne: 1/9.
  • Ryzyko 3: Przejęcie stacji GPZ przez skompromitowany komputer zewnętrznego serwisanta. P=3, S=3. Ryzyko inherentne: 9/9. Kontrola: Likwidacja stałego VPN, wdrożenie bramy PAM z MFA i sesją na żądanie (Just-In-Time access). Ryzyko rezydualne: 2/9.
• Krok 5 (Kwalifikacja niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Bezpośrednie połączenie sieci korporacyjnej IT z serwerami SCADA z pominięciem strefy IDMZ (naruszenie ISO 27001 A.8.22, IEC 62443-3-2 oraz art. 8 ustawy o KSC).
  • NC2 (Niezgodność Mała): Brak uwierzytelniania wieloskładnikowego (MFA) dla zewnętrznych serwisantów stacyjnych łączących się przez VPN (naruszenie ISO 27001 A.8.5).
  • OFI (Szansa na poprawę): Brak wdrożenia systemu Network Detection and Response (NDR) wyspecjalizowanego w analizie anomalii w protokołach IEC 104 i DNP3.
• Krok 6 (Plan CAP z analizą przyczyn źródłowych):

Tabela CAP z analizą Root Cause metodą 5 Why dla połączenia GIS-SCADA oraz wyznaczenie terminów i właścicieli.

• Krok 7 (Harmonogram wielostrumieniowy - 4 dni audytu):

Rozpisanie inspekcji CDM, węzłów APN, 3 stacji transformatorowych i serwerowni IT.

Struktura 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie i ramy Operatora Usługi Kluczowej (2 min): Rola OSD w bezpieczeństwie energetycznym kraju i rygory KSC (Student 1).
• Model Purdue, separacja stref i matryca ryzyka 3x3 (4 min): Prezentacja szacowania ryzyka blackoutu i koncepcji diody danych (Student 2).
• Przebieg audytu telemetrycznego i inspekcji stacji GPZ (4 min): Przedstawienie metod bezinwazyjnej weryfikacji protokołów stacyjnych (Student 2 i 3).
• Rejestr niezgodności i Plan Działań Korygujących CAP (3 min): Analiza 5 Why i plan budowy przemysłowej strefy IDMZ (Student 3).
• Podsumowanie i obrona koncepcji (2 min): Dyskusja na temat radzenia sobie z oporem inżynierów elektroenergetyki wobec zmian w telemetrii (cały zespół).

Raport składany na zaliczenie (8-12 stron znormalizowanego maszynopisu) musi obejmować:

A. Uwarunkowania techniczne i prawne Operatora Usługi Kluczowej w elektroenergetyce.

B. Wzorcowy Plan Audytu ISMS / KSC w EnergoDystrybucja S.A.:

• Metryka: Zleceniodawca (Zarząd EnergoDystrybucja S.A.), Podstawa prawna (art. 15 ustawy o KSC), Zespół audytorów (3 osoby).
• Cel: Weryfikacja zgodności zabezpieczeń technicznych i organizacyjnych z normami ISO/IEC 27001:2022, ISO/IEC 27019 oraz wymaganiami ustawy o KSC.
• Zakres audytu: Centralna Dyspozycja Mocy (CDM), środowisko teleinformatyczne IT, sieć telemetrii radiowo-komórkowej APN, stacje GPZ "Północ", "Południe" i "Centrum".
• Bezwzględne obostrzenia: Zakaz generowania sztucznego ruchu sieciowego w magistralach sterowniczych; obecność dyżurnego inżyniera ruchu przy każdej czynności audytowej.
• Matryca szacowania ryzyka (3x3):
  • Zestawienie 3 kluczowych ryzyk (przeniknięcie ransomware ze strefy IT do SCADA, sfałszowanie telemetrii IEC 104, nieautoryzowany dostęp serwisanta).
• Rejestr Niezgodności:
  • NC1 (Niezgodność Duża): Połączenie magistrali SCADA z systemem GIS z pominięciem strefy Industrial DMZ. Podstawa: ISO 27001 A.8.22; IEC 62443-3-2; art. 8 ustawy o KSC.
  • NC2 (Niezgodność Mała): Stałe tunele VPN dla serwisu zewnętrznego bez MFA. Podstawa: ISO 27001 A.8.5, A.5.19.
  • OFI (Szansa na poprawę): Brak wdrożenia sprzętowej diody danych dla eksportu danych ze SCADA do systemów analitycznych.
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Połączenie GIS-SCADA):
    • Analiza 5 Why: Dlaczego serwery połączono bezpośrednio? -> Aby dane o wyłączeniach trafiały natychmiast na stronę WWW dla odbiorców. Dlaczego pominięto IDMZ? -> Bo wdrożenie zrealizowano jako projekt pilotażowy z krótkim terminem. Dlaczego nie audytowano projektu? -> Brak procedury kontroli zmian (Change Management) obejmującej styk IT/OT. Przyczyna źródłowa (Root Cause): Brak zintegrowanego ładu zarządczego IT/OT i brak formalnej bramki bezpieczeństwa (Security Gate) w projektach teleinformatycznych.
    • Działanie naprawcze: Natychmiastowe zablokowanie bezpośrednich reguł firewall; zaprojektowanie i wdrożenie strefy IDMZ z serwerem pośredniczącym (proxy/replikator); zakup sprzętowej diody danych; aktualizacja procedury zarządzania zmianą.
    • Właściciel: Dyrektor Pionu IT we współpracy z Głównym Dyspozytorem Mocy.
    • Termin: 14 dni na reguły tymczasowe; 60 dni na IDMZ i diodę danych.
• Harmonogram wielostrumieniowy audytu (4 dni robocze):
  • Dzień 1: Spotkanie otwierające z Zarządem i Głównym Inżynierem Ruchu, audyt procedur bezpieczeństwa KSC, audyt serwerowni IT i węzłów telekomunikacyjnych.
  • Dzień 2 (równolegle): Strumień A (Audytor 2) - pasywna analiza architektury SCADA w CDM, weryfikacja konfiguracji firewalli strefowych; Strumień B (Audytor 3) - audyt umów z podwykonawcami automatyki stacyjnej i procedur reagowania na incydenty krytyczne.
  • Dzień 3: Wyjazdowe inspekcje terenowe na stacjach GPZ 110/15 kV (weryfikacja szaf telemetrii, łączności APN, ochrony obwodowej stacji, zasilania awaryjnego akumulatorowni).
  • Dzień 4: Triangulacja dowodów, kwalifikacja ustaleń, narada zespołu, oficjalne spotkanie zamykające z Zarządem i przekazanie zaleceń.

C. Analiza zalet i wad planu:

• Zalety: Wykluczenie ryzyka zakłóceń w dostawie prądu; precyzyjna implementacja standardów energetycznych IEC 62443 i ISO 27019; eliminacja wektorów ataków państwowych (Advanced Persistent Threat).
• Trudności i wady: Wysokie koszty zakupu diod danych i modernizacji sterowników polowych; konieczność długich uzgodnień okien serwisowych dla rekonfiguracji sieci stacyjnych.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor energetyki jako podmiot kluczowy.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO/IEC 27019:2020 - Bezpieczeństwo informacji w systemach sterowania procesami w branży energetycznej.
• Norma PN-EN IEC 62443 (seria norm) - Bezpieczeństwo przemysłowych systemów automatyki i sterowania.
• Norma PN-EN IEC 62351 - Zarządzanie systemami zasilania i powiązana wymiana informacji - Bezpieczeństwo danych i komunikacji.
• Pełnomocnik Rządu ds. Strategicznej Infrastruktury Energetycznej: "Wytyczne w zakresie cyberbezpieczeństwa dla OSD i OSP", Warszawa.

• U1 Student projektuje zaawansowany plan audytu ISMS dla infrastruktury krytycznej elektroenergetyki.
• U2 Student poprawnie identyfikuje i klasyfikuje uchybienia w protokołach telemetrii i automatyki stacyjnej.
• U3 Student przeprowadza szacowanie ryzyka sabotażu i blackoutu w ujęciu normy ISO 27005.
• U4 Student opracowuje plan CAP oparty na analizie 5 Why dla środowiska przemysłowego OT.
• W2W3 Student rozumie specyfikę norm IEC 62443, ISO 27019 oraz ustawy o KSC.
• K1K3 Student wykazuje dyscyplinę zawodową, świadomość rygorów BHP i odpowiedzialność za bezpieczeństwo powszechne.

Celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanego warsztatu dowodowego w audycie ISMS dużej platformy handlu elektronicznego i logistyki działającej w modelu wielochmurowym (Multi-Cloud: AWS i Google Cloud Platform). Zadanie kładzie nacisk na zaplanowanie reprezentatywnego samplingu statystycznego dla milionów operacji, triangulacji dowodów z systemów klasy SIEM/SOC, weryfikacji zgodności z najnowszym standardem bezpieczeństwa kart płatniczych PCI DSS v4.0, formalnej analizy ryzyka 3x3, gradacji niezgodności (NC1/NC2/OFI) oraz opracowania Planu CAP z analizą przyczyn źródłowych.

• U1 Opracowanie zaawansowanego planu audytu ISMS dla platformy wielochmurowej obsługującej miliony transakcji.
• U2 Klasyfikacja niezgodności w oparciu o normę ISO 27001, standard PCI DSS v4.0 oraz przepisy RODO.
• U3 Przeprowadzenie analizy ryzyka wycieku danych konsumentów i przestoju w okresie wyprzedażowym.
• U4 Opracowanie Planu Działań Korygujących (CAP) eliminującego podatności w mikroserwisach.
• W2 Biegła znajomość ISO/IEC 27001:2022, wytycznych ISO 19011 dotyczących próbkowania statystycznego oraz PCI DSS v4.0.
• W1W3 Znajomość przepisów RODO (profilowanie, zgody, transfer transgraniczny) i prawa komunikacji elektronicznej.
• K1K2 Obiektywizm, precyzja dowodowa i umiejętność konstruktywnego wywierania wpływu na inżynierów chmury.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole ISO 27001), Wyk6 (Zaawansowane techniki dowodowe, SIEM, sampling), Wyk7 (Niezgodności i CAP).

Grupa "EuroMarket Global Sp. z o.o." prowadzi zintegrowaną platformę e-commerce obsługującą rynki w Polsce, Czechach, Słowacji, Niemczech i Rumunii. Miesięcznie platforma rejestruje ponad 2,5 miliona zamówień o wolumenie przekraczającym 300 mln PLN. Spółka zarządza własną siecią 8 centrów dystrybucyjnych oraz flotą 1 200 paczkomatów.

Architektura teleinformatyczna i stos technologiczny:

• Architektura oparta na mikroserwisach w klastrach Kubernetes rozproszonych w chmurze AWS (silnik zamówień, baza danych klientów) oraz Google Cloud Platform (analityka behawioralna, silnik rekomendacji AI, logistyka magazynowa).
• Płatności realizowane są przez bezpośrednie integracje z 12 procesorami kartowymi i bankami (wymóg pełnej zgodności z PCI DSS v4.0 na poziomie Service Provider Level 1).
• Ruch sieciowy i zdarzenia bezpieczeństwa monitorowane są przez całodobowe centrum Security Operations Center (SOC) oparte na systemie SIEM (Splunk Cloud).

Wyzwania audytowe i zidentyfikowane uchybienia:

• Naruszenie retencji logów: Z powodu wysokich kosztów licencjonowania chmurowego systemu SIEM, logi z bram brzegowych API oraz klastrów Kubernetes są kasowane po 14 dniach (PCI DSS v4.0 wymaga przechowywania historii logów przez co najmniej 12 miesięcy, z czego 3 miesiące w trybie natychmiastowego dostępu).
• Zarządzanie sekretami w mikroserwisach: Podczas wstępnej weryfikacji wykryto, że część mikroserwisów pobiera klucze dostępowe do baz danych z nieszyfrowanych zmiennych środowiskowych (Environment Variables) zamiast z dedykowanego magazynu sekretów (HashiCorp Vault / AWS Secrets Manager).
• Skargi klientów na profilowanie: Dział marketingu uruchomił nowy moduł rekomendacji AI, który bez zgody użytkowników przetwarza dane o lokalizacji geograficznej i historii przeglądania w celu dynamicznego różnicowania cen produktów (ryzyko naruszenia art. 21 i 22 RODO).
• Zarząd wymaga planu audytu ISMS, który precyzyjnie wykorzysta sampling statystyczny i triangulację SIEM, nie spowalniając działania klastrów produkcyjnych.

Zespół audytorów (2-3 studentów) projektuje zaawansowany plan audytu:

• Krok 1 (Podział ról i metodyka badania wielochmurowego):

Student 1 (Audytor Wiodący / Metodolog Samplingu): Odpowiada za konstrukcję planu audytu, matematyczny model doboru próby statystycznej, ramy komunikacji z Zarządem i CISO, moderację spotkań otwierających/zamykających.

Student 2 (Audytor Chmury, Mikroserwisów i Logów SIEM): Projektuje metody weryfikacji klastrów Kubernetes, polityk IAM w AWS i GCP, audytu retencji logów w SIEM, badania konfiguracji Vault i bramek API.

Student 3 (Audytor Zgodności PCI DSS, RODO i Planu CAP): Opracowuje matrycę ryzyka 3x3, checklistę PCI DSS v4.0 (wymogi 3, 6, 10), weryfikację procedur profilowania AI, klasyfikację niezgodności NC1/NC2/OFI oraz tabelę CAP z analizą 5 Why.

• Krok 2 (Projektowanie zaawansowanego doboru próby - sampling statystyczny):

Zastosujcie model doboru próby zgodny z ISO 19011 (załącznik A.6):

• Dla transakcji kartowych: Z puli 2,5 mln operacji miesięcznych zaplanujcie losowy dobór próby 150 transakcji (poziom ufności 95%, margines błędu 5%) do sprawdzenia braku zapisu wrażliwych danych uwierzytelniających (kodów CVV2/CVC2) po autoryzacji.
• Dla zgód marketingowych i profilowania AI: Celowy dobór próby 30 kont użytkowników, którzy zgłosili sprzeciw wobec marketingu bezpośredniego.

Zaprojektujcie schemat krzyżowej weryfikacji incydentu bezpieczeństwa (np. wykrycia ataku SQL Injection na bramkę API):

• Źródło 1: Wpis w systemie zgłoszeń Jira Service Desk o podjęciu działań przez analityka SOC.
• Źródło 2: Zdarzenie w systemie SIEM (Splunk) potwierdzające wygenerowanie alertu i blokadę adresu IP na zaporze WAF.
• Źródło 3: Zrzut logu surowego (raw log) z kontenera Nginx w klastrze Kubernetes potwierdzający odrzucenie zapytania HTTP 403.

Opracowanie tabeli działań naprawczych z terminami (14-60 dni) i przypisaniem do Lead DevOps Architekta i IOD.

• Krok 7 (Harmonogram wielostrumieniowy - 4 dni robocze):

Szczegółowy podział na audyt chmury AWS, audyt Google Cloud, weryfikację centrum SOC i procesów RODO.

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Wyzwania architektury wielochmurowej i standard PCI DSS v4.0 w transgranicznym e-commerce (Student 1).
• Model samplingu statystycznego i szacowanie ryzyka 3x3 (4 min): Uzasadnienie doboru próby 150 transakcji i hierarchizacji ryzyk (Student 1 i 3).
• Przebieg audytu technicznego mikroserwisów i triangulacji SIEM (4 min): Prezentacja wyników inspekcji klastrów K8s, Vault i logów (Student 2).
• Kwalifikacja ustaleń (NC1/NC2/OFI) oraz Plan Działań Korygujących CAP (3 min): Analiza 5 Why i plan naprawczy dla Zarządu EuroMarket (Student 3).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania komisji dotyczące ryzyka próbkowania i wydajności chmury (cały zespół).

Raport składany na zaliczenie (8-12 stron znormalizowanego maszynopisu) musi obejmować:

A. Charakterystyka modelu biznesowego i infrastruktury wielochmurowej EuroMarket Global.

B. Zaawansowany Plan Audytu ISMS / PCI DSS:

• Metryka: Zleceniodawca (Zarząd EuroMarket Global), Zespół audytorów (3 osoby), Czas: 4 dni.
• Cel nadrzędny: Weryfikacja zgodności procesów przetwarzania danych kartowych i osobowych z normą ISO/IEC 27001:2022, standardem PCI DSS v4.0 oraz RODO.
• Zakres: Klastry Kubernetes w AWS i GCP, bazy danych zamówień, bramki płatności API, centrum SOC/SIEM, moduł analityki AI, flota paczkomatów.
• Model doboru próby statystycznej: Zastosowanie wzoru na liczebność próby dla populacji skończonej z poziomem ufności 95% i marginesem błędu 5% (n=150 transakcji).
• Matryca szacowania ryzyka (3x3):
  • Szczegółowe zestawienie ryzyk: utrata certyfikacji PCI DSS (9/9), wyciek sekretów ze zmiennych środowiskowych (6/9), kara za profilowanie AI (6/9).
• Rejestr Ustalonych Niezgodności:
  • NC1 (Niezgodność Duża): Kasowanie logów bezpieczeństwa po 14 dniach (wymóg min. 12 miesięcy wg PCI DSS v4.0 wymóg 10.5.1 oraz ISO 27001 A.8.15). Dowód: Konfiguracja polityki retencji indeksów w klastrze Splunk Cloud.
  • NC2 (Niezgodność Mała): Nieszyfrowane sekrety bazodanowe w manifestach środowiskowych Kubernetes. Podstawa: ISO 27001 A.8.28; PCI DSS wymóg 6.3.2. Dowód: Wynik inspekcji zrzutu konfiguracji podów w namespace "checkout-prod".
  • OFI (Szansa na poprawę): Brak wdrożenia wzorca Sidecar do szyfrowania ruchu wewnętrznego mTLS (service mesh) pomiędzy mikroserwisami.
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Retencja logów):
    • Analiza 5 Why: Dlaczego logi kasowano po 14 dniach? -> Bo przekraczano limit kosztowy w usłudze Splunk. Dlaczego przekraczano? -> Bo do systemu SIEM przesyłano miliony nieistotnych logów debugowania. Dlaczego przesyłano logi debug? -> Brak polityki filtrowania logów na poziomie agentów brzegowych. Przyczyna źródłowa (Root Cause): Brak zoptymalizowanej strategii logowania i kategoryzacji danych telemetrycznych oraz brak tiered-storage (pamięci wielowarstwowej).
    • Działanie naprawcze: Wdrożenie filtrów Fluentbit odrzucających zbędny szum; automatyczny eksport zindeksowanych logów bezpieczeństwa do taniej pamięci zimnej (AWS S3 Glacier Vault) z blokadą kasowania (Object Lock) na okres 12 miesięcy; rekonfiguracja Splunka na retencję gorącą 90 dni.
    • Właściciel: Kierownik Zespołu SOC we współpracy z Głównym Inżynierem Chmury.
    • Termin: 14 dni na filtry; 30 dni na wdrożenie S3 Glacier Object Lock.
• Harmonogram wielostrumieniowy audytu (4 dni robocze):
  • Dzień 1: Spotkanie otwierające, audyt ładu ISMS i polityk bezpieczeństwa, weryfikacja architektury wielochmurowej AWS/GCP.
  • Dzień 2 (równolegle): Strumień A (Audytor 2) - audyt klastrów K8s, konfiguracji Vault, inspekcja 10 mikroserwisów; Strumień B (Audytor 3) - audyt procedur RODO, doboru próby transakcji i zgód marketingowych.
  • Dzień 3 (równolegle): Strumień A (Audytor 2) - audyt centrum SOC, badanie retencji logów i triangulacja incydentów w Splunk; Strumień B (Audytor 3) - audyt zgodności z wymaganiami PCI DSS v4.0 i umów z bankami akceptantami.
  • Dzień 4: Triangulacja dowodów, spotkanie z zespołem technicznym w celu potwierdzenia ustaleń, formalne spotkanie zamykające z Zarządem EuroMarket Global.

C. Analiza zalet i ograniczeń planu:

• Zalety: Wysoka wiarygodność dzięki matematycznemu doborowi próby; uodpornienie platformy na rygorystyczne audyty Qualified Security Assessor (QSA) PCI DSS; optymalizacja kosztów chmury przy jednoczesnym spełnieniu prawa.
• Ograniczenia: Konieczność wysokich kompetencji audytorów w zakresie chmury i kontenerów; złożoność analizy logów w rozproszonym środowisku wielochmurowym.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• PCI Security Standards Council: "Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures v4.0", 2022.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania (Załącznik A.6: Próbkowanie).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 21, 22, 28, 32.
• Cloud Security Alliance (CSA): "Security Guidance for Critical Areas of Focus in Cloud Computing v4.0".
• Center for Internet Security (CIS): "CIS Kubernetes Benchmark v1.8", 2023.

• U1 Student konstruuje zaawansowany plan audytu platformy wielochmurowej w oparciu o normę ISO 27001.
• U2 Student klasyfikuje uchybienia według rygorów standardu PCI DSS v4.0 oraz ISO 27001.
• U3 Student wdraża zaawansowane metody samplingu statystycznego i analizy ryzyka 3x3.
• U4 Student opracowuje plan CAP oparty na analizie przyczyn źródłowych 5 Why dla mikroserwisów.
• W2 Student dogłębnie zna wymagania techniczne PCI DSS v4.0 i wytyczne próbkowania ISO 19011.
• K1K2 Student wykazuje skrupulatność dowodową i umiejętność profesjonalnej argumentacji inżynierskiej.

Celem zadania na ocenę 4.0 jest wykształcenie umiejętności zaplanowania zaawansowanego audytu ISMS w przedsiębiorstwie informatycznym wytwarzającym oprogramowanie o najwyższym poziomie krytyczności (systemy bankowości mobilnej i płatności transakcyjnych). Zadanie koncentruje się na audycie bezpieczeństwa procesu wytwórczego (Secure Software Development Life Cycle - Secure SDLC), weryfikacji łańcucha dostaw oprogramowania (analiza Software Bill of Materials - SBOM, weryfikacja bibliotek open-source i zależności tranzytywnych), bezpieczeństwie orkiestracji kontenerów Kubernetes, szacowaniu ryzyka 3x3, gradacji niezgodności (NC1/NC2/OFI) oraz opracowaniu Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych.

• U1 Opracowanie specjalistycznego planu audytu ISMS dla procesów DevSecOps i wytwarzania oprogramowania bankowego.
• U2 Formułowanie i klasyfikacja uchybień w potokach CI/CD, klastrach Kubernetes i zarządzaniu zależnościami.
• U3 Przeprowadzenie analizy ryzyka wstrzyknięcia złośliwego kodu lub podatności zero-day do aplikacji produkcyjnej.
• U4 Opracowanie profesjonalnego Planu Działań Korygujących (CAP) dla zespołów programistycznych.
• W2 Biegła znajomość ISO/IEC 27001:2022 (szczególnie kontrole Załącznika A: sekcja 8), standardów NIST SP 800-218 (Secure Software Development Framework - SSDF) oraz wytycznych OWASP ASVS i SAMM.
• W1 Ochrona własności intelektualnej, kodu źródłowego i tajemnicy bankowej w oprogramowaniu finansowym.
• K1K2 Zdolność do partnerskiej dyskusji z architektami oprogramowania i inżynierami bezpieczeństwa.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole techniczne ISO 27001), Wyk5 (Risk-based audit), Wyk7 (Niezgodności i CAP).

Spółka "SecureBank Tech Sp. z o.o." tworzy dedykowane aplikacje bankowości mobilnej dla 5 czołowych banków w Polsce i Niemczech. Aplikacje te obsługują łącznie ponad 4 miliony klientów bankowych, realizując autoryzację przelewów, transakcje BLIK oraz wnioskowanie o kredyty. Przedsiębiorstwo zatrudnia 130 pracowników (w tym 85 programistów Java, Kotlin, Swift, 15 inżynierów DevOps i QA, 10 specjalistów AppSec oraz kadrę zarządzającą).

Środowisko wytwórcze i architektura CI/CD:

• Repozytoria kodu źródłowego: Samodzielnie hostowana instancja GitLab Enterprise.
• Potoki CI/CD: Zautomatyzowane budowanie aplikacji w oparciu o kontenery Docker uruchamiane na dedykowanych maszynach runners.
• Wdrożenia testowe i demonstracyjne: Klastry Kubernetes (K8s) w chmurze prywatnej.
• Zastosowanie komponentów open-source: Średnio 70% kodu wynikowej aplikacji stanowią zewnętrzne biblioteki i frameworki pobierane z publicznych rejestrów (Maven Central, npm).

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

• Podatność w łańcuchu dostaw (Supply Chain Vulnerability): Dwa miesiące temu w jednej z powszechnie stosowanych bibliotek do parsowania JSON wykryto krytyczną podatność Remote Code Execution (RCE, ocena CVSS 9.8). Zespół dowiedział się o luce dopiero po zgłoszeniu od banku zamawiającego, ponieważ spółka nie generowała i nie monitorowała cyfrowej listy składowej oprogramowania (SBOM).
• Omijanie kontroli bezpieczeństwa w potoku CI/CD: W celu przyspieszenia wydań przed końcem kwartału programiści dodali do skryptów wdrożeniowych flagę "--skip-security-scans", co pozwoliło na wdrożenie wersji z pominięciem testów SAST i skanowania kontenerów.
• Zarządzanie sekretami i poświadczeniami: Klucze do podpisywania aplikacji mobilnych (certyfikaty produkcyjne Android Keystore i Apple iOS Developer) były przechowywane na współdzielonym dysku sieciowym w plikach chronionych prostym hasłem znanym 12 programistom.
• Zarząd spółki zleca zespołowi audytorów przygotowanie kompleksowego planu audytu ISMS procesu Secure SDLC, który zidentyfikuje niezgodności z ISO 27001 i standardami bankowymi oraz wytyczy ścieżkę naprawczą CAP.

Zespół audytorów (2-3 studentów) opracowuje plan audytu procesu wytwórczego:

• Krok 1 (Podział ról i metodyka badania DevSecOps):

Student 1 (Audytor Wiodący / Analityk Jakości Oprogramowania): Koordynuje audyt, współpracuje z Zarządem, CTO i Dyrektorem Jakości, odpowiada za spójność metodologiczną, procedury zarządzania zmianą (Change Management) i protokoły spotkań otwierających/zamykających.

Student 2 (Audytor Bezpieczeństwa Aplikacji i CI/CD): Planuje audyt potoków GitLab CI/CD, kontroli SAST/DAST, narzędzi analizy komponentów oprogramowania (SCA) i generowania SBOM, bezpieczeństwa repozytoriów kodu oraz procedur podpisywania aplikacji.

Student 3 (Audytor Środowisk Chmurowych K8s, Ryzyka i Planu CAP): Opracowuje matrycę ryzyka 3x3, audytuje bezpieczeństwo klastrów Kubernetes, zarządzanie sekretami w Vault, klasyfikuje niezgodności NC1/NC2/OFI i projektuje plan CAP z analizą 5 Why.

• Krok 2 (Wyznaczenie zakresu i granic audytu):

Zakres: Cały cykl życia oprogramowania (od wymagań, przez kodowanie, testy, budowanie, po wydanie), repozytoria GitLab, potoki CI/CD, magazyn sekretów, klastry testowe K8s, stacje robocze deweloperów. Wyłączenia: Sprawy księgowe i kadrowe (o ile nie dotyczą personelu IT).

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Norma PN-EN ISO/IEC 27001:2022 (szczególnie Załącznik A: A.8.25 Bezpieczny cykl życia oprogramowania, A.8.27 Architektura i inżynieria bezpieczeństwa, A.8.28 Bezpieczne kodowanie, A.8.30 Testowanie bezpieczeństwa, A.8.31 Rozdzielenie środowisk), ramy NIST SP 800-218 (SSDF), standard OWASP Mobile Application Security Verification Standard (MASVS).

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):
  • Ryzyko 1: Wprowadzenie złośliwego kodu przez podatną bibliotekę open-source bez kontroli SBOM. P=3 (Wysokie), S=3 (Krytyczne - kompromitacja bankowości mobilnej u milionów klientów). Ryzyko inherentne: 9/9 (Niedopuszczalne). Kontrola: Wdrożenie obowiązkowego skanowania SCA i automatycznego generowania SBOM w formacie CycloneDX. Ryzyko rezydualne: 1/9.
  • Ryzyko 2: Kompromitacja produkcyjnego klucza podpisywania aplikacji mobilnych. P=2, S=3. Ryzyko inherentne: 6/9 (Wysokie). Kontrola: Przeniesienie kluczy do sprzętowego modułu HSM w chmurze z autoryzacją wieloosobową. Ryzyko rezydualne: 1/9.
  • Ryzyko 3: Ominięcie testów bezpieczeństwa SAST w potoku CI/CD przez programistów. P=3, S=2. Ryzyko inherentne: 6/9. Kontrola: Zablokowanie możliwości modyfikacji plików konfiguracyjnych potoków przez uprawnienia branch protection. Ryzyko rezydualne: 2/9.
• Krok 5 (Kwalifikacja niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Możliwość ominięcia testów bezpieczeństwa w potoku CI/CD oraz brak weryfikacji zależności open-source SBOM (naruszenie ISO 27001 A.8.25, A.8.28 i A.8.30).
  • NC2 (Niezgodność Mała): Przechowywanie kluczy certyfikatów deweloperskich na dysku sieciowym bez ochrony HSM (naruszenie Załącznika A.8.24).
  • OFI (Szansa na poprawę): Wdrożenie automatycznego podpisywania commitów kluczami GPG powiązanymi z tożsamością każdego programisty.
• Krok 6 (Konstrukcja Planu CAP z analizą 5 Why):

Zaprojektujcie tabelę CAP z analizą przyczyn źródłowych (dlaczego deweloperzy wyłączali skany? -> presja terminowa + zbyt duża liczba fałszywych alarmów false-positive) i działaniami naprawczymi.

• Krok 7 (Harmonogram wielostrumieniowy audytu - 4 dni):

Dzień 1: Spotkanie otwierające, audyt nadrzędnych polityk Secure SDLC i zarządzania zmianą. Dzień 2: Audyt techniczny repozytoriów GitLab i potoków CI/CD, próbkowanie 15 wydań kodu. Dzień 3: Audyt klastrów K8s, modułów kryptograficznych HSM i zarządzania sekretami. Dzień 4: Triangulacja dowodów, spotkanie z liderami technicznymi, formalne spotkanie zamykające z Zarządem.

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Bezpieczeństwo łańcucha dostaw oprogramowania i rola DevSecOps w bankowości mobilnej (Student 1).
• Metodyka SBOM, analiza zależności i matryca ryzyka 3x3 (4 min): Wyjaśnienie zagrożeń wynikających z komponentów open-source i szacowanie ryzyka (Student 2).
• Przebieg audytu technicznego potoków CI/CD i Kubernetes (4 min): Przedstawienie dowodów ominięcia kontroli i przechowywania kluczy (Student 2 i 3).
• Kwalifikacja ustaleń (NC1/NC2/OFI) oraz Plan Działań Korygujących CAP (3 min): Analiza przyczyn źródłowych i harmonogram naprawczy (Student 3).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania komisji dotyczące zrównoważenia tempa wydań z bezpieczeństwem (cały zespół).

Raport składany na zaliczenie (8-12 stron znormalizowanego maszynopisu) musi zawierać:

A. Kontekst inżynierii oprogramowania finansowego i profil zagrożeń Supply Chain Attack.

B. Wzorcowy Plan Audytu ISMS w procesie Secure SDLC:

• Metryka: Zleceniodawca (Zarząd SecureBank Tech), Zespół audytorów (3 osoby), Czas: 4 dni robocze.
• Cel nadrzędny: Weryfikacja zgodności procesu wytwórczego i potoków CI/CD z wymaganiami ISO/IEC 27001:2022 oraz ramami NIST SSDF pod kątem integralności aplikacji bankowych.
• Zakres: Repozytoria GitLab, potoki CI/CD, narzędzia SAST/DAST/SCA, procedury zarządzania sekretami i kluczami, klastry testowe K8s, procedury wdrożeniowe.
• Matryca szacowania ryzyka (3x3):
  • Zestawienie ryzyk: Podatność w bibliotece open-source (9/9), kompromitacja klucza certyfikatu produkcyjnego (6/9), omijanie testów bezpieczeństwa (6/9).
• Rejestr Ustalonych Niezgodności:
  • NC1 (Niezgodność Duża): Brak wymuszonego, zautomatyzowanego testowania bezpieczeństwa w potokach CI/CD oraz brak inwentaryzacji bibliotek zewnętrznych (brak SBOM). Podstawa: ISO 27001 A.8.25, A.8.28, A.8.30; NIST SSDF PW.1. Dowód: Analiza konfiguracji pliku .gitlab-ci.yml w 4 głównych projektach bankowych.
  • NC2 (Niezgodność Mała): Przechowywanie kluczy certyfikatów deweloperskich na dysku współdzielonym w formacie PKCS#12 bez ochrony sprzętowej. Podstawa: ISO 27001 A.8.24. Dowód: Zrzut uprawnień do katalogu sieciowego z certyfikatami.
  • OFI (Szansa na poprawę): Wdrożenie technologii podpisów kryptograficznych Sigstore/Cosign dla obrazów kontenerów w rejestrze Docker.
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Brak SBOM i omijanie skanów):
    • Analiza 5 Why: Dlaczego programiści dodali flagę pomijania skanów? -> Bo skanowanie trwało ponad 45 minut i blokowało pilne wydania poprawek. Dlaczego trwało tak długo? -> Narzędzie skanujące było źle skonfigurowane i skanowało cały kod od zera zamiast tylko zmienionych linii (brak skanowania przyrostowego). Dlaczego nikt nie zoptymalizował narzędzia? -> Brak dedykowanego inżyniera AppSec w zespole projektowym. Przyczyna źródłowa (Root Cause): Brak zasobów i kompetencji AppSec dedykowanych optymalizacji narzędzi bezpieczeństwa w potoku deweloperskim oraz brak kultury DevSecOps.
    • Działanie naprawcze: Zakup i integracja narzędzia SCA generującego automatycznie SBOM w standardzie CycloneDX przy każdym budowaniu; optymalizacja skanerów SAST do analizy przyrostowej; zablokowanie możliwości pominięcia skanów w potokach przez wymuszenie szablonów CI/CD na poziomie grupy GitLab.
    • Właściciel: Dyrektor Pionu Technologii (CTO) we współpracy z Lead AppSec Engineerem.
    • Termin: 30 dni na szablony CI/CD i blokady; 60 dni na wdrożenie SBOM i optymalizację narzędzi.
• Harmonogram wielostrumieniowy audytu (4 dni robocze):
  • Dzień 1: Spotkanie otwierające z Zarządem i CTO, przegląd architektury bezpieczeństwa oprogramowania i ładu ISMS.
  • Dzień 2 (równolegle): Strumień A (Audytor 2) - inspekcja potoków CI/CD, konfiguracji skanerów SAST i pobierania zależności z repozytoriów; Strumień B (Audytor 3) - audyt procedur szkoleniowych programistów z bezpiecznego kodowania (OWASP Top 10) i weryfikacji umów licencyjnych.
  • Dzień 3 (równolegle): Strumień A (Audytor 2) - audyt zarządzania kluczami podpisywania aplikacji i klastrów K8s; Strumień B (Audytor 3) - audyt procedur reagowania na zgłoszenia podatności od banków i klientów.
  • Dzień 4: Triangulacja dowodów, spotkanie z zespołem technicznym, formalne spotkanie zamykające z Zarządem spółki.

C. Analiza zalet i wad planu:

• Zalety: Wyeliminowanie krytycznych zagrożeń w łańcuchu dostaw oprogramowania; pełna zgodność z międzynarodowymi standardami inżynierii NIST i OWASP; budowa zaufania banków partnerskich.
• Ograniczenia i ryzyka: Ryzyko początkowego spowolnienia cyklu wydań oprogramowania w fazie kalibracji narzędzi SBOM; konieczność przeszkolenia 85 programistów z obsługi nowych reguł potoków CI/CD.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji (Załącznik A: kontrole sekcji 8).
• NIST Special Publication 800-218: "Secure Software Development Framework (SSDF) Version 1.1", 2022.
• OWASP Foundation: "Software Assurance Maturity Model (SAMM) v2.0", 2020.
• OWASP Mobile Application Security Verification Standard (MASVS) v2.0.
• Cybersecurity and Infrastructure Security Agency (CISA): "Types of Software Bill of Materials (SBOM) Documents", 2023.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania.

• U1 Student potrafi zaplanować zaawansowany audyt procesu programistycznego i potoków DevSecOps.
• U2 Student bezbłędnie identyfikuje i klasyfikuje uchybienia w architekturze CI/CD i zarządzaniu kodem (NC1/NC2/OFI).
• U3 Student przeprowadza szacowanie ryzyka w łańcuchu dostaw oprogramowania w matrycy 3x3.
• U4 Student buduje plan CAP z analizą 5 Why usuwający przyczyny źródłowe opóźnień i uchybień w procesie SDLC.
• W2 Student zna normy ISO 27001, wytyczne NIST SSDF oraz metodykę SBOM.
• K1K2 Student rozwija profesjonalne podejście do audytu środowisk inżynierskich i konstruktywnej współpracy z kadrą IT.

Celem zadania na ocenę 4.0 jest nauczenie studentów projektowania zaawansowanego planu audytu ISMS w dużej uczelni wyższej łączącej kształcenie akademickie z prowadzeniem innowacyjnych badań klinicznych i technologicznych. Zadanie kładzie szczególny nacisk na wyzwania audytowe wynikające z tradycyjnej autonomii katedr i wydziałów, specyfikę protokołów komunikacji i spotkań otwierających/zamykających prowadzonych w duchu normy ISO 19011:2018, audyt ochrony danych pacjentów biorących udział w badaniach lekowych, zabezpieczenie infrastruktury wielokampusowej sieci eduroam, szacowanie ryzyka w matrycy 3x3, gradację uchybień (NC1/NC2/OFI) oraz opracowanie Planu Działań Korygujących (CAP).

• U1 Opracowanie zintegrowanego planu audytu ISMS w złożonym ekosystemie akademicko-badawczym.
• U2 Formułowanie i klasyfikacja uchybień (NC1/NC2/OFI) w obszarze badań naukowych i administracji studenckiej.
• U3 Przeprowadzenie analizy ryzyka wycieku wyników badań przed opatentowaniem oraz danych klinicznych pacjentów.
• U4 Opracowanie realistycznego Planu Działań Korygujących (CAP) uwzględniającego specyfikę prawa o szkolnictwie wyższym.
• W1 Ochrona własności przemysłowej (patenty), praw autorskich oraz danych osobowych studentów i pacjentów (art. 9 RODO).
• W2W3 Wymagania ISO/IEC 27001:2022, wytyczne audytowe ISO 19011, Rozporządzenie KRI oraz Ustawa - Prawo o szkolnictwie wyższym i nauce.
• K1K2 Dyplomacja audytorska, szacunek dla autonomii naukowej i umiejętność konstruktywnego przełamywania oporu środowiska akademickiego.
• Treści programowe: Wyk2 (Komunikacja i zasady audytowania), Wyk3 (Kontrole ISO 27001), Wyk4 (RODO i KRI), Wyk5 (Risk-based audit), Wyk7 (Niezgodności i CAP).

Uniwersytet Medyczno-Techniczny kształci 14 000 studentów na 7 wydziałach (m.in. Wydział Lekarski, Farmaceutyczny, Biotechnologii, Informatyki Medycznej) i zatrudnia 2 400 pracowników (w tym 1 600 nauczycieli akademickich i badaczy). Kampus obejmuje 18 budynków dydaktycznych, 3 szpitale kliniczne oraz Centrum Badań Przedklinicznych.

Infrastruktura teleinformatyczna i zasoby badawcze:

• Uczelniany system dziekanatowy (USOS) zintegrowany z systemami e-learningu (Moodle) i pocztą elektroniczną w chmurze Microsoft 365.
• Wielokampusowa sieć Wi-Fi (eduroam) z ponad 600 punktami dostępowymi, do której codziennie loguje się 18 000 urządzeń prywatnych (BYOD).
• Centrum Badań Przedklinicznych prowadzące badania nad nowymi cząsteczkami przeciwnowotworowymi we współpracy z globalnymi koncernami farmaceutycznymi. W bazach przetwarzane są nieopublikowane sekwencje DNA, wyniki prób klinicznych pacjentów onkologicznych oraz dokumentacja zgłoszeń patentowych.

Sygnały ostrzegawcze i zidentyfikowane uchybienia:

• Niekontrolowane dyski chmurowe i BYOD: Naukowcy z Wydziału Farmaceutycznego zapisują surowe pliki z wynikami badań klinicznych na darmowych, prywatnych kontach Google Drive i Dropbox, aby móc pracować w domu i udostępniać dane zagranicznym doktorantom.
• Brak izolacji sieci eduroam od stacji laboratoryjnych: Wykazano, że stacja robocza podłączona do sekwencera DNA w laboratorium biotechnologii znajduje się w tej samej logicznej podsieci co ogólnodostępna sieć studencka eduroam, bez zapory ogniowej.
• Procedury RODO i KRI: Rektor powołał Inspektora Ochrony Danych, jednak wydziały nie prowadzą rejestru czynności przetwarzania danych badawczych, uznając, że autonomia naukowa wyłącza je spod procedur centralnych.
• Rektor zarządził kompleksowy audyt ISMS przed wizytacją Komisji Akredytacyjnej i audytem sponsora badań klinicznych.

Zespół audytorów (2-3 studentów) projektuje zaawansowany plan audytu:

• Krok 1 (Podział ról i metodyka komunikacji akademickiej):

Student 1 (Audytor Wiodący / Moderator Dialogu): Opracowuje plan komunikacji wg ISO 19011, scenariusze spotkań otwierających z Rektorem i Dziekanami, zarządza harmonogramem i procedurą łagodzenia sporów kompetencyjnych.

Student 2 (Audytor Sieci Kampusowej, Systemów i Laboratoriów): Planuje audyt bezpieczeństwa sieci eduroam, separacji stacji badawczych, systemów USOS/Moodle, serwerowni uczelnianej i polityki szyfrowania.

Student 3 (Audytor Prawno-Regulacyjny, Ryzyka i Działań Korygujących): Opracowuje matrycę ryzyka 3x3 dla ochrony własności intelektualnej i danych klinicznych, checklistę RODO/KRI, klasyfikuje niezgodności NC1/NC2/OFI i projektuje plan CAP z analizą 5 Why.

• Krok 2 (Wyznaczenie zakresu i granic audytu):

Zakres: Rektorat, Centrum Badań Przedklinicznych, Wydział Lekarski i Farmaceutyczny, Uczelniane Centrum Informatyki, system USOS, sieć eduroam, serwerownia główna.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Norma PN-EN ISO/IEC 27001:2022 (kontrole: A.5.10, A.8.1, A.8.12 Zapobieganie wyciekowi danych, A.8.20, A.8.22 Segregacja sieci), Rozporządzenie RODO (art. 9, 32), Ustawa - Prawo o szkolnictwie wyższym i nauce, Rozporządzenie w sprawie KRI.

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):
  • Ryzyko 1: Wyciek nieopublikowanych wyników badań onkologicznych z prywatnych chmur naukowców i utrata pierwszeństwa patentowego. P=3 (Wysokie), S=3 (Krytyczne - wielomilionowe straty i utrata grantów). Ryzyko inherentne: 9/9. Kontrola: Wdrożenie bezpiecznej uczelnianej chmury badawczej (Nextcloud z szyfrowaniem end-to-end) i zakaz chmur prywatnych. Ryzyko rezydualne: 2/9.
  • Ryzyko 2: Atak z sieci studenckiej eduroam na aparaturę badawczą i sekwencery DNA. P=3, S=3. Ryzyko inherentne: 9/9. Kontrola: Całkowita izolacja sieci laboratoryjnej (VLAN badawczy z kontrolą dostępu 802.1X). Ryzyko rezydualne: 1/9.
  • Ryzyko 3: Wyciek danych wrażliwych pacjentów uczestniczących w próbach lekowych. P=2, S=3. Ryzyko inherentne: 6/9. Kontrola: Obowiązkowa pseudonimizacja danych klinicznych przed wprowadzeniem do baz. Ryzyko rezydualne: 2/9.
• Krok 5 (Kwalifikacja niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Przechowywanie danych badań klinicznych i patentowych na prywatnych dyskach chmurowych bez umów powierzenia oraz brak separacji sieci eduroam od aparatury badawczej (naruszenie ISO 27001 A.8.12, A.8.22 oraz art. 32 RODO).
  • NC2 (Niezgodność Mała): Brak ewidencji i rejestru czynności przetwarzania danych osobowych pacjentów w badaniach prowadzonych przez katedry (naruszenie art. 30 RODO).
  • OFI (Szansa na poprawę): Wdrożenie kluczy sprzętowych FIDO2 dla pracowników dziekanatów obsługujących system USOS.
• Krok 6 (Konstrukcja Planu CAP z analizą 5 Why):

Zaprojektujcie tabelę CAP z analizą przyczyn źródłowych (dlaczego naukowcy korzystali z prywatnych chmur? -> brak uczelnianego narzędzia do wymiany dużych plików surowych danych badawczych) i planem wdrożenia platformy badawczej.

• Krok 7 (Harmonogram wielostrumieniowy - 4 dni audytu):

Rozpisanie audytu Rektoratu, Dziekanatów, laboratoriów Centrum Badań i Centrum Informatyki.

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Specyfika środowiska akademickiego - jak pogodzić wolność badań naukowych z rygorami ISMS (Student 1).
• Komunikacja wg ISO 19011 i szacowanie ryzyka 3x3 (4 min): Przebieg spotkań otwierających z Dziekanami i matryca ryzyka badań klinicznych (Student 1 i 3).
• Przebieg audytu technicznego sieci eduroam i stacji laboratoryjnych (4 min): Dowody braku separacji i wycieków do chmur publicznych (Student 2).
• Rejestr niezgodności NC1/NC2/OFI i Plan Działań Korygujących CAP (3 min): Analiza 5 Why i plan wdrożenia bezpiecznej chmury badawczej (Student 3).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania komisji o postępowanie w przypadku odmowy audytu przez profesora/kierownika grantu (cały zespół).

Raport seminaryjny (8-12 stron maszynopisu) musi zawierać:

A. Kontekst organizacyjno-prawny uniwersytetu i uwarunkowania grantów badawczych.

B. Wzorcowy Plan Audytu ISMS na Uniwersytecie Medyczno-Technicznym:

• Metryka: Zleceniodawca (Rektor Uczelni), Czas audytu: 4 dni robocze, 3 audytorów.
• Cel nadrzędny: Ocena zgodności procesów przetwarzania danych badawczych i studenckich z normą ISO/IEC 27001:2022 oraz wymogami RODO i KRI.
• Zakres: Centrum Badań Przedklinicznych, laboratoria Wydziału Farmacji i Biotechnologii, system USOS, sieć eduroam, serwerownia główna.
• Matryca szacowania ryzyka (3x3):
  • Szczegółowa ocena ryzyk dla danych patentowych (9/9), sieci aparatury badawczej (9/9) oraz baz klinicznych pacjentów (6/9).
• Rejestr Ustalonych Niezgodności:
  • NC1 (Niezgodność Duża): Przechowywanie danych z prób klinicznych na nieszyfrowanych chmurach prywatnych oraz brak separacji eduroam od sieci badawczej. Podstawa: ISO 27001 A.8.12, A.8.22; art. 32 RODO.
  • NC2 (Niezgodność Mała): Brak centralnego rejestru czynności przetwarzania danych w projektach badawczych. Podstawa: art. 30 RODO.
  • OFI (Szansa na poprawę): Brak wdrożenia bezpiecznego repozytorium danych badawczych zgodnego z zasadami FAIR Data.
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Chmury prywatne i brak separacji):
    • Analiza 5 Why: Dlaczego badacze korzystają z prywatnych chmur? -> Bo oficjalna skrzynka pocztowa ma limit załącznika 25 MB, a pliki sekwencera mają po 10 GB. Dlaczego nie ma narzędzia centralnego? -> Uczelniane IT nie zbadało potrzeb naukowców przy wdrażaniu systemów. Dlaczego nie zbadało? -> Brak dialogu pomiędzy administracją centralną a zespołami badawczymi. Przyczyna źródłowa (Root Cause): Brak zintegrowanej strategii cyfrowej wspierającej procesy badawcze i brak dostarczenia przez uczelnię bezpiecznych narzędzi do wymiany dużych zbiorów danych (Big Data).
    • Działanie naprawcze: Uruchomienie uczelnianego serwera Nextcloud zintegrowanego z uczelnianym Active Directory i szyfrowaniem dysków; natychmiastowe wydzielenie bezpiecznego VLAN-u Laboratoryjnego odciętego od eduroam; wydanie Zarządzenia Rektora zakazującego umieszczania danych badawczych w chmurach konsumenckich.
    • Właściciel: Prorektor ds. Nauki we współpracy z Dyrektorem Uczelnianego Centrum IT.
    • Termin: 14 dni na wydzielenie sieci VLAN; 45 dni na wdrożenie bezpiecznej chmury i zarządzenie.
• Harmonogram wielostrumieniowy audytu (4 dni robocze):
  • Dzień 1: Spotkanie otwierające z Rektorem, Dziekanami i IOD; audyt ładu ISMS i Centrum Informatyki.
  • Dzień 2 (równolegle): Strumień A (Audytor 2) - inspekcja szaf sieciowych, testy konfiguracji eduroam i stacji roboczych USOS; Strumień B (Audytor 3) - audyt Dziekanatu i archiwum prac dyplomowych.
  • Dzień 3 (równolegle): Strumień A (Audytor 2) - audyt stacji laboratoryjnych i sekwencerów DNA; Strumień B (Audytor 3) - audyt umów grantowych i procedur pseudonimizacji w Centrum Badań.
  • Dzień 4: Triangulacja dowodów, narada zespołu, spotkanie zamykające z Kolegium Rektorskim.

C. Analiza zalet i trudności rozwiązania:

• Zalety: Skuteczne zabezpieczenie wielomilionowej własności intelektualnej i patentów uczelni; zachowanie zgodności z RODO bez hamowania współpracy międzynarodowej; edukacja kadry naukowej.
• Trudności: Konieczność przełamania niechęci części profesorów wobec procedur kontrolnych; koszty rozbudowy uczelnianej macierzy dyskowej dla potrzeb badawczych.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Ustawa z dnia 20 lipca 2018 r. - Prawo o szkolnictwie wyższym i nauce (Dz.U. z 2023 r. poz. 742).
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania (punkt 6.4.2: Spotkanie otwierające w środowiskach autonomicznych).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 9, 30, 32.
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2024 r. poz. 773).
• Urząd Patentowy Rzeczypospolitej Polskiej: "Ochrona własności przemysłowej i know-how w projektach naukowo-badawczych", Warszawa.

• U1 Student umie zaplanować audyt ISMS w zróżnicowanym środowisku akademicko-naukowym.
• U2 Student poprawnie identyfikuje niezgodności dotyczące własności intelektualnej i danych wrażliwych (NC1/NC2/OFI).
• U3 Student przeprowadza szacowanie ryzyka wycieku danych patentowych w matrycy 3x3.
• U4 Student buduje plan CAP oparty na analizie 5 Why dla placówki badawczo-dydaktycznej.
• W1W3 Student rozumie powiązania prawa o szkolnictwie wyższym, prawa patentowego i RODO z normą ISO 27001.
• K1K2 Student wykazuje wysokie kompetencje komunikacyjne i dyplomatyczne w dialogu ze środowiskiem akademickim.

Celem zadania na ocenę 4.0 jest wykształcenie umiejętności zaplanowania zaawansowanego audytu ISMS w międzynarodowej kancelarii prawnej i firmie audytorsko-doradczej obsługującej transakcje fuzji i przejęć (M&A) spółek notowanych na Giełdzie Papierów Wartościowych. Zadanie skupia się na metodyce badania procedur ochrony informacji poufnych i cenotwórczych zgodnie z Rozporządzeniem MAR (Market Abuse Regulation), audycie wirtualnych pokoi danych (Virtual Data Room - VDR), procedurach informatyki śledczej (computer forensics), rygorystycznym szacowaniu ryzyka w matrycy 3x3, gradacji niezgodności (NC1/NC2/OFI) oraz opracowaniu Planu Działań Korygujących (CAP).

• U1 Opracowanie zaawansowanego planu audytu ISMS dedykowanego ochronie tajemnicy giełdowej i zawodowej.
• U2 Bezbłędna kwalifikacja uchybień w zarządzaniu listami dostępu do informacji poufnych (Insider Lists).
• U3 Przeprowadzenie analizy ryzyka wycieku informacji cenotwórczych i nielegalnego wykorzystania informacji (Insider Trading).
• U4 Opracowanie profesjonalnego Planu Działań Korygujących (CAP) chroniącego reputację rynkową kancelarii.
• W1 Ochrona tajemnicy adwokackiej, radcowskiej, biegłego rewidenta oraz tajemnicy giełdowej w rozumieniu Rozporządzenia MAR.
• W2W3 Wymagania normy ISO/IEC 27001:2022 (szczególnie kontrole Załącznika A: A.5.14, A.6.6, A.8.11, A.8.24), wytyczne ISO 19011 i regulacje Europejskiego Urzędu Nadzoru Giełd i Papierów Wartościowych (ESMA).
• K1K3 Bezwzględna etyka, dyskrecja oraz zachowanie tajemnicy bez naruszania tajemnicy obrończej klientów.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole ISO 27001), Wyk4 (RODO i tajemnice sektorowe), Wyk5 (Risk-based audit), Wyk7 (Niezgodności i CAP).

Kancelaria "Global Legal & Audit Alliance Sp.k." zatrudnia 140 prawników, biegłych rewidentów i doradców podatkowych w biurach w Warszawie i Frankfurcie. Kancelaria doradza w procesach pierwszych ofert publicznych (IPO), przejęciach spółek notowanych na GPW i Deutsche Börse oraz przeprowadza due diligence finansowe i prawne.

Infrastruktura techniczna i obieg informacji wrażliwych:

• Dokumentacja transakcyjna (często wyceniana na miliardy euro) przetwarzana jest na platformach Virtual Data Room (VDR) dostarczanych w modelu chmurowym.
• Prawnicy i audytorzy pracują w modelu hybrydowym na służbowych laptopach z systemem Windows 11 Enterprise zarządzanych przez Microsoft Intune.
• Kancelaria posiada dedykowane laboratorium informatyki śledczej (Computer Forensics) wyposażone w blokery zapisu i oprogramowanie EnCase do zabezpieczania dowodów cyfrowych na potrzeby sporów korporacyjnych.

Złożone uchybienia ujawnione w toku wstępnego rozpoznania:

• Brak aktualizacji list Insiderów (Rozporządzenie MAR): Po zakończeniu transakcji przejęcia spółki energetycznej z GPW uprawnienia do wirtualnego pokoju danych VDR nie zostały odebrane 18 prawnikom i analitykom przez ponad 45 dni; lista osób mających dostęp do informacji poufnej (art. 18 MAR) nie zawierała dokładnych znaczników czasu UTC.
• Praca hybrydowa i urządzenia mobilne: Jeden z młodszych prawników przesyłał robocze projekty prospektu emisyjnego ze służbowego laptopa na swój prywatny adres e-mail i otwierał je na niezabezpieczonym domowym iPadzie.
• Ryzyko podsłuchu i podglądu: Sale konferencyjne przeznaczone do negocjacji transakcji fuzji nie posiadają zabezpieczeń przed podsłuchem elektronicznym, a szklane ściany sal umożliwiają odczyt prezentacji z korytarza (brak folii matującej).
• Partnerzy Zarządzający zlecają zespołowi audytorów przygotowanie planu audytu ISMS, który potwierdzi najwyższy poziom poufności przed zagranicznymi instytucjami finansowymi i KNF.

Zespół audytorów (2-3 studentów) projektuje zaawansowany plan audytu:

• Krok 1 (Podział ról i metodyka badania rynków kapitałowych):

Student 1 (Audytor Wiodący / Ekspert Zgodności MAR): Koordynuje audyt, współpracuje z Partnerami Zarządzającymi i Oficerem Compliance, weryfikuje procedury Insider Lists, nadzoruje harmonogram i spotkania otwierające/zamykające.

Student 2 (Audytor Bezpieczeństwa IT, Urządzeń Mobilnych i Forensics): Planuje audyt konsoli MDM/Intune, szyfrowania urządzeń BitLocker, platform VDR, konfiguracji laboratorium śledczego i zabezpieczeń przed podsłuchem.

Student 3 (Audytor Ryzyka, Tajemnic Zawodowych i Planu CAP): Opracowuje matrycę ryzyka 3x3 dla scenariusza wycieku informacji cenotwórczej, klasyfikuje niezgodności NC1/NC2/OFI i projektuje plan CAP z analizą 5 Why.

• Krok 2 (Wyznaczenie granic audytu i ochrona tajemnicy obrończej):

Zakres: Siedziba w Warszawie, flota urządzeń przenośnych, platformy VDR, laboratorium forensics, sale konferencyjne. Wyłączenie metodyczne: Audytorzy badają procedury, uprawnienia i logi, bez wglądu w merytoryczną treść poufnych opinii prawnych i dokumentów obrończych.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Rozporządzenie MAR (art. 7 Informacje poufne, art. 17 Podawanie do wiadomości, art. 18 Listy osób mających dostęp do informacji poufnych), Norma PN-EN ISO/IEC 27001:2022 (kontrole: A.5.14, A.6.6, A.7.7, A.8.1, A.8.24), Kodeksy etyki radców prawnych i biegłych rewidentów.

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):
  • Ryzyko 1: Wykorzystanie informacji poufnej (Insider Trading) wskutek nieodebrania uprawnień do platformy VDR. P=2, S=3 (Krytyczny - sankcje KNF do 20 mln PLN i odpowiedzialność karna partnerów). Ryzyko inherentne: 6/9 (Wysokie). Kontrola: Automatyczna integracja VDR z bazą projektową i odbieranie dostępu w dniu zamknięcia transakcji. Ryzyko rezydualne: 1/9.
  • Ryzyko 2: Wyciek projektu prospektu emisyjnego przez wysyłkę na prywatny adres e-mail. P=3, S=3. Ryzyko inherentne: 9/9 (Niedopuszczalne). Kontrola: Wdrożenie reguł Data Loss Prevention (DLP) w Microsoft 365 blokujących wysyłkę plików na domeny publiczne. Ryzyko rezydualne: 2/9.
  • Ryzyko 3: Podsłuchanie negocjacji fuzji spółek w sali konferencyjnej. P=2, S=3. Ryzyko inherentne: 6/9. Kontrola: Montaż folii polaryzacyjnych na przeszkleniach, wdrożenie zagłuszarek akustycznych i procedury sprawdzania obecności urządzeń podsłuchowych. Ryzyko rezydualne: 1/9.
• Krok 5 (Kwalifikacja niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Pozostawienie aktywnych kont do platformy VDR po zakończeniu projektu oraz brak precyzyjnych znaczników czasu w listach Insiderów (naruszenie art. 18 Rozporządzenia MAR oraz ISO 27001 A.5.18).
  • NC2 (Niezgodność Mała): Brak technicznej blokady wysyłania plików z oznaczeniem "Poufne MAR" na prywatne adresy e-mail (naruszenie Załącznika A.8.12).
  • OFI (Szansa na poprawę): Wdrożenie systemu certyfikowanego niszczenia danych w laboratorium forensics zgodnego ze standardem NIST SP 800-88.
• Krok 6 (Plan CAP z analizą 5 Why):

Zaprojektujcie tabelę CAP z analizą przyczyn źródłowych (dlaczego konta VDR nie zostały zablokowane? -> brak komunikacji między liderem transakcji a administratorem IT) i procedurą automatycznego zamykania projektów.

• Krok 7 (Harmonogram wielostrumieniowy - 3,5 dnia audytu):

Rozpisanie audytu systemów VDR, floty laptopów, laboratorium forensics i strefy spotkań z klientami.

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Rygory Rozporządzenia MAR i odpowiedzialność prawna kancelarii za informacje poufne (Student 1).
• Szacowanie ryzyka 3x3 i granice audytu a tajemnica zawodowa (4 min): Prezentacja matrycy ryzyka insider tradingu i ochrony akt klientów (Student 3).
• Przebieg audytu technicznego VDR, MDM i laboratorium forensics (4 min): Przedstawienie dowodów braku reguł DLP i kont w VDR (Student 2).
• Kwalifikacja ustaleń (NC1/NC2/OFI) oraz Plan Działań Korygujących CAP (3 min): Analiza 5 Why i plan naprawczy dla Partnerów Kancelarii (Student 3 i 1).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania komisji o procedury postępowania w przypadku podejrzenia popełnienia przestępstwa giełdowego (cały zespół).

Raport składany na zaliczenie (8-12 stron znormalizowanego maszynopisu) musi obejmować:

A. Charakterystyka uwarunkowań prawnych kancelarii i standardów compliance na rynkach kapitałowych.

B. Zaawansowany Plan Audytu ISMS w Global Legal & Audit Alliance:

• Metryka: Zleceniodawca (Partnerzy Zarządzający), Czas audytu: 3,5 dnia roboczego, 3 audytorów (z klauzulą poufności).
• Cel nadrzędny: Weryfikacja skuteczności środków kontroli ISMS w zapobieganiu nieuprawnionemu ujawnieniu informacji cenotwórczych zgodnie z ISO/IEC 27001:2022 oraz Rozporządzeniem MAR.
• Zakres: Platformy VDR, flota urządzeń przenośnych Intune, system pocztowy M365, laboratorium informatyki śledczej, sale negocjacyjne.
• Ograniczenia: Zakaz przeglądania treści dokumentacji procesowej i akt klientów; badanie wyłącznie metadanych, logów i uprawnień.
• Matryca szacowania ryzyka (3x3):
  • Zestawienie 3 ryzyk: nieuprawniony dostęp do VDR po terminie (6/9), wysyłka na maile prywatne (9/9), podsłuch w salach (6/9).
• Rejestr Ustalonych Niezgodności:
  • NC1 (Niezgodność Duża): Utrzymywanie aktywnych uprawnień w VDR po zakończeniu transakcji i uchybienia w listach Insiderów. Podstawa: art. 18 Rozporządzenia MAR; ISO 27001 A.5.18. Dowód: Zestawienie logów platformy VDR z datą zamknięcia transakcji w rejestrze spraw.
  • NC2 (Niezgodność Mała): Brak wymuszenia reguł DLP blokujących transfery plików do domen konsumenckich. Podstawa: ISO 27001 A.8.12. Dowód: Pomyślna próba wysłania testowego pliku z oznaczeniem "Poufne" na skrzynkę Gmail.
  • OFI (Szansa na poprawę): Brak regularnych przeglądów obecności nieautoryzowanych urządzeń radiowych (kontrinwigilacja) w salach zarządu.
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Konta VDR i listy MAR):
    • Analiza 5 Why: Dlaczego konta nie zostały zablokowane? -> Bo koordynator transakcji nie wysłał zlecenia zamknięcia pokoju VDR. Dlaczego nie wysłał? -> Bo procedura zamykania sprawy nie miała obowiązkowego punktu checklisty w systemie ERP. Dlaczego nie miała? -> Dział IT i Dział Praktyki Transakcyjnej działały w silosach organizacyjnych. Przyczyna źródłowa (Root Cause): Brak zautomatyzowanego procesu Offboardingu projektowego integrującego system zarządzania kancelarią z uprawnieniami VDR i listami MAR.
    • Działanie naprawcze: Wdrożenie zautomatyzowanego modułu "Project Close" blokującego dostęp do VDR z chwilą ogłoszenia komunikatu ESPI/EBI; aktualizacja wzorów list osób mających dostęp do informacji poufnych z wymogiem czasu UTC; wdrożenie rygorystycznych reguł Microsoft Purview DLP.
    • Właściciel: Oficer Compliance we współpracy z Kierownikiem Działu IT.
    • Termin: 14 dni na reguły DLP i procedurę; 45 dni na automatyzację z systemem ERP.
• Harmonogram wielostrumieniowy audytu (3,5 dnia roboczego):
  • Dzień 1: Spotkanie otwierające z Partnerami, przegląd procedur MAR i polityki ochrony tajemnicy zawodowej, audyt konfiguracji M365 i konsoli Intune.
  • Dzień 2 (równolegle): Strumień A (Audytor 2) - inspekcja 15 laptopów, testy reguł DLP, audyt platform VDR; Strumień B (Audytor 3) - audyt list Insiderów i procedur compliance.
  • Dzień 3: Audyt laboratorium informatyki śledczej (łańcuch dowodowy Chain of Custody) oraz inspekcja fizyczna sal konferencyjnych i strefy spotkań.
  • Dzień 4 (pół dnia): Triangulacja dowodów, kwalifikacja ustaleń, formalne spotkanie zamykające z Partnerami Zarządzającymi.

C. Analiza zalet i wad planu:

• Zalety: Wykluczenie ryzyka sankcji ze strony KNF i organów europejskich; ochrona najcenniejszego aktywa kancelarii – reputacji rynkowej; nowoczesne podejście łączące rygory prawne z audytem technologicznym.
• Wady i trudności: Wysoki koszt zakupu zaawansowanych licencji Microsoft Purview Information Protection; konieczność bezwzględnego zdyscyplinowania partnerów kancelarii w zakresie korzystania z narzędzi służbowych.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 596/2014 z dnia 16 kwietnia 2014 r. w sprawie nadużyć na rynku (Rozporządzenie MAR) - w szczególności art. 7, 17, 18.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania.
• Ustawa z dnia 29 lipca 2005 r. o obrocie instrumentami finansowymi (Dz.U. z 2023 r. poz. 646).
• Europejski Urząd Nadzoru Giełd i Papierów Wartościowych (ESMA): "Wytyczne dotyczące rozporządzenia w sprawie nadużyć na rynku", Paryż.
• NIST Special Publication 800-88 Rev. 1: "Guidelines for Media Sanitization".

• U1 Student umie zaplanować zaawansowany audyt ISMS w instytucji podlegającej rygorom rynku kapitałowego.
• U2 Student bezbłędnie klasyfikuje niezgodności dotyczące informacji cenotwórczych MAR i tajemnic zawodowych (NC1/NC2/OFI).
• U3 Student przeprowadza szacowanie ryzyka w obszarze insider tradingu w matrycy 3x3.
• U4 Student konstruuje plan CAP oparty na analizie 5 Why dla kancelarii korporacyjnej.
• W1W3 Student dogłębnie zna wymogi Rozporządzenia MAR i standardów etyki zawodowej.
• K1K3 Student zachowuje najwyższe standardy poufności, bezstronności i odpowiedzialności zawodowej.

Celem zadania na ocenę 4.0 jest opanowanie umiejętności zaprojektowania zaawansowanego planu audytu ISMS w przedsiębiorstwie produkcyjnym sektora motoryzacyjnego (Dostawca Tier-1) przygotowującym się do certyfikacji według standardu TISAX (Trusted Information Security Assessment Exchange) na najwyższym poziomie wiarygodności Assessment Level 3 (AL 3 - bardzo wysoki stopień ochrony prototypów i części tajnych). Zadanie kładzie szczególny nacisk na wielostrumieniową alokację zespołu audytowego (równoległe badanie cyberbezpieczeństwa, ochrony fizycznej i łańcucha dostaw), weryfikację transferów wielkich plików projektowych CAD/CAM/CATIA, szacowanie ryzyka szpiegostwa przemysłowego w matrycy 3x3, gradację niezgodności (NC1/NC2/OFI) oraz opracowanie Planu Działań Korygujących (CAP).

• U1 Opracowanie zintegrowanego planu audytu ISMS spełniającego rygory certyfikacji TISAX AL 3.
• U2 Formułowanie i klasyfikacja uchybień w oparciu o katalog wymagań motoryzacyjnych VDA ISA.
• U3 Przeprowadzenie analizy ryzyka kradzieży tożsamości cyfrowej pojazdów autonomicznych i prototypów.
• U4 Opracowanie Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych (Root Cause).
• W1 Ochrona tajemnicy przedsiębiorstwa, własności przemysłowej i know-how koncernów motoryzacyjnych.
• W2W3 Wymagania normy ISO/IEC 27001:2022, standardu VDA ISA / TISAX oraz wytyczne audytowe ISO 19011.
• K1K2 Zdolność do koordynacji prac w wielodyscyplinarnym zespole audytorskim pod presją rygorystycznych wymogów OEM.
• Treści programowe: Wyk2 (Zespół audytowy i wielostrumieniowość), Wyk3 (Łańcuch dostaw ISO 27001), Wyk5 (Risk-based audit), Wyk7 (Niezgodności i CAP).

Fabryka "Silesia AutoTech Solutions Sp. z o.o." w Katowickiej Specjalnej Strefie Ekonomicznej produkuje zaawansowane moduły radarowe, sensory LiDAR oraz jednostki sterujące dla pojazdów autonomicznych czołowych marek europejskich. Zakład zatrudnia 680 pracowników (w tym 120 inżynierów w centrum badawczo-rozwojowym R&D).

Struktura techniczno-operacyjna:

• Strefa Prototypów R&D: Dedykowany budynek z laboratoryjnymi liniami montażowymi, tunelami testowymi i stacjami roboczymi CAD/CATIA odciętymi od Internetu.
• Wymiana danych inżynieryjnych: Pliki projektowe z modelami 3D wymieniane są z centralami koncernów w Niemczech i Szwecji za pośrednictwem dedykowanych łącz światłowodowych z wykorzystaniem protokołu OFTP2 (Odette File Transfer Protocol) z certyfikatami sprzętowymi.
• Produkcja seryjna: 16 zautomatyzowanych linii produkcyjnych nadzorowanych przez system MES zintegrowany z zakładowym ERP.

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

• Uchybienia w ochronie fizycznej strefy prototypowej: Kamery monitoringu CCTV w strefie montażu prototypów posiadają martwe strefy obejmujące stanowiska kalibracji sensorów LiDAR; strefa nie posiada śluzy osobowej (ang. mantrap), a drzwi wejściowe są regularnie blokowane klinem przez inżynierów podczas przerw na kawę.
• Zarządzanie tożsamością w strefie CAD: Wykryto, że 5 stacji inżynierskich posiada aktywne uprawnienia do podłączania pamięci USB w celu zgrywania logów z prób drogowych pojazdów (brak kontroli urządzeń końcowych DLP).
• Wymóg kontrahenta: Główny odbiorca niemiecki postawił ultimatum: fabryka musi w ciągu 6 miesięcy uzyskać certyfikat TISAX na poziomie AL 3 z etykietami "Bardzo Wysokie Bezpieczeństwo Informacji" oraz "Ochrona Prototypów", pod rygorem wykluczenia z przetargu na platformę elektryczną o wartości 400 mln EUR.

Zespół audytorów (2-3 studentów) projektuje zaawansowany plan audytu:

• Krok 1 (Wielostrumieniowy podział ról w zespole audytowym):

Student 1 (Audytor Wiodący / Koordynator TISAX): Odpowiada za zarządzanie audytem certyfikacyjnym, relacje z Zarządem i Dyrektorem Jakości, nadzór nad harmonogramem, audyt procedur nadrzędnych ISMS i ładu korporacyjnego.

Student 2 (Audytor Bezpieczeństwa IT, Stacji CAD i Łączności OFTP2): Odpowiada za Strumień Techniczny - audyt stacji inżynierskich, sieci R&D, zabezpieczeń protokołu OFTP2, mechanizmów DLP, zarządzania podatnościami i segmentacji IT/OT.

Student 3 (Audytor Ochrony Fizycznej, Stref Prototypowych i Planu CAP): Odpowiada za Strumień Ochrony Fizycznej i Łańcucha Dostaw - audyt kontroli dostępu do stref prototypów, systemu CCTV, procedur wizyt gości, matrycę ryzyka 3x3, gradację niezgodności i tabelę CAP z analizą 5 Why.

• Krok 2 (Wyznaczenie zakresu i stref bezpieczeństwa):

Zakres: Kompleks fabryczny w Gliwicach (Strefa Ogólna, Strefa Produkcyjna, Strefa R&D i Prototypów o Bardzo Wysokim Stopniu Ochrony), infrastruktura serwerowa, węzły łączności z OEM.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Katalog wymagań VDA ISA v5.1 (moduły: Bezpieczeństwo Informacji, Ochrona Prototypów, Połączenia z Podmiotami Trzecimi), Norma PN-EN ISO/IEC 27001:2022 (kontrole: A.5.19, A.7.1-A.7.4, A.8.12), Ustawa o zwalczaniu nieuczciwej konkurencji (tajemnica przedsiębiorstwa).

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):
  • Ryzyko 1: Kradzież zdjęć lub geometrii 3D prototypu radaru przez nieautoryzowaną osobę w strefie R&D. P=3 (Wysokie), S=3 (Krytyczne - zerwanie kontraktu 400 mln EUR). Ryzyko inherentne: 9/9 (Niedopuszczalne). Kontrola: Montaż śluzy mantrap, usunięcie martwych stref CCTV, zakaz wnoszenia smartfonów. Ryzyko rezydualne: 1/9.
  • Ryzyko 2: Wyniesienie plików CATIA na niezabezpieczonym pendrive. P=3, S=3. Ryzyko inherentne: 9/9. Kontrola: Wymuszenie sprzętowej blokady USB przez oprogramowanie DLP i szyfrowanie plików. Ryzyko rezydualne: 1/9.
  • Ryzyko 3: Przejęcie transmisji OFTP2 przez brak rotacji kluczy kryptograficznych. P=2, S=3. Ryzyko inherentne: 6/9. Kontrola: Wdrożenie modułu HSM do zarządzania certyfikatami Odette. Ryzyko rezydualne: 1/9.
• Krok 5 (Kwalifikacja niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Blokowanie drzwi do strefy prototypów oraz martwe strefy CCTV uniemożliwiające spełnienie wymagań TISAX AL 3 dla modułu Prototype Protection (naruszenie VDA ISA punkt 8 oraz ISO 27001 A.7.2 i A.7.4).
  • NC2 (Niezgodność Mała): Aktywne porty USB na 5 stacjach inżynierskich bez kontroli DLP (naruszenie VDA ISA punkt 5.2.7 i ISO 27001 A.8.12).
  • OFI (Szansa na poprawę): Wdrożenie systemu biometrycznego rozpoznawania naczyń krwionośnych dłoni (PalmSecure) zamiast kart zbliżeniowych RFID w strefie R&D.
• Krok 6 (Konstrukcja Planu CAP z analizą 5 Why):

Zaprojektujcie tabelę CAP z analizą przyczyn źródłowych (dlaczego inżynierowie blokowali drzwi? -> uciążliwe otwieranie kartą przy częstym przechodzeniu między halą a biurem) i rozwiązaniem w postaci śluzy automatycznej.

• Krok 7 (Harmonogram wielostrumieniowy - 4 dni audytu):

Równoległe badanie strefy R&D (Strumień A), ochrony fizycznej (Strumień B) i łańcucha dostaw (Strumień C).

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Rola standardu TISAX na poziomie AL 3 w globalnym łańcuchu dostaw automotive (Student 1).
• Wielostrumieniowa alokacja audytorów i szacowanie ryzyka 3x3 (4 min): Prezentacja podziału kompetencji i matrycy ryzyka prototypów (Student 1 i 3).
• Przebieg audytu technicznego CAD/OFTP2 i ochrony strefy R&D (4 min): Dowody uchybień w CCTV, śluzach i portach USB (Student 2 i 3).
• Rejestr niezgodności NC1/NC2/OFI oraz Plan Działań Korygujących CAP (3 min): Analiza 5 Why i harmonogram dostosowania fabryki do audytu TISAX (Student 3).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania komisji dotyczące specyfiki kryteriów VDA ISA (cały zespół).

Raport seminaryjny (8-12 stron maszynopisu) musi obejmować:

A. Kontekst przemysłu motoryzacyjnego i wymagania certyfikacyjne TISAX AL 3.

B. Wzorcowy Plan Audytu ISMS / TISAX w Silesia AutoTech Solutions:

• Metryka: Zleceniodawca (Zarząd Silesia AutoTech Solutions), Zespół: 3 wyspecjalizowanych audytorów, Czas: 4 dni robocze.
• Cel nadrzędny: Weryfikacja gotowości zakładu do pomyślnego przejścia akredytowanego audytu TISAX na poziomie wiarygodności AL 3.
• Zakres audytu: Budynek R&D, strefa prototypów, stacje inżynierskie CATIA, węzeł telekomunikacyjny OFTP2, hale produkcyjne, ochrona obwodowa fabryki.
• Matryca szacowania ryzyka (3x3):
  • Szczegółowe zestawienie ryzyk: Kradzież geometrii prototypu (9/9), wyciek plików na USB (9/9), kompromitacja transmisji OFTP2 (6/9).
• Rejestr Ustalonych Niezgodności:
  • NC1 (Niezgodność Duża): Blokowanie drzwi do strefy prototypów oraz martwe strefy w systemie CCTV strefy R&D. Podstawa: VDA ISA moduł Prototype Protection; ISO 27001 A.7.2, A.7.4. Dowód: Nagrania z monitoringu z 7 dni oraz bezpośrednia obserwacja audytora.
  • NC2 (Niezgodność Mała): Aktywne porty USB na stacjach inżynierskich bez kontroli i szyfrowania DLP. Podstawa: VDA ISA punkt 5.2.7; ISO 27001 A.8.12. Dowód: Zrzut rejestru systemu Windows na stacjach inżynierskich w R&D.
  • OFI (Szansa na poprawę): Wdrożenie znakowania wodnego (cyfrowy watermark) w plikach projektowych 3D generowanych w systemie CAD.
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Ochrona fizyczna strefy prototypów):
    • Analiza 5 Why: Dlaczego drzwi były blokowane klinem? -> Bo inżynierowie przenosili ciężkie prototypy i musieli za każdym razem odkładać części, by przyłożyć kartę. Dlaczego nie ma automatycznych drzwi? -> Bo zainstalowano najtańsze drzwi jednoskrzydłowe bez automatyki. Dlaczego takie wybrano? -> Dział Inwestycji ciął koszty modernizacji bez analizy wymagań TISAX AL 3. Przyczyna źródłowa (Root Cause): Brak uwzględnienia wytycznych ochrony prototypów TISAX na etapie projektowania infrastruktury budowlanej centrum badawczego.
    • Działanie naprawcze: Montaż automatycznej śluzy dwudrzwiowej (mantrap) z bezdotykowymi czytnikami i czujnikiem wagi; rozbudowa systemu CCTV o 6 kamer o wysokiej rozdzielczości eliminujących martwe punkty; natychmiastowe usunięcie klinów i wprowadzenie alarmu dźwiękowego przy otwarciu drzwi dłuższym niż 15 sekund.
    • Właściciel: Dyrektor Zakładu we współpracy z Kierownikiem Ochrony Obiektu i Szefem R&D.
    • Termin: 7 dni na usunięcie klinów i alarm; 45 dni na śluzę mantrap i montaż kamer.
• Harmonogram wielostrumieniowy audytu (4 dni robocze):
  • Dzień 1: Spotkanie otwierające z Zarządem i Dyrekcją R&D; audyt ładu korporacyjnego ISMS i procedur TISAX.
  • Dzień 2 (strumienie równoległe):
    • Strumień A (Audytor 2): Audyt stacji inżynierskich CATIA, serwerów plików CAD, blokad USB i łączności OFTP2.
    • Strumień B (Audytor 3): Audyt ochrony fizycznej strefy prototypów, inspekcja ogrodzenia, portierni, śluz i monitoringu CCTV.
  • Dzień 3 (strumienie równoległe):
    • Strumień A (Audytor 2): Audyt sieci przemysłowej MES/PLC na halach produkcyjnych.
    • Strumień B (Audytor 3): Audyt łańcucha poddostawców komponentów, umów poufności (NDA) i procedur utylizacji prototypów złomowanych.
  • Dzień 4: Triangulacja dowodów ze wszystkich strumieni, narada zespołu, oficjalne spotkanie zamykające z Zarządem fabryki.

C. Analiza zalet i wad planu:

• Zalety: Kompletne zaadresowanie rygorystycznych kryteriów TISAX AL 3; wyeliminowanie ryzyka zerwania strategicznego kontraktu motoryzacyjnego; wysoka sprawność dzięki równoległym strumieniom audytowym.
• Wady: Znaczny koszt inwestycji w infrastrukturę budowlaną i śluzy osobowe; konieczność rygorystycznego egzekwowania zakazu wnoszenia telefonów komórkowych przez kadrę inżynierską.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Verband der Automobilindustrie (VDA): "Information Security Assessment (VDA ISA) Catalog Version 5.1", Berlin 2023.
• ENX Association: "TISAX Participant Handbook v2.4", 2023.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania (punkt 5.5: Przypisywanie zadań zespołowi audytującemu).
• Ustawa z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji (Dz.U. z 2022 r. poz. 1233) - art. 11.
• Odette International: "OFTP2 (Odette File Transfer Protocol 2) Recommendation".

• U1 Student umie zaplanować wielostrumieniowy audyt ISMS spełniający wymagania standardu TISAX AL 3.
• U2 Student bezbłędnie klasyfikuje uchybienia w oparciu o katalog VDA ISA i normę ISO 27001.
• U3 Student przeprowadza szacowanie ryzyka szpiegostwa przemysłowego i kradzieży prototypów w matrycy 3x3.
• U4 Student przygotowuje profesjonalny plan CAP z analizą 5 Why dla przedsiębiorstwa produkcyjnego.
• W1W2 Student zna specyfikę normy ISO 27001 i wymagania sektora motoryzacyjnego TISAX.
• K1K2 Student wykazuje umiejętność kierowania pracą wielodyscyplinarnego zespołu audytorów w przemyśle.

Celem zadania na ocenę 4.0 jest opanowanie umiejętności zaprojektowania zaawansowanego planu audytu ISMS w międzynarodowym Centrum Usług Wspólnych (Business Process Outsourcing / Shared Services Center - BPO/SSC) pełniącym rolę podmiotu przetwarzającego (procesora wg art. 28 RODO) na rzecz 60 globalnych korporacji. Zadanie stawia wysokie wymagania metodyczne w zakresie: badania logicznej i fizycznej separacji danych klientów w architekturze wielodostępnej (multitenancy), weryfikacji legalności i bezpieczeństwa transferów danych osobowych poza Europejski Obszar Gospodarczy (Standardowe Klauzule Umowne - SCC), audytu zarządzania dostępem uprzywilejowanym (PAM) przy wysokiej rotacji kadrowej, triangulacji procedur Offboardingu, szacowania ryzyka 3x3, gradacji niezgodności (NC1/NC2/OFI) oraz opracowania Planu CAP.

• U1 Opracowanie zaawansowanego planu audytu ISMS u globalnego dostawcy usług BPO/SSC.
• U2 Poprawna identyfikacja i klasyfikacja uchybień w zarządzaniu tożsamością uprzywilejowaną i transferami transgranicznymi.
• U3 Przeprowadzenie analizy ryzyka nieuprawnionego dostępu do danych korporacyjnych i naruszenia przepisów RODO.
• U4 Opracowanie profesjonalnego Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych.
• W1W3 Dogłębna znajomość art. 28, 44-49 RODO (transfery do państw trzecich, wyrok Schrems II, SCC), Kodeksu pracy i regulacji o ochronie tajemnicy płacowej.
• W2 Norma PN-EN ISO/IEC 27001:2022 (szczególnie Załącznik A: A.5.15, A.8.2, A.8.11, A.8.12), wytyczne ISO 19011 i ISO/IEC 27701 (zarządzanie informacjami o prywatności).
• K1K2K3 Profesjonalizm audytorski, bezstronność i odporność na presję korporacyjną w środowisku międzynarodowym.
• Treści programowe: Wyk2 (Zasady audytowania), Wyk3 (Kontrole dostępowe ISO 27001), Wyk4 (RODO i transfery poza EOG), Wyk5 (Risk-based audit), Wyk7 (Niezgodności i CAP).

Spółka "Global Corporate Services Poland Sp. z o.o." prowadzi wielkie Centrum Usług Wspólnych w Krakowie i Wrocławiu, zatrudniające 1 800 specjalistów. Centrum przetwarza płace, rozliczenia podatkowe, rekrutacje i operacje finansowe dla 60 międzynarodowych koncernów z branży bankowej, technologicznej i farmaceutycznej. Baza obejmuje dane ponad 120 000 pracowników klientów z Europy, Ameryki Północnej i Azji.

Infrastruktura techniczna i model operacyjny:

• Systemy kadrowo-płacowe (SAP SuccessFactors, Workday, zintegrowane bazy Oracle) hostowane w chmurze hybrydowej (centrum danych w Warszawie oraz w Singapurze na potrzeby operacji azjatyckich).
• Rotacja kadr: Z powodu specyfiki branży BPO roczna rotacja pracowników wynosi 28% (ponad 500 procesów zatrudnienia i zwolnienia rocznie).
• Zdalne wsparcie techniczne: Administratorzy baz danych i inżynierowie systemowi z oddziału w Indiach łączą się z polskimi serwerami w celu nocnego utrzymania systemów.

Sygnały ostrzegawcze i złożone uchybienia ujawnione przed audytem:

• Naruszenia w transferach transgranicznych (art. 44-49 RODO): Dane płacowe i numery ubezpieczeń społecznych pracowników z UE były przesyłane do zespołu analitycznego w Indiach bez wdrożenia zaktualizowanych Standardowych Klauzul Umownych (SCC z 2021 r.) oraz bez przeprowadzenia Oceny Skutków Transferu (Transfer Impact Assessment - TIA).
• Uchybienia w systemie PAM i procedurach Offboardingu: Wykryto 42 konta administracyjne o uprawnieniach "SuperUser" w bazach Oracle, które należały do pracowników zwolnionych w ciągu ostatnich 9 miesięcy; system zarządzania dostępem uprzywilejowanym PAM (CyberArk) nie obejmował wszystkich serwerów bazodanowych.
• Ryzyko wycieku w architekturze multitenant: W jednym ze skryptów raportujących brakowało klauzuli filtrującej ID klienta (Tenant_ID), co spowodowało wygenerowanie zbiorczego raportu płacowego zawierającego dane dwóch konkurujących ze sobą korporacji.
• Rada Dyrektorów wymaga opracowania planu audytu ISMS, który pozwoli przygotować spółkę do audytów korporacyjnych prowadzonych przez globalnych klientów.

Zespół audytorów (2-3 studentów) projektuje zaawansowany plan audytu:

• Krok 1 (Podział ról i metodyka badania międzynarodowego):

Student 1 (Audytor Wiodący / Koordynator Globalny): Odpowiada za kierowanie audytem, relacje z Zarządem i Global Compliance, procedurę komunikacji w języku polskim i angielskim, zintegrowany harmonogram i protokoły spotkań.

Student 2 (Audytor Architektury Multitenant, Chmury i Systemów PAM): Planuje audyt separacji baz Oracle/SAP, konfiguracji bramy PAM (CyberArk), analizy logów uprawnień uprzywilejowanych i szyfrowania transferów danych między Polską a Singapurem/Indiami.

Student 3 (Audytor Zgodności Transgranicznej RODO, Ryzyka i Planu CAP): Opracowuje matrycę ryzyka 3x3, bada legalność transferów poza EOG (klauzule SCC, oceny TIA), triangulację procedur Offboardingu, klasyfikację niezgodności NC1/NC2/OFI oraz tabelę CAP z analizą 5 Why.

• Krok 2 (Wyznaczenie zakresu i granic audytu):

Zakres: Centra operacyjne w Krakowie i Wrocławiu, połączenia z centrum danych w Singapurze i zespołem w Indiach, systemy SAP/Workday, bazy Oracle, serwer PAM CyberArk, umowy powierzenia przetwarzania danych ze wszystkimi 60 klientami.

• Krok 3 (Ustalenie kryteriów audytowych):

Kryteria: Norma PN-EN ISO/IEC 27001:2022 (kontrole: A.5.15, A.5.18, A.6.5, A.8.2, A.8.11), Rozporządzenie RODO (art. 28, art. 32, Rozdział V: art. 44-49), wytyczne Europejskiej Rady Ochrony Danych (EDPB) 01/2020 w sprawie transferów po wyroku Schrems II.

• Krok 4 (Szacowanie ryzyka w matrycy 3x3):
  • Ryzyko 1: Nielegalny transfer danych pracowników do Indii bez aktualnych SCC i TIA skutkujący zablokowaniem transferu przez Prezesa UODO i karą do 20 mln EUR. P=3 (Wysokie), S=3 (Krytyczne). Ryzyko inherentne: 9/9 (Niedopuszczalne). Kontrola: Wdrożenie zaktualizowanych SCC 2021/914, audyt bezpieczeństwa w Indiach, szyfrowanie end-to-end z kluczem w UE. Ryzyko rezydualne: 2/9.
  • Ryzyko 2: Nieautoryzowany wgląd lub kradzież baz płacowych przez nieusunięte konta SuperUser w systemie PAM. P=3, S=3. Ryzyko inherentne: 9/9. Kontrola: Pełna integracja CyberArk ze wszystkimi bazami i automatyczna blokada kont po rozwiązaniu umowy. Ryzyko rezydualne: 1/9.
  • Ryzyko 3: Pomieszanie danych klientów w architekturze multitenant. P=2, S=3. Ryzyko inherentne: 6/9. Kontrola: Wdrożenie testów integracyjnych weryfikujących separację Tenant_ID na poziomie zapytań SQL. Ryzyko rezydualne: 1/9.
• Krok 5 (Kwalifikacja niezgodności NC1/NC2/OFI):
  • NC1 (Niezgodność Duża): Przesyłanie danych osobowych poza EOG do Indii z naruszeniem Rozdziału V RODO oraz pozostawienie 42 aktywnych kont SuperUser po odejściu pracowników (naruszenie ISO 27001 A.6.5, A.8.2 oraz art. 44-46 RODO).
  • NC2 (Niezgodność Mała): Brak objęcia 15% serwerów bazodanowych centralnym monitoringiem sesji uprzywilejowanych w systemie CyberArk (naruszenie Załącznika A.8.2).
  • OFI (Szansa na poprawę): Wdrożenie technologii maskowania dynamicznego (Dynamic Data Masking) dla personelu pierwszej linii helpdesk.
• Krok 6 (Plan CAP z analizą przyczyn źródłowych 5 Why):

Zaprojektujcie tabelę CAP z analizą Root Cause dla kont sierocych w PAM i transferów transgranicznych oraz plan naprawczy (14-60 dni).

• Krok 7 (Harmonogram wielostrumieniowy - 4 dni audytu):

Rozpisanie audytu centrów w Krakowie i Wrocławiu, weryfikacji połączeń z Indiami i próbkowania umów korporacyjnych.

Układ 15-minutowego wystąpienia seminaryjnego:

• Wprowadzenie (2 min): Wyzwania prawne i operacyjne globalnego procesora BPO/SSC w świetle RODO i ISO 27001 (Student 1).
• Architektura multitenant, transfery transgraniczne i matryca ryzyka 3x3 (4 min): Prezentacja szacowania ryzyka transferów poza EOG i wyroku Schrems II (Student 3).
• Przebieg audytu technicznego systemów PAM, baz Oracle i triangulacji Offboardingu (4 min): Przedstawienie dowodów nieodebranych uprawnień (Student 2).
• Kwalifikacja ustaleń (NC1/NC2/OFI) oraz Plan Działań Korygujących CAP (3 min): Analiza 5 Why i plan wdrożenia klauzul SCC i automatyzacji PAM (Student 3 i 1).
• Podsumowanie i obrona koncepcji (2 min): Odpowiedzi na pytania komisji o ryzyka kontraktowe i kary umowne z klientami (cały zespół).

Raport składany na zaliczenie (8-12 stron znormalizowanego maszynopisu) musi obejmować:

A. Kontekst biznesowy globalnego outsourcingu procesów biznesowych i profil ryzyka procesora.

B. Wzorcowy Plan Audytu ISMS w Global Corporate Services Poland:

• Metryka: Zleceniodawca (Zarząd Spółki), Zespół audytorów (3 osoby), Czas: 4 dni robocze.
• Cel nadrzędny: Ocena skuteczności wdrożonych mechanizmów kontroli ISMS w zakresie ochrony danych powierzonych przez klientów, bezpieczeństwa architektury multitenant oraz transferów transgranicznych zgodnie z ISO/IEC 27001:2022 i RODO.
• Zakres: Centra w Krakowie i Wrocławiu, serwery w Warszawie i Singapurze, połączenia z Indiami, systemy SAP/Workday, bazy Oracle, brama CyberArk PAM, 60 umów powierzenia DPA.
• Matryca szacowania ryzyka (3x3):
  • Szczegółowe zestawienie ryzyk: Nielegalny transfer poza EOG (9/9), nieusunięte konta SuperUser (9/9), naruszenie separacji klientów w SQL (6/9).
• Rejestr Ustalonych Niezgodności:
  • NC1 (Niezgodność Duża): Transfer danych do Indii bez zaktualizowanych Standardowych Klauzul Umownych i TIA oraz obecność 42 nieaktywnych kont SuperUser w bazach danych. Podstawa: art. 44, 46 RODO; ISO 27001 A.6.5, A.8.2. Dowód: Brak dokumentacji TIA w Dziale Prawnym oraz logi uprawnień z bazy Oracle zestawione z listą zwolnionych pracowników.
  • NC2 (Niezgodność Mała): Częściowy brak objęcia serwerów bazodanowych monitoringiem w systemie PAM CyberArk. Podstawa: ISO 27001 A.8.2. Dowód: Inwentaryzacja agentów PAM w środowisku produkcyjnym.
  • OFI (Szansa na poprawę): Brak wdrożenia zautomatyzowanego narzędzia do ciągłego audytu zgodności konfiguracji chmurowej (Cloud Security Posture Management - CSPM).
• Plan Działań Korygujących (CAP) - Analiza 5 Why:
  • Dla Ustalenia NC1 (Transfer do Indii i konta SuperUser):
    • Analiza 5 Why: Dlaczego nie podpisano nowych SCC? -> Bo dział prawny centrali w Londynie nie zakończył przeglądu wzorców po wyroku Schrems II. Dlaczego nie wstrzymano transferu? -> Bo zatrzymanie nocnego wsparcia z Indii sparaliżowałoby obsługę klientów. Przyczyna źródłowa (Root Cause): Brak lokalnego nadzoru compliance nad transferami transgranicznymi i przedkładanie ciągłości operacyjnej nad zgodność z prawem ochrony danych.
    • Działanie naprawcze: Natychmiastowe wdrożenie Standardowych Klauzul Umownych UE 2021/914 wraz z Oceną Skutków Transferu (TIA); wdrożenie szyfrowania danych w spoczynku i tranzycie z zarządzaniem kluczami wyłącznie na terenie UE; natychmiastowe zablokowanie 42 kont SuperUser i wymuszenie logowania do baz wyłącznie przez bramę PAM z MFA.
    • Właściciel: Dyrektor Prawny i Compliance we współpracy z Głównym Architektem Bezpieczeństwa IT.
    • Termin: 7 dni na blokadę kont i wymuszenie PAM; 30 dni na formalizację SCC i TIA.
• Harmonogram wielostrumieniowy audytu (4 dni robocze):
  • Dzień 1: Spotkanie otwierające z Zarządem i Global Compliance, audyt ładu ISMS i rejestru umów DPA ze wszystkimi 60 klientami.
  • Dzień 2 (strumienie równoległe):
    • Strumień A (Audytor 2): Audyt techniczny separacji multitenant w bazach Oracle/SAP oraz konfiguracji serwera PAM CyberArk.
    • Strumień B (Audytor 3): Audyt transferów poza EOG, przegląd klauzul umownych z podmiotami w Indiach i Singapurze, weryfikacja procedur TIA.
  • Dzień 3 (strumienie równoległe):
    • Strumień A (Audytor 2): Triangulacja procedury Offboardingu - konfrontacja ewidencji zwolnień Działu HR z logami Active Directory, SAP i bazy Oracle.
    • Strumień B (Audytor 3): Audyt procedur reagowania na incydenty bezpieczeństwa i zgłaszania naruszeń do klientów (art. 33 RODO).
  • Dzień 4: Triangulacja dowodów ze wszystkich strumieni, narada zespołu, oficjalne spotkanie zamykające z Zarządem spółki.

C. Analiza zalet i wad przyjętej koncepcji:

• Zalety: Wyeliminowanie ryzyka gigantycznych kar finansowych za nielegalny transfer danych transgranicznych; zabezpieczenie przed roszczeniami odszkodowawczymi globalnych korporacji; przywrócenie pełnej kontroli nad uprawnieniami uprzywilejowanymi w systemie PAM.
• Wady i trudności: Złożoność prawna procedur TIA wymagająca analizy prawodawstwa państw trzecich (Indie); koszty rozbudowy licencji CyberArk PAM na wszystkie instancje bazodanowe.

Skala szacowania ryzyka (matryca 3x3): Prawdopodobieństwo (P): 1 – niskie, 2 – średnie, 3 – wysokie. Skutek (S): 1 – niski, 2 – poważny, 3 – krytyczny. Poziom ryzyka to iloczyn P x S (1-9). Wynik 6-9 oznacza strefę wysoką / niedopuszczalną, 3-4 strefę średnią, a 1-2 ryzyko akceptowalne. Tabele poniżej zawierają przykładowe karty ryzyka dla kluczowych aktywów jednostki (ryzyko inherentne przed zabezpieczeniami oraz ryzyko rezydualne po mitygacji).

Rejestr ustaleń audytowych z formalną gradacją: NC1 – Niezgodność Duża, NC2 – Niezgodność Mała, OFI – Szansa na poprawę. Każde ustalenie zawiera dowód audytowy (triangulacja źródeł dowodowych).

Plan Działań Korygujących (CAP) zawiera numer ustalenia, kwalifikację, analizę przyczyny źródłowej (metoda 5 Why), działanie naprawcze, właściciela oraz harmonogram realizacji (7-120 dni).

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - w szczególności art. 28, art. 32 oraz Rozdział V (art. 44-49).
• Decyzja wykonawcza Komisji (UE) 2021/914 z dnia 4 czerwca 2021 r. w sprawie standardowych klauzul umownych dotyczących przekazywania danych osobowych do państw trzecich.
• Europejska Rada Ochrony Danych (EDPB): "Zalecenia 01/2020 w sprawie środków uzupełniających narzędzia przekazywania w celu zapewnienia zgodności z unijnym poziomem ochrony danych osobowych", Bruksela.
• Norma PN-EN ISO/IEC 27001:2022 - Systemy zarządzania bezpieczeństwem informacji.
• Norma PN-EN ISO/IEC 27701:2021 - Rozszerzenie ISO/IEC 27001 i ISO/IEC 27002 o zarządzanie informacjami o prywatności - Wymagania i wytyczne.
• Norma PN-EN ISO 19011:2018 - Wytyczne dotyczące audytowania systemów zarządzania.

• U1 Student konstruuje zaawansowany plan audytu ISMS u globalnego procesora biznesowego.
• U2 Student bezbłędnie klasyfikuje uchybienia w obszarze transferów transgranicznych i uprawnień uprzywilejowanych (NC1/NC2/OFI).
• U3 Student przeprowadza szacowanie ryzyka w relacjach B2B i multitenancy w matrycy 3x3.
• U4 Student przygotowuje profesjonalny plan CAP z analizą 5 Why dla środowiska korporacyjnego.
• W1W3 Student wykazuje dogłębną znajomość prawa europejskiego w zakresie transferów danych poza EOG (Schrems II, SCC).
• K1K2 Student prezentuje dojrzałą postawę zawodową i etyczną niezbędną w międzynarodowym audycie cyberbezpieczeństwa.