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.
DREAD to skrót od następujących pojęć:
-
Damage potential
-
Reproducibility
-
Exploitability
-
Affected users
-
Discoverability
Głównym powodem, z którego nie lubiłem prostej metody opartej na prawdopodobieństwie i skutku był fakt, iż zespół zwykle nie zgadzał się w ocenach, zwłaszcza, gdy poszczególni jego członkowie mieli interes w obniżeniu lub podniesieniu rangi jakiegoś zagrożenia. Ograniczając stopnie swobody często okazywało się, że otrzymane narzędzie nie jest wystarczająco elastyczne do zadowalającej analizy. Metoda DREAD jest w zasadzie rozwinięciem tej uproszczonej metody, przy czym parametr "prawdopodobieństwo wystąpienia" można utożsamić z wartościami Demage potential
oraz Affected users, pozostałe wartości odpowiadają natomiast za prawdopodobieństwo wystąpienia.
Każdemu z powyższych atrybutów przypisywana jest wartość, poszczególne wskaźniki są przez siebie mnożone, a następnie dzielone przez 5. Zakres przypisywanych wartości może być różny, 1-3, 0-10. Kluczem jest określenie kiedy dana wartość jest przypisywana, wskazane jest określenie przynajmniej trzech poziomów (dla 1-3), natomiast dla większej ilości dopuszczalnych wartości ma się do czynienia tak naprawdę z "odcieniami szarości".
Demage potential
Jak sama nazwa wskazuje wartość skutek jakiego należy się spodziewać w przypadku wykorzystania podatności. Wskaźnikami mogą być następujące scenariusze:
-
LOW
- nic się nie dzieje, pozyskana może być mało istotna informacja,
-
MEDIUM
- dane pojedynczych użytkowników mogą zostać ujawnione bądź zmienione, ujawniane są istotne informacje,
-
HIGH
- kompletne przejęcie systemu, obejście mechanizmów bezpieczeństwa, możliwość modyfikacji bądź ujawnienia dowolnych danych,
Dla przykładu jeśli mamy do czynienia z sql-injection, to w przypadku, gdy jedynym skutkiem wykorzystania podatności jest otrzymanie błędu bazy o nieprawidłowym zapytaniu, to ciężko zakwalifikować taki przypadek do stopnia innego niż LOW.
Jeśli możliwe jest pozyskanie pewnych informacji o innym użytkowniku pod warunkiem podania na przykład identyfikatora, którego bezpośrednio nie znamy, jest on losowy i zbyt złożony, by atakować go metodą brute-force, to stopień MEDIUM jest jak najbardziej odpowiedni.
Gdy w wyniku błędu możliwe jest pozyskanie całej bazy, choćby trzeba by to było robić za pomocą blind sql-injection, co nie jest proste, to jednak stopień jest HIGH.
Gdy te trzy stopnie są niewystarczające, można wprowadzić "odcienie szarości" mapując je na przykład tak:
-
1 - LOW
-
2
-
3 - MEDIUM
-
4
-
5 - HIGH
Reproducibility
Parametr ten odpowiada za łatwość odtworzenia określonego zachowania systemu, czyli jak łatwo jest przeprowadzić ponownie ten sam atak. Tutaj mapowanie może wyglądać następująco:
-
LOW
- atak ciężki do odtworzenia, nawet w przypadku dokładnej znajomości błędu,
-
MEDIUM
- atak może być odtworzony jedynie w specyficznym czasie lub rzadkiej sytuacji, konieczne są dodatkowe kroki poprzedzające wykorzystanie luki,
-
HIGH
- odtworzenie ataku można dokonać w dowolnej chwili, nie są wymagane żadne szczególne okoliczności lub narzędzia,
W tym wypadku kategorię LOW może otrzymać na przykład błąd przepełnienia bufora, przed którego wykorzystaniem chronią system technologie takie jak randomizacja (co za paskudne słowo) przestrzeni adresowej. Wiemy, że błąd jest, wiemy co można nadpisać, ale nie mamy wpływu na to, czy to, co nadpiszemy trafi w odpowiednie miejsce w pamięci.
Jeśli dostęp do konta dowolnego użytkownika możliwy jest jedynie po wcześniejszym uwierzytelnieniu się tego użytkownika (na przykład przez przejęcie sesji), to wówczas odpowiednią kategorią jest kategoria MEDIUM. Innym przykładem może być atak na serwer (właściwie na usługę) w krótkim oknie czasowym między podniesieniem sieci i atakowanej usługi, a aktywacją firewalla.
Kategorię HIGH otrzyma podatność, która na przykład nie wymaga wcześniejszego uwierzytelnienia i może być wykorzystywana w dowolnej chwili.
Exploitability
Łatwość wykorzystania podatności.
-
LOW
- podatność może wykorzystać jedynie doświadczona osoba o dużych umiejętnościach, potrzebne są zaawansowane narzędzia,
-
MEDIUM
- dostępne są narzędzia umożliwiające wykorzystanie luki, exploity, wirusy, robaki...,
-
HIGH
- nie jest wymagana zaawansowana wiedza, potrzebne narzędzia istnieją, mogą zostać w łatwy sposób stworzone lub nie są wymagane,
Nawet wiedząc, że w określonym parametrze istnieje sql-injection nie oznacza to, że wykorzystanie podatności jest proste. Dużo pracy może być potrzebne w celu określenia jak powinno wyglądać zapytanie, określenia struktury bazy i wreszcie odczytania interesujących informacji. Jeśli jest to blind sql-injection, wymagany może być skrypt, który proces wyciągania danych ułatwi. Taka podatność klasyfikuję się do kategorii LOW. Gdy jednak osoba, która wykryła błąd udostępnia działający PoC, wówczas automatycznie błąd awansuje na kategorię MEDIUM (lub nawet HIGH). Jeśli do zalogowania się w aplikacji wystarczy wpisać słynne ' or 1=1 --, wówczas ciężko wystawić ocenę niższą niż HIGH.
Affected users
Ilość użytkowników objętych problemem.
-
LOW
- niewielka ilość użytkowników, błąd istnieje w rzadko używanej funkcjonalności, która nie jest dostępna w domyślnej konfiguracji,
-
MEDIUM
- pewna ilość użytkowników korzystających z niestandardowej konfiguracji,
-
HIGH
- wszyscy użytkownicy, domyślna konfiguracja,
Jeśli podatność istnieje w funkcjonalności, którą używa 0,05% wszystkich użytkowników, która jest wyłączona domyślnie, to trudno uznać, by problem był bardzo istotny, w związku z czym otrzymuje on klasyfikację LOW. Gdy problem dotyczy pewnej grupy użytkowników, którzy zmienili domyślną konfigurację, wówczas podatność może zostać zakwalifikowana do poziomu MEDIUM. Jeśli każdy użytkownik jest objęty problemem, wówczas oczywiście odpowiednim stopniem jest HIGH.
Discoverability
Jak łatwo jest znaleźć określoną podatność.
-
LOW
- błąd jest bardzo trudny do znalezienia, konieczny jest dostęp administracyjny do aplikacji bądź dostęp do kodu źródłowego,
-
MEDIUM
- podatność jest stosunkowo łatwa do wykrycia,
-
HIGH
- informacja o podatności jest już opublikowana,
A po co to wszystko?
Ocena ryzyka pozwala podejmować uzasadnione działania, odpowiednio oceniać kolejność wymaganych akcji, określić ich typ. Czasem po przeanalizowaniu ryzyka może okazać się, że to, co w pierwszej chwili wydawało się krytycznym błędem, tak naprawdę dotyczy znikomej części użytkowników i jest ciężkie do wykrycia. Zamiast zajmować się tym w pierwszej kolejności, może okazać się, że istotniejszy jest inny problem, choć potencjalny koszt jego wystąpienia jest niewielki, to jednak prawdopodobieństwo z jakim on wystąpi (łatwy do wykorzystania, istnieją informacje na jego temat, dotyczy wszystkich użytkowników) jest na tyle duże, by oczekiwana wartość strat uzasadniła inwestycję w jego usunięcie. Analiza taka sprawdza się również w przypadku testu aplikacji, która jest przygotowywana do uruchomienia produkcyjnego. Może się okazać, że konflikt między oczekiwaniami biznesu, a stanem bezpieczeństwa aplikacji jest trudny do rozstrzygnięcia, data go-live
jest nieprzesuwalna (bo na przykład już trwa kampania reklamowa), a aplikacja podatności ma kilka(dziesiąt). Dzięki takiej analizie można określić, które podatności są najbardziej istotne i przynajmniej je usunąć przed uruchomieniem produkcyjnym, pozostałe biznes powinien świadomie zaakceptować i... nie mieć pretensji, gdy ktoś je znajdzie.
Więcej informacji:
