CVD dla NIS2 i DORA: mapa dowodów ISO 27001

O 08:17 we wtorek skrzynka bezpieczeństwa otrzymuje wiadomość od niezależnego badacza. Temat jest spokojny, niemal uprzejmy: „Potencjalne przejęcie konta w portalu klienta”. Treść jest mniej komfortowa. Badacz twierdzi, że podatność łańcuchowa w aplikacji SaaS pozwala jednemu tenantowi uzyskać dostęp do rejestrów faktur innego tenanta. Do wiadomości dołączono proof of concept zaszyfrowany publicznym kluczem PGP organizacji.

Dla Marii, nowej CISO w FinanTechSaaS, moment nie mógł być gorszy. Jej firma właśnie podpisała duży kontrakt z czołowym bankiem z UE. Zespół klienta prowadzący due diligence poprosił już o „Politykę skoordynowanego ujawniania podatności” oraz dowody jej wdrożenia, wprost odwołując się do NIS2 i DORA. Firma ma adres e-mail security@, ale monitoruje go jeden programista. Nie ma formalnego rejestru zgłoszeń, zdefiniowanego SLA dla weryfikacji, ścieżki eskalacji do kierownictwa ani ścieżki audytu.

Uruchamiają się jednocześnie trzy zegary.

Pierwszy zegar jest operacyjny. Czy podatność jest rzeczywista? Czy można ją wykorzystać w środowisku produkcyjnym? Czy ktoś aktywnie jej nadużywa?

Drugi zegar jest regulacyjny. Jeśli doszło do ekspozycji danych klientów, rozpoczyna się ocena naruszenia zgodnie z GDPR. Jeśli naruszono sposób świadczenia usługi dla podmiotu kluczowego lub ważnego w rozumieniu NIS2, mogą zostać spełnione progi zgłaszania incydentów. Jeśli firma jest podmiotem finansowym albo dostawcą ICT wspierającym usługi finansowe, mogą mieć zastosowanie zasady DORA dotyczące zarządzania incydentami, klasyfikacji, eskalacji i komunikacji z klientami.

Trzeci zegar dotyczy dowodów. Sześć miesięcy później audytor ISO/IEC 27001:2022, organ nadzoru sektora finansowego, zespół zapewnienia po stronie klienta albo komitet audytu wewnętrznego może zapytać: „Pokażcie, jak obsłużyliście tę podatność”.

W tym miejscu wiele organizacji odkrywa, że skoordynowane ujawnianie podatności nie jest tylko skrzynką bezpieczeństwa. To system ładu zarządczego. Wymaga właściciela polityki, publicznego kanału zgłoszeń, procesu wstępnej kwalifikacji, SLA dla działań naprawczych, eskalacji do dostawców, logiki decyzji incydentowych, przeglądu prywatności, raportowania zarządczego oraz dowodów możliwych do obrony przed audytorem.

Clarysec traktuje CVD jako zintegrowany wzorzec zabezpieczeń, a nie samodzielną skrzynkę odbiorczą. W Zenith Blueprint: 30-etapowej mapie drogowej audytora Zenith Blueprint obsługa podatności pojawia się w fazie działania zabezpieczeń, krok 19: Zabezpieczenia techniczne I, gdzie wskazówka jest jednoznaczna: organizacje nie powinny biernie archiwizować ustaleń dotyczących podatności, lecz poddawać je wstępnej kwalifikacji, przypisywać właścicieli i śledzić je do zamknięcia. Ta sama zasada dotyczy zewnętrznych ujawnień. Jeśli ktoś informuje, w jaki sposób usługa może zawieść, właściwe pytanie brzmi: czy potraficie wykazać, że zgłoszenie zostało odebrane, ocenione, spriorytetyzowane, naprawione, zakomunikowane i wykorzystane do doskonalenia?

Dlaczego CVD jest obecnie zagadnieniem na poziomie zarządu w ramach NIS2 i DORA

Przez lata organizacje świadome bezpieczeństwa zachęcały etycznych hakerów do zgłaszania podatności, ponieważ była to dobra praktyka. W ramach NIS2 i DORA praktyka ta stała się elementem regulowanej odporności cyfrowej.

NIS2 ma zastosowanie do wielu średnich i większych podmiotów w sektorach o wysokiej krytyczności oraz innych sektorach krytycznych, w tym do dostawców infrastruktury cyfrowej, dostawców usług chmurowych, dostawców usług centrów danych, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa oraz niektórych dostawców cyfrowych, takich jak internetowe platformy handlowe, wyszukiwarki internetowe i platformy społecznościowe. Może również mieć zastosowanie niezależnie od wielkości do takich kategorii jak dostawcy usług zaufania, dostawcy usług DNS, rejestry TLD oraz dostawcy publicznych sieci lub usług łączności elektronicznej.

NIS2 Article 21 wymaga od podmiotów kluczowych i ważnych wdrożenia odpowiednich i proporcjonalnych technicznych, operacyjnych oraz organizacyjnych środków zarządzania ryzykiem cyberbezpieczeństwa, z zastosowaniem podejścia obejmującego wszystkie zagrożenia. Jednym z minimalnych obszarów jest bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu sieci oraz systemów informatycznych, w tym obsługa i ujawnianie podatności. Ten sam poziom bazowy obejmuje również obsługę incydentów, bezpieczeństwo łańcucha dostaw, ciągłość działania, kontrolę dostępu, zarządzanie aktywami, szkolenia, kryptografię oraz procedury oceny skuteczności zabezpieczeń.

NIS2 Article 20 wprost wskazuje również odpowiedzialność kierownictwa. Organy zarządzające muszą zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorować ich wdrożenie i uczestniczyć w szkoleniach. Dla programu CVD oznacza to, że zarząd lub kierownictwo wyższego szczebla powinno rozumieć kanał zgłoszeń, zespół reagowania na podatności, terminy weryfikacji, oczekiwania dotyczące działań naprawczych, zależności od dostawców oraz przesłanki zgłaszania incydentów.

DORA tworzy od 17 stycznia 2025 r. sektorowy reżim dla podmiotów finansowych. Obejmuje zarządzanie ryzykiem ICT, zgłaszanie incydentów związanych z ICT, testowanie cyfrowej odporności operacyjnej, wymianę informacji, ryzyko związane z zewnętrznymi dostawcami ICT, wymogi umowne, nadzór nad krytycznymi zewnętrznymi dostawcami ICT oraz współpracę nadzorczą. W przypadku podmiotów finansowych objętych DORA, DORA zasadniczo ma pierwszeństwo przed NIS2 w zakresie zarządzania ryzykiem ICT i zgłaszania incydentów, ponieważ jest sektorowym aktem prawnym Unii. Wymóg praktyczny pozostaje jednak taki sam: podmioty finansowe i dostawcy ICT świadczący dla nich usługi muszą prowadzić ustrukturyzowany, udokumentowany i możliwy do przetestowania proces identyfikacji, analizy, klasyfikacji, eskalacji, naprawy oraz wyciągania wniosków ze słabości ICT.

Zgłoszenie podatności może rozpocząć się jako ustalenie techniczne, stać się zdarzeniem bezpieczeństwa informacji, zostać eskalowane do incydentu, uruchomić ocenę naruszenia ochrony danych osobowych zgodnie z GDPR, wymagać działania dostawcy, a następnie pojawić się w Deklaracji stosowania ISO/IEC 27001:2022. Dlatego CVD należy zaprojektować jako jeden model operacyjny obejmujący bezpieczeństwo, zgodność, inżynierię, dział prawny, prywatność, zakupy i kierownictwo.

Fundament ISO 27001: od ujawnienia do dowodów SZBI

ISO/IEC 27001:2022 daje CISO i liderom zgodności system zarządzania, który czyni CVD możliwym do audytu.

Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała kwestie wewnętrzne i zewnętrzne, wymagania stron zainteresowanych, granice SZBI oraz zależności z innymi organizacjami. To tutaj NIS2, DORA, GDPR, umowy z klientami, obowiązki dostawców i zobowiązania dotyczące ujawniania podatności wchodzą do SZBI.

Klauzule 5.1 do 5.3 tworzą odpowiedzialność przywództwa. Najwyższe kierownictwo musi zapewnić zgodność bezpieczeństwa informacji z kierunkiem strategicznym, zapewnić zasoby, przypisać odpowiedzialności i dopilnować, aby SZBI osiągał zamierzone wyniki. Dla CVD oznacza to powołanie zespołu reagowania na podatności, zdefiniowanie uprawnień do akceptacji ryzyka rezydualnego oraz eskalowanie podatności o dużym wpływie do kierownictwa.

Klauzule 6.1.1 do 6.1.3 stanowią mechanizm ryzyka. Organizacja musi zdefiniować kryteria ryzyka, ocenić ryzyka bezpieczeństwa informacji, przypisać właścicieli ryzyka, wybrać warianty postępowania z ryzykiem, porównać zabezpieczenia z Załącznikiem A, przygotować Deklarację stosowania oraz uzyskać zatwierdzenie ryzyka rezydualnego. Klauzule 8.1 do 8.3 wymagają następnie kontroli operacyjnej, planowanych zmian, kontroli procesów dostarczanych z zewnątrz, ocen ryzyka w zaplanowanych odstępach czasu lub po istotnych zmianach oraz dowodów wyników postępowania z ryzykiem.

W Zenith Blueprint, w fazie zarządzania ryzykiem, krok 13, Deklaracja stosowania jest opisana jako coś więcej niż arkusz zgodności:

„SoA jest w praktyce dokumentem pomostowym: łączy ocenę ryzyka/postępowanie z ryzykiem z rzeczywistymi środkami kontrolnymi, które posiadacie”.
Źródło: Zenith Blueprint: 30-etapowa mapa drogowa audytora, faza zarządzania ryzykiem, krok 13: Planowanie postępowania z ryzykiem i Deklaracja stosowania (SoA) Zenith Blueprint

W przypadku skoordynowanego ujawniania podatności SoA powinna łączyć obowiązki regulacyjne, ryzyko biznesowe, zabezpieczenia z Załącznika A, zapisy polityki i dowody operacyjne.

Celem nie jest tworzenie równoległych silosów zgodności. Polityka CVD powinna być kontrolowanym procesem SZBI, który jednocześnie wspiera certyfikację ISO/IEC 27001:2022, zgodność z NIS2, gotowość do DORA, zapewnienie dla klientów i operacje bezpieczeństwa.

Bazowy zakres polityki: co musi mówić polityka CVD

Pierwszym widocznym zabezpieczeniem jest publiczny kanał ujawniania. Badacze, klienci, dostawcy i partnerzy muszą wiedzieć, gdzie zgłaszać podatności oraz jak chronić wrażliwe dowody.

Polityka skoordynowanego ujawniania podatności Clarysec Polityka skoordynowanego ujawniania podatności zapewnia bazę dla przedsiębiorstwa:

„Publiczne kanały ujawniania: Organizacja utrzymuje jednoznaczny kanał zgłaszania podatności, taki jak dedykowany kontaktowy adres e-mail do spraw bezpieczeństwa (na przykład security@company.com) albo formularz internetowy. Informacja ta jest publikowana na stronie bezpieczeństwa w witrynie firmowej wraz z publicznym kluczem PGP organizacji, aby umożliwić szyfrowane zgłoszenia”.
Źródło: Polityka skoordynowanego ujawniania podatności, wymagania wdrożeniowe, klauzula 6.1

Ta klauzula rozwiązuje częstą słabość audytową. Wiele organizacji twierdzi, że przyjmuje zgłoszenia, ale ścieżka zgłoszeniowa jest ukryta, nieszyfrowana albo przypisana niewłaściwemu zespołowi. Dojrzały kanał jest publiczny, bezpieczny, monitorowany i przypisany do odpowiedzialnej funkcji.

Kolejnym zabezpieczeniem jest dyscyplina odpowiedzi. Krytyczne zgłoszenie, po którym następuje cisza, tworzy ryzyko ujawnienia, ryzyko reputacyjne i ryzyko wykorzystania. Polityka skoordynowanego ujawniania podatności ustanawia konkretne oczekiwania dotyczące potwierdzenia i weryfikacji:

„Triage i potwierdzenie: Po otrzymaniu zgłoszenia VRT rejestruje je i wysyła potwierdzenie do zgłaszającego w ciągu 2 dni roboczych, przypisując numer referencyjny do śledzenia. VRT przeprowadza wstępną ocenę wagi, na przykład z użyciem punktacji CVSS, oraz weryfikuje problem, w tym przy wsparciu zespołów IT i rozwoju, gdy jest to konieczne, w docelowym terminie 5 dni roboczych. Podatności krytyczne, takie jak umożliwiające zdalne wykonanie kodu lub poważne naruszenie ochrony danych, są obsługiwane w trybie przyspieszonym”.
Źródło: Polityka skoordynowanego ujawniania podatności, wymagania wdrożeniowe, klauzula 6.4

Takie brzmienie tworzy natychmiastowe punkty dowodowe: czas otrzymania, czas potwierdzenia, numer referencyjny, wstępną wagę, wynik weryfikacji oraz decyzję o obsłudze przyspieszonej.

Dla MŚP Clarysec stosuje tę samą logikę przy proporcjonalnym wdrożeniu. Polityka wymagań bezpieczeństwa aplikacji dla MŚP Polityka wymagań bezpieczeństwa aplikacji — MŚP wymaga od organizacji, aby:

„określały obowiązki dotyczące ujawniania podatności, czasów reakcji i wdrażania poprawek”.
Źródło: Polityka wymagań bezpieczeństwa aplikacji dla MŚP, wymagania ładu zarządczego, klauzula 5.3.2

Nie trzeba posiadać dużego zespołu bezpieczeństwa produktu, aby być rozliczalnym. Potrzebne są jednoznaczne obowiązki, realistyczne terminy, wskazani właściciele oraz dowody, że proces działa.

Proces przyjmowania zgłoszeń CVD: od e-maila badacza do zapisu decyzji

Dobry proces przyjmowania zgłoszeń jest na tyle prosty, aby działał pod presją, i na tyle kompletny, aby spełnić oczekiwania audytora. Powinien zaczynać się od dedykowanego kanału, takiego jak security@[company], formularz internetowy albo opublikowany plik security.txt. Ścieżka zgłoszeniowa powinna umożliwiać przekazanie zaszyfrowanych dowodów, wskazanie produktu lub punktu końcowego, kroków odtworzenia, danych kontaktowych zgłaszającego, preferowanego terminu ujawnienia oraz wszelkich informacji o ekspozycji danych lub aktywnym wykorzystaniu.

Po otrzymaniu zgłoszenia zespół reagowania na podatności powinien utworzyć zapis w narzędziu GRC, systemie zgłoszeniowym, systemie zarządzania podatnościami albo kontrolowanym rejestrze. Samo narzędzie ma mniejsze znaczenie niż spójność i jakość dowodów.

Następnie proces obsługi powinien przejść przez siedem kroków operacyjnych.

1. Przyjęcie zgłoszenia: zgłoszenie jest otrzymywane przez publiczny kanał i rejestrowane automatycznie albo ręcznie.
2. Potwierdzenie: VRT odpowiada w ciągu 2 dni roboczych i przypisuje numer referencyjny do śledzenia.
3. Weryfikacja: zespół techniczny odtwarza problem, potwierdza dotknięte systemy i przeprowadza wstępną ocenę wagi.
4. Ocena zdarzenia: VRT ustala, czy podatność jest wyłącznie słabością, zdarzeniem bezpieczeństwa informacji czy incydentem.
5. Eskalacja: problemy o wysokiej lub krytycznej wadze są kierowane odpowiednio do właścicieli systemów, CISO, funkcji prywatności, działu prawnego, dostawców i kierownictwa.
6. Działania naprawcze: odpowiedzialny zespół wdraża poprawkę, ograniczenie ryzyka, zabezpieczenie kompensujące albo tymczasowy środek ograniczający.
7. Zamknięcie: VRT weryfikuje poprawkę, komunikuje się ze zgłaszającym, aktualizuje plik dowodowy i zapisuje wnioski.

Clarysec mapuje ten krok operacyjny do zabezpieczenia ISO/IEC 27002:2022 A.5.25, Ocena i decyzja dotycząca zdarzeń bezpieczeństwa informacji, oraz zabezpieczenia A.8.8, Zarządzanie podatnościami technicznymi, poprzez Zenith Controls: przewodnik po zgodności krzyżowej Zenith Controls. Dla A.5.25 Zenith Controls wyjaśnia, że ocena zdarzeń jest funkcją wstępnej kwalifikacji pomiędzy surowymi alertami z monitorowania a formalną obsługą incydentów, wykorzystującą logi, progi i kryteria decyzyjne do ustalenia eskalacji. Dla A.8.8 Zenith Controls łączy zarządzanie podatnościami technicznymi z ochroną przed złośliwym oprogramowaniem, zarządzaniem konfiguracją, zarządzaniem zmianami, bezpieczeństwem punktów końcowych, informacjami o zagrożeniach, monitorowaniem, bezpiecznym rozwojem oprogramowania, oceną zdarzeń i reagowaniem na incydenty.

Jeden fragment Zenith Controls jest szczególnie użyteczny, gdy podejrzewa się aktywne wykorzystanie:

„Informacje o zagrożeniach wskazują, które podatności są aktywnie wykorzystywane, ukierunkowując priorytetyzację poprawek”.
Źródło: Zenith Controls: przewodnik po zgodności krzyżowej, ISO/IEC 27002:2022 zabezpieczenie 8.8, powiązanie z zabezpieczeniem 5.7 Informacje o zagrożeniach Zenith Controls

To istotny punkt ładu zarządczego. Waga to nie tylko CVSS. Podatność ze średnią punktacją, aktywnie wykorzystywana przeciwko danemu sektorowi, może mieć wyższy priorytet niż teoretyczny problem krytyczny w nieeksponowanym systemie testowym.

Kiedy podatność staje się incydentem

Nie każde zgłoszenie podatności jest incydentem. Brakujący nagłówek bezpieczeństwa w środowisku stagingowym to nie to samo co wykorzystane obejście autoryzacji ujawniające faktury klientów. Każde wiarygodne zgłoszenie podatności powinno jednak przejść przez bramkę decyzji incydentowej.

NIS2 Article 23 wymaga od podmiotów kluczowych i ważnych powiadomienia CSIRT lub właściwego organu bez zbędnej zwłoki o incydentach, które znacząco wpływają na świadczenie usług. Incydent znaczący to taki, który spowodował lub może spowodować poważne zakłócenie operacyjne albo stratę finansową, albo który dotknął lub może dotknąć inne podmioty, powodując znaczną szkodę materialną lub niematerialną. Sekwencja raportowania obejmuje wczesne ostrzeżenie w ciągu 24 godzin od uzyskania świadomości, zgłoszenie incydentu w ciągu 72 godzin, raporty pośrednie na żądanie oraz raport końcowy w ciągu jednego miesiąca od zgłoszenia 72-godzinnego.

DORA Articles 17 to 20 wymagają od podmiotów finansowych wykrywania, zarządzania, rejestrowania, klasyfikowania, eskalowania, zgłaszania i komunikowania incydentów związanych z ICT oraz istotnych cyberzagrożeń. Poważne incydenty związane z ICT muszą być eskalowane do kierownictwa wyższego szczebla i organu zarządzającego. Komunikacja z klientami może być wymagana, gdy dotknięte są interesy finansowe.

Dla MŚP kultura zgłaszania musi być równie jednoznaczna. Polityka reagowania na incydenty dla MŚP Clarysec Polityka reagowania na incydenty — MŚP stanowi:

„Personel musi zgłaszać każdą podejrzaną aktywność lub potwierdzony incydent na adres incident@[company] albo ustnie Dyrektorowi Generalnemu lub dostawcy IT”.
Źródło: Polityka reagowania na incydenty dla MŚP, wymagania dotyczące wdrożenia polityki, klauzula 6.2.1

W Zenith Blueprint, faza działania zabezpieczeń, krok 16: Zabezpieczenia osobowe II, zasada jest jeszcze prostsza:

„W razie wątpliwości zgłoś”.
Źródło: Zenith Blueprint: 30-etapowa mapa drogowa audytora, faza działania zabezpieczeń, krok 16: Zabezpieczenia osobowe II (A.6.5 do A.6.8)

Ta zasada powinna dotyczyć programistów, zespołów wsparcia, menedżerów dostawców, osób odpowiedzialnych za prywatność, kadry kierowniczej i dostawców outsourcingowych. Podatność, która może wpływać na poufność, integralność, dostępność, zaufanie klientów, raportowanie regulacyjne lub operacje finansowe, powinna być zarejestrowana i oceniona, a nie obsługiwana nieformalnie na czacie.

Działania naprawcze, wdrażanie poprawek i zabezpieczenia kompensujące

Po weryfikacji podatności należy ją objąć postępowaniem z ryzykiem. Postępowanie powinno być oparte na ryzyku, poparte dowodami i ograniczone w czasie.

Polityka skoordynowanego ujawniania podatności ustanawia oczekiwanie dla przedsiębiorstwa:

„Plan działań naprawczych: Dla wszystkich potwierdzonych podatności opracowuje się plan działań naprawczych lub ograniczających. Wdrożenie poprawki jest priorytetyzowane na podstawie wagi. Na przykład podatności krytyczne są naprawiane lub ograniczane w ciągu 14 dni, jeśli jest to wykonalne, albo szybciej, gdy wykryto aktywne wykorzystanie, natomiast problemy o niższej wadze są rozwiązywane w rozsądnym terminie. Gdy pełna poprawka jest opóźniona, wdraża się kontrole kompensujące albo tymczasowe środki ograniczające, takie jak wyłączenie podatnej funkcjonalności lub zwiększenie monitorowania”.
Źródło: Polityka skoordynowanego ujawniania podatności, wymagania wdrożeniowe, klauzula 6.6

Dla dyscypliny wdrażania poprawek w MŚP Polityka zarządzania podatnościami i poprawkami dla MŚP Polityka zarządzania podatnościami i poprawkami — MŚP stanowi:

„Poprawki krytyczne muszą być wdrażane w ciągu 3 dni od wydania, w szczególności dla systemów dostępnych z Internetu”.
Źródło: Polityka zarządzania podatnościami i poprawkami dla MŚP, wymagania dotyczące wdrożenia polityki, klauzula 6.1.1

Te terminy nie są sprzeczne. Poprawka dostawcy dla systemu dostępnego z Internetu może wymagać bardzo szybkiego wdrożenia. Podatność produktu wymagająca zmian w kodzie, testów regresji, koordynacji z klientami i etapowego wydania może wymagać planu działań naprawczych z tymczasowymi ograniczeniami. Kluczowe jest to, aby decyzja była udokumentowana, miała właściciela ryzyka i była zatwierdzona tam, gdzie pozostaje ryzyko rezydualne.

Praktyczny przebieg przypadku wygląda następująco:

1. Badacz zgłasza obejście autoryzacji w API rozliczeń klienta.
2. VRT rejestruje CVD-2026-014 ze znacznikiem czasu i potwierdza zgłoszenie w ciągu 2 dni roboczych.
3. Bezpieczeństwo produktu weryfikuje błąd w ciągu 24 godzin i przypisuje wysoką wagę ze względu na dostęp między tenantami do danych.
4. Funkcja prywatności przeprowadza ocenę naruszenia zgodnie z GDPR, ponieważ rejestry faktur mogą zawierać dane osobowe.
5. Menedżer incydentu otwiera ocenę zdarzenia zgodnie z zabezpieczeniem ISO/IEC 27002:2022 A.5.25.
6. Właściciel systemu wyłącza podatny punkt końcowy za pomocą tymczasowej flagi funkcji.
7. Inżynieria tworzy poprawkę awaryjną zgodnie z zabezpieczeniem ISO/IEC 27002:2022 A.8.32, Zarządzanie zmianami.
8. Dodawane są reguły monitorowania wskaźników wykorzystania, powiązane z A.8.15, Rejestrowanie, oraz A.8.16, Działania monitorujące.
9. CISO informuje kierownictwo wyższego szczebla, ponieważ problem wiąże się z wysokim ryzykiem.
10. VRT koordynuje z badaczem ponowne testowanie i termin ujawnienia.
11. Właściciel ryzyka zatwierdza zamknięcie dopiero po testach weryfikacyjnych i przeglądzie wpływu na klientów.
12. Aktualizowane są SoA, rejestr ryzyk, zgłoszenie, logi, powiadomienie kierownictwa i wnioski.

To różnica między „wdrożyliśmy poprawkę” a „potrafimy wykazać, że zarządzaliśmy tym w sposób kontrolowany”.

Zależności od dostawców i chmury obliczeniowej: ukryty punkt awarii

Wiele niepowodzeń CVD to w rzeczywistości niepowodzenia dostawców. Podatność może dotyczyć komponentu SaaS, usługi chmury obliczeniowej, dostawcy zarządzanych usług bezpieczeństwa, bramki płatniczej, brokera uwierzytelniania, biblioteki open source, zespołu rozwoju oprogramowania w modelu outsourcingowym albo podwykonawcy.

NIS2 Article 21 wymaga bezpieczeństwa łańcucha dostaw, w tym relacji z bezpośrednimi dostawcami i usługodawcami. Środki dotyczące łańcucha dostaw powinny uwzględniać podatności dostawców, jakość produktów, praktyki cyberbezpieczeństwa i procedury bezpiecznego rozwoju oprogramowania.

DORA Articles 28 to 30 idą dalej w przypadku podmiotów finansowych. Wymagają, aby ryzyko związane z zewnętrznymi dostawcami ICT było zarządzane jako część ram ryzyka ICT, z rejestrami umów na usługi ICT, rozróżnieniem funkcji krytycznych lub ważnych, due diligence przed zawarciem umowy, umownymi wymaganiami bezpieczeństwa, wsparciem incydentowym, współpracą z organami, prawem do audytu, prawami do rozwiązania umowy i strategiami wyjścia. Podmioty finansowe pozostają w pełni odpowiedzialne za zgodność z DORA, nawet gdy korzystają z zewnętrznych dostawców ICT.

Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP Clarysec Polityka bezpieczeństwa dostawców i stron trzecich — MŚP zawiera prostą regułę eskalacji:

„Musi natychmiast powiadomić Dyrektora Generalnego o każdym naruszeniu bezpieczeństwa, zmianie lub incydencie”.
Źródło: Polityka bezpieczeństwa dostawców i stron trzecich dla MŚP, role i odpowiedzialności, klauzula 4.4.3

W przypadku umów z dostawcami na poziomie przedsiębiorstwa Zenith Blueprint, faza działania zabezpieczeń, krok 23, zaleca uwzględnianie obowiązków dotyczących poufności, odpowiedzialności za kontrolę dostępu, środków technicznych i organizacyjnych, terminów zgłaszania incydentów, prawa do audytu, kontroli podwykonawców oraz postanowień dotyczących zakończenia umowy. Stwierdza:

„Znaczenie ma to, że one istnieją oraz że są rozumiane i zaakceptowane przez obie strony”.
Źródło: Zenith Blueprint: 30-etapowa mapa drogowa audytora, faza działania zabezpieczeń, krok 23: Zabezpieczenia organizacyjne (5.19 do 5.37)

Gotowość dostawców w zakresie CVD powinna odpowiadać na następujące pytania:

• Czy dostawca publikuje kanał zgłaszania podatności?
• Czy terminy powiadamiania o podatnościach są zdefiniowane w umowie?
• Czy krytyczne podatności dostawcy są zgłaszane bez zbędnej zwłoki?
• Czy słabości wpływające na klientów są powiązane z obowiązkami wsparcia incydentowego?
• Czy dostawca może dostarczyć dowody działań naprawczych albo komunikaty bezpieczeństwa?
• Czy obowiązki dotyczące podatności są przenoszone na podwykonawców?
• Czy istnieje strategia wyjścia, jeśli działania naprawcze są niewystarczające?

To miejsce, w którym zbiegają się NIS2, DORA i ISO/IEC 27001:2022. Zarządzanie podatnościami dostawców nie jest checkboxem zakupowym. Jest częścią odporności operacyjnej.

Mapowanie dowodów dla ISO 27001, NIS2, DORA, GDPR i COBIT

Najsilniejsze programy CVD są projektowane od strony dowodów. Zakładają, że każde znaczące zgłoszenie może później zostać poddane przeglądowi przez audyt wewnętrzny, audytorów certyfikacyjnych, organy regulacyjne, klientów, ubezpieczycieli albo komitet ds. ryzyka Rady Dyrektorów.

Polityka audytu i monitorowania zgodności dla MŚP Clarysec Polityka audytu i monitorowania zgodności — MŚP wychwytuje szczegół, który umyka wielu zespołom:

„Metadane (np. kto je zebrał, kiedy i z którego systemu) muszą być udokumentowane”.
Źródło: Polityka audytu i monitorowania zgodności dla MŚP, wymagania dotyczące wdrożenia polityki, klauzula 6.2.3

Zrzut ekranu z poprawionego serwera jest słabym dowodem, jeśli nikt nie wie, kto go wykonał, kiedy, z jakiego systemu i jak odnosi się do podatności. Zgłoszenie ze znacznikami czasu, wynikiem skanera, pull requestem, zatwierdzeniem zmiany, logami wdrożenia, zapytaniem monitorującym, potwierdzeniem ponownego testu i metadanymi jest znacznie mocniejsze.

Bardziej szczegółowa macierz identyfikowalności pomaga podczas due diligence klienta i audytu wewnętrznego.

Różni audytorzy będą testować ten sam proces z różnych perspektyw.

Audytor ISO/IEC 27001:2022 zacznie od SZBI. Zapyta, czy obowiązki dotyczące ujawniania podatności są uwzględnione w wymaganiach stron zainteresowanych, czy ryzyka są oceniane spójnie, czy zabezpieczenia znajdują się w SoA, czy istnieją dowody operacyjne oraz czy kierownictwo przegląda trendy i zaległe pozycje.

Recenzent DORA lub sektora usług finansowych skupi się na odporności operacyjnej. Zbada integrację ryzyka ICT, klasyfikację incydentów, eskalację do kierownictwa wyższego szczebla, komunikację z klientem, zależności od stron trzecich, testowanie i wnioski. Jeśli podatność wpływa na funkcję krytyczną lub ważną, będzie oczekiwać ścisłego powiązania między zgłoszeniem technicznym, wpływem biznesowym, konsekwencjami dla ciągłości działania i obowiązkami dostawcy.

Recenzent GDPR skupi się na danych osobowych. Czy dane osobowe były objęte problemem? Czy doszło do nieuprawnionego dostępu, utraty, zmiany lub ujawnienia? Czy role administratora i podmiotu przetwarzającego były jasne? Czy oceniono próg naruszenia? Czy istotne były środki bezpieczeństwa, takie jak szyfrowanie, kontrola dostępu, rejestrowanie i minimalizacja?

Audytor COBIT 2019 lub ISACA skupi się na ładzie zarządczym, odpowiedzialności, skuteczności działania i zapewnieniu. Będzie szukać zdefiniowanego właściciela procesu, metryk, eskalacji, celów kontroli, nadzoru kierownictwa i śledzenia wyjątków. Zaległa podatność krytyczna nie jest wyłącznie problemem technicznym. Jest problemem ładu zarządczego, chyba że została formalnie eskalowana i objęta akceptacją ryzyka.

Asesor zorientowany na NIST będzie myślał w kategoriach Identyfikacji, Ochrony, Wykrywania, Reagowania i Odtwarzania. Będzie oczekiwać własności aktywów, identyfikacji podatności, priorytetyzacji, zmiany ochronnej, wykrywania wykorzystania, koordynacji reakcji i walidacji odtworzenia.

Zaletą zintegrowanego modelu CVD jest to, że ten sam rdzeń dowodowy może wspierać wszystkie te przeglądy.

Miesięczna pętla kontrolna: metryki użyteczne dla kierownictwa

CVD nie kończy się w momencie zamknięcia zgłoszenia. Polityka skoordynowanego ujawniania podatności wymaga bieżącego przeglądu rejestru:

„VRT utrzymuje rejestr ujawnień podatności śledzący każde zgłoszenie od otrzymania do zamknięcia. Rejestr jest przeglądany co miesiąc, aby zapewnić terminowy postęp otwartych pozycji. Pozycje zaległe są eskalowane”.
Źródło: Polityka skoordynowanego ujawniania podatności, monitorowanie i audyt, klauzula 9.1

Ten comiesięczny przegląd zamienia ujawnianie podatności w ład zarządczy gotowy do prezentacji zarządowi. Kierownictwo nie potrzebuje każdego szczegółu technicznego. Potrzebuje trendu, ekspozycji, odpowiedzialności i zaległego ryzyka.

W dojrzałym wdrożeniu Clarysec ten comiesięczny przegląd rejestru zasila rejestr ryzyk, Deklarację stosowania, backlog bezpiecznego rozwoju, przeglądy dostawców, wnioski z incydentów, plan audytu wewnętrznego i pakiet raportowania zarządczego.

Zbuduj proces, zanim nadejdzie poważne zgłoszenie

Najgorszym momentem na projektowanie skoordynowanego ujawniania podatności jest chwila po tym, jak badacz publicznie opublikował słabość albo krytyczny klient bankowy wstrzymał onboarding. NIS2, DORA, GDPR, ISO/IEC 27001:2022, oczekiwania odporności w stylu NIST oraz ład zarządczy COBIT 2019 wskazują ten sam kierunek: ujawnianie podatności musi być zaplanowane, mieć właściciela, być przetestowane, udokumentowane dowodowo i doskonalone.

Zacznij od tych pięciu działań:

1. Przyjmij lub dostosuj Politykę skoordynowanego ujawniania podatności.
2. Zbuduj proces przyjmowania zgłoszeń i wstępnej kwalifikacji z wykorzystaniem Zenith Blueprint, szczególnie kroku 13 dla identyfikowalności SoA, kroku 16 dla kultury zgłaszania, kroku 19 dla zarządzania podatnościami technicznymi oraz kroku 23 dla umów z dostawcami.
3. Zmapuj proces obsługi przez Zenith Controls, koncentrując się na zabezpieczeniach ISO/IEC 27002:2022 A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 i A.8.32.
4. Dodaj klauzule gotowe dla MŚP z Polityki reagowania na incydenty dla MŚP, Polityki zarządzania podatnościami i poprawkami dla MŚP, Polityki bezpieczeństwa dostawców i stron trzecich dla MŚP, Polityki wymagań bezpieczeństwa aplikacji dla MŚP oraz Polityki audytu i monitorowania zgodności dla MŚP, gdy znaczenie ma proporcjonalność.
5. Przeprowadź ćwiczenie tabletop symulujące zgłoszenie badacza dotyczące danych osobowych i komponentu hostowanego przez dostawcę, a następnie przetestuj potwierdzenie, wstępną kwalifikację, klasyfikację incydentu, wdrażanie poprawek, komunikację z klientem, pozyskanie dowodów i eskalację do kierownictwa.

Clarysec może pomóc przekształcić to w działającą politykę CVD, rejestr przyjmowania zgłoszeń, mapę dowodów ISO/IEC 27001:2022, drzewo decyzyjne NIS2 i DORA, model eskalacji do dostawców oraz pakiet zabezpieczeń gotowy do audytu. Cel jest prosty: gdy nadejdzie kolejne zgłoszenie podatności, zespół nie powinien improwizować. Powinien działać z pewnością, dowodami i kontrolą.