Bezpieczeństwo łańcucha dostaw NIS 2 – wytyczne ENISA

W świecie NIS 2 organizacja nie kończy się na własnych systemach.
O jej realnym poziomie bezpieczeństwa decydują także dostawcy: chmura, integratorzy, software house’y, operatorzy telekomunikacyjni, a nawet dostawcy niszowych komponentów IT.

W rozdziale 5 wytycznych ENISA Technical Implementation Guidance bezpieczeństwo łańcucha dostaw staje się pełnoprawnym obszarem zarządzania ryzykiem, a nie tylko dopiskiem w umowie.
Chodzi o to, by mieć politykę, kryteria, konkretne klauzule, proces monitoringu i aktualny rejestr dostawców – a nie tylko „zaufanie do marki”.

Poniżej kolejny wpis z serii NIS 2 – tym razem o tym, jak zorganizować bezpieczeństwo łańcucha dostaw zgodnie z ENISA.

1. Polityka bezpieczeństwa łańcucha dostaw – punkt wyjścia

ENISA wymaga, żeby organizacje objęte NIS 2 miały politykę bezpieczeństwa łańcucha dostaw (Supply Chain Security Policy).
To dokument, który:

• określa jak zarządzamy ryzykiem dostawców i usługodawców,
• wskazuje naszą rolę w łańcuchu dostaw (np. operator usługi kluczowej, dostawca, integrator),
• oraz opisuje zasady współpracy z bezpośrednimi dostawcami i usługodawcami w kontekście cyberbezpieczeństwa.

Polityka powinna korzystać z uznanych standardów, np.:

• ISO/IEC 27036 (relacje z dostawcami),
• NIST SP 800-161 (cybersecurity supply chain risk management),
• oraz dobrych praktyk ENISA dla bezpieczeństwa łańcucha dostaw.

Ważny niuans:
w przypadku FOSS (open source)¹ nie zawsze mamy klasyczną relację dostawca–klient, więc wymogi kontraktowe trzeba adresować do własnych procesów i dostawców, którzy FOSS integrują, a nie do samej społeczności.

2. Kryteria wyboru dostawców – nie każdy „vendor” jest równy

Polityka musi przekładać się na konkretne kryteria wyboru i kontraktowania dostawców.
ENISA podpowiada, by patrzeć nie tylko na cenę i funkcjonalność, ale przede wszystkim na:

• cybersecurity practices dostawcy
  – jak wygląda rozwój bezpiecznego oprogramowania, zarządzanie podatnościami, aktualizacje, proces reagowania na incydenty.
• zdolność spełnienia wymagań bezpieczeństwa
  – czy dostawca jest w stanie realnie zrealizować nasze wymagania (SLA, szyfrowanie, lokalizacja danych, logowanie, dostępność, raportowanie).
• jakość i odporność usług/produktów ICT
  – czy rozwiązanie ma wbudowane mechanizmy bezpieczeństwa, jaka jest jego krytyczność i ryzyko.
• ryzyko vendor lock-in
  – zależność od jednej technologii, brak otwartych standardów, utrudnione migracje, własnościowe formaty danych.

Do tego ENISA sugeruje brać pod uwagę m.in.:

• jurysdykcję (prawo, pod które podlega dostawca),
• regulacyjny status (np. sam jest podmiotem NIS 2),
• historię incydentów bezpieczeństwa,
• opinie i rekomendacje organów krajowych / NIS Cooperation Group,
• certyfikaty (ISO 27001, SOC 2, itp.).

W praktyce dobrze działa macierz oceny dostawców, w której łączysz krytyczność usługi z jakością zabezpieczeń i ryzykiem zależności.

3. Ryzyko łańcucha dostaw a NIS Cooperation Group

NIS 2 przewiduje tzw. koordynowane oceny ryzyka krytycznych łańcuchów dostaw na poziomie UE.
ENISA wymaga, żeby przy tworzeniu polityki łańcucha dostaw:

• sprawdzać rekomendacje NIS Cooperation Group i organów krajowych,
• uwzględniać publiczne ostrzeżenia i wytyczne dotyczące dostawców, technologii, sektorów,
• dopasować wewnętrzne kryteria do tych rekomendacji (np. ograniczenia dla wysokiego ryzyka).

Krótko mówiąc: polityka nie powstaje w próżni – musi brać pod uwagę szerszy kontekst regulacyjny i geopolityczny.

4. Kontrakt, SLA i prawo audytu – bezpieczeństwo na papierze i w praktyce

Na bazie polityki i oceny ryzyka organizacja musi zadbać, żeby konkretne wymagania trafiły do umów (często w formie SLA).
ENISA wymienia wprost, że w kontraktach powinny się znaleźć m.in.:

• wymagania bezpieczeństwa dla produktów i usług ICT (szyfrowanie, dostęp, logowanie, aktualizacje, testy bezpieczeństwa),
• wymagania dotyczące kompetencji i szkoleń personelu dostawcy,
• zasady weryfikacji personelu dostawcy (np. dla dostępów uprzywilejowanych),
• obowiązek niezwłocznego raportowania incydentów wpływających na nasze systemy,
• prawo audytu lub prawo do otrzymywania raportów z audytów (np. SOC 2, ISO, raporty z testów),
• obowiązek zarządzania podatnościami po stronie dostawcy (patching, CVE, proces naprawczy),
• wymagania wobec podwykonawców – tak, aby łańcuch dostaw był spójnie zarządzany,
• zasady zakończenia współpracy: zwrot / zniszczenie danych, wygaszenie dostępów, wsparcie migracji.

Przy dużych vendorach ENISA wręcz sugeruje:

• łączenie sił z innymi klientami (zamówienia grupowe, organizacje branżowe),
• korzystanie ze wsparcia prawnego przy negocjacji klauzul,
• świadome planowanie exit strategy już na etapie wyboru dostawcy.

5. Wybór nowych dostawców – ryzyko na wejściu

NIS 2 nie pozwala na „ślepy” wybór dostawców.
ENISA jasno mówi: przed podpisaniem umowy musi być analiza ryzyka uwzględniająca m.in.:

• kryteria bezpieczeństwa z polityki,
• rekomendacje NIS Cooperation Group,
• charakter usługi (krytyczność biznesowa, dane, regulacje),
• możliwy wpływ na nasze RTO/RPO i ciągłość działania.

Dobrym podejściem jest powiązanie procesu zakupowego z:

• checklistą NIS 2 / ENISA dla dostawców,
• minimalnymi kryteriami dopuszczenia (must-have),
• oceną ryzyka (risk score) i decyzją: akceptujemy, mitygujemy, szukamy alternatywy.

6. Stały nadzór nad dostawcami – to nie jest „ustaw i zapomnij”

Relacja z dostawcą nie kończy się po podpisaniu umowy.
ENISA wymaga ciągłego monitorowania i cyklicznych przeglądów, w tym:

• regularnego przeglądu realizacji SLA,
• analizy incydentów związanych z usługami / produktami dostawcy,
• oceny zmian po stronie dostawcy (fuzje, zmiany architektury, nowe wersje usług, nowe ryzyka),
• decyzji o dodatkowych, pozaplanowych przeglądach, jeśli pojawią się sygnały ostrzegawcze.

To oznacza w praktyce:

• stały proces Vendor Risk Management,
• listę incydentów „związanych z dostawcami”,
• oraz mechanizmy wyciągania konsekwencji (zmiany w umowie, plany naprawcze, w skrajnym przypadku – exit).

7. Rejestr dostawców i ich klasyfikacja

ENISA wymaga utrzymywania aktualnego rejestru bezpośrednich dostawców i usługodawców, który obejmuje m.in.:

• dane kontaktowe,
• listę usług, systemów i procesów, które dany dostawca obsługuje,
• a w praktyce – klasyfikację ryzyka i krytyczności.

Warto wprowadzić klasy typu:

• krytyczni – mają bezpośredni wpływ na usługi kluczowe, dane wrażliwe, ciągłość działania,
• strategiczni – wysoka wartość, ale mniejsza krytyczność operacyjna,
• rutynowi – niski wpływ na bezpieczeństwo i ciągłość działania.

Taka klasyfikacja pozwala:

• skupić wysiłek na dostawcach krytycznych,
• różnicować wymagania, poziom monitoringu i częstotliwość przeglądów,
• lepiej przygotować się na scenariusze awaryjne (kogo trzeba mieć „na radarze” non stop).

8. FOSS w łańcuchu dostaw – odpowiedzialność po naszej stronie

ENISA poświęca osobny fragment otwartemu oprogramowaniu. Kluczowe przesłanie jest proste:

• społeczność FOSS nie jest klasycznym dostawcą,
• nie zawsze można jej narzucić wymagania kontraktowe,
• ale ryzyko związane z FOSS nadal trzeba zarządzać.

W praktyce oznacza to np.:

• żądanie od integratorów / dostawców informacji o użytych komponentach FOSS,
• stosowanie narzędzi do zarządzania zależnościami i podatnościami,
• monitorowanie projektów, od których jesteśmy zależni (patchowanie, status utrzymania),
• czasem – wręcz inwestowanie w projekty open source, od których zależy nasza usługa krytyczna.

NIS 2 nie znosi FOSS – raczej wymusza dojrzałe podejście do jego używania.

9. Krótka checklista startowa

Na koniec – szybki reality check. Z perspektywy ENISA i NIS 2 warto zadać sobie kilka pytań:

• Czy masz spisaną politykę bezpieczeństwa łańcucha dostaw, a nie tylko akapit w ogólnej polityce bezpieczeństwa?
• Czy kryteria wyboru dostawców obejmują bezpieczeństwo, lock-in, jurysdykcję i historię incydentów, a nie tylko cenę i funkcje?
• Czy w umowach i SLA masz konkretne wymagania bezpieczeństwa, prawo audytu, obowiązek raportowania incydentów i zasady zakończenia współpracy?
• Czy prowadzisz rejestr dostawców z klasyfikacją krytyczności i powiązaniem z usługami NIS 2?
• Czy regularnie monitorujesz dostawców, analizujesz incydenty z ich udziałem i przeglądasz SLA?
• Czy masz plan, co zrobisz, gdy kluczowy dostawca nagle przestanie spełniać wymagania lub stanie się niedostępny?

Jeśli na część z tych pytań odpowiedź brzmi „nie” albo „nie do końca”, to właśnie tutaj zaczyna się Twoje bezpieczeństwo łańcucha dostaw NIS 2.

Twoje bezpieczeństwo to nasza pasja! 🌐 Jeśli interesuje Cię ochrona danych osobowych, bezpieczeństwo informacji czy cyberbezpieczeństwo, zajrzyj na stronę CAB oraz Platformę Cyberbezpieczeństwa. Szukasz informacji o ochronie sygnalistów? 📢 Sprawdź stronę Kanału Zgłoszeniowego. Czekają tam praktyczne porady i ekspercka wiedza!

¹ FOSS (Free and Open Source Software) – oprogramowanie udostępniane na licencjach umożliwiających swobodne używanie, analizowanie, modyfikowanie i dalsze rozpowszechnianie kodu źródłowego. FOSS nie oznacza, że dostawca jest formalnym kontraktowym podmiotem – często stoi za nim społeczność, a nie firma.