Od skanowania do dowodów: ISO 27001:2022, NIS2, DORA

Jest poniedziałek, godzina 08:16. Na panelu dotyczącym dostępnego z Internetu serwera aplikacyjnego właśnie pojawiła się krytyczna podatność umożliwiająca zdalne wykonanie kodu. Zespół infrastruktury informuje, że poprawka dostawcy jest dostępna. Właściciel aplikacji ostrzega, że serwer obsługuje krytyczny dla przychodów proces klienta. Dział prawny pyta, czy wykorzystanie podatności mogłoby uruchomić obowiązki raportowe wynikające z NIS2, DORA lub GDPR. CISO, Maria, otwiera kalendarz audytów i widzi rzeczywisty problem: audyt nadzoru ISO 27001:2022 zaczyna się w przyszłym tygodniu, przegląd gotowości do NIS2 już trwa, a duży klient fintech poprosił o dowody na potrzeby DORA.

Skaner pokazuje status czerwony. Tablica zgłoszeń pokazuje aktywność. Arkusz kalkulacyjny pokazuje nakład pracy. Żadne z tych źródeł samo w sobie nie dowodzi jednak skuteczności kontroli.

To luka, którą wiele organizacji odkrywa zbyt późno. Skanowanie podatności nie jest tym samym co audytowa gotowość procesu zarządzania podatnościami. Skan wskazuje, że coś może być nieprawidłowe. Dowód audytowy potwierdza, że organizacja wiedziała, jakie aktywa posiada, oceniła ryzyko, przypisała właścicielstwo, działała zgodnie z polityką, kontrolowała zmianę, udokumentowała wyjątki, zweryfikowała wyniki i przeprowadziła przegląd rezultatu.

Dla ISO/IEC 27001:2022, NIS2 i DORA taki łańcuch dowodowy jest równie istotny jak sama poprawka techniczna. Skaner rozpoczyna historię. Uzupełniają ją inwentarz aktywów, rejestr podatności, zgłoszenie, decyzja dotycząca ryzyka, zapis zmiany, rejestr poprawek, dowód walidacji, zatwierdzenie wyjątku i przegląd zarządzania.

Podejście Clarysec jest proste: nie traktuj zarządzania podatnościami jako comiesięcznego rytuału technicznego. Traktuj je jako nadzorowany proces tworzenia i utrzymywania dowodów.

Dlaczego raporty ze skanowania zawodzą jako dowody audytowe

Skanowanie podatności jest obserwacją techniczną wykonaną w określonym momencie. Może zidentyfikować CVE, brakującą poprawkę, niewspieraną bibliotekę, wyeksponowaną usługę albo słabą konfigurację. To użyteczne, ale niewystarczające.

Audytor zada inne pytania:

• Czy objęte problemem aktywo znajdowało się w zakresie?
• Kto jest właścicielem aktywa i usługi biznesowej?
• Czy podatność oceniono z uwzględnieniem ekspozycji, możliwości wykorzystania, wpływu biznesowego i wrażliwości danych?
• Czy działania naprawcze zakończono w zdefiniowanym terminie?
• Jeśli działania naprawcze opóźniono, kto zaakceptował ryzyko szczątkowe?
• Czy poprawkę wdrożono w ramach kontrolowanego procesu zarządzania zmianami?
• Czy naprawę zweryfikowano przez ponowne skanowanie albo walidację techniczną?
• Czy dowody zachowano i objęto przeglądem zarządzania?

Folder z eksportami ze skanera rzadko odpowiada na te pytania. W audycie ISO 27001:2022 audytor sprawdza, czy SZBI działa zgodnie z założeniami. W ramach NIS2 organy zarządzające muszą zatwierdzać i nadzorować środki zarządzania ryzykiem cyberbezpieczeństwa. W ramach DORA podmioty finansowe potrzebują udokumentowanych ram zarządzania ryzykiem ICT, cyklu życia incydentów, testów odporności oraz kontroli ryzyka ze strony zewnętrznych dostawców usług ICT. W ramach GDPR problem sprowadza się do tego, czy odpowiednie środki techniczne i organizacyjne chroniły dane osobowe oraz czy można wykazać rozliczalność.

Klauzule ISO/IEC 27001:2022 od 4.1 do 4.4 wymagają, aby organizacja rozumiała swój kontekst, strony zainteresowane, wymagania i zakres SZBI. Zarządzania podatnościami i poprawkami nie można projektować w oderwaniu od tych elementów. Musi ono odzwierciedlać umowy z klientami, wymagania regulatorów, zależności od chmury obliczeniowej, outsourcing usług ICT, obowiązki ochrony danych i usługi krytyczne.

Klauzule ISO/IEC 27001:2022 od 6.1.1 do 6.1.3 wymagają oceny ryzyka, postępowania z ryzykiem, doboru środków kontrolnych, Deklaracji stosowania oraz zatwierdzenia ryzyka szczątkowego przez właściciela ryzyka. Oznacza to, że dowody dotyczące podatności powinny być powiązane z rejestrem ryzyk, planem postępowania z ryzykiem i SoA.

ISO/IEC 27005:2022 wzmacnia ten model, zachęcając organizacje do konsolidowania wymagań z Załącznika A, obowiązków sektorowych, regulacji, umów, reguł wewnętrznych i istniejących kontroli w konfiguracji bazowej oceny ryzyka. Podkreśla również znaczenie kryteriów prawdopodobieństwa, konsekwencji, obowiązków prawnych, relacji z dostawcami, wpływu na prywatność i wpływu stron trzecich. W praktyce podatność nie jest tylko liczbą CVSS. Jest zdarzeniem ryzyka powiązanym z aktywami, obowiązkami, interesariuszami i konsekwencjami biznesowymi.

Presja regulacyjna stojąca za dowodami dotyczącymi poprawek

Współczesne regulacje cyberbezpieczeństwa coraz mniej tolerują nieformalne wdrażanie poprawek.

NIS2 ma zastosowanie do wielu średnich i dużych podmiotów w sektorach wysokiej krytyczności i krytycznych, a w określonych przypadkach może obejmować także podmioty niezależnie od ich wielkości. Jej zakres obejmuje dostawców infrastruktury cyfrowej, takich jak usługi w chmurze obliczeniowej, usługi centrów danych, sieci dostarczania treści, dostawcy publicznie dostępnych usług łączności elektronicznej, usługi zaufania, usługi DNS i TLD, a także dostawców zarządzania usługami ICT, takich jak dostawcy usług zarządzanych i dostawcy zarządzanego bezpieczeństwa. Obejmuje również ważnych dostawców cyfrowych, takich jak internetowe platformy handlowe, wyszukiwarki internetowe i platformy społecznościowe.

Article 20 NIS2 czyni cyberbezpieczeństwo odpowiedzialnością organu zarządzającego. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego nabywania, bezpiecznego rozwoju oprogramowania, bezpiecznego utrzymania, obsługi i ujawniania podatności, oceny skuteczności, cyberhigieny, kontroli dostępu, zarządzania aktywami i uwierzytelniania. Article 23 ustanawia etapowy proces zgłaszania istotnych incydentów, obejmujący wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin oraz, w stosownych przypadkach, raport końcowy w ciągu jednego miesiąca.

DORA tworzy bezpośrednio stosowany zbiór zasad cyfrowej odporności operacyjnej dla podmiotów finansowych od 17 stycznia 2025 r. Obejmuje zarządzanie ryzykiem ICT, zgłaszanie poważnych incydentów związanych z ICT, testowanie odporności operacyjnej, wymianę informacji o cyberzagrożeniach, zarządzanie ryzykiem ze strony zewnętrznych dostawców usług ICT oraz nadzór nad kluczowymi zewnętrznymi dostawcami usług ICT. Articles 5 i 6 umieszczają zarządzanie ryzykiem ICT pod nadzorem organu zarządzającego i wymagają udokumentowanych, zintegrowanych oraz regularnie przeglądanych ram zarządzania ryzykiem ICT. Article 8 wzmacnia potrzebę identyfikacji funkcji biznesowych wspieranych przez ICT, aktywów informacyjnych, aktywów ICT i zależności. Articles 17 to 20 wymagają wykrywania, rejestrowania, klasyfikacji, eskalacji, raportowania, komunikacji, działań naprawczych i uczenia się w odniesieniu do incydentów związanych z ICT. Articles 28 to 30 wymagają kontrolowania ryzyka ze strony zewnętrznych dostawców usług ICT poprzez rejestry, due diligence, zabezpieczenia umowne, prawa audytu, planowanie wyjścia i nadzór.

W przypadku podmiotów finansowych objętych DORA rozporządzenie to co do zasady zastępuje równoważne obowiązki NIS2 dotyczące zarządzania ryzykiem i raportowania. NIS2 nadal ma jednak znaczenie dla koordynacji ekosystemu oraz podmiotów znajdujących się poza zakresem DORA. Dla dostawców SaaS, MSP i MSSP obsługujących klientów finansowych praktyczna rzeczywistość jest bezpośrednia: klienci mogą wymagać dowodów dotyczących podatności, aby spełnić swoje obowiązki wynikające z DORA.

GDPR dodaje kolejną warstwę. Articles 2 i 3 mogą mieć zastosowanie do organizacji mających siedzibę w UE oraz organizacji spoza UE oferujących towary lub usługi osobom w UE albo monitorujących ich zachowanie. Article 5 wymaga ochrony danych osobowych i rozliczalności za zgodność. Article 4 definiuje naruszenie ochrony danych osobowych jako naruszenie bezpieczeństwa prowadzące do przypadkowej lub bezprawnej utraty, zniszczenia, zmiany, nieuprawnionego ujawnienia danych osobowych lub nieuprawnionego dostępu do nich. Opóźniona poprawka na bazie danych, platformie tożsamości albo portalu klienta może stać się kwestią rozliczalności w obszarze prywatności.

Od polityki do dowodu

Pierwszym krokiem jest zdefiniowanie zasad. Silna polityka zarządzania podatnościami i poprawkami nie jest wyłącznie dokumentem audytowym. Jest operacyjną konstytucją dla danej kontroli.

Dla środowisk korporacyjnych Polityka zarządzania podatnościami i poprawkami wyraźnie łączy techniczne wdrażanie poprawek ze zgodnością przekrojową:

Niniejsza polityka wspiera zgodność z ISO/IEC 27001 Załącznik A, środek kontrolny 8.8 oraz wytycznymi ISO/IEC 27002, a także odnosi się do wymagań regulacyjnych wynikających z DORA Article 8, NIS2 Article 21, GDPR Article 32 oraz domen DSS i APO COBIT 2019.

Z sekcji „Cel”.

Ta sama polityka ustanawia oczekiwanie w zakresie ładu dla kluczowego artefaktu dowodowego:

Scentralizowany rejestr zarządzania podatnościami musi być utrzymywany przez zespół operacji bezpieczeństwa i przeglądany co miesiąc przez CISO lub delegowany organ.

Z sekcji „Wymagania dotyczące ładu”, klauzula polityki 5.1.

Definiuje również częstotliwość skanowania:

Wszystkie systemy muszą być skanowane co najmniej raz w miesiącu; aktywa wysokiego ryzyka lub eksponowane zewnętrznie muszą być skanowane co tydzień.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Zapobiega także temu, aby pilne wdrażanie poprawek stało się niekontrolowaną aktywnością techniczną:

Wszystkie działania naprawcze muszą być koordynowane poprzez proces zarządzania zmianami (zgodnie z P5 - Polityka zarządzania zmianami), aby zapewnić stabilność i zachowanie ścieżki audytu.

Z sekcji „Wymagania dotyczące ładu”, klauzula polityki 5.5.

W przypadku MŚP te same zasady dowodowe można wdrożyć prościej. Polityka zarządzania podatnościami i poprawkami dla MŚP stanowi:

Utrzymywać dokładne zapisy zastosowanych poprawek, nierozwiązanych problemów i wyjątków w celu zapewnienia gotowości do audytu.

Z sekcji „Cele”, klauzula polityki 3.4.

Następnie definiuje rejestr poprawek jako dowód audytowy:

Rejestr poprawek musi być utrzymywany i przeglądany podczas audytów oraz działań reagowania na incydenty.

Z sekcji „Wymagania dotyczące ładu”, klauzula polityki 5.4.1.

Określa też minimalną zawartość:

Rejestry muszą obejmować nazwę urządzenia, zastosowaną aktualizację, datę wdrożenia poprawki oraz przyczynę ewentualnego opóźnienia.

Z sekcji „Wymagania dotyczące ładu”, klauzula polityki 5.4.2.

Dla pilnej ekspozycji dostępnej z Internetu polityka dla MŚP ustanawia mierzalne wymaganie:

Poprawki krytyczne muszą być zastosowane w ciągu 3 dni od wydania, zwłaszcza w przypadku systemów dostępnych z Internetu.

Z Polityki zarządzania podatnościami i poprawkami dla MŚP, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Te klauzule przekształcają pracę techniczną w dowody. Polityka definiuje oczekiwania. Rejestr dokumentuje ustalenia. Zgłoszenie przypisuje pracę. Zapis zmiany kontroluje wdrożenie. Rejestr poprawek potwierdza działanie. Rejestr ryzyk ujmuje wyjątki. Protokoły przeglądu potwierdzają nadzór.

Model Clarysec zorientowany na dowody

Model Clarysec zorientowany na dowody zaczyna się od jednej zasady: każde ustalenie dotyczące podatności musi być możliwe do prześledzenia od wykrycia do decyzji.

W Zenith Blueprint: 30-etapowa mapa drogowa audytora, w fazie „Kontrole w praktyce”, krok 19: „Zabezpieczenia techniczne I”, zarządzanie podatnościami jest traktowane jako powtarzalna kontrola, a nie wymóg teoretyczny:

Zarządzanie podatnościami jest jednym z najważniejszych obszarów współczesnej cyberhigieny. Chociaż zapory sieciowe i oprogramowanie antywirusowe zapewniają ochronę, mogą zostać osłabione, jeśli niezałatane systemy lub błędnie skonfigurowane usługi pozostają eksponowane.

Ten sam krok wyjaśnia, że organizacje powinny stosować regularne harmonogramy wdrażania poprawek, skanery podatności, kwalifikację podatności, przypisanie odpowiedzialności, śledzenie działań naprawczych, środki kompensujące i akceptację ryzyka szczątkowego. Co najważniejsze, właściwie ujmuje perspektywę audytową:

Kontrola nie polega na perfekcji, lecz na posiadaniu zorganizowanego, przejrzystego i rozliczalnego procesu.

Dla audytorów to rozróżnienie ma znaczenie. Dojrzała organizacja może mieć otwarte podatności i nadal wykazywać kontrolę, pod warunkiem że posiada priorytetyzację opartą na ryzyku, udokumentowane właścicielstwo, zatwierdzone wyjątki, środki kompensujące i zweryfikowane działania naprawcze.

Zenith Blueprint ostrzega również, że audytorzy dokładnie sprawdzą ten obszar:

To kontrola o wysokim priorytecie dla audytorów i zwykle będą w nią wchodzić bardzo szczegółowo. Należy spodziewać się pytań o to, jak często systemy są poprawiane, jaki proces stosujecie po ogłoszeniu zero-day oraz które systemy najtrudniej załatać.

Dlatego CISO nie powinien wchodzić na audyt wyłącznie z panelem skanera. Pakiet dowodowy musi pokazywać ład, proces, wykonanie, weryfikację i doskonalenie.

Mapowanie środków kontrolnych ISO 27002 na dowody audytowe

Zenith Controls: przewodnik zgodności przekrojowej działa jak kompas zgodności przekrojowej, mapując środki kontrolne ISO/IEC 27002:2022 i pokazując, jak odnoszą się do oczekiwań audytowych. W przypadku zarządzania podatnościami i poprawkami trzy środki kontrolne ISO/IEC 27002:2022 tworzą trójkąt operacyjny.

ISO/IEC 27002:2022 środek kontrolny 8.8, Zarządzanie podatnościami technicznymi, jest kontrolą centralną. Ma charakter zapobiegawczy, wspiera poufność, integralność i dostępność, jest zgodny z koncepcjami cyberbezpieczeństwa Identify i Protect oraz łączy się z zarządzaniem zagrożeniami i podatnościami.

ISO/IEC 27002:2022 środek kontrolny 8.32, Zarządzanie zmianami, również ma charakter zapobiegawczy. Łączy wdrażanie poprawek z kontrolowanym wdrożeniem, testowaniem, zatwierdzeniem, planem wycofania zmian i identyfikowalnością audytową.

ISO/IEC 27002:2022 środek kontrolny 5.36, Zgodność z politykami, zasadami i normami bezpieczeństwa informacji, zapewnia, że proces nie jest opcjonalny ani zależny od indywidualnego heroizmu. Łączy zarządzanie podatnościami ze zgodnością z politykami, zapewnieniem i nadzorem.

To mapowanie pozwala uniknąć częstej porażki audytowej. Bezpieczeństwo mówi: „Załataliśmy”. Operacje mówią: „Wdrożyliśmy”. Zgodność mówi: „Nie możemy udowodnić sekwencji”. Zmapowany łańcuch dowodowy daje wszystkim trzem zespołom tę samą historię.

Łańcuch dowodowy, którego oczekują audytorzy

Możliwy do obrony łańcuch dowodowy zarządzania podatnościami ma siedem etapów.

Praktyczna różnica między „uruchamiamy skany” a „jesteśmy gotowi do audytu” polega na ciągłości. Jeśli podatności nie można prześledzić od wykrycia do zamknięcia, kontrola jest słaba. Jeśli istnieją wyjątki, ale nikt ich nie zatwierdził, proces jest słaby. Jeśli poprawki omijają zarządzanie zmianami, ścieżka audytu jest słaba. Jeśli podatności krytyczne pozostają otwarte bez środków kompensujących, ład jest słaby.

Polityka audytu i monitorowania zgodności wspiera automatyzację jako część tego modelu:

Należy wdrożyć zautomatyzowane narzędzia do monitorowania zgodności konfiguracji, zarządzania podatnościami, statusu poprawek i dostępu uprzywilejowanego.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.

Dla MŚP Polityka audytu i monitorowania zgodności dla MŚP definiuje weryfikację kontroli technicznych w praktycznych kategoriach:

Weryfikacja kontroli technicznych (np. status kopii zapasowych, konfiguracja kontroli dostępu, zapisy poprawek).

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.2.

Małe organizacje nie potrzebują narzędzi klasy korporacyjnej, aby osiągnąć gotowość do audytu. Potrzebują spójnych dowodów. Uproszczony rejestr, tablica zgłoszeń, rejestr poprawek i comiesięczny przegląd mogą wystarczyć, jeśli są kompletne, aktualne i powiązane z ryzykiem.

Przykład: jedno krytyczne ustalenie, w pełni gotowe do audytu

Cotygodniowe skanowanie zewnętrzne Marii identyfikuje CVE-2026-12345 na dostępnej z Internetu bramie API płatności. Skaner klasyfikuje je jako krytyczne. Usługa przetwarza tożsamość klientów i metadane transakcji, więc możliwe są implikacje GDPR i DORA. Właścicielem bramy jest zespół inżynierii platformy, ale poprawka wymaga krótkiej przerwy w działaniu.

Oto proces gotowy do audytu.

1. Utwórz wpis w rejestrze podatności

Zespół bezpieczeństwa zapisuje ustalenie w centralnym rejestrze:

• Identyfikator ustalenia: VULN-2026-0142
• Źródło: cotygodniowe skanowanie zewnętrzne
• Data i godzina wykrycia
• Aktywo: api-gw-prod-01
• Właściciel: zespół inżynierii platformy
• Ekspozycja: dostępny z Internetu
• Kontekst danych: tożsamość klientów i metadane transakcji
• Waga: krytyczna
• SLA: 72 godziny albo krócej zgodnie z polityką
• Zgłoszenie: SEC-4821
• Zapis zmiany: CHG-10988
• Status: zaplanowane działania naprawcze

2. Przeprowadź kwalifikację z uwzględnieniem kontekstu biznesowego i regulacyjnego

Zespół sprawdza dostępność exploita, powierzchnię ataku, wymagania uwierzytelniania, wpływ biznesowy i wrażliwość danych. Ponieważ system jest dostępny z Internetu i wspiera procesy klientów, podatność pozostaje krytyczna. Właścicielem ryzyka jest kierownik obszaru platformy, a CISO zostaje powiadomiony ze względu na możliwe implikacje NIS2, DORA i GDPR.

Klauzule ISO/IEC 27005:2022 od 7.1 do 7.4 wspierają identyfikację ryzyka, własność ryzyka, konsekwencje, prawdopodobieństwo i priorytetyzację. Klauzule od 8.2 do 8.6 wspierają wybór postępowania, określenie kontroli, powiązanie z SoA, planowanie postępowania i zatwierdzanie ryzyka szczątkowego.

3. Otwórz kontrolowaną zmianę awaryjną

Poprawka zostaje zaplanowana na ten sam wieczór. Zapis zmiany obejmuje referencję dostawcy, objęte usługi, plan testów, plan wycofania zmian, okno serwisowe, decyzję dotyczącą komunikacji z klientami, zatwierdzenia oraz wymaganie walidacji po wdrożeniu.

Wspiera to bezpośrednio ISO/IEC 27002:2022 środek kontrolny 8.32 oraz wymaganie polityki korporacyjnej, aby koordynować działania naprawcze przez zarządzanie zmianami.

4. Zastosuj poprawkę i zaktualizuj rejestr poprawek

Rejestr poprawek zapisuje nazwę urządzenia, zastosowaną aktualizację, datę wdrożenia poprawki oraz ewentualny powód opóźnienia. Gdyby wdrożenie poprawki zostało opóźnione, zespół udokumentowałby środki kompensujące, takie jak reguły zapory aplikacji webowych, tymczasowe ograniczenia dostępu, zwiększone rejestrowanie, izolację albo wzmocnione monitorowanie.

5. Zweryfikuj i zamknij

Zespół bezpieczeństwa ponownie skanuje bramę API. Podatność nie pojawia się już w wynikach. Zgłoszenie zostaje zaktualizowane o dowód czystego wyniku skanowania, wersję poprawki, znacznik czasu wdrożenia i powiązanie z zapisem zmiany. Status w rejestrze podatności zmienia się na „Zamknięte, zweryfikowane”.

6. Oceń wpływ na obowiązki raportowe

Jeśli nie doszło do wykorzystania podatności ani zakłócenia usługi, raportowanie incydentu w ramach NIS2 lub DORA może nie zostać uruchomione. Jeśli zostaną znalezione wskaźniki naruszenia, proces incydentowy musi sklasyfikować wpływ i eskalację. W ramach NIS2 istotny incydent może wymagać wczesnego ostrzeżenia i raportowania etapowego. W ramach DORA poważny incydent związany z ICT wymaga klasyfikacji i zgłoszenia zgodnie z właściwym procesem organu kompetentnego.

7. Włącz wnioski do przeglądu zarządzania

Na koniec miesiąca przegląd CISO odnotowuje, że podatność została wykryta przez cotygodniowe skanowanie zewnętrzne, usunięta w ramach SLA, zweryfikowana ponownym skanowaniem i zamknięta bez incydentu. Jeśli podobne problemy się powtarzają, plan postępowania może obejmować bezpieczne konfiguracje bazowe, zautomatyzowane wdrażanie poprawek, eskalację do dostawcy albo modernizację aplikacji.

Gdy audytor zapyta o CVE-2026-12345, Maria może przedstawić uporządkowany pakiet zamiast wiadomości e-mail i zrzutów ekranu.

To jest gotowość do audytu. Nie dlatego, że organizacja nie miała podatności, ale dlatego, że miała nad nimi kontrolę.

Jeden zestaw dowodów, wiele obowiązków

Dobrze zaprojektowany program zarządzania podatnościami i poprawkami może spełniać wymagania wielu frameworków bez dublowania pracy.

W przypadku ISO 27001:2022 dowody wspierają SZBI oparte na ryzyku, wdrożenie środków kontrolnych z Załącznika A, Deklarację stosowania, plany postępowania z ryzykiem, audyt wewnętrzny i ciągłe doskonalenie. Jeśli ISO/IEC 27002:2022 środek kontrolny 8.8 ma zastosowanie w SoA, organizacja powinna umieć wykazać uzasadnienie prawne, regulacyjne, ryzykowe albo biznesowe. Uzasadnienie to często obejmuje NIS2 Article 21, obowiązki DORA w zakresie ryzyka ICT, rozliczalność GDPR, umowy z klientami i potrzeby odporności operacyjnej.

W przypadku NIS2 te same dowody pomagają wykazać środki z Article 21, w tym analizę ryzyka, obsługę podatności, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, cyberhigienę, kontrolę dostępu i ocenę skuteczności. Article 20 wykazuje się poprzez przegląd CISO, raportowanie do zarządu, zatwierdzenia kierownictwa i szkolenia z cyberbezpieczeństwa. Article 23 staje się istotny, jeśli wykorzystanie podatności powoduje lub mogłoby spowodować poważne zakłócenie operacyjne, stratę finansową albo szkodę dla innych.

W przypadku DORA dowody dotyczące podatności i poprawek wspierają ramy zarządzania ryzykiem ICT, nadzór organu zarządzającego, strategię odporności, wykrywanie i klasyfikację incydentów, testowanie odporności oraz nadzór nad zewnętrznymi dostawcami usług ICT. Gdy dostawca ICT hostuje objęty problemem system albo nim zarządza, Articles 28 to 30 wymagają due diligence, zabezpieczeń umownych, praw audytu, wsparcia incydentowego i uwzględnienia wyjścia.

W przypadku GDPR te same dowody wspierają rozliczalność z Article 5 oraz profil ryzyka w obszarze bezpieczeństwa oczekiwany na podstawie Article 32. Jeśli podatność prowadzi do nieuprawnionego dostępu, zmiany, utraty lub ujawnienia danych osobowych, oś czasu podatności, zapisy poprawek, logi monitorowania i notatki z oceny naruszenia stają się kluczowe.

W przypadku COBIT 2019 i zapewnienia w stylu ISACA zarządzanie podatnościami ocenia się przez pryzmat bezpieczeństwa operacyjnego, monitorowania kontroli, umożliwiania zmian i rozliczalności ładu. Odniesienia zgodności przekrojowej w Zenith Blueprint wskazują COBIT 2019 DSS05.04 i BAI09.02, a także oczekiwania zapewnienia ITAF dotyczące zarządzania podatnościami, wdrażania poprawek i bezpiecznego zarządzania zmianami.

Wspierające normy ISO wzmacniają model operacyjny. ISO/IEC 27005:2022 wspiera ocenę ryzyka i postępowanie z ryzykiem. ISO/IEC 27035:2023 wspiera reagowanie na incydenty, gdy podatności zostaną wykorzystane. ISO/IEC 30111 wspiera procesy obsługi podatności. ISO/IEC 29147 wspiera ujawnianie podatności i komunikaty. ISO/IEC 27017 wspiera zarządzanie podatnościami w chmurze obliczeniowej. ISO 22301 wspiera planowanie ciągłości tam, gdzie podatności techniczne mogą zakłócić usługi biznesowe.

Jak różni audytorzy testują ten sam proces

Różni asesorzy stosują różne perspektywy. Dowody mogą być te same, ale pytania się zmieniają.

Polityka mówi, co powinno się wydarzyć. Dowody operacyjne pokazują, co się wydarzyło. Zapisy z przeglądów pokazują, że kierownictwo wiedziało, kwestionowało i podejmowało działania.

Częste powody, dla których zarządzanie poprawkami nie przechodzi audytu

Większość ustaleń nie wynika z braku skanera. Wynika z przerwanej identyfikowalności.

Inwentarz aktywów jest niekompletny.
Jeśli skaner znajduje aktywa, których brakuje w CMDB albo rejestrze aktywów, właścicielstwa i wpływu biznesowego nie można wiarygodnie ocenić. Podważa to zakres ISO 27001:2022, ocenę ryzyka i postępowanie z ryzykiem.

Podatności są śledzone wyłącznie w skanerze.
Panele skanerów nie są rejestrami ładu. Często brakuje w nich zatwierdzeń właściciela ryzyka, uzasadnienia wyjątku, referencji do zmian i kontekstu biznesowego.

Ustalenia krytyczne nie mają dowodów SLA.
Polityka może stwierdzać, że podatności krytyczne są usuwane w ciągu trzech dni. Pytanie audytowe brzmi, czy zapisy dowodzą, że tak się stało.

Wyjątki są nieformalne.
Systemy legacy, ograniczenia wynikające z niedostępności usług i opóźnienia dostawców się zdarzają. Jednak „nie mogliśmy tego załatać” musi stać się udokumentowanym wyjątkiem ze środkami kompensującymi, datą wygaśnięcia i zatwierdzeniem ryzyka szczątkowego.

Awaryjne wdrażanie poprawek omija zarządzanie zmianami.
Zmiany awaryjne nadal są zmianami. Jeśli brakuje dowodów zatwierdzenia, testowania lub wycofania zmian, audytorzy mogą uznać, że działania naprawcze stworzyły ryzyko operacyjne.

Systemy stron trzecich są niewidoczne.
W ramach NIS2 i DORA ryzyko dostawców oraz zewnętrznych dostawców usług ICT jest centralne. Jeśli dostawca łata platformę, nadal potrzebujesz dowodów, praw umownych, raportowania usługowego i ścieżek eskalacji.

Nikt nie przegląda trendów.
Powtarzające się podatności mogą wskazywać na słabe zarządzanie konfiguracją, niewystarczające praktyki bezpiecznego tworzenia kodu, niewspierane aktywa albo nieskuteczność dostawcy. Comiesięczny przegląd przekształca dane techniczne w działania z zakresu ładu.

Pakiet audytowy Clarysec dotyczący podatności

Na potrzeby zbliżającego się przeglądu gotowości ISO 27001:2022, NIS2 albo DORA Clarysec pomaga organizacjom przygotować pakiet audytowy zarządzania podatnościami i poprawkami obejmujący:

• Politykę zarządzania podatnościami i poprawkami, w tym zakres, role, częstotliwość skanowania, SLA dla poprawek i zasady wyjątków
• Wyciąg z inwentarza aktywów pokazujący systemy w zakresie, właścicieli, krytyczność i ekspozycję
• Najnowsze wewnętrzne i zewnętrzne raporty ze skanowania podatności
• Centralny rejestr zarządzania podatnościami z pozycjami otwartymi, zamkniętymi i wyjątkami
• Rejestry poprawek pokazujące urządzenie, aktualizację, datę wdrożenia poprawki i przyczyny opóźnień
• Zapisy zmian dla wybranych podatności krytycznych i wysokich
• Dowody ponownego skanowania albo walidacji po działaniach naprawczych
• Zatwierdzenia wyjątków i ryzyka szczątkowego dla systemów z opóźnionym wdrożeniem poprawek lub niemożliwych do załatania
• Proces monitorowania komunikatów bezpieczeństwa dla dostawców, bibliotek i usług w chmurze obliczeniowej
• Comiesięczne protokoły przeglądów CISO lub kierownictwa
• Mapowanie przekrojowe do obowiązków ISO 27001:2022, NIS2, DORA, GDPR i COBIT 2019
• Wyniki audytu wewnętrznego albo weryfikacji kontroli technicznych

W Zenith Blueprint, w fazie „Audyt, przegląd i doskonalenie”, krok 24, Clarysec podkreśla identyfikowalność między Deklaracją stosowania, rejestrem ryzyk i planem postępowania z ryzykiem:

Twoja SoA powinna być spójna z Rejestrem ryzyk i Planem postępowania z ryzykiem. Sprawdź dwukrotnie, czy każda kontrola wybrana jako sposób postępowania z ryzykiem jest oznaczona w SoA jako „Applicable”.

Jest to szczególnie ważne dla zarządzania podatnościami. Jeśli środek kontrolny 8.8 ma zastosowanie, pakiet audytowy powinien dowodzić nie tylko tego, że skanowanie się odbywa, lecz także że ustalenia są zarządzane poprzez postępowanie z ryzykiem i ciągłe doskonalenie.

30-dniowy sprint gotowości

Jeśli audyt jest blisko, nie zaczynaj od przepisywania wszystkiego. Zacznij od szybkiego zbudowania dowodów.

Ten sprint nie wyeliminuje całego długu technicznego. Zmieni rozmowę audytową. Zamiast bronić chaotycznego eksportu ze skanera, możesz pokazać nadzorowany proces z właścicielami, terminami, działaniami, decyzjami i nadzorem.

Przejdź od skanowania do możliwych do obrony dowodów

Gotowość do audytu zarządzania podatnościami i poprawkami nie polega na udowodnieniu, że nie masz podatności. Polega na udowodnieniu, że potrafisz je znaleźć, zrozumieć, priorytetyzować, naprawiać, kontrolować wyjątki i wykazywać nadzór.

Zenith Blueprint, Zenith Controls, Polityka zarządzania podatnościami i poprawkami, Polityka zarządzania podatnościami i poprawkami dla MŚP, Polityka audytu i monitorowania zgodności oraz Polityka audytu i monitorowania zgodności dla MŚP Clarysec zapewniają strukturę do zbudowania takiego procesu dowodowego.

Jeśli Twoja organizacja przygotowuje się do certyfikacji ISO 27001:2022, gotowości do NIS2, cyfrowej odporności operacyjnej DORA, due diligence klienta albo audytu wewnętrznego, zacznij od jednego pytania:

Czy każdą podatność krytyczną można prześledzić od skanowania do zamknięcia?

Jeśli odpowiedź brzmi „nie”, Clarysec może pomóc zbudować rejestr, zestaw polityk, mapowanie zgodności przekrojowej, pakiet przeglądu zarządzania i gotowy do audytu proces dowodowy, który przekształca skanowanie techniczne w możliwy do obrony ład.