Audyt ma wskazać ryzyko i kolejność napraw, nie tylko wygenerować listę uwag.
Oceniamy wybrane elementy środowiska IT pod kątem realnych scenariuszy zagrożeń. Wyniki powinny pozwolić odpowiedzieć na trzy pytania: co jest niebezpieczne, jaki może być skutek i co należy poprawić w pierwszej kolejności.
Przykładowe obszary audytu
Tożsamość i dostęp
Konta uprzywilejowane, MFA, polityka haseł, nieużywane konta, uprawnienia i rozdzielenie ról administracyjnych.
Sieć i ekspozycja
Segmentacja, zdalny dostęp, wystawione usługi, reguły firewall, urządzenia sieciowe i podstawowe mechanizmy ochronne.
Systemy i aktualizacje
Wsparcie producenta, zaległe poprawki, konfiguracja systemów, zabezpieczenia endpointów i oprogramowanie o podwyższonym ryzyku.
Backup i odtwarzanie
Zakres kopii, retencja, separacja, ochrona przed usunięciem oraz przede wszystkim praktyczna możliwość odtworzenia.
Monitoring i logi
Czy organizacja zbiera informacje potrzebne do wykrycia incydentu i późniejszego ustalenia, co faktycznie się wydarzyło.
Poczta i współpraca
Ochrona przed phishingiem, konfiguracja domen, reguły przekazywania, aplikacje OAuth i proces reagowania na przejęcie konta.
Dane i urządzenia
Szyfrowanie, nośniki wymienne, urządzenia mobilne, udostępnianie informacji i wycofywanie sprzętu.
Reagowanie
Role, kontakty, procedury, priorytety, sposób izolacji urządzeń i zachowania informacji po incydencie.
Audyt zaczyna się od kontekstu biznesowego.
Nie wszystkie systemy mają tę samą wartość i nie każdy problem wymaga natychmiastowej inwestycji. Najpierw identyfikujemy krytyczne procesy, dane, zależności i scenariusze, które mogłyby zatrzymać działalność lub spowodować utratę informacji.
Następnie łączymy ustalenia techniczne z oceną wpływu i możliwością wykorzystania słabości.
Wynik powinien być wykonalny.
- opis stanu i kontekstu problemu;
- ocena istotności i potencjalnego wpływu;
- dowody lub przykłady potwierdzające ustalenie;
- rekomendowane działanie naprawcze;
- priorytet oraz sugerowana kolejność wdrożenia;
- lista tematów wymagających dalszej, pogłębionej analizy.
Od wywiadu do planu naprawczego
Zakres
Ustalenie środowiska, systemów krytycznych, ograniczeń i oczekiwanego rezultatu.
Przegląd
Zbieranie konfiguracji, rozmowy z właścicielami systemów i analiza wybranych zabezpieczeń.
Ocena ryzyka
Powiązanie ustaleń technicznych z wpływem na organizację i prawdopodobnym scenariuszem nadużycia.
Rekomendacje
Priorytety, działania szybkie i plan zmian wymagających projektu lub budżetu.
Ocena nie powinna opierać się wyłącznie na deklaracjach.
W zależności od uzgodnionego zakresu audyt może wykorzystywać eksporty konfiguracji, listy kont i uprawnień, raporty podatności, logi, ustawienia backupu, dokumentację sieciową oraz rozmowy z właścicielami systemów.
Konfiguracje
Ustawienia systemów, urządzeń, usług chmurowych, bezpieczeństwa endpointów i mechanizmów zdalnego dostępu.
Tożsamość
Role, grupy, konta uprzywilejowane, konta serwisowe, MFA, nieaktywne obiekty i wyjątki od standardów.
Logi i alerty
Ocena, czy dostępne dane pozwalają zauważyć nietypową aktywność oraz odtworzyć przebieg najważniejszych zdarzeń.
Procesy
Backup, patching, onboarding/offboarding, obsługa podatności, reagowanie na incydenty i wycofywanie sprzętu.
Nie każda luka ma taki sam wpływ.
Wysoki numer w skanerze podatności nie zawsze oznacza najwyższe ryzyko biznesowe. Przy ocenie liczy się m.in. ekspozycja systemu, łatwość wykorzystania, znaczenie usługi, dostępne zabezpieczenia kompensujące i to, jakie dane lub uprawnienia może uzyskać atakujący.
Raport powinien oddzielać działania natychmiastowe od zmian wymagających projektu, testów lub modernizacji architektury.
To nie są synonimy.
Audyt może obejmować szeroką analizę konfiguracji i procesów bez aktywnego wykorzystywania podatności. Test penetracyjny skupia się na praktycznej weryfikacji możliwości uzyskania dostępu w ściśle uzgodnionym zakresie. Zakres prac powinien jasno określać, które działania są dozwolone.
Raport ma być przydatny również po zakończeniu spotkania: powinien wskazywać właściciela działania, priorytet, zależności i sposób weryfikacji, że poprawka rzeczywiście została wdrożona.