Specyfikowanie systemów krytycznych

Prezentacja na temat: "Specyfikowanie systemów krytycznych"— Zapis prezentacji:

1 Specyfikowanie systemów krytycznych
Celem tego rozdziału jest wyjaśnienie, jak specyfikować wymagania funkcjonalne i niefunkcjonalne wobec pewności.

2 Cele Znać kilka miar służących do określania niezawodności i wiedzieć, jak należy ich używać do specyfikowania wymagań niezawodnościowych. Wiedzieć, jak z analizy ryzyka i zagrożeń wywnioskować wymagania stawiane bezpieczeństwu systemów krytycznych. Znać podobieństwa między procesami specyfikowania wymagań stawianych bezpieczeństwu i zabezpieczeniu.

3 Zawartość Specyfikowanie niezawodności systemu
Specyfikowanie bezpieczeństwa Specyfikowanie zabezpieczenia

4 Jakość specyfikacji systemów krytycznych
Z powodu wysokiego kosztu awarii systemu trzeba sprawić, by specyfikacja systemu krytycznego miała wysoką jakość i precyzyjnie odzwierciedlała prawdziwe potrzeby użytkowników systemu.

5 Pewność systemów krytycznych
Oczekiwanie pewności systemów krytycznych prowadzi do wymagań funkcjonalnych i niefunkcjonalnych: Systemowe wymagania funkcjonalne mogą być definicjami udogodnień do wykrywania błędów i odtwarzania oraz definicjami właściwości systemu, które chronią go przed awariami. Wymagania niefunkcjonalne mogą być definicjami wymaganej niezawodności i dostępności systemu.

6 Wymagania typu „nie będzie”
Służą do określenia nieakceptowalnych zachowań systemu. Oto przykłady takich wymagań: System nie będzie umożliwiał użytkownikom modyfikowania praw dostępu do plików, których nie utworzyli (zabezpieczenie). System nie będzie umożliwiał wybrania trybu wstecznej siły ciągu, gdy samolot jest w powietrzu (bezpieczeństwo). System nie będzie umożliwiał jednoczesnego uruchomienia więcej niż trzech sygnałów alarmowych (bezpieczeństwo).

7 Specyfikowanie niezawodności systemu
Niezawodność jest złożonym pojęciem, które zawsze należy rozważać na poziomie systemu, a nie poszczególnych komponentów. Komponenty systemu zależą od siebie nawzajem, awaria jednego z nich może się więc przenieść na cały system i wpłynąć na działanie innych komponentów.

8 Wymiary, które należy wziąć pod uwagę przy specyfikowaniu niezawodności
Niezawodność sprzętu. Jakie jest prawdopodobieństwo awarii komponentu sprzętowego i jak dużo czasu potrzeba na jej usunięcie? Niezawodność oprogramowania. Jakie jest prawdopodobieństwo wytworzenia niepoprawnego wyniku przez komponent programowy? Niezawodność operatora. Jakie jest prawdopodobieństwo popełnienia błędu przez operatora?

9 Inżynieria niezawodności oprogramowania
Jest specjalistyczna gałęzią inżynierii oprogramowania, poświęconą dokonywaniu ogólnej oceny niezawodności systemów. Bierze się w niej pod uwagę prawdopodobieństwa awarii różnych komponentów systemu i sposób ich połączenia, wpływający na całkowitą niezawodność systemu. Przyjmijmy dla uproszczenia, że system zależy od komponentów A i B z prawdopodobieństwami awarii P (A) i P (B). Wówczas całkowite prawdopodobieństwo awarii systemu P(S) wynosi: P (S) = P (A) + P (B)

10 Przykłady wymagań niezawodnościowych
Należy wyspecyfikować zakres wartości, które mogą być wprowadzone przez operatora. System będzie sprawdzał, czy wszystkie dane wejściowe otrzymane od operatora mieszczą się w tym przedziale. W procesie inicjowania system będzie sprawdzał, czy wszystkie dyski nie zawierają uszkodzonych bloków. System musi być zaimplementowany za pomocą bezpiecznego podzbioru Ady i sprawdzony za pomocą analizy statycznej.

11 Miary niezawodności Pierwsze miary niezawodności dotyczyły komponentów sprzętowych. Awarie takich komponentów są nieuchronne ze względu na czynniki fizyczne, takie jak zużycie ścierne, ogrzewanie elektryczne itd. Te miary sprzętowe nie zawsze są odpowiednie do specyfikowania niezawodności oprogramowania, ponieważ natury awarii sprzętu i oprogramowania są różne. Awarie komponentów sprzętowych są zwykle chwilowe, a nie trwałe. Pojawiają się jedynie dla pewnych danych wejściowych. Jeśli nie uszkodzono danych, to system często może kontynuować działanie po wystąpieniu awarii.

12 Miary niezawodności Miara Objaśnienie
POFOD Prawdopodobieństwo awarii przy zleceniu. Prawdopodobieństwo, że Probability system ulegnie awarii po zleceniu mu usługi. POFOD o wartości 0,001 of failure oznacza, że jedno zlecenie na tysiąc skończy się awarią. on demand ROCOF Częstotliwość występowania awarii. Częstotliwość występowania Rateof failure nieoczekiwanych zachowań. ROCOF o wartości 0,002 oznacza, że w Occurence ciągu 100 jednostek czasu działania prawdopodobnie zdarza się 2 awarie. Ta miara bywa czasem nazywana intensywnością awarii. MTTF Średni czas do awarii. Średni czas między zaobserwowanymi awariami Mean time systemu. MTTF o wartości 500 oznacza, że co 500 jednostek czasu to Failure można oczekiwać jednej awarii. AVAIL Dostępność. Prawdopodobieństwo, że system jest dostępny dla Availability użytkownika w określonej chwili. Dostępność o wartości 0,998 oznacza, że na 1000 jednostek czasu system prawdopodobnie będzie dostępny w czasie 998 jednostek.

13 Miary niezawodności Prawdopodobieństwo awarii przy zleceniu. Ta miara najbardziej nadaje się w wypadku systemów, których usługi są oczekiwane w nieprzewidywalnych i dość długich odstępach czasu, a niezrealizowanie tych usług ma poważne konsekwencje. Częstotliwość występowania awarii. Tę miarę należy używać tam, gdzie żądania usług systemu są regularne i jest ważne, aby te usługi poprawnie zrealizować. Średni czas awarii. Tę miarę należy używać w wypadku systemów z długimi transakcjami, tzn. tam gdzie ludzie używają systemu przez długi czas. Średni czas do awarii powinien być dłuższy niż średni czas trwania transmisji. Dostępność. Tę miarę warto używać w wypadku systemów działających bez przerwy, których użytkownicy oczekują ciągłej realizacji usług.

14 Rodzaje pomiarów, które można wykonać szacując niezawodność systemu
Liczba awarii systemu w czasie obsługi ustalonej liczby żądań usług. Służy do wyznaczenia POFOD. Czas (lub liczba transakcji) między awariami systemu. Służy do wyznaczania ROCOF i MTTF. Czas spędzony przy naprawie lub ponownym uruchomieniu systemu po awarii. Przy założeniu, że system musi być bez przerwy dostępny, ten pomiar umożliwia wyznaczanie AVAIL.

15 Niefunkcjonalne wymagania niezawodnościowe
W wielu dokumentacjach wymagań systemowych wymagania niezawodnościowe są niestarannie określone. Specyfikacje niezawodności są subiektywne i niemierzalne. Zdania, takie jak „Oprogramowanie powinno być niezawodne przy normalnym użytkowaniu”, nic nie znaczą. Stwierdzenia niby ilościowe są równie bezużyteczne.

16 Klasyfikacja awarii Klasa awarii Opis
Chwilowa Zdarza się tylko dla niektórych danych wejściowych Trwała Następuje dla wszystkich danych wejściowych Usuwalna System może ją usunąć bez interwencji operatora Nieusuwalna Usunięcie awarii wymaga interwencji operatora Nieniszcząca Awaria nie powoduje zniszczenia stanu i danych systemu Niszcząca Awaria powoduje zniszczenie stanu i danych systemu

17 Czynności prowadzące do opracowania specyfikacji niezawodności
Dla każdego zidentyfikowanego podsystemu należy wskazać różne rozdaje możliwych awarii systemu i zanalizować konsekwencje tych awarii. Na podstawie wyników analizy awarii systemu trzeba podzielić awarie na klasy. Dobrym punktem wyjściowym może być klasyfikacja z rysunku. Dla każdej rozpoznanej klasy awarii trzeba zdefiniować wymaganie niezawodnościowe za pomocą odpowiedniej miary niezawodności. Nie trzeba używać tej samej miary dla różnych klas. Jeśli usunięcie awarii wymaga interwencji, to jej prawdopodobieństwo przy zleceniu nie jest najlepszą miarą. Tam gdzie trzeba, należy określić niezawodnościowe wymagania niefunkcjonalne, w których wskaże się funkcjonalność systemu umożliwiającą zmniejszenie prawdopodobieństwa awarii krytycznych.

18 Przykład specyfikacji niezawodności
Rozważmy wymagania niezawodnościowe stawiane bankomatowi. Przypuśćmy, że każda maszyna w sieci jest używana około 300 razy dziennie. Czas życia sprzętu systemu wynosi osiem lat, a oprogramowanie jest aktualizowane średnio raz na dwa lata. W czasie działania jednej wersji oprogramowania każda maszyna obsługuje około transakcji. Sieć banku składa się z 1000 maszyn. Oznacza to, że dziennie następuje transakcji w centralnej bazie danych (około 100 milionów rocznie). Awarie dzieli się na dwie duże klasy: te, które wpływają na jedną maszynę w sieci, oraz te, które wpływają na bazę danych, a zatem na wszystkie bankomaty w sieci.

19 Specyfikacja niezawodności bankomatu
Klasa awarii Przykład Miara niezawodności Trwała System nie działa z żadną wsuwaną ROCOF nieniszcząca kartą. Usunięcie awarii wymaga ponownego zdarzenie/1000 dni uruchomienia oprogramowania. Chwilowa Pasek magnetyczny nieuszkodzonej ROCOF nieniszcząca wsuniętej karty nie może być odczytany 1 na 1000 transakcji Trwała Zestaw jednoczesnych transakcji w sieci Niemierzalna! Nie powinna niszcząca powoduje uszkodzenie bazy danych się zdarzyć w czasie życia systemu

20 Rodzaje awarii Awarie chwilowe, które mogą być usunięte przez użytkownika, np. przez ponowne uruchomienie lub dostrojenie maszyny. Awarie trwałe, które wymagają naprawy maszyny przez producenta. Prawdopodobieństwo awarii tego rodzaju powinno być znacznie mniejsze.

21 Uwagi Koszt opracowania i zatwierdzenia specyfikacji niezawodności systemu jest bardzo wysoki. Firmy musza realnie oceniać konieczność ponoszenia takich kosztów. Są one na pewno uzasadnione w wypadku systemów, których niezawodne działanie jest krytyczne, takich jak systemy central telefonicznych,i systemów, których awaria może doprowadzić do wielkich start gospodarczych. Takie koszty nie są na pewno uzasadnione w wypadku większości rodzajów systemów gospodarczych i naukowych. Takie systemy maja zwykle skromne wymagania niezawodnościowe, ponieważ koszt ich awarii to jedyne opóźnienia w przetwarzaniu, a usunięcie skutków tych awarii jest mało kosztowne.

22 Specyfikowanie bezpieczeństwa
Bezpieczne działanie jest wymaganą cechą systemów oprogramowania związanych z bezpieczeństwem. W czasie procesu inżynierii wymagań należy więc rozważyć potencjalne zagrożenia. W wypadku każdego zagrożenia należy oszacować powodowane przez nie ryzyko. W specyfikacji można opisać, jak oprogramowanie powinno się zachowywać, żeby zmniejszyć to ryzyko, lub stwierdzić, że ryzyko nie może się nigdy pojawić.

23 Cykl życia bezpieczeństwa zgodny z IEC 61508
Definicja pojęć i zakresu Analiza zagrożeń i ryzyka Opracowanie wymagań bezpieczeństwa Przyporządkowanie wymagań bezpieczeństwa Planowanie i budowanie Planowanie Zatwierdzenie i instalacja Budowanie systemów związanych z bezpieczeństwem Zewnętrzne udogodnienia do redukcji ryzyka Zatwierdzenie bezpieczeństwa Instalacja i przekazanie Cykl życia bezpieczeństwa zgodny z IEC 61508 Działanie i pielęgnacja Likwidacja systemu ©Ian Sommerville Dependable systems specification Slide 23

24 Zarządzanie bezpieczeństwem
Nie kończy się w chwili dostarczenia systemu. Po dostarczeniu system musi być zainstalowany zgodnie z planem, aby analiza ryzyka była ciągle aktualna. Zatwierdzenie bezpieczeństwa również ma miejsce w trakcie działania i (zwłaszcza) pielęgnacji systemu. Do wielu kłopotów z bezpieczeństwem dochodzi z powodu złego procesu pielęgnacji systemu, a zatem zaprojektowanie systemu zdatnego do pielęgnacji jest szczególnie ważne. Ostatecznie ważne jest także, aby wziąć pod uwagę kwestie bezpieczeństwa związane z likwidacją systemu (np. utylizacja groźnych materiałów użytych do budowy układów).

25 Analiza zagrożeń i ryzyka
Analiza zagrożeń i ryzyka polega na badaniu systemu i środowiska, w jakim system działa. Jej celem jest znalezienie potencjalnych zagrożeń, które mogą pojawić się w środowisku, pierwotnych przyczyn tych zagrożeń i związanego z nimi ryzyka. To złożony i trudny proces, który wymaga niestandardowego myślenia i wiedzy ekspertów z rozmaitych dziedzin. Powinien być wykonywany przez doświadczonych inżynierów z udziałem ekspertów z dziedziny zastosowania i profesjonalnych doradców od bezpieczeństwa. Do identyfikacji zagrożeń można użyć sposobów pracy grupowej, takich jak burza mózgów. Zagrożenia mogą być znalezione także dzięki temu, że jeden z uczestniczących analityków bezpośrednio doświadczył incydentu, który doprowadził do zagrożenia.

26 Analiza zagrożeń i ryzyka
Rozpoznawanie zagrożeń Analiza ryzyka i klasyfikacja zagrożeń Rozkładanie zagrożeń Ocena szans zmniejszenia ryzyka Opis zagrożeń Oszacowanie ryzyka Analiza drzewa awarii Wstępne wymagania bezpieczeństwa

27 Proces analizy zagrożeń i ryzyka
Rozpoznawanie zagrożeń. Rozpoznaje się potencjalne zagrożenia, które mogą wystąpić. Ich zbiór zależy od środowiska, w którym system będzie użytkowany. Analiza ryzyka i klasyfikacja zagrożeń. Każde zagrożenie rozpatruje się oddzielnie. Te szczególnie poważne i nie wykluczone są wybierane do dalszej analizy. Rozkładanie zagrożeń. Każde zagrożenie rozpatruje się oddzielnie i szuka jego przyczyn. Ocena szans zmniejszenia ryzyka. Znajduje się propozycje zmniejszenia i redukcji rozpoznanego ryzyka.

28 Etapy analizy dla wielkich systemów
Wstępna analiza zagrożeń, która polega na rozpoznaniu najważniejszych zagrożeń. Bardziej szczegółowa analiza zagrożeń w systemach i podsystemach. Analiza zagrożeń oprogramowania, w czasie której rozważa się ryzyko awarii oprogramowania. Analiza zagrożeń operacyjnych, która jest poświęcona systemowemu interfejsowi użytkownika i ryzyku, wynikającemu z błędów operatora.

29 System podawania insuliny
Za duża dawka insuliny (niepowodzenie usługi). Za mała dawka insuliny (niepowodzenie usługi). Brak zasilania w związku z wyczerpaniem baterii (elektryczne). Elektryczna interferencja maszyny z innym sprzętem medycznym, takim jak rozrusznik serca (elektryczne). Złe podłączenie detektora lub efektora spowodowane przez niedopasowanie (fizyczne). Części maszyny pozostawione w ciele chorego (biologiczne). Zakażenie spowodowane podłączeniem maszyny (biologiczne). Reakcja alergiczna na materiał lub insulinę używaną w maszynie (biologiczne).

30 Analiza drzewa awarii W wypadku każdego rozpoznanego zagrożenia należy przeprowadzić analizę, której celem jest znalezienie sytuacji powodujących to zagrożenie. Istnieją dedukcyjne i indukcyjne metody analizy zagrożeń. Metody dedukcyjne (zwykle łatwiejsze w użyciu) polegają na rozpoczęciu od zagrożenia i na jego podstawie poszukiwania możliwych awarii systemu. Metody indukcyjne polegają na rozpoczęciu od awarii systemu i poszukiwaniu zagrożeń, które mogą powstać. Jeśli to możliwe, w analizie zagrożeń należy użyć obu rodzajów metod

31 Analiza drzewa awarii Ta szeroko stosowana metoda analizy zagrożeń jest łatwa do zrozumienia bez fachowej wiedzy. Analiza drzewa awarii polega na rozpoznaniu niepożądanego zdarzenia i badania go wstecz, aby odkryć możliwe przyczyny tego zagrożenia. Zagrożenie jest korzeniem tego drzewa, a liście reprezentują potencjalne przyczyny zagrożenia.

32 Drzewo awarii systemu podawania insuliny
Podano nieodpowiednią dawkę insuliny lub Niepoprawny pomiar poziomu cukru Odpowiednia dawka podana w niewłaściwym czasie Awaria systemu podawania lub lub Błąd przy obliczaniu poziomu cukru Awaria detektora Awaria zegara Błąd przy obliczaniu poziomu cukru Błędne sygnały pompy lub lub Błąd algorytmiczny Błąd arytmetyczny Błąd algorytmiczny Błąd arytmetyczny

33 Szacowanie ryzyka Proces szacowania ryzyka rozpoczyna się po zidentyfikowaniu wszystkich zagrożeń. Szacując ryzyko, ocenia się znaczenie każdego zagrożenia, prawdopodobieństwo jego wystąpienia i prawdopodobieństwo, że doprowadzi ono do wypadku. W wyniku tego procesu dla każdego zagrożenia powstaje opinia o jego akceptowalności.

34 Poziomy akceptowalności zagrożenia
Nie do przyjęcia. System musi być zaprojektowany tak, że to zagrożenie nie może wystąpić, a nawet jeśli wystąpi, nie może doprowadzić do wypadku. Tak małe, jak to jest możliwe (ALARP- as low as reasonably practical). System musi być zaprojektowany tak, aby biorąc pod uwagę koszty, czas dostawy, itd., zmniejszyć prawdopodobieństwo wystąpienia wypadku z powodu tego zagrożenia. Akceptowalne. Projektanci powinni przedsięwziąć wszystkie kroki w celu zmniejszenia prawdopodobieństwa powstania zagrożenia, jednak tylko pod warunkiem, że nie zwiększą one kosztu, nie opóźnią czasu dostawy, ani nie pogorszą atrybutów niefunkcjonalnych.

35 Poziomy ryzyka Obszar nieakceptowalny Ryzyko nie jest tolerowane
Ryzyko jest tolerowane jedynie wtedy, kiedy jego redukcja jest praktycznie niemożliwa lub niezwykle kosztowna Obszar akceptowalny Obszar ALARP Ryzyko nieistotne

36 Proces szacowania ryzyka
Obejmuje kalkulacje prawdopodobieństwa i dotkliwości zagrożenia. Zwykle osiągnięcie dokładnych wyników tej czynności jest bardzo trudne i najczęściej zależy od inżynierskiego rozsądku. Prawdopodobieństwa i dotkliwość są oceniane za pomocą wartości względnych, takich jak „prawdopodobne”, „niemożliwe”, „rzadkie”, „duża”, „średnia” i „mała”. Doświadczenia zdobyte przy pracy nad poprzednimi systemami umożliwiają skojarzenie z tymi pojęciami pewnych wartości liczbowych. Wypadki są jednak dość rzadkie, zwykle więc trudno jest zweryfikować dokładność takiej wartości.

37 Analiza ryzyka związanego z zagrożeniami
Rozpoznane zagrożenie Prawdo Dotkliwość Oszacowanie Akcepto- podobieństwo zagrożenia ryzyka walność Przedawkowanie insuliny Średnie Duża Wysokie Nie do przyjęcia Niedostateczna dawka insuliny Średnie Mała Niskie Akceptowalne Zanik zasilania Duże Mała Niskie Akceptowalne Maszyna podłączona niewłaściwie Duże Duża Wysokie Nie do przyjęcia Maszyna rani pacjenta Małe Duża Średnie ALARP Maszyna powoduje infekcję Średnie Średnia Średnie ALARP Zakłócenia elektryczne Małe Duża Średnie ALARP Reakcja alergiczna Małe Mała Małe Akceptowalne

38 Redukcja ryzyka Po rozpoznaniu potencjalnych zagrożeń i ich przyczyn formułuje się taką specyfikacje systemu, aby prawdopodobieństwo, że zagrożenie doprowadzi do wypadku było niewielkie.

39 Strategie redukcji ryzyka
Unikanie zagrożeń. System jest zaprojektowany tak, aby zagrożenia nie mogły się pojawić. Wykrywanie i eliminowanie. System jest zaprojektowany tak, aby wykrywać i eliminować zagrożenia, zanim doprowadzą do wypadku. Ograniczanie szkód. System jest zaprojektowany tak, aby zminimalizować konsekwencje wypadków.

40 Potencjalne problemy oprogramowania
Błąd arytmetyczny. Pojawia się, gdy jakieś obliczenie arytmetyczne powoduje błąd reprezentacji. W specyfikacji trzeba wskazać wszystkie błędy arytmetyczne, które mogą się zdarzyć. Zależą one od zastosowanego algorytmu. Błąd algorytmiczny. To znacznie trudniejsza sytuacja, ponieważ trudno wykryć jakiekolwiek nienormalne okoliczności. Można je wykryć przez porównanie obliczonej potrzebnej dawki insuliny z poprzednio podaną.

41 Przykłady wymagań stawianych bezpieczeństwu pompy insulinowej
WB1 Jedna dawka insuliny podana przez system nie będzie większa niż maksimum określone przez użytkownika systemu. WB2 Całkowita dzienna dawka insuliny podana przez system nie będzie większa niż maksimum określone przez użytkownika systemu. WB3 System będzie zawierał udogodnienia do diagnozowania sprzętu, które należy uruchamiać co najmniej 4 razy na godzinę. WB4 System będzie zawierał procedurę obsługi wszystkich wyjątków wskazanych w tabeli 3. WB5 Dźwiękowy sygnał alarmowy będzie włączany po wykryciu każdej anomalii sprzętu; wówczas należy również wyświetlić komunikat diagnostyczny zgodnie z definicjami z tabeli 4.

42 Specyfikowanie zabezpieczenia
Specyfikacja wymagań stawianych zabezpieczeniu ma coś wspólnego z wymaganiami stawianymi bezpieczeństwu. Nie ma sensu określać ich liczbowo, ponieważ wymagania stawiane zabezpieczeniom są zwykle wymaganiami”nie będzie”, w których definiuje się niedopuszczalne zachowania, a nie oczekiwaną funkcjonalność systemu.

43 Różnice pomiędzy specyfikacjami wymagań, a specyfikacjami bezpieczeństwa
Cykl życia bezpieczeństwa obejmujący wszystkie aspekty zarządzania bezpieczeństwem jest starannie opracowany. Dziedzina specyfikowania i zarządzania zabezpieczeniem jest jeszcze bardzo niedojrzała i nie istnieje powszechnie przyjęty odpowiednik cyklu życia bezpieczeństwa. Zbiór sytuacji grożących zabezpieczeniu systemu jest uniwersalny. Wszystkie systemy muszą być chronione przed intruzami, odmową realizacji usług itd.. Zagrożenia w systemach krytycznych dla bezpieczeństwa są zwykle charakterystyczne dla jednej dziedziny. Techniki i technologie zabezpieczenia, takie jak szyfrowanie i urządzenia do uwierzytelniania, są dobrze opracowane. Wiele technologii zabezpieczenia przygotowano jednak dla szczególnych systemów (takich jak systemy wojskowe i finansowe). Ich przekazanie do powszechnego użytku wiąże się z pewnymi trudnościami. Techniki związane z bezpieczeństwem oprogramowania są ciągle tematem badań.

44 Specyfikowanie zabezpieczeń
Analiza technologii zabezpieczeń Analizowanie technologii Identyfikacja aktywów Analiza gróźb i oszacowanie ryzyka Specyfikacja wymagań stawianych zabezpieczeniom Przyporządkowanie gróźb Macierz groźba-ryzyko Lista aktywów systemowych Wymagania stawiane zabezpieczeniom Opis aktywów i gróźb

45 Kroki procesu specyfikowania wymagań
Identyfikacja i wycena aktywów. Rozpoznaje się aktywa (dane i programy) i ich oczekiwany stopień ochrony. Stopień pożądanej ochrony zależy zwykle od wartości składnika majątku. Plik z hasłami ma zatem zwykle większa wartość niż zbiór ogólnie dostępnych witryn WWW, ponieważ potencjalny atak na plik z hasłami ma poważne konsekwencje dla całego systemu. Analiza gróźb i oszacowanie ryzyka. Rozpoznaje się możliwe groźby dla zabezpieczeń systemu i ocenia ryzyko związane z każdą z tych gróźb. Przyporządkowanie gróźb. Rozpoznane groźby przyporządkowuje się do aktywów. Dla każdego zidentyfikowanego składnika majątku powstaje lista związanych z nim gróźb. Analizowanie technologii. Ocenia się dostępne technologie zabezpieczeń i ich skuteczność na rozpoznane groźby. Specyfikacja wymagań stawianych zabezpieczeniom. Specyfikuje się wymagania stawiane zabezpieczeniom. Tam, gdzie ma to sens, w specyfikacji wymagań wskazuje się technologie zabezpieczeń, które można zastosować w celu ochrony systemu przed groźbami.

46 Główne tezy Wymagania niezawodnościowe należy zdefiniować ilościowo i uwzględnić w specyfikacji wymagań systemu. Istnieje kilka miar niezawodności, takich jak prawdopodobieństwo wystąpienia awarii przy zleceniu, częstość występowania awarii, średni czas awarii i dostępność. Wybór najbardziej odpowiedniej miary w wypadku konkretnego systemu zależy od jego rodzaju i dziedziny zastosowania. W różnych podsystemach można wykorzystać inne miary. Niefunkcjonalna specyfikacja niezawodnościowa może powodować funkcjonalne wymagania systemu, w których wskazuje się jego cechy umożliwiające zmniejszenie liczby awarii systemu i przez to zwiększenie jego niezawodności.

47 Główne tezy Analiza zagrożeń to zasadnicza czynność procesu specyfikowania bezpieczeństwa. Obejmuje identyfikację sytuacji zagrożeń, które czyhają na bezpieczeństwo systemu. Opracowuje się wówczas wymagania systemowe, których spełnienie ma zapewnić, że te zagrożenia się nie pojawią, a nawet ich wystąpienie nie doprowadzi do wypadku. Analiza ryzyka to proces oceny prawdopodobieństwa, ze zagrożenie doprowadzi do wypadku. W czasie analizy ryzyka identyfikuje się krytyczne zagrożenia, których należy uniknąć, i klasyfikuje ryzyka według ich wagi. Aby określić wymagania stawiane zabezpieczeniom, należy rozpoznać aktywa, które trzeba chronić, i ustalić, jakie techniki i technologie zabezpieczenia wykorzystać do ochrony tych aktywów, oraz w jaki sposób to zrobić.