Rozdz17.ppt

©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Specyfikowanie systemów krytycznych

Celem tego rozdziału jest wyjaśnienie, jak specyfikować wymagania funkcjonalne i niefunkcjonalne wobec pewności.


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.


Zawartość

Specyfikowanie niezawodności systemu Specyfikowanie bezpieczeństwa Specyfikowanie zabezpieczenia


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.


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.


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).


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.


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?


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)


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.


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.

Miary niezawodności


Miara ObjaśnieniePOFOD Prawdopodobieństwo awarii przy zleceniu. Prawdopodobieństwo, żeProbability system ulegnie awarii po zleceniu mu usługi. POFOD o wartości 0,001of 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 wOccurence 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 awariamiMean time systemu. MTTF o wartości 500 oznacza, że co 500 jednostek czasu toFailure można oczekiwać jednej awarii.

AVAIL Dostępność. Prawdopodobieństwo, że system jest dostępny dlaAvailability 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.

Miary niezawodności


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.


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.


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.


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


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.


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 200 000 transakcji. Sieć banku składa się z 1000 maszyn. Oznacza to, że dziennie następuje 300 000 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.


Specyfikacja niezawodności bankomatu

Klasa awarii Przykład Miara niezawodności

Trwała System nie działa z żadną wsuwaną ROCOFnieniszcząca kartą. Usunięcie awarii wymaga ponownego 1 zdarzenie/1000 dni

uruchomienia oprogramowania.

Chwilowa Pasek magnetyczny nieuszkodzonej ROCOFnieniszcząca wsuniętej karty nie może być odczytany 1 na 1000 transakcji

Trwała Zestaw jednoczesnych transakcji w sieci Niemierzalna! Nie powinnaniszcząca powoduje uszkodzenie bazy danych się zdarzyć w czasie życia

systemu


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.

Rodzaje awarii


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.


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ć.

Cykl życia bezpieczeństwa

zgodny z IEC 61508

©Ian Sommerville 2000 Dependable systems specification Slide 23

Budowanie systemówzwiązanych z bezpieczeństwem

Planowanie

Zatwierdzenie i instalacja

Instalacjai przekazanie

Zatwierdzeniebezpieczeństwa

Działanie i pielęgnacja

Likwidacja systemu

Zewnętrzne udogodnieniado redukcji ryzyka

Analiza zagrożeńi ryzyka

Definicja pojęći zakresu

Przyporządkowaniewymagań bezpieczeństwa

Opracowanie wymagańbezpieczeństwa

Planowanie i budowanie


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).


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.


Analiza zagrożeń i ryzyka

Rozpoznawaniezagrożeń

Analiza ryzykai klasyfikacja

zagrożeń

Rozkładaniezagrożeń

Ocena szanszmniejszenia

ryzyka

Opis zagrożeń Oszacowanieryzyka

Analiza drzewaawarii

Wstępnewymagania

bezpieczeństwa


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.

Proces analizy zagrożeń i ryzyka


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.


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).

System podawania insuliny


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


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.


Drzewo awarii systemu podawania insuliny

Podano nieodpowiednią dawkę insuliny

Awaria systemupodawania

Odpowiednia dawkapodana w niewłaściwym

czasie

Błędne sygnały pompy

Niepoprawny pomiarpoziomu cukru

Awaria zegaraBłąd przy obliczaniu

poziomu cukruAwaria detektora

Błąd arytmetyczny

Błądalgorytmiczny

Błąd przy obliczaniupoziomu cukru

Błąd algorytmiczny

Błąd arytmetyczny

lub lub

lub lub

lub


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.


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.


Poziomy ryzyka

ObszarALARP

Ryzyko nieistotne

Obszar nieakceptowalnyRyzyko nie jest tolerowane

Ryzyko jest tolerowanejedynie wtedy, kiedy jegoredukcja jest praktycznieniemożliwa lub niezwyklekosztowna

Obszar akceptowalny


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.


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


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.


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.


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ą.


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.


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.


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ń.


Specyfikowanie zabezpieczeń

Macierzgroźba-ryzyko

Lista aktywówsystemowych Opis aktywów

i gróźb

Wymagania stawiane

zabezpieczeniom

Analizatechnologii

zabezpieczeń

Przyporządkowaniegróźb

Analizowanietechnologii

Analiza gróźbi oszacowanie

ryzyka

Identyfikacjaaktywów

Specyfikacjawymagań stawianychzabezpieczeniom


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.


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.


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ć.

Date post:	11-Jan-2017
Category:	Documents
Upload:	truongdat
View:	218 times
Download:	0 times

Rozdz17.ppt

Documents