“Mamy raport z pentestów. 47 podatności, w tym 8 krytycznych. Raport trafił do IT i… nic się nie stało.” To historia, którą słyszymy regularnie. Firmy wydają dziesiątki tysięcy złotych na testy penetracyjne, otrzymują szczegółowe raporty z konkretnymi podatnościami - a potem te raporty lądują w szufladzie. Nazywamy to remediation gap - lukę między identyfikacją problemu a jego naprawą.
Remediation gap w liczbach
Dane branżowe rysują niepokojący obraz:
| Statystyka | Wartość | Źródło |
|---|---|---|
| Firmy nienawiające podatności krytycznych w 90 dni | 73% | Verizon DBIR 2024 |
| Średni czas naprawy podatności krytycznej | 205 dni | Qualys Research |
| Podatności wysokiego ryzyka otwarte po roku | 45% | Kenna Security |
| Firmy powtarzające te same podatności w kolejnym pentescie | 60% | Dane własne nFlo |
Ponad połowa firm, które zlecają re-test penetracyjny po roku, ma nadal te same podatności co poprzednio. To oznacza, że pierwszy pentest był zmarnowaną inwestycją.
📚 Przeczytaj kompletny przewodnik: Testy Penetracyjne: Testy penetracyjne - rodzaje, metodologie, przebieg
Dlaczego firmy nie naprawiają podatności?
1. Zespół IT jest przeciążony
To najpowszechniejsza przyczyna. Dział IT ma 3-5 osób, które:
- Obsługują helpdesk (100 ticketów dziennie)
- Utrzymują infrastrukturę (serwery, sieci, backup)
- Wdrażają nowe projekty (biznes ciśnie)
- Gasią pożary (coś się zepsuło, VIP nie może się zalogować)
Raport z pentestów trafia na koniec kolejki. “Zajmiemy się tym jak będziemy mieć czas”. Czas nigdy nie przychodzi.
2. Brak kompetencji
Pentest wskazuje: “Słaba konfiguracja Kerberos - podatność na Kerberoasting”.
Admin IT myśli: “Co to Kerberoasting? Jak to naprawić? Gdzie szukać?”
Pentesterzy są świetni w znajdowaniu dziur. Ale ich raporty często zakładają poziom wiedzy, którego typowy admin nie ma. Bez konkretnych kroków “klik tu, wpisz to” - naprawa nie następuje.
3. Strach przed zmianą
“Jak zmienię konfigurację firewalla, to może przestać działać poczta”.
“Jak zaktualizuję serwer, to stara aplikacja może się posypać”.
IT boi się zmian, bo zmiany generują problemy. Lepiej żyć z teoretyczną podatnością niż z pewnym outage’m po nieudanej poprawce. To błędne myślenie, ale ludzkie.
4. Brak ownership
Raport wskazuje 47 podatności w 15 różnych systemach. Kto jest odpowiedzialny za naprawę każdej z nich?
- Aplikacja webowa → zespół developerów
- Active Directory → admin systemowy
- Firewall → admin sieci
- Baza danych → DBA
Bez jasnego przypisania ownership, każdy czeka aż “ktoś inny” naprawi.
5. Brak priorytetyzacji
47 podatności. Od czego zacząć?
Jeśli raport nie daje jasnej odpowiedzi “te 3 napraw w tym tygodniu, te 5 w tym miesiącu, reszta może poczekać” - IT rozkłada ręce. Wszystko jest pilne = nic nie jest pilne.
6. Silosy organizacyjne
- Pentest zamówił CISO (compliance wymaga)
- Raport dostał IT (bo to “techniczne”)
- IT raportuje do CTO (nie do CISO)
- CTO ma inne priorytety (nowe funkcje, nie łatanie dziur)
- Nikt nie koordynuje, nikt nie rozlicza
Konsekwencje niezamkniętego cyklu
Konsekwencja 1: Zmarnowana inwestycja
Pentest kosztował 30 000 PLN. Jeśli nic nie naprawisz - to wyrzucone pieniądze. Równie dobrze mógłbyś nie robić pentestu w ogóle.
Konsekwencja 2: Fałszywe poczucie bezpieczeństwa
“Mieliśmy pentest, jesteśmy bezpieczni”. Nie, mieliście pentest który pokazał że NIE jesteście bezpieczni. Sam pentest niczego nie naprawia.
Konsekwencja 3: Audytor pyta o follow-up
Audytor ISO 27001 / NIS2: “Widzę raport z pentestów z marca. Jakie działania naprawcze podjęliście?”
Ty: ”…”
To jest finding audytowy. Świadome ignorowanie zidentyfikowanych ryzyk to gorsze niż nie wiedzieć o nich.
Konsekwencja 4: Incydent, który można było przewidzieć
Włamanie przez podatność opisaną w raporcie sprzed 6 miesięcy. Zarząd pyta: “Wiedzieliście o tej dziurze?” Tak, wiedzieliście. Był raport. Co teraz?
Jak zamknąć cykl: pentest → naprawa → weryfikacja
Krok 1: Priorytetyzacja przed raportem
Dobry pentest to nie tylko lista podatności z CVSS. To priorytetyzacja według ryzyka biznesowego:
| Podatność | CVSS | Business Impact | Priorytet |
|---|---|---|---|
| SQL Injection w portalu klienta | 9.8 | Dane 100k klientów | P1 - Tydzień |
| Słabe hasła w AD | 7.5 | Dostęp do wszystkiego | P1 - Tydzień |
| XSS w panelu admina | 6.1 | Tylko 3 adminów | P2 - Miesiąc |
| TLS 1.0 na dev serwerze | 5.3 | Brak prod danych | P3 - Kwartał |
CVSS to nie wszystko. SQL Injection na serwerze testowym (CVSS 9.8, ale brak danych) jest mniej pilne niż słabe hasła w produkcyjnym AD (CVSS 7.5, ale dostęp do wszystkiego).
Krok 2: Plan naprawczy z ownership
Dla każdej podatności:
- Co naprawić (szczegółowy opis)
- Kto odpowiedzialny (nazwisko, nie dział)
- Kiedy deadline (konkretna data)
- Jak zweryfikować (kryterium sukcesu)
| ID | Podatność | Owner | Deadline | Weryfikacja |
|---|---|---|---|---|
| V-001 | SQL Injection | Jan Kowalski | 15.02 | Retest przez nFlo |
| V-002 | Weak AD passwords | Anna Nowak | 22.02 | Audit GPO |
| V-003 | Missing patches | Piotr Wiśniewski | 01.03 | WSUS report |
Krok 3: Regularne follow-up
Nie wystarczy stworzyć plan i o nim zapomnieć.
Tygodniowo:
- Status update od ownerów (zrobione / w toku / zablokowane)
- Eskalacja blokerów
Miesięcznie:
- Raport postępu dla zarządu
- Aktualizacja priorytetów (nowe podatności, zmiany w biznesie)
Krok 4: Retest
Po naprawie - weryfikacja. Nie “admin mówi że naprawił”. Pentester wraca i sprawdza:
- Czy podatność faktycznie naprawiona?
- Czy naprawa nie wprowadziła nowych problemów?
- Czy coverage jest kompletny (wszystkie warianty)?
Dopiero po pozytywnym re-teście podatność jest zamknięta.
Remediation Support - partner, nie policjant
Problem z modelem “pentest i cześć”
Tradycyjny model:
- Firma pentestowa robi test
- Dostarcza raport
- Znika
Zostawiają klienta z listą 50 podatności i życzeniem powodzenia. To jak lekarz który diagnozuje chorobę, wypisuje 20 leków których nie można kupić w aptece, i mówi “zdrówka!”.
Model “Pentest + Fix”
Nowe podejście:
- Testy penetracyjne (jak zawsze)
- Sesja priorytetyzacji (2h z klientem)
- Pakiet godzin wsparcia remediacji
- Retest naprawionych podatności
Pentester nie tylko wytyka błędy - pomaga je naprawić. Siada z adminem i wspólnie konfigurują WAF, hardening AD, patche.
Korzyści wsparcia remediacji
Dla IT:
- Nie muszą się uczyć wszystkiego sami
- Mają eksperta do trudnych pytań
- Transfer wiedzy - uczą się przy okazji
Dla Security:
- Podatności faktycznie naprawione
- Zamknięty cykl do pokazania audytorowi
- Mierzalny postęp (nie tylko “raport dostarczony”)
Dla biznesu:
- Jeden dostawca od A do Z (mniej koordynacji)
- Szybszy time-to-fix
- Lepszy ROI z pentestów
Best practices dla skutecznej remediacji
1. Ustal SLA przed pentestem
Zanim zamówisz pentest, uzgodnij wewnętrznie:
- Kto będzie naprawiał (zasoby IT)?
- W jakim czasie (SLA per kategoria)?
- Kto koordynuje (CISO/Security/IT Manager)?
Nie ma sensu robić pentestu, jeśli nie masz ludzi do naprawy.
2. Bądź na sesji zamykającej
Pentesterzy robią zazwyczaj “debriefing” po testach. Bądź tam. Zadawaj pytania. Upewnij się że rozumiesz CO naprawić i JAK.
3. Nie bój się prosić o pomoc
Jeśli nie wiesz jak naprawić daną podatność - powiedz. Lepiej poprosić o wsparcie niż zostawić dziurę otwartą. Dobry vendor pentestowy pomoże lub wskaże kierunek.
4. Automatyzuj gdzie możesz
Niektóre podatności można naprawić automatycznie:
- Brakujące patche → WSUS/SCCM
- Słabe hasła → GPO + password policy
- Stare TLS → konfiguracja grupy
Automatyzacja = powtarzalność = mniej pracy przy następnym pentescie.
5. Ucz się z każdego pentestu
Po zamknięciu cyklu:
- Co poszło dobrze?
- Co było blokerem?
- Jakie procesy poprawić na przyszłość?
Każdy kolejny pentest powinien być łatwiejszy do remediation, bo uczysz się na błędach.
6. Wbuduj remediation w umowę
Rozważ model “Pentest + Fix” od początku:
- Stała cena za pentest + pakiet godzin remediation
- Retest wliczony w cenę
- Jeden dostawca, jedno rozliczenie
Podsumowanie
Remediation gap to jedna z największych luk w cyberbezpieczeństwie organizacji. Firmy wydają pieniądze na identyfikację problemów, ale nie na ich naprawę. To jak kupić alarm do domu i nigdy go nie włączyć.
Zamknięcie cyklu wymaga:
- Priorytetyzacji - wiesz co naprawić najpierw
- Ownership - wiesz kto odpowiada
- Wsparcia - masz kogoś kto pomoże
- Weryfikacji - masz pewność że naprawione
Sam pentest bez remediacji to zmarnowana inwestycja. Raport w szufladzie nie chroni przed atakiem.
Masz raport z pentestów i nie wiesz jak ruszyć z naprawą? Oferujemy wsparcie remediacji - pomagamy naprawić znalezione podatności. Skontaktuj się z nami, żeby omówić szczegóły.
Powiązane pojęcia
Poznaj kluczowe terminy związane z tym artykułem w naszym słowniku cyberbezpieczeństwa:
- Analiza podatności kodu źródłowego — Analiza podatności kodu źródłowego to proces systematycznego badania kodu…
- Cyberbezpieczeństwo — Cyberbezpieczeństwo to zbiór technik, procesów i praktyk ochrony systemów IT,…
- Firewall — Firewall (zapora sieciowa) to system zabezpieczeń, który monitoruje i…
- IT Security — IT Security to praktyki i technologie chroniące systemy informatyczne, sieci i…
- NIS2 — NIS2 (Network and Information Security Directive 2) to dyrektywa UE…
Dowiedz się więcej
Zapoznaj się z powiązanymi artykułami w naszej bazie wiedzy:
- Programy bug bounty: Jak wykorzystać globalną społeczność hakerów do wzmocnienia swojego bezpieczeństwa?
- Czego oczekiwać od raportu z testów penetracyjnych: Struktura, jakość i deliverables
- Jak stosujemy OWASP, PTES, NIST w praktyce
- NIS2 a kompetencje w cyberbezpieczeństwie: Jakie role i umiejętności są kluczowe?
- Przegląd konfiguracji bezpieczeństwa: Niedoceniany fundament cyberodporności
Sprawdź nasze usługi
Potrzebujesz wsparcia w zakresie cyberbezpieczeństwa? Sprawdź:
- Testy penetracyjne - identyfikacja podatności w infrastrukturze
- Red Team - zaawansowane symulacje ataków
Tematy powiązane
Zobacz również:
