Formalny szablon zasad prowadzenia testów bezpieczeństwa (Rules of Engagement) oraz struktura przyjmowania zgłoszeń podatności (Vulnerability Disclosure). Dokument do wypełnienia i podpisania przed jakąkolwiek aktywnością testową. Bez podpisanego RoE nie ma autoryzacji, a bez autoryzacji nie ma testu.
[…]. Realne testy bezpieczeństwa są dopuszczalne wyłącznie po podpisaniu RoE przez umocowane strony i po pisemnej autoryzacji zakresu. Wypełnienie tej strony niczego nie autoryzuje.
Każda aktywność ofensywna wymaga śladu: podpisany zakres, okno czasowe, kanał deconfliction. Brak podpisu = status GAP. Ten portal nie zawiera i nie udostępnia żadnych payloadów ofensywnych — dostarcza wyłącznie ramy proceduralne.
Treść wzorca RoE i pola intake są dostępne i kompletne jako referencja dokumentacyjna.
Elektroniczny sign-off, wersjonowanie i archiwizacja podpisanych RoE — brak żywej implementacji.
Przyjmowanie zgłoszeń VDP przez formularz/API, kolejka triage, nadawanie public_id — planowane.
Docelowy magazyn autoryzowanych zakresów i okien czasowych; obecnie tylko model danych.
[Zwięzły cel — np. weryfikacja odporności bankowości elektronicznej na phishing i przejęcie sesji; ocena segmentacji sieci; walidacja playbooków SOC. Cel określa, co jest przedmiotem dowodu, nie „ile luk znajdziemy".]
Wyłącznie zasoby wymienione poniżej są autoryzowane. Cokolwiek nie jest wprost wpisane — jest poza zakresem.
| Zasób | Typ | Identyfikator | Środowisko | Uwagi |
|---|---|---|---|---|
| [domena] | WWW / API | [app.przyklad.pl] | [staging / prod] | [okno, throttling] |
| [zakres IP] | Sieć | [203.0.113.0/28] | [DMZ] | [bez skanów agresywnych] |
| [aplikacja mobilna] | Mobile | [bundle id / wersja] | [test] | [tylko konta testowe] |
| [agent / model AI] | AI / LLM | [endpoint, wersja] | [sandbox] | [testy prompt-injection w izolacji] |
Poniższe są bezwzględnie wyłączone, niezależnie od zakresu. Naruszenie unieważnia safe harbor (A.7).
| Technika | Status | Doprecyzowanie |
|---|---|---|
| DoS / DDoS / stress | ZAKAZ | Żadnych działań degradujących dostępność, w tym flooding, resource exhaustion, testy wydajnościowe bez odrębnej zgody. |
| Socjotechnika | ZAKAZ | Phishing pracowników, vishing, pretexting, przynęty fizyczne — chyba że objęte osobnym, wyraźnym aneksem. |
| Ataki fizyczne | ZAKAZ | Wejście do obiektów, tailgating, manipulacja sprzętem, dostęp do okablowania. |
| Eksfiltracja danych | ZAKAZ | Zakaz pobierania/kopiowania danych realnych. Dowód dostępu = zrzut metadanych/PoC, nie wynoszenie zawartości. |
| Naruszenie prywatności | ZAKAZ | Dostęp do danych osobowych klientów, korespondencji, treści prywatnych. Przy przypadkowym dostępie — natychmiastowy stop + zgłoszenie. |
| Ataki na third-party | ZAKAZ | Pivotowanie do dostawców, systemów partnerów, infrastruktury współdzielonej poza kontrolą zleceniodawcy. |
| Destrukcja / trwała zmiana | ZAKAZ | Kasowanie, szyfrowanie, modyfikacja produkcyjnych danych i konfiguracji. |
Zleceniodawca zobowiązuje się nie inicjować postępowań cywilnych ani nie składać zawiadomień karnych wobec Wykonawcy z tytułu działań podjętych w ramach niniejszego RoE, wyłącznie i pod warunkiem, że działania te były:
Ochrona safe harbor nie obejmuje działań wykraczających poza którykolwiek z powyższych warunków. Przekroczenie zakresu, eksfiltracja danych lub wyrządzenie szkody powoduje automatyczne wygaśnięcie ochrony w odniesieniu do danego czynu. Safe harbor nie zwalnia z obowiązków wynikających z bezwzględnie obowiązujących przepisów prawa.
Sukces mierzony jest jakością dowodu i pokryciem, nie samą liczbą znalezisk.
| Kryterium | Miara | Próg akceptacji |
|---|---|---|
| Pokrycie zakresu | % zasobów in-scope faktycznie przetestowanych | [≥ 90%] |
| Jakość dowodu | Każde znalezisko z repro + PoC + poziomem pewności | [100% znalezisk P0/P1] |
| Brak szkody | Incydenty dostępności/integralności spowodowane testem | [0] |
| Deconfliction | Czas potwierdzenia aktywności na żądanie SOC | [≤ 15 min] |
| Terminowość raportu | Dostarczenie raportu po zamknięciu okna | [≤ 5 dni roboczych] |
| Rola | Kto | Zakres odpowiedzialności |
|---|---|---|
| White team | [koordynator, obie strony] | Nadzór nad RoE, deconfliction, arbitraż STOP, kontrola zakresu i okna. Jedyna rola z pełną wiedzą o teście. |
| Red team | [Wykonawca] | Symulacja przeciwnika w granicach A.3–A.6. Dokumentacja każdego kroku. Zero payloadów niszczących. |
| Blue team | [SOC zleceniodawcy] | Detekcja i reakcja. W trybie double-blind może nie wiedzieć o teście — decyzja w A.1. |
| Purple team | [wspólny] | Iteracyjna wymiana: red pokazuje wektor, blue wzmacnia detekcję. Cel = odporność, nie punktacja. |
| Rola | Imię i nazwisko | Funkcja / umocowanie | Podpis | Data |
|---|---|---|---|---|
| Zleceniodawca | [……] | [……] | [……] | [YYYY-MM-DD] |
| Wykonawca (kierownik testu) | [……] | [……] | [……] | [YYYY-MM-DD] |
| White team (koordynator) | [……] | [……] | [……] | [YYYY-MM-DD] |
Dokument obowiązuje od chwili złożenia wszystkich wymaganych podpisów. Do tego momentu status autoryzacji: GAP — brak zgody na testy.
Struktura przyjmowania zgłoszeń podatności w ramach polityki Vulnerability Disclosure. Pola poniżej stanowią wzorzec formularza. Faktyczne przyjmowanie i triage zgłoszeń przez system: ROADMAP.
Zwięzły opis podatności — [np. „Odbite XSS w wyszukiwarce panelu"].
Numerowana lista odtworzenia. Deterministyczna. Bez tego zgłoszenie ma status GAP.
Konsekwencja biznesowa/techniczna: poufność, integralność, dostępność, dane osobowe.
Wektor i wynik [np. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5]. Klasyfikacja wstępna zgłaszającego.
Minimalny, nieniszczący PoC dowodzący podatności. Zero eksfiltracji danych realnych.
Kanał zwrotny do zgłaszającego, zgoda na politykę disclosure, opcjonalny klucz PGP.