Łańcuch dostaw ICT stał się jednym z najważniejszych obszarów cyberbezpieczeństwa. Dla podmiotów kluczowych i ważnych oznacza to konieczność spojrzenia na dostawców nie tylko przez pryzmat ceny, funkcjonalności i terminów realizacji, ale również ryzyka, ciągłości działania, odporności produktów i usług ICT, chmury, sztucznej inteligencji oraz zdolności organizacji do utrzymania usług w sytuacji zakłócenia.
W praktyce cyberbezpieczeństwo organizacji jest dziś tak silne, jak najsłabszy element jej ekosystemu dostawców. System dziedzinowy, usługa chmurowa, zewnętrzny SOC, narzędzie EDR, dostawca SaaS, integrator, komponent open source, model AI, centrum danych albo podwykonawca producenta mogą mieć bezpośredni wpływ na dostępność usługi, bezpieczeństwo informacji i zdolność organizacji do działania w sytuacji kryzysowej.
KSC i NIS2: dostawca staje się częścią ryzyka organizacji
Krajowy system cyberbezpieczeństwa oraz dyrektywa NIS2 przesuwają ciężar odpowiedzialności z reaktywnego podejścia do incydentów na systemowe zarządzanie ryzykiem. Dotyczy to również łańcucha dostaw produktów ICT, usług ICT i procesów ICT, od których zależy świadczenie usług przez podmioty kluczowe i ważne.
Oznacza to, że organizacja nie może ograniczyć się do stwierdzenia, że „za bezpieczeństwo odpowiada dostawca”. Jeżeli dostawca dostarcza system, usługę, komponent, infrastrukturę, oprogramowanie, usługę zarządzaną albo proces ICT niezbędny do świadczenia usługi, to ryzyko tego dostawcy staje się elementem ryzyka organizacji.
W praktyce podmiot powinien wiedzieć, którzy dostawcy są krytyczni, jakie usługi od nich zależą, jakie systemy wspierają, jakie dane przetwarzają, jakie mają podwykonawstwa, jakie są ich punkty awarii oraz jak organizacja zachowa ciągłość działania, jeżeli dostawca przestanie świadczyć usługę, ulegnie cyberatakowi, zmieni warunki, zakończy wsparcie albo utraci zdolność operacyjną.
Bezpośredni dostawca to dopiero początek
Bezpośredni dostawca sprzętu, oprogramowania lub usługi ICT jest pierwszym punktem kontroli, ponieważ to z nim organizacja ma relację umowną, SLA, kanał eskalacji, procedury reklamacyjne i możliwość egzekwowania wymagań. Może to być producent, integrator, dystrybutor, dostawca SaaS, dostawca chmury, dostawca usług zarządzanych, dostawca usług zarządzanych w zakresie cyberbezpieczeństwa albo firma serwisowa.
Problem polega na tym, że bezpośredni dostawca rzadko działa samodzielnie. Jego usługa może zależeć od centrum danych, platformy chmurowej, bibliotek open source, narzędzi CI/CD, podwykonawców, zewnętrznych repozytoriów, dostawców aktualizacji, usług telekomunikacyjnych, producentów sprzętu, a coraz częściej także od zewnętrznych modeli AI lub API.
Dlatego analiza łańcucha dostaw nie powinna kończyć się na pierwszym poziomie. Organizacja powinna dążyć do uzyskania rozsądnej, proporcjonalnej do ryzyka widoczności dalszych zależności. Nie zawsze oznacza to pełną kontrolę nad całym łańcuchem dostaw, ale zawsze oznacza konieczność zadania dostawcy właściwych pytań i przeniesienia wymagań bezpieczeństwa na relację umowną.
ISO/IEC 27002: praktyczny katalog zabezpieczeń dla dostawców
ISO/IEC 27002:2022 pomaga przełożyć wymagania prawne na praktykę organizacyjną. Szczególne znaczenie mają zabezpieczenia dotyczące relacji z dostawcami, bezpieczeństwa informacji w umowach, zarządzania bezpieczeństwem w łańcuchu dostaw ICT, monitorowania usług dostawcy oraz korzystania z usług chmurowych.
Z perspektywy organizacji oznacza to konieczność wdrożenia procesu obejmującego wybór dostawcy, ocenę ryzyka, kontraktowanie, monitorowanie, przeglądy okresowe, obsługę incydentów, zarządzanie zmianami i zakończenie współpracy. Taki proces powinien być udokumentowany i audytowalny.
Wymagania wobec dostawców powinny obejmować między innymi zarządzanie dostępem, szyfrowanie, logowanie, zarządzanie podatnościami, aktualizacje, bezpieczne wytwarzanie oprogramowania, kopie zapasowe, odtwarzanie, ciągłość działania, podwykonawców, lokalizację danych, zgłaszanie incydentów, testy bezpieczeństwa i zasady usunięcia lub zwrotu danych po zakończeniu umowy.
ISO 22301: ciągłość dostawcy to ciągłość usługi
Bezpieczeństwo łańcucha dostaw nie może być rozumiane wyłącznie jako ochrona przed nieuprawnionym dostępem, podatnościami lub wyciekiem danych. Równie ważna jest ciągłość działania. Dostawca może być bezpieczny technicznie, ale nadal stanowić krytyczne ryzyko, jeżeli nie ma realnej zdolności odtworzenia usługi po awarii, cyberataku, utracie centrum danych, problemie kadrowym, przerwaniu łańcucha podwykonawców albo zakończeniu wsparcia dla produktu.
W tym obszarze właściwą ramą jest ISO 22301. To właśnie ta norma porządkuje analizę wpływu na działalność, ocenę ryzyka zakłóceń, strategie ciągłości działania, plany ciągłości, procedury odtworzeniowe, program ćwiczeń oraz ocenę zdolności organizacji do utrzymania działania w warunkach kryzysowych.
Dla krytycznych dostawców należy ustalić w szczególności, jaki będzie wpływ ich niedostępności na usługę, jaki jest wymagany czas odtworzenia, jaka utrata danych jest akceptowalna, jaki minimalny poziom działania musi być utrzymany w trybie awaryjnym oraz czy istnieje alternatywny dostawca, tryb manualny, model zapasowy, multi-cloud albo inna strategia ograniczająca zależność.
ISO/IEC 27036-3 i ISO/IEC 27036-4 wspierają zarządzanie bezpieczeństwem relacji z dostawcami, sprzętem, oprogramowaniem, usługami i chmurą. Nie zastępują jednak ISO 22301 jako podstawowej ramy dla BIA, strategii ciągłości, planów odtworzeniowych i ćwiczeń. Dlatego w praktyce zarządzanie dostawcami powinno łączyć wymagania bezpieczeństwa informacji z wymaganiami ciągłości działania.
ISO/IEC 27036: zarządzanie relacją przez cały cykl życia
Seria ISO/IEC 27036 rozwija podejście do bezpieczeństwa relacji z dostawcami. Najważniejsza praktyczna lekcja płynąca z tej serii norm jest prosta: bezpieczeństwo dostawcy nie zaczyna się w dniu podpisania umowy i nie kończy się na ankiecie bezpieczeństwa.
Relacja z dostawcą powinna być zarządzana przez cały cykl życia: od planowania zakupu, przez wybór dostawcy, zawarcie umowy, zarządzanie usługą, monitorowanie, incydenty, zmiany, audyty i przeglądy, aż po zakończenie współpracy i bezpieczne wyjście z relacji.
W praktyce oznacza to konieczność posiadania kryteriów wyboru dostawców, wymagań bezpieczeństwa, zasad klasyfikacji dostawców, planu pozyskiwania dowodów, procedur incydentowych, zasad zarządzania zmianą, prawa audytu lub dostępu do raportów, wymagań wobec podwykonawców, procedury przejścia oraz exit planu.
ENISA: jak przełożyć wymagania na działania i dowody
Wytyczne ENISA do rozporządzenia wykonawczego Komisji (UE) 2024/2690 są szczególnie użyteczne, ponieważ pokazują, jak praktycznie wdrażać środki zarządzania ryzykiem cyberbezpieczeństwa wynikające z NIS2. ENISA wskazuje, że opracowanie zawiera praktyczne porady, przykłady dowodów i mapowania wymagań bezpieczeństwa dla podmiotów objętych rozporządzeniem wykonawczym 2024/2690.
W obszarze łańcucha dostaw ENISA wzmacnia kilka praktycznych zasad. Po pierwsze, organizacja powinna posiadać politykę bezpieczeństwa łańcucha dostaw. Nie powinna to być ogólna deklaracja, ale dokument regulujący relacje z bezpośrednimi dostawcami i usługodawcami, sposób ograniczania ryzyka oraz rolę organizacji w łańcuchu dostaw.
Po drugie, ENISA podkreśla znaczenie kryteriów wyboru i kontraktowania dostawców. Kryteria te powinny obejmować praktyki cyberbezpieczeństwa dostawcy, bezpieczne wytwarzanie, zdolność spełnienia wymagań cyberbezpieczeństwa, jakość i odporność produktów oraz usług ICT, a także możliwość dywersyfikacji źródeł dostaw i ograniczenia vendor lock-in.
Po trzecie, wytyczne ENISA kładą nacisk na umowy. W umowach powinny znaleźć się wymagania dotyczące cyberbezpieczeństwa, kompetencji i świadomości personelu dostawcy, zgłaszania incydentów, obsługi podatności, prawa audytu lub raportów z audytu, kontroli podwykonawców oraz obowiązków po zakończeniu współpracy, w tym zwrotu albo bezpiecznego usunięcia informacji.
Po czwarte, ENISA wskazuje na konieczność prowadzenia aktualnego rejestru bezpośrednich dostawców i usługodawców, wraz z punktami kontaktowymi oraz listą produktów ICT, usług ICT i procesów ICT dostarczanych organizacji. Taki rejestr powinien być aktualizowany przy zmianach i okresowo przeglądany.
Wreszcie, podejście ENISA bardzo mocno łączy zakupy ICT z cyberbezpieczeństwem. Bezpieczeństwo powinno być obecne już na etapie opisu potrzeb, dokumentacji zakupowej, wymagań wobec wykonawcy, kryteriów oceny ofert, projektowanych postanowień umowy, odbiorów, testów i późniejszego nadzoru nad realizacją.
Najprostsza zasada wdrożeniowa brzmi: każdy krytyczny dostawca powinien być znany, sklasyfikowany, oceniony, objęty wymaganiami umownymi, monitorowany, testowany pod kątem ciągłości działania oraz uwzględniony w procedurach incydentowych i planach odtworzeniowych.
Sprzęt, oprogramowanie, usługi i SBOM
W przypadku sprzętu, oprogramowania i usług ICT istotne jest nie tylko to, kto jest dostawcą, ale również co faktycznie jest dostarczane. Organizacja powinna wiedzieć, jakie komponenty, biblioteki, moduły, zależności, wersje i mechanizmy aktualizacji tworzą produkt lub usługę wykorzystywaną do świadczenia usługi.
W tym kontekście coraz większe znaczenie ma SBOM, czyli wykaz komponentów oprogramowania. SBOM nie jest samodzielną analizą ryzyka i nie zastępuje testów bezpieczeństwa, ale pozwala szybciej ustalić, czy podatność w bibliotece, frameworku, kontenerze, pakiecie lub komponencie open source wpływa na system wykorzystywany przez organizację.
Dla systemów krytycznych warto wymagać od dostawców informacji o komponentach, procesie aktualizacji, sposobie obsługi podatności, źródłach oprogramowania, bezpieczeństwie repozytoriów, testach bezpieczeństwa, integralności dostarczanych komponentów i zasadach wprowadzania zmian.
Chmura jako szczególny przypadek łańcucha dostaw
Usługi chmurowe są jednym z najważniejszych i jednocześnie najbardziej złożonych elementów łańcucha dostaw ICT. Klient często ma ograniczoną możliwość negocjowania warunków, ograniczony wgląd w techniczną realizację usługi i ograniczoną kontrolę nad lokalizacją danych, dostępem administratorów, podwykonawcami, logami, zmianami oraz usuwaniem danych.
Nie oznacza to jednak, że odpowiedzialność organizacji znika. Wręcz przeciwnie — organizacja powinna rozumieć model współodpowiedzialności, wiedzieć, które zabezpieczenia zapewnia dostawca, a które pozostają po stronie klienta. Powinna również ocenić lokalizację i transfer danych, backup, odtwarzanie, SLA, powiadamianie o incydentach, dostęp uprzywilejowany, separację tenantów, certyfikaty, raporty audytowe, exit plan oraz sposób usunięcia danych po zakończeniu korzystania z usługi.
W praktyce chmura powinna być traktowana nie jako „zewnętrzna infrastruktura”, lecz jako krytyczna zależność operacyjna, prawna i bezpieczeństwa.
AI jako nowy element łańcucha dostaw ICT
Sztuczna inteligencja coraz częściej staje się częścią produktów ICT, usług ICT i procesów ICT. Dotyczy to systemów SOC/SIEM, EDR/XDR, narzędzi do analizy podatności, systemów antyfraudowych, automatyzacji obsługi zgłoszeń, chatbotów, klasyfikacji dokumentów, monitoringu infrastruktury, narzędzi wspierających decyzje operacyjne oraz usług chmurowych opartych na modelach AI.
Jeżeli AI wspiera usługę, proces lub system wykorzystywany przez podmiot kluczowy albo ważny, powinna być traktowana jako część łańcucha dostaw ICT. Ryzyko nie dotyczy wtedy wyłącznie aplikacji lub infrastruktury, ale również modelu AI, dostawcy modelu, danych treningowych, danych wejściowych i wyjściowych, promptów, konfiguracji, API, logów, integracji oraz zmian wprowadzanych przez dostawcę.
W Unii Europejskiej dodatkowe znaczenie ma AI Act. Komisja Europejska wskazuje, że AI Act wszedł w życie 1 sierpnia 2024 r. i co do zasady ma być w pełni stosowany od 2 sierpnia 2026 r., z wyjątkami przewidzianymi w harmonogramie stosowania. Harmonogram należy monitorować w aktualnych źródłach UE.
Z perspektywy łańcucha dostaw szczególnie istotne są pytania: czy dostawca używa AI, w jakim celu, czy dane klienta są wykorzystywane do trenowania modelu, gdzie są przetwarzane, kto ma do nich dostęp, czy model może być zmieniony bez zgody klienta, czy istnieje możliwość uzasadnienia wyniku, czy system ma tryb awaryjny oraz czy człowiek zachowuje realny nadzór nad decyzją lub rekomendacją AI.
Ryzyka AI, które trzeba uwzględnić w zarządzaniu dostawcami
Ryzyka AI powinny być włączone do oceny ryzyka dostawców, BIA, wymagań umownych, procedur incydentowych i planów ciągłości działania. Szczególne znaczenie mają: zależność od dostawcy modelu, vendor lock-in, niekontrolowane zmiany modelu, prompt injection, data poisoning, model evasion, ujawnienie danych, brak możliwości uzasadnienia wyniku, automatyzacja bez nadzoru człowieka i brak planu awaryjnego.
Dla krytycznych zastosowań AI organizacja powinna przewidzieć procedurę awaryjną. Może to być ręczna weryfikacja, alternatywny kanał decyzyjny, możliwość wyłączenia automatyzacji, powrót do poprzedniej wersji modelu, wykorzystanie modelu zapasowego albo przełączenie na proces bez AI.
Jeżeli dostarczany lub wykorzystywany system AI kwalifikuje się jako system AI wysokiego ryzyka, należy dodatkowo uwzględnić obowiązki wynikające z AI Act, w szczególności dotyczące dokumentacji technicznej, rejestrowania zdarzeń, nadzoru człowieka, dokładności, odporności i cyberbezpieczeństwa. Art. 15 AI Act odnosi się do dokładności, odporności i cyberbezpieczeństwa systemów AI wysokiego ryzyka, w tym podatności specyficznych dla AI.
Zamówienia publiczne: bezpieczeństwo trzeba wbudować od początku
W przypadku podmiotów publicznych i zamawiających sektorowych bezpieczeństwo łańcucha dostaw powinno być elementem całego cyklu życia zamówienia. Nie powinno pojawiać się dopiero po wyborze wykonawcy ani ograniczać do ogólnej ankiety bezpieczeństwa.
Wymagania cyberbezpieczeństwa należy uwzględnić już na etapie analizy potrzeb, opisu przedmiotu zamówienia, warunków udziału, kryteriów oceny ofert, projektowanych postanowień umowy, odbiorów, testów, monitorowania realizacji, obsługi incydentów i zakończenia współpracy.
Dobrze przygotowane zamówienie powinno wskazywać wymagania dotyczące bezpieczeństwa informacji, ciągłości działania, podatności, incydentów, kopii zapasowych, odtwarzania, dostępu uprzywilejowanego, szyfrowania, monitorowania, lokalizacji danych, podwykonawców, AI, komponentów oprogramowania oraz exit planu.
Co powinno znaleźć się w umowie z dostawcą ICT
Umowa jest podstawowym narzędziem przeniesienia wymagań KSC, NIS2, ISO/IEC 27002, ISO 22301, ISO/IEC 27036, wytycznych ENISA i AI Act na relację operacyjną. Powinna być konkretna, mierzalna i audytowalna.
W umowie z krytycznym dostawcą ICT warto uwzględnić co najmniej:
- Bezpieczeństwo informacji – Obowiązek spełniania wymagań bezpieczeństwa organizacji.
- Podwykonawcy – Notyfikacja, zgoda lub kontrola oraz przeniesienie wymagań na dalszych dostawców.
- Incydenty – Obowiązek szybkiego powiadomienia i współpracy przy analizie.
- Podatności – Kanał zgłaszania, terminy usuwania, klasyfikacja i raportowanie.
- Ciągłość działania – RTO, RPO, backup, DR, redundancja i udział w ćwiczeniach.
- Audyt i dowody – Prawo audytu albo dostęp do raportów, certyfikatów i atestacji.
- AI – Opis użycia AI, danych, modeli, logów, nadzoru człowieka i trybu awaryjnego.
- Zmiany – Obowiązek informowania o zmianach wpływających na bezpieczeństwo lub ciągłość.
- Zakończenie współpracy – Exit plan, zwrot danych, usunięcie danych i cofnięcie dostępów
Dowody zgodności: czego będzie szukał audytor
Podmiot kluczowy lub ważny powinien być w stanie wykazać, że zarządzanie łańcuchem dostaw ICT działa w praktyce. Sama polityka nie wystarczy. Audytor będzie oczekiwał dowodów, że organizacja zna swoich dostawców, rozumie zależności, ocenia ryzyka, egzekwuje wymagania, monitoruje poziom usług i potrafi reagować na zakłócenia.
Najważniejsze dowody to: polityka bezpieczeństwa łańcucha dostaw ICT, rejestr bezpośrednich dostawców i usługodawców, mapa zależności ICT, klasyfikacja dostawców według ryzyka, ocena ryzyka dostawców, BIA, umowy i SLA, załączniki bezpieczeństwa, raporty z audytów, certyfikaty, wyniki testów, rejestr incydentów dostawczych, plan działań korygujących, exit plan, dokumentacja AI, wyniki testów bezpieczeństwa AI oraz dowody przeglądu polityki i rejestrów.
Warto pamiętać, że dowód zgodności powinien pokazywać działanie procesu, a nie tylko jego opis. Dlatego większą wartość audytową ma aktualny rejestr dostawców z przypisaną krytycznością, wynikiem oceny ryzyka, właścicielem relacji, SLA i terminem przeglądu niż sama ogólna procedura zarządzania dostawcami.
Wnioski
Bezpieczeństwo i ciągłość łańcucha dostaw ICT wymagają zintegrowanego podejścia. KSC i NIS2 wzmacniają obowiązek zarządzania ryzykiem dostawców, ISO/IEC 27002 dostarcza katalogu zabezpieczeń, ISO 22301 porządkuje ciągłość działania, ISO/IEC 27036 opisuje cykl życia relacji z dostawcami, ENISA pokazuje praktyczne działania i dowody, a AI Act wprowadza dodatkowy wymiar nadzoru nad systemami sztucznej inteligencji.
Organizacja powinna wiedzieć, od których dostawców zależy świadczenie jej usług, jakie są dalsze zależności w łańcuchu dostaw, jakie ryzyka z nich wynikają, jakie wymagania postawiono dostawcom, jakie dowody otrzymano i jak zachowa ciągłość działania, jeżeli dostawca, produkt ICT, usługa ICT, proces ICT albo komponent AI staną się niedostępne, podatne, niezgodne lub niemożliwe do dalszego używania.
Łańcuch dostaw ICT nie jest już dodatkiem do cyberbezpieczeństwa. Jest jednym z jego kluczowych obszarów.
