Skan to za mało. Jakie testy penetracyjne powinien zlecić bank spółdzielczy, żeby nie usłyszeć tego na audycie?

Bank posiada firewall, EDR, SOC, regularne skany podatności i procedurę testowania operacyjnej odporności cyfrowej. Czy może więc uznać, że temat testów penetracyjnych jest zamknięty?

Nie. Skan podatności pokazuje potencjalne słabości, natomiast pentest sprawdza, czy można je rzeczywiście wykorzystać, połączyć w ścieżkę ataku i dotrzeć do Active Directory, systemu wspierającego KLIF, backupu albo konsoli administracyjnej.

Właśnie takiej odpowiedzi potrzebuje Bank, Zarząd i audytor.

Problem zaczyna się wtedy, gdy Bank wysyła do wykonawcy jedno zdanie: „Prosimy o ofertę na testy penetracyjne”. Pod tą samą nazwą mogą kryć się zupełnie różne usługi – od skanu kilku adresów IP po kontrolowaną próbę przejęcia środowiska wewnętrznego. Cena może wyglądać atrakcyjnie, ale raport nie musi potwierdzać, że sprawdzono obszary najważniejsze z perspektywy DORA, KNF oraz audytu zrzeszeniowego.

Jakie testy powinien rozważyć bank spółdzielczy?

W typowym środowisku bankowym należy przeanalizować co najmniej pięć obszarów:

1. zewnętrzną powierzchnię ataku – publiczne adresy IP, usługi, domeny, VPN, portale i panele;
2. sieć wewnętrzną i Active Directory – możliwość eskalacji uprawnień i przejścia do zasobów krytycznych;
3. aplikacje WWW, bankowość elektroniczną i API – uwierzytelnianie, autoryzację, sesje, tokeny i logikę biznesową;
4. dostęp uprzywilejowany i dostęp dostawców – VPN, MFA, PAM, jump server oraz rozliczalność sesji;
5. backup i wirtualizację – odporność kopii na przejęcie środowiska i atak ransomware.

Nie oznacza to, że każdy Bank powinien od razu zamówić wszystkie testy.  Zakres i kolejność muszą wynikać z BIA, klasyfikacji KLIF, analizy ryzyka ICT, architektury, modelu on-premises/CPD/chmura, istotnych zmian oraz wyników wcześniejszych badań.

Nie wiesz, które z tych testów dotyczą środowiska Twojego Banku? Servus Comp Kraków może przeprowadzić krótką kwalifikację zakresu na podstawie BIA, systemów wspierających KLIF i podstawowych danych o architekturze ICT. Dzięki temu Bank nie zamawia badania zbyt wąskiego ani nie płaci za elementy, które nie dotyczą jego środowiska.

Co wynika z DORA i oczekiwań KNF?

DORA wymaga programu testowania operacyjnej odporności cyfrowej opartego na ryzyku. Systemy i aplikacje ICT wspierające funkcje krytyczne lub istotne powinny być objęte odpowiednimi testami co najmniej raz w roku. Nie oznacza to automatycznie pełnego pentestu każdego komponentu w każdym roku. Bank musi jednak wykazać:

• co zostało sprawdzone;
• dlaczego wybrany test był adekwatny;
• jakie podatności wykryto;
• kto odpowiada za ich usunięcie;
• czy wykonano retest.

Podstawę stanowią art. 24–25 rozporządzenia DORA.

KNF w metodyce BION uwzględnia testowanie operacyjnej odporności cyfrowej, w tym cykliczne testy penetracyjne systemów, protokołów i narzędzi ICT. Dla nadzoru nie wystarcza procedura. Liczy się wykonanie testów, pokrycie systemów wspierających KLIF, obsługa wyników, harmonogram napraw oraz dowód skutecznego zamknięcia zaleceń.

SOZ BPS i ZOS SGB – wymagania zrzeszeniowe też mają znaczenie

W Bankach BPS należy dodatkowo uwzględnić wymagania SOZ BPS. Zgodnie z przekazaną wytyczną systemy ICT wspierające KLIF i dostępne online powinny być testowane raz w roku. SOZ BPS wskazuje również obszary, które należy rozważyć: zasoby publiczne, sieć wewnętrzną, aplikacje WWW i API, aplikacje mobilne, systemy operacyjne, chmurę, urządzenia końcowe, infrastrukturę IT oraz socjotechnikę.

Banki należące do SGB powinny stosować aktualne ZOS SGB i ustalenia dotyczące właściwych usług bezpieczeństwa SGB. Nie należy automatycznie przenosić częstotliwości właściwych dla SOZ BPS na Bank SGB. W obu zrzeszeniach wspólna pozostaje najważniejsza zasada: zakres testu musi odpowiadać realnemu ryzyku, funkcjom KLIF, architekturze oraz granicom odpowiedzialności Banku i dostawców.

Dlaczego Rapid7, Nessus albo OpenVAS nie zamyka tematu?

Skaner wyszukuje znane podatności, brakujące aktualizacje i typowe błędy konfiguracji. Jest niezbędnym elementem zarządzania podatnościami, ale działa głównie automatycznie.

Pentester sprawdza, czy wykrytą słabość można bezpiecznie wykorzystać i czy kilka pozornie drobnych problemów tworzy realną ścieżkę ataku. Z tego powodu raport ze skanowania nie powinien być przedstawiany jako pełny pentest.

Również SOC nie zastępuje testu penetracyjnego. SOC obserwuje i reaguje, a pentest weryfikuje możliwość przełamania zabezpieczeń. Dobrze zaplanowane badanie może dodatkowo pokazać, czy działania testera zostały wykryte, prawidłowo sklasyfikowane i obsłużone.

Test zewnętrzny czy wewnętrzny? Bank często potrzebuje obu

Test zewnętrzny

Powinien odpowiedzieć na pytanie: co osoba bez dostępu do Banku może zobaczyć i zaatakować z Internetu?

Obejmuje przede wszystkim publiczne adresy IP, dostępne usługi, VPN, domeny, subdomeny, portale, zdalne panele, konfigurację TLS i elementy chronione przez WAF lub reverse proxy.

Samo sprawdzenie strony wizytówkowej nie jest testem całej zewnętrznej powierzchni ataku. Podobnie sam skan portów nie zastępuje weryfikacji mechanizmów logowania, MFA, VPN czy aplikacji.

Test wewnętrzny i Active Directory

Powinien odpowiedzieć na inne pytanie: co może zrobić atakujący po przejęciu zwykłej stacji, konta pracownika albo po uzyskaniu dostępu przez VPN?

W tym przypadku znaczenie mają Active Directory, konta uprzywilejowane i serwisowe, GPO, segmentacja, eskalacja uprawnień oraz możliwość przemieszczania się pomiędzy strefami. Celem nie jest wykonanie kolejnego skanu, ale ustalenie, czy można przejść od zwykłego punktu wejścia do systemu krytycznego, backupu lub konsoli zarządzającej.

Aplikacje, API i bankowość elektroniczna

Test aplikacyjny powinien obejmować ręczną ocenę mechanizmów bezpieczeństwa i logiki biznesowej. W szczególności należy zweryfikować uwierzytelnianie, autoryzację, zarządzanie sesją, tokeny, dostęp do danych, nieużywane endpointy i możliwość wykonywania operacji poza uprawnieniami użytkownika.

Automatyczny skan OWASP nie wystarcza. Właściwym punktem odniesienia są m.in. OWASP Top 10, OWASP API Security Top 10 i OWASP Web Security Testing Guide, ale o wartości testu decyduje przede wszystkim scenariusz dopasowany do konkretnej aplikacji i jej roli w Banku.

Core lokalny i core w CPD wymagają innego podejścia

Jeżeli system core działa lokalnie, Bank powinien przeanalizować komponenty pozostające w jego środowisku: serwery, bazę danych, segmentację, konta techniczne, dostęp producenta i połączenia z innymi systemami. Test produkcji musi być prowadzony bezpiecznie – bez modyfikacji zapisów księgowych, testów DoS i działań grożących zakłóceniem usług.

Jeżeli core jest utrzymywany w CPD albo w modelu SaaS, Bank nie może samodzielnie testować infrastruktury dostawcy bez odpowiedniego prawa i zgody. Nadal powinien jednak sprawdzić własne stacje, konta, VPN, MFA, integracje i logowanie oraz ocenić wiarygodność dowodów przedstawionych przez dostawcę.

Samo oświadczenie „dostawca wykonuje pentesty” nie daje jeszcze odpowiedzi, czy test obejmował usługę wykorzystywaną przez Bank, jakie wykryto luki i czy wykonano retest.

Granica odpowiedzialności Bank–dostawca jest jednym z najczęstszych problemów przy ustalaniu zakresu. Przed wysłaniem zapytania ofertowego warto zweryfikować, które elementy Bank może i powinien testować samodzielnie, a dla których powinien uzyskać raport lub inne dowody od CPD, dostawcy core albo operatora chmury.

Backup, PAM i dostęp dostawców – obszary, których nie warto pomijać

Bank może posiadać poprawne kopie zapasowe, a mimo to stracić możliwość odtworzenia po ransomware. Test powinien sprawdzić izolację backupu, niezależność poświadczeń, ochronę konsoli oraz możliwość dotarcia do repozytorium po przejęciu konta lub stacji. Nie wykonuje się przy tym rzeczywistego usunięcia kopii – wystarcza uzgodniony, bezpieczny dowód możliwości wykonania takiej operacji.

Podobnie wdrożenie VPN, PAM lub jump servera nie kończy tematu dostępu uprzywilejowanego. Trzeba zweryfikować MFA, imienne konta, ograniczenia sieciowe, dostęp czasowy, rozliczalność sesji oraz możliwość przerwania połączenia. Test ma pokazać, czy dostawca może dotrzeć wyłącznie tam, gdzie powinien.

Czy każdy Bank musi wykonać pełny zakres jednocześnie?

Nie. Testy można budować etapami, pod warunkiem że kolejność wynika z ryzyka, a nie wyłącznie z ceny.

W typowym Banku pierwszeństwo powinny otrzymać:

1. systemy wspierające KLIF dostępne online;
2. publiczna powierzchnia ataku i VPN;
3. Active Directory, segmentacja i dostęp uprzywilejowany;
4. backup i wirtualizacja;
5. aplikacje, API oraz pozostałe obszary wynikające z BIA i analizy ryzyka.

To model orientacyjny. Istotna zmiana, incydent, migracja albo wyniki poprzednich testów mogą uzasadniać inną kolejność.

Co Bank powinien przekazać do wyceny?

Zapytanie powinno określać przynajmniej:

• cel i oczekiwany scenariusz testu;
• rodzaj środowiska i systemy objęte badaniem;
• orientacyjną liczbę adresów, urządzeń, segmentów lub aplikacji;
• model utrzymania oraz udział dostawców;
• wymagania dotyczące bezpieczeństwa, raportu i retestu.

Pełna specyfikacja powinna zostać dopasowana do architektury konkretnego Banku. Dopiero wtedy oferty różnych wykonawców stają się rzeczywiście porównywalne.

Chcesz otrzymać Kartę doboru testów penetracyjnych dla Banku Spółdzielczego? Napisz do Servus Comp Kraków. Na podstawie kilku informacji wskażemy obszary wymagające testu i dane potrzebne do przygotowania rzetelnej wyceny.

Jak rozpoznać dobry raport?

Dobry raport nie kończy się listą błędów. Powinien zawierać jednoznaczny zakres, potwierdzone ścieżki ataku, ocenę wpływu na Bank, priorytety, zalecenia oraz podsumowanie dla Zarządu.

Po teście potrzebny jest plan naprawczy: właściciel działania, termin, status, zabezpieczenie kompensacyjne i dowód realizacji. Podatności krytyczne i wysokie powinny zostać objęte retestem.

Bez tego nawet wartościowy raport może pozostać jedynie plikiem PDF w katalogu – bez realnego wpływu na bezpieczeństwo i bez mocnego dowodu dla audytora.

Najczęstsze błędy przy zlecaniu pentestów

• uznanie skanu podatności za pentest;
• ograniczenie testu do strony WWW;
• brak powiązania zakresu z BIA i KLIF;
• pominięcie Active Directory, backupu lub dostępu dostawców;
• przyjęcie ogólnego oświadczenia dostawcy bez oceny zakresu;
• brak zasad bezpiecznej realizacji testu;
• brak planu naprawczego i retestu;
• brak informacji zarządczej o wynikach i zaległościach.

Nie zamawiaj „ogólnego pentestu”

Test penetracyjny ma dać Bankowi odpowiedź, czy można wejść do jego środowiska, przejąć konto, ominąć segmentację, dotrzeć do systemu krytycznego, zagrozić backupowi oraz pozostać niezauważonym przez mechanizmy monitorowania.

Jeżeli planowany zakres nie odpowiada na te pytania, warto poprawić go przed podpisaniem zamówienia – nie dopiero po otrzymaniu zalecenia audytowego.

Servus Comp Kraków pomoże dobrać zakres do Banku

Servus Comp Kraków wspiera Banki Spółdzielcze w:

• kwalifikacji systemów i obszarów wymagających testowania;
• powiązaniu zakresu z BIA, KLIF i analizą ryzyka ICT;
• ustaleniu kolejności badań adekwatnej do ryzyka i budżetu;
• przygotowaniu porównywalnego zapytania ofertowego;
• określeniu bezpiecznych zasad realizacji;
• ocenie raportu, planu naprawczego i retestu;
• przygotowaniu informacji dla Zarządu i dowodów audytowych.

Zadzwoń lub napisz do Servus Comp Kraków. Krótka rozmowa pozwoli ustalić, czy Bank potrzebuje testu zewnętrznego, wewnętrznego, aplikacyjnego, testu AD, backupu lub dostępu dostawców – zanim zakres zostanie wyceniony i zamówiony.

Więcej informacji: premiumbank.zadbajobezpieczenstwo.pl

FAQ – testy penetracyjne w banku spółdzielczym

Czy skan podatności może zastąpić pentest?

Nie. Skan identyfikuje prawdopodobne słabości, a pentest aktywnie sprawdza możliwość ich wykorzystania, połączenia w ścieżkę ataku i rzeczywisty wpływ na Bank.

Czy systemy wspierające KLIF trzeba testować co roku?

DORA wymaga, aby systemy i aplikacje ICT wspierające funkcje krytyczne lub istotne były objęte odpowiednimi testami co najmniej raz w roku. Rodzaj testu powinien wynikać z ryzyka, architektury, zmian i wcześniejszych wyników. W Bankach SOZ BPS systemy wspierające KLIF i dostępne online powinny być testowane raz w roku.

Czy SOC BPS albo SOC SGB zastępuje test penetracyjny?

Nie. SOC monitoruje i reaguje, natomiast pentest sprawdza możliwość przełamania zabezpieczeń. Test może dodatkowo zweryfikować, czy działania testera zostały wykryte i prawidłowo obsłużone.

Czy Bank może testować core utrzymywany w CPD?

Nie bez prawa i zgody dostawcy. Bank powinien przetestować własne elementy dostępu i integracji oraz uzyskać wiarygodne dowody testów przeprowadzonych po stronie dostawcy.

Od czego powinien zacząć Bank Spółdzielczy?

Od wskazania systemów wspierających KLIF i zasobów dostępnych online. Następnie należy ocenić zewnętrzną powierzchnię ataku, VPN, Active Directory, segmentację, dostęp uprzywilejowany oraz bezpieczeństwo backupu.

Zapraszamy Państwa do zapoznania się z innymi wpisami na naszm blogu:

1. Strategia ICT to za mało. KNF pyta o operacyjną odporność cyfrową Banku:

   https://premiumbank.zadbajobezpieczenstwo.pl/strategia-ict-to-za-malo-knf-pyta-o-operacyjna-odpornosc-cyfrowa-banku/

2. Backup jest? To za mało. KNF zapyta, czy Bank potrafi się odtworzyć:
   https://premiumbank.zadbajobezpieczenstwo.pl/backup-jest-to-za-malo-knf-zapyta-czy-bank-potrafi-sie-odtworzyc-strategia-ciaglosci-dzialania-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/

3. Skan to za mało. KNF zapyta, czy Bank naprawdę testuje odporność ICT:
   https://premiumbank.zadbajobezpieczenstwo.pl/skan-podatnosci-to-nie-test-odpornosci-knf-zapyta-czy-bank-naprawde-testuje-ict/

4. Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT:
   https://premiumbank.zadbajobezpieczenstwo.pl/jeden-dostawca-wiele-systemow-jedno-duze-ryzyko-knf-pyta-o-koncentracje-ict/

5. Audyt ZDU — czy wiesz, kogo naprawdę powinien kontrolować Bank?:
   https://premiumbank.zadbajobezpieczenstwo.pl/audyt-zdu-w-banku-spoldzielczym-jak-kontrolowac-dostawcow-zewnetrznych-zgodnie-z-dora/

6. Zarząd musi wiedzieć. KNF zapyta, kto naprawdę nadzoruje ryzyko ICT w Banku:
   https://premiumbank.zadbajobezpieczenstwo.pl/raport-ict-do-zarzadu-knf-pyta-kto-nadzoruje-ryzyko-ict-w-banku/

7. Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś:
   https://premiumbank.zadbajobezpieczenstwo.pl/znalazles-podatnosc-knf-zapyta-kiedy-ja-usunales-zarzadzanie-podatnosciami-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/

8. Masz procedury DORA? KNF zapyta: kiedy ostatnio naprawdę je przeczytałeś?:
   https://premiumbank.zadbajobezpieczenstwo.pl/coroczny-przeglad-dokumentacji-ict-dora-w-banku-spoldzielczym-po-ocenie-nadzorczej-knf-ryzyka-ict-za-2025-r/

9. DORA nie zna wymówki: pracownik nie miał czasu na szkolenie:
   https://premiumbank.zadbajobezpieczenstwo.pl/szkolenia-ict-dora-po-ocenie-knf-ryzyka-ict-za-2025-r-czy-bank-przeszkolil-wszystkich-czy-tylko-ma-plan-szkolenia/

10. Dokument jest? KNF zapyta o dowód, że działa:
    https://premiumbank.zadbajobezpieczenstwo.pl/dokument-jest-knf-zapyta-o-dowod-ze-dziala/

Zadzwoń lub napisz do Servus Comp, aby omówić temat.

• Strona główna: https://premiumbank.zadbajobezpieczenstwo.pl

Servus Comp Data Security, Świętokrzyska 12/403, 30-015 Kraków

tel. +48 608 407 668, +48 12 631 91 22 • biuro@servus-comp.pl

PODEJMIEMY DLA PAŃSTWA KAŻDE WYZWANIE!

JESTEŚ ZAINTERESOWANY? ZADZWOŃ, NAPISZ DO NAS

#TestyPenetracyjne #BankSpółdzielczy #Cyberbezpieczeństwo #DORA #KNF #SOZBPS #SOZSGB #BezpieczeństwoICT #OdpornośćCyfrowa #SkanowaniePodatności #AudytIT #Pentest #ZarządzanieRyzykiemICT #ServusComp