Zajmując się tematyką bezpieczeństwa wielokrotnie spotykałem się z problemem jak oszacować skalę zagrożenia. Fakt, że nie ma systemów w 100% bezpiecznych jest dość dobrze znany, ale już mniejsza ilość ludzi zdaje sobie sprawę, że na przykład celem banku wcale nie jest posiadanie najbezpieczniejszego systemu informatycznego, lecz raczej posiadanie systemu, dla którego ryzyko związane z jego wykorzystaniem ma akceptowalną wartość. W świecie, gdzie rządzą pieniądze, a nie wzniosłe idee, konieczne jest wykazanie, że usunięcie danej podatności opłaca się, bo może się okazać, że zamiast inwestować pieniądze w poprawę systemu, bardziej opłaca się wykupić stosowną polisę, lub (o zgrozo) wprowadzić stosowną modyfikację do warunków użytkowania danej usługi, tak, by użytkownik to ryzyko wziął na siebie...
W takich zastosowaniach najczęściej stosowane są wyliczenia oparte na dwóch parametrach, prawdopodobieństwie wystąpienia zdarzenia oraz ich koszcie.
Ponieważ prawdopodobieństwo jest często ciężkie do precyzyjnego określenia, często zamiast jego wartości stosowany jest wskaźnik z zakresu (na przykład) 1-5, który określa subiektywne prawdopodobieństwo wystąpienia (1 - prawie na pewno nie wystąpi, 5 - prawie na pewno wystąpi).
Wymierny koszt wystąpienia zdarzenia również jest często ciężki do oszacowania, w związku z czym tu również stosuje się subiektywny wskaźnik określający skutek na zasadzie 1 - prawie nic się nie stało, 10 - trzeba zamykać biznes...
Osobiście nigdy nie lubiłem tego podejścia, zwłaszcza, gdy wartości do wyboru było zbyt dużo, ponieważ wówczas metoda staje się doskonałym narzędziem do udowadniania własnych tez. Zawsze dążyłem do tego, by ograniczać stopnie swobody (prawdopodobieństwo do 3, koszt do 5) i przedstawić ogólne wytyczne do przyznawania danej wartości.
Dzisiaj chcę napisać kilka słów o metodologii DREAD, którą uważam za bardzo pomocną w przypadku określenia stopnia zagrożenia dla podatności znalezionych w aplikacjach webowych.
Ciąg dalszy "Jak nie popaść w paranoję, czyli o..." »