Jak pracuję — test penetracyjny od środka

Zanim cokolwiek uruchomię: ustalenia i zgoda

Pierwszy etap nie dzieje się w sieci, tylko w rozmowie. Ustalamy zakres — które adresy, aplikacje i konta wchodzą do testu, a co zostaje poza nim — oraz techniki, które są dopuszczalne, a które wykluczone. Osobno omawiamy działania o charakterze inwazyjnym: próby eksploatacji podatności i testy obciążeniowe. Tylko ta część wymaga zwykle okna poza godzinami pracy.

Sam test prowadzony standardowo nie zakłóca pracy Państwa zespołu. Rozpoznanie i weryfikacja podatności to ruch sieciowy porównywalny z codzienną pracą kilku osób. Zauważalny efekt bywa inny: Państwa systemy EDR i antywirus zgłoszą zdarzenia, bo takie działania wyglądają z ich strony jak atak. Dlatego warto wcześniej uprzedzić zespół odpowiedzialny za bezpieczeństwo i monitoring, żeby nie analizował tych alarmów jak prawdziwego incydentu.

Do tego dochodzi zgoda na piśmie — z podpisem osoby upoważnionej, ze wskazaniem zakresu i okresu. Bez tego dokumentu nie zaczynam, nawet gdy zlecenie jest ustalone ustnie. Dostaję również kontakt techniczny po Państwa stronie: kogo powiadomić, jeśli w trakcie pracy natrafię na objaw awarii, oraz jak postępować w razie incydentu.

Ustalamy też jedną rzecz, która dotyczy zakończenia pracy. Ustalenia z testu przekazuję w całości w raporcie, po uporządkowaniu środowiska. Nie wysyłam wniosków po kawałku w trakcie — raportowanie na bieżąco zaczyna żyć własnym życiem, angażuje Państwa zespół w natychmiastowe naprawy i rozbija obraz całości, przez co trudniej ocenić, co jest skutkiem czego. Jedyny wyjątek dotyczy realnego zagrożenia: jeśli natrafię na ślad aktywnego incydentu — działające złośliwe oprogramowanie albo ślad włamania — wstrzymuję test i informuję Państwa od razu.

Urządzenie testowe w Państwa sieci

Pracuję zdalnie. Do Państwa lokalizacji trafia urządzenie testowe — minikomputer wielkości małego radia, który podłącza się do sieci przewodem Ethernet. Państwa administrator wybiera, gdzie je wpiąć, i podłącza zasilanie. To wszystko, czego potrzebuję na miejscu; nikt z Państwa nie musi nic konfigurować ani udostępniać dostępu do stacji roboczej.

Jedna rzecz jest tu istotna i proszę jej nie pomijać: urządzenie powinno trafić do sieci użytkowników, a nie do segmentu serwerowego. Test prowadzony z pozycji zwykłego użytkownika jest najbardziej wiarygodny, bo odpowiada na pytanie, co realnie osiągnie napastnik, który wszedł przez konto pracownika albo przejął jego stację. Widok z sieci użytkowników pokazuje też to, czego nie widać z serwerowni: co jest osiągalne między stanowiskami, gdzie panuje zbyt duże zaufanie i które usługi wystawiliśmy na wewnętrzną sieć niepotrzebnie.

Urządzenie zestawia szyfrowany tunel VPN, przez który prowadzę test ze swojego środowiska. Nie jest to urządzenie pomiarowe ani nasłuchujące — to punkt wejścia do Państwa sieci, z którego wykonuję dokładnie te działania, które obejmuje zakres. Nie zbiera ruchu użytkowników i nie działa po zakończeniu testu: tunel zamykam, a urządzenie wraca do mnie.

Taki sposób pracy ma trzy zalety praktyczne. Nie trzeba zamawiać wizyty ani wyłączać ludzi z pracy na czas obecności konsultanta. Test można rozłożyć na kilka dni i wracać do niego po ustaleniach z Państwa zespołem. A ponieważ nie siedzę w Państwa biurze, nikt nie musi organizować dostępu do pomieszczeń ani przepustek.

Cztery etapy pracy

1. Rozpoznanie — ustalam, co jest w zasięgu: aktywne urządzenia, otwarte usługi, wersje oprogramowania, konta o niskich uprawnieniach. Na tym etapie nie zmieniam niczego w systemach.
2. Weryfikacja podatności — z listy potencjalnych słabości sprawdzam, które faktycznie występują w Państwa środowisku. Skanowanie automatyczne daje tu kandydatów; rozstrzygam ręcznie.
3. Dowód i ocena skutku — dla potwierdzonej podatności ustalam, co realnie zyskuje napastnik: dostęp do jakich danych, do jakich systemów, czy da się z tego rozwinąć atak dalej. Robię to w granicach zakresu i zapisuję dowód.
4. Porządki i raport — usuwam ślady własnej pracy, przekazuję ustalenia i raport z zaleceniami. Dopiero wtedy kończę zlecenie.

Kolejność jest istotna i rzadko bywa skracana. Rozpoznanie bez weryfikacji daje długą listę ostrzeżeń, z których część jest nieprawdziwa — a to najgorszy możliwy materiał do planowania napraw, bo zespołowi brakuje czasu i uwagi.

Co dzieje się z dowodami z testu

Dowody z testu — zrzuty ekranu, fragmenty odpowiedzi systemów, ewentualne pliki pozyskane w ramach demonstracji skutku — trafiają do archiwum na zaszyfrowanym nośniku. Mówię o tym wprost, bo to nie jest materiał jednorazowy: zostaje u mnie jako podstawa do weryfikacji własnych ustaleń, oceny trafności przyjętych założeń i porównania z kolejnymi testami w tym samym środowisku. Dzięki temu przy następnym zleceniu nie zaczynam od zera i widzę, co realnie zmieniło się w Państwa sieci.

W granicach pracy obowiązuje mnie zasada minimalnego zakresu: nie kopiuję tego, czego nie potrzebuję do udowodnienia ustalenia, i nie przenoszę z Państwa środowiska dokumentów ani baz danych. W raporcie zamieszczam tylko to, co pozwala zrozumieć problem i naprawę — końcówkę identyfikatora hosta, nazwę usługi, sposób powtórzenia — bez danych osobowych i bez treści Państwa dokumentów. Zasady dostępu do archiwum, jego zabezpieczenia i czasu przechowywania opisujemy w umowie, żeby było to ustalone przed startem, a nie domyślane po fakcie.

Raport: streszczenie zarządcze i część techniczna

Raport ma dwie części. Otwiera go streszczenie zarządcze — jedno- lub dwustronicowe podsumowanie dla osób decyzyjnych: co jest najpoważniejsze, jakie jest ryzyko w praktyce, co zrobić w pierwszej kolejności i ile pracy to zajmie. Napisane bez żargonu, bo czyta je zarząd i właściciel procesu, a nie tylko dział IT.

Dalej jest część techniczna: ustalenia podzielone według klas — krytyczne, wysokie, średnie, niskie i informacyjne. Każde opisane tak, by dało się je powtórzyć i sprawdzić po naprawie: gdzie występuje, na czym polega, co zyskuje napastnik, jak to sprawdzić i co zmienić. Do każdego podaję kierunek naprawy — konkretną zmianę konfiguracji, aktualizację albo decyzję architektoniczną, a nie ogólne „wdrożyć dobre praktyki”. Na końcu dokumentu jest zestawienie pozwalające ustawić kolejność prac: co naprawić natychmiast, co da się odłożyć i co nie ma znaczenia dla bezpieczeństwa, choć wygląda poważnie.

Retest — jeśli został wykupiony

Retest nie jest częścią testu i nie dzieje się automatycznie. To osobna usługa: wracam po naprawach i sprawdzam ponownie te ustalenia, które zostały zamknięte. Nie powtarzam całego testu — weryfikuję konkretne punkty i sprawdzam, czy naprawa nie otworzyła czegoś innego. Wynikiem jest krótki dokument: co jest zamknięte, co nadal otwarte, co zmieniło charakter. Zakres i orientacyjny koszt opisuję w sekcji retestu po naprawach.

Czego po tej pracy nie ma

Nie prowadzę testów w ruchu publicznym — nie „war drivinguję” po okolicy w poszukiwaniu otwartych sieci. Nie robię tego, bo wynik takiej pracy obciąża osoby postronne, a nie Państwa organizację.

Nie raportuję częściowo. W trakcie testu nie wysyłam list ustaleń, bo taka lista zaczyna żyć własnym życiem: zespół rzuca się do naprawy wybranych punktów, środowisko zmienia się pod ręką, a część najbardziej wartościowych obserwacji przestaje być możliwa do sprawdzenia. Dokument po zakończeniu pracy jest spójny i kompletny. Wyjątkiem pozostaje realny incydent opisany wyżej.

Nie zostawiam po sobie śmieci. W ramach porządków usuwam konta, pliki i zmiany, które powstały wyłącznie na potrzeby testu, i przekazuję listę tego, co po mnie zostało do weryfikacji przez Państwa administratora.

Ile to trwa i jak wpiąć to w kalendarz

Czas zależy od liczby hostów i od tego, jak głęboko wchodzimy. Orientacyjne wielkości — wraz z modelem wyliczenia i przykładowymi kwotami — są w sekcji wycena testu penetracyjnego. Same terminy i kalendarz omawiamy przy ustalaniu zakresu: realny start to zwykle kilka dni roboczych od podpisania zgody, bo tyle potrzebuję na przygotowanie środowiska i potwierdzenie zakresu.

Jeśli nie wiedzą Państwo, który wariant testu wybrać, prościej opisać środowisko w krótkiej wiadomości — liczba hostów, podsieci, systemy, które bolą najbardziej. Powiem, co ma sens, a czego w tej chwili nie warto kupować. Zestaw wariantów zebrany jest na stronie wariantów testu.

Pytania o ten wariant

Czy muszę być na miejscu w trakcie testu?+

Nie. Urządzenie testowe podłącza administrator i od tego momentu pracuję zdalnie. Potrzebuję jednego kontaktu technicznego po Państwa stronie, do którego mogę zadzwonić, jeśli w trakcie pracy natrafię na coś, co wymaga decyzji.

Do którego miejsca w sieci podłączyć urządzenie testowe?+

Do sieci użytkowników — tam, gdzie pracują Państwa ludzie, a nie do segmentu serwerowego. Test z pozycji zwykłego użytkownika jest najbardziej wiarygodny: pokazuje, co osiągnie napastnik, który wszedł przez konto pracownika albo przejął jego stację. Widok z serwerowni tego nie pokaże.

Czy test zakłóci pracę zespołu?+

Standardowy zakres nie zakłóca pracy — to ruch sieciowy porównywalny z codzienną pracą kilku osób. Część inwazyjna, czyli próby eksploatacji podatności i testy obciążeniowe, jest ustalana osobno i to ona wymaga okna poza godzinami pracy. Uprzedzić warto dział bezpieczeństwa: Państwa EDR i antywirus zgłoszą zdarzenia, bo z ich strony wygląda to jak atak.

Czy urządzenie testowe jest bezpieczne dla mojej sieci?+

To minikomputer z systemem o minimalnej konfiguracji, bez usług nasłuchujących na Państwa sieci i bez zapisu ruchu użytkowników. Komunikacja idzie szyfrowanym tunelem, a dostęp do urządzenia zabezpieczony jest kluczem. Po zakończeniu testu tunel jest zamykany, a samo urządzenie wraca do mnie.

Co, jeśli w trakcie testu wystąpi awaria systemu?+

Przerywam pracę i kontaktuję się z ustalonym kontaktem technicznym. Zakres działań, które mogą obciążyć systemy produkcyjne, ustalamy przed startem — dlatego ryzyko takiej sytuacji jest małe i przewidziane w umowie.

Dostanę częściowe wyniki w trakcie pracy?+

Nie, poza jednym wyjątkiem. Ustalenia przekazuję w raporcie po zakończeniu pracy, bo raportowanie po kawałku angażuje Państwa zespół w natychmiastowe naprawy, zmienia środowisko w trakcie testu i rozbija obraz całości. Wyjątkiem jest realne zagrożenie — ślad aktywnego incydentu. Wtedy wstrzymuję test i informuję od razu.

Co się dzieje z dowodami po zakończeniu?+

Trafiają do archiwum na zaszyfrowanym nośniku i zostają u mnie jako materiał do weryfikacji własnych ustaleń oraz punkt odniesienia przy kolejnych testach w tym środowisku. Nie kopiuję niczego ponad to, co potrzebne do udowodnienia ustalenia, a w raporcie zamieszczam minimum pozwalające zrozumieć problem i naprawę — bez danych osobowych i bez treści Państwa dokumentów. Zasady dostępu, zabezpieczenia i czasu przechowywania archiwum ustalamy w umowie.

Czy po naprawach muszę zlecać cały test od nowa?+

Retest jest osobną usługą — uruchamiamy ją, jeśli zostanie wykupiona. Obejmuje wtedy tylko ustalenia zamknięte po poprzednim teście: sprawdzam, czy naprawa działa i czy nie otworzyła nowej drogi. To krótsza i tańsza praca niż pełny test, a przy okazji daje dokument pokazujący postęp.

Uzyskaj wycenę

Krótki opis środowiska wystarczy — liczba hostów, podsieci i systemy, które wymagają sprawdzenia. Odpowiem w ciągu 24 h w dni robocze i potwierdzę zakres oraz termin.

Jeśli nie wiedzą Państwo, od czego zacząć, pomocne mogą być opisy wariantów: test sieci wewnętrznej, test Active Directory, test aplikacji webowych i API oraz test zdalny. Najczęstsze pytania — o czas, ceny, podstawy prawne i dane z testu — zebrałem w sekcji pytania i odpowiedzi.