Infrastruktura krytyczna w teorii

Teoretyczne aspekty infrastruktury krytycznej

Przedstawienie w postaci uogólnionego modelu infrastruktury krytycznej składającej się z wielu złożonych i funkcjonalnie zależnych elementów wymaga wyodrębnienia pewnych składowych, których wzajemne oddziaływanie determinuje sposób prawidłowego działania określonego systemu tej infrastruktury zarówno w aspekcie funkcjonalnym, jak i jego ochrony, rozumianej jako zapewnienie podstawowych atrybutów bezpieczeństwa, takich jak [1]:

  • Dostępność - rozumianą jako pewność, że funkcja określonego systemu wchodzącego w skład infrastruktury jest dostępna wtedy, kiedy jest potrzebna.
  • Integralność - rozumianą jako zapewnienie dokładności i kompletności realizowanych funkcji systemu wchodzącego w skład infrastruktury, zgodnie z oczekiwaniami użytkownika, w tym potrzebami państwa i jego obywateli, a także instytucji i przedsiębiorców.
  • Poufność - rozumianą jako pewność, że funkcje określonego systemu wchodzącego w skład infrastruktury są dostępne wyłącznie dla uprawnionych osób, podmiotów i procesów.

Model konstrukcji infrastruktury krytycznej odwzorowującej daną rzeczywistość w sposób pokazujący jej najistotniejsze cechy i zależności może stanowić podstawę do uporządkowanej oraz systemowej definicji wymagań funkcjonalnych i niefunkcjonalnych, w tym wymogów bezpieczeństwa dla każdego z systemów wyznaczonych do tej infrastruktury [2], w celu zapewnienia skutecznej ich ochrony przed zagrożeniami zniszczenia lub uszkodzenia.

Zaproponowana koncepcja modelu, jako propozycji sposobu teoretycznego opisu, zakłada istnienie systemu S należącego do infrastruktury krytycznej [3] udostępniającego pewne zasoby (dobra i usługi) i jednocześnie zależnego od innych dóbr i usług dostarczanych przez inne systemy należące do tej infrastruktury.

Przykładowo, systemy administracji publicznej, czy też ochrony zdrowia są zależne, pomimo często posiadanych rozwiązań zasilania awaryjnego, od systemów zaopatrzenia w energię, czy też systemów teleinformatycznych, których nieplanowane przestoje lub długie awarie mogą rodzić drastyczne konsekwencje. Analogicznie, systemy energetyczne są zależne od systemów transportowych, którymi dostarczane są surowce energetyczne i paliwa niezbędne do działania określonego typu elektrowni. Uszkodzenie systemu transportowego może rodzić negatywne skutki nie tyle dla gospodarki, co dla innego systemu wyznaczonego do infrastruktury krytycznej.

Konstrukcja systemu S zakłada istnienie specjalizowanych modułów zapewniających poprawną jego pracę i interakcję z otoczeniem. Powstały w wyniku takiej koncepcji system S należący do infrastruktury krytycznej jest logicznym zbiorem pewnych grup procesów współpracujących ze sobą, w celu skutecznego dostarczania dóbr i usług pomimo pojawiających się zagrożeń. W skład takiego systemu S wchodzą następujące elementy:

  • Moduł podstawowej funkcjonalności systemu S, o którym mowa w art. 3 Ustawy [4], dostarczający usługi i dobra, rozumiane jako usługi kluczowe dla bezpieczeństwa państwa i jego obywateli oraz służące zapewnieniu sprawnego funkcjonowania organów administracji publicznej, a także instytucji i przedsiębiorców, przy czym przez określenie podstawowa funkcjonalność należy rozumieć realizowanie, odpowiednio do swojego przeznaczania, potrzeb państwa i jego obywateli, a także instytucji i przedsiębiorców przez systemy oraz wchodzące w ich skład powiązane ze sobą funkcjonalnie obiekty, w tym obiekty budowlane, urządzenia i instalacje, o których mowa w art. 3 ww. Ustawy;
  • Moduł bezpieczeństwa systemu S, realizujący funkcje w zakresie zapewnienia podstawowych atrybutów bezpieczeństwa na potrzeby systemu S;
  • Moduł interfejsu użytkownika systemu S, pozwalający na interakcję użytkownika z systemem S, przy czym użytkownikiem może być obywatel, przedsiębiorca lub inny system należący do infrastruktury krytycznej.

Dla prawidłowego funkcjonowania systemu S niezbędne jest zapewnienie wymiany danych z następującymi jednostkami zewnętrznymi, które dostarczają informacje konieczne do pracy systemu S i odbierają zlecenia dotyczące dalszych działań:

  • Moduł identyfikacji i szacowania ryzyka, pozwalający na bieżącą identyfikację ryzyka, określanie jego źródeł, wielkości, istotności oraz obszarów systemu S wymagających zabezpieczeń wraz ze wskazaniem listy środków ochrony adekwatnych do zidentyfikowanego zagrożenia;
  • Moduł implementacji i rozwoju systemu S, pozwalający na zbudowanie podstawowej funkcjonalności systemu S i jego rozbudowę w miarę pojawiających się nowych potrzeb również w obszarze bezpieczeństwa w oparciu o wymagania adekwatne do przeprowadzonej analizy ryzyka, w celu minimalizowania potencjalnych strat spowodowanych zakłóceniem lub uszkodzeniem systemu S;
  • Użytkownik systemu S, obywatel i przedsiębiorca korzystający z usług i dóbr systemu S,
  • System S′, o którym mowa w art. 3 ww. Ustawy współzależny od systemu S.

Przyjęty model specyfikacji w sposób uogólniony opisuje ww. składowe, bez szczegółowego wyjaśniania ich sposobu działania. Podejście takie ma na celu przedstawienie najważniejszych elementów systemu należącego do infrastruktury krytycznej i jego otoczenia, które mają wpływ na jego sprawne działanie.

Konstrukcję odwzorowującą rzeczywistość systemu S wraz z pozostałymi składowymi w sposób pokazujący ich istotne właściwości można przedstawić przy wykorzystaniu strukturalnej metody Warda-Mellora [5], która uwzględnia dwa rodzaje modeli, tj. model funkcjonalny (essential model) i implementacyjny (implementational model). Pierwszy z nich może opisywać zachowanie danego systemu infrastruktury, zaś drugi może definiować jego strukturę. Istotne jest, że model funkcjonalny jest niezależną od implementacji specyfikacją wymagań określającą dokładnie co ma zostać zrobione. Model implementacyjny pokazuje dokładnie technologię realizacji wszystkich funkcji określonych w modelu funkcjonalnym.

W niniejszym opracowaniu ograniczono się wyłącznie do przedstawienia modelu funkcjonalnego, z uwagi na fakt, że istotne dla przyjętych rozważań jest określenie dokładne co system ma robić, czyli jakie funkcje ma realizować, szczególnie te wynikające z aspektów jego ochrony, a nie w jaki sposób. Podejście takie pozwala uniknąć nie tyle przedwczesnych decyzji implementacyjnych, co umożliwia znalezienie optymalnego rozwiązania pod względem funkcjonalnym i bezpieczeństwa przed stworzeniem modelu implementacyjnego.

Na podstawie przyjętej metody strukturalnej [6],[7] model funkcjonalny systemu S należącego do infrastruktury krytycznej będzie opisany przy pomocy modelu otoczenia (environmental model) oraz modelu zachowania (behavioural model).

Pierwszy z nich składa się ze schematu kontekstu (context schema), który określa otoczenie systemu S oraz definiuje granicę pomiędzy systemem S, a jego otoczeniem oraz listę zdarzeń występujących w tym otoczeniu, na które system S musi odpowiadać. Z kolei model zachowania składa się ze schematów transformacji (transformation schema), które opisują działanie systemu S oraz schematów danych (data schema) definiujących strukturę danych związanych z przepływami i zbiorami wewnątrz danego systemu S.

Model otoczenia systemu S, jak pokazano na rysunku nr 2, zawiera schemat kontekstu określający sprzęg systemu S z otoczeniem oraz listę zdarzeń, na które system S musi odpowiadać.

Poszczególne elementy z poniższego rysunku przedstawiają cztery jednostki zewnętrzne, które wraz z transformacją „System S” zapewniają założoną funkcjonalność systemu S.

Diagram kontekstowy systemu S

Poniżej przedstawiono nieformalny opis wybranych wymagań dla systemu S poprzez zestawienie zdarzeń wraz z opisem jego reakcji na określone zdarzenia.

Lista zdarzeń systemu S

Opisane powyżej zdarzenia i reakcje systemu S nie wyczerpują wszystkich możliwości ukazujących sposób zachowania się systemu S, ponieważ celem niniejszego opracowania jest, jak wspomniano powyżej, zaproponowanie metody formalnego opisu infrastruktury krytycznej, a nie  przedstawienie pełnej specyfikacji wymagań.

W dalszej części zdefiniowano struktury poszczególnych komunikatów wraz z opisem znaczenia przepływów i jednostek danych przedstawionych na schemacie kontekstu. Przepływy danych uwidocznione na rysunku 1 (schemat kontekstu) mają następujące znaczenie [8]:

Struktury poszczególnych komunikatów wraz z opisem znaczenia przepływów i jednostek danych

Jednostki danych zostały zdefiniowane następująco:

Struktury poszczególnych komunikatów wraz z opisem znaczenia przepływów i jednostek danych

Zgodnie z przyjętą metodą dla zapewnienia kompletnego opisu funkcjonalnego systemu S należy przedstawić model jego zachowania, który powinien zawierać schematy transformacji opisujące wszystkie funkcje systemu oraz schematy danych określające struktury danych związane z przepływami i zbiorami wewnątrz systemu.

Z uwagi na przyjęte założenie co do przedstawienia wyłącznie propozycji sposobu teoretycznego opisu infrastruktury krytycznej, w dalszej części opracowania organiczno się jedynie do wskazania składowych systemu S i zobrazowania ich na diagramie, bez przedstawiania poszczególnych schematów i grafów przejść transformacjioraz danych szczegółowo opisujących wybrane moduły w kontekście funkcji realizowanych przez system S.

System S składa się z trzech współpracujących ze sobą procesów P:

  • Moduł podstawowej funkcjonalności systemu S (MPF),
  • Moduł bezpieczeństwa systemu S (MB),
  • Moduł interfejsu użytkownika systemu S (MIU).

oraz z dwóch składnic danych D:

  • Informacje o stanie realizowanych czynności i operacji związanych z podstawową funkcjonalnością systemu S (IS) - zawiera m.in. następujące dane: żądania udostępnienia usługi lub dobra, listę dostępnych funkcji, aktualny stan realizowanych funkcji przez uprawnionych użytkowników, podmioty i procesy;
  • Informacje o regułach bezpieczeństwa i zdarzeniach  (IRBZ) - zawiera m.in. następujące dane: reguły monitorowania i kontroli, zasady zapewniania podstawowych atrybutów bezpieczeństwa, wzorce zachowań uznawane za niebezpieczne, uprawnienia dostępu, dane o wszelkich zdarzeniach związanych z funkcjonowaniem systemu S.

Poniżej, na rysunku nr 2, pokazano trzy współpracujące ze sobą procesy P systemu S wykorzystujące składnice danych D oraz przepływy danych jakie między nimi zachodzą.

Diagram transformacji systemu S

Poszczególne elementy z powyższego rysunku przedstawiają trzy procesy i dwie składnice danych, które wraz z otoczeniem, czyli z czterema jednostkami zewnętrznymi zapewniają założoną funkcjonalność systemu S.

Poniżej przedstawiono nieformalny opis wybranych wymagań dla procesów systemu S poprzez zestawienie zdarzeń wraz z opisem ich reakcji na określone zdarzenia.

Lista zdarzeń związanych z procesami systemu S

W dalszej części przedstawiono struktury komunikatów wraz z opisem przepływów i jednostek danych przedstawionych na schemacie transformacji. Przepływy danych uwidocznione na rysunku 2 (transformacja systemu S) mają następujące znaczenie:

Struktury poszczególnych komunikatów wraz z opisem znaczenia przepływów i jednostek danych

Jednostki danych zostały zdefiniowane następująco:

Struktury poszczególnych komunikatów wraz z opisem znaczenia przepływów i jednostek danych

Zaproponowany opis modelu otoczenia i zachowania systemu S opiera się na podstawowych modułach i obsługuje wybrane zdarzenia, co nie wyklucza możliwości ich rozbudowy o inne procesy i składnice danych istotne z punktu widzenia opisu specyficznych wymagań, w celu zapewnienia wysokiej jakości działania i bezpieczeństwa danej infrastruktury krytycznej. Ograniczenie specyfikacji zdarzeń i obsługujących je procesów wraz ze składnicami danych jedynie do wybranych obszarów wynika z zaprezentowania wyłącznie metody pozwalającej na teoretyczne przedstawienie problemu infrastruktury krytycznej.

Opisany powyżej model teoretyczny pozwala wyjaśnić ogólne zasady funkcjonowania systemu należącego do infrastruktury krytycznej wraz z określeniem najistotniejszych wymagań i właściwości, co do jego ochrony, w celu zapewnienia ciągłości świadczonych przez niego usług i dostarczanych dóbr.

Zaproponowana koncepcja uogólnionego modelu infrastruktury krytycznej może zostać odpowiednio rozbudowana o inne zdarzenia i procesy dla zapewnienia dokładniejszych rozważań, szczególnie w momencie pojawienia się potrzeby zaprojektowania i skonstruowania konkretnego systemu spełniającego wymagania dla systemów wyznaczanych do infrastruktury krytycznej.


[1] PN-I-02000:2002 Technika informatyczna - Zabezpieczenia w systemach informatycznych - Terminologia.

[2] A. Machnacz, Metody rozpoznawania, wyznaczania i projektowania infrastruktury krytycznej na potrzeby ochrony ludności oraz zapewnienia funkcjonowania organów administracji, Wiedza Obronna, Kwartalnik Towarzystwa Wiedzy Obronnej, ROK XXXVIII, nr 2 /237/, str. 106-121, Warszawa 2011.

[3] jeden z systemów, o którym mowa w art. 3 Ustawy z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (Dz.U. 2007 nr 89 poz. 590 z późn. zm.).

[4] Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (Dz.U. 2007 nr 89 poz. 590 z późn. zm.).

[5]P. T. Ward i S. J. Mellor, Structured Development for Real-Time Systems, Yourdon Press, 1985.

[6] K. Sacha, Projektowanie oprogramowania systemów sterujących, Oficyna Wydawnicza PW, Warszawa, 1996.

[7] Edward Yourdon, Współczesna analiza strukturalna, Wydawnictwa Naukowo-Techniczne, Warszawa, 1996.

[8] W przyjętej metodzie specyfikacji znaczenie atrybutów opisuje się nieformalnie, w języku naturalnym, umieszczając odpowiednie zdanie między znakami gwiazdki (*). Atrybuty kluczowe poprzedza się znakiem „@”. W przypadku, kiedy klucz składa się z kilku atrybutów, znak „@” stawia się przed każdym z nich.

Publikacja jest dostępna na licencji Creative Commons Uznanie autorstwa 4.0 Międzynarodowe, pewne prawa zastrzeżone na rzecz autora i machnacz.eu. Zezwala się na dowolne wykorzystywanie treści publikacji pod warunkiem wskazania autora i podania informacji o licencji.

logo.png
Utwory z tej strony są dostępne na licencji Creative Commons Uznanie autorstwa 4.0 Międzynarodowe, pewne prawa zastrzeżone na rzecz autora i machnacz.eu. Zezwala się na dowolne wykorzystywanie treści publikacji pod warunkiem wskazania autora i podania informacji o licencji.
© 2012-2024 machnacz.eu. Powerd by ITbrain.

Kontakt

info@machnacz.eu

Search