Rodzaje i stopień zagrożeń
aplikacji w metodyce DREAD są następujące:
1. Poziom zniszczeń ( Damage Potential) w przypadku skutecznego ataku
 0 – praktycznie brak zniszczeń
 5 – ujawnienie poufnych informacji pojedynczych użytkowników
 10 – całkowite zniszczenie systemu i utrata danych
2. Stopień trudności w odtworzeniu stanu systemu sprzed ataku
( Reproductibility)
 0 – niemożliwy lub niezwykle trudny do odtworzenia, nawet dla
administratorów systemu
 5 – możliwy do odtworzenia, jednak wymaga dodatkowych
warunków
 10 – bardzo prosty do odtworzenia, do odtworzenia wystarczy
przeglądarka internetowa
3. Łatwość wykorzystania luki ( Exploitability)
 0 – wymaga zaawansowanej wiedzy sieciowej i programistycznej,
jak również zaawansowanych narzędzi do ataku
 5 – możliwy do wykorzystanie z użyciem dostępnych narzędzi
 10 – nawet osoba bez specjalnych kompetencji jest w stanie
przeprowadzić atak
4. Ilość zagrożonych użytkowników ( Affected Users)
 0 – bliska zeru
 5 – część użytkowników, lecz nie wszyscy
198
10. Problemy bezpieczeństwa w systemach informatyki medycznej

 10 – praktycznie wszyscy użytkownicy
5. Poziom trudności w zlokalizowaniu luki ( Discoverability)
 0 – niemożliwa lub bardzo trudna do zlokalizowania, często tylko z
posiadaniem uprawnień administratora lub wglądem do kodu
źródłowego
 5 – może być zlokalizowana podczas monitorowania sieci
 10 – łatwa do zlokalizowania nawet dla użytkowników bez żadnej
specjalistycznej wiedzy
Metodyka DREAD bywa czasami w uproszczeniu przedstawiana jak na rysunku
10.13, pokazującym kategoryzację zagrożeń i sposobów reagowania na nie.

Rysunek 10.13. Rodzaje postępowania w zapewnianiu bezpieczeństwa
Tak naprawdę trzeba zapamiętać i stosować jedną regułę: Jedynie ciągłe
modelowanie bezpieczeństwa na każdym etapie projektowania, a następnie
implementacji i użytkowania aplikacji pozwala osiągnąć pozytywne rezultaty w
postaci aplikacji odpornych na zagrożenia. Odpowiednie działania należy
prowadzić zgodnie z normami:
• PN-I-07799-2:2005 (BS-7799-2)
• PN ISO/IEC 17799:2003 (BS-7799-1)
z uwzględnieniem najnowszych rewizji wspomnianych norm, czyli:
• ISO/IEC 27001:2005
• ISO/IEC 17799:2005
Informatyka Medyczna

199
Niezależnie od wszystkich uwag podanych wyżej aplikacje internetowe
stanowią znaczne wyzwanie w zakresie zapewniania bezpieczeństwa. Wynika to
ze złożoności technologii tworzenia aplikacji oraz specyfiki środowiska
wykonania. Bezstanowy charakter protokołu HTTP powoduje konieczność
dynamicznego zarządzania sesjami użytkowników, co w połączeniu z
możliwością podsłuchu ( sniffing) wymaga zabezpieczenia transmisji danych na
niższej warstwie.
Protokół HTTP zawiera wiele metod, które potencjalnie mogą zostać
wykorzystane w celu oszukania aplikacji internetowej. Istnieje możliwość
dowolnego spreparowania praktycznie każdej części zapytania HTTP, np. adresu
URL, parametrów zapytania, nagłówków, ciasteczek, pól formularza, pól
ukrytych- wszystko w celu oszukania podstawowych mechanizmów
zabezpieczeń. Brak właściwej kontroli nad strumieniem danych napływających
do aplikacji może prowadzić do powstawania poważnych luk umożliwiających
zastosowanie ataków typu: XSS, przepełnienie bufora, manipulacja ukrytymi
polami formularzy, nieuprawniona modyfikacja zapytań SQL wykonywanych
przez serwer itd.
Brak ścisłej kontroli danych wejściowych jest jednym z najczęściej
popełnianych błędów. Należy sprawdzać wszystkie dane wejściowe pod kątem
oczekiwanych wartości i odrzucać wszystko, co nie spełnia założonych
kryteriów. Ma to szczególne znaczenie w przypadku aplikacji stworzonych w
językach, które nie stosują silnego typowania (PHP, Perl). Brak mechanizmów