Mapowanie NIS2 2024/2690 na ISO 27001 dla dostawców usług chmurowych

We wtorek o 08:17 Maria, dyrektor ds. bezpieczeństwa informacji europejskiego dostawcy usług zarządzanych, otrzymuje alert, którego obawia się każdy MSP. Jedno uprzywilejowane konto zdalnego zarządzania wygenerowało alerty logowań z niemożliwych lokalizacji. W dwóch tenantach klientów widać anomalne działania administracyjne. SOC uruchomił już telekonferencję kryzysową dla incydentu krytycznego.

O 09:00 do połączenia dołącza prezes zarządu. Pytania natychmiast się zmieniają.

Czy jesteśmy objęci zakresem NIS2? Czy ma do nas zastosowanie rozporządzenie wykonawcze Komisji (UE) 2024/2690? Czy musimy przekazać wczesne ostrzeżenie w ciągu 24 godzin? Których klientów należy powiadomić? Czy potrafimy wykazać, że MFA, rejestrowanie, segmentacja, zarządzanie podatnościami, kontrole dostawców i eskalacja incydentów działały przed incydentem?

Firma Marii posiada certyfikat ISO/IEC 27001:2022. Świadczy klientom usługi zarządzania chmurą, usługi centrów danych oraz zarządzane usługi wsparcia bezpieczeństwa, w tym dla dostawcy logistycznego i banku regionalnego. Certyfikat ma znaczenie, ale sam w sobie nie odpowiada na pytania operacyjne. Zespół prawny ma projekt procesu powiadamiania. Menedżer ds. zgodności ma arkusz kalkulacyjny. Audytor poprosił o Deklarację stosowania, testy reagowania na incydenty, logi dostępu uprzywilejowanego, due diligence dostawców, dowody wspólnej odpowiedzialności w chmurze oraz założenia dotyczące ciągłości działania.

To moment, w którym NIS2 przestaje być tekstem prawnym, a staje się problemem operacyjnych zabezpieczeń.

Dla dostawców usług chmurowych, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa i dostawców centrów danych NIS2 oraz rozporządzenie wykonawcze 2024/2690 podnoszą poprzeczkę: od ogólnej deklaracji bezpieczeństwa do weryfikowalnych dowodów działania zabezpieczeń. Ład, zarządzanie ryzykiem, kontrola dostępu, zarządzanie aktywami, obsługa podatności, reagowanie na incydenty, bezpieczeństwo dostawców, rejestrowanie, monitorowanie, szyfrowanie, ciągłość działania i odporność fizyczna muszą funkcjonować jako jeden system.

ISO/IEC 27001:2022 jest najlepszym fundamentem takiego systemu, ale tylko wtedy, gdy organizacja mapuje wymagania NIS2 na SZBI, rejestr ryzyk, Deklarację stosowania, polityki i model dowodowy. Certyfikat na ścianie nie wystarczy. Rzeczywista praca polega na zbudowaniu audytowalnej ścieżki identyfikowalności: od regulacji do ryzyka, od ryzyka do zabezpieczenia, od zabezpieczenia do polityki oraz od polityki do dowodów operacyjnych.

Dlaczego NIS2 2024/2690 zmienia rozmowę o zgodności w chmurze i MSP

NIS2 stosuje model sektorowo-wielkościowy, ale kategorie infrastruktury cyfrowej i zarządzania usługami ICT są celowo szerokie. Zgodnie z NIS2 Article 2 i Article 3, czytanymi łącznie z Annex I i Annex II, wiele organizacji może zostać zaklasyfikowanych jako podmioty kluczowe albo ważne, w tym dostawcy usług chmurowych, dostawcy usług centrów danych, dostawcy usług zarządzanych, dostawcy zarządzanych usług bezpieczeństwa, dostawcy DNS, rejestry TLD, sieci dostarczania treści oraz dostawcy usług zaufania. Państwa członkowskie muszą ustanowić i okresowo przeglądać wykazy podmiotów kluczowych i ważnych, przy czym pierwszy termin sporządzenia wykazu przypada na 17 kwietnia 2025 r.

Ma to znaczenie, ponieważ dostawcy usług chmurowych, MSP, MSSP i centrów danych są częścią łańcuchów ryzyka innych organizacji. Naruszenie bezpieczeństwa płaszczyzny sterowania chmury może wpłynąć na tysiące systemów klientów. Niedostępność centrum danych może kaskadowo uderzyć w bankowość, ochronę zdrowia, logistykę i administrację publiczną. Naruszenie poświadczeń MSP może stać się wieloklienckim zdarzeniem ransomware. Nieskuteczna detekcja po stronie MSSP może opóźnić powstrzymanie incydentu u klientów regulowanych.

NIS2 Article 20 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem w cyberbezpieczeństwie i nadzorowały ich wdrożenie. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych opartych na podejściu obejmującym wszystkie zagrożenia. Bazowy zakres obejmuje analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie i rozwój, obsługę i ujawnianie podatności, ocenę skuteczności, cyberhigienę, szkolenia, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami, MFA lub ciągłe uwierzytelnianie, bezpieczną komunikację i komunikację awaryjną.

Article 23 dodaje etapowe zgłaszanie istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, 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 albo od zakończenia obsługi incydentu, jeżeli incydent nadal trwa.

Rozporządzenie wykonawcze 2024/2690 konkretyzuje te oczekiwania wobec właściwych dostawców cyfrowych. W praktyce organy, klienci i audytorzy będą pytać nie tylko o to, czy polityki istnieją. Będą pytać, czy zabezpieczenia są zmapowane, mają właścicieli, są testowane i potwierdzone dowodami.

ISO/IEC 27001:2022 przekształca NIS2 w kontekst operacyjny SZBI

Częstym błędem w przygotowaniach do NIS2 jest rozpoczęcie od obszernej listy kontrolnej i rozdzielenie zadań między IT, dział prawny, SOC, infrastrukturę, zarządzanie dostawcami i zgodność. Może to wygenerować aktywność, ale często nie wytrzymuje audytu, ponieważ nikt nie potrafi wykazać, dlaczego wybrano dane zabezpieczenia, jak odnoszą się do ryzyka, kto zaakceptował ryzyko rezydualne i jakie dowody potwierdzają skuteczność.

ISO/IEC 27001:2022 daje dostawcom strukturę pozwalającą uniknąć takiego niepowodzenia.

Klauzule 4.1–4.4 wymagają, aby organizacja określiła czynniki wewnętrzne i zewnętrzne, zidentyfikowała zainteresowane strony oraz ich wymagania, zdecydowała, które wymagania będą adresowane przez SZBI, i zdefiniowała zakres SZBI, w tym interfejsy oraz zależności. W przypadku dostawcy usług chmurowych lub MSP zakres powinien wprost uwzględniać NIS2, rozporządzenie wykonawcze 2024/2690, harmonogramy bezpieczeństwa klientów, wymagania klientów wynikające z DORA, regiony chmurowe, podwykonawców, zależności od centrów danych, platformy zdalnego zarządzania, ścieżki dostępu uprzywilejowanego i obowiązki powiadamiania o incydentach.

Klauzule 5.1–5.3 wymagają przywództwa, dostosowania polityk, zasobów, komunikacji, przypisanych odpowiedzialności i rozliczalności kierownictwa. Bezpośrednio wspiera to NIS2 Article 20.

Klauzule 6.1.1–6.1.3 wymagają oceny ryzyka, postępowania z ryzykiem, właścicieli ryzyka, analizy prawdopodobieństwa i skutków, doboru zabezpieczeń, porównania z Załącznikiem A, Deklaracji stosowania, planu postępowania z ryzykiem oraz formalnej akceptacji ryzyka rezydualnego. To tutaj NIS2 staje się operacyjna. Każde wymaganie regulacyjne staje się czynnikiem ryzyka, obowiązkiem zgodności, wymaganiem dotyczącym zabezpieczenia albo wymaganiem dowodowym.

Clarysec rozpoczyna tę pracę od Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, zwłaszcza od fazy zarządzania ryzykiem.

Od kroku 13, planowania postępowania z ryzykiem i Deklaracji stosowania, Zenith Blueprint instruuje zespoły, aby budowały identyfikowalność między ryzykami, zabezpieczeniami i czynnikami regulacyjnymi:

„Odwołania krzyżowe do regulacji: jeżeli określone zabezpieczenia są wdrażane specjalnie w celu zapewnienia zgodności z GDPR, NIS2 lub DORA, można to odnotować w rejestrze ryzyk albo w notatkach SoA. Np. zabezpieczenie 8.27 (bezpieczne usuwanie danych) może być bardzo istotne dla wymogu GDPR dotyczącego usuwania danych osobowych; można odnotować: „Ma zastosowanie – wspiera GDPR Art.32 (bezpieczeństwo przetwarzania)”. Nie jest to wymagane przez ISO, ale pomaga wykazać, że uwzględniono te ramy”.

Krok 14, polityki postępowania z ryzykiem i regulacyjne odwołania krzyżowe, dodaje praktyczną dyscyplinę mapowania:

„Dla każdej regulacji, jeśli ma zastosowanie, można utworzyć prostą tabelę mapowania, która wymienia kluczowe wymagania bezpieczeństwa danej regulacji oraz odpowiadające im zabezpieczenia/polityki w SZBI. Nie jest to obowiązkowe w ISO 27001, ale jest użytecznym ćwiczeniem wewnętrznym, które pomaga upewnić się, że nic nie zostało pominięte”.

Na tym polega różnica między stwierdzeniem „mamy certyfikat ISO” a wykazaniem, że „nasz SZBI ISO/IEC 27001:2022 adresuje rozporządzenie wykonawcze NIS2 2024/2690”.

Ujednolicona mapa zabezpieczeń NIS2 do ISO/IEC 27001:2022

Poniższe mapowanie nie stanowi porady prawnej ani nie zastępuje analizy krajowej transpozycji. Jest to praktyczna architektura zabezpieczeń dla dostawców, którzy potrzebują audytowalnej ścieżki ISO/IEC 27001:2022 do gotowości na NIS2.

Mapowanie staje się wartościowe, gdy zostanie osadzone w rejestrze ryzyk i Deklaracji stosowania. Przykładowo dostawca może utworzyć scenariusz ryzyka: „Naruszenie bezpieczeństwa platformy zdalnego zarządzania prowadzi do nieuprawnionych działań w środowiskach klientów”. Zabezpieczenia obejmują MFA, zarządzanie dostępem uprzywilejowanym, segmentację, rejestrowanie, zarządzanie podatnościami, bezpieczeństwo dostawców, planowanie incydentowe i procedury powiadamiania klientów. Notatki SoA mogą odwoływać się do NIS2 Article 21, Article 23, rozporządzenia wykonawczego 2024/2690, umów z klientami oraz wymagań due diligence klientów wynikających z DORA, jeżeli mają zastosowanie.

Ład chmurowy: zabezpieczenie ISO 5.23 jako kotwica NIS2

Dla dostawców usług chmurowych i MSP, którzy korzystają z usług chmurowych do świadczenia usług klientom, zabezpieczenie ISO/IEC 27001:2022 Załącznik A 5.23, Bezpieczeństwo informacji przy korzystaniu z usług chmurowych, jest jedną z najważniejszych kotwic.

Zenith Controls: The Cross-Compliance Guide Zenith Controls podsumowuje zabezpieczenie 5.23 jako zabezpieczenie prewencyjne wspierające poufność, integralność i dostępność, powiązane z bezpieczeństwem relacji z dostawcami, ładem, ryzykiem ekosystemu i ochroną. Obejmuje ład dla usług chmurowych, wspólną odpowiedzialność, ocenę dostawców, inwentarze, lokalizację danych, rejestrowanie, szyfrowanie, role tożsamościowe, monitorowanie, klauzule umowne, ryzyko dostawcy, wyjście z chmury i planowanie odporności.

Zenith Blueprint, w fazie „Zabezpieczenia w działaniu”, krok 23, wyjaśnia praktyczne uzasadnienie:

„Chmura obliczeniowa nie jest już miejscem docelowym, lecz stanem domyślnym. Zabezpieczenie 5.23 uznaje tę rzeczywistość i wymaga, aby bezpieczeństwo informacji było wprost uwzględniane przy wyborze, korzystaniu i zarządzaniu usługami chmurowymi — nie jako refleksja po fakcie, lecz jako zasada projektowa od samego początku”.

W przypadku MSP nadzorem muszą być objęte: każda platforma zdalnego monitorowania i zarządzania, portal klienta, narzędzie zgłoszeniowe, platforma telemetrii bezpieczeństwa, usługa kopii zapasowych, katalog chmurowy i konsola administracyjna SaaS. W przypadku dostawcy centrum danych ład chmurowy może dotyczyć platform monitorowania, systemów zarządzania gośćmi, integracji kontroli dostępu fizycznego, systemów zdalnego zarządzania i infrastruktury portalu klienta.

Polityka Enterprise Clarysec Cloud Usage Policy Cloud Usage Policy nakłada obowiązek przeprowadzenia due diligence przed aktywacją:

„Każde korzystanie z chmury obliczeniowej musi przed aktywacją przejść due diligence oparte na ryzyku, obejmujące ocenę dostawcy, walidację zgodności prawnej oraz przeglądy walidacji zabezpieczeń”.

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

Dla mniejszych dostawców Cloud Usage Policy-sme Cloud Usage Policy-sme - SME tworzy lekki model zatwierdzania:

„Każde korzystanie z usług chmurowych musi zostać przejrzane i zatwierdzone przez dyrektora generalnego (GM) przed wdrożeniem lub subskrypcją”.

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

Oba podejścia wspierają to samo oczekiwanie NIS2: ryzyko zależności od chmury musi być zrozumiane, zanim usługa stanie się częścią łańcucha świadczenia usług.

Reagowanie na incydenty: zegar 24-godzinny rusza przed przygotowaniem raportu

NIS2 Article 23 jest bezwzględny, ponieważ termin zgłoszenia biegnie od uzyskania wiedzy o istotnym incydencie, a nie od momentu, w którym dostępna jest pełna analiza przyczyny źródłowej. Wyzwanie dla dostawców polega na szybkim ustaleniu, czy zdarzenie jest istotne, których klientów dotyczy, czy obejmuje dane osobowe, czy występuje transgraniczny wpływ na świadczenie usług i które terminy umowne zaczęły biec.

Zabezpieczenie ISO/IEC 27001:2022 Załącznik A 5.24, Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji, jest zabezpieczeniem planistycznym. Zenith Controls podsumowuje je jako zabezpieczenie korygujące wspierające poufność, integralność i dostępność, powiązane z funkcjami Respond i Recover, ładem, zarządzaniem zdarzeniami i obroną. Obejmuje role, odpowiedzialności, ścieżki eskalacji, protokoły komunikacyjne, gotowość do powiadomień regulacyjnych, dostosowanie do rejestrowania i monitorowania, integrację z ciągłością działania i odtwarzaniem po awarii, uczenie się po incydencie oraz mapowanie do NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 i COBIT 2019.

Incident Response Policy-sme Clarysec Incident Response Policy-sme - SME przekształca pierwszą decyzję w wymaganie ograniczone czasowo:

„Dyrektor generalny, przy wsparciu dostawcy IT, musi sklasyfikować wszystkie incydenty według wagi w ciągu jednej godziny od powiadomienia”.

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

Taka klasyfikacja w ciągu jednej godziny wspiera dyscyplinę operacyjną potrzebną do analizy 24-godzinnego wczesnego ostrzeżenia NIS2, oceny naruszenia ochrony danych osobowych zgodnie z GDPR, eskalacji do klientów w kontekście DORA i triage powiadomień umownych.

Drzewo decyzyjne incydentu u dostawcy powinno odpowiadać na cztery pytania:

1. Czy doszło do potwierdzonego lub podejrzewanego naruszenia poufności, integralności lub dostępności?
2. Czy zdarzenie wpływa na świadczenie usług, środowiska klientów, klientów regulowanych, dane osobowe lub funkcje krytyczne?
3. Czy może spowodować poważne zakłócenie operacyjne, stratę finansową albo szkodę materialną lub niematerialną?
4. Jakie obowiązki powiadomieniowe mają zastosowanie: NIS2, GDPR, obowiązki klientów wynikające z DORA, umowne SLA czy oczekiwania krajowego organu regulacyjnego?

Drzewo decyzyjne należy przetestować w ćwiczeniach tabletop przed rzeczywistym incydentem.

Zarządzanie podatnościami: wykazanie redukcji ryzyka przed wystąpieniem wpływu

NIS2 wymaga obsługi i ujawniania podatności. Dla klientów i organów regulacyjnych zarządzanie podatnościami jest jednym z najłatwiejszych do pomiaru obszarów kontroli, ponieważ generuje jednoznaczne dowody: pokrycie skanowaniem, terminy wdrażania poprawek, zatwierdzenia wyjątków, analizę wykorzystanych podatności i zapisy działań naprawczych.

Zabezpieczenie ISO/IEC 27001:2022 Załącznik A 8.8, Zarządzanie podatnościami technicznymi, jest w Zenith Controls podsumowane jako zabezpieczenie prewencyjne obejmujące poufność, integralność i dostępność, powiązane z Identify i Protect, zarządzaniem zagrożeniami i podatnościami, ładem, ekosystemem, ochroną i obroną. Obejmuje identyfikację podatności, ocenę, priorytetyzację, wdrażanie poprawek, środki kompensujące, integrację z informacjami o zagrożeniach, ujawnianie podatności, odpowiedzialności za podatności chmury i aplikacji, dowody audytowe oraz terminy działań naprawczych.

Polityka Enterprise Clarysec Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy daje audytorom konkretny model do przetestowania:

„Organizacja musi klasyfikować wszystkie wykryte podatności przy użyciu ustandaryzowanej metodyki (np. CVSS v3.x) i stosować terminy działań naprawczych dostosowane do krytyczności biznesowej: 5.2.1 Krytyczne (CVSS 9.0-10.0): natychmiastowy przegląd; termin wdrożenia poprawki maksymalnie 72 godziny. 5.2.2 Wysokie (7.0-8.9): reakcja w ciągu 48 godzin; termin wdrożenia poprawki 7 dni kalendarzowych. 5.2.3 Średnie (4.0-6.9): reakcja w ciągu 5 dni; termin wdrożenia poprawki 30 dni kalendarzowych. 5.2.4 Niskie (<4.0): reakcja w ciągu 10 dni; termin wdrożenia poprawki 60 dni kalendarzowych”.

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

W przypadku dostawcy usług chmurowych musi to obejmować komponenty hipernadzorcy, obrazy kontenerów, warstwy orkiestracji, interfejsy API dostępne dla klientów, potoki CI/CD, konsole administracyjne i biblioteki stron trzecich. W przypadku MSP kluczowe pytanie brzmi, czy podatności wewnętrzne są oddzielone od podatności zarządzanych przez klientów i czy umowy definiują odpowiedzialność. W przypadku dostawcy centrum danych zakres może obejmować systemy zarządzania budynkiem, systemy kontroli dostępu, platformy monitorowania, narzędzia remote hands i infrastrukturę sieciową.

Model wspólnej odpowiedzialności musi być udokumentowany. Dostawca może nie być właścicielem każdej poprawki, ale nadal musi zarządzać ryzykiem, powiadamiać klienta tam, gdzie jest to właściwe, i wykazać, że granice odpowiedzialności są rozumiane.

Rejestrowanie, monitorowanie i segmentacja umożliwiają dochodzenie incydentów

Gdy incydent u dostawcy zaczyna wpływać na klientów, pierwsze pytania dowodowe są proste: kto się zalogował, skąd, z jakimi uprawnieniami, do którego tenanta, co zmienił, jakie logi istnieją i czy ścieżki administracyjne były segmentowane.

Polityka Enterprise Clarysec Logging and Monitoring Policy Logging and Monitoring Policy wymaga, aby objęte nią systemy generowały logi potrzebne zespołom reagowania i audytorom:

„Wszystkie objęte systemy muszą generować logi rejestrujące: 6.1.1.1 Próby uwierzytelniania użytkowników i dostępu 6.1.1.2 Działania użytkowników uprzywilejowanych 6.1.1.3 Zmiany konfiguracji 6.1.1.4 Nieudane próby dostępu lub zdarzenia systemowe 6.1.1.5 Wykrycia złośliwego oprogramowania i alerty bezpieczeństwa 6.1.1.6 Komunikację zewnętrzną i wyzwolenia reguł zapory sieciowej”.

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

Dla MŚP polegających na podmiotach zewnętrznych Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME dodaje wymaganie umowne:

„Umowy muszą wymagać od dostawców przechowywania logów przez co najmniej 12 miesięcy oraz zapewnienia dostępu na żądanie”.

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

Segmentacja jest równie istotna. Network Security Policy-sme Network Security Policy-sme - SME stanowi:

„Sieci wewnętrzne muszą być segmentowane według funkcji (np. finanse, goście, IoT, systemy administracyjne)”.

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

Zenith Blueprint, w fazie „Zabezpieczenia w działaniu”, krok 20, podaje praktyczną procedurę audytu architektury sieci i segmentacji. Instruuje zespoły, aby przeglądały i dokumentowały układ sieci, weryfikowały reguły zapory sieciowej, konfiguracje IPS/IDS i dostępu zdalnego, potwierdzały, że grupy bezpieczeństwa w chmurze oraz reguły VPC lub podsieci odpowiadają zamierzonej architekturze, wykazywały wewnętrzne i zewnętrzne usługi sieciowe oraz walidowały, że systemy wrażliwe nie są osiągalne z ogólnych VLAN użytkowników ani sieci gościnnych.

W przypadku MSP narzędzia zdalnego zarządzania nie mogą działać w płaskiej sieci biurowej. W przypadku dostawcy centrum danych interfejsy zarządzania zasilaniem, chłodzeniem, kontrolą dostępu i usługami sieciowymi klientów powinny być izolowane i monitorowane. W przypadku dostawcy usług chmurowych dostęp do płaszczyzny sterowania powinien być ograniczony przez tożsamość, sieć, stan bezpieczeństwa urządzenia i mechanizmy kontroli przepływów pracy uprzywilejowanej.

Bezpieczeństwo dostawców: dostawca jest również klientem

Dostawcy usług chmurowych, MSP, MSSP i centrów danych są dostawcami dla klientów regulowanych, ale sami są również klientami dostawców oprogramowania, operatorów telekomunikacyjnych, dostawców tożsamości, platform SaaS, dostawców sprzętu, podwykonawców i operatorów infrastruktury.

NIS2 czyni bezpieczeństwo łańcucha dostaw wymaganiem podstawowym. DORA, stosowane od 17 stycznia 2025 r., stawia zarządzanie ryzykiem ICT stron trzecich w centrum wymagań dla podmiotów finansowych. NIS2 Article 4 i Recital 28 uznają DORA za sektorowy akt prawny Unii dla podmiotów finansowych tam, gdzie wymagania się pokrywają. Nie zmniejsza to presji na dostawców usług chmurowych i MSP. Zwiększa ją, ponieważ klienci finansowi przenoszą do umów z dostawcami wymagania na poziomie DORA: prawa do audytu, testowanie odporności, strategie wyjścia i oczekiwania dotyczące zgłaszania incydentów.

Polityka Enterprise Clarysec Third party and supplier security policy Third party and supplier security policy wymaga kontrolowanego dostępu stron trzecich:

„Każdy dostęp stron trzecich musi być logowany i monitorowany oraz, tam gdzie jest to wykonalne, segmentowany przez hosty bastionowe, VPN lub bramy Zero Trust”.

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

Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME wyraża zasadę najmniejszych uprawnień wprost:

„Dostawcom należy nadawać dostęp wyłącznie do minimalnego zakresu systemów i danych wymaganych do wykonania ich funkcji”.

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

Te klauzule naturalnie mapują się na zabezpieczenia ISO/IEC 27001:2022 Załącznik A 5.19, 5.20, 5.21 i 5.22. Wspierają również zarządzanie podmiotami przetwarzającymi i podwykonawcami przetwarzania w GDPR, przeglądy ryzyka stron trzecich w DORA oraz kwestionariusze audytowe klientów.

Ciągłość działania i odporność centrum danych: wykazanie założeń

NIS2 Article 21 obejmuje ciągłość działania, zarządzanie kopiami zapasowymi, odtwarzanie po awarii i zarządzanie kryzysowe. DORA Articles 11–14 wymagają od podmiotów finansowych polityk ciągłości działania ICT, planów reagowania i odzyskiwania, analizy wpływu na biznes, polityk kopii zapasowych, procedur odtwarzania, celów odzyskiwania, testowania, przeglądów po incydencie oraz komunikacji kryzysowej.

Dla dostawców usług chmurowych i centrów danych ciągłość nie jest segregatorem. To architektura, przepustowość, umowy, zależności, dowody odtworzenia i przetestowane założenia.

Polityka Enterprise Clarysec Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy wymaga corocznej BIA oraz przeglądu po istotnych zmianach:

„Analiza wpływu na biznes (BIA) musi być wykonywana co najmniej raz w roku dla wszystkich krytycznych jednostek biznesowych i przeglądana po istotnych zmianach w systemach, procesach lub zależnościach. Wyniki BIA muszą określać: 5.2.1. Maksymalny tolerowany czas niedostępności (MTD) 5.2.2. Docelowe czasy odtworzenia (RTO) 5.2.3. Docelowe punkty odtworzenia (RPO) 5.2.4. Krytyczne zależności (systemy, dostawcy, personel)”.

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

W scenariuszu centrum danych BIA powinna obejmować linie zasilania, UPS, generatory, umowy paliwowe, chłodzenie, gaszenie pożaru, operatorów sieci, systemy dostępu fizycznego, remote hands, monitorowanie, sprzęt zapasowy i kanały komunikacji z klientami. W scenariuszu chmurowym powinna obejmować regiony, strefy dostępności, replikację, niemodyfikowalność kopii zapasowych, zależności tożsamościowe, DNS, urzędy certyfikacji, bramy API i systemy wsparcia. W scenariuszu MSP powinna obejmować narzędzia zdalnego zarządzania, skarbce dostępu uprzywilejowanego, konsole EDR, system zgłoszeniowy, repozytoria dokumentów i komunikację awaryjną.

ISO 22301 może wzmocnić dyscyplinę zarządzania ciągłością działania, a ISO/IEC 27005:2022 wspiera kryteria ryzyka, planowanie postępowania, monitorowanie, dowody i ciągłe doskonalenie. Jest to użyteczne, ponieważ gotowość do NIS2 wymaga od organizacji skonsolidowania czynników prawnych, umownych, operacyjnych, dostawczych, technologicznych, finansowych, procesowych i ludzkich w jednym procesie ryzyka.

Praktyczna ścieżka ryzyka dla naruszenia dostępu zdalnego MSP

Praktyczny warsztat można rozpocząć od jednego scenariusza:

„Naruszenie bezpieczeństwa uprzywilejowanego dostępu zdalnego skutkuje nieuprawnionym dostępem do systemów klientów, zakłóceniem usługi, możliwym ujawnieniem danych osobowych i obowiązkami zgłoszeń regulacyjnych”.

Utwórz wiersz w rejestrze ryzyk i uzupełnij ścieżkę.

Następnie zaktualizuj Deklarację stosowania. Dla każdego właściwego zabezpieczenia z Załącznika A wyjaśnij, dlaczego ma zastosowanie i jaki temat NIS2 wspiera. Na koniec zgromadź dowody przed audytem: raporty egzekwowania MFA, listy kont uprzywilejowanych, ustawienia przechowywania logów, status poprawek RMM, alerty SIEM, zapisy klasyfikacji incydentów, zatwierdzenia dostępu dostawców i wyniki ćwiczeń tabletop.

Jak różni audytorzy przetestują to samo środowisko kontroli

Zintegrowany SZBI musi zaspokoić różne perspektywy zapewnienia bez tworzenia oddzielnych pakietów dowodowych dla każdej struktury.

W tym miejscu Zenith Controls pomaga jako przewodnik cross-compliance. Dla zabezpieczeń takich jak 5.23, 5.24 i 8.8 łączy oczekiwania kontrolne ISO/IEC 27001:2022 z tematami NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF i ISO 22301. Celem nie jest tworzenie oddzielnych programów zgodności. Celem jest jedna architektura dowodowa oznaczona według zabezpieczenia, ryzyka, czynnika regulacyjnego i właściciela.

Wzorzec wdrożenia Clarysec

Dla dostawców usług chmurowych, MSP, MSSP i centrów danych prace powinny przebiegać w pięciu warstwach.

Po pierwsze, potwierdź zakres. Ustal, czy organizacja i usługi mieszczą się w zakresie NIS2, które przepisy państwa członkowskiego mają zastosowanie, czy rozporządzenie wykonawcze 2024/2690 dotyczy danej kategorii dostawcy oraz czy klienci nakładają obowiązki wynikające z DORA, GDPR, NIST lub regulacji sektorowych.

Po drugie, zbuduj kontekst SZBI. Zgodnie z klauzulami 4 i 5 ISO/IEC 27001:2022 zidentyfikuj zainteresowane strony, obowiązki prawne, zobowiązania wobec klientów, zależności od dostawców, granice usług i odpowiedzialności kierownictwa.

Po trzecie, przeprowadź ocenę ryzyka i postępowanie z ryzykiem z wykorzystaniem zasad ISO/IEC 27005:2022. Skonsoliduj NIS2, DORA, GDPR, umowy, polityki wewnętrzne i ryzyka usług w jednym rejestrze wymagań bazowych. Zdefiniuj kryteria ryzyka, właścicieli, prawdopodobieństwo, wpływ, opcje postępowania, wybory zabezpieczeń i zatwierdzenia ryzyka rezydualnego.

Po czwarte, zmapuj zabezpieczenia do Deklaracji stosowania. Użyj kroków 13 i 14 Zenith Blueprint, aby powiązać ryzyka z zabezpieczeniami z Załącznika A i oczekiwaniami regulacyjnymi. Użyj Zenith Controls, aby zrozumieć, jak zabezpieczenia takie jak 5.23, 5.24, 8.8, 5.20 i 5.30 mapują się na frameworki i perspektywy audytowe.

Po piąte, operacjonalizuj dowody. Polityki nie wystarczą. Biblioteka polityk Clarysec zapewnia egzekwowalne wymagania dotyczące zatwierdzania korzystania z chmury, dostępu dostawców, rejestrowania, usuwania podatności, segmentacji sieci, klasyfikacji incydentów i planowania ciągłości. Pakiet dowodowy potwierdza, że wymagania działają.

Następny krok: przekształcenie presji NIS2 w odporność gotową do audytu

Rozporządzenie wykonawcze NIS2 2024/2690 nie wymaga chaosu. Wymaga identyfikowalności, własności i dowodów.

Jeżeli jesteś dostawcą usług chmurowych, MSP, MSSP lub operatorem centrum danych, zacznij od swoich usług, klientów, zależności, scenariuszy incydentów i obowiązków dowodowych. Następnie przeprowadź ustrukturyzowane ćwiczenie mapowania NIS2 do ISO/IEC 27001:2022:

1. Potwierdź, czy Twój podmiot i usługi mieszczą się w zakresie.
2. Zmapuj tematy NIS2 i rozporządzenia wykonawczego do zakresu SZBI.
3. Zaktualizuj rejestr ryzyk i Deklarację stosowania.
4. Zastosuj polityki Clarysec dotyczące korzystania z chmury, bezpieczeństwa dostawców, rejestrowania, zarządzania podatnościami, reagowania na incydenty, bezpieczeństwa sieci i ciągłości.
5. Użyj kroków 13, 14, 20 i 23 Zenith Blueprint Zenith Blueprint, aby utworzyć identyfikowalność i dowody operacyjne.
6. Użyj Zenith Controls Zenith Controls, aby zmapować zabezpieczenia ISO/IEC 27001:2022 na oczekiwania NIS2, DORA, GDPR, NIST i COBIT 2019.
7. Przetestuj dowody w symulacji audytu, zanim poprosi o nie klient, organ regulacyjny lub audytor certyfikujący.

Clarysec może pomóc wyjść poza zgodność opartą na listach kontrolnych i zbudować zintegrowany SZBI odporny na presję NIS2, DORA, GDPR i audytów klienckich. Pobierz odpowiednie zestawy narzędzi Clarysec, zarezerwuj warsztat mapowania albo zamów ocenę gotowości do audytu, aby przekształcić złożoność regulacyjną w obronny ład bezpieczeństwa i odporność operacyjną.