Jak sprawdzić zabezpieczenia
-
- 19.05.2009
Wynik pracy audytora
Wynikiem testów jest raport, który określa dokładnie podatności badanego systemu. Najważniejszymi jego elementami są status, krytyczność błędu, jego opis, rzeczywiste zagrożenie, oraz zalecenia. Status określa, czy dana podatność została potwierdzona w praktyce, czy jedynie wykazana podczas wstępnego rozpoznania. Przykładem może być wykrycie podatności przepełnienia stosu w badanej aplikacji lub systemie. Po zaatakowaniu aplikacja się załamuje. Nie zawsze jest to jednak możliwość przejęcia kontroli przez wykonanie spreparowanego kodu. To samo dotyczy błędów wstrzyknięcia kodu SQL, który należy dokładnie sprawdzić. Jeśli przynajmniej raz udało się dokonać tego ataku (czyli pobrać dane bezpośrednio z bazy lub rzeczywiście wykonać własny kod SQL i zmodyfikować dane w bazie), jest on potwierdzony, w przeciwnym przypadku nadal jest wątpliwy, nawet jeśli udało się wyświetlić komunikaty o błędach.
Poziom krytyczności luki określa się jako: informational, low, medium, high i critical, przy czym klasyfikacja nie zawsze będzie oczywista. Luką krytyczną może być np. potwierdzona możliwość zdalnego przejęcia kontroli nad systemem lub aplikacją, przy czym każdy z błędów, z których dana luka się składa, może być średniego poziomu, dopiero ich kombinacja daje tak poważne skutki. Opis określa dokładnie, na czym polega dany błąd i pozwala na odtworzenie zasady ataku przez osobę, która potem taki raport analizuje. Nie zawsze należy jednak publikować w raporcie detale techniczne, wymaga to uzgodnień z audytowaną firmą. Jedną z przyczyn pomijania niektórych szczegółów jest to, że raport może dotrzeć do osób niepowołanych albo opis byłby nieczytelny dla osób, które nie dysponują dogłębną wiedzą z zakresu programowania. Zagrożenie powinno określić maksymalne skutki udanego wykorzystania wykrytej luki.
Bardzo ważnym elementem jest opis zaleceń w celu usunięcia luki w bezpieczeństwie. Opis ten powinien zawierać dwa warianty, jeden umożliwiający minimalizację ryzyka w szybki i prosty sposób i drugi, który zawiera działania, mające na celu eliminacje wykrytej luki.
Większość audytorów woli przeprowadzać testy penetracyjne w prawdziwym środowisku produkcyjnym podczas normalnej eksploatacji systemów. Oddają one rzeczywiste warunki działania intruza. Nie zawsze jednak takie podejście można zastosować. Przykładem mogą być niektóre krytyczne systemy, takie jak bankowość elektroniczna, czy systemy zintegrowane z urządzeniami przemysłowymi kontrolującymi procesy fizyczne lub chemiczne. W przypadku udanego włamania, skutki działania eksploitów mogą być poważne. To samo dotyczy testów podatności np. na wyłączenie zasilania przez osobę podszywającą się pod pracownika ochrony. Środowisko testowe nie zawsze musi dokładnie odzwierciedlać stan środowiska produkcyjnego. Ponadto obciążenie środowiska testowego może daleko odbiegać od rzeczywistej pracy systemu produkcyjnego, co wpływa na wyniki analiz niektórych ataków.
