Testy penetracyjne · Red teaming
Red teaming to wieloetapowa, kontrolowana symulacja ataku, która sprawdza, czy atakujący osiągnie cel ważny dla firmy - np. dostęp do danych klientów albo systemu płatności - i czy Twój zespół bezpieczeństwa to zauważy i zareaguje. Innovix z Wrocławia prowadzi red teaming dla dużych organizacji w całej Polsce, zdalnie i na miejscu: cele uzgadniamy z zarządem, a scenariusze obejmują perymetr, aplikacje i API, chmurę oraz założony incydent w sieci wewnętrznej. Bez phishingu, socjotechniki, testów fizycznych i DoS.
01Definicja
Red teaming to kontrolowana, wieloetapowa symulacja ataku prowadzona za pisemną zgodą organizacji. Zespół atakujący (red team) nie dostaje listy systemów do sprawdzenia, tylko cel - na przykład odczyt wskazanego zbioru danych testowych albo uzyskanie uprawnień do panelu, z którego zatwierdza się płatności - i szuka do niego drogi tak, jak zrobiłby to realny przeciwnik, w granicach uzgodnionych reguł.
Test penetracyjny ma szeroko pokryć podatności jednego systemu i opisać każdą z nich. Red teaming idzie wąsko i głęboko: interesuje go tylko ta ścieżka, która prowadzi do celu, oraz to, czy po drodze ktoś ją zauważył. Dlatego wynikiem jest nie tylko lista słabości, ale też odpowiedź na pytanie, jak działa wykrywanie i reagowanie w Twojej organizacji.
Szczegółowe porównanie z testem penetracyjnym, TLPT i purple teamingiem opisujemy w artykule red teaming a test penetracyjny.
02Dla kogo
Red teaming sprawdza dojrzałość obrony, więc daje najwięcej organizacjom, które mają już za sobą podstawy.
Po pentestach
Najważniejsze systemy były testowane, a podatności z raportów naprawiono i zweryfikowano retestem. Kolejny pentest tych samych aplikacji przyniósłby niewiele nowego - teraz liczy się to, jak słabości łączą się w ścieżkę ataku.
Wykrywanie i reagowanie
Logi trafiają do jednego miejsca, a ktoś - własny dział bezpieczeństwa albo zewnętrzny SOC - analizuje alerty. Red teaming pokaże, które etapy ataku generują alert, które przechodzą niezauważone i ile trwa reakcja.
Regulacje i zarząd
Zarząd chce wiedzieć, czy inwestycje w bezpieczeństwo działają, podmiot objęty ustawą o KSC ocenia skuteczność środków, a podmiot finansowy przygotowuje zespół do możliwego TLPT.
03Scenariusze
Scenariusz określa punkt startu i cel. W jednym ćwiczeniu można połączyć kilka scenariuszy.
| Scenariusz | Punkt startu | Przykładowy cel | Co sprawdza po stronie obrony |
|---|---|---|---|
| Perymetr zewnętrzny | Internet, tylko nazwa firmy i jej domeny | Dostęp do systemu wewnętrznego z zewnątrz | Czy rozpoznanie i próby dostępu do usług wystawionych na zewnątrz zostają zauważone |
| Aplikacje i API | Konto klienta albo partnera założone tak, jak może to zrobić każdy | Dane innych klientów albo funkcja zastrzeżona dla administratora | Czy nietypowe wywołania API i nadużycia logiki biznesowej generują alert |
| Chmura | Klucz aplikacji o ograniczonych uprawnieniach albo konto zwykłego użytkownika | Uprawnienia administracyjne w koncie lub subskrypcji, dostęp do magazynu danych | Czy zmiany uprawnień i dostęp do danych są rejestrowane i analizowane |
| Założony incydent (assumed breach) | Komputer zwykłego pracownika w sieci firmy, przygotowany przez Ciebie | Serwer z danymi wskazanymi przez zarząd albo uprawnienia administratora | Czy ruch wewnątrz sieci i użycie przejętych poświadczeń zostaje wykryte i zatrzymane |
Scenariusz założonego incydentu zaczyna się w miejscu, w którym realny atak często jest już po pierwszym kroku: atakujący ma dostęp do jednego komputera w firmie. Nie odtwarzamy tego, jak ten dostęp zdobył - nie prowadzimy kampanii phishingowych ani działań socjotechnicznych wobec pracowników. Dzięki temu cały czas ćwiczenia przypada na to, co dzieje się dalej i czy obrona to zatrzyma.
Każdy scenariusz opiera się na metodyce naszych testów: testów infrastruktury i sieci, aplikacji webowych, API i chmury. Jeśli w organizacji działa asystent albo agent AI z dostępem do danych, można go włączyć do ścieżki ataku - zakres takich testów opisujemy na stronie testów bezpieczeństwa aplikacji LLM.
04Reguły zaangażowania
Red team działa swobodniej niż pentester, dlatego zasady spisujemy dokładniej niż przy zwykłym teście.
Przed startem razem z zespołem kontrolnym przygotowujemy dokument reguł zaangażowania. Zawiera on:
Zespół kontrolny to zwykle przedstawiciel zarządu, który sponsoruje ćwiczenie, osoba odpowiedzialna za bezpieczeństwo i - gdy trzeba - prawnik albo inspektor ochrony danych. Tylko oni wiedzą o terminach i scenariuszach. Od nas dostają regularne informacje o postępie i decydują o wszystkim, czego reguły nie przewidziały.
Jeśli blue team wykryje działania red teamu, zespół kontrolny decyduje, co dalej: czy pozwolić obrońcom przeprowadzić pełną reakcję, czy ujawnić ćwiczenie i kontynuować od kolejnego etapu. Obie decyzje dają wartościowy wynik - ważne, żeby zapadły świadomie i zostały zapisane.
Jak przygotować zgody, kontakty awaryjne i powiadomienia dostawców, opisujemy w artykule o przygotowaniu do testu penetracyjnego - przy red teamingu obowiązuje to samo, z tą różnicą, że wiedza o teście zostaje w wąskim gronie.
05Bezpieczeństwo działań
Ćwiczenie ma pokazać ryzyko, a nie je zrealizować. Te zasady obowiązują w każdym scenariuszu.
06Przebieg
Sześć etapów od rozmowy z zarządem do weryfikacji napraw. Czas każdego z nich zależy od celów i liczby scenariuszy.
Rozmowa z zarządem o tym, co byłoby najbardziej bolesne dla firmy, wybór celów, skład zespołu kontrolnego i dokument reguł zaangażowania.
Analiza tego, kto realnie mógłby zaatakować organizację z Twojego sektora i jak, oraz informacji o firmie dostępnych publicznie. Na tej podstawie układamy scenariusze.
Działania red teamu według scenariuszy, z dziennikiem każdego kroku i regularnymi informacjami dla zespołu kontrolnego.
Usunięcie artefaktów, zestawienie ścieżki ataku z tym, co zarejestrowały systemy obrony, raport techniczny i podsumowanie dla zarządu.
Wspólne przejście ścieżki ataku z blue teamem: co było widać w logach, dlaczego alert się nie pojawił, jak to poprawić (purple teaming).
Priorytety zmian w zabezpieczeniach, wykrywaniu i procedurach, a po ich wdrożeniu ponowne sprawdzenie kluczowych etapów ścieżki.
07Co dostajesz
Raport z red teamingu odpowiada na trzy pytania: czy cel został osiągnięty, co obrona zauważyła i co zmienić najpierw.
Sesję z zespołem obrony traktujemy jako część raportu, a nie dodatek: dopiero wspólne przejście ścieżki pokazuje, które zdarzenia były w logach, ale nikt ich nie oglądał, a których w ogóle nie rejestrowano.
Strukturę raportu z testu i sposób opisu pojedynczego ustalenia pokazujemy na przykładowym raporcie z testu penetracyjnego.
| Krok | Działanie red teamu | Wykrycie | Reakcja |
|---|---|---|---|
| 1 | Rozpoznanie usług widocznych z internetu | Brak alertu | Brak (zgodnie z oczekiwaniem) |
| 2 | Dostęp do danych innego klienta przez błąd uprawnień w API | Brak alertu | Brak - zdarzenie widoczne w logach aplikacji, nieanalizowane |
| 3 | Logowanie przejętymi poświadczeniami na serwer w sieci wewnętrznej | Alert po kilku godzinach | Zgłoszenie w SOC, brak izolacji hosta |
| 4 | Odczyt pliku testowego wskazanego jako cel | Brak alertu | Cel osiągnięty - zespół kontrolny zamyka scenariusz |
08TLPT i regulacje
TLPT (testy penetracyjne ukierunkowane przez analizę zagrożeń) to red teaming w procedurze rozporządzenia (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA). Przeprowadzają go podmioty finansowe wskazane przez organ nadzoru, w Polsce przez KNF w drodze decyzji (art. 18zk ustawy o nadzorze nad rynkiem finansowym), nie rzadziej niż co trzy lata (art. 26 ust. 1 DORA). Scenariusze przygotowuje zewnętrzny dostawca analizy zagrożeń, aktywna faza red team trwa co najmniej 12 tygodni (art. 11 ust. 5 rozporządzenia delegowanego (UE) 2025/1190), a cały test nadzoruje organ, który na końcu wydaje poświadczenie. Wymagania wobec testerów TLPT i przebieg testu opisujemy na stronie o przygotowaniu do TLPT.
Nie jesteśmy testerem TLPT i nasz red teaming nie zastępuje tego testu ani nie daje poświadczenia organu. Może natomiast przygotować do niego organizację:
Różnice między testami z art. 24-25 DORA a TLPT wyjaśniamy w artykule testy penetracyjne a TLPT w DORA, a usługi dla banków, ubezpieczycieli i fintechów - na stronie testów penetracyjnych dla finansów i ubezpieczeń.
09Wycena
Red teaming wyceniamy indywidualnie po rozmowie z zespołem kontrolnym. Na cenę wpływają przede wszystkim:
Kwot nie publikujemy, bo pod nazwą „red teaming” kryją się bardzo różne zakresy. Ogólne zasady wyceny testów opisujemy na stronie czynników wyceny testów penetracyjnych. Zespół testów bezpieczeństwa pracuje z Wrocławia; scenariusze zewnętrzne, aplikacyjne i chmurowe prowadzimy zdalnie, a scenariusz w sieci wewnętrznej - przez przygotowany komputer w Twojej sieci albo na miejscu, w każdym mieście w Polsce.
Takie, których osiągnięcie przez atakującego zarząd uznałby za poważny incydent: odczyt wskazanego zbioru danych, uprawnienia do panelu zatwierdzania płatności albo uprawnienia administracyjne w koncie chmurowym. Cel wybieramy na pierwszej rozmowie z zarządem i zapisujemy w regułach zaangażowania razem ze sposobem udowodnienia - red team pokazuje odczyt podłożonego pliku testowego albo zrzut uprawnień, a nie kopiuje danych produkcyjnych. Jedno ćwiczenie może mieć jeden lub kilka celów, a każdy może być osiągany w innym scenariuszu.
Nie. Nie prowadzimy phishingu, socjotechniki, testów fizycznych ani testów DoS. Etap wejścia do sieci zastępuje scenariusz założonego incydentu: startujemy z komputera zwykłego pracownika przygotowanego przez Ciebie i sprawdzamy, co atakujący może zrobić dalej i czy obrona to zatrzyma.
Od liczby celów i scenariuszy oraz od wariantu ćwiczenia - z blue teamem uprzedzonym albo nieuprzedzonym o teście. Red teaming trwa dłużej niż test penetracyjny pojedynczego systemu, bo obejmuje przygotowanie scenariuszy, fazę aktywną, raport i sesję z zespołem obrony. Harmonogram podajemy w ofercie po rozmowie zakresowej.
Nie. Wystarczy, że ktoś analizuje alerty - własny zespół albo zewnętrzny dostawca usług SOC. Jeśli nikt nie przegląda logów, red teaming pokaże głównie brak wykrywania, a to taniej ustalić w przeglądzie i testach penetracyjnych. Wtedy zaczynamy od nich, a red teaming planujemy jako kolejny krok.
Testy penetracyjne · Infrastruktura
Testy penetracyjne i audyt bezpieczeństwa infrastruktury i sieci - perymetr, VPN, sieć wewnętrzna, przegląd zapór. Według NIST SP 800-115, bez testów DoS.
Testy penetracyjne · Chmura
Testy penetracyjne i audyt bezpieczeństwa chmury AWS, Azure i Google Cloud - IAM, sieci, magazyny danych, logowanie i szyfrowanie według CIS Benchmarks.
DORA · Przygotowanie do TLPT
Przygotowanie do TLPT w DORA: testy penetracyjne i przeglądy kodu z art. 24-25, ocena gotowości, wybór dostawców testu i weryfikacja napraw po teście.
Opisz krótko, czego potrzebujesz - wrócimy z propozycją kolejnych kroków.
lub zadzwoń pod numer +48 575 621 877