VAPT: ocena podatności i testy penetracyjne w praktyce

W Indiach „VAPT” to codzienne określenie testów bezpieczeństwa. Klienci, partnerzy, audytorzy i regulowani kontrahenci często proszą o „raport VAPT”, zanim podpiszą umowę, podłączą integrację lub zatwierdzą wdrożenie. Termin ten łączy dwa działania: ocenę podatności (vulnerability assessment), która szeroko wyszukuje znane słabości, oraz testy penetracyjne, które dogłębnie sprawdzają, czy te słabości można wykorzystać. Ten przewodnik wyjaśnia, co zwykle obejmuje projekt VAPT, jak rozsądnie określić jego zakres i co sprawdzić przed udostępnieniem wyniku.

Co to jest

Część dotycząca oceny podatności (VA) ma szeroki charakter. Łączy automatyczne skanowanie z przeglądem, aby zidentyfikować brakujące poprawki, nieaktualne komponenty, wystawione usługi, słabą konfigurację i typowe problemy aplikacji internetowych w uzgodnionych zasobach. Część dotycząca testów penetracyjnych (PT) jest dogłębna. Tester pracuje ręcznie na wybranych celach, zwykle aplikacjach internetowych, API i aplikacjach mobilnych, weryfikując znaleziska i testując uwierzytelnianie, obsługę sesji, kontrolę dostępu między rolami, ekspozycję danych oraz logikę biznesową. Razem VA zapewnia pokrycie, a PT pewność co do tego, co rzeczywiście da się wykorzystać. Projekt VAPT powinien zakończyć się pisemnym raportem, który dokumentuje zakres, metodę, znaleziska ocenione według istotności wraz z dowodami, zalecenia naprawcze oraz — jeśli uzgodniono — wynik ponownego testu po naprawach. Zapytania czasem odwołują się do ram takich jak OWASP Top 10 lub wytyczne OWASP Mobile Application Security; są to przydatne punkty odniesienia dla tego, co sprawdzają testerzy.

Dla kogo

O VAPT najczęściej proszą lub zlecają je:

Zespoły SaaS, fintech i e-commerce, których klienci korporacyjni w procesie zakupowym proszą o aktualny raport VAPT
Firmy łączące się z partnerem, bankiem lub dostawcą płatności, który przed integracją wymaga dowodu przeprowadzenia testów bezpieczeństwa
Zespoły produktowe przygotowujące publiczne uruchomienie aplikacji internetowej lub mobilnej
Organizacje, które zmieniły hosting, uwierzytelnianie lub przepływy płatności i chcą niezależnej kontroli

Co pomaga wyjaśnić

Dobrze określony zakres VAPT pomaga wyjaśnić:

Które aplikacje, API i środowiska wnioskodawca faktycznie oczekuje zobaczyć przetestowane
Czy wymaganie wskazuje konkretny rodzaj audytora lub akredytację, którą należy potwierdzić przed wyborem dostawcy
Które znaleziska są zweryfikowanym ryzykiem, a które obserwacjami skanera
Jakie naprawy muszą nastąpić, zanim raport będzie można udostępnić z pełnym przekonaniem

Co jest zawarte

Uzyskać od wnioskodawcy dokładne wymaganie na piśmie: zasoby, głębokość, format raportu i ewentualne kryteria dotyczące dostawcy
Sporządzić listę celów: domeny, adresy URL aplikacji, ścieżki bazowe API, wersje aplikacji mobilnych i środowiska (testowe lub produkcyjne)
Przygotować konta testowe dla każdej roli użytkownika, aby testy kontroli dostępu miały sens
Potwierdzić pisemną autoryzację, okno testowe, osoby kontaktowe i warunki przerwania
Poinformować dostawców hostingu, CDN lub WAF, jeśli wymagają tego ich warunki
Uzgodnić oceny istotności, format raportu i sposób udostępniania dowodów
Zarezerwować czas na naprawę znalezisk i poprosić o ponowny test uzgodnionych problemów

Co nie jest uwzględnione

Stwierdzenia, że VAPT czyni aplikację bezpieczną lub zgodną z przepisami
Twierdzenia, że dany dostawca spełnia konkretny wymóg akredytacji lub wpisu na listę (empanelment), bez sprawdzenia go względem tego wymogu
Testowania systemów stron trzecich bez zgody właściciela
Porad prawnych ani regulacyjnych dotyczących tego, czego wymaga konkretny przepis

Kiedy to wybrać

VAPT warto zlecić, gdy prosi o to wskazany kontrahent, przed istotnym wdrożeniem albo po dużych zmianach w sposobie logowania użytkowników, płatności lub dostępu do danych. Jeśli prośba wynika z relacji regulowanej, należy uważnie przeczytać wymaganie: niektóre wskazują akredytowanego lub wpisanego na listę audytora (w Indiach niektórzy regulatorzy i kontrahenci odwołują się do audytorów z listy CERT-In), określony zakres lub stały cykl testów. Te szczegóły należy najpierw potwierdzić z wnioskodawcą, ponieważ raport niezgodny z wymaganiem może wymagać powtórzenia. Ten artykuł ma charakter informacji ogólnej i nie stanowi porady prawnej ani regulacyjnej.

Nasze podejście

Listę kontrolną wnioskodawcy warto traktować jako punkt wyjścia, a następnie dodać systemy niosące największe ryzyko dla Państwa firmy, nawet jeśli nikt o nie nie pytał. W miarę możliwości należy testować w środowisku testowym odzwierciedlającym produkcję i z wyprzedzeniem uzgodnić, jak będą prowadzone testy produkcji, jeśli są wymagane. Nasza usługa Application Security Review obejmuje testy aplikacji internetowych i API z pisemnymi znaleziskami ocenionymi według istotności oraz zaleceniami naprawczymi; szersze zakresy obejmujące wiele środowisk lub sieci realizujemy w ramach usługi Penetration Testing. W obu przypadkach zakres, autoryzacja i raportowanie są potwierdzane na piśmie przed rozpoczęciem prac. Po przekazaniu wyników należy najpierw naprawić znaleziska o wysokiej i krytycznej istotności, udokumentować decyzje dotyczące zaakceptowanego ryzyka i poprosić o ponowny test. Następnie warto udostępnić podsumowanie dla kierownictwa lub pismo o statusie napraw zamiast pełnego raportu technicznego, chyba że wnioskodawca wyraźnie potrzebuje takiego poziomu szczegółowości i ma bezpieczny sposób jego odebrania.

Application Security Review

Zobacz stronę usługi Application Security Review