Testy penetracyjne można zdefiniować jako legalną i autoryzowaną próbę znalezienia i wykorzystania luk bezpieczeństwa w systemach komputerowych w celu poprawienia bezpieczeństwa tychże systemów. Proces ten obejmuje testowanie luk w zabezpieczeniach jak i również dostarczenie pełnych dowodów ataku tzw. POC (proof of concept). Ma to na celu potwierdzenia tego, że raportowane błędy bezpieczeństwa są możliwe do wykorzystania. Oprócz tego testy penetracyjne kończą się konkretnymi zaleceniami. Dotyczą one tego w jaki sposób naprawić błędy wykryte podczas testu. Reasumując proces ten ma na celu pomóc w zabezpieczeniu komputerów i sieci przed atakami w przyszłości. Testy penetracyjne znane są także pod nazwami takimi jak pentesty, PT, Hacking, Ethical Hacking, White Hat Hacking.
Ważnym zaznaczenia jest aby widzieć różnicę pomiędzy testami penetracyjnymi a oceną ryzyka czy też audytami. Audytor pyta – „czy mają państwo backupy?”, pentester natomiast informuje – „mamy wasze backupy” ????. Wielu ludzi (oraz firm) w społeczności zajmującej się bezpieczeństwem używa błędnie tych pojęć zamiennie. Ocena ryzyka jest procesem przeglądu usług i systemów skupiająca się na potencjalnych problemach bezpieczeństwa, podczas gdy testy penetracyjne poprzez eksploatację i przeprowadzanie realnych ataków wskazują na błędy bezpieczeństwa, które w rzeczywistości istnieją. Przeprowadzanie testów penetracyjnych wykracza poza ocenę słabych punktów poprzez symulowanie aktywności hakerów i dostarczania gotowych wektorów ataku.
Testy penetracyjne można podzielić na kilka kategorii, biorąc pod uwagę następujące czynniki:
- poziom posiadanej wiedzy;
- zakres testu;
- skład zespołu testerskiego;
- sposób przeprowadzania testów;
- lokalizację testów;
- umiejscowienie w cyklu SDLC (system development life cycle);
Poniżej przedstawiona została klasyfikacja testów penetracyjnych ze względu na powyższe kryteria:
a) poziom posiadanej wiedzy:
- blackbox (czarna skrzynka) – metoda w której osoba testująca posiada minimalną ilość informacji o atakowanym systemie. Zazwyczaj jest to jedynie informacja o zakresie testów. Ma to na celu zasymulowanie ataku hackerskiego z zewnątrz (atakujący próbuje się włamać do systemu o którym nic nie wie);
- greybox (szara skrzynka) – metoda w której osoba testująca posiada pewien poziom wiedzy o systemie, ale bez dostępu do kodów źródłowych. Zazwyczaj posiada on wgląd do struktury danych np. poprzez udostępnione mu konto użytkownika z niskimi uprawnieniami. Atak ten ma na celu zasymulowanie ataku hackerskiego z wewnątrz firmy (atakujący jest pracownikiem firmy, bądź też posiada konto w systemie);
- whitebox (biała skrzynka) – metoda w której osoba testująca posiada pełen wgląd do dokumentacji technicznej. Test ten ma na celu w głównej mierze na przegląd kodu źródłowego i zlokalizowaniu w nim błędów bezpieczeństwa;
b) zakres testu:
- testy inwazyjne, które polegają na zasymulowaniu prawdziwego ataku np. modyfikacji danych czy też zablokowaniu usługi. Tym samym wpływają one na funkcjonowanie systemu;
- testy bezinwazyjne, które są przeciwieństwem testów inwazyjnych, więc nie wpływają na funkcjonowanie systemu. Polegają na wyszukiwaniu podatności bez praktycznego weryfikowania ich np. poprzez przegląd kodu źródłowego.
c) skład zespołu testerskiego:
- badania przeprowadzane przez pracowników wewnętrznych firmy;
- badania przeprowadzane przez firmę zewnętrzną;
- badania przeprowadzane przez skład mieszany tzn. pracowników wewnętrznych firmy oraz pracowników zewnętrznej firmy;
d) sposób przeprowadzania testów:
- testy eksperckie, przeprowadzane manualnie, to znaczy ręcznie przez wykwalifikowanego specjalistę;
- testy automatyczne przeprowadzane za pomocą przeznaczonych do tego narzędzi np. skanerów sieci, analizatorów kodu źródłowego;
- testy mieszane, w których skład wchodzą zarówno testy manualne jak i automatyczne;
e) lokalizacje testów:
- testy wewnętrzne, polegają na symulacji ataku z wewnątrz firmy z pominięciem zabezpieczeń takich jak zapory sieciowe, najczęściej z wykorzystaniem sieci intranet;
- testy zewnętrzne, polegają na symulacji na ataku z zewnątrz, np. poprzez Internet. W tym przypadku atakujący ma na swojej drodze do pokonania mechanizmy firewall czy też filtry aplikacyjne;
f) umiejscowienie w cyklu SDLC (system development life cycle):
- testy przeprowadzane w trakcie tworzenia oprogramowania. tak zwane test driven development;
- testy akceptacyjne, wykonywane na stworzonym już oprogramowaniu.
