prof. dr inĪ. Tadeusz Missala
Przemysáowy Instytut Automatyki i Pomiarów PIAP, Warszawa
WYKORZYSTANIE METOD BEZPIECZEēSTWA
FUNKCJONALNEGO W OCENIE ZAGROĩEē W SIECIACH
INFORMATYCZNYCH – PROPOZYCJA
W nawiązaniu do poprzedniej publikacji autora [1] zwrócono uwagĊ, Īe na Warsztatach CRITIS’2010 pojawiáy siĊ publikacje dotyczące analizy zagroĪeĔ powstających w sieciach informatycznych sterujących infrastrukturą krytyczną i iloĞciowej oceny odpornoĞci na te zagroĪenia. Ta tematyka ma wiele aspektów wspólnych z tematyką oceny zagroĪeĔ i ryzyka stosowaną w bezpieczeĔstwie funkcjonalnym [3]. Zaproponowano zastosowanie tych metod w ocenie zagroĪeĔ w sieciach informatycznych.
PROVIDING OF FUNCTIONAL SAFETY METHODS TO THREATS AND RESILIENCE ANALYSIS IN INFORMATION NETWORKS
– PROPOSAL
Referring to the precedent publication of the author [1] the attention is direct to the fact, during Workshop CRITIS’2010 are occurred publications concerning threats analysis in the information networks controlling the critical infrastructure and quantitative assessment of the networks resilience. It is to note the many of aspects of these are common with the methods applied in the functional safety [3]. Use of functional safety methods to threats assessment in information networks is proposed.
1. WPROWADZENIE
Zabezpieczenie (security)1 jest pewnoĞcią dostarczaną przez system, Īe kaĪde niepoprawne wejĞcie lub kaĪdy nieuprawniony dostĊp jest niemoĪliwy [10e]. Jest skáadową niezawodnoĞci systemu [2] i áącznie z innymi cechami niezawodnoĞci wchodzi w skáad pojĊcia bezpieczeĔstwa (safety) systemu [10g]. To upowaĪnia do spojrzenia na zagadnienie analizy i oceny zagroĪeĔ i ryzyka w sieciach informatycznych z punktu widzenia doĞwiadczeĔ zdobytych przez technikĊ automatyzacji przy realizacji sterowania i zabezpieczenia infrastruktury krytycznej, to jest przez pryzmat bezpieczeĔstwa funkcjonalnego.
W dotychczas prezentowanych pracach, m.in. [1, 6, 7, 8], gáówna uwaga byáa skierowana na opracowanie systemu zabezpieczającego transmisjĊ danych, w szczególnoĞci na zabezpieczenie systemów lokalnych (obiektowych i przedsiĊbiorstwa) przed zagroĪeniami pochodzącymi z sieci rozlegáych, gáównie z Internetu. Dobre inĪynierskie metody postĊpowania w przypadku zagroĪeĔ bezpieczeĔstwa obiektów przemysáowych, a szczególnie infrastruktury krytycznej, wprowadzone do praktyki miĊdzynarodowej serią norm IEC 61508 [11] (jako normy bezpieczeĔstwa funkcjonalnego) wskazują, Īe aby wáaĞciwie dobraü zabezpieczenia, naleĪy zacząü od analizy zagroĪeĔ i ryzyka. Takie podejĞcie prezentują takĪe normy miĊdzynarodowe [19, 20, 21].
1
W nawiasach zamieszczono angielskie nazwy terminów, w celu uzyskania jednoznacznoĞci i unikniĊcia pomylenia z terminami stosowanymi w zagadnieniach bezpieczeĔstwa w automatyzacji. W szczególnoĞci naleĪy zaznaczyü, Īe w automatyce terminem „bezpieczeĔstwo” táumaczy siĊ termin „safety”, stąd wprowadzenie terminu „zabezpieczenie”.
Narzuca siĊ wiĊc zagadnienie doboru metod wáaĞciwych do oceny zagroĪeĔ i ryzyka w sieciach komunikacyjnych. Ta tematyka znalazáa siĊ w obiektywie Warsztatów CRITIS’10, które odbyáy siĊ w Atenach w dniach 23–24 wrzeĞnia 2010 r. [4, 5].
Ostatnio wykonany cyberatak na elektrowniĊ atomową w Iranie wskazuje, Īe zagroĪenie systemów infrastruktury krytycznej atakami terrorystycznymi lub wojskowymi jest rzeczą realną. Nakáada to koniecznoĞü dbaáoĞci o najwyĪszy poziom zabezpieczenia sieci obsáugujących taką infrastrukturĊ.
2. POJĉCIA PODSTAWOWE
W technice sieci teleinformatycznych do scharakteryzowania wáaĞciwoĞci sieci związanych z ich zabezpieczeniem stosuje siĊ nastĊpujące terminy [17, 18]:
zagroĪenie (threa t) – okolicznoĞü lub zdarzenie, które moĪe wpáywaü niekorzystnie
na dziaáania instalacji (wáączając funkcje, wygląd lub opiniĊ), majątek lub jednostki poprzez system informatyczny przez dostĊp nieuprawniony, zniszczenie, ujawnienie, modyfikacjĊ danych, opóĨnienie przesyáek i/lub odmowĊ usáug.
prĊĪnoĞü2 (resilience) – cecha opisująca zdolnoĞü systemu do dostosowania siĊ
do znaczących zmian w jego Ğrodowisku przez wykonanie dziaáaĔ nadzwyczajnych w celu utrzymania akceptowanego dziaáania systemu.
odpornoĞü (robustness) – cecha opisująca zdolnoĞü systemu do tolerowania znaczących
zmian w jego Ğrodowisku i utrzymania akceptowalnego dziaáania systemu w sposób niewymagający wykonania dziaáaĔ nadzwyczajnych.
protokóá komunikacyjny zabezpieczony (secure communications protocol) – protokóá
komunikacyjny zapewniający odpowiednie zabezpieczenie poufnoĞci, uwierzytelnienia, nienaruszalnoĞci zawartoĞci i taktowania przesyáek.
uwierzytelnienie (autentication) – proces ustalający pochodzenie informacji lub okreĞlający
toĪsamoĞü jednostki.
autoryzacja (authorisation) – uprawnienia dostĊpu przyznane jednostce; przekazanie
uprawnienia urzĊdowego do wykonywania funkcji lub czynnoĞci.
poufnoĞü (confidentiality) – wáaĞciwoĞü, Īe informacje poufne nie zostaną ujawnione
jednostkom nieuprawnionym.
podatnoĞü (vulnerability) – cecha opisująca wraĪliwoĞü systemu na znaczące zmiany w jego
Ğrodowisku, prowadząca do utraty jego akceptowanego dziaáania.
metryka (metric, also called „indicator”) – wartoĞü obliczona z zaobserwowanych
cech miary.
UWAGA 1 – Gdy temperatura jest okreĞlona jako 38 °C, to 38 jest metryką, zaĞ stopnie Celsjusza są miarą.
UWAGA 2 – DostĊpnoĞü poáączenia okreĞlona jako 99,99 % (metryka) moĪe byü obliczona przez sumowanie dostĊpnoĞci indywidualnych (cech zaobserwowanych) rutera, linii
transmisyjnej dostĊpu i sieci gáównej.
2
3. METODOLOGIA ANALIZY ZAGROĩEē I RYZYKA
Celem analizy zagroĪeĔ i ryzyka jest ocena stanu bezpieczeĔstwa, porównanie go ze stanem poĪądanym i umoĪliwienie zmniejszenia ryzyka do stanu akceptowanego lub wyeliminowanie obiektów stwarzających takie zagroĪenia, lub tak nieodpornych na zagroĪenia umyĞlne, Īe ich eksploatacja jest bezsensowna.
Przeprowadzenie analizy zagroĪeĔ i ryzyka wymaga wykonania kroków [3, 22]:
x
okreĞlenie ryzyka akceptowanego,x
okreĞlenie granic obiektu (procesu/urządzenia) wraz j jego ukáadem sterowania,x
okreĞlenie wszelkich interfejsów zapewniających komunikacjĊ z otoczeniem,x
dokáadne zdefiniowanie warunków Ğrodowiskowych, w tym elektromagnetycznych, w jakich jest gwarantowane poprawne dziaáanie obiektu i jego systemu sterowania,x
dokáadne zdefiniowanie warunków Ğrodowiskowych, w tym elektromagnetycznych, jakie mogą wystąpiü w czasie eksploatacji, a które mogą siĊ nie mieĞciü w zakresie warunków gwarantowanych,x
zidentyfikowanie sáaboĞci (vulnerabilities) systemu,x
zidentyfikowanie wszelkich moĪliwych sytuacji zagraĪających, jakie mogą zaistnieü z powodu: niewáaĞciwego dziaáania obiektu, niewáaĞciwego dziaáania ukáadu sterowania, w tym ich awarii, zaistnienia nienormalnych warunków Ğrodowiskowych, w tym ekstremalnych zaburzeĔ atmosferycznych, niewáaĞciwego lub nieuwaĪnego postĊpowania obsáugi (operatorów, serwisantów) i ataków zewnĊtrznych,x
opracowanie scenariuszy rozwoju zagroĪeĔ przez okreĞlenie Ĩródáa zagroĪenia, dróg jego rozprzestrzeniania siĊ, ujĞcia zagroĪeĔ (tj. elementów, które bĊdą naraĪone i mogą zostaü uszkodzone lub wytrącone z normalnej pracy),x
oszacowanie konsekwencji, jakie mogą wystąpiü,x
oszacowanie prawdopodobieĔstwa wystąpienia kaĪdej z konsekwencji,x
ocena ryzyka obiektu áącznie z jego ukáadem sterowania i porównanie z ryzykiem akceptowanym,x
okreĞlenie wymaganego stopnia zmniejszenia ryzyka, rodzaju Ğrodków zabezpieczających i ewentualnie ich nienaruszalnoĞci bezpieczeĔstwa,x
sporządzenie odpowiedniego raportu.4. METODY ANALIZY ZAGROĩEē I RYZYKA PREZENTOWANE W CZASIE WARSZTATÓW CRITIS’2010
4.1. Propozycja metryk do oceny sieci
Choáda i Jajszczyk w prezentacji [5] przedstawili propozycjĊ metryk do oceny prĊĪnoĞci (resiliencse) sieci. Te koncepcjĊ przedstawiono na rysunku 1. Znaczenie niektórych pojĊü zaprezentowanych na rysunku Autorzy przybliĪają nastĊpująco:
x
Czas przestoju: Ğredni czas przestoju MTD, Ğredni czas do odnowy MTTR.x
CiągáoĞü: Ğredni czas zdatnoĞci MUT, Ğredni czas do uszkodzenia MTTF, Ğredni czas dziaáania miĊdzy uszkodzeniami MTBF, intensywnoĞü uszkodzeĔ Ȝ.x
DostĊpnoĞü: funkcja MTD MUT MUT A lub MTTF MTTR MTTF Ax
JakoĞü ĞcieĪki naprawy zaleĪy od wielu parametrów, np. bitowej stopy báĊdów, ilorazu sygnaáu do szumu, utraty pakietu przesyáki, opóĨnienia, fluktuacji sygnaáu, zdolnoĞci odbiorczej, zabezpieczenia – powstaje pytanie, jak to mierzyü.x
Ruch zakáócony: bezpoĞrednio (buforowanie i krótki czas do naprawy czynią gopomijalnym) i poĞrednio (nie koniecznie wymagające skierowania ruchu na inną drogĊ, zaleĪne od stanu sieci, dáugotrwaáe).
x
PrĊĪnoĞü na uszkodzenia wielokrotne: wymaga wiĊkszych zasobów, jest natomiastkonieczna przy zastosowaniach krytycznych.
x
Pokrycie uszkodzeĔ: naprawianie podsieci áączy/poáączeĔ.Autorzy wskazali na koniecznoĞü uwzglĊdniania krótkoterminowego i dáugoterminowego zarządzania ryzykiem w relacjach z klientem, jak teĪ wyposaĪanie go w lepsze Ğrodki naprawy uszkodzeĔ. Zadaniem przyszáoĞciowym jest zwrócenie uwagi na metody okreĞlania (metryki) uzyskania stanu ustalonego dostĊpnoĞci. Szczególnie waĪnym zadaniem jest wprowadzenie prĊĪnoĞci wielopoziomowej. Zaprezentowano takĪe ocenĊ czuáoĞci róĪnych aplikacji na metryki jakoĞci prĊĪnoĞci (QoR); zamieszczono ją w tablicy 1.
Rys.1. Skáadowe metryki jakoĞci prĊĪnoĞci
To podejĞcie jest bardzo zbliĪone do prezentowanego w PN-EN 61069 [10].
Cechy niezawodnoĞci WáaĞciwoĞci związane z dziaáaniem WáaĞciwoĞci związane z odnową Czas przestoju CiągáoĞü DostĊpnoĞü Stan ogólny Wymagania na sygnalizowanie ElastycznoĞü SkalowalnoĞü Koszt JakoĞü ĞcieĪki naprawy PrĊĪnoĞü na uszkodzenia wielokrotne Udaremnienie Pokrycie uszkodzeĔ Ruch zakáócony Metryki jakoĞci prĊĪnoĞci (QoR)
4.2. Propozycja iloĞciowej metody analizy ryzyka wynikającego z zagroĪeĔ zamierzonych
Vavoulas i Xenakis [4] wskazali na stosowane metody jakoĞciowe CORAS, CRAMM, OCTAVE, FRAP. Metody te uznano jako niedostatecznie speániające obecne wymagania, miĊdzy innymi ze wzglĊdu na nie dostarczanie podstaw do analizy kosztów i korzyĞci. Ponadto zagroĪenia zamierzone nie są adekwatnie opisywane metodami jakoĞciowymi, wymagają gáĊbszej analizy, gáównie z dwóch powodów:
x
moĪliwoĞci oddziaáywania záoĪonegox
moĪliwoĞci, jakimi dysponuje atakujący (doĞwiadczenie, zasoby materialne,intelektualne itd.).
Tab. 1. CzuáoĞü aplikacji na metryki QoR
CiągáoĞü DostĊpnoĞü Czas naprawy QoR rezerwy Uszkodzenia wielokrotne
E-mail Maáa ĝrednia Maáa Maáa Maáa
FTP ĝrednia ĝrednia DuĪa Maáa Maáa
Gáos/video przez IP
DuĪa ĝrednia DuĪa DuĪa ĝrednia
Sterowanie
produkcją DuĪa DuĪa DuĪa Maáa DuĪa
WspóádostĊp do pliku
Maáa ĝrednia Maáa Maáa ĝrednia
VoP2P
(gáos/video) Maáa Maáa ĝrednia Maáa ĝrednia Sieü do sieci
energetycznej
DuĪa ĝrednia ĝrednia ĝrednia DuĪa
Autorzy zaproponowali wáasne podejĞcie iloĞciowe w wersji trzech odrĊbnych poziomów: podstawy koncepcyjne, narzĊdzia modelowania, podstawy matematyczne – rys. 2.
Rys. 2. Koncepcja metody analizy ryzyka
analiza ryzyka
Podstawy koncepcyjne
NarzĊdzia modelowania Macierz wag Ĩródeá zagroĪeĔ
Rozszerzone drzewo ataków
Aczkolwiek wskazano, Īe Ĩródáami zagroĪeĔ są Ğrodowisko, wypadki i ataki, to dalsza analiza koncentruje siĊ na zagroĪeniach zamierzonych, których Ĩródáami są ataki. Proponowaną koncepcjĊ metodologii przedstawiono na rysunku 3. Rozpatruje siĊ szkody na majątku, ryzyko powstania szkody, podatnoĞü na szkodĊ, Ĩródáa zagroĪenia i ataki.
KoncepcjĊ macierzy zagroĪenia – koszty przedstawiono w tablicy 2.
Podstawy matematyczne obejmują fundamentalne zaleĪnoĞci wynikające z rachunku prawdopodobieĔstwa; niestety nie przywoáano Īadnej bazy danych.
Rys. 3. Schemat pojĊü i atrybutów analizy ryzyka
Tab. 2. Macierz zagroĪenia – koszty
ħródáo zagroĪenia A ħródáo zagroĪenia B ħródáo zagroĪenia C Koszt WKA WKB WKC TrudnoĞü WTA WTB WTC WykrywalnoĞü WWA WWB WWC 4.3. Metoda CORAS [23]
Metoda ta zostanie zaprezentowana w skrócie jako reprezentant metod wymienionych w [4]. Badanie metodą CORAS jest przeprowadzane przez zespóá zewnĊtrzny wzglĊdem ocenianego
obiektu. Do modelowania celów analizy stosuje siĊ jĊzyk UML (Unified Modelling
Language), wyniki są prezentowane za pomocą specjalnych wykresów. Badanie jest
wykonywane w siedmiu krokach:
ħródáo zagroĪenia Motywacja DoĞwiadczenie Zasoby ZagroĪenie Koszty WartoĞü sieci Koszty naprawy Straty na opinii Straty operacyjne Straty prawne szkoda PodatnoĞü Ryzyko Konsekwencje Prawdopodo bieĔstwo Atak Koszt TrudnoĞü WykrywalnoĞü oddziaáywania
x krok 1 – spotkanie wprowadzające: wskazanie przez przedstawicieli klienta caákowitych celów analizy, obiektów do przeanalizowania oraz przekazanie informacji o przedmiocie analizy;
x krok 2 – spotkania oddzielne z poszczególnymi grupami przedstawicieli klienta, przedstawienie przez analistów rozumienia sprawy i bardzo zgrubnych, ogólnych wyników analizy, a ponadto pierwsze zidentyfikowanie zagroĪeĔ, sáaboĞci, scenariuszy rozwoju zagroĪeĔ i zdarzeĔ niepoĪądanych;
x krok 3 – dokáadniejsze opisanie obiektów do przeanalizowania oraz zaáoĪeĔ i wniosków wstĊpnych; zakoĔczenie kroku nastĊpuje po zaakceptowaniu dotychczasowych wyników przez klienta;
x krok 4 – ten krok jest organizowany jako warsztaty projektowane przez osoby zorientowane w obiekcie analizy, celem jest zidentyfikowanie jak najwiĊkszej liczby potencjalnych zdarzeĔ niepoĪądanych, a takĪe zagroĪeĔ, sáaboĞci i scenariuszy rozwoju zagroĪeĔ;
x krok 5 – ten krok teĪ jest organizowany jako warsztaty, których celem jest estymacja konsekwencji i prawdopodobieĔstwa wystąpienia wczeĞniej zidentyfikowanych zdarzeĔ niepoĪądanych;
x krok 6 – w tym kroku zostaje przedstawiony klientowi pierwszy obraz ryzyka caákowitego, który z reguáy wymaga jeszcze poprawek i doprecyzowania;
x krok 7 – jest przeznaczony na identyfikacjĊ zabezpieczenia oraz wskazanie kosztów wzglĊdem korzyĞci z nich; wskazane jest teĪ zorganizowanie go jako warsztatów.
5. PRZ EGLĄD PROPONOWANYCH METOD Z TECHNIKI BEZPI ECZEēSTWA FUNKCJONALNEGO
5.1. Ustalenie ryzyka akceptowanego
Podstawową wadą przedstawionych powyĪej propozycji jest niewyeksponowanie etapu ustalenia ryzyka akceptowanego. Bez tego nie moĪna okreĞliü dostatecznoĞci zabezpieczeĔ istniejących i dalszych, potrzebnych.
Vavoulas i Xenakis [4] wymieniają grupy kosztów, jakie moĪe ponieĞü korporacja w wyniku awarii sieci informatycznej (patrz rys. 3) . Do tych grup naleĪy dodaü: wypadki przy pracy i w wyniku awarii sieci (urazy, inwalidztwa, zgony) oraz straty w Ğrodowisku, gdy awaria infrastruktury informatycznej spowoduje awariĊ w przedsiĊbiorstwie stwarzającym zagroĪenie dla Ğrodowiska lub w sieci energetycznej.
Ryzyko akceptowane to jest ten poziom ryzyka, który moĪe przyjąü korporacja lub kraj w przypadku, np. sieci energetycznej elektrycznej, gazociągów, zaopatrzenia w wodĊ.
Poziom ten ustala siĊ miĊdzy innymi na podstawie [3, 11e, 12c]:
x wytycznych odpowiedniej jednostki okreĞlającej przepisy bezpieczeĔstwa,
x dyskusji i uzgodnieĔ z róĪnymi stronami zaangaĪowanymi w konkretne zastosowanie, x norm i przewodników przemysáowych, telekomunikacyjnych i innych odpowiednich, x miĊdzynarodowych dyskusji i uzgodnieĔ; w tym rozmaitych wytycznych i rekomendacji
wydawanych przez organizacje miĊdzynarodowe i krajowe,
x wyników prac badawczych prowadzonych ostatnio w wielu konsorcjach miĊdzynarodowych i w ramach programów rządowych ,
x najlepszych niezaleĪnych porad przemysáowych, eksperckich i naukowych ze strony instytucji doradczych,
x wymagaĔ prawnych, tak ogólnych jak i dotyczących bezpoĞrednio konkretnego zastosowania.
Przykáadowy diagram ustalania ryzyka tolerowanego przedstawiono na rys. 4 [25].
START ANALIZA DANYCH WEJĝCIOWYCH Dyrektywa 96/82/WE Ustawa Prawo Ochrony ĝrodowiska Normy dotyczące poziomu emisji zanieczyszczeĔ Wymagania ubezpieczycieli Uzgodnienia lokalne Polityka jakoĞci korporacji Inne dotyczące sprawy Zbieranie danych Ustalenie ryzyka docelowego tolerowanego KONIEC
5.2. Ogólna zasada zmniejszania ryzyka [3, 11a, 12a]
Na rys. 5 przedstawiono ogólny schemat zmniejszania ryzyka, który zakáada, Īe: x wystĊpuje urządzenie sterowane i jego system sterowania;
x są wprowadzone powiązane czynniki ludzkie;
x na urządzenia ochronne/zabezpieczające skáadają siĊ: zewnĊtrzne urządzenia do zmniejszania ryzyka;
elektryczne i/lub elektroniczne i/lub elektroniczne programowalne systemy związane z bezpieczeĔstwem (E/E/PE), w tym przyrządowe systemy bezpieczeĔstwa (SIS);
urządzenia związane z bezpieczeĔstwem wykonane w innych technikach.
Schemat przedstawiony na rys. 5 powinien byü modyfikowany w konkretnych przypadkach tak, aby odzwierciedlaá rzeczywistą sytuacjĊ. Odpowiednia modyfikacja umoĪliwi dostosowanie go do zagadnieĔ bezpieczeĔstwa i zabezpieczenia sieci informatycznych.
RóĪne rodzaje ryzyka wskazane na schemacie mają nastĊpujące znaczenie:
x ryzyko urządzenia/procesu – ryzyko, w odniesieniu do okreĞlonego zdarzenia zagraĪającego, istniejące w urządzeniu/procesie, systemie sterowania urządzeniem/procesem i powiązanymi z nim czynnikami ludzkimi, przy czym nie jest brane pod uwagĊ Īadne wyposaĪenie ochronne/zabezpieczające
x ryzyko tolerowane – ryzyko, które jest akceptowane w okreĞlonym kontekĞcie na bazie bieĪących wskaĨników przyjĊtych w spoáeczeĔstwie
x ryzyko szczątkowe – w rozumieniu IEC 61508-5 [11e] jest to ryzyko, w odniesieniu do okreĞlonego zdarzenia zagraĪającego, pozostające w wyposaĪeniu/procesie, systemie sterowania urządzeniem/procesem i powiązanymi z nim czynnikami ludzkimi, lecz po wprowadzeniu kompletnego wyposaĪenia ochronnego/zabezpieczającego.
Rys. 5. Zasada zmniejszania ryzyka [3]
Ryzyko resztkowe
Ryzyko tolerowane
Konieczne zmniejszenie ryzyka OsiągniĊte zmniejszenie ryzyka CzĊĞü ryzyka usuniĊta
przez systemy wiąĪące siĊ z bezpieczeĔstwem wykonane w innych technikach CzĊĞü ryzyka usuniĊta przez systemy E/E/PE związane siĊ z bezpieczeĔstwem CzĊĞü ryzyka usuniĊta przez zewnĊtrzne urządzenia do redukcji ryzyka
Zmniejszenie ryzyka osiągniĊte za pomocą wyposaĪenia ochronnego/zabezpieczającego
Ryzyko wyposaĪenia
Wskazane wyĪej ryzyko urządzenia/procesu, w przypadku sieci informatycznej bĊdzie
odpowiadaáo ryzyku uszkodzenia sieci niezabezpieczonej ani sprzĊtowo, ani programowo przed uszkodzeniami wáasnymi i dziaáaniem intruzów.
5.3. Identyfikacja potencjalnych zagroĪeĔ
Do identyfikacji potencjalnych zagroĪeĔ wynikających z dziaáania czynników zewnĊtrznych jak teĪ z niedoskonaáoĞci dziaáania systemu w technice bezpieczeĔstwa funkcjonalnego stosuje siĊ studium HAZOP (Badanie zagroĪeĔ i zdolnoĞci do dziaáania) [3, 13]. Jest ono zbliĪone do metody CORAS [23] oraz do metod ontologicznych [8], jednak ma pewne waĪne zalety.
Istotnymi cechami tego studium HAZOP jest praca zespoáowa wykonywana przez zespóá interdyscyplinarny záoĪony w zasadzie z pracowników korporacji. Zasady HAZOP są nastĊpujące:
x Badanie prowadzi siĊ przez systematyczne stosowanie ciągu sáów wiodących w celu identyfikowania potencjalnych odchyleĔ od zamierzenia projektowego i uĪywania tych odchyleĔ do stymulowania czáonków zespoáu do rozpatrzenia, jak takie odchylenie mogáoby powstaü i jakie mogáoby wywoáaü konsekwencje.
x Badanie jest prowadzone pod kierunkiem wyszkolonego i doĞwiadczonego lidera, który musi
zapewniü wyczerpującą analizĊ badanego systemu, stosując rozumowanie logiczne i analityczne. Z badania powstają zapisy o zidentyfikowanych zagroĪeniach i/lub zaburzenia dziaáania w celu dalszego badania i rozwiązania problemu.
x Badanie jest wykonywane przez specjalistów z róĪnych dziedzin mających odpowiednie wyszkolenie i doĞwiadczenie, dysponującymi intuicją i dobrym sądem.
x Badanie przeprowadza siĊ w atmosferze myĞlenia pozytywnego i otwartej dyskusji – rozpatrzenie zidentyfikowanych problemów odkáada siĊ na póĨniej; problem, który zostaá zidentyfikowany, zostaje zapisany i nastĊpnie problemy są kolejno oceniane i rozwiązywane.
x Zalecenia do rozwiązania zidentyfikowanych problemów nie są pierwszoplanowym celem badania HAZOP, lecz mogą zostaü zapisane do rozwaĪenia przez osoby odpowiedzialne za projekt.
Badanie HAZOP skáada siĊ z czterech kolejnych kroków, jak to pokazano na rys. 6.
Podstawą HAZOP jest „badanie wedáug sáów wiodących”, które jest przemyĞlanym poszukiwaniem odchyleĔ od zamierzenia projektowego. W celu uáatwienia badania system dzieli siĊ na czĊĞci w taki sposób, aby zamierzenie projektowe dotyczące kaĪdej z nich mogáo byü odpowiednio zdefiniowane. Rozmiar wybranych czĊĞci zaleca siĊ dobieraü zaleĪnie od záoĪonoĞci systemu i ostroĞci zagroĪeĔ. W przypadku systemów záoĪonych lub powodujących wysokie zagroĪenie, czĊĞci powinny byü maáe. W przypadku systemów prostych, o niskich zagroĪeniach, przyjĊcie duĪych czĊĞci usprawni badanie. Zamierzenie projektowe dotyczące okreĞlonej czĊĞci systemu wyraĪa siĊ przez elementy, które dają pojĊcie o jej istotnych wáaĞciwoĞciach i przedstawiają jej naturalny podziaá. Wybór elementów do zbadania jest do pewnego stopnia decyzją subiektywną, która moĪe mieü kilka kombinacji prowadzących do uzyskania wymaganego zamierzenia i wybór moĪe takĪe zaleĪeü od konkretnego zastosowania. Elementami mogą byü;
x
dyskretne kroki lub etapy w procedurze,x
pojedyncze sygnaáy lub urządzenia w systemie sterowania,x
materiaáy wejĞciowe otrzymywane ze Ĩródáa,x
czynnoĞci wykonywane na materiaáach,x
produkt przekazywany do ujĞcia.CzĊsto moĪe byü uĪytecznym dalsze zdefiniowanie elementów przez ich charakterystyki iloĞciowe lub jakoĞciowe.
.
Rys. 6. Schemat realizacji HAZOP [13]
Zespóá HAZOP bada kaĪdy element (i parametry, gdy są istotne) z punktu widzenia odchyleĔ od zamierzenia projektowego, które mogą prowadziü do niepoĪądanych konsekwencji. IdentyfikacjĊ odchyleĔ od zamierzenia projektowego osiąga siĊ przez „przepytywanie” systemu za pomocą przygotowanych „sáów wiodących”. Zadaniem sáów wiodących jest stymulowanie myĞlenia obrazowego, w celu zogniskowania studium i wydobycia idei i spowodowania dyskusji, a tym samym doprowadzenia do maksimum szans na kompletnoĞü studium.
Definicja x Zdefiniowanie przedmiotu i celów
x Zdefiniowanie odpowiedzialnoĞci x Wybranie zespoáu Przygotowanie x Zaplanowanie studium x Zebranie danych x Oszacowanie czasu x Opracowanie harmonogramu x Zaplanowanie zapisów Badanie x Podzielenie systemu na czĊĞci
x Wybranie czĊĞci i zdefiniowanie zamierzenia projektowego
x Zidentyfikowanie odchyleĔ za pomocą sáów wiodących dotyczących kaĪdego
elementu
x Zidentyfikowanie konsekwencji i przyczyn x Zidentyfikowanie, czy istnieją istotne problemy
x Zidentyfikowanie mechanizmów ochrony, wykrywania i wskazywania
x Zidentyfikowanie moĪliwych Ğrodków zaradczych lub ograniczających skutki
(opcjonalne)
x Uzgodnienie dziaáaĔ
x Powtórzenie w odniesieniu do kaĪdego elementu i kaĪdej czĊĞci systemu
Dokumentowanie i dalsze postĊpowanie x Uzgodnienie treĞci zapisów
x Podpisanie dokumentacji x Sporządzenie raportu z badania
x Doprowadzenie do zaimplementowania dziaáaĔ
x Przeprowadzenie powtórnego badania dowolnej czĊĞci, gdy to konieczne x Opracowanie raportu koĔcowego
5.4. Scenariusze rozwoju zagroĪeĔ
Metoda póáiloĞciowa analizy ryzyka [3, 12c] wykorzystuje scenariusze rozwoju zagroĪeĔ. Przykáad przedstawiono na rys. 7.
NadciĞnienie
Alarm wyso-
kiego ciĞnienia OdpowiedĨ operatora
Warstwa za bezpieczeĔ Sukces 3. Zrzut do Ğrodowiska, 9 x 10–4 /rok 5. Zrzut do Ğrodowiska, 1 x 10-3 /rok
2. Zrzut z warstwy zabezpieczeĔ do flary, 8 x 10–3 /rok
4. Zrzut z warstwy zabezpieczeĔ do flary, 9 x 10–3 /rok 1. Nie ma zrzutu do flary, 8 x 10–2/rok
Uszkodzenie 10–1/rok 0,9 10–1 0,9 10–1 0,9 0,9 10–1 10–1
Rys. 7. Przykáadowy scenariusz rozwoju zagroĪeĔ
W tym konkretnym przypadku nie zostaáy speánione wymagania dotyczące ryzyka
tolerowalnego (10-4), wobec czego wprowadzono nowe zabezpieczenie i otrzymano kolejny
scenariusz – patrz rys. 8.
W tym przypadku wymagania dotyczące ryzyka tolerowanego zostaáy speánione.
Przedstawione przykáady wskazują na moĪliwoĞü opracowania analogicznych scenariuszy dostosowanych do specyfiki sieci informatycznych.
5. Nie ma zrzutu do flary, 1 x 10–2/rok
6. Zrzut do flary, 9 x 10–5/rok
7. Uszkodzenie zbiornika i zrzut do Ğrodowiska, 1 x 10–5/rok
NadciĞnienie 10–1/rok
CzĊstoĞü i konsekwencje
4. Uszkodzenie zbiornika I zrzut do Ğrodowiska, 9 x 10–6/year
1. Nie ma zrzutu do flary, 8 x 10–2/rok
2. Nie ma zrzutu do flary, 9 x 10–3/rok 3. Zrzut do flary, 8 x 10–5/rok
0,9 0,9 0,9 0,99 0,9 0,99 10–1 10–2 10–1 10–1 10–2 10–1 Funkcja bezpie-czeĔstwa Warstwa zabezpie-czeĔ OdpowiedĨ operatora Alarm wysokiego ciĞnienia
Rys. 8. Przykáadowy scenariusz rozwoju zagroĪeĔ
5.5. Zasada Tak Niskie Jak Rozsądnie Uzasadnione (ALARP) [3, 12c]
W sytuacji rzeczywistej instalacji (np. procesowej lub sieci informatycznej) mogą wystąpiü trzy sytuacje wykrywane przy analizie zagroĪeĔ i ryzyka:
a. ryzyko jest tak duĪe, Īe w ogóle odrzuca siĊ moĪliwoĞü eksploatowania obiektu, b. ryzyko jest lub moĪe byü tak maáe, Īe moĪna je uwaĪaü za bez znaczenia,
c. ryzyko mieĞci siĊ miĊdzy stanami a i b, i moĪe zostaü zmniejszone do najniĪszego praktycznie uzasadnionego poziomu, mając na wzglĊdzie korzyĞci wynikające z jego zaakceptowania i biorąc pod uwagĊ koszty dalszej redukcji.
W odniesieniu do przypadku c zasada ALARP zaleca, aby dowolne ryzyko zostaáo zredukowane do poziomu tak niskiego, jak to jest rozsądnie wykonalne. JeĞli ryzyko mieĞci siĊ miĊdzy wymienionymi wyĪej dwiema skrajnoĞciami i zastosowano zasadĊ ALARP, to ryzyko wynikowe jest ryzykiem dopuszczalnym w danej konkretnej sytuacji.
Ryzyko powyĪej pewnego poziomu uznaje siĊ za niedopuszczalne i nie moĪe byü ono usprawiedliwione Īadnymi zwykáymi okolicznoĞciami.
PoniĪej tego poziomu jest obszar tolerowania, w którym jest dopuszczalna dziaáalnoĞü w zaáoĪeniu, Īe związane z nią ryzyko zostaáo zmniejszone tak, jak to jest rozsądnie wykonalne. Tolerowane oznacza co innego niĪ dopuszczalne (akceptowalne) – wskazuje na chĊü Īycia z ryzykiem, tak by chroniü pewne korzyĞci, jednoczeĞnie spodziewając siĊ, Īe bĊdzie ono analizowane i redukowane jak tylko bĊdzie to moĪliwe do wykonania. W tej sytuacji zaleca siĊ stosowanie rachunku ekonomicznego, albo bezpoĞrednie, albo poĞrednie, w celu wywaĪenia kosztów i uzyskiwanych korzyĞci uzasadniających wprowadzenie dodatkowych Ğrodków zabezpieczających/ochronnych lub zaniechanie tego dziaáania.
PoniĪej zakresu tolerancji, poziom ryzyka jest uwaĪany za na tyle nieznaczący, Īe organ wydający przepisy nie potrzebuje Īądaü dalszych ulepszeĔ. Jest to powszechnie akceptowalny obszar, w którym ryzyko jest maáe w porównaniu do codziennego ryzyka, które wszyscy ponosimy. Aczkolwiek w tym powszechnie akceptowalnym obszarze nie ma potrzeby szczegóáowego dziaáania w celu wykazania speánienia zasady ALARP, to jednakĪe jest konieczne staáe czuwanie, aby ryzyko pozostawaáo w tym obszarze.
Koncepcja ALARP moĪe byü stosowana gdy przyjĊto tak jakoĞciowe jak i iloĞciowe cele przy okreĞleniu ryzyka. Szersze informacje są zawarte w normie [12.c]. Przykáadem stosowania zasady ALARP z podaniem kategoryzacji ryzyka jest norma kolejowa [9]. Zdefiniowano w niej 24 klasy ryzyka przypisując do nich wymagane poziomy nienaruszalnoĞci bezpieczeĔstwa wyposaĪenia związanego z bezpieczeĔstwem [11a], co zestawiono w tablicy 3.
Tablica 3 – Kategoryzacja klas ryzyka wg PN-EN 50128 [9]
WskaĨniki zdarzeĔ zagraĪających – Poziomy nienaruszalnoĞci bezpieczeĔstwa POZIOMY CZĉSTOĝCI ZDARZEē
Poziom ostroĞci zdarzenia CzĊsty Prawdo-podobny Okazjonalny Przypad-kowy Niepraw-dopodobny Niewiary-godny
Katastrofi-czny 1 – SIL4 2 – SIL4 3 – SIL3 4 – SIL3 5 – SIL3 6 – SIL2
Krytyczny 7 – SIL4 8 – SIL3 9 – SIL3 10 – SIL3 11 – SIL2 12 – SIL2
Marginalny 13 – SIL3 14 – SIL3 15 – SIL3 16 – SIL2 17 – SIL2 18 – SIL1
Poziomy 1, 2, 7 są uznane za nietolerowane (ryzyko bardzo wysokie), poziomy 3, 4, 5, 8, 9, 10, 13, 14, 14, 19 i 20 uznano za niepoĪądane (ryzyko wysokie), poziomy 6, 11, 12, 16, 17, 21, 22 – za tolerowane (ryzyko Ğrednie) zaĞ poziomy 18, 23 i 24 za pomijalne (ryzyko niskie). Tego rodzaju kategoryzacja moĪe byü wykorzystana w metodach proponowanych przez Vavoulasa i Xenakisa [4] oraz ChoádĊ i Jajszczyka [5].
5.6. Analiza warstw zabezpieczeĔ
Sieü informatyczna jest zabezpieczana na wiele sposobów, tak sprzĊtowo, jak i programowo. Stosowane zabezpieczenia tworzą „warstwy zabezpieczeĔ”. Do analizy skutecznoĞci i dostatecznoĞci wprowadzonych i/lub przewidzianych zabezpieczeĔ moĪe posáuĪyü metoda
LOPA (Layer of Protection Analysis) [3, 12c]. Danymi wejĞciowymi metody są dane
uzyskane w Badaniu HAZOP [13]; nastĊpnie uwzglĊdnia siĊ kaĪde zidentyfikowane zagroĪenie, przez udokumentowanie, przyczyny inicjującej i warstw zabezpieczenia zapobiegających lub ograniczających zagroĪenie. Tym samym moĪe zostaü okreĞlony caákowity istniejący zakres redukcji ryzyka i przeanalizowana potrzeba jego dalszego zmniejszenia. LOPA jest metodą realizowaną przez zespóá multidyscyplinarny do okreĞlenia dostatecznoĞci zabezpieczeĔ. W przypadku analizy sieci informatycznej zespóá powinien skáadaü siĊ z:
x operatora doĞwiadczonego w prowadzeniu rozpatrywanego rodzaju sieci, x inĪyniera z doĞwiadczeniem w rozpatrywanym rodzaju sieci,
x menedĪera sieci,
x inĪyniera automatyka procesu sterowanego rozpatrywaną siecią,
x osoby serwisu przyrządów/elektrycznego z doĞwiadczeniem w zakresie rozwaĪanego rodzaju sieci i procesu sterowanego,
x specjalisty ds. analizy ryzyka.
Jeden z czáonków zespoáu powinien byü przeszkolony w metodologii LOPA.
Informacje wymagane przez LOPA są zawarte w danych zgromadzonych i opracowanych w HAZOP. W tablicy 4 przedstawiono zaleĪnoĞü miĊdzy danymi wymaganymi przez LOPA i danymi opracowanymi w czasie HAZOP. Na rys. 9 przedstawiono typowy arkusz kalkulacyjny, który moĪe byü zastosowany do LOPA. WartoĞci liczbowe zamieszczone w tym arkuszu są przykáadowe.
Tablica 4 – Dane do LOPA opracowane w HAZOP
Informacje wymagane przez LOPA Informacje opracowane w HAZOP
Zdarzenie oddziaáujące Konsekwencja
Poziom ostroĞci OstroĞü konsekwencji
Przyczyna inicjująca Przyczyna
PrawdopodobieĔstwo zainicjowania CzĊstoĞü zaistnienia przyczyny
Warstwy zabezpieczeĔ Zabezpieczenia istniejące
# 1 2 3 4 5 6 7 8 9 10 11 WARSTWY ZABEZPIECZEē Opis zdarzenia oddziaáującego F.3 F.14.1 Poziom ostroĞci F.4 F.14.1 Przyczyna inicjująca F.5 F.14.2 PrawdopodobieĔstwo zainicjowania F.6 F.14.3 Ogólny projekt procesu F.14.4 BPCS F.14.5Alarmy itp. F.14.6 Ograniczenie dodatkowe, dostĊp ograniczony, F.8 F.14.7 IPL Dodatkowe tamy ogranicz., dekompresja F.9 F.14.8 PrawdopodobieĔstwo Ğrednie zdarzenia F.10 F.14.9 Poziom nienaruszalnoĞci SIF F.11 F.14.10 PrawdopodobieĔstwo zdarzenia ograniczającego F.12 F.14.10 Uwagi 1 OgieĔ z pĊkniĊcia kolumny destylacyjnej S Brak dopáywu wody cháodzącej 0,1 0,1 0,1 0,1 0,1 PRV 01 10í7 10í2 10í9 Wysokie ciĞnienie powoduje pĊkniĊcie kolumny 2 OgieĔ z pĊkniĊcia kolumny destylacyjnej S Uszkodzenie pĊtli regulacji pary 0,1 0,1 0,1 01 PRV 01 10í6 10í2 10í8 To samo co wyĪej N
UWAGA Poziom ostroĞci: E = Rozlegáy; S = PowaĪny; M = Niewielki
WartoĞci prawdopodobieĔstwa są liczbami zdarzeĔ na rok, inne wartoĞci liczbowe są Ğrednimi prawdopodobieĔstwami uszkodzenia przy przywoáaniu
Rys. 9. Raport Analizy Warstw ZabezpieczeĔ (LOPA)
6. PODSUMOWANIE
Wykazano zbieĪnoĞü metod stosowanych w technice bezpieczeĔstwa funkcjonalnego do analizy ryzyka i oceny dostatecznoĞci zabezpieczeĔ z potrzebami, jakie siĊ ujawniáy w związku z podobnymi ocenami sieci informatycznych. Zaproponowano zastosowanie niektórych metod. Przedstawione tu propozycje bĊdą rozwijane.
Opracowanie zostaáo sfinansowane w ramach zadania 4.R.08 „Modele i procedury oceny zgodnoĞci bezpieczeĔstwa funkcjonalnego systemów zabezpieczeniowych sektorze przemysáu procesowego” Programu Wieloletniego „Poprawa bezpieczeĔstwa i warunków pracy” koordynowanego przez CIOP-PIB.
BIBLIOGRAFIA
1. Missala T.: Zabezpieczenie sieci przemysáowych przed intruzami – temat dnia.
Pomiary, Automatyka, Robotyka nr 2/2010, s. 180–189.
2. Missala T.: Walidacja záoĪonych systemów automatyki i robotyki. Pomiary,
Automatyka, Robotyka nr 2/2009, s. 201–213.
3. Missala T.: Analiza wymagaĔ i metod postĊpowania przy ocenie ryzyka i okreĞlaniu
wymaganego poziomu nienaruszalnoĞci bezpieczeĔstwa. Monografia. Przemysáowy
Instytut Automatyki i Pomiarów. Warszawa, 2009 r.
4. Vavoulas N., Xenakis Ch.: A Quantitative Risk Analysis Approach for deliberate Threats. Conference Pre-Proceedings, 5th International Workshop on Critical Information
Infrastructures Security, CRITIS’10, Athens, 2010 r., s. 13–26.
5. Choáda P., Jajszczyk A.: Resilience metrics. Presentation on the special session of 4th
International Workshop on Critical Information Infrastructures Security, CRITIS’09, Athens, 2010 r.
6. Duessel P. et all.: Cyber-Critical Infrastructure Protection Using Real-time
Payoload-Based anomaly Detection., 4th International Workshop on Critical Information Infrastructures Security, CRITIS’09, Bonn, 2009 r., Springer, Conference Revised Papers, s. 85–97.
7. Batista Jr. A.B. et all.: Application Filters for TCP/IP Industrial Automation Protocols.
4th International Workshop on Critical Information Infrastructures Security, CRITIS’09,
Bonn, 2009 r.,Springer,Conference Revised Papers, s. 111–123.
8. ChoraĞ M. et all.: Ontology-Based Reasoning Combined with Inference Engine for
SCADA-ITC Independencies, Vulnerabilities and Treats Analysis. 4th International Workshop on Critical Information Infrastructures Security, CRITIS’09, Bonn, 2009 r.,
Springer, Conference Revised Papers, s. 98–110.
9. PN-EN 50128:2002, Zastosowania kolejowe – àącznoĞü, sygnalizacja i systemy
sterowania – Programy dla kolejowych systemów sterowania i zabezpieczenia (oryg.).
10. PN-EN 61069, Pomiary i sterowanie procesami przemysáowymi – OkreĞlenie wáaĞciwoĞci systemu w celu jego oceny.
a. PN-EN 61069-1:2002, CzĊĞü 1: Postanowienia ogolne i metodologia. b. PN-EN 61069-2:2002, CzĊĞü 2: Metodologia oceny.
c. PN-EN 61069-3:2002, CzĊĞü 3: Ocena funkcjonalnosci systemu. d. PN-EN 61069-4:2002, CzĊĞü 4: Ocena parametrów systemu. e. PN-EN 61069-5:2004, CzĊĞü 5: Ocena niezawodnoĞci systemu.
f. PN-EN 61069-6:2004, CzĊĞü 6: Ocena wspóádziaáania systemu z operatorem. g. PN-EN 61069-7:2004, CzĊĞü 7: Ocena bezpieczeĔstwa systemu.
h. PN-EN 61069-8:1004, CzĊĞü 8: Ocena niewiąĪących siĊ z zadaniem wáaĞciwoĞci systemu. 11. PN-EN 61508 (IEC 61508): BezpieczeĔstwo funkcjonalne elektrycznych/
elektronicznych/ programowalnych elektronicznych systemów związanych z bezpieczeĔstwem:
a PN-EN 61508-1:2010 CzĊĞü 1:Wymagania ogólne (oryg.).
b PN-EN 61508-2:2010 CzĊĞü 2: Wymagania dotyczące elektrycznych/elektronicznych/
programowalnych elektronicznych systemów związanych z bezpieczeĔstwem (oryg.).
c PN-EN 61508-3:2010 CzĊĞü 3: Wymagania dotyczące oprogramowania (oryg.).
d PN-EN 61508-4:2010 CzĊĞü 4: Definicje i skrótowce (oryg.).
e PN-EN 61508-5:2010 CzĊĞü 5: Przykáady metod okreĞlania poziomów
f PN-EN 61508-6:2010 CzĊĞü 6: Wytyczne do stosowania IEC 61508-2 i IEC 61508-3
(oryg.).
g PN-EN 61508-7:2010 CzĊĞü 7: Przegląd technik i miar (oryg.).
12. PN-EN 61511 (IEC 61511): BezpieczeĔstwo funkcjonalne – Przyrządowe systemy bezpieczeĔstwa do sektora przemysáu procesowego:
a. PN-EN 61511-1:2005 CzĊĞü 1: Schemat, definicje, wymagania dotyczące systemu, sprzĊtu i oprogramowania.
b. PN-EN 61511-2:2008 CzĊĞü 2 : Wytyczne do stosowania IEC 61511-1.
c. PN-EN 61511-3:2009 CzĊĞü 3: Wytyczne do okreĞlania poziomów nienaruszalnoĞci bezpieczeĔstwa .
13. PN-EN 61882:2005, Badanie zagroĪeĔ i zdolnoĞci do dziaáania (badania HAZOP) – Przewodnik zastosowaĔ.
14. PN-EN ISO 9000:2006, Systemy zarządzania jakoĞcią – Podstawy i terminologia.
15. PN-ISO/IEC 27001:2007, Technika informatyczna – Techniki bezpieczeĔstwa – Systemy zarządzania bezpieczeĔstwem – Wymagania.
16. PN –ISO/IEC 13332-1:2004, Information technology – Security techniques – Management of information and communications technology security – Part 1: Concepts and models for information and communications technology security management.
17. ITU-T E800, Telecommunication Standardization Sector of ITU, (09/2008) – Series E: Overall network operation, Telephone service, service operation and human factors – Quality of telecommunication services: concepts, models, objectives and dependability planning – Terms and definitions related to the quality of telecommunication services – Definitions of terms related to quality of service. Recommendation ITU.
18. ISA-100.11a-2009, An ISA Standard – Wireless systems for industrial automation: Process control and related application.
19. IEC 62443-1-1: 2009: Industrial communication networks – network and system security – Part 1-1: Terminology, concepts and models.
20. IEC 62443-2-1(65/438/CDV: Industrial communication networks – network and system security – Part 2-1: Establishing an industrial automation and control system security program.
21. IEC/TR 662443-3-1:2009: Industrial communication networks – network and system security – Part 5: Security technologies for industrial automation and control systems.
22. NIST National Institute of Standard and Technology; USA – SP 800-30: Risk Management Guide for Information Technology Systems – Recommendations, July 2002.
23. The CORAS Method [http://coras.souceforge.net/].
24. Facilitated Risk Analysis Process (FRAP) [www.wikipedia.org/Risk_analysis_(buissnes)]. 25. Model krok po kroku [www.piap.pl/certyfikacja].
