Test penetracyjny odpowiada na pytanie zapisane w jego zakresie i na nic więcej. Jeśli zakres brzmi "przetestujcie naszą aplikację webową", dostaniesz raport z tego, co testerzy uznali za najciekawsze w dostępnym czasie, a to niekoniecznie jest to, co chciałeś wiedzieć.
Rozwiązaniem jest przygotowanie. Zanim poprosisz o wyceny, ustal pytanie, zasady, dostępy, sposób obchodzenia się z danymi i definicję zakończenia prac.
Zacznij od pytania, nie od celu ataku
Lista adresów IP i URL-i to lista celów, a nie cel testu. Cel testu to decyzja, którą ma on wesprzeć. NIST SP 800-115 wskazuje, że techniczne testy bezpieczeństwa służą różnym celom, na przykład wykrywaniu podatności w systemie lub sieci oraz weryfikacji zgodności z polityką lub innymi wymaganiami. To różne zadania i wymagają różnych testów.
Sformułuj cel jako zdanie, które zrozumie sponsor bez wiedzy technicznej. Kilka przykładów:
- Czy zalogowany klient może odczytać faktury innego klienta w nowym portalu?
- Czy atakujący bez konta może dotrzeć do interfejsu administracyjnego systemu rezerwacji?
- Czy aplikacja spełnia wymagania dotyczące kontroli dostępu, które cytuje kwestionariusz bezpieczeństwa naszego klienta?
Każdy z tych celów oznacza inny zakres, inne konta i inny raport. Jeśli nie potrafisz napisać jednego zdania, nie jesteś jeszcze gotowy na zakup. Zanim poprosisz o wyceny, warto odbyć krótką rozmowę scopingową z testerami lub doradcą, na przykład z naszym zespołem doradczym.
Wybierz punkt odniesienia dla pojęcia "przetestowane"
"W pełni przetestowane" nic nie znaczy, dopóki nie nazwiesz tego, względem czego test przeprowadzono. W przypadku aplikacji webowych wspólny język dają dwa projekty OWASP.
OWASP Application Security Verification Standard (ASVS) jest podstawą do testowania technicznych mechanizmów bezpieczeństwa aplikacji webowych, a programistom daje listę wymagań dla bezpiecznego wytwarzania oprogramowania. Strona projektu wskazuje wersję 5.0.0 jako najnowszą stabilną. Każde wymaganie ma numerowany identyfikator, a projekt zaleca cytowanie go razem z wersją, na przykład v5.0.0-1.2.5. Wersja ma znaczenie, ponieważ identyfikatory mogą zmieniać się między wydaniami.
OWASP Web Security Testing Guide opisuje, jak testować. Jego strona wskazuje v4.2 jako bieżące wydanie, a wersja 5.0 jest nadal w opracowaniu. Wpisz do umowy wersję, której oczekujesz, w przeciwnym razie każda ze stron założy inną.
Następnie określ, które części ASVS wchodzą w zakres, podając rozdział i sekcję zgodnie z wybraną wersją. Identyfikator v5.0.0-1.2.5 wskazuje na przykład piąte wymaganie w sekcji "Injection Prevention" rozdziału "Encoding and Sanitization". Wybierz sekcje odpowiadające Twojemu celowi i poproś o findingi zmapowane na identyfikatory wymagań. Dzięki temu retest i dalsza praca programistów będą znacznie prostsze.
Rules of engagement
Rules of engagement to spisane granice tego, co testerzy mogą robić. To nasze rekomendacje, a nie coś, co narzucają wymienione źródła, ale każdy dokument zakresu powinien rozstrzygać poniższe kwestie:
| Element | Co ustalić |
|---|---|
| Środowisko | Produkcja, staging lub oba. Staging jest bezpieczniejszy, ale przydatny tylko wtedy, gdy jego konfiguracja odpowiada produkcji. |
| Okno testów | Daty i godziny oraz to, czy testy mogą odbywać się poza godzinami pracy. |
| Adresy źródłowe | Adresy IP, z których będą korzystać testerzy, aby Twój zespół monitoringu odróżnił ich od prawdziwego atakującego. |
| Wykluczone techniki | Typowe wyłączenia to denial of service, socjotechnika i dostęp fizyczny. Zapisz je w każdym przypadku. |
| Warunki zatrzymania | Co powoduje wstrzymanie testów: awaria, dostęp do nieoczekiwanych danych osobowych, krytyczny finding. |
| Kontakty | Po dwie imienne osoby z każdej strony, z numerami telefonów działającymi także w nocy. |
Zdecyduj z góry, czy Twój SOC zostanie poinformowany o teście. Poinformowanie go sprawdza procesy, a zachowanie testu w tajemnicy sprawdza detekcję. Oba podejścia są uprawnione, ale wybierz je świadomie.
Konta testowe i obsługa danych
Przygotuj konta, ponieważ tester bez loginu nie sprawdzi tego, co się za nim kryje. Daj po jednym koncie dla każdej roli w aplikacji, a do tego dwa konta w tej samej roli należące do różnych klientów lub tenantów. Bez takiej pary nie da się sprawdzić, czy jeden użytkownik może dotrzeć do danych drugiego.
Załóż konta z wyprzedzeniem, sprawdź, czy da się na nie zalogować, i określ, jak będzie obsługiwane uwierzytelnianie wieloskładnikowe.
Uzgodnij w umowie sposób obchodzenia się z danymi:
- Tam, gdzie to możliwe, używaj w stagingu danych syntetycznych. Jeśli produkcja jest w zakresie, wskaż, które rzeczywiste rekordy testerzy mogą przeglądać, a których nie wolno im oglądać.
- Określ, gdzie będą przechowywane materiały dowodowe, takie jak zrzuty ekranu, logi żądań i wydobyte dane, kto będzie miał do nich dostęp i jak długo testerzy będą je przechowywać.
- Wymagaj, aby sam raport był przesyłany w formie zaszyfrowanej. To lista Twoich słabych punktów.
- Ustal zasadę dla wrażliwych znalezisk: jeśli testerzy natrafią na dane osobowe, przerywają pracę, zapisują lokalizację bez kopiowania zawartości i dzwonią do Twojej osoby kontaktowej.
Kryteria sukcesu i raportowanie
"Brak krytycznych findingów" nie jest kryterium sukcesu. Nagradza płytki test. Zdefiniuj zakończenie prac jako pokrycie plus jakość wyniku: uzgodnione wymagania zostały zbadane, a każdy finding ma wystarczająco dużo szczegółów, by go odtworzyć i naprawić.
NIST opisuje swój przewodnik jako pomoc w analizie findingów i opracowywaniu strategii ograniczania ryzyka, a nie tylko w przeprowadzaniu testów. Wymagaj tego samego. Każdy finding powinien zawierać kroki odtworzenia, dotknięty komponent, ocenę krytyczności z podaną metodą, byś mógł ją samodzielnie zweryfikować, oraz konkretne zalecenie naprawcze. Dodaj do wyceny retest naprawionych findingów i uzgodnij, kto przyjmuje raport i kiedy.
Jeśli zamawiasz test u dostawcy, na przykład w ramach naszej usługi testów penetracyjnych, zapisz te punkty w statement of work, a nie tylko ustal je podczas rozmowy kick-off.
Od czego zacząć
- Zapisz cel jako jedno zdanie i uzyskaj jego akceptację właściciela biznesowego.
- Wypisz aplikacje, środowiska i role objęte zakresem oraz wskaż wprost, co jest poza zakresem.
- Wybierz punkt odniesienia: rozdziały i sekcje ASVS objęte zakresem oraz wersję Web Security Testing Guide, wszystko zapisane z numerami wersji.
- Wypełnij tabelę rules of engagement, w tym kontakty, okno testów i adresy źródłowe.
- Utwórz i zweryfikuj konta testowe, w tym dwa konta w tej samej roli dla różnych tenantów, i ustal zasady obsługi danych.
- Wpisz kryteria sukcesu do umowy: format findingów, metodę oceny krytyczności, mapowanie na identyfikatory wymagań i retest.
