Specyfikowanie systemw krytycznych l Celem tego rozdziau jest

Specyfikowanie systemów krytycznych l Celem tego rozdziału jest wyjaśnienie, jak specyfikować wymagania funkcjonalne i niefunkcjonalne wobec pewności. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Cele l l l 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 specyfikowania wymagań bezpieczeństwu i zabezpieczeniu. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17 procesami stawianych

Zawartość l l l Specyfikowanie niezawodności systemu Specyfikowanie bezpieczeństwa Specyfikowanie zabezpieczenia ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Jakość specyfikacji systemów krytycznych l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Pewność systemów krytycznych l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Wymagania typu „nie będzie” l 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). ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Specyfikowanie niezawodności systemu l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Wymiary, które należy wziąć pod uwagę przy specyfikowaniu niezawodności l l l 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? ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Inżynieria niezawodności oprogramowania l l l 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) ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Przykłady wymagań niezawodnościowych l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Miary niezawodności l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Miary niezawodności Miara POFOD Probability of failure on demand Objaśnienie Prawdopodobieństwo awarii przy zleceniu. Prawdopodobieństwo, że system ulegnie awarii po zleceniu mu usługi. POFOD o wartości 0, 001 oznacza, że jedno zlecenie na tysiąc skończy się awarią. ROCOF Rateof failure Occurence Częstotliwość występowania awarii. Częstotliwość występowania nieoczekiwanych zachowań. ROCOF o wartości 0, 002 oznacza, że w ciągu 100 jednostek czasu działania prawdopodobnie zdarza się 2 awarie. Ta miara bywa czasem nazywana intensywnością awarii. MTTF Mean time Failure Średni czas do awarii. Średni czas między zaobserwowanymi awariami systemu. MTTF o wartości 500 oznacza, że co 500 jednostek czasu to można oczekiwać jednej awarii. AVAIL Availability Dostępność. Prawdopodobieństwo, że system jest dostępny dla 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Miary niezawodności l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Rodzaje pomiarów, które można wykonać szacując niezawodność systemu l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Niefunkcjonalne wymagania niezawodnościowe l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

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 ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Czynności prowadzące do opracowania specyfikacji niezawodności l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Przykład specyfikacji niezawodności l l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

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

Rodzaje awarii l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Uwagi l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Specyfikowanie bezpieczeństwa l l 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ć. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

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 Zatwierdzenie bezpieczeństwa Instalacja i przekazanie Działanie i pielęgnacja Likwidacja systemu ©Ian Sommerville 2000 Zewnętrzne udogodnienia do redukcji ryzyka Dependable systems specification Cykl życia bezpieczeństwa zgodny z IEC 61508 Slide 23

Zarządzanie bezpieczeństwem l l l 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). ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Analiza zagrożeń i ryzyka l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Analiza zagrożeń i ryzyka Rozpoznawanie zagrożeń Analiza ryzyka i klasyfikacja zagrożeń Opis zagrożeń Oszacowanie ryzyka ©Ian Sommerville 2004 Rozkładanie zagrożeń Ocena szans zmniejszenia ryzyka Analiza drzewa awarii Wstępne wymagania bezpieczeństwa Inżynieria oprogramowania, Rozdział 17

Proces analizy zagrożeń i ryzyka l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Etapy analizy dla wielkich systemów l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

System podawania insuliny l l l l 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). ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Analiza drzewa awarii l l l 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 ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Analiza drzewa awarii l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Drzewo awarii systemu podawania insuliny Podano nieodpowiednią dawkę insuliny lub Odpowiednia dawka podana w niewłaściwym czasie Niepoprawny pomiar poziomu cukru Awaria systemu podawania lub Awaria detektora lub Błąd przy obliczaniu poziomu cukru Awaria zegara Błąd przy obliczaniu poziomu cukru lub Błąd algorytmiczny ©Ian Sommerville 2004 Błędne sygnały pompy lub Błąd arytmetyczny Błąd algorytmiczny Inżynieria oprogramowania, Rozdział 17 Błąd arytmetyczny

Szacowanie ryzyka l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Poziomy akceptowalności zagrożenia l l l Nie do przyjęcia. System musi być zaprojektowany tak, że to zagrożenie 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Poziomy ryzyka Obszar nieakceptowalny Ryzyko nie jest tolerowane Ryzyko jest tolerowane jedynie wtedy, kiedy jego redukcja jest praktycznie niemożliwa lub niezwykle kosztowna Obszar ALARP Obszar akceptowalny Ryzyko nieistotne ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Proces szacowania ryzyka l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Analiza ryzyka związanego z zagrożeniami Rozpoznane zagrożenie Prawdopodobieństwo Dotkliwość zagrożenia Oszacowanie ryzyka Akceptowalność 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ża Wysokie Nie do przyjęcia Maszyna rani pacjenta Małe Duża Średnie ALARP Maszyna powoduje infekcję Średnie Zakłócenia elektryczne Reakcja alergiczna ©Ian Sommerville 2004 Średnia Średnie ALARP Małe Duża Średnie ALARP Małe Mała Małe Inżynieria oprogramowania, Rozdział 17 Akceptowalne

Redukcja ryzyka l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Strategie redukcji ryzyka l Unikanie zagrożeń. • l Wykrywanie i eliminowanie. • l System jest zaprojektowany tak, aby zagrożenia nie mogły się pojawić. 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Potencjalne problemy oprogramowania l Błąd arytmetyczny. • l 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ą. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Przykłady wymagań stawianych bezpieczeństwu pompy insulinowej WB 1 Jedna dawka insuliny podana przez system nie będzie większa niż maksimum określone przez użytkownika systemu. WB 2 Całkowita dzienna dawka insuliny podana przez system nie będzie większa niż maksimum określone przez użytkownika systemu. WB 3 System będzie zawierał udogodnienia do diagnozowania sprzętu, które należy uruchamiać co najmniej 4 razy na godzinę. WB 4 System będzie zawierał procedurę obsługi wszystkich wyjątków wskazanych w tabeli 3. 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. WB 5 ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Specyfikowanie zabezpieczenia l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Różnice pomiędzy specyfikacjami wymagań, a specyfikacjami bezpieczeństwa l l l 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ń. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Specyfikowanie zabezpieczeń Analiza technologii zabezpieczeń Identyfikacja aktywów Lista aktywów systemowych ©Ian Sommerville 2004 Analiza gróźb i oszacowanie ryzyka Macierz groźba-ryzyko Analizowanie technologii Przyporządkowanie gróźb Opis aktywów i gróźb Inżynieria oprogramowania, Rozdział 17 Specyfikacja wymagań stawianych zabezpieczeniom Wymagania stawiane zabezpieczeniom

Kroki procesu specyfikowania wymagań l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Główne tezy l l l 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. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17

Główne tezy l l l 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 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ć. ©Ian Sommerville 2004 Inżynieria oprogramowania, Rozdział 17