Zadania i kompetencje organów administracji publicznej po reformie ustrojowej państwa
Bezpieczeństwo energetyczne państw
Zagrożenia cywilizacje Podstawowe pojęcia i zakres
międzynarodowego bezpieczeństwa energetycznego Międzynarodowe bezpieczeństwo energetyczne w XXI w Bezpieczeństwo energetyczne państwa, geopolityczne uwarunkowania
Bezpieczeństwo energetyczne we współczesnej securitologii Bezpieczeństwo energetyczne Europy Środkowej
Bezpieczeństwo energetyczne w pierwszej dekadzie XXI wieku. Mozaika interesów i geostrategii Bezpieczeństwo energetyczne. Koncepcje, wyzwania, interesy
Bezpieczeństwo energetyczne Polski na początek trzeciej dekady XXI wieku
Celem
pytanie badawcze
Bezpieczeństwo elektrowni jądrowych w kontekście zagrożeń radiacyjnych – aspekty teoretyczne
Eksploatacja elektrowni jądrowych
Organization for Economic Cooperation and Development
International Nuclear Event Scale
Nie bójmy się energetyki jądrowej
Nie bójmy się energetyki jądrowej
Bezpieczeństwo energetyczne – rynki surowców i energii
Awarie nuklearne Vademecum Bezpieczeństwa
TABELA 2.2.
Kryteria
World Association of Nuclear Operators
Działalność WANO – Światowego Stowarzyszenia Operatorów Jądrowych
Reaktor jądrowy pod cyfrowym pancerzem
Zapraszamy do lektury wywiadu z dr Alicją Żukowską, autorką książki „Cyberbezpieczeństwo w energetyce jądrowej. Wyzwania, regulacje i modele zarządzania dla Polski”. Rozmowa przybliża kulisy pracy nad kodem sterującym reaktorem, który w tym specyficznym sektorze traktowany jest jako kluczowy element fizycznej bariery bezpieczeństwa.
W świecie jądrowym często operujemy na systemach klasy OT (Operational Technology), które dla typowego programisty webowego są „egzotyką”. Jakie specyficzne wymagania stawia się przed kodem sterującym reaktorem, których nie spotkamy w standardowym enterprise software?
Przede wszystkim musimy pamiętać, że inżynierowie oprogramowania w elektrowniach jądrowych operują w środowisku o zerowej tolerancji dla błędów. W świecie jądrowym kod nie jest jedynie narzędziem przetwarzania danych, lecz elementem fizycznej bariery bezpieczeństwa, której naruszenie może prowadzić do skutków o charakterze globalnym. Kod traktowany jest jako element konstrukcyjny reaktora, element systemu bezpieczeństwa. Z perspektywy programisty przyzwyczajonego do standardów korporacyjnych systemy te wykazują „egzotykę”, wynikającą z konieczności zachowania najwyższego stopnia niezawodności i bezpieczeństwa. Podczas gdy oprogramowanie enterprise jest optymalizowane pod kątem wydajności, skalowalności i elastyczności, kod sterujący reaktorem musi być przede wszystkim deterministyczny, weryfikowalny i odporny na błędy zarówno logiczne, jak i sprzętowe. Kod ten jest ściśle powiązany z analizą z analizą bezpieczeństwa reaktora. To z kolei przekłada się na bardzo sformalizowany cykl życia – wymagania, projekt, implementacja, weryfikacja i walidacja, eksploatacja. Każdy z tych etapów musi odpowiadać międzynarodowym standardom, być udokumentowany i objęty audytem. Warto tu zaznaczyć, że zgodnie z wymogami IAEA weryfikacja i walidacja powinny być przeprowadzana przez niezależne od siebie zespoły czy przedsiębiorstwa.
Kolejną różnicą dotyczącą kodu sterującego reaktorem jest wymóg pracy w reżimie twardego czasu rzeczywistego (hard real-time). W standardowym systemie korporacyjnym opóźnienie w odpowiedzi bazy danych o kilkaset milisekund jest zazwyczaj akceptowalne i nie prowadzi do katastrofy. W systemach sterowania reaktorem, takich jak rozproszone systemy sterowania (DCS) czy programowalne sterowniki logiczne (PLC), każda operacja musi zostać wykonana w ściśle zdefiniowanym cyklu czasowym.
Błędy w zarządzaniu pamięcią, które w świecie webowym kończą się restartem kontenera, w systemie OT mogą doprowadzić do utraty kontroli nad procesem fizycznym. Determinizm oznacza, że system
Książka dostępna w księgarnii PWN: https://ksiegarnia.pwn.pl/Cyberbezpieczenstwo-w-energetycejadrowej-101314222.html
musi zawsze reagować w ten sam sposób na te same wejścia w tym samym czasie. Wyklucza to stosowanie mechanizmów, które wprowadzają nieprzewidywalność do czasu wykonania kodu.
Tradycyjne podejście do cyberbezpieczeństwa opiera się na triadzie CIA (Confidentiality, Integrity, Availability). W sektorze jądrowym priorytety te ulegają drastycznemu przesunięciu. Celem systemów OT jest kontrola procesów fizycznych i bezpieczeństwo. Najważniejszym elementem staje się dostępność i integralność danych procesowych, Poufność często schodzi na dalszy plan, oczywiście o ile nie dotyczy parametrów konstrukcyjnych obiektu.
Czy w energetyce jądrowej istnieje coś takiego jak „Nuclear-grade DevSecOps”? Jak wyglądają rygory testowania kodu przed wdrożeniem w środowisku, gdzie błąd nie kończy się restartem kontenera, a potencjalnym skażeniem?
W środowisku IT DevSecOps jest filozofią, która w ostatnim czasie bardzo zyskała dużą popularność. Trudno się temu dziwić, gdyż pozwala ona na szybkie iteracje, automatyzację i wczesne wykrywanie podatności. W sektorze jądrowym istnieje odpowiednik tych procesów, jednak jest on poddany rygorom, które dla typowego programisty mogą wydawać się paraliżujące. Mam tu na myśli standardy i ramy stworzone przez IEC (IEC 61513, IEC 60880, IEC 62138, IEC 62645) i IAEA (Verification and Validation of Software Related to Nuclear Power Plant Instrumentation and Control) oraz nadzór organu regulacyjnego nad ich przestrzeganiem. Termin „Nuclear-grade DevSecOps” odnosi się do procesu weryfikacji i walidacji, który musi być przeprowadzony dla każdej linii kodu.
W sytuacji, gdy każdy błąd może prowadzić do fatalnego w skutkach skażenia, testowanie kodu opiera się na metodach formalnych i matematycznych dowodach poprawności i służy udowodnieniu, że kod zachowa się poprawnie w każdym możliwym stanie automatu
skończonego. Wymaga to stworzenia symulatorów o wysokiej wierności, pozwalające na testowanie oprogramowania I&C w warunkach symulujących awarie, takie jak pęknięcie rurociągu chłodziwa czy utrata zasilania zewnętrznego.
Programiści często narzekają na długie procesy CI/CD. W Pani książce mowa o regulacjach i modelach zarządzania – o ile rzędów wielkości dłużej trwa cykl życia oprogramowania w sektorze jądrowym w porównaniu do komercyjnego IT?
W komercyjnym IT pomysł, rozwój i wdrożenie obejmuje okres tygodni lub miesięcy. Sektor jądrowy operuje w zupełnie innej skali czasowej. Samo projektowanie i implementacja trwa kilka lat. Należy także uwzględnić okres, w którym następuje kwalifikacja i zatwierdzenie przez organ regulacyjny. Każda zmiana w systemie krytycznego bezpieczeństwa wymaga analizy wpływu na bezpieczeństwo, aktualizacji dokumentacji i przeglądu przeprowadzonego przez organ regulacyjny. Przewidywany cykl życia elektrowni jądrowej to kilka dekad (40-60 lat). Systemy I&C są projektowane na dziesiątki lat pracy. Procesy modernizacyjne są bardzo rygorystyczne i często podlegają procesowi licencjonowania. I tu ujawnia się różnica w tempie rozwoju technologii cyfrowych i trwałości fizycznej infrastruktury elektrowni jądrowej – infrastruktura I&C wdrożona podczas budowy, w momencie uruchomienia elektrowni wymaga modernizacji w celu osiągnięcia zgodności z aktualnym stanem wiedzy i praktyki inżynierskiej. Ta rozbieżność pomiędzy cyklem życia technologii a cyklem życia inwestycji stanowi bardzo poważny problem, gdyż zagrożenia w cyberprzestrzeni ewoluują bardzo dynamicznie, a wszelkie modernizacje są bardzo powolne, bo głównym celem wielkich przedsiębiorstw energetycznych jest zapewnienie stałych i przerwanych dostaw.
Obecnie bezpieczeństwo łańcucha dostaw (Supply Chain Security) to gorący temat w IT. Czy przy budowie polskiej elektrowni jądrowej dopuszczalne jest korzystanie z bibliotek Open Source, czy też każdy bajt kodu musi pochodzić od certyfikowanych dostawców z pełnym audytem?
To bardzo ważne i w pełni uzasadnione pytanie. Incydenty SolarWinds czy Stuxnet pokazują, jak newralgiczne jest bezpieczeństwo łańcucha dostaw. Ten obszar także objęty jest unormowaniu i standaryzacji. Supply Chain Security jest integralną częścią programu cyberbezpieczeństwa elektrowni jądrowych. Wymogi IAEA i IEC uzależniają wykorzystywanie oprogramowania Open Source od klasy bezpieczeństwa systemu, w którym ma ono pracować. W systemach o najwyższej krytyczności, obejmujących bezpośrednie sterowanie reaktorem, korzystanie z niezweryfikowanych bibliotek Open Source jest praktycznie wykluczone. Każdy fragment kodu musi pochodzić od dostawcy posiadającego certyfikowany system zapewnienia jakości i być poddany pełnemu audytowi. W polskim modelu inwestycyjnym każdy dostawca musi udowodnić integralność swojego łańcucha dostaw przed uzyskaniem zezwolenia od Prezesa Państwowej Agencji Atomistyki. Inwestor jest także zobowiązany do prowadzenia ciągłych audytów i inspekcji u podwykonawców.
Nie oznacza to jednak, że Open Source jest całkowicie zakazany w elektrowniach. Może być stosowany w systemach pomocniczych
(np. administracyjnych), o ile zostanie objęty modelem „Graded Approach” – czyli stopniem nadzoru proporcjonalnym do ryzyka.
Jeśli czytelnik „Programisty” chciałby za 5 lat pracować przy cyberzabezpieczaniu polskiego programu jądrowego, jakie konkretne certyfikacje lub technologie (np. standardy IEC 62443) powinien zacząć zgłębiać już teraz?
Pozwolę sobie na trochę przewrotną tezę, udzielając odpowiedzi na to pytanie. Cyberbezpieczeństwo elektrowni jądrowych niewiele różni się od cyberbezpieczeństwa w innych sektorach. Jest ono jednak znacznie bardziej sformalizowane i podlega ścisłemu nadzorowi.
Czytelnikowi „Programisty”, poza nabywaniem wiedzy i kompetencji w zakresie ogólnego cyberbezpieczeństwa, sugeruję przede wszystkim zrozumienie ochrony OT oraz ciągłą analizę standardów bezpieczeństwa jądrowego i ochrony jądrowej. Na pewno lekturą obowiązkową powinny być wymogi IAEA w zakresie bezpieczeństwa komputerowego oraz normy IEC 62645 dotyczącej cyberbezpieczeństwa systemów I&C, czy IEC 62859 w zakresie wymagań dotyczących koordynacji bezpieczeństwa i cyberbezpieczeństwa.
Zwrócę uwagę na jeszcze jeden aspekt – konieczność zrozumienia i zaakceptowania pracy w warunkach kultury bezpieczeństwa w środowisku regulowanym, o czym bardzo często zapominamy.
ALICJA ŻUKOWSKA
Doktor prawa; adiunkt w Morskim Centrum Cyberbezpieczeństwa, AMW w Gdyni. Absolwentka University of Abertay Dundee oraz Uniwersytetu w Białymstoku. Od 2013 roku zatrudniona w Akademii Marynarki Wojennej. Główne zainteresowania badawcze obejmują zagadnienia bezpieczeństwa międzynarodowego, prawnych aspektów cyberbezpieczeństwa i ochrony ludności.
