Bezpieczeństwo sieci komputerowych i testy penetracyjne
Jak wygląda test penetracyjny sieci: sześć etapów według PTES i ISSAF, proporcja testów ręcznych do automatycznych oraz rola raportu i retestów.
Opublikowano 1 min czytania
- bezpieczeństwo
- testy penetracyjne
- PTES
- audyt
W mniejszych firmach bezpieczeństwo sieci bywa lekceważone, a zaniechanie tego procesu potrafi skończyć się kosztownie. Narzędziem, które pokazuje realny stan rzeczy, są testy penetracyjne.
Po co się je robi
Celem testu penetracyjnego jest zidentyfikowanie podatności w sieciach, systemach, hostach i urządzeniach sieciowych, takich jak routery i przełączniki, zanim znajdzie je ktoś nieuprawniony. Test pokazuje, co faktycznie da się osiągnąć: gdzie kończy się kontrola dostępu i czy możliwe jest dotarcie do danych wrażliwych albo przejęcie systemu.
Metodyka obejmuje symulację ataku prowadzoną po to, by:
- zidentyfikować luki obecne w środowisku,
- określić poziom ryzyka związanego z bezpieczeństwem systemów IT,
- pomóc te luki usunąć.
Istotny szczegół: osoba testująca powinna mieć doświadczenie w utrzymaniu sieci i systemów, nie tylko w ich łamaniu. Wiedza o tym, jak środowiska są budowane, podpowiada, gdzie szukać błędów.
Przebieg testu
- Gromadzenie informacji
- Modelowanie zagrożeń
- Analiza podatności
- Wykorzystanie podatności
- Działania po uzyskaniu dostępu
- Raport
Zakres opiera się na PTES (Penetration Testing Execution Standard) oraz ISSAF (Information Systems Security Assessment Framework) i obejmuje m.in. ataki na CDP, testowanie MIME, enumerację DNS i próby AXFR, sprawdzenie relayingu SMTP, rozpoznanie SNMP, weryfikację port security, ataki siłowe oraz testy szyfrowania.
Ręcznie czy automatycznie
Proporcja wygląda mniej więcej tak: 80% testów manualnych, 20% automatycznych. Narzędzia automatyczne są skuteczne w początkowych fazach, czyli podczas rozpoznania i wstępnego skanowania. Dalej ich przydatność gwałtownie spada, bo istotne podatności wynikają zwykle z logiki konkretnego środowiska, a nie z sygnatury, którą skaner zna.
Raport i retesty
Raport jest produktem końcowym, ale nie końcem pracy. Sam wykaz znalezionych słabości ma ograniczoną wartość. Liczy się opis sposobu ich usunięcia i weryfikacja, czy poprawki faktycznie zadziałały. Dlatego retest po wdrożeniu poprawek powinien być częścią usługi, a nie osobno wycenianym dodatkiem.