Audytor powinien zobaczyć środowisko takim, jakie jest w rzeczywistości. Próba szybkiego „upiększania” konfiguracji przed audytem może ukryć przyczynę problemów i utrudnić ocenę ryzyka. Znacznie lepiej przygotować wiarygodną inwentaryzację, listę osób, zakres dostępu i dokumentację, nawet jeżeli część materiałów jest niepełna.
1. Ustal cel i zakres audytu
Na początku trzeba odpowiedzieć, dlaczego audyt jest wykonywany. Inny zakres będzie miała ocena przed ubezpieczeniem, inny przegląd po incydencie, a jeszcze inny audyt całej organizacji. Warto ustalić lokalizacje, systemy, okres prac, ograniczenia, osoby kontaktowe oraz format raportu.
2. Wyznacz osoby odpowiedzialne
Audyt wymaga kontaktu z osobą decyzyjną, administratorem IT, właścicielami procesów biznesowych i — zależnie od zakresu — księgowością, kadrami, inspektorem ochrony danych lub dostawcami zewnętrznymi. Jedna osoba powinna koordynować przekazywanie informacji, ale odpowiedzi nie mogą opierać się wyłącznie na wiedzy jednego administratora.
3. Przygotuj inwentaryzację
Lista nie musi być idealna. Powinna jednak wskazywać właściciela zasobu, lokalizację, funkcję, system operacyjny, znaczenie dla firmy i sposób wykonywania kopii zapasowej.
4. Zbierz dokumentację i dowody
Przydatne będą schematy sieci, procedury nadawania kont, polityka kopii, wykaz licencji, instrukcja reagowania na incydenty, umowy z dostawcami, raporty z testów odtwarzania oraz zestawienie aktualizacji. Jeżeli dokument nie istnieje, należy to jasno zaznaczyć — brak dokumentacji jest również wynikiem audytu.
5. Zaplanuj bezpieczny dostęp audytora
Dostęp powinien być czasowy, imienny i ograniczony do uzgodnionego zakresu. Nie należy przekazywać głównego hasła administratora pocztą ani komunikatorem. Lepsze jest osobne konto, VPN, MFA oraz rejestrowanie operacji. Po zakończeniu prac konto powinno zostać zablokowane lub usunięte.
6. Wstrzymaj niepotrzebne zmiany
Duże aktualizacje, migracje i przebudowa sieci w trakcie audytu utrudniają porównanie stanu. Jeżeli zmiany są konieczne, powinny zostać odnotowane i przekazane audytorowi. Krytycznych podatności nie należy jednak pozostawiać bez naprawy tylko po to, aby audytor mógł je zobaczyć — wystarczy zachować dowód i opis działań.
7. Przygotuj pracowników do rozmów
Pracownicy powinni wiedzieć, że celem audytu nie jest szukanie winnych. Ważne są rzeczywiste praktyki: jak przekazywane są pliki, gdzie zapisywane są hasła, jak zgłasza się podejrzane wiadomości i co dzieje się podczas awarii. Różnica między procedurą a praktyką jest jednym z najcenniejszych wyników audytu.
8. Pytania, na które warto znać odpowiedź
- które systemy muszą działać, aby firma mogła obsługiwać klientów,
- jak długo organizacja może pracować bez każdego z nich,
- kiedy ostatnio odtworzono dane z kopii,
- kto ma uprawnienia administratora i dlaczego,
- jak wyłączany jest dostęp osoby odchodzącej z firmy,
- kto podejmuje decyzję podczas incydentu,
- gdzie znajdują się aktualne dane kontaktowe do dostawców.
9. Co zrobić po audycie?
Jeszcze przed otrzymaniem raportu warto ustalić, kto będzie zatwierdzał plan naprawczy i budżet. Zalecenia należy przypisać do osób, terminów i mierzalnych rezultatów. Po wdrożeniu najważniejszych zmian powinien odbyć się przegląd potwierdzający.
Źródła i dalsza lektura
Słownik
Skróty i pojęcia użyte w artykule
Kliknij wybraną nazwę, aby rozwinąć jej znaczenie.
CMDB
Baza informacji o urządzeniach, systemach, usługach, konfiguracjach i zależnościach w środowisku IT.
SLA
Uzgodniony poziom świadczenia usługi, np. czas reakcji, dostępność lub termin usunięcia awarii.
MFA
Logowanie wymagające więcej niż jednego składnika, np. hasła oraz kodu, aplikacji lub klucza sprzętowego.
VPN
Szyfrowany dostęp zdalny do firmowej sieci lub bezpieczne połączenie pomiędzy lokalizacjami.
SIEM
Centralne gromadzenie, korelacja i analiza logów oraz alertów bezpieczeństwa.
EDR
System monitorowania stacji i serwerów, wykrywania zagrożeń oraz wspierania reakcji na incydent.
BCP
Plan ciągłości działania opisujący, jak organizacja utrzyma najważniejsze procesy podczas zakłócenia.
DRP
Plan odtworzenia systemów IT po poważnej awarii, ataku lub utracie lokalizacji.
RPO
Maksymalna akceptowalna utrata danych określona czasem.
RTO
Zakładany maksymalny czas przywrócenia procesu lub systemu.

