Zestaw 10 zaawansowanych zadań audytowych weryfikujących dojrzałość procesów Change Management, CI/CD oraz zmian awaryjnych pod kątem norm ISO 27001 i DORA. Zadania obejmują matrycę ryzyka 3×3, kwalifikację niezgodności NC1/NC2/OFI, analizę przyczyn 5 Why oraz plan CAP z terminami 14–90 dni. Raport końcowy (8–12 stron) podlega obronie seminaryjnej.
Audyt bezpieczeństwa informacji – Laboratorium 6 (kod Lab6): Audyt Change Management (Zarządzanie Zmianą w bezpieczeństwie informacji, systemach teleinformatycznych i aplikacjach) – poziom oceny 4.0. Kierunek: Informatyka i ekonometria, specjalność Bezpieczeństwo informacji, studia pierwszego stopnia (PRK 6), semestr 7, profil praktyczny. Wymiar: wykład 15 godz., laboratorium 24 godz., 5 pkt ECTS.
Zgodnie z sylabusem przedmiotu zaliczenie zadania laboratoryjnego na ocenę 4.0 (dobrą) wymaga wyczerpującego i precyzyjnego przeprowadzenia zaawansowanego audytu procesu zarządzania zmianami (Change Management) w organizacji o złożonej strukturze procesowej, technologicznej i regulacyjnej. Student musi: (1) zidentyfikować luki i uchybienia w procesie wdrożeniowym – w tym w procedurach zmian awaryjnych (Emergency Change), regulaminach komitetów CAB/ECAB, separacji środowisk DEV/TEST/STAGE/PROD, potokach CI/CD, bazie konfiguracji CMDB, planach wycofania zmian, testach akceptacyjnych UAT, nadzorze nad zmianami u dostawców chmurowych oraz oknach serwisowych; (2) dokonać ich profesjonalnej gradacji na Niezgodności Duże (NC1), Niezgodności Małe (NC2) i Szanse na poprawę (OFI) z precyzyjną referencją do normy PN-EN ISO/IEC 27001:2022 i aktów prawnych właściwych dla sektora (art. 25 i 32 RODO, par. 20 KRI, ustawa o KSC / dyrektywa NIS2, rozporządzenie DORA, Rekomendacja D i M KNF, PCI DSS v4.0, IEC 62443); (3) przeprowadzić analizę ryzyka audytowego z użyciem matrycy prawdopodobieństwa i skutku 3x3 (ryzyko inherentne i rezydualne); (4) zrealizować procedurę dochodzenia przyczyn źródłowych uchybień metodą 5 Why (Root Cause Analysis); (5) skonstruować kompletny i wykonalny Plan Działań Korygujących (CAP) z przypisaniem właścicieli biznesowych, mierzalnych wskaźników sukcesu (KPI) i terminów realizacji (14-90 dni).
Zadania realizowane są przez zespoły 2–3 osobowe wcielające się w profesjonalną kadrę audytorsko-inżynierską. Efektem prac jest raport seminaryjny oraz ustna obrona koncepcji przed komisją laboratoryjną. Ujednolicony podział ról analityczno-audytowych:
Raport seminaryjny w formacie PDF (objętość 8–12 stron znormalizowanego maszynopisu A4) zawierający stronę tytułową (nazwa uczelni, wydział, kierunek, nazwa przedmiotu, kod Lab6, numer i pełny tytuł zadania, skład zespołu z przydzielonymi rolami analitycznymi) oraz obowiązkowe rozdziały merytoryczne: wprowadzenie i charakterystyka badanej organizacji (kontekst prawno-regulacyjny i technologiczny środowiska Change Management), szczegółowa diagnoza stanu zastałego i wykaz zidentyfikowanych luk w procesach wdrożeniowych, matryca analizy ryzyka 3x3 (ryzyko inherentne i rezydualne), formalne karty niezgodności w gradacji NC1/NC2/OFI wraz z referencją do normy ISO/IEC 27001:2022 i przepisów prawa, protokół analizy przyczyn źródłowych metodą 5 Why dla kluczowego uchybienia krytycznego, Plan Działań Korygujących (CAP) w ujęciu tabelarycznym z właścicielem biznesowym, wskaźnikiem KPI i terminem realizacji (14-90 dni), projekt docelowej procedury zarządzania zmianą (regulamin CAB/ECAB, procedura Emergency Change, pierścienie wdrożeniowe, plan rollback, standard testów UAT, polityka patchingu CMDB) oraz analizę wad, zalet, ryzyk wdrożeniowych i bilansu kosztów przyjętego rozwiązania, a także wykaz źródeł normatywnych, prawnych i literaturowych. Raport przekazywany jest prowadzącemu najpóźniej na 24 godziny przed zajęciami i kończy się ustną obroną – 15-minutowym wystąpieniem zespołowym z prezentacją multimedialną, w którym aktywny udział bierze każdy członek zespołu, oraz odpowiedzią na 3–4 dociekliwe pytania kontrolne prowadzącego (symulującego rolę CISO, Prezesa Zarządu lub Inspektora Nadzoru KNF/UODO) dotyczące uzasadnienia wag w matrycy ryzyka, wykonalności planu CAP oraz reakcji na potencjalne spory interpretacyjne.
Poprawność diagnozy procesu Change Management i konstrukcja matrycy ryzyka 3x3 (25%), prawidłowość formalnej gradacji niezgodności NC1/NC2/OFI i zgodność z kontrolami ISO/IEC 27001 oraz przepisami sektorowymi (30%), jakość Planu Działań Korygujących (CAP) i analizy 5 Why (25%), jakość prezentacji ustnej, profesjonalizm dyskusji i praca zespołowa (20%).
Brak formalnej analizy ryzyka w matrycy 3x3 lub sporządzenie jej powierzchownie, bez wyliczenia ryzyka rezydualnego; brak formalnych kart niezgodności albo pomylenie Niezgodności Dużej (NC1) ze Szansą na doskonalenie (OFI); pozorna analiza 5 Why (zatrzymanie się na objawach technicznych zamiast dotarcia do źródłowej przyczyny w ładzie korporacyjnym i procesach decyzyjnych); przedstawienie Planu CAP bez mierzalnych wskaźników KPI lub z nierealistycznymi terminami; pobieżne opracowanie raportu (poniżej 8 stron maszynopisu); dominacja prezentacji jednego studenta i brak znajomości szczegółów technicznych przez pozostałych członków zespołu; rażące błędy merytoryczne i prawne (np. utożsamianie migawek (snapshotów) z kopiami zapasowymi albo powoływanie się na akt prawny nieobowiązujący).
Zegar odlicza 180 minut i podświetla aktualny etap pracy zespołu oraz odpowiadający mu wiersz tabeli. Rozkład minut jest propozycją organizacji pracy w zespole 2–3 osobowym, a nie sztywnym regulaminem ćwiczeń: kolejność i długość poszczególnych etapów ustala zespół, zachowując łączny czas 180 minut. Opis etapów i podział ról różnią się w każdym studium przypadku.
Zegar nie jest wymagany do realizacji zadań. Służy wyłącznie do podziału 180 minut pracy w zespole.
| Przedział | Etap pracy zespołu | Artefakt wyjściowy | Wiodąca rola |
|---|---|---|---|
| Minuty 00-45 | Rozpoznanie procesu: spis rodzajów zmian, analiza ścieżki zatwierdzania, ustalenie, kto może zatwierdzić zmianę awaryjną i jakie ma to skutki dla środowiska produkcyjnego. | Mapa procesu zmiany, spis rodzajów zmian, zakres przeglądu. | Rola 1 |
| Minuty 45-90 | Diagnoza: przegląd przykładowych zmian, porównanie z procedurą, ocena śladu zatwierdzeń, kontroli w środowisku testowym i możliwości wycofania. | Rejestr ustaleń z gradacją NC1 / NC2 / OFI i wskazaną podstawą normatywną. | Rola 2 |
| Minuty 90-135 | Analiza ryzyka: ocena prawdopodobieństwa i skutku dla zmian poza procedurą, wyznaczenie ryzyka po kontrolach i decyzji o postępowaniu w każdej strefie. | Matryca ryzyka 5 × 5 dla ryzyk związanych ze zmianą i decyzje o postępowaniu. | Rola 3 |
| Minuty 135-180 | Plan działań i obrona: tabela CAP, projekt procedury zmian awaryjnych z ograniczeniami, kryteria wycofania, analiza wad i zalet, redakcja raportu i obrona. | Kompletny raport, tabela CAP, projekt procedury i prezentacja obrony. | Rola 1 i Rola 2 |
Wskaż, który członek zespołu prowadzi każdy etap pracy, i sprawdź kompletność podziału. W triadzie każda z ról 1–3 prowadzi dokładnie jeden etap, natomiast etap 4 (redakcja raportu i obrona) jest prowadzony przez parę ról. W zespole dwuosobowym obowiązaki trzeciej roli realizują wspólnie role 1 i 2.
Rozpoznaje ścieżkę zatwierdzania zmian, rozróżnia zmiany planowe, awaryjne i pilne, sprawdza kompletność wniosków oraz sposób komunikacji wdrożeń.
Analizuje potok dostarczania, automatyczne wdrożenia, separację środowisk, kontrolę wersji i możliwość wycofania zmiany wraz z wpływem na produkcję.
Szacuje ryzyko zmiany poza procedurą, kwalifikuje ustalenia do NC1, NC2 i OFI oraz buduje plan działań korygujących z kryteriami skuteczności.
Wpisz niezgodność w procesie zarządzania zmianą, dobierz prawdopodobieństwo (P) oraz skutek (S) w skali 1-5 i dodaj pozycję do rejestru. Kalkulator wylicza iloczyn P × S, wskazuje strefę ryzyka i aktualizuje statystyki rejestru. Pozycje dodane tutaj są automatycznie zaznaczane w interaktywnej macierzy ryzyka.
| Lp. | Niezgodność w zarządzaniu zmianą | Kategoria niezgodności | P | S | P × S | Strefa | Akcja |
|---|---|---|---|---|---|---|---|
| Rejestr jest pusty. Dodaj pierwszą pozycję zdiagnozowaną w tym laboratorium. | |||||||
Dobierz wartości P i S suwakami albo kliknij komórkę macierzy, aby odczytać poziom ryzyka (P × S). Moduł zawiera trzy dodatkowe suwaki, które pozwalają dopasować skalę do własnej metodologii: granice stref zielonej, żółtej i czerwonej oraz próg akceptacji ryzyka (tolerancję organizacji). Poniżej znajduje się karta stanowiska „Niezgodność w zarządzaniu zmianą”, a gwiazdka oznacza pozycję wprowadzoną wcześniej w interaktywnym kalkulatorze ryzyka.
Ładowanie powiązania z rejestrem…
możliwe raz na rok; zdarza się w innych jednostkach tego samego typu.
poważny przerwanie ciągłości usługi lub naruszenie obowiązku prawnego.
P = 3 (możliwe) × S = 4 (poważny) = 12
Przyjmuje się ryzyko warunkowo. Należy zaplanować proste działanie naprawcze w formule reguły, zakazu lub szkolenia i wskazać jego właściciela w polityce bezpieczeństwa.
Wartości powyżej progu wymagają decyzji kierownika jednostki organizacyjnej, a nie tylko odnotowania w rejestrze zagrożeń.
| Wartość P × S | Strefa | Znaczenie dla decyzji audytowej | Wymagane postępowanie |
|---|---|---|---|
| 1–7 | zielona | Ryzyko akceptowalne.. | Wystarczy odnotować niezgodność w rejestrze ustaleń i uzupełnić opis zmiany przy najbliższej aktualizacji. |
| 8–14 | żółta | Ryzyko warunkowo akceptowalne.. | Uzupełnić rejestr zmian, wskazać osobę zatwierdzającą i wyznaczyć datę kolejnego przeglądu. |
| 15–25 | czerwona | Ryzyko krytyczne, wymagające pilnego działania.. | Nie przyjmować ryzyka: wstrzymać samowolne zmiany do czasu zatwierdzenia, a wdrożenia pilne objąć trybem awaryjnym z pełnym zapisem. |
Wybierz studium przypadku, a pola formularza wypełnią się danymi jednostki (metryka audytowanej jednostki, kluczowe aktywa i podstawy prawne). Generator składa z wpisanych treści szkic raportu z 10 rozdziałami; szkic jest punktem wyjścia do redakcji, nie gotowym tekstem do oddania. Generator nie ocenia ani nie uzupełnia treści merytorycznej: redakcja, uporządkowanie i uzasadnienie zostają po stronie zespołu.
Pola wypełniane automatycznie (metryka audytowanej jednostki, systemy, środowiska i procesy krytyczne, obowiązujące podstawy prawne i normatywne) uzupełniają się po wyborze studium przypadku. Pozostałe rozdziały wpisuje zespół. Po wygenerowaniu szkic trafia również do licznika objętości w sekcji checklista.
Generator prowadzi przez każde ustalenie z rejestru NC1 / NC2 i wymaga od zespołu podania przyczyny źródłowej (metoda 5 Why), działania naprawczego, stanowiska właściciela, terminu z przedziału 14–90 dni oraz mierzalnego kryterium skuteczności. Narzędzie sprawdza kompletność planu i wskazuje typowe błędy: działanie objawowe zamiast naprawiającego źródło, właściciela podanego imieniem zamiast stanowiskiem, brak kryterium skuteczności albo ujęcie szansy na poprawę (OFI) jako niezgodności.
| Lp. | Nr | Kwal. | Ustalony stan | Przyczyna źródłowa | Działanie naprawcze | Właściciel | Termin | Kryterium skuteczności |
|---|
Plan jest pusty. Dodaj ustalenia z rejestru NC1 i NC2, a generator sprawdzi kompletność przyczyn źródłowych, właścicieli, terminów i kryteriów skuteczności.
Checklista ma cztery grupy po pięć punktów: rozpoznanie, diagnoza, projekt i plan. Zaznacz pozycje faktycznie zrealizowane w raporcie, a nie zamierzone. Postęp zapamiętuje się w pamięci przeglądarki. Licznik objętości sprawdza, czy tekst raportu mieści się w wymaganych 8–12 stronach, przy założeniu 300 słów na stronę znormalizowanego maszynopisu A4 (2400–3600 słów).
Krótkie charakterystyki badanych organizacji oraz zagadnień raportowe według sektorów. Wybierz sektor, aby zawęzić listę, i kliknij kartę, aby przejść do właściwego zadania. Kliknięcie nagłówka karty zadania rozwija lub zwija jego pełną treść.
Kliknij nagłówek zadania, aby je rozwinąć lub zwinąć. Przyciski poniżej rozwijają / zwijają wszystkie karty.
Temat: Zaawansowany Audyt Procedury Wdrążania Zmian Awaryjnych (Emergency Change), Kontroli Poprawek w Środowisku Zintegrowanym HIS/RIS/PACS/LINAC, Funkcjonowania Komitetu ECAB, Ryzyko 3X3, Analiza 5 Why i Plan Działań Korygujących (CAP)
Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu procesu zarządzania zmianami awaryjnymi (Emergency Change Management) w wieloprofilowym podmiocie leczniczym o statusie podmiotu kluczowego w rozumieniu dyrektywy NIS2 i ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC). Zadanie wymaga zbadania wieloaplikacyjnego ekosystemu szpitalnego (HIS, RIS, PACS, systemy planowania radioterapii TPS oraz akceleratory liniowe LINAC), zidentyfikowania krytycznych luk w nadzorze nad poprawkami typu hotfix wgrywanymi na żywo, przeprowadzenia matrycowej analizy ryzyka 3x3 w ujęciu inherentnym i rezydualnym, formalnej kwalifikacji uchybień (NC1, NC2, OFI), przeprowadzenia dochodzenia przyczyn źródłowych metodą 5 Why oraz skonstruowania kompleksowego Planu Działań Korygujących (CAP) z przypisaniem mierzalnych wskaźników KPI i terminów realizacji.
Powiązanie z sylabusem i treściami programowymi:
Wojewódzki Szpital Kliniczny i Centrum Onkologii w Białymstoku jest wysokospecjalistycznym kompleksem kliniczno-badawczym dysponującym 950 łóżkami, 24 klinikami stacjonarnymi, w tym Kliniką Onkologii, Radioterapii, Hematologii oraz Szpitalnym Oddziałem Ratunkowym. Szpital hospitalizuje rocznie ponad 70 tysięcy pacjentów i wykonuje 45 tysięcy sesji napromieniania nowotworów za pomocą 5 medycznych akceleratorów liniowych (LINAC).
Stan faktyczny w obszarze zarządzania zmianami w systemach teleinformatycznych:
Dyrektor Szpitala, wobec skandalu medialnego i kontroli Rzecznika Praw Pacjenta oraz Departamentu Cyberbezpieczeństwa Ministerstwa Zdrowia, powołuje zespół audytorów do przeprowadzenia zaawansowanego audytu procedur Emergency Change Management na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu śledczego, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Lead Auditor i Koordynator Zespołu): Odpowiada za relacje z Dyrekcją, ordynatorami i UODO/MZ, badanie ładu korporacyjnego, analizę regulaminu komitetu ECAB, koordynację matrycy ryzyka oraz moderację referatu.
Student 2 (Audytor Techniczny ds. Baz Danych, Integracji HIS/LINAC i Wdrożeń): Analizuje logi Oracle RAC, procedury PL/SQL, architekturę połączeń VPN/PAM, brak migawek pre-migration snapshot, mechanizmy rollbacku oraz projektuje bezpieczny sandbox walidacyjny.
Student 3 (Audytor Zgodności Regulacyjnej RODO/NIS2, Ryzyka i Jakości CAP): Przeprowadza ocenę skutków RODO (art. 32), gradację niezgodności (NC1/NC2/OFI), prowadzi sekwencję 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka dla 4 kluczowych obszarów luki:
Wyliczcie ryzyko inherentne i rezydualne dla:
1. Wdrożenia niesprawdzonej poprawki SQL na bazie produkcyjnej bez testów i bez zgody ECAB (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Braku zweryfikowanego planu wycofania (Rollback Script) i braku snapshotu bazy przed zmianą (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Niekontrolowanego dostępu uprzywilejowanego 'SYSDBA' dla zewnętrznych serwisantów bez rejestracji sesji PAM (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Braku procedury awaryjnego podawania chemioterapii w trybie papierowym (Paper Fallback) podczas przestoju HIS (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności z powołaniem na konkretne punkty normy ISO/IEC 27001:2022 oraz akty prawne:
Dla niezgodności krytycznej (wdrożenie niesprawdzonego skryptu SQL na żywo i paraliż leczenia) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego doszło do paraliżu podawania leków i naświetlań onkologicznych? Ponieważ skrypt serwisanta uszkodził relacje kluczy obcych i procedury składowane bazy HIS.
2. Dlaczego skrypt zawierał krytyczne błędy relacyjne? Ponieważ serwisant nie przetestował go na środowisku testowym ani stagingowym przed uruchomieniem.
3. Dlaczego zmiana została uruchomiona na produkcji bez wcześniejszych testów? Ponieważ informatyk dyżurny i serwisant chcieli natychmiast usunąć błąd deadlocka, obchodząc standardową ścieżkę RFC.
4. Dlaczego system pozwolił na ominięcie komitetu ECAB i autoryzacji kierownictwa? Ponieważ w szpitalu procedura Emergency Change nie posiadała technicznych blokad wdrożeniowych ani regulaminu dyżuru decyzyjnego ECAB w trybie 24/7.
5. Jaka jest przyczyna źródłowa (Root Cause)? Brak sformalizowanego i technicznie egzekwowanego ładu zarządzania zmianami awaryjnymi (Emergency Change Governance), brak systemu Privilege Access Management (PAM) ograniczającego prawa serwisantów oraz brak kultury bezpieczeństwa przedkładającej stabilność nad prowizoryczne rozwiązania.
Opracujcie tabelę CAP zawierającą:
Zaprojektujcie schemat blokowy procesu Emergency Change, formularz cyfrowego wniosku RFC z podpisem kwalifikowanym oraz standardową procedurę Post-Implementation Review (PIR) przeprowadzanego w ciągu 48 godzin od zakończenia incydentu.
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Raport seminaryjny na ocenę 4.0 (objętość 8-12 stron A4) musi zawierać:
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
Podczas obrony referatu wykażcie, dlaczego wdrożenie systemu PAM i procedury ECAB eliminuje sytuacje, w których zewnętrzny serwisant podejmuje jednoosobowe, ryzykowne decyzje techniczne w nocy.
Temat: Zaawansowany Audyt Separacji Środowisk DEV/TEST/STAGE/PROD, Anonimizacji i Pseudonimizacji Danych Obywateli w Procesach Testowych Regionalnych E-usług (Sekap/EZD RP), Ryzyko 3X3, Analiza 5 Why i Plan CAP
Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu fizycznej, sieciowej i aplikacyjnej separacji środowisk wielowarstwowych (DEV, TEST, STAGING, PROD) oraz weryfikacji procesów zarządzania danymi testowymi (Test Data Management - TDM) w regionalnej administracji samorządowej. Zadanie koncentruje się na ocenie zgodności z kontrolami ISO/IEC 27001:2022 A.8.31 (Rozdzielenie środowisk) i A.8.33 (Informacje testowe), przepisami RODO (zasada Privacy by Design / Default, art. 25 i art. 32) oraz par. 20 Krajowych Ram Interoperacyjności (KRI). Studenci przeprowadzają matrycową analizę ryzyka 3x3 dla wektorów wycieku danych mieszkańców przez firmy programistyczne, klasyfikują niezgodności (NC1/NC2/OFI), przeprowadzają analizę 5 Why oraz konstruują Plan Działań Korygujących (CAP) wdrażający automatyczną anonimizację i syntetyzację danych testowych.
Powiązanie z sylabusem i treściami programowymi:
Urząd Marszałkowski Województwa Śląskiego wraz ze Śląskim Centrum Społeczeństwa Informacyjnego (ŚCSI) zarządza regionalną platformą e-usług publicznych, systemem Elektronicznego Zarządzania Dokumentacją (EZD RP) oraz bazami beneficjentów funduszy europejskich i dotacji na termomodernizację (program "Czyste Powietrze"). Bazy te obejmują dane ponad 350 tysięcy mieszkańców województwa (numery PESEL, zarobki, stan posiadania nieruchomości, zaświadczenia o dochodach, numery rachunków bankowych).
Stan faktyczny w obszarze rozwoju systemów i zarządzania zmianami:
Marszałek Województwa zleca zaawansowany audyt procedur separacji środowisk, weryfikacji danych testowych i oceny ryzyka naruszenia RODO na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu separacji sieciowej, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Samorządowy i RODO): Bada umowy z konsorcjum IT, klauzule powierzenia danych, uprawnienia IOD, zgodność z wytycznymi UODO i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Sieci, Baz Danych i TDM): Bada reguły firewall, brak separacji VLAN między DEV/TEST a PROD, analizuje schematy baz PostgreSQL, brak narzędzi maskowania danych i projektuje architekturę generowania danych syntetycznych.
Student 3 (Audytor Zgodności Regulacyjnej KRI/ISO, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Masowego wycieku danych wrażliwych 350 tys. mieszkańców z laptopów programistów zewnętrznych (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Przejęcia środowiska produkcyjnego w wyniku ataku na środowisko DEV ze względu na otwarty routing i wspólne hasła (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Nałożenia kary finansowej przez Prezesa UODO za zmianę celu przetwarzania danych bez podstawy prawnej (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Awaryjnego uszkodzenia bazy produkcyjnej przez omyłkowe uruchomienie skryptu testowego z konsoli dewelopera (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (przekazanie produkcyjnej bazy danych do testów) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego rzeczywiste dane 350 tys. mieszkańców znalazły się na laptopach zewnętrznych programistów? Ponieważ architekt ŚCSI przekazał wykonawcy zrzut produkcyjnej bazy danych PostgreSQL.
2. Dlaczego przekazano bazę produkcyjną zamiast danych testowych? Ponieważ urząd nie posiadał bazy danych testowych, a wykonawca zgłosił błędy w integracji modułów.
3. Dlaczego urząd nie posiadał środowiska testowego z danymi syntetycznymi? Ponieważ w budżecie i harmonogramie projektu nie przewidziano zakupu narzędzi ani czasu na wdrożenie Test Data Management.
4. Dlaczego kierownictwo IT zignorowało wymogi bezpieczeństwa danych testowych? Ponieważ w organizacji panowało błędne przekonanie, że podpisanie umowy NDA z wykonawcą zwalnia urząd z konieczności anonimizacji danych.
5. Jaka jest przyczyna źródłowa (Root Cause)? Brak sformalizowanej polityki zarządzania danymi testowymi (TDM Policy), brak procedury Privacy by Design w projektach informatycznych oraz niedostateczny nadzór IOD nad cyklem życia oprogramowania.
Opracujcie tabelę CAP:
Zaprojektujcie Politykę Rozdzielenia Środowisk, procedurę generowania syntetycznych numerów PESEL z poprawną sumą kontrolną oraz matrycę ról w procesie zatwierdzania wdrożeń.
Plan wystąpienia seminaryjnego na ocenę 4.0 (15 minut):
Zawartość raportu seminaryjnego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
Podczas prezentacji wykażcie, dlaczego generowanie danych w pełni syntetycznych jest znacznie bezpieczniejsze i tańsze prawnie niż próby 'zamazywania' czy pseudonimizowania rzeczywistej bazy produkcyjnej.
Temat: Zaawansowany Audyt Komitetu Zarządzania Zmianami (CAB), Matrycy Oceny Ryzyka ICT Wniosków RFC, Automatycznych Bramek Wdrożeniowych Go/No-go oraz Audytu Separacji Ról SOD przy Aktualizacjach Systemu Core Banking, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych kompetencji audytu struktur zarządczych procesu zarządzania zmianami (Change Advisory Board - CAB), weryfikacji wielowymiarowych matryc oceny ryzyka ICT dla wniosków o zmianę (RFC), badania procedur decyzji Go/No-Go oraz egzekwowania rygorystycznego rozdziału obowiązków (Segregation of Duties - SoD) w banku zrzeszającym. Zadanie kładzie szczególny nacisk na spełnienie rygorów Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA - art. 9 i 12), Rekomendacji D i M Komisji Nadzoru Finansowego (KNF) oraz kontroli ISO/IEC 27001:2022 A.8.32 i A.5.3. Studenci przeprowadzają matrycową analizę ryzyka 3x3, klasyfikują uchybienia (NC1/NC2/OFI), realizują dochodzenie 5 Why oraz konstruują Plan Działań Korygujących (CAP) eliminujący patologie samowolnych wdrożeń i konfliktów uprawnień.
Powiązanie z sylabusem i treściami programowymi:
Krajowy Bank Spółdzielczy Zrzeszeniowy S.A. pełni rolę banku zrzeszającego dla 120 lokalnych banków spółdzielczych, realizując centralne rozliczenia finansowe, obsługując węzeł płatności natychmiastowych Express Elixir, dostęp do systemu SWIFT oraz dostarczając zintegrowany system bankowości centralnej (Core Banking - Oracle FlexCube) dla ponad 1,2 miliona klientów końcowych.
Stan faktyczny w obszarze procesu Change Management i komitetu CAB:
Zarząd Banku zleca niezależny audyt śledczy procesu decyzyjnego CAB, kontroli SoD i bramek wdrożeniowych na poziomie oceny 4.0.
Zadanie wymaga zbadania ładu korporacyjnego IT, analizy konfliktu interesów, oceny ryzyka 3x3, gradacji niezgodności, analizy 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Bankowy i DORA): Analizuje strukturę zarządczą banku, protokoły posiedzeń Zarządu i CAB, bada ramy DORA (art. 9 i 12), regulacje KNF i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Systemów Core Banking i SoD): Bada wniosek RFC/2026/089, logi klastra Oracle FlexCube, uprawnienia wdrożeniowe programisty, konflikt ról w Active Directory/GitLab oraz konfigurację bramki Change Gatekeeper.
Student 3 (Audytor Zgodności Regulacyjnej KNF/DORA, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Paraliżu ogólnokrajowych rozliczeń międzybankowych Elixir i utraty płynności zrzeszonych banków (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Wprowadzenia złośliwego lub błędnego kodu na produkcję w wyniku braku rozdziału ról SoD między deweloperem a administratorem wdrożeń (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Sankcji finansowych i nakazu zawieszenia licencji bankowej przez KNF za złamanie rygorów DORA i Rekomendacji D (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Roszczeń odszkodowawczych klientów i utraty reputacji banku zrzeszającego (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (jednoosobowe zatwierdzenie zmiany i ominięcie CAB) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego doszło do 14-godzinnego paraliżu węzła rozliczeń Elixir? Ponieważ wdrożono wersję oprogramowania zawierającą błąd wycieku pamięci w serwerach aplikacji.
2. Dlaczego błąd nie został wykryty przed wdrożeniem? Ponieważ zrezygnowano z przeprowadzenia testów przeciążeniowych i integracyjnych z KIR.
3. Dlaczego zmiana została skierowana na produkcję bez kompletu testów? Ponieważ Dyrektor Rozwoju jednoosobowo zatwierdził wniosek RFC pod presją terminu kwartalnego.
4. Dlaczego system dopuścił jednoosobową autoryzację i brak posiedzenia CAB? Ponieważ w banku komitet CAB funkcjonował w sposób fasadowy, a narzędzia ITSM nie posiadały blokad braku kworum.
5. Jaka jest przyczyna źródłowa (Root Cause)? Wadliwy ład korporacyjny (Governance failure), w którym presja biznesowa przeważała nad zarządzaniem ryzykiem operacyjnym, połączony z brakiem twardego rozdziału ról SoD i brakiem technicznych bramek wdrożeniowych.
Opracujcie tabelę CAP:
Zaprojektujcie regulamin komitetu CAB, matrycę punktacji ryzyka RFC (Risk Scoring Matrix) oraz procedurę awaryjnego wstrzymania wdrożenia (Abort & Rollback Trigger).
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
W referacie skupcie się na wykazaniu, dlaczego rozdzielenie ról programisty i administratora wdrożeń (SoD) jest w bankowości fundamentem bezpieczeństwa, a jego złamanie zawsze traktowane jest jako uchybienie krytyczne.
Temat: Zaawansowany Audyt Zarządzania Zmianami Konfiguracyjnymi i Programowymi w Warstwie OT/SCADA, Stanowisk Testowych Hardware-in-the-loop (HIL), Bezpiecznego Zdalnego Dostępu Serwisowego oraz Procedur Industrial Rollback, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Głównym celem zadania na ocenę 4.0 jest opanowanie zaawansowanej metodyki audytu procesu zarządzania zmianami w środowiskach automatyki przemysłowej (Operational Technology - OT) oraz dyspozytorskich systemach telemetrycznych SCADA w strategicznym przedsiębiorstwie sektora gazowniczego posiadającym status Operatora Usługi Kluczowej (OUK). Zadanie wymaga zbadania specyfiki infrastruktury krytycznej OT (sterowniki PLC, stacje inżynierskie, magistrale polowe Modbus/Profinet, układy nawęglania i tłoczenia biometanu), zidentyfikowania zagrożeń fizyczno-cyfrowych wynikających z niekontrolowanego wgrywania oprogramowania firmware, przeprowadzenia matrycowej analizy ryzyka 3x3 w ujęciu safety i reliability, formalnej gradacji uchybień (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu Działań Korygujących (CAP) wdrażającego stanowiska testowe Hardware-in-the-Loop (HIL) i systemy wersjonowania konfiguracji przemysłowych.
Powiązanie z sylabusem i treściami programowymi:
Polska Grupa Biogazowa i Dystrybucja Gazu S.A. jest operatorem strategicznej sieci dystrybucji biometanu i gazu ziemnego, zarządzającym 14 tłoczniami gazu, 65 stacjami redukcyjno-pomiarowymi oraz zaopatrującym w paliwo gazowe ponad 400 tysięcy odbiorców komunalnych i przemysłowych. Przedsiębiorstwo posiada status Operatora Usługi Kluczowej w rozumieniu Ustawy o KSC.
Stan faktyczny w obszarze zarządzania zmianami w infrastrukturze OT/SCADA:
Zarząd Spółki powołuje zespół audytorów do przeprowadzenia zaawansowanego audytu procesów Change Management w warstwie automatyki OT na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu inżynierskiego, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Infrastruktury Krytycznej i OUK): Analizuje procedury nadrzędne OUK, politykę bezpieczeństwa informacji i automatyki, rygory Ustawy o KSC, umowy serwisowe i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Automatyki Przemysłowej OT/SCADA i Bezpieczeństwa Fizycznego): Bada logi stacji inżynierskiej, kod sterowników PLC, błąd firmware'u modułu Modbus, podatności dostępu LTE, brak systemu wersjonowania kodu i projektuje stanowisko HIL.
Student 3 (Audytor Zgodności ze Standardem IEC 62443, Ryzyka i Jakości CAP): Przeprowadza ocenę ryzyka procesowego w matrycy 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Wybuchu gazu, zniszczenia tłoczni i ofiar śmiertelnych w wyniku błędu w algorytmie PLC wgranym bez testów (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Całkowitego paraliżu telemetrii SCADA i utraty kontroli dyspozytorskiej nad siecią gazową (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Wstrzymania dostaw paliwa do elektrociepłowni i kar finansowych od URE/KSC (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Przejęcia stacji inżynierskich przez cyberprzestępców z powodu niezabezpieczonego modemu LTE (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (niekontrolowane wgranie kodu PLC i rozszczelnienie tłoczni) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego doszło do rozszczelnienia sprężarek i wycieku biometanu? Ponieważ sterownik PLC gwałtownie zablokował zawory regulacyjne, wywołując skok ciśnienia do 78 barów.
2. Dlaczego sterownik zachował się w ten sposób? Ponieważ nowy kod zawierał błąd w algorytmie przeliczania ciśnienia różnicowego.
3. Dlaczego kod z błędem został uruchomiony na pracującym obiekcie? Ponieważ serwisant wgrał go bezpośrednio przez modem LTE bez wcześniejszego przetestowania na symulatorze.
4. Dlaczego serwisant mógł wgrać kod bez autoryzacji dyspozytora? Ponieważ w tłoczni nie wdrożono procedury Industrial Change Management z wymogiem zgody "czterech oczu" i blokady przełącznika kluczykowego na sterowniku.
5. Jaka jest przyczyna źródłowa (Root Cause)? Brak procedur zarządzania zmianami dedykowanych dla środowisk automatyki przemysłowej OT, brak stanowiska Hardware-in-the-Loop do weryfikacji zmian oraz brak świadomości ryzyka fizycznego (safety) u wykonawców zewnętrznych.
Opracujcie tabelę CAP:
Zaprojektujcie Standardową Procedurę Operacyjną (SOP) wgrywania poprawek w warstwie automatyki gazowej oraz matrycę kwalifikacji ryzyka procesowego HAZOP/Change.
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja inżynierska poaudytowa):
C. Analiza zalet i wad proponowanego rozwiązania:
Podczas wystąpienia wykażcie, w jaki sposób brak procedury testów HIL i brak backupu programu sterownika doprowadził do fizycznego rozszczelnienia instalacji gazowej i bezpośredniego zagrożenia wybuchem.
Temat: Zaawansowany Audyt Potoków CI/CD (DevSecOps), Automatycznych Bramek Jakościowych (SAST/DAST/SCA), Ochrony Gałęzi Głównych Kodu oraz Zarządzania Sekretami w Architekturze Mikrousługowej, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych kompetencji audytu nowoczesnych potoków ciągłej integracji i ciągłego wdrażania (Continuous Integration / Continuous Deployment - CI/CD) w metodyce DevSecOps w instytucji płatniczej przetwarzającej dane kartowe w chmurze hybrydowej AWS-Kubernetes. Zadanie skupia się na weryfikacji spełnienia rygorów standardu Payment Card Industry Data Security Standard (PCI DSS v4.0 - wymóg 6), kontroli normy ISO/IEC 27001:2022 A.8.25, A.8.28 i A.8.32 oraz wytycznych NIST SP 800-204. Studenci badają procesy automatyzacji testów bezpieczeństwa (SAST, DAST, SCA), zarządzania sekretami wdrożeniowymi w architekturze mikrousługowej, egzekwowania reguł Branch Protection, przeprowadzają analizę ryzyka 3x3, klasyfikują uchybienia (NC1/NC2/OFI), realizują dochodzenie 5 Why oraz konstruują Plan Działań Korygujących (CAP).
Powiązanie z sylabusem i treściami programowymi:
Pay-Fast Polska S.A. jest licencjonowaną Krajową Instytucją Płatniczą (KIP) nadzorowaną przez KNF, oferującą bramki płatności internetowych dla ponad 5000 sklepów e-commerce i przetwarzającą miesięcznie ponad 4 miliony transakcji bezgotówkowych. Środowisko IT działa w modelu chmury hybrydowej z wykorzystaniem klastrów orkiestracji kontenerów Kubernetes (Amazon EKS) w chmurze AWS oraz baz danych przechowujących numery kart płatniczych (Primary Account Number - PAN) w wydzielonej strefie Cardholder Data Environment (CDE).
Stan faktyczny w obszarze procesu CI/CD i wydań oprogramowania:
Zarząd Pay-Fast S.A., w obliczu groźby utraty certyfikacji PCI DSS i cofnięcia licencji KIP, powołuje zespół audytorów do przeprowadzenia zaawansowanego audytu potoków CI/CD i DevSecOps na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu kodu i potoków CI/CD, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Lead Auditor i Zgodności PCI DSS): Analizuje polityki wytwórcze, standardy PCI DSS v4.0 (wymóg 6), regulacje KIP i nadzoru KNF, procedury zgłaszania incydentów i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Chmury AWS, Kubernetes i DevSecOps): Bada konfigurację GitLab CI/CD, historię commitów, pliki konfiguracyjne, mechanizmy ochrony gałęzi, konfigurację HashiCorp Vault / AWS Secrets Manager oraz projektuje bramki SAST/DAST/SCA.
Student 3 (Audytor Zgodności z Normą ISO 27001, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Masowego wycieku danych kart płatniczych (PAN/CVV2) przez złośliwą bibliotekę w łańcuchu dostaw (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Całkowitego przejęcia klastra produkcyjnego EKS w wyniku kompromitacji zahardkodowanych kluczy AWS IAM (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Cofnięcia certyfikacji PCI DSS i zablokowania procesowania transakcji przez organizacje płatnicze (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Wypchnięcia na produkcję błędu logicznego blokującego rozliczenia sklepów e-commerce (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (wyłączenie bramek bezpieczeństwa i wyciek danych kartowych) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego złośliwy kod kradnący dane kartowe znalazł się na produkcji? Ponieważ w potoku CI/CD wdrożono niezaufaną bibliotekę npm bez weryfikacji bezpieczeństwa.
2. Dlaczego biblioteka nie została zbadana przez skanery SCA? Ponieważ Tech Lead wyłączył w pliku konfiguracyjnym GitLab CI etapy analizy podatności.
3. Dlaczego kierownictwo zespołu wyłączyło skanery bezpieczeństwa? Ponieważ skanery zgłaszały fałszywe alarmy i opóźniały wdrożenia wymagane przez harmonogram sprintu.
4. Dlaczego kod trafił na produkcję bez akceptacji innego inżyniera? Ponieważ wyłączono regułę Branch Protection i zrezygnowano z obowiązkowego procesu Peer Review.
5. Jaka jest przyczyna źródłowa (Root Cause)? Wadliwa kultura organizacyjna przedkładająca tempo wydań nad rygory bezpieczeństwa (brak wdrożenia metodyki DevSecOps), brak centralnego zarządzania sekretami oraz brak twardych, nieprzekraczalnych bramek jakościowych (Quality Gates) w ładzie wytwórczym.
Opracujcie tabelę CAP:
Zaprojektujcie Standard Bezpiecznego Cyklu Wytwarzania Oprogramowania (Secure SDLC Policy), konfigurację potoku GitLab CI z bramkami SonarQube/Trivy oraz procedurę natychmiastowej rotacji skompromitowanych sekretów.
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
Podczas obrony referatu przedstawcie konfigurację pliku CI/CD z twardą bramką blokującą wdrożenie w razie wykrycia sekretów lub podatności – pokażcie, jak automatyzacja zastępuje zawodny czynnik ludzki.
Temat: Zaawansowany Audyt Zarządzania Konfiguracją (CMDB), Wersjonowania w Architekturze Mikroserwisowej oraz Strategii Pierścieni Wdrożeniowych w Procesie Patch Managementu dla Klastrów Państwowych, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu procesu zarządzania konfiguracją (Configuration Management Database - CMDB), wersjonowania oprogramowania oraz strategii pierścieni wdrożeniowych (Deployment Rings / Canary Deployments) w procesie instalacji poprawek bezpieczeństwa (Patch Management) w strategicznych rejestrach państwowych zarządzanych przez instytucję administracji rządowej. Zadanie koncentruje się na weryfikacji zgodności z kontrolami normy ISO/IEC 27001:2022 A.8.8 (Zarządzanie podatnościami), A.8.9 (Zarządzanie konfiguracją) i A.8.32 (Zarządzanie zmianami), przepisami par. 20 ust. 2 pkt 1 i 7 Krajowych Ram Interoperacyjności (KRI) oraz wytycznymi Pełnomocnika Rządu ds. Cyberbezpieczeństwa. Studenci przeprowadzają analizę ryzyka 3x3, klasyfikują uchybienia (NC1/NC2/OFI), realizują dochodzenie 5 Why oraz konstruują Plan Działań Korygujących (CAP).
Powiązanie z sylabusem i treściami programowymi:
Centralny Ośrodek Informatyki (COI) jako instytucja gospodarki budżetowej podległa Ministerstwu Cyfryzacji odpowiada za utrzymanie, rozwój i bezpieczeństwo kluczowych rejestrów państwowych Rzeczypospolitej Polskiej, w tym Systemu Rejestrów Państwowych (SRP - baza PESEL, Rejestr Dowodów Osobistych, Rejestr Stanu Cywilnego), centralnej ewidencji pojazdów i kierowców (CEPIK 2.0) oraz infrastruktury backendowej aplikacji mObywatel, z której korzysta ponad 16 milionów obywateli.
Stan faktyczny w obszarze zarządzania konfiguracją i wdrażania poprawek systemowych:
Minister Cyfryzacji zleca przeprowadzenie niezależnego, zaawansowanego audytu procesu zarządzania konfiguracją, wersjonowania oraz procedur Patch Managementu na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu klastrów chmurowych, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Administracji Rządowej i KRI): Bada strukturę zarządczą COI, wymogi KRI, procedury Pełnomocnika Rządu ds. Cyberbezpieczeństwa, ład korporacyjny w projektach publicznych i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Chmury Rządowej, Klastrów K8s i CMDB): Analizuje konfigurację węzłów, logi błędów OpenSSL, historię wdrożeń Ansible/Terraform, brak bazy CMDB, podatności masowego rolloutu i projektuje architekturę Canary Deployment.
Student 3 (Audytor Zgodności Regulacyjnej ISO/KSC, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Ogólnokrajowego paraliżu cyfrowej tożsamości obywateli (mObywatel/login.gov.pl) i zablokowania usług państwa (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Braku możliwości wycofania wadliwej aktualizacji z powodu braku ewidencji relacji mikrousług w CMDB (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Nieodwracalnego uszkodzenia spójności danych w rejestrze PESEL przy niekontrolowanym restartowaniu klastrów (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Strat wizerunkowych państwa i utraty zaufania milionów obywateli do cyfryzacji usług publicznych (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (masowe wdrożenie poprawki i ogólnokrajowa awaria) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego aplikacja mObywatel i Węzeł Krajowy przestały działać w całym kraju? Ponieważ biblioteka kryptograficzna po aktualizacji zawiesiła moduły weryfikacji certyfikatów.
2. Dlaczego błąd ujawnił się natychmiast na wszystkich węzłach chmury rządowej? Ponieważ łatka została zainstalowana jednocześnie na 100% węzłów produkcyjnych.
3. Dlaczego nie zastosowano wdrożenia stopniowego (Canary Deployment)? Ponieważ zespół utrzymania spieszył się z zamknięciem podatności Zero-Day i nie posiadał procedury etapowego wdrażania poprawek systemowych.
4. Dlaczego nie przetestowano poprawki z realnym ruchem transakcyjnym? Ponieważ środowisko testowe nie odzwierciedlało skali obciążenia produkcyjnego, a w COI brak było testów transakcji syntetycznych.
5. Jaka jest przyczyna źródłowa (Root Cause)? Brak sformalizowanej strategii pierścieni wdrożeniowych (Deployment Rings Policy) w procesie Patch Managementu, brak bazy CMDB wiążącej komponenty systemowe oraz brak narzędzi automatycznej weryfikacji jakości po wdrożeniu.
Opracujcie tabelę CAP:
Zaprojektujcie architekturę federacyjnej bazy CMDB, specyfikację wdrożeń Canary w potoku ArgoCD/Flux oraz procedurę automatycznego wyzwalacza rollbacku na bazie metryk Prometheus/Grafana.
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
W trakcie obrony referatu wyjaśnijcie ideę wdrożeń kanarkowych (Canary Deployment) – dlaczego skierowanie poprawki na 5-10% serwerów z monitoringiem telemetrii ratuje 90% obywateli przed skutkami błędnej aktualizacji.
Temat: Zaawansowany Audyt Procedur Wycofania Zmian (Rollback Plan), Wyznaczania Punktu bez Powrotu (Point of No Return) oraz Formalnych Testów Akceptacyjnych Użytkowników (UAT) w Repertoriach Sądowych, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu procedur awaryjnego wycofywania zmian (Rollback Plan / Fallback Management), mechanizmów definiowania i kontroli punktu bez powrotu (Point of No Return) oraz badania autentyczności i kompletności testów akceptacyjnych użytkowników końcowych (User Acceptance Testing - UAT) w strukturach wymiaru sprawiedliwości. Zadanie skupia się na weryfikacji zgodności z kontrolami ISO/IEC 27001:2022 A.8.29 (Testowanie bezpieczeństwa w rozwoju i akceptacji) oraz A.8.32 (Zarządzanie zmianami), rygorami Ustawy - Prawo o ustroju sądów powszechnych, wymogami Krajowych Ram Interoperacyjności oraz standardem ISTQB. Studenci przeprowadzają matrycową analizę ryzyka 3x3 dla paraliżu postępowań karnych i cywilnych, klasyfikują uchybienia (NC1/NC2/OFI), prowadzą dochodzenie 5 Why oraz konstruują Plan Działań Korygujących (CAP).
Powiązanie z sylabusem i treściami programowymi:
Sąd Apelacyjny w Poznaniu wraz z Sądowym Centrum Usług Wspólnych (SCUW) koordynuje obsługę orzeczniczą, teleinformatyczną i administracyjną dla 4 sądów okręgowych i 30 sądów rejonowych w obszarze apelacji poznańskiej. W apelacji orzeka ponad 650 sędziów, a roczna liczba rozpatrywanych spraw przekracza 350 tysięcy.
Stan faktyczny w obszarze wdrożenia nowej wersji oprogramowania orzeczniczego:
Prezes Sądu Apelacyjnego zleca przeprowadzenie niezależnego, zaawansowanego audytu procedur Rollback Plan, punktu Point of No Return i rzetelności testów UAT na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu śledczego, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Sądownictwa i KRI): Bada akta wdrożenia, umowę z wykonawcą ZSWS, procedury Prezesa Sądu i SCUW, poświadczenie nieprawdy w protokole UAT i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Baz Danych MSSQL, Architektury PKI i Rollbacku): Bada logi migracji DDL, uszkodzony plik backupu .bak, brak skryptów downgrade, przekroczenie Point of No Return i projektuje zautomatyzowany szablon rollbacku.
Student 3 (Audytor Zgodności Regulacyjnej ISO/Prawo o Ustroju Sądów, Ryzyka i CAP): Przeprowadza analizę ryzyka 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Czterodniowego paraliżu wymiaru sprawiedliwości i zwolnienia z aresztu podejrzanych z powodu przekroczenia terminów procesowych (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Nieodwracalnej utraty integralności cyfrowych orzeczeń sądowych w wyniku braku procedury rollbacku i uszkodzonego backupu (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Odpowiedzialności karnej i dyscyplinarnej urzędników za poświadczenie nieprawdy w protokołach UAT (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Roszczeń odszkodowawczych stron procesowych za przewlekłość postępowań wywołaną awarią (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (brak planu rollback i wielodniowy paraliż sądu) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego sądy w całej apelacji nie mogły orzekać przez 4 dni? Ponieważ baza danych ZSWS była uszkodzona i nie można było cofnąć nieudanej migracji.
2. Dlaczego nie można było cofnąć migracji do stanu stabilnego? Ponieważ wykonawca nie przygotował skryptu downgrade, a backup przedwdrożeniowy był niesprawny.
3. Dlaczego dopuszczono do wdrożenia bez sprawdzonego planu wycofania i kopii? Ponieważ kierownik projektu SCUW nie zweryfikował załączników do wniosku RFC i zignorował checklistę bezpieczeństwa.
4. Dlaczego zignorowano procedury kontrolne? Ponieważ wykonawca zapewniał o "stuprocentowej niezawodności", a w sądzie brakowało procedury twardej weryfikacji Rollbacku i Point of No Return.
5. Jaka jest przyczyna źródłowa (Root Cause)? Brak sformalizowanego ładu zarządzania wycofaniem zmian (Rollback Governance), brak kultury twardej weryfikacji dowodów audytowych w SCUW oraz fikcyjny nadzór nad wykonawcami zewnętrznymi.
Opracujcie tabelę CAP:
Zaprojektujcie Regulamin Testów UAT w Sądownictwie, Szablon Dokumentu Rollback Plan z listą kontrolną oraz matrycę decyzyjną Punktu bez powrotu.
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
W referacie dobitnie wskażcie, dlaczego zdefiniowanie sztywnego Punktu bez powrotu (Point of No Return) i bezwzględne zarządzenie rollbacku po jego przekroczeniu chroni organizację przed paraliżem operacyjnym w poniedziałek rano.
Temat: Zaawansowany Audyt Zarządzania Zmianami u Krytycznych Dostawców Chmurowych (SaaS/PAAS), Aneksów SLA-change, Środowisk Testowych Sandbox oraz Zarządzania Cyklem Życia Interfejsów API (Deprecation Policy) w Świetle DORA, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu procesów nadzoru nad zmianami architektonicznymi, aplikacyjnymi i konfiguracyjnymi wprowadzanymi przez zewnętrznych dostawców usług chmurowych (Third-Party Change Governance / SaaS Release Management) w instytucji sektora ubezpieczeniowego. Zadanie koncentruje się na badaniu zgodności z rygorystycznymi przepisami Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA - Rozdział V: Zarządzanie ryzykiem ze strony zewnętrznych dostawców usług ICT, art. 28-30), Wytycznych KNF w sprawie zarządzania technologią informacyjną w zakładach ubezpieczeń oraz kontroli normy ISO/IEC 27001:2022 A.5.21, A.5.22 i A.8.32. Studenci analizują umowy SLA-Change, polityki wygaszania wersji API (API Deprecation Policy), badają dostępność środowisk Sandbox, przeprowadzają analizę ryzyka 3x3, klasyfikują uchybienia (NC1/NC2/OFI), realizują dochodzenie 5 Why oraz konstruują Plan Działań Korygujących (CAP).
Powiązanie z sylabusem i treściami programowymi:
Powszechny Zakład Ubezpieczeń Cyfrowych S.A. (PZUC) jest ogólnopolskim ubezpieczycielem majątkowym i komunikacyjnym obsługującym ponad 1,8 miliona aktywnych polis, likwidującym rocznie 220 tysięcy szkód i współpracującym z siecią 4000 agentów ubezpieczeniowych oraz setkami warsztatów naprawczych.
Stan faktyczny w obszarze procesów chmurowych i nadzoru nad zmianami dostawców:
Zarząd PZUC zleca przeprowadzenie niezależnego, zaawansowanego audytu nadzoru nad zmianami u dostawców chmurowych, klauzul umownych SLA-Change i procedur DORA na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu umów chmurowych, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Sektora Ubezpieczeń i DORA): Analizuje umowy ramowe i SLA z dostawcą SaaS, ramy prawne DORA (art. 28-30), Wytyczne KNF ds. IT, procedury wyjścia (Exit Strategy) i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Chmury SaaS, Integracji API i Kryptografii): Bada logi handshake TLS 1.2/1.3, specyfikację OpenAPI/Swagger, brak środowiska piaskownicy Sandbox, mechanizmy kolejkowania awaryjnego i projektuje bramkę API Gateway.
Student 3 (Audytor Zgodności Regulacyjnej KNF/EIOPA, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Całkowitego paraliżu likwidacji szkód i wypłat odszkodowań w wyniku jednostronnych zmian API u dostawcy chmurowego (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Nałożenia wielomilionowych kar administracyjnych przez KNF za naruszenie rygorów art. 28-30 rozporządzenia DORA (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
3. Zerwania łączności z bazą UFG i utraty licencji na sprzedaż ubezpieczeń komunikacyjnych OC (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Masowych skarg konsumenckich do Rzecznika Finansowego i utraty pozycji rynkowej (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (brak nadzoru nad zmianami w chmurze i paraliż likwidacji szkód) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego systemy PZUC przestały komunikować się z platformą CLAIMS-CLOUD? Ponieważ dostawca wyłączył protokół TLS 1.2 i zmienił strukturę obiektów JSON w interfejsie API.
2. Dlaczego ubezpieczyciel nie dostosował swoich systemów przed wprowadzeniem zmiany? Ponieważ dział IT nie wiedział o planowanej modyfikacji i nie przeprowadził testów.
3. Dlaczego dział IT nie został uprzedzony o zmianie? Ponieważ dostawca opublikował informację jedynie w biuletynie na blogu, nie mając obowiązku bezpośredniego powiadamiania klienta.
4. Dlaczego umowa nie nakładała na dostawcę obowiązku notyfikacji i udostępnienia Sandboxa? Ponieważ dział zakupów IT zawarł umowę na standardowym formularzu dostawcy, nie wprowadzając aneksu Change Governance.
5. Jaka jest przyczyna źródłowa (Root Cause)? Brak wdrożonych rygorów rozporządzenia DORA w obszarze zarządzania ryzykiem ze strony dostawców zewnętrznych ICT (Third-Party Risk Management), asymetria negocjacyjna zaakceptowana bez analizy ryzyka prawnego oraz brak procedury nadzoru nad cyklem życia API.
Opracujcie tabelę CAP:
Zaprojektujcie Wzorcowy Aneks Umowny DORA Change Addendum, Procedurę Nadzoru nad Wygaszaniem Interfejsów API (API Deprecation SOP) oraz zasady eskalacji incydentów zewnętrznych do KNF.
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
Podczas obrony referatu skupcie się na wykazaniu, w jaki sposób brak klauzuli API Deprecation Policy w umowie SaaS przekształcił planową aktualizację dostawcy w wielodniowy paraliż likwidacji szkód u ubezpieczyciela.
Temat: Zaawansowany Audyt Zarządzania Oknami Serwisowymi (Maintenance Windows), Architektury Wysokiej Dostępności (Zero Downtime / Blue-green Deployment), Powiadamiania Operacyjnego oraz Fallbacku Procedur Papierowych w Środowisku 24/7/365, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu planowania, koordynacji i zarządzania oknami serwisowymi (Maintenance Windows) w systemach infrastruktury krytycznej państwa działających w reżimie ciągłym (24/7/365) ze szczególnym uwzględnieniem Systemu Powiadamiania Ratunkowego (SPR - centra 112) oraz Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM). Zadanie koncentruje się na weryfikacji wdrożenia bezprzerwowych wzorców wdrożeniowych (Zero Downtime Deployment / Blue-Green Deployment), audycie wielopoziomowej komunikacji operacyjnej ze służbami ratowniczymi (Policja, PSP, ZRM) oraz badaniu rygorystycznych procedur przejścia na tryb pracy awaryjnej (Fallback to Contingency Procedures) zgodnie z normą ISO/IEC 27001:2022 (kontrole A.8.32, A.8.14, A.5.29), Ustawą o Państwowym Ratownictwie Medycznym i Ustawą o systemie powiadamiania ratunkowego. Studenci przeprowadzają analizę ryzyka 3x3, klasyfikują uchybienia (NC1/NC2/OFI), prowadzą dochodzenie 5 Why oraz konstruują Plan Działań Korygujących (CAP).
Powiązanie z sylabusem i treściami programowymi:
Krajowe Centrum Monitorowania Ratownictwa Medycznego (KCMRM) wraz z Wojewódzkimi Centrami Powiadamiania Ratunkowego (CPR) koordynuje przyjmowanie i obsługę zgłoszeń alarmowych z numerów 112, 999, 998 i 997 na terytorium całego kraju. System obsługuje średnio 60 tysięcy połączeń alarmowych na dobę, z czego ponad 12 tysięcy wymaga natychmiastowego zadysponowania Zespołów Ratownictwa Medycznego (ZRM).
Stan faktyczny w obszarze planowania prac modernizacyjnych i zarządzania zmianami:
Minister Spraw Wewnętrznych i Administracji oraz Minister Zdrowia powołują wspólną komisję audytową do przeprowadzenia zaawansowanego audytu procedur zarządzania oknami serwisowymi i bezprzerwowości wdrożeń na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu śledczego, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Służb Ratunkowych i MSWiA): Analizuje regulaminy CPR i KCMRM, Ustawę o systemie powiadamiania ratunkowego, Ustawę o PRM, proces decyzyjny planowania okien i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Sieci Telekomunikacyjnych, VoIP i Blue-Green): Bada logi przełączników, błąd pętli STP, konfigurację klastra VoIP SIP, brak architektury Zero Downtime i projektuje bezprzerwowy potok Blue-Green Deployment.
Student 3 (Audytor Zgodności z Normą ISO 27001, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka 3x3 (odpowiedzialność z art. 160 KK), formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Utraty życia obywateli i zgonów pacjentów w wyniku zrzucenia połączeń alarmowych 112 podczas prac w południe (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Zawieszenia sieci szkieletowej i centrali VoIP przez błąd pętli STP podczas przełączania przełączników (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Odpowiedzialności karnej kierownictwa IT z art. 160 Kodeksu Karnego za narażenie na bezpośrednie niebezpieczeństwo utraty życia (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Braku reakcji dyspozytorów z powodu wadliwego kanału komunikacji e-mail na 15 minut przed pracami (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (prace w szczycie, paraliż 112 i zgon pacjenta) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego karetka nie dotarła na czas do zatrzymania krążenia u dziecka? Ponieważ formatka zgłoszeniowa z numeru 112 została przekazana z 28-minutowym opóźnieniem.
2. Dlaczego doszło do opóźnienia w przekazaniu formatki? Ponieważ centrala VoIP i sieć SWD PRM były zablokowane z powodu pętli broadcast storm na przełącznikach.
3. Dlaczego przełączniki były restartowane w południe? Ponieważ kierownik IT zaplanował okno serwisowe na godzinę 12:00, aby inżynierowie i dostawca byli dostępni w biurze.
4. Dlaczego dyspozytornie nie przeszły natychmiast na procedury papierowe i radiowe? Ponieważ dyspozytorzy nie wiedzieli o rozpoczęciu prac (e-mail wysłano na 15 minut przed faktem).
5. Jaka jest przyczyna źródłowa (Root Cause)? Przedłożenie wygody inżynierów i dostawców sprzętu ponad bezpieczeństwo ratowania życia obywateli, brak sformalizowanej polityki okien serwisowych zakazującej prac w dzień oraz brak architektury bezprzerwowej Blue-Green Deployment.
Opracujcie tabelę CAP:
Zaprojektujcie Regulamin Okien Konserwacyjnych w Systemie Powiadamiania Ratunkowego, Standardową Procedurę Operacyjną (SOP) Przejścia na Łączność Awaryjną VHF oraz procedurę raportowania incydentów krytycznych do Rządowego Centrum Bezpieczeństwa (RCB).
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
W referacie wstrząśnijcie audytorium faktami: wykażcie, jak decyzja inżynierów o pracy 'w południe przy kawie' zamiast w nocy bezpośrednio doprowadziła do zrzucenia połączenia ratunkowego i śmierci dziecka.
Temat: Zaawansowany Audyt Przeglądu Po-wdrożeniowego (Post-implementation Review - PIR), Dochodzenia Przyczyn Źródłowych (RCA - 5 Why), Bazy Błędów Znanych (KEDB) oraz Ciągłego Doskonalenia w Zarządzaniu Zmianami po Incydencie Systemu Bagażowego BHS i Odpraw DCS, Ryzyko 3X3, Analiza 5 Why i Plan CAP
Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych kompetencji audytu fazy zamykania zmiany (Change Closure), weryfikacji rzetelności przeprowadzania Przeglądów Po-wdrożeniowych (Post-Implementation Review - PIR), badania jakości wielowymiarowych analiz przyczyn źródłowych (Root Cause Analysis - RCA metodą 5 Why i diagramu Ishikawy), zasilania Bazy Znanych Błędów (Known Error Database - KEDB) oraz wdrażania mechanizmów ciągłego doskonalenia Systemu Zarządzania Bezpieczeństwem Informacji (ISMS) w strategicznym węźle transportu lotniczego. Zadanie koncentruje się na spełnieniu rygorów normy ISO/IEC 27001:2022 (klauzula 10 Doskonalenie: 10.1 Ciągłe doskonalenie, 10.2 Niezgodności i działania korygujące, kontrola A.8.32), standardów Urzędu Lotnictwa Cywilnego (ULC), wytycznych Europejskiej Agencji Bezpieczeństwa Lotniczego (EASA) oraz Ustawy o Krajowym Systemie Cyberbezpieczeństwa. Studenci przeprowadzają analizę ryzyka 3x3, klasyfikują uchybienia (NC1/NC2/OFI), prowadzą dochodzenie 5 Why oraz konstruują Plan Działań Korygujących (CAP).
Powiązanie z sylabusem i treściami programowymi:
Przedsiębiorstwo Państwowe "Porty Lotnicze" - Międzynarodowy Port Lotniczy Warszawa-Radom im. Bohaterów Radomskiego Czerwca 1976 r. jest nowoczesnym lotniskiem pasażerskim obsługującym rejsy rejsowe, czarterowe i cargo, dysponującym terminalem o przepustowości 3 milionów pasażerów rocznie. Lotnisko podlega ścisłemu nadzorowi Urzędu Lotnictwa Cywilnego (ULC) oraz europejskim rygorom EASA Safety & Security.
Stan faktyczny w obszarze zamykania zmian i ciągłego doskonalenia procesów:
Zarząd PPL S.A. zleca powołanie zespołu audytorskiego do przeprowadzenia zaawansowanego audytu procesów Post-Implementation Review, dochodzenia przyczyn źródłowych RCA oraz kultury zamykania zmian na poziomie oceny 4.0.
Zadanie wymaga przeprowadzenia wnikliwego audytu śledczego, matrycowej oceny ryzyka 3x3, formalnej gradacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:
Student 1 (Audytor Wiodący / Governance Transportu Lotniczego i ULC): Bada procedury operacyjne PPL S.A., podręcznik zarządzania bezpieczeństwem lotniska (SMS), dokumentację audytową ULC/EASA, ład korporacyjny w Jira i koordynuje przygotowanie referatu.
Student 2 (Audytor Techniczny ds. Systemów Terminalowych BHS/DCS i RCA): Analizuje logi sterowników PLC sortera bagażowego, błąd ramki danych IATA, mechanizm zatoru bagażowego, analizuje przyczyny techniczne incydentu oraz moderuje warsztat 5 Why i diagram Ishikawy.
Student 3 (Audytor Zgodności z Normą ISO 27001, Ryzyka i Jakości CAP): Przeprowadza analizę ryzyka 3x3, formalną gradację niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.
Oceńcie ryzyka w matrycy 3x3:
1. Całkowitego paraliżu operacji lotniczych, odwołania lotów czarterowych i kar finansowych od przewoźników za opóźnienia rejsów (P=3, S=3 -> R=9; po CAP: P=1, S=3 -> R=3).
2. Powtórzenia katastrofy wdrożeniowej w wyniku zignorowania procedury PIR i braku analizy przyczyn źródłowych RCA (P=3, S=3 -> R=9; po CAP: P=1, S=2 -> R=2).
3. Sankcji administracyjnych i utraty certyfikatu lotniska użytku publicznego wydanego przez ULC (P=2, S=3 -> R=6; po CAP: P=1, S=2 -> R=2).
4. Strat wizerunkowych portu lotniczego i lawiny roszczeń odszkodowawczych pasażerów za zagubiony bagaż (P=3, S=2 -> R=6; po CAP: P=1, S=2 -> R=2).
Sformułujcie karty niezgodności:
Dla niezgodności krytycznej (brak analizy PIR/RCA i powtórzenie paraliżu sortowni) przeprowadźcie dochodzenie 5 Why:
1. Dlaczego doszło do powtórnego paraliżu sortowni bagażu w niedzielny poranek? Ponieważ kolejna poprawka wywołała identyczny konflikt struktury ramki danych z wagami odprawowymi.
2. Dlaczego programiści nie wiedzieli o istniejącym konflikcie ramek danych? Ponieważ wiedza o przyczynach pierwszej awarii sprzed 3 tygodni nie została udokumentowana ani wdrożona do testów regresyjnych.
3. Dlaczego nie udokumentowano przyczyn pierwszej awarii? Ponieważ nie przeprowadzono warsztatu analizy przyczyn źródłowych (RCA) ani spotkania Przeglądu Po-wdrożeniowego (PIR).
4. Dlaczego wniosek o zmianę został zamknięty jako udany bez procedury PIR? Ponieważ kierownik projektu IT obawiał się konsekwencji służbowych i kar umownych (kultura obwiniania - Blame Culture), a system Jira pozwalał na zamknięcie ticketu bez wymogu dołączenia raportu PIR.
5. Jaka jest przyczyna źródłowa (Root Cause)? Wadliwa kultura organizacyjna karząca za błędy zamiast wspierać ciągłe doskonalenie (brak No-Blame Culture), brak twardej bramki procesowej w narzędziach ITSM wymuszającej raport PIR dla incydentów P1/P2 oraz brak Bazy Znanych Błędów (KEDB).
Opracujcie tabelę CAP:
Zaprojektujcie Formularz Raportu PIR, szablon Diagramu Ishikawy dla awarii automatyki lotniskowej oraz procedurę weryfikacji skuteczności działań korygujących po 60 dniach od wdrożenia.
Plan seminaryjnego wystąpienia studenckiego na ocenę 4.0 (15 minut):
Zawartość raportu poaudytowego na ocenę 4.0 (8-12 stron A4):
A. Odpowiedzi na pytania problemowe i opis sytuacyjny:
B. Wzorcowe rozwiązanie problemu (Dokumentacja zaawansowana):
C. Analiza zalet i wad proponowanego rozwiązania:
Zakończcie obronę referatu mottem Sidney Dekkera: 'Bezpieczeństwa nie buduje się poprzez karanie ludzi za popełnione błędy, lecz poprzez stworzenie warunków, w których ludzie nie boją się o nich mówić i wspólnie je eliminować'.