Bezpieczeństwo OT w NIS2: mapowanie ISO 27001 i IEC 62443

O 02:17 w poniedziałek operator stacji uzdatniania wody otrzymuje alarm z systemu dozowania. Podawanie substancji chemicznej pozostaje w granicach bezpieczeństwa, ale jeden PLC zgłasza nieregularne polecenia, stacja inżynierska pokazuje nieudane logowania z konta VPN dostawcy, a dyżurny analityk SOC zadaje pytanie, na które nikt nie chce odpowiadać pod presją.

Czy jest to incydent IT, incydent OT, zdarzenie dotyczące bezpieczeństwa funkcjonalnego, czy istotny incydent podlegający zgłoszeniu zgodnie z NIS2?

Zakład ma zapory sieciowe. Ma dokumentację ISO. Ma arkusz kalkulacyjny z dostawcami. Ma nawet plan reagowania na incydenty. Tyle że plan napisano z myślą o naruszeniu poczty elektronicznej i niedostępności usług chmurowych, a nie o sterowniku legacy, dla którego nie można wdrożyć poprawek w trakcie produkcji, dostawcy potrzebującym dostępu zdalnego do przywrócenia usługi oraz organie regulacyjnym oczekującym dowodów w terminach raportowania NIS2.

Ten sam problem pojawia się w salach zarządów. CISO u regionalnego dostawcy energii może mieć certyfikowany zgodnie z ISO/IEC 27001:2022 System Zarządzania Bezpieczeństwem Informacji dla korporacyjnego IT, podczas gdy środowisko technologii operacyjnej pozostaje plątaniną PLC, RTU, HMI, serwerów historian, stacji inżynierskich, przemysłowych przełączników i ścieżek dostępu dostawców. Pytanie CEO jest proste: „Czy jesteśmy zabezpieczeni? Czy potrafisz to udowodnić?”

Dla wielu podmiotów kluczowych i ważnych uczciwa odpowiedź jest niewygodna. Są częściowo zabezpieczone. Potrafią to częściowo wykazać. Jednak bezpieczeństwo OT w NIS2 wymaga więcej niż ogólnej zgodności IT.

Wymaga jednolitego modelu operacyjnego, który łączy ład ISO/IEC 27001:2022, język zabezpieczeń ISO/IEC 27002:2022, praktyki inżynierii przemysłowej IEC 62443, środki zarządzania ryzykiem cyberbezpieczeństwa z NIS2 Article 21 oraz dowody zgłaszania incydentów z NIS2 Article 23.

Ten przewodnik buduje właśnie taki pomost.

Dlaczego bezpieczeństwo OT w NIS2 różni się od zwykłej zgodności IT

NIS2 ma zastosowanie do wielu podmiotów publicznych i prywatnych świadczących usługi objęte zakresem w UE, w tym do podmiotów kluczowych i ważnych w sektorach takich jak energia, transport, bankowość, infrastruktura rynków finansowych, ochrona zdrowia, woda pitna, ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT, administracja publiczna, sektor kosmiczny, usługi pocztowe, gospodarowanie odpadami, produkcja, chemikalia, żywność, dostawcy cyfrowi i badania.

Dyrektywa wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych służących zarządzaniu ryzykami cyberbezpieczeństwa, zapobieganiu wpływowi incydentów lub jego minimalizowaniu oraz ochronie ciągłości usług. Article 21 obejmuje podejście uwzględniające wszystkie zagrożenia i obejmuje analizę ryzyka, polityki bezpieczeństwa, obsługę incydentów, ciągłość działania, zarządzanie kryzysowe, bezpieczeństwo łańcucha dostaw, bezpieczne pozyskiwanie i utrzymanie, 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ę oraz, tam gdzie to właściwe, komunikację awaryjną.

Te wymagania brzmią znajomo dla zespołu ISO/IEC 27001:2022. W OT każde z nich działa inaczej.

Podatność w serwerze WWW często można usunąć w ciągu kilku dni. Podatność w sterowniku turbiny może wymagać walidacji dostawcy, okna serwisowego, przeglądu bezpieczeństwa funkcjonalnego i awaryjnych procedur operacyjnych. Laptop można odtworzyć. Produkcyjny HMI może zależeć od systemu operacyjnego legacy, ponieważ aplikacja przemysłowa nie została certyfikowana dla nowszej platformy. Podręcznik SOC może wskazywać „odizoluj hosta”, podczas gdy inżynier OT odpowie: „nie, dopóki nie wiemy, czy izolacja nie wpłynie na regulację ciśnienia”.

Różnica nie jest wyłącznie techniczna. IT zwykle priorytetyzuje poufność, integralność i dostępność. OT priorytetyzuje dostępność, integralność procesu i bezpieczeństwo funkcjonalne. Zabezpieczenie, które wprowadza opóźnienia, wymaga restartu lub przerywa proces fizyczny, może być niedopuszczalne bez zatwierdzenia inżynieryjnego.

NIS2 nie wyłącza OT z zarządzania ryzykiem cyberbezpieczeństwa. Oczekuje, że organizacja wykaże, iż zabezpieczenia są odpowiednie do ryzyka i proporcjonalne do realiów operacyjnych.

Stos zabezpieczeń: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 i IEC 62443

Możliwy do obrony program bezpieczeństwa OT w NIS2 zaczyna się od warstwowego stosu zabezpieczeń.

ISO/IEC 27001:2022 zapewnia system zarządzania. Wymaga, aby organizacja określiła kontekst, strony zainteresowane, obowiązki regulacyjne, zakres SZBI, interfejsy i zależności. Wymaga również odpowiedzialności kierownictwa, polityki bezpieczeństwa informacji, oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania, udokumentowanych informacji, audytu wewnętrznego, przeglądu zarządzania i ciągłego doskonalenia.

ISO/IEC 27002:2022 zapewnia słownik zabezpieczeń. Dla OT najważniejsze zabezpieczenia często obejmują bezpieczeństwo dostawców, zarządzanie ryzykiem łańcucha dostaw ICT, planowanie obsługi incydentów, gotowość ICT do ciągłości działania, wymagania prawne i umowne, zarządzanie aktywami, kontrolę dostępu, zarządzanie podatnościami, kopie zapasowe, rejestrowanie, monitorowanie, bezpieczeństwo sieci i segregację sieci.

IEC 62443 zapewnia model inżynierii bezpieczeństwa przemysłowego. Pomaga przełożyć wymagania systemu zarządzania na praktyki OT, takie jak strefy, kanały komunikacyjne, poziomy bezpieczeństwa, odpowiedzialności właściciela aktywów, odpowiedzialności integratora systemów, oczekiwania wobec dostawców produktów, ograniczenia dostępu zdalnego, zasada minimalnej funkcjonalności, zarządzanie cyklem życia kont, utwardzanie i kontrole cyklu życia.

Clarysec używa tego stosu, ponieważ pozwala uniknąć dwóch częstych błędów. Po pierwsze, zapobiega temu, aby wdrożenie ISO stało się zbyt ogólne dla OT. Po drugie, zapobiega oderwaniu prac inżynieryjnych IEC 62443 od odpowiedzialności zarządu, obowiązków raportowania NIS2 i dowodów audytowych.

Polityka bezpieczeństwa IoT / OT Clarysec wskazuje ten pomost bezpośrednio:

Aby zapewnić zgodność wszystkich wdrożeń z zabezpieczeniami ISO/IEC 27001 oraz mającymi zastosowanie wytycznymi sektorowymi (np. IEC 62443, ISO 27019, NIST SP 800-82).

To zdanie ma znaczenie. Polityka nie jest wyłącznie listą kontrolną utwardzania urządzeń. Łączy ład ISO, sektorowe wytyczne OT i bezpieczeństwo operacyjne.

Zacznij od zakresu: jaką usługę OT należy chronić?

Przed mapowaniem zabezpieczeń należy opisać usługę OT językiem biznesowym i regulacyjnym.

Kierownik zakładu może powiedzieć: „Obsługujemy linię pakującą”. Ocena NIS2 powinna powiedzieć: „Ten proces produkcyjny wspiera usługę kluczową lub ważną i zależy od PLC, HMI, stacji inżynierskich, serwerów historian, przemysłowych przełączników, zdalnego dostępu dostawcy, wykonawcy utrzymania, strumienia analitycznego w chmurze oraz korporacyjnej usługi tożsamości”.

Klauzule ISO/IEC 27001:2022 od 4.1 do 4.4 są przydatne, ponieważ wymuszają identyfikację zagadnień wewnętrznych i zewnętrznych, stron zainteresowanych, wymagań prawnych i umownych, granic SZBI, interfejsów i zależności. Dla bezpieczeństwa OT w NIS2 oznacza to mapowanie nie tylko sieci centrali, lecz także systemów przemysłowych i zależności usługowych wpływających na ciągłość, bezpieczeństwo funkcjonalne i świadczenie usług regulowanych.

NIST CSF 2.0 wzmacnia tę samą logikę. Jego funkcja GOVERN wymaga zrozumienia misji, interesariuszy, zależności, obowiązków prawnych i regulacyjnych, usług krytycznych oraz usług, od których zależy organizacja. Profile organizacyjne zapewniają praktyczną metodę określenia stanu bieżącego, zdefiniowania stanu docelowego, analizy luk i przygotowania spriorytetyzowanego planu działań.

Dla środowiska OT Clarysec zwykle zaczyna od pięciu pytań:

1. Jaką usługę regulowaną lub krytyczną wspiera to środowisko OT?
2. Jakie aktywa OT, sieci, przepływy danych i strony trzecie są wymagane dla tej usługi?
3. Jakie ograniczenia dotyczące bezpieczeństwa funkcjonalnego, dostępności i operacji wpływają na zabezpieczenia?
4. Jakie obowiązki prawne, umowne i sektorowe mają zastosowanie, w tym NIS2, GDPR, DORA tam, gdzie są relewantne, umowy z klientami i przepisy krajowe?
5. Które części środowiska znajdują się w zakresie SZBI, a które są zależnościami zewnętrznymi wymagającymi kontroli dostawców?

Wiele programów NIS2 zawodzi właśnie tutaj. Określają zakres wokół korporacyjnego IT, ponieważ łatwiej je zinwentaryzować. Audytorzy i regulatorzy nie będą pod wrażeniem, jeżeli najbardziej krytyczna zależność usługowa występuje jedynie jako nieprecyzyjna pozycja „sieć fabryczna”.

Praktyczna mapa zabezpieczeń OT dla NIS2

Poniższa tabela pokazuje, jak przekształcić obszary NIS2 Article 21 w dowody dla ISO/IEC 27001:2022, ISO/IEC 27002:2022 i IEC 62443. Nie zastępuje formalnej oceny ryzyka, ale daje CISO, menedżerom OT i zespołom ds. zgodności praktyczny punkt wyjścia.

Ta mapa celowo koncentruje się na dowodach. W NIS2 stwierdzenie „mamy segmentację” nie wystarczy. Należy pokazać, dlaczego segmentacja jest odpowiednia, jak została wdrożona, jak zatwierdza się wyjątki i jak projekt ogranicza wpływ na usługę regulowaną.

Segmentacja: pierwsze zabezpieczenie OT, które sprawdzą audytorzy

Gdyby incydent o 02:17 obejmował przejście atakującego z laptopa biurowego na stację inżynierską, pierwsze pytanie audytowe byłoby oczywiste: dlaczego taka ścieżka mogła istnieć?

Polityka bezpieczeństwa IoT / OT jest jednoznaczna:

Systemy OT muszą działać w dedykowanych sieciach odizolowanych od korporacyjnego IT i systemów dostępnych z Internetu.

Dla mniejszych środowisk Polityka bezpieczeństwa Internetu Rzeczy (IoT) / technologii operacyjnej (OT) - MŚP podaje praktyczną konfigurację bazową:

Wszystkie urządzenia Internetu Rzeczy (IoT) i technologii operacyjnej (OT) muszą zostać umieszczone w odrębnej sieci Wi‑Fi lub VLAN

Dla dojrzałego operatora infrastruktury krytycznej segmentacja powinna być projektowana wokół stref i kanałów komunikacyjnych OT. Użytkownicy korporacyjni nie powinni mieć bezpośredniego dostępu do sieci PLC. Połączenia dostawców powinny kończyć się w kontrolowanych strefach dostępu. Replikacja danych z serwerów historian powinna korzystać z zatwierdzonych ścieżek. Systemy bezpieczeństwa funkcjonalnego powinny być izolowane zgodnie z ryzykiem i wymaganiami inżynieryjnymi. Bezprzewodowe sieci OT powinny być uzasadnione, utwardzane i monitorowane.

Zenith Blueprint: 30-etapowa mapa drogowa audytora, w fazie „Zabezpieczenia w działaniu”, krok 20, wyjaśnia zasadę stojącą za bezpieczeństwem sieci w ISO/IEC 27002:2022:

Systemy sterowania przemysłowego powinny być odizolowane od ruchu biurowego.

Ostrzega również, że bezpieczeństwo sieci wymaga bezpiecznej architektury, segmentacji, kontroli dostępu, szyfrowania danych w tranzycie, monitorowania oraz obrony w głąb.

W Zenith Controls: przewodnik zgodności międzyramowej zabezpieczenie 8.22 ISO/IEC 27002:2022, Segregacja sieci, jest traktowane jako zabezpieczenie zapobiegawcze wspierające poufność, integralność i dostępność, powiązane z koncepcją cyberbezpieczeństwa Protect, z bezpieczeństwem systemów i sieci jako zdolnością operacyjną oraz Protection jako domeną bezpieczeństwa.

Ta klasyfikacja jest przydatna dla dowodów NIS2, ponieważ segmentacja nie jest dekoracyjnym diagramem. To zabezpieczenie zapobiegawcze zaprojektowane w celu ograniczenia zasięgu skutków incydentu i zachowania ciągłości usługi kluczowej.

Zarządzanie podatnościami, gdy systemów OT nie można po prostu załatać

NIS2 wymaga bezpiecznego pozyskiwania, rozwoju i utrzymania sieci i systemów informatycznych, w tym obsługi i ujawniania podatności. W IT zarządzanie podatnościami często oznacza skanowanie, priorytetyzację, wdrożenie poprawek i weryfikację. OT dodaje ograniczenia.

Dla krytycznego HMI poprawki mogą być możliwe wyłącznie podczas planowanego przestoju. Aktualizacja oprogramowania układowego PLC może wymagać udziału dostawcy. System certyfikowany pod kątem bezpieczeństwa funkcjonalnego może utracić certyfikację, jeżeli zostanie nieprawidłowo zmodyfikowany. Niektóre urządzenia legacy mogą w ogóle nie mieć wsparcia dostawcy.

Zenith Blueprint, faza „Zabezpieczenia w działaniu”, krok 19, podaje właściwą logikę audytową dla podatności technicznych:

W przypadku systemów, dla których nie można natychmiast wdrożyć poprawek, na przykład z powodu oprogramowania legacy lub ograniczeń przestojów, należy wdrożyć środki kompensujące. Może to obejmować odizolowanie systemu za zaporą sieciową, ograniczenie dostępu albo zwiększenie monitorowania. We wszystkich przypadkach należy zarejestrować i formalnie zaakceptować ryzyko szczątkowe, pokazując, że problem nie został pominięty.

Bazowa polityka dla MŚP jest podobnie praktyczna:

Inwentarz musi być przeglądany kwartalnie w celu identyfikacji urządzeń przestarzałych, niewspieranych lub takich, dla których nie wdrożono poprawek

W Zenith Controls zabezpieczenie 8.8 ISO/IEC 27002:2022, Zarządzanie podatnościami technicznymi, jest mapowane jako zabezpieczenie zapobiegawcze wspierające poufność, integralność i dostępność, powiązane z Identify i Protect, z zarządzaniem zagrożeniami i podatnościami jako zdolnością operacyjną w domenach Governance, Ecosystem, Protection i Defense.

Solidna teczka podatności OT powinna obejmować:

• Identyfikator aktywa, właściciela, strefę i krytyczność
• Źródło podatności, takie jak komunikat dostawcy, skaner, powiadomienie integratora lub informacje o zagrożeniach
• Ograniczenia bezpieczeństwa funkcjonalnego i dostępności
• Możliwość wdrożenia poprawki oraz planowane okno serwisowe
• Środki kompensujące, takie jak izolacja, listy kontroli dostępu, wyłączone usługi lub zwiększone monitorowanie
• Zatwierdzenie właściciela ryzyka i akceptacja ryzyka szczątkowego
• Dowody weryfikacji po remediacji lub wdrożeniu środka kompensującego

To przekształca „nie możemy wdrożyć poprawki” z wymówki w możliwe do prześledzenia audytowo postępowanie z ryzykiem.

Dostęp zdalny dostawcy: punkt zapalny NIS2 i IEC 62443

Większość incydentów OT ma gdzieś wymiar strony trzeciej. Konto dostawcy. Laptop integratora. Narzędzie zdalnego utrzymania. Współdzielone poświadczenia. Wyjątek w zaporze sieciowej, który trzy lata temu miał być tymczasowy.

NIS2 Article 21 wyraźnie obejmuje bezpieczeństwo łańcucha dostaw, podatności specyficzne dla dostawców, praktyki cyberbezpieczeństwa dostawców i procedury bezpiecznego rozwoju. NIST CSF 2.0 również szczegółowo traktuje ten obszar poprzez krytyczność dostawców, wymagania umowne, należytą staranność, ciągłe monitorowanie, koordynację incydentów i postanowienia dotyczące zakończenia współpracy.

Polityka bezpieczeństwa dostawców i stron trzecich - MŚP Clarysec ujmuje zasadę prostym językiem:

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

Dla OT minimalny dostęp oznacza więcej niż dostęp oparty na rolach w aplikacji. Dostęp dostawcy powinien być:

• Uprzednio zatwierdzony dla określonego celu utrzymaniowego
• Ograniczony czasowo i domyślnie wyłączony
• Chroniony przez MFA lub ciągłe uwierzytelnianie, tam gdzie to właściwe
• Kierowany przez bezpieczny serwer przesiadkowy lub kontrolowaną platformę dostępu zdalnego
• Ograniczony do właściwej strefy lub aktywa OT
• Rejestrowany, monitorowany oraz, dla dostępu wysokiego ryzyka, nagrywany na poziomie sesji
• Przeglądany po zakończeniu
• Objęty umownymi obowiązkami bezpieczeństwa i powiadamiania o incydentach

Korporacyjna Polityka bezpieczeństwa IoT / OT zawiera dedykowane wymaganie dotyczące dostępu zdalnego:

Dostęp zdalny (do zarządzania lub obsługi serwisowej przez dostawcę) musi:

Ta klauzula zakotwicza punkt ładu zarządczego, natomiast szczegółowe wymagania powinny zostać wdrożone w procedurach dostępu, umowach z dostawcami, konfiguracji technicznej i procesach monitorowania.

W Zenith Controls zabezpieczenie 5.21 ISO/IEC 27002:2022, Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT, jest klasyfikowane jako zabezpieczenie zapobiegawcze wspierające poufność, integralność i dostępność, powiązane z koncepcją Identify, z bezpieczeństwem relacji z dostawcami jako zdolnością operacyjną oraz Governance, Ecosystem i Protection jako domenami.

Dla OT to mapowanie pomaga wyjaśnić, dlaczego dowody dotyczące dostępu zdalnego należą jednocześnie do dokumentacji ryzyka dostawcy, nadzoru nad tożsamością, bezpieczeństwa sieci, reagowania na incydenty i ciągłości.

Reagowanie na incydenty: zegar NIS2 spotyka sterownię

Wróćmy do alarmu o 02:17. Organizacja musi zdecydować, czy zdarzenie jest istotne w rozumieniu NIS2. Article 23 wymaga zgłaszania bez zbędnej zwłoki istotnych incydentów wpływających na świadczenie usług. Sekwencja obejmuje wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiedzy, zgłoszenie incydentu w ciągu 72 godzin, aktualizacje pośrednie na żądanie oraz raport końcowy nie później niż miesiąc po zgłoszeniu incydentu albo raport z postępu, jeżeli incydent nadal trwa.

W OT reagowanie na incydenty musi odpowiadać na pytania, które podręczniki IT często pomijają:

• Czy dotknięte urządzenie można odizolować bez stworzenia ryzyka dla bezpieczeństwa funkcjonalnego?
• Kto ma uprawnienia do zatrzymania produkcji lub przełączenia na tryb ręczny?
• Które logi są ulotne i wymagają natychmiastowego zabezpieczenia?
• Z którym dostawcą lub integratorem należy się skontaktować?
• Czy zdarzenie jest złośliwe, przypadkowe, środowiskowe, czy wynika z błędnej konfiguracji?
• Czy może wystąpić wpływ transgraniczny albo wpływ na odbiorców usługi?
• Czy są zaangażowane dane osobowe, takie jak logi identyfikatorów dostępu, CCTV, dane pracowników lub rejestry obsługi klientów?

Polityka OT dla MŚP podaje prostą regułę eskalacji anomalii:

Wszelkie anomalie należy niezwłocznie zgłaszać Dyrektorowi Generalnemu w celu podjęcia dalszych działań

Zawiera również zasadę powstrzymania uwzględniającą bezpieczeństwo funkcjonalne:

Urządzenie należy natychmiast odłączyć od sieci, jeżeli można to zrobić bezpiecznie

Te ostatnie pięć słów ma krytyczne znaczenie. Reakcja OT nie może ślepo kopiować działań powstrzymujących z IT. „Jeżeli można to zrobić bezpiecznie” powinno zostać odzwierciedlone w podręcznikach operacyjnych, macierzach eskalacji, szkoleniach i ćwiczeniach tabletop.

NIST CSF 2.0 dobrze się tu mapuje. Wyniki Respond i Recover obejmują wstępną kwalifikację, kategoryzację, eskalację, analizę przyczyny źródłowej, integralność materiału dowodowego, powiadamianie interesariuszy, powstrzymanie, usunięcie zagrożenia, przywracanie, kontrole integralności kopii zapasowych i komunikację dotyczącą odzyskiwania.

Zbuduj linię dowodową od ryzyka do zabezpieczenia

Praktycznym sposobem uniknięcia rozproszonej zgodności jest zbudowanie jednej linii dowodowej od ryzyka przez regulację i zabezpieczenie po dowód.

Scenariusz: dostawca zdalnej obsługi sprężarki wymaga dostępu do stacji inżynierskiej w sieci OT. Stacja robocza może modyfikować logikę PLC. Konto dostawcy jest zawsze włączone, współdzielone przez wielu inżynierów dostawcy i chronione wyłącznie hasłem. Stacja robocza uruchamia oprogramowanie, którego nie można zaktualizować do następnego przestoju serwisowego.

Zapisz scenariusz ryzyka w rejestrze ryzyk:

„Nieuprawniony lub skompromitowany zdalny dostęp dostawcy do stacji inżynierskiej OT może doprowadzić do nieuprawnionych zmian logiki PLC, zakłócenia produkcji, wpływu na bezpieczeństwo funkcjonalne oraz przerwy w świadczeniu usługi podlegającej zgłoszeniu zgodnie z NIS2”.

Następnie zmapuj zabezpieczenia i obowiązki.

Plan postępowania powinien wyłączyć stały dostęp dostawcy, wymagać imiennych tożsamości dostawcy, wymuszać MFA, kierować dostęp przez kontrolowany serwer przesiadkowy, ograniczać dostęp do stacji inżynierskiej, wymagać zatwierdzenia zgłoszenia utrzymaniowego, rejestrować sesje uprzywilejowane, monitorować polecenia i anomalny ruch, udokumentować stację roboczą bez wdrożonych poprawek jako wyjątek dotyczący podatności oraz przetestować reakcję na incydent w przypadku podejrzanej aktywności dostawcy.

Zenith Blueprint, faza Zarządzanie ryzykiem, krok 13, podaje logikę identyfikowalności SoA:

Odwołania krzyżowe do regulacji: jeżeli określone zabezpieczenia są wdrażane specjalnie w celu spełnienia wymagań GDPR, NIS2 lub DORA, można odnotować to w rejestrze ryzyk (jako część uzasadnienia wpływu ryzyka) albo w uwagach SoA.

Praktyczna lekcja jest prosta. Nie trzymaj dowodów NIS2, ISO i inżynierii OT w osobnych silosach. Dodaj kolumny w rejestrze ryzyk i SoA dla obszaru NIS2 Article 21, zabezpieczenia ISO/IEC 27002:2022, rodziny wymagań IEC 62443, właściciela dowodu i statusu audytu.

Gdzie GDPR i DORA mieszczą się w bezpieczeństwie OT

Bezpieczeństwo OT nie zawsze dotyczy wyłącznie maszyn. Środowiska infrastruktury krytycznej często przetwarzają dane osobowe za pośrednictwem CCTV, systemów kontroli dostępu, logów identyfikatorów dostępu, systemów bezpieczeństwa pracowników, zgłoszeń utrzymaniowych, śledzenia pojazdów, systemów obsługi gości i platform obsługi klientów.

GDPR wymaga, aby dane osobowe były przetwarzane zgodnie z prawem, rzetelnie i przejrzyście, zbierane w określonych celach, ograniczone do tego, co niezbędne, utrzymywane jako dokładne, przechowywane tylko tak długo, jak jest to potrzebne, oraz chronione odpowiednimi środkami technicznymi i organizacyjnymi. Wymaga również rozliczalności, co oznacza, że administrator musi być w stanie wykazać zgodność.

Dla OT oznacza to, że logi dostępu i zapisy monitorowania nie powinny stać się niekontrolowanymi repozytoriami danych nadzorczych. Okres przechowywania, prawa dostępu, ograniczenie celu i ocena naruszenia muszą zostać zaprojektowane w rejestrowaniu i monitorowaniu.

DORA może mieć zastosowanie tam, gdzie uczestniczą podmioty finansowe albo gdy zewnętrzny dostawca usług ICT wspiera odporność operacyjną sektora finansowego. DORA obejmuje zarządzanie ryzykiem ICT, zgłaszanie incydentów, testowanie odporności i ryzyko zewnętrznych dostawców ICT. Dla podmiotów finansowych, które są również podmiotami kluczowymi lub ważnymi zgodnie z przepisami transponującymi NIS2, DORA może działać jako sektorowy reżim dla nakładających się obowiązków, przy czym koordynacja z organami NIS2 może nadal pozostawać istotna.

Obowiązują te same dyscypliny dowodowe: identyfikacja aktywów, ochrona, wykrywanie, ciągłość, kopie zapasowe, ryzyko stron trzecich, testowanie, szkolenia i nadzór kierownictwa.

Perspektywa audytu: jedno zabezpieczenie, wiele perspektyw zapewnienia

Silne wdrożenie bezpieczeństwa OT w NIS2 powinno wytrzymać wiele perspektyw audytowych.

Dlatego Clarysec traktuje Zenith Controls jako kompas zgodności międzyramowej. Atrybuty zabezpieczeń pomagają wyjaśnić cel oficjalnych zabezpieczeń ISO/IEC 27002:2022, natomiast podejście mapujące łączy te zabezpieczenia z NIS2, NIST CSF, nadzorem nad dostawcami, ciągłością i dowodami audytowymi.

Typowe pułapki wdrożenia OT w NIS2

Najczęstsze niepowodzenia bezpieczeństwa OT rzadko wynikają z braku dokumentów. Wynikają z dokumentów, które nie odpowiadają rzeczywistości zakładu.

Pułapka 1: IT posiada program NIS2, ale OT posiada ryzyko. Operacje, inżynieria, bezpieczeństwo funkcjonalne i utrzymanie muszą być zaangażowane.

Pułapka 2: Inwentarz aktywów kończy się na serwerach. Inwentarz OT musi obejmować PLC, RTU, HMI, serwery historian, stacje inżynierskie, przemysłowe przełączniki, czujniki, bramy, urządzenia dostępu zdalnego i komponenty zarządzane przez dostawców.

Pułapka 3: Segmentacja istnieje na diagramie, ale nie w regułach zapory sieciowej. Audytorzy poproszą o dowody egzekwowania, kontroli zmian i monitorowania.

Pułapka 4: Wyjątki dotyczące podatności są nieformalne. Ograniczenia systemów legacy są akceptowalne tylko wtedy, gdy są udokumentowane, zatwierdzone, monitorowane i ponownie przeglądane.

Pułapka 5: Dostęp dostawcy jest traktowany wyłącznie jako kwestia dostawcy. Jest to również kwestia kontroli dostępu, rejestrowania, monitorowania, bezpieczeństwa sieci, reagowania na incydenty i ciągłości.

Pułapka 6: Reagowanie na incydenty ignoruje bezpieczeństwo funkcjonalne. Podręczniki OT muszą określać, kto może izolować urządzenia, zatrzymywać procesy, przełączać tryby lub kontaktować się z regulatorami.

Pułapka 7: Raportowanie NIS2 nie zostało przećwiczone. Proces decyzyjny 24-godzinny i 72-godzinny powinien zostać przetestowany przed rzeczywistym zdarzeniem.

Ścieżka wdrożenia Clarysec: od odpowiedzialności zarządu do dowodów OT

Praktyczne wdrożenie bezpieczeństwa OT w NIS2 może przebiegać według następującej sekwencji:

1. Potwierdź zakres NIS2, klasyfikację podmiotu i krytyczność usługi.
2. Zdefiniuj zakres OT w SZBI, w tym interfejsy i zależności.
3. Zbuduj inwentarz aktywów OT i przepływów danych.
4. Zidentyfikuj obowiązki prawne, umowne, dotyczące bezpieczeństwa funkcjonalnego, prywatności i sektorowe.
5. Przeprowadź warsztaty oceny ryzyka specyficzne dla OT z inżynierią, operacjami, IT, SOC, zakupami i kierownictwem.
6. Zmapuj postępowanie z ryzykiem na zabezpieczenia ISO/IEC 27002:2022, obszary NIS2 i wzorce wdrożeniowe IEC 62443.
7. Zaktualizuj Deklarację stosowania o uzasadnienie OT i właścicieli dowodów.
8. Wdróż priorytetowe zabezpieczenia: segmentację, dostęp dostawców, obsługę podatności, monitorowanie, kopie zapasowe i reagowanie na incydenty.
9. Zaktualizuj polityki i procedury, w tym bezpieczeństwo OT, bezpieczeństwo dostawców, dostęp zdalny, reagowanie na incydenty i ciągłość działania.
10. Przeprowadź ćwiczenia tabletop i techniczne ćwiczenia walidacyjne.
11. Przygotuj pakiety audytowe dla NIS2, ISO/IEC 27001:2022, zapewnienia dla klientów i wewnętrznego nadzoru.
12. Wprowadź ustalenia do przeglądu zarządzania i ciągłego doskonalenia.

Odzwierciedla to model operacyjny w Zenith Blueprint, zwłaszcza krok 13 dotyczący postępowania z ryzykiem i identyfikowalności SoA, krok 14 dotyczący rozwoju polityk i odwołań krzyżowych do regulacji, krok 19 dotyczący zarządzania podatnościami oraz krok 20 dotyczący bezpieczeństwa sieci.

To samo podejście wykorzystuje polityki Clarysec do przekształcenia języka ram w reguły operacyjne. Korporacyjna Polityka bezpieczeństwa IoT / OT wymaga przeglądu architektury bezpieczeństwa przed wdrożeniem:

Wszystkie nowe urządzenia IoT/OT muszą przejść Przegląd architektury bezpieczeństwa przed wdrożeniem. Przegląd ten musi zweryfikować:

Stwierdza również:

Cały ruch w sieciach IoT/OT oraz pomiędzy nimi musi być stale monitorowany z użyciem:

Te klauzule tworzą kotwice ładu zarządczego. Dowody wdrożenia mogą obejmować alerty OT IDS, logi zapory sieciowej, korelację SIEM, bazowe profile ruchu, zgłoszenia anomalii i zapisy reakcji.

Jak wygląda dobry pakiet dowodowy OT dla NIS2

Pakiet dowodowy OT dla NIS2 powinien być wystarczająco praktyczny dla inżynierów i wystarczająco uporządkowany dla audytorów.

W przypadku segmentacji należy uwzględnić zatwierdzoną architekturę, diagramy stref i kanałów komunikacyjnych, eksporty reguł zapory sieciowej, zapisy zmian, okresowe przeglądy reguł, zapisy wyjątków i alerty monitorowania.

W przypadku dostępu dostawców należy uwzględnić ocenę krytyczności dostawcy, klauzule umowne, zatwierdzoną procedurę dostępu, imienne konta, dowody MFA, logi dostępu, nagrania sesji, okresowy przegląd dostępu i zapisy zakończenia współpracy.

W przypadku zarządzania podatnościami należy uwzględnić inwentarz, źródła komunikatów, wyniki pasywnego wykrywania, zgłoszenia podatności, plany wdrażania poprawek, środki kompensujące, akceptację ryzyka i dowody zamknięcia.

W przypadku reagowania na incydenty należy uwzględnić podręczniki postępowania, kontakty eskalacyjne, drzewo decyzyjne raportowania NIS2, wyniki ćwiczeń tabletop, zgłoszenia incydentów, projekty powiadomień do organu, zasady postępowania z materiałem dowodowym i wnioski.

W przypadku ciągłości należy uwzględnić strategię kopii zapasowych OT, kopie zapasowe offline lub chronione, wyniki testów odtworzeniowych, listę krytycznych części zamiennych, ręczne procedury operacyjne, priorytety odzyskiwania i plany komunikacji kryzysowej.

W przypadku ładu zarządczego należy uwzględnić zatwierdzenie zarządu lub kierownictwa, przypisania ról, zapisy o ukończeniu szkoleń, wyniki audytu wewnętrznego, KPI, protokoły przeglądów ryzyka i decyzje przeglądu zarządzania.

Ten model dowodowy jest zgodny z ISO/IEC 27001:2022, ponieważ wspiera postępowanie z ryzykiem, udokumentowane informacje, ocenę wyników i ciągłe doskonalenie. Jest zgodny z NIS2, ponieważ wykazuje odpowiednie i proporcjonalne środki. Jest zgodny z IEC 62443, ponieważ można go prześledzić do architektury OT i inżynieryjnych zabezpieczeń.

Przekształć program bezpieczeństwa OT w gotowość do audytu NIS2

Jeżeli środowisko OT wspiera usługę krytyczną lub regulowaną, czekanie, aż regulator, klient albo incydent ujawni luki, jest niewłaściwą strategią.

Zacznij od jednego przypadku użycia o wysokim wpływie: zdalnego dostępu dostawcy do krytycznej strefy OT, obsługi podatności dla niewspieranych aktywów przemysłowych albo segmentacji między korporacyjnym IT i OT. Zbuduj scenariusz ryzyka, zmapuj go na NIS2 Article 21, wybierz zabezpieczenia ISO/IEC 27002:2022, przełóż je na wzorce wdrożeniowe IEC 62443 i zbierz dowody.

Clarysec może pomóc przyspieszyć te prace za pomocą Zenith Blueprint, Zenith Controls, Polityki bezpieczeństwa IoT / OT, Polityki bezpieczeństwa Internetu Rzeczy (IoT) / technologii operacyjnej (OT) - MŚP oraz Polityki bezpieczeństwa dostawców i stron trzecich - MŚP.

Twoje następne działanie: wybierz jedną usługę OT, zmapuj jej aktywa i zależności oraz utwórz w tym tygodniu linię dowodową od ryzyka do zabezpieczenia. Jeżeli potrzebujesz uporządkowanej ścieżki wdrożenia, 30-etapowa mapa drogowa Clarysec i zestaw narzędzi zgodności międzyramowej mogą przekształcić tę pierwszą linię w kompletny program bezpieczeństwa OT w NIS2.