®Bezpieczeństwo ofensywne / Pentesting oprogramowania i SaaS
Szybkie wydania wymagają sprawdzenia bezpieczeństwa, które rozumie Państwa aplikację. OTOKO® analizuje produkty SaaS, API, aplikacje działające na PaaS oraz rozwijane przez lata oprogramowanie starszego typu. W centrum uwagi są realnie osiągalne skutki: dane innych dzierżawców, niedozwolone działania, nadużycie logiki biznesowej oraz granice między rolami użytkowników. Odtwarzalne ustalenia dają Państwa zespołowi programistycznemu podstawę do naprawy.
Szczegóły usług
Analiza, integracja i przejrzyste przekazanie
Państwa zlecenie dla OTOKO®
Pakiety prac wynikają z Państwa sytuacji wyjściowej. Państwa zespół zna uzgodniony zakres, wymagany udział z Państwa strony oraz wyniki, które mają być dostępne przy przekazaniu.
Wspólnie ustalamy istotne biznesowo procesy i role testowe. Następnie badamy, czy funkcja może być wykorzystana poza przewidzianymi dla niej granicami. Automatyczne sprawdzenia są uzupełniane ręczną analizą aplikacji.
Ocenione ustalenia z opisem skutków biznesowych i możliwym do zweryfikowania dowodem.
Przypisanie dzierżawców, dostęp do obiektów i funkcje uprzywilejowane są sprawdzane w zatwierdzonym zakresie. Odrębny zbiór testowy umożliwia ocenę skutków bez konieczności wykorzystywania danych innych klientów do przedstawienia dowodu.
Udokumentowane sprawdzenie uzgodnionych granic ról i dzierżawców.
W przypadku aplikacji PaaS analizujemy ustawienia i interfejsy, za które Państwo odpowiadają. W przypadku systemów starszego typu do planowania testów włączane są znane ograniczenia eksploatacyjne i zależności. Platformy innych podmiotów pozostają poza zakresem, dopóki nie zostanie udzielone zatwierdzenie.
Wyznaczony zakres testów z metodami dopasowanymi pod względem technicznym i eksploatacyjnym.
Ustalenia są priorytetyzowane i omawiane z Państwa zespołem programistycznym. Uzgodniony retest sprawdza, czy konkretna przyczyna została usunięta w nowej wersji. Wyniki są odnoszone do faktycznie sprawdzonego zakresu i momentu w czasie.
Raport techniczny, ocena dla kierownictwa oraz udokumentowane wyniki retestu.
Planowanie i wdrożenie
Produkt SaaS nie składa się jedynie z publicznie dostępnych punktów końcowych. Różne role, zaproszenia, eksporty, zadania w tle i funkcje administracyjne razem tworzą logikę biznesową. Przed testem wyjaśniamy więc, które procesy wymagają szczególnej ochrony i jakie granice powinna wymuszać aplikacja. Ta perspektywa uzupełnia klasyczne sprawdzenia techniczne. Funkcja może odpowiadać formalnie prawidłowo, a jednocześnie umożliwiać działanie, które nie jest przewidziane dla zalogowanej osoby lub jej dzierżawcy.
Na tej podstawie powstaje uzgodniony zakres testów. Elementy typu black box, grey box lub white box są dobierane w zależności od celu i dostępnych informacji. Jeśli udostępniony zostanie kod źródłowy lub dokumentacja architektury, obserwacje można trafniej zaklasyfikować. Sprawdzenie koncentruje się na autoryzowanej aplikacji i wykorzystuje uzgodnione konta i dane. Wynik narzędzia nie jest przyjmowany jako potwierdzona podatność bez wcześniejszej oceny; skutek i warunki wystąpienia muszą być zrozumiałe dla Państwa zespołu.
W przypadku SaaS i PaaS decydująca jest granica odpowiedzialności. Sprawdzenie Państwa aplikacji lub konfiguracji nie stanowi automatycznie zgody na atak na infrastrukturę operatora platformy. Wspólnie ustala się cele, dozwolone metody i niezbędne zatwierdzenia. API i integracje są sprawdzane pod kątem przewidzianego zakresu danych i uprawnień. Szczególną uwagę zwracamy na to, czy różne role i dzierżawcy pozostają niezawodnie rozdzieleni w rzeczywistych ścieżkach korzystania z aplikacji.
Oprogramowanie starszego typu często wymaga innego podejścia. Dokumentacja może być niekompletna, środowiska testowe tylko częściowo odwzorowują stan produkcyjny, a poszczególne komponenty są wrażliwe na obciążenie. Te warunki należy uwzględnić w planowaniu przed rozpoczęciem testów. Uzgadniamy okna testowe, dostępne osoby kontaktowe oraz kryteria przerwania. Tam, gdzie sprawdzenia nie da się przeprowadzić w odpowiedzialny sposób, to ograniczenie jest widoczne w wyniku. Dzięki temu jasne pozostaje, jakie wnioski pozwala wyciągnąć test i gdzie potrzebne byłyby dodatkowe badania.
Raport ma umożliwić podjęcie decyzji i pomóc zespołowi programistycznemu w naprawie. Potwierdzone ustalenie opisuje więc wersję, której dotyczy, wymagane warunki, uzgodniony dowód oraz możliwy skutek. Kierownictwo i zespoły techniczne potrzebują przy tym różnego poziomu szczegółowości. Priorytetyzacja uwzględnia kontekst aplikacji, zamiast tworzyć jedynie długą listę zgłoszeń o jednakowej wadze. Dowody są ograniczane do niezbędnego zakresu i przekazywane uprawnionym osobom kontaktowym uzgodnionymi ścieżkami.
Naprawa jest omawiana z Państwa zespołem; uzgodniony retest ocenia konkretną zmianę. Usunięcie jednego ustalenia nie oznacza jednak automatycznie, że cała aplikacja jest wolna od podatności. Nowe wydania i zmiany konfiguracji mogą zmienić sytuację wyjściową. Na życzenie można na tej podstawie wprowadzić regularne sprawdzanie istotnych zmian. Dla odpowiednich, jasno wyodrębnionych celów można również uzgodnić Result as a Service: wynagrodzenie zależy wtedy od wcześniej zdefiniowanego i wykazanego rezultatu.
Poglądowy scenariusz projektu
Dwóch odrębnych dzierżawców testowych odwzorowuje zwykłych użytkowników i administrację. Przed wydaniem badane są uzgodnione procesy biznesowe i granice uprawnień. Zespół otrzymuje priorytetyzowane dowody i sprawdza poprawki w reteście, bez potrzeby wykorzystywania danych innych klientów do demonstracji.
Przed rozpoczęciem
Tak. Aplikacje starszego typu są planowane z uwzględnieniem ich ograniczeń eksploatacyjnych, dostępnych środowisk testowych i zależności. Sprawdzenia niemożliwe do przeprowadzenia są wskazywane w raporcie jako ograniczenie.
Skanery wspierają pracę. Logika biznesowa, role i rzeczywisty kontekst aplikacji wymagają jednak merytorycznej oceny i ukierunkowanego ręcznego sprawdzenia.
Dla odpowiednich przedsięwzięć można uzgodnić pisemnie zdefiniowany dowód rezultatu wraz ze stałą kwotą. Bez tego dowodu uzgodnione wynagrodzenie za pentest uzależnione od sukcesu nie jest naliczane. Szczegóły znajdują się na stronie Result as a Service.
Nie. Wniosek odnosi się do uzgodnionego zakresu, sprawdzonej wersji i okna czasowego. Brak dowodu podatności nie stanowi ogólnej gwarancji bezpieczeństwa.
Powiązane usługi
Pentesting oprogramowania i SaaS z OTOKO®
Proszę podać dotknięte systemy oraz cel swojego zapytania. Podczas pierwszej konsultacji wspólnie określimy zakres, warunki wstępne i kolejne kroki.
Omówmy Pentesting oprogramowania i SaaS
