Umowy z dostawcami dla NIS2 z materiałem dowodowym ISO 27001

Jest poniedziałek, godzina 07:40. CISO platformy logistycznej działającej w chmurze otwiera wiadomość e-mail od dostawcy usług Managed Detection and Response (MDR). Komunikat jest krótki, ostrożny i niepokojący: dostawca wykrył podejrzany dostęp do środowiska wsparcia używanego przez kilku klientów. Szczegóły są ograniczone. Dostawca obiecuje aktualizację „tak szybko, jak będzie to praktycznie możliwe”.

O 08:15 menedżer ds. zgodności pyta, czy może to uruchomić obowiązki zgłoszeniowe wynikające z NIS2. O 08:40 dział zakupów szuka umowy. O 09:10 sekretarz zarządu oczekuje briefingu dotyczącego rozliczalności organu zarządzającego. O 10:00 dział prawny pyta, czy umowa obejmuje 24-godzinne powiadomienie, prawa audytu, kontrole podwykonawców, dostęp do dowodów, obowiązki w zakresie ciągłości działania, zwrot danych oraz postanowienia dotyczące usunięcia danych.

Nikt nie chce odkryć w trakcie aktywnego incydentu, że umowa z krytycznym dostawcą ogranicza się do sformułowania „rozsądne środki bezpieczeństwa”.

W tym miejscu klauzule umów z dostawcami dla NIS2 przestają być szablonem prawnym, a stają się zabezpieczeniami operacyjnymi. Dla podmiotów kluczowych i ważnych nadzór nad dostawcami jest obecnie elementem rozliczalności zarządu, dowodów dla organu nadzorczego, gotowości do reagowania na incydenty, zapewnienia dla klientów, zgodności w zakresie prywatności oraz planowania odporności. Podpisana umowa nie wystarcza. Organizacja musi wykazać, że ryzyka dostawców są identyfikowane, zatwierdzane, poddawane postępowaniu, monitorowane i udokumentowane dowodowo.

Podejście Clarysec opiera się na prostej zasadzie: jeżeli klauzuli dotyczącej dostawcy nie da się monitorować, udowodnić i przetestować, nie jest ona zabezpieczeniem.

Zenith Blueprint: 30-etapowa mapa drogowa audytora umieszcza relacje z dostawcami w fazie Kontrole w działaniu, w kroku 23, gdzie umowy, monitorowanie, onboarding, ponowna ocena i dowody audytowe są przekładane na praktyczne działania w SZBI. Zenith Controls: przewodnik po mapowaniu zgodności między ramami mapuje następnie zabezpieczenia ISO/IEC 27002:2022 dotyczące dostawców na NIS2, DORA, GDPR, NIST, COBIT 2019, wspierające normy ISO oraz metodyki audytu.

Rezultatem jest model nadzoru nad dostawcami, z którego mogą korzystać zakupy, dział prawny, bezpieczeństwo, prywatność i zarząd.

Dlaczego NIS2 przekształca umowy z dostawcami w zapisy dowodowe

NIS2 Article 20 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie oraz ponosiły odpowiedzialność za naruszenia. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, obejmujących m.in. analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne pozyskiwanie i utrzymanie, ocenę skuteczności, cyberhigienę, kryptografię, bezpieczeństwo zasobów ludzkich, kontrolę dostępu, zarządzanie aktywami oraz MFA tam, gdzie jest to właściwe.

Article 21(3) wprost wskazuje due diligence dostawców. Organizacje muszą uwzględniać podatności specyficzne dla bezpośrednich dostawców i dostawców usług, ogólną jakość produktów i praktyk cyberbezpieczeństwa oraz procedury bezpiecznego wytwarzania oprogramowania.

Ten język tworzy praktyczny obowiązek: relacje z dostawcami muszą być oparte na ryzyku, egzekwowalne umownie i możliwe do przeglądu. Kwestionariusz dostawcy zapisany w folderze nie wystarcza. Ogólna umowa bez osi czasu incydentu, bez praw dostępu do dowodów i bez widoczności podwykonawców nie wystarcza. Certyfikat dostawcy, którego nikt nie przejrzał, również nie wystarcza.

ISO/IEC 27001:2022 zapewnia model operacyjny. Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała kontekst, strony zainteresowane, obowiązki prawne i umowne, zakres SZBI oraz zależności. Klauzule 5.1 do 5.3 wymagają przywództwa, polityki, ról i raportowania. Klauzule 6.1.1 do 6.1.3 wymagają oceny ryzyka, postępowania z ryzykiem oraz Deklaracji stosowania. Klauzule 8.1 do 8.3 wymagają kontroli operacyjnej, powtarzania ocen ryzyka oraz udokumentowanych wyników.

Dla nadzoru nad dostawcami najważniejsze zabezpieczenia z Załącznika A ISO/IEC 27002:2022 obejmują:

• A.5.19 Bezpieczeństwo informacji w relacjach z dostawcami
• A.5.20 Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami
• A.5.21 Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT
• A.5.22 Monitorowanie, przegląd i zarządzanie zmianami usług dostawców
• A.5.24 Planowanie i przygotowanie zarządzania incydentami
• A.5.25 Ocena i decyzja dotycząca zdarzeń bezpieczeństwa informacji
• A.5.26 Reagowanie na incydenty bezpieczeństwa informacji
• A.5.27 Uczenie się na podstawie incydentów bezpieczeństwa informacji
• A.5.28 Zbieranie dowodów
• A.5.29 Bezpieczeństwo informacji podczas zakłóceń
• A.5.30 Gotowość ICT do ciągłości działania
• A.5.31 Wymagania prawne, ustawowe, regulacyjne i umowne
• A.5.34 Prywatność i ochrona PII
• A.8.8 Zarządzanie podatnościami technicznymi
• A.8.13 Kopie zapasowe informacji
• A.8.15 Rejestrowanie
• A.8.16 Działania monitorujące
• A.8.24 Stosowanie kryptografii
• A.8.32 Zarządzanie zmianami

Kluczowa jest własność. Klauzula ma ograniczoną wartość, jeżeli nikt nie jest właścicielem ryzyka, nikt nie przegląda dowodów, nikt nie śledzi wyjątków i nikt nie eskaluje niezgodności.

Enterprise Polityka bezpieczeństwa dostawców i stron trzecich ujmuje to wprost:

„Prawa do audytu, inspekcji oraz żądania dowodów bezpieczeństwa”

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

Dla MŚP Polityka bezpieczeństwa stron trzecich i dostawców dla MŚP ustanawia to samo praktyczne oczekiwanie:

„Prawa audytu lub dostępność dowodów zgodności”

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

To rozróżnienie ma znaczenie. Mniejsza organizacja może nie być w stanie audytować na miejscu każdego dużego dostawcy usług chmurowych, ale może wymagać dostępu do dowodów zapewnienia, takich jak zakres certyfikacji ISO/IEC 27001:2022, raporty SOC, podsumowania testów penetracyjnych, poświadczenia działań naprawczych dotyczących podatności, podsumowania incydentów, raporty z testów ciągłości działania oraz potwierdzenia usunięcia danych.

Trzy filary zabezpieczeń dla zapewnienia dotyczącego dostawców w NIS2

W modelu mapowania zgodności Clarysec trzy zabezpieczenia ISO/IEC 27002:2022 tworzą trzon nadzoru nad dostawcami w NIS2: 5.19, 5.20 i 5.22.

A.5.19 identyfikuje ryzyko dostawcy

Zabezpieczenie A.5.19, Bezpieczeństwo informacji w relacjach z dostawcami, stanowi fundament. Wymaga od organizacji ochrony informacji i aktywów, do których dostawcy uzyskują dostęp, które przetwarzają, przechowują lub którymi zarządzają.

Zenith Controls klasyfikuje je jako zabezpieczenie zapobiegawcze obejmujące poufność, integralność i dostępność, z koncepcją cyberbezpieczeństwa „Identify” oraz zdolnością operacyjną „Supplier Relationships Security”. Łączy A.5.19 z A.5.20, A.5.21, A.5.14, A.5.36 i A.5.10. W praktyce organizacja identyfikuje ryzyko dostawcy, definiuje oczekiwania bezpieczeństwa, kontroluje ekspozycję łańcucha dostaw ICT, chroni przekazywanie informacji, monitoruje zgodność oraz rozszerza obowiązki dopuszczalnego użytkowania na strony zewnętrzne.

Dla NIS2 mapuje się to bezpośrednio na Article 21(2)(d) dotyczący bezpieczeństwa łańcucha dostaw oraz Article 21(3) dotyczący due diligence dostawców. Dla GDPR wspiera to wymaganie korzystania z podmiotów przetwarzających, które zapewniają wystarczające gwarancje. Dla DORA wspiera zarządzanie ryzykiem zewnętrznych dostawców ICT, due diligence przed zawarciem umowy, ocenę krytyczności, ryzyko koncentracji oraz nadzór w całym cyklu życia.

A.5.20 nadaje wymaganiom egzekwowalność

Zabezpieczenie A.5.20, Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami, przekształca oczekiwania bezpieczeństwa w obowiązki umowne. Zenith Controls jasno wyjaśnia relację między A.5.19 i A.5.20:

„5.20 służy jako umowna formalizacja potrzeb i ryzyk bezpieczeństwa zidentyfikowanych w ramach 5.19. Podczas gdy 5.19 obejmuje ocenę ryzyk stron trzecich oraz definiowanie oczekiwań bezpieczeństwa, 5.20 zapewnia, że oczekiwania te stają się prawnie wiążące poprzez umowy lub umowy o poziomie świadczenia usług (SLA). Bez 5.20 zabezpieczenia zidentyfikowane w 5.19 nie miałyby egzekwowalności.”

To tutaj decyzje dotyczące ryzyka NIS2 stają się klauzulami: zgłaszanie naruszeń, prawa do audytu i dowodów, szyfrowanie, kontrola dostępu, zarządzanie podatnościami, zatwierdzanie podwykonawców, bezpieczny transfer, ciągłość działania, współpraca regulacyjna, wsparcie wyjścia oraz usunięcie danych.

A.5.22 dowodzi, że umowa działa

Zabezpieczenie A.5.22, Monitorowanie, przegląd i zarządzanie zmianami usług dostawców, zapobiega sprowadzeniu zapewnienia dotyczącego dostawców do jednorazowego onboardingu. Zenith Controls wiąże A.5.22 z A.5.19 i A.5.20, ale także z A.5.29 dotyczącym bezpieczeństwa informacji podczas zakłóceń, A.8.8 dotyczącym zarządzania podatnościami technicznymi, A.5.36 dotyczącym zgodności z politykami, zasadami i normami bezpieczeństwa informacji, A.5.15 dotyczącym kontroli dostępu oraz A.8.27 dotyczącym bezpiecznej architektury systemów i zasad inżynierii.

Ma to znaczenie, ponieważ usługi dostawców się zmieniają. Zmieniają się lokalizacje danych. Zmieniają się podwykonawcy przetwarzania. Pojawiają się podatności. Certyfikaty wygasają. Ujawniają się wzorce incydentów. Dostawca, który był akceptowalny w ubiegłym roku, dziś może być zbyt ryzykowny.

Co powinny obejmować klauzule umów z dostawcami dla NIS2

Zenith Blueprint, faza Kontrole w działaniu, krok 23, podaje praktyczny zestaw obszarów umowy z dostawcą:

„Kluczowe obszary zwykle uwzględniane w umowach z dostawcami obejmują:

✓ Obowiązki dotyczące poufności, w tym zakres, czas trwania oraz ograniczenia ujawniania stronom trzecim; ✓ Odpowiedzialności w zakresie kontroli dostępu, takie jak to, kto może uzyskiwać dostęp do danych, jak zarządzane są dane uwierzytelniające oraz jakie monitorowanie jest wdrożone; ✓ Środki techniczne i organizacyjne dotyczące ochrony danych, szyfrowania, bezpiecznej transmisji, kopii zapasowych oraz zobowiązań dotyczących dostępności; ✓ Terminy i protokoły zgłaszania incydentów, często z określonymi ramami czasowymi, np. „powiadomienie w ciągu 24 godzin”; ✓ Prawo do audytu, w tym częstotliwość, zakres oraz dostęp do odpowiednich dowodów, np. raportów z testów penetracyjnych, SoA, certyfikacji; ✓ Kontrole podwykonawców, wymagające od dostawcy przeniesienia równoważnych obowiązków bezpieczeństwa na dalszych partnerów; ✓ Postanowienia końcowe umowy, takie jak zwrot lub zniszczenie danych, odzyskanie aktywów oraz dezaktywacja kont.”

Z fazy Kontrole w działaniu, krok 23: zabezpieczenia organizacyjne.

Silna klauzula dostawcy dla NIS2 jest na tyle konkretna, aby można było ją przetestować. „Dostawca będzie utrzymywać odpowiednie bezpieczeństwo” to zapis słaby. „Dostawca powiadomi kontakt ds. bezpieczeństwa klienta w ciągu 24 godzin od potwierdzenia lub podejrzenia incydentu wpływającego na systemy klienta, dane klienta, dostępność usługi lub obowiązki zgłoszeniowe wobec organów regulacyjnych” to zapis z audytowalną ścieżką dowodową.

Klauzule incydentowe muszą odpowiadać terminom zgłaszania z NIS2

NIS2 Article 23 tworzy etapowy model raportowania znaczących incydentów: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy, zgłoszenie incydentu w ciągu 72 godzin, raporty pośrednie na żądanie oraz raport końcowy w ciągu miesiąca od zgłoszenia incydentu. Znaczący incydent to taki, który spowodował lub może spowodować poważne zakłócenia operacyjne, straty finansowe albo znaczną szkodę materialną lub niematerialną dla innych podmiotów.

Umowy z dostawcami muszą wspierać tę oś czasu. Jeżeli krytyczny dostawca usług zarządzanych potrzebuje czterech dni, aby potwierdzić, czy środowiska klienta zostały dotknięte incydentem, klient może przekroczyć własny termin regulacyjny.

Enterprise Polityka bezpieczeństwa dostawców i stron trzecich wymaga:

„Ramy czasowe powiadamiania o naruszeniu, np. w ciągu 24 lub 72 godzin, zależnie od krytyczności i wymagań regulacyjnych”

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

SME Polityka bezpieczeństwa stron trzecich i dostawców dla MŚP również wymaga zdefiniowanych terminów powiadamiania o naruszeniach z sekcji „Wymagania dotyczące ładu organizacyjnego”, klauzula polityki 5.3.3.

W przypadku incydentów PII Enterprise Polityka zarządzania incydentami i naruszeniami PII łączy zgłaszanie w obszarze cyberbezpieczeństwa, sektora finansowego, klientów i odbiorców usług:

„[Warunkowo] Lider ds. prywatności / PIMS Manager MUSI koordynować wszelkie wymagane sektorowe, cyberbezpieczeństwa, finansowe, klienckie lub skierowane do odbiorców usług zgłoszenia incydentów, gdy incydent PII o istotnym wpływie spełnia właściwy próg zgłoszeniowy, oraz MUSI odnotować organ, odbiorcę, oś czasu, złożenie i dowód potwierdzenia w REG01 i REG10.”

Z sekcji „Powiadamianie i komunikacja”, klauzula polityki 4.4.6.

To dojrzały dowód NIS2: nie tylko wiadomość e-mail z powiadomieniem, ale zapis organu, odbiorcy, osi czasu, złożenia, potwierdzenia, wpływu, przyczyny źródłowej i działań następczych.

Dostosowanie do prywatności i DORA bez dublowania programów dostawców

Wielu dostawców NIS2 przetwarza również dane osobowe. GDPR Article 28 wymaga, aby administratorzy korzystali z podmiotów przetwarzających zapewniających wystarczające gwarancje oraz aby obowiązki podmiotu przetwarzającego były określone w pisemnej umowie. GDPR Article 5 wymaga rozliczalności za bezpieczne i zgodne z prawem przetwarzanie. Obowiązki GDPR dotyczące naruszeń wymagają także szybkiej współpracy, gdy incydenty dostawców wpływają na dane osobowe.

Enterprise Polityka zarządzania podmiotami przetwarzającymi, podwykonawcami przetwarzania i stronami trzecimi w zakresie prywatności ustanawia bramkę zatwierdzenia:

„[Oba] Właściciel dostawcy / zakupów MUSI zapewnić, aby umowy z podmiotami przetwarzającymi i podwykonawcami przetwarzania obejmowały wsparcie w zakresie prywatności, zapewnienie bezpieczeństwa, interfejs incydentowy przez PII15, zwrot lub usunięcie przez PII10, powiązanie transferu przez PII13 oraz współpracę audytową lub zapewnieniową przed zatwierdzeniem.”

Z sekcji „Kontrole umów i udokumentowanych poleceń”, klauzula polityki 4.3.6.

Wymaga również przeglądu dowodów przed zatwierdzeniem:

„[Wszyscy] Lider ds. bezpieczeństwa informacji MUSI przejrzeć dowody zapewnienia bezpieczeństwa dla każdej relacji z podmiotem przetwarzającym, podwykonawcą przetwarzania lub stroną trzecią z dostępem do PII albo hostingiem PII przed zatwierdzeniem oraz MUSI odnotować wynik w REG08 lub REG12.”

Z sekcji „Due diligence i ocena ryzyka”, klauzula polityki 4.2.2.

DORA dodaje kolejną warstwę, gdy dostawca obsługuje podmiot finansowy. DORA Articles 28 do 30 wymagają nadzoru nad zewnętrznymi dostawcami ICT, rejestrów umów na usługi ICT, due diligence opartego na ryzyku, oceny krytyczności, analizy ryzyka koncentracji, praw audytu i inspekcji, praw wypowiedzenia, strategii wyjścia oraz obowiązkowych postanowień umownych. Article 30 jest szczególnie istotny, ponieważ wymaga treści umownych obejmujących opisy usług, lokalizacje, ochronę danych, dostęp i odtwarzanie, poziomy usług, wsparcie incydentowe, współpracę z organami, prawa audytu, podwykonawstwo, środki awaryjne oraz wsparcie przejścia.

Praktyczną odpowiedzią nie są trzy oddzielne programy dostawców dla NIS2, GDPR i DORA. Jest nią jeden zharmonizowany model dowodów dotyczących dostawców, zmapowany między ramami.

NIST CSF 2.0 jest użyteczny, ponieważ jego funkcja GOVERN wymaga rozumienia zależności, obowiązków prawnych, obowiązków umownych, apetytu na ryzyko, polityk, rozliczalności oraz nadzoru. Kategoria łańcucha dostaw GV.SC obejmuje role dostawców, krytyczność, wymagania umowne, due diligence, monitorowanie, uwzględnienie incydentów, monitorowanie cyklu życia oraz postanowienia kończące relację.

Proces Clarysec dla onboardingu krytycznego dostawcy

Załóżmy, że wdrażasz dostawcę zarządzanych usług bezpieczeństwa, który będzie monitorować telemetrię punktów końcowych, odbierać alerty zawierające identyfikatory użytkowników oraz wspierać triaż incydentów dla organizacji objętej zakresem NIS2.

Krok 1: sklasyfikuj dostawcę

Odnotuj dostawcę w rejestrze dostawców wraz z opisem usługi, systemami i danymi, do których uzyskuje dostęp, udziałem PII, wsparciem dla usług kluczowych lub ważnych, dostępem uprzywilejowanym, krajami świadczenia usług, podwykonawcami, zależnościami od czwartych stron, oceną krytyczności, właścicielem ryzyka, właścicielem po stronie zakupów oraz recenzentem bezpieczeństwa informacji.

Wdraża to klauzule ISO/IEC 27001:2022 4.2, 4.3, 6.1.2 i 8.1 przez połączenie wymagań stron zainteresowanych, zależności, własności ryzyka i kontroli operacyjnej.

Krok 2: zmapuj ryzyko na SoA

W Zenith Blueprint, faza Zarządzanie ryzykiem, krok 13, Clarysec zaleca odwołania krzyżowe do regulacji w rejestrze ryzyk lub SoA:

„Odwołuj się krzyżowo do regulacji: jeżeli określone zabezpieczenia są wdrażane specjalnie w celu zachowania zgodności z GDPR, NIS2 lub DORA, możesz odnotować to albo w rejestrze ryzyk jako część uzasadnienia wpływu ryzyka, albo w notatkach SoA.”

Z fazy Zarządzanie ryzykiem, krok 13: planowanie postępowania z ryzykiem i Deklaracja stosowania.

Dla MSSP uwzględnij co najmniej A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 do A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 i A.8.24.

Krok 3: wymagaj egzekwowalnych klauzul

Użyj dodatku bezpieczeństwa dla dostawcy wymagającego wstępnego powiadomienia o incydencie w ciągu 24 godzin, szczegółowej aktualizacji w ciągu 72 godzin, raportu końcowego z incydentu, MFA dla dostępu uprzywilejowanego, imiennych kont użytkowników, kontroli podwykonawców, bezpiecznego transferu, szyfrowania, dowodów zapewnienia, współpracy regulacyjnej, dowodów BCP i DR, wsparcia wyjścia, zwrotu lub usunięcia danych oraz cofnięcia dostępu.

Enterprise Polityka zarządzania ryzykiem zależności od dostawców określa wymaganie dotyczące ciągłości:

„Tam, gdzie ma to zastosowanie, wymaganie, aby dostawca utrzymywał własne plany ciągłości działania (BCP/DRP) oraz plany zarządzania incydentami, testował je oraz przekazywał nam podsumowania lub raporty z testów na żądanie.”

Z sekcji „Wymagania wdrożeniowe”, klauzula polityki 6.8.4.

Krok 4: zbuduj pakiet dowodów zapewnienia

Przed zatwierdzeniem zażądaj podpisanej umowy, SLA, dodatku bezpieczeństwa, zakresu certyfikacji ISO/IEC 27001:2022 lub równoważnego zapewnienia, raportu SOC tam, gdzie jest dostępny, podsumowania dla kierownictwa z testu penetracyjnego, podsumowania zarządzania podatnościami, podsumowania procedury reagowania na incydenty, podsumowania testu BCP lub DR, poświadczenia kontroli dostępu i MFA, listy podwykonawców, procedury usunięcia danych i wyjścia oraz DPA tam, gdzie przetwarzane są PII.

SME Polityka bezpieczeństwa stron trzecich i dostawców dla MŚP czyni podstawowe dowody umowne mierzalnymi:

„Podpisane umowy i SLA”

Z sekcji „Egzekwowanie i zgodność”, klauzula polityki 8.3.2.1.

Identyfikuje również powtarzalne dowody dotyczące dostawców:

„Ważne certyfikaty bezpieczeństwa lub zaktualizowane dowody kontroli”

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

W zakresie szerszego due diligence dostawców Polityka audytu i monitorowania zgodności stanowi:

„Due diligence dostawców musi obejmować przegląd certyfikacji, np. ISO 27001, SOC 2, kwestionariuszy bezpieczeństwa oraz rejestrów incydentów.”

Krok 5: monitoruj zależnie od krytyczności

Enterprise Polityka zarządzania podmiotami przetwarzającymi, podwykonawcami przetwarzania i stronami trzecimi w zakresie prywatności wymaga kwartalnego monitorowania relacji wysokiego ryzyka dotyczących PII:

„[Wszyscy] Właściciel dostawcy / zakupów MUSI kwartalnie monitorować aktywne relacje wysokiego ryzyka z podmiotami przetwarzającymi i podwykonawcami przetwarzania oraz corocznie inne aktywne relacje z podmiotami przetwarzającymi i podwykonawcami przetwarzania PII względem warunków due diligence, statusu umowy, statusu zapewnienia, otwartych problemów oraz dat przeglądu w REG08.”

Z sekcji „Bieżące monitorowanie, wsparcie, interfejs ujawniania i wyjście”, klauzula polityki 4.5.1.

Tak A.5.22 staje się realnym działaniem. Przegląd powinien ustalić, czy dostawca pozostaje w granicach apetytu na ryzyko, czy dowody są aktualne, czy istnieją otwarte problemy, czy wystąpiły incydenty oraz czy zmiany usługi wymagają ponownej oceny.

Jak audytorzy będą testować klauzule dostawców NIS2

Audytorzy rzadko zaczynają od czytania polityki w izolacji. Pobierają próbę dostawców i podążają ścieżką dowodową.

Audytor ISO/IEC 27001:2022 poprosi o inwentarz dostawców, klasyfikację ryzyka, kryteria dostawców, zapisy due diligence, umowy, dowody, mapowanie SoA oraz historię monitorowania. Dla Załącznika A 5.20 audytor sprawdzi, czy próbkowane umowy zawierają egzekwowalne klauzule. Dla Załącznika A 5.22 audytor przetestuje, czy raporty były przeglądane, wyjątki rejestrowane, a działania monitorowane do zamknięcia.

Właściwy organ NIS2 może skupić się na tym, czy praktyki cyberbezpieczeństwa dostawcy i procedury bezpiecznego wytwarzania zostały ocenione zgodnie z Article 21(3). Recenzent ukierunkowany na DORA może poprosić o wpisy w rejestrze umów ICT, strategie wyjścia, analizę ryzyka koncentracji oraz obowiązkowe postanowienia Article 30. Audytor prywatności może testować umowy z podmiotami przetwarzającymi, przeniesienie obowiązków na podwykonawców przetwarzania, interfejsy naruszeń oraz dowody wystarczających gwarancji.

Enterprise Polityka bezpieczeństwa i kontroli dostępu PII pokazuje, jak kontrola dostępu, podatności, konfiguracja, monitorowanie i kryptografia łączą się z ISO/IEC 27001:2022:

„ISO/IEC 27001:2022 — Klauzula 6.1.3; Klauzula 8.1; zabezpieczenia Załącznika A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Zaadresowane przez klauzule [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

Z sekcji „Normy i ramy odniesienia”, klauzula polityki 13.9.

Gdy dostawca ma dostęp do PII, systemów uprzywilejowanych lub danych monitorowania, dowody kontroli dostępu nie są oddzielone od zapewnienia dotyczącego dostawcy. Są częścią tej samej ścieżki audytowej.

Pułapka zakupowa: podpisane umowy bez operacyjnego zapewnienia

Najczęstszą nieskutecznością nadzoru nad dostawcami w NIS2 nie jest brak umów. Jest nią luka między językiem umowy a codziennym działaniem.

Umowa może wymagać corocznych podsumowań testów penetracyjnych, ale żaden właściciel ich nie żąda. Może wymagać 24-godzinnego powiadomienia o incydencie, ale dostawca udostępnia wyłącznie ogólny adres wsparcia. Może wymagać zatwierdzania podwykonawców, ale zakupy nigdy nie otrzymują powiadomień o zmianach. Może obejmować prawa audytu, ale organizacja nie ma procesu oceny wyjątków w raportach SOC. Może wymagać usunięcia danych przy wyjściu, ale IT nigdy nie waliduje dezaktywacji kont.

Zenith Blueprint, faza Kontrole w działaniu, krok 23, wyjaśnia, jak zabezpieczenia dostawców zaczynają działać w praktyce:

„W praktyce to zabezpieczenie funkcjonuje poprzez:

✓ oceny ryzyka dostawców, ✓ kwestionariusze due diligence przed rozpoczęciem współpracy, ✓ wzory umów z wbudowanymi warunkami bezpieczeństwa, ✓ listy kontrolne onboardingu dostawców obejmujące nadawanie dostępu i konfigurację monitorowania, ✓ bieżące ponowne oceny, szczególnie gdy zmienia się zakres dostawcy, występują incydenty lub zbliżają się odnowienia.

To zabezpieczenie nie kończy się na dostawcach pierwszego poziomu. Twój dostawca może outsourcować usługi do własnych dostawców, a ryzyko nadal może obciążać Ciebie.”

To jest komunikat NIS2 na poziomie zarządu: outsourcing świadczenia usług nie oznacza outsourcingu rozliczalności.

Lista kontrolna działań naprawczych dla umów z dostawcami dla NIS2

Zacznij od 20 najważniejszych dostawców według krytyczności i przeprowadź ukierunkowane działania naprawcze:

• Zidentyfikuj dostawców wspierających usługi kluczowe lub ważne.
• Potwierdź, czy każdy dostawca przetwarza PII, wspiera usługi regulowane lub ma dostęp uprzywilejowany.
• Przypisz właściciela biznesowego, właściciela po stronie zakupów oraz recenzenta bezpieczeństwa.
• Zweryfikuj, czy ocena ryzyka dostawcy jest aktualna i zgodna z rzeczywistym zakresem usługi.
• Potwierdź, że umowa obejmuje bazowe wymagania bezpieczeństwa, powiadamianie o incydentach, prawa audytu lub dowodów, kontrole podwykonawców, ciągłość działania, bezpieczny transfer, kontrolę dostępu, współpracę w zakresie podatności oraz klauzule wyjścia.
• Potwierdź, że terminy naruszeń wspierają potrzeby eskalacji 24-godzinnej i 72-godzinnej tam, gdzie ma to zastosowanie.
• Zażądaj zaktualizowanych dowodów zapewnienia, w tym certyfikacji, raportów SOC, podsumowań testów penetracyjnych, testów BCP lub DR oraz historii incydentów.
• Przeglądaj dowody, nie tylko je przechowuj.
• Rejestruj wyjątki i przypisuj właścicieli działań naprawczych.
• Zaktualizuj SoA i rejestr ryzyk tam, gdzie zabezpieczenia dostawców wspierają NIS2, GDPR, DORA lub zobowiązania wobec klientów.
• Zaplanuj częstotliwość monitorowania na podstawie krytyczności dostawcy.
• Przetestuj jedną ścieżkę eskalacji incydentu dostawcy.
• Przetestuj jedną ścieżkę zakończenia współpracy z dostawcą, obejmującą zwrot danych, usunięcie, odzyskanie aktywów oraz cofnięcie dostępu.

Jeżeli nie możesz wykazać tych punktów dla krytycznego dostawcy, umowa nie jest jeszcze gotowa do audytu.

Przekształć klauzule dostawców w dowody dla organu nadzorczego

Nadzór nad dostawcami w NIS2 jest obecnie aktywną dyscypliną operacyjną. Organy nadzorcze, klienci, audytorzy certyfikujący, zespoły prywatności, partnerzy z sektora finansowego i zarządy będą pytać nie tylko o to, czy klauzule dotyczące dostawców istnieją. Będą pytać, czy klauzule są oparte na ryzyku, egzekwowalne, monitorowane, poparte dowodami oraz powiązane ze zgłaszaniem incydentów, ciągłością działania, kontrolą dostępu, zarządzaniem podatnościami, przeniesieniem obowiązków na podwykonawców i zakończeniem współpracy.

Clarysec pomaga organizacjom zamknąć tę lukę dzięki Zenith Blueprint, który przekształca zabezpieczenia dostawców w fazy SZBI, postępowanie z ryzykiem, wpisy SoA, rutyny onboardingu oraz dowody audytowe. Zenith Controls mapuje zabezpieczenia ISO/IEC 27002:2022 dotyczące dostawców A.5.19, A.5.20 i A.5.22 na NIS2, DORA, GDPR, NIST, COBIT 2019, wspierające normy ISO oraz metodyki audytu. Polityki Clarysec dotyczące dostawców i prywatności zapewniają strukturę klauzul, oczekiwania dowodowe oraz rutyny monitorowania, które czynią zapewnienie dotyczące dostawców możliwym do obrony.

Następne działanie jest proste: wybierz pięciu krytycznych dostawców, pobierz próbę ich umów, zmapuj każdą klauzulę na postępowanie z ryzykiem ISO/IEC 27001:2022 i zabezpieczenia z Załącznika A, zażądaj aktualnych dowodów zapewnienia oraz przeprowadź ćwiczenie typu tabletop dla 24-godzinnego powiadomienia o incydencie. Jeżeli ścieżka dowodowa się urywa, zestawy narzędzi Clarysec dają strukturę do jej naprawy, zanim zrobi to za Ciebie incydent, przegląd klienta lub żądanie organu nadzorczego.