Jak napisać dobry raport z audytu bezpieczeństwa?

Nawet najlepiej przeprowadzony audyt bezpieczeństwa strony internetowej lub aplikacji będzie mało użyteczny, jeśli w jego trakcie nie udokumentujemy wykrytych zagrożeń, kroków do reprodukcji, potencjalnych zagrożeń płynących z ich wykorzystania oraz zaleceń dotyczących załatania błędu. Pokażemy Ci, jak krok po kroku przygotować szczegółowy raport.

Co powinien zawierać dobry raport z audytu bezpieczeństwa?

Ważny jest zarówno aspekt wizualny jak i merytoryczny. Raport powinien być estetyczny, lecz jego wizualna część nie powinna dominować i przeszkadzać w odbiorze treści w nim zawartych. To w końcu zawartość raportu ma kluczowe znaczenie. W tym artykule skupimy się na części merytorycznej. Na konkretnych przykładach przedstawimy poszczególne części składowe dokumentu podsumowującego audyt bezpieczeństwa, czyli:

• przedmiot prac,
• podsumowanie przeprowadzonych działań i ich wyników,
• szczegółowy opis wykrytych zagrożeń.

Sekcja pierwsza - strona tytułowa z przedmiotem audytu

W tej części powinniśmy zawrzeć informację o zawartości dokumentu i zaznaczyć, że jest to raport z audytu bezpieczeństwa. Dodatkowo należy określić przedmiot prac, czyli to, co zostało poddane testom bezpieczeństwa. Należy również podać datę wykonania prac, miejsce oraz osoby odpowiedzialne za audyt. Strona tytułowa powinna zawierać jedynie kluczowe i ogólnikowe przedmioty prac.

Jeśli testom została poddana aplikacja Foo, jej API, kod źródłowy oraz infrastruktura, na której działa, to właśnie te elementy powinny znaleźć się na pierwszej stronie raportu. Jeżeli natomiast audytowi została poddana cała aplikacja, nie należy w przedmiocie prac rozbijać jej na poszczególne części, a opisać jako całość. Na szeregowanie audytu na mniejsze i bardziej szczegółowe części przyjdzie czas później.

Raport z testów bezpieczeństwa - przykład

Przedmiot prac:

• Testy penetracyjne aplikacji Foo
• Testy bezpieczeństwa API aplikacji Foo
• Analiza kodu źródłowego aplikacji
• Testy penetracyjne infrastruktury aplikacji

Data wykonania prac:

01.10.2021 - 10.10.2021

Miejsce wykonania prac:

Wrocław

Audytorzy

Jan Kowalski

Sekcja druga - podsumowanie treści raportu

Kolejne strony powinny zawierać podsumowanie prac. Można na nich w bardziej szczegółowy sposób, niż na stronie tytułowej, opisać przedmiot prac. Podsumowanie jest też miejscem na podzielenie się wynikami zbiorczymi przeprowadzonego audytu i poinformowanie o najbardziej krytycznych podatnościach, znalezionych podczas audytu. Krytyczne podatności powinny być opisane w sposób zwięzły. Wszystkie podatności znajdą swoje miejsce na szerszy opis w dalszej części raportu.

Podsumowanie jest również miejscem na zapoznanie czytelnika z przyjętą klasyfikacją podatności. Dlatego powinniśmy wyszczególnić wszystkie stopnie i do każdego z nich dodać szczegółowy opis.

Poniżej przedstawiamy przykładowy opis stopni klasyfikacji podatności.

Informacja

Poziom Informacja nie jest traktowany jako podatność zagrażająca bezpieczeństwu. Jest to wiadomość wskazująca dobre praktyki, których wdrożenie pozwoli zwiększyć ogólny poziom bezpieczeństwa aplikacji. W tym stopniu spotkamy również zalecenia architektoniczne, których wdrożenie pozwoli zwiększyć bezpieczeństwo aplikacji.

Niski

Podatność mało istotna, jej wykorzystanie ma znikomy wpływ na bezpieczeństwo aplikacji lub jej wykorzystanie wymaga trudnych do osiągnięcia warunków.

Średni

Podatność średnio istotna, co oznacza, że jej wykorzystanie może wymagać pewnych warunków, które nie są niezwykle trudne do osiągnięcia. Może umożliwić dostęp do ograniczonej ilości danych lub do danych, które są klasyfikowane jako mało istotne.

Wysoki

Podatność istotna, której wykorzystanie pozwala na dostęp do wrażliwych danych aplikacji, lecz jej wykorzystanie wymaga spełnienia określonych warunków, takich jak na przykład konto z określonymi prawami. Jako wysokie określamy również podatności, które mogą zostać wykorzystane w prosty sposób, ale ich skutki nie są krytyczne.

Krytyczny

Wykorzystanie podatności krytycznej pozwala na przejęcie pełnej kontroli nad serwerem lub pozwala uzyskać dostęp do informacji istotnych i poufnych. Zwykle jest łatwa do wykorzystania i nie wymaga spełnienia określonych warunków. Podatności krytyczne wymagają natychmiastowej naprawy.

Sekcja trzecia - podatności

Każda podatność powinna zawierać zwięzły tytuł opisujący zagrożenie. W tytule należy umieścić również poziom krytyczności podatności. Następnie tworzymy opis, w którym w sposób szczegółowy przedstawiamy wykryte zagrożenie. Jeśli istnieją pewne warunki, które muszą zostać spełnione, aby wykorzystać podatność, należy je opisać. Następnie przychodzi kolej na opis szczegółów technicznych błędu, w którym przedstawiamy sposób wykorzystania błędu. Na końcu tej części raportu z audytu bezpieczeństwa należy zawrzeć rekomendacje, które po wprowadzeniu wyeliminują zagrożenie.

Przykładowy opis podatności

Poziom podatności: Krytyczny

Identyfikator podatności: FOO_BAR-API-000

Tytuł podatności: Tryb administratora dostępny poprzez manualne dodanie cookie

Opis

Aplikacja do autoryzacji administratora wykorzystuje cookie, które może zostać pozyskane przez atakującego. Konto, do którego można w ten sposób uzyskać dostęp, określane jest przez aplikację jako konto z god mode.

Warunki niezbędne do wykorzystania podatności: Brak

Szczegóły techniczne

Atakujący musi dodać w aplikacji cookie o następujących właściwościach:

Nazwa: code

Value: iddqd

Rekomendacja

Wprowadzenie autoryzacji login oraz uwierzytelniania dwuetapowego przy dostępie do konta god mode. Usunięcie autoryzacji poprzez cookie.

Raport z audytu bezpieczeństwa - podsumowanie

Podążanie za kilkoma prostymi zasadami pozwala na sprawne tworzenie przejrzystego i pełnego istotnych informacji raportu z audytu bezpieczeństwa. Jak zaznaczyliśmy we wstępie, sam audyt mógł być przeprowadzony wzorowo. Jeśli jednak raport (podsumowanie prac) nie będzie na tak samo wysokim poziomie, wynik audytu - czyli wszystkie wnioski, do których doszliśmy w trakcie, uwagi i rekomendacje - mogą nie zostać wprowadzone poprawnie lub zostać całkowicie pominięte. Raport powinien być napisany w sposób zarówno najprzyjemniejszy w odbiorze, jak i rzeczowy. Pamiętajmy również o części wizualnej takiego dokumentu, która powinna dodać estetyki całości bez odwracania uwagi od treści.

Wskazówki, które przedstawiliśmy w tym artykule będą przydatne podczas przygotowywania dokumentów po audytach różnego rodzaju aplikacji i stron internetowych, także w Drupalu. Jeśli potrzebujesz dodatkowych porad odnośnie raportów bezpieczeństwa aplikacji w tym frameworku lub przeprowadzenia kompletnego audytu, dowiedz się więcej o naszym zespole wsparcia Drupala.