Raport to ta część testu penetracyjnego, która pozostaje na dłużej. Testy trwają kilka dni lub tygodni; raport jest podstawą pracy programistów nad poprawkami, czyta go kierownictwo i może on zostać udostępniony klientowi lub partnerowi. Słaby raport może sprawić, że staranny test wyda się powierzchowny, a przejrzysty raport zamienia znaleziska w decyzje. Ten przewodnik wyjaśnia, co zwykle zawiera profesjonalny raport z testu penetracyjnego, jak go czytać i o co prosić przed rozpoczęciem współpracy.
Co to jest
Raport z testu penetracyjnego to pisemny zapis tego, co było testowane, w jaki sposób, w jakich warunkach i co zostało znalezione. Powinien być czytelny dla dwóch grup odbiorców. Interesariusze nietechniczni potrzebują krótkiego podsumowania ogólnego ryzyka, najważniejszych problemów i zalecanych priorytetów. Zespoły techniczne potrzebują wystarczająco szczegółowych informacji o każdym znalezisku, aby je zrozumieć, odtworzyć w bezpiecznym środowisku i naprawić. Dobry raport opisuje też własne ograniczenia: co było poza zakresem, czego nie dało się przetestować i jakie warunki wpłynęły na pokrycie, na przykład niedostępne konta testowe lub skrócone okno testowe. Bez tych ograniczeń czytelnicy mogą założyć, że raport obejmuje więcej, niż faktycznie obejmuje.
Dla kogo
Ten przewodnik jest przydatny dla:
- Kupujących, którzy porównują oferty i chcą wiedzieć, jaki rezultat faktycznie otrzymają
- Liderów zespołów inżynierskich, którzy otrzymają znaleziska i muszą zaplanować naprawy
- Menedżerów, którzy muszą przekazać podsumowanie klientowi, partnerowi, audytorowi lub zarządowi bez wyolbrzymiania wyniku
- Zespołów, które otrzymały wcześniejszy raport i miały trudność z podjęciem działań na jego podstawie
Co pomaga wyjaśnić
Znajomość oczekiwanej struktury pomaga sprawdzić:
- Czy zakres i zasady prowadzenia testów opisane w raporcie odpowiadają temu, co uzgodniono
- Czy każde znalezisko ma dowody, jasną ocenę istotności i praktyczne zalecenia naprawcze
- Które problemy wymagają natychmiastowego działania, a które można zaplanować w normalnych cyklach rozwoju
- Które stwierdzenia można bezpiecznie udostępnić na zewnątrz, a które powinny pozostać wyłącznie w gronie pracowników technicznych
Co jest zawarte
- Podsumowanie dla kierownictwa: ogólny obraz, najistotniejsze znaleziska i zalecane priorytety opisane prostym językiem
- Zakres i zasady prowadzenia testów: cele, środowiska, role użytkowników, daty, okno testowe i wyłączenia
- Podsumowanie metodyki: zastosowane podejście i ramy referencyjne, na przykład wytyczne OWASP dla aplikacji internetowych
- Rejestr znalezisk: każdy problem z tytułem, oceną istotności, zasobem, którego dotyczy, opisem, odniesieniem do dowodów i wpływem na biznes
- Szczegóły techniczne: kroki, dzięki którym zespół może zrozumieć problem i bezpiecznie go odtworzyć
- Zalecenia naprawcze: praktyczne poprawki oraz, tam gdzie to przydatne, krótkoterminowe środki ograniczające ryzyko
- Ograniczenia: czego nie dało się przetestować i dlaczego
- Sekcja ponownego testu: status uzgodnionych znalezisk po ich naprawieniu przez zespół, jeśli ponowny test jest uwzględniony
Co nie jest uwzględnione
- Stwierdzenia, że po testach system jest bezpieczny lub nie ma już podatności
- Znalezisk spoza uzgodnionego zakresu przedstawionych tak, jakby zostały przetestowane
- Certyfikacji, zatwierdzenia zgodności ani formalnej opinii audytowej
- Wdrożenia poprawek, chyba że zostanie to uzgodnione osobno
Kiedy to wybrać
Warto przeczytać ten przewodnik przed podpisaniem oferty na testy, aby móc poprosić o przykładowy raport i potwierdzić jego strukturę. Jest on przydatny także w momencie otrzymania raportu: powyższe sekcje mogą posłużyć jako lista kontrolna, aby sprawdzić, czy czegoś nie brakuje. Jeśli interesariusz poprosił o „przesłanie raportu z pentestu”, należy z wyprzedzeniem zdecydować, czy potrzebuje pełnego dokumentu technicznego, czy podsumowania dla kierownictwa i pisma o statusie napraw. Szerokie udostępnianie pełnych szczegółów technicznych zwiększa ryzyko, ponieważ opisują one słabości Państwa systemów.
Nasze podejście
Przed rozpoczęciem testów warto ustalić jasne zasady oceny istotności. Wielu dostawców stosuje skalę opartą na prawdopodobieństwie i wpływie, czasem z odwołaniem do CVSS; ważne jest, aby była spójna i wyjaśniona. Należy uzgodnić, jak dowody będą przechowywane i udostępniane oraz kto jest wskazaną osobą kontaktową. Po otrzymaniu raportu warto zaplanować omówienie wyników, aby programiści mogli zadawać pytania, dopóki kontekst jest świeży. Rejestr znalezisk należy zamienić na zgłoszenia z osobami odpowiedzialnymi i docelowymi terminami, a w pierwszej kolejności naprawić problemy o najwyższej istotności. Następnie warto poprosić o ponowny test uzgodnionych znalezisk, aby raport mógł odnotować, co zostało rozwiązane. Nasza usługa Penetration Testing obejmuje podsumowanie dla kierownictwa, podsumowanie zakresu i zasad prowadzenia testów, rejestr znalezisk ocenionych według istotności z odniesieniami do dowodów, szczegóły techniczne każdego znaleziska, priorytetowy plan napraw oraz wynik ponownego testu, jeśli jest on uwzględniony. Niezależnie od wybranego dostawcy warto zachowywać każdą wersję raportu, odnotowywać, które znaleziska zaakceptowano jako ryzyko zamiast je naprawić, i zapisywać, kto podjął tę decyzję. Taki zapis bywa równie cenny jak sam test, gdy następnym razem ktoś zapyta o stan Państwa bezpieczeństwa.
Często zadawane pytania
Artykuły pokrewne
Zacznij
Potrzebują Państwo raportu, na podstawie którego zespół rzeczywiście może działać?
Proszę wskazać, które systemy wymagają testów i kto będzie czytał wyniki. Potwierdzimy na piśmie zakres, zasady prowadzenia testów i strukturę raportu.
Poproś o pisemny zakres