Testy penetracyjne a SOC 2: wybierz test, który mówi coś o bezpieczeństwie

Test penetracyjny dostarcza dowodów na istnienie możliwych do wykorzystania słabości w określonym systemie. Jego wartość zależy od tego, co badają testerzy, jak prowadzą badanie i co zespół inżynierski robi z ustaleniami. Raport, który pomija istotne granice zaufania produktu, może pozwolić dotrzymać wewnętrznego terminu, a jednocześnie niewiele powiedzieć o bezpieczeństwie.

Dla CTO użyteczne pytanie nie brzmi po prostu, czy test został przeprowadzony. Brzmi ono: czy zlecenie weryfikuje zabezpieczenia chroniące dane klientów i czy daje ustalenia, które zespół może odtworzyć, naprawić i zweryfikować.

Czego SOC 2 wymaga – a czego nie

SOC 2 to raport atestacyjny, a nie certyfikacja. Jego kryteria opierają się na zasadach; nie narzucają każdej organizacji jednego uniwersalnego wymogu przeprowadzania testów penetracyjnych ani corocznej częstotliwości. O tym, jakie testy są właściwe, decydują ryzyko, opisane przez Ciebie zabezpieczenia, oczekiwania audytora i umowy z klientami.

Przed zleceniem testu omów z audytorem cel i oczekiwane dowody. Jeśli Twoje udokumentowane zabezpieczenie zakłada określoną częstotliwość lub zakres testów, zaplanuj wykazanie realizacji tego zobowiązania.

Zaufanie klientów to odrębna kwestia. Kupujący może wymagać niezależnego testu aplikacji, nawet jeśli Twoje podejście audytowe go nie przewiduje. Ustal te oczekiwania wcześnie, ale nie pozwól, by lista kontrolna z procesu zakupowego zastąpiła techniczne określenie zakresu. Ani raport SOC 2, ani test penetracyjny nie dowodzą, że system nie ma podatności.

Określ zakres na podstawie powierzchni ataku, a nie tylko strony internetowej

Zacznij od architektury, przepływów danych wrażliwych i granic zaufania. Wytyczne OWASP dotyczące modelowania zagrożeń stanowią użyteczną podstawę do ustalenia, co może pójść nie tak i na czym powinny się skupić testy.

W przypadku wielodostępnego produktu SaaS testowanie wyłącznie publicznej strony głównej pozostawia istotne granice aplikacji niezbadane. Przekaż wykonawcy inwentarz obejmujący API, przetwarzanie w tle, narzędzia administracyjne i odpowiednią infrastrukturę – a nie tylko listę domen.

Jednoznacznie określ wyłączenia i ograniczenia. Nieprzetestowany klient mobilny, niedostępna rola lub niedostępne środowisko muszą pozostać widoczne w raporcie końcowym. Zakres powinien też odróżniać systemy, których jesteś właścicielem, od usług podmiotów trzecich, na atakowanie których nie możesz udzielić testerom zgody.

Wybierz metodę, która odpowiada na Twoje pytania

Automatyczne skanowanie identyfikuje potencjalne słabości i wspiera regularną higienę bezpieczeństwa. Test penetracyjny dodaje do tego fachowe badanie możliwości wykorzystania słabości i istotnych ścieżek ataku w autoryzowanym zakresie. Narzędzia są przydatne; eksport ze skanera przemianowany na test penetracyjny nie jest jednak równoważny takiemu badaniu.

Testy metodą black-box zaczynają się od ograniczonej wiedzy o systemie. Testy gray-box zapewniają wybrane informacje lub dostęp, często w tym konta. Testy white-box zapewniają głębszy wgląd, potencjalnie obejmujący kod źródłowy i architekturę. Podejścia te odpowiadają na różne pytania, a nie tworzą prostego rankingu jakości.

Przy testowaniu autoryzacji w aplikacji konta w kilku rolach i tenantach mogą zwiększyć skuteczność badania. Sam test infrastruktury zewnętrznej nie pozwala ustalić, czy uwierzytelnieni użytkownicy mogą przekraczać granice między tenantami.

Oceń wykonawcę i rezultaty

Zapytaj, kto będzie wykonywał pracę i czy testował porównywalne architektury. Odpowiednie kwalifikacje wspierają należytą staranność, ale same certyfikaty nie dowodzą kompetencji w odniesieniu do konkretnej aplikacji. Poproś o zanonimizowany przykładowy raport i omów, jak zespół bada logikę biznesową, a nie tylko znane podatności oprogramowania.

Przed podpisaniem umowy wyjaśnij:

• Które systemy, role i ścieżki ataku są objęte testem i jak rozłożony jest nakład pracy.
• Jakie ręczne badanie uzupełnia narzędzia automatyczne.
• Jak pilne ustalenia są przekazywane przed raportem końcowym.
• Czy ustalenia zawierają odtwarzalne dowody, komponenty, których dotyczą, wpływ i wskazówki dotyczące naprawy.
• Czy ponowny test jest wliczony, w jakim oknie czasowym i co się dzieje, jeśli poprawki pojawią się później.
• Jak chronione i ostatecznie usuwane są raporty, poświadczenia i przechwycone dane.

Porównuj oferty pod względem zakresu i rezultatów, a nie tylko ceny. Niższa wycena może oznaczać węższe zlecenie, a nie równoważną pracę wykonaną wydajniej.

Ustal zasady bezpiecznego przeprowadzenia testu

Przed rozpoczęciem testów udokumentuj zgodę i zasady prowadzenia testu (rules of engagement). Wskaż zatwierdzone hosty, konta, środowiska, okna testowe, kontakty awaryjne i warunki przerwania testu. Uzgodnij, czy wyłączone są testy odmowy usługi (DoS), socjotechnika, utrzymywanie dostępu lub wydobywanie danych.

Testy w środowisku produkcyjnym mogą ujawnić rzeczywiste problemy z konfiguracją, ale tworzą też ryzyko operacyjne. Reprezentatywne środowisko stagingowe może być bezpieczniejsze, pod warunkiem że różnice względem produkcji zostaną zapisane. Tam, gdzie to wykonalne, używaj syntetycznych danych tenantów i uzgodnij, jakie dowody wystarczą do wykazania wpływu bez zbierania niepotrzebnych informacji o klientach.

Upewnij się, że zespoły monitorujące wiedzą, jak odróżnić autoryzowaną aktywność od niezwiązanego z nią incydentu. Testy nie powinny stać się pretekstem do wyłączania zabezpieczeń ochronnych bez udokumentowania konsekwencji.

Przykład: ustalenie dotyczące izolacji tenantów

Rozważmy przykładowe zlecenie dla produktu SaaS. Przyjmijmy, że produkt ma dwa testowe tenanty, zwykłych użytkowników, administratorów tenantów i rolę wsparcia. Test obejmuje uwierzytelnione API i workflow eksportu; infrastruktura tożsamości podmiotu trzeciego jest wyłączona.

Tester odkrywa, że endpoint eksportu weryfikuje zalogowanie, ale nie egzekwuje konsekwentnie przynależności do tenanta. Na danych syntetycznych wykazuje, że użytkownik z tenanta A może zażądać eksportu należącego do tenanta B.

Ustalenie powinno wskazywać endpoint, wymagane uprawnienia, workflow, którego dotyczy, odtwarzalne dowody i wpływ na biznes. Zespół inżynierski ustala, że źródłem problemu jest proces działający w tle, który ufa identyfikatorowi tenanta przekazanemu w żądaniu.

Poprawka egzekwuje przynależność przed zaplanowaniem eksportu i ponownie przy jego pobieraniu. Testy regresyjne obejmują żądania między tenantami i odpowiednie role. Ponowny test potwierdza, że pierwotna ścieżka jest zablokowana, i sprawdza powiązane ścieżki eksportu. Zespół zachowuje pierwotne ustalenie, dowody wdrożenia poprawki i wynik ponownego testu; nie oznacza po prostu ticketu jako „gotowe”.

Przekształć ustalenia w pracę inżynierską z przypisaną odpowiedzialnością

Ustalaj priorytety ustaleń na podstawie wagi technicznej i ekspozycji biznesowej. Weź pod uwagę wymagane uprawnienia, dostępność z internetu, dane, których dotyczy problem, niezawodność exploita i zabezpieczenia kompensujące. Problem o nominalnie umiarkowanej wadze może wymagać pilnej reakcji, jeśli narusza krytyczną granicę między klientami.

Każdemu ustaleniu przypisz właściciela, termin docelowy i metodę weryfikacji. W stosownych przypadkach wdróż tymczasowy środek łagodzący na czas przygotowania trwałej poprawki. Wszelkie zaakceptowane ryzyko rezydualne powinien zatwierdzić wyznaczony właściciel ryzyka, z uzasadnieniem i datą przeglądu; milczenie zespołu inżynierskiego nie oznacza akceptacji.

Zapisz przetestowaną wersję produktu i środowisko. Wynik sprzed dużej przebudowy mechanizmów autoryzacji nie może opisywać nowej implementacji. W ramach praktycznej rekomendacji oceniaj ponownie potrzeby w zakresie testów po istotnych zmianach architektonicznych, poważnych incydentach lub pojawieniu się nowej ekspozycji, niezależnie od ustalonej częstotliwości.

Utrzymuj dowody użyteczne dla audytorów i klientów

Zachowaj uzgodniony zakres, zasady prowadzenia testu, raport końcowy, zapisy działań naprawczych, dowody z ponownego testu i decyzje dotyczące ryzyka. Utrzymuj ograniczony dostęp do pełnego raportu, ponieważ może on zawierać wrażliwe szczegóły dotyczące wykorzystania podatności.

Przygotuj podsumowanie dla klientów opisujące daty testów, zakres, metodykę, ograniczenia i status działań naprawczych, bez niepotrzebnego ujawniania instrukcji ataku. W przypadku dalszych pytań zapoznaj się z naszym przewodnikiem po przeglądzie zapewnienia bezpieczeństwa.

W Secani połącz dowody z testów z odpowiednimi systemami, wymaganiami, zabezpieczeniami, właścicielami i decyzjami z przeglądów. Śledź luki w dowodach jako zadania i zachowuj zatwierdzanie wniosków przez ludzi. Dzięki temu związek między tym, co zostało przetestowane, a tym, co się zmieniło, pozostaje dostępny do późniejszego przeglądu.

Przed zapytaniem o oferty przygotuj jednostronicowy opis zakresu obejmujący granice zaufania, konta testowe, wyłączenia, rezultaty i oczekiwania dotyczące ponownych testów. Dokument ten daje wykonawcy, audytorowi i zespołowi inżynierskiemu wspólną podstawę dla testu, który faktycznie mówi coś o bezpieczeństwie.