Securitatea OT conform NIS2: mapare ISO 27001 și IEC 62443

La 02:17, într-o zi de luni, un operator al unei stații de tratare a apei primește o alarmă de la un sistem de dozare. Alimentarea cu substanțe chimice se află încă în limitele de siguranță, dar un PLC raportează comenzi neregulate, stația de lucru de inginerie afișează autentificări eșuate dintr-un cont VPN al unui furnizor, iar analistul SOC de gardă pune o întrebare la care nimeni nu vrea să răspundă sub presiune.

Este acesta un incident IT, un incident OT, un eveniment de siguranță sau un incident semnificativ raportabil conform NIS2?

Unitatea are firewall-uri. Are documentație ISO. Are un tabel cu furnizori. Are chiar și un Plan de răspuns la incidente. Însă planul a fost redactat pentru compromiterea e-mailului și indisponibilități ale serviciilor cloud, nu pentru un controler legacy care nu poate fi actualizat prin patch-uri în timpul producției, un furnizor care are nevoie de acces la distanță pentru a restaura serviciul și o autoritate de reglementare care se așteaptă la dovezi în termenele de raportare NIS2.

Aceeași problemă apare și în sălile de consiliu. Un CISO al unui furnizor regional de energie poate avea un Sistem de management al securității informației certificat ISO/IEC 27001:2022 pentru IT-ul corporativ, în timp ce mediul de tehnologie operațională rămâne o combinație greu de controlat de PLC, RTU, HMI, istorice de proces, stații de lucru de inginerie, switch-uri industriale și căi de acces ale furnizorilor. Întrebarea CEO-ului este simplă: „Suntem acoperiți? Puteți dovedi?”

Pentru multe entități esențiale și importante, răspunsul sincer este inconfortabil. Sunt acoperite parțial. Pot dovedi parțial. Însă securitatea OT conform NIS2 cere mai mult decât conformitate IT generică.

Aceasta cere un model operațional unificat care conectează guvernanța ISO/IEC 27001:2022, limbajul controalelor ISO/IEC 27002:2022, practicile de inginerie industrială IEC 62443, măsurile de management al riscurilor de securitate cibernetică din NIS2 Article 21 și dovezile pentru raportarea incidentelor conform NIS2 Article 23.

Acesta este podul pe care îl construiește acest ghid.

De ce securitatea OT conform NIS2 este diferită de conformitatea IT obișnuită

NIS2 se aplică multor entități publice și private care furnizează servicii aflate în domeniul de aplicare în UE, inclusiv entităților esențiale și importante din sectoare precum energie, transport, servicii bancare, infrastructuri ale piețelor financiare, sănătate, apă potabilă, ape uzate, infrastructură digitală, managementul serviciilor TIC, administrație publică, spațiu, servicii poștale, managementul deșeurilor, producție, produse chimice, alimente, furnizori digitali și cercetare.

Directiva impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale pentru gestionarea riscurilor cibernetice, prevenirea sau minimizarea impactului incidentelor și protejarea continuității serviciilor. Article 21 include o abordare bazată pe toate tipurile de amenințări, care acoperă analiza riscurilor, politicile de securitate, gestionarea incidentelor, continuitatea activității, managementul crizelor, securitatea lanțului de aprovizionare, achiziția și mentenanța securizate, gestionarea și divulgarea vulnerabilităților, evaluarea eficacității, igiena cibernetică, instruirea, criptografia, securitatea resurselor umane, controlul accesului, managementul activelor, autentificarea multifactor sau autentificarea continuă, comunicațiile securizate și comunicațiile de urgență, acolo unde este cazul.

Aceste cerințe sunt familiare pentru o echipă ISO/IEC 27001:2022. În OT, fiecare dintre ele se comportă diferit.

O vulnerabilitate într-un server web poate fi adesea remediată prin patch-uri în câteva zile. O vulnerabilitate într-un controler de turbină poate necesita validarea furnizorului, o fereastră de mentenanță, o revizuire de siguranță și proceduri operaționale de revenire într-o stare sigură. Un laptop poate fi reconstruit. Un HMI de producție poate depinde de un sistem de operare legacy, deoarece aplicația industrială nu a fost certificată pentru o platformă mai nouă. O procedură SOC de răspuns poate spune „izolați gazda”, în timp ce inginerul OT răspunde: „nu înainte să știm dacă izolarea afectează controlul presiunii”.

Diferența nu este doar tehnică. IT prioritizează, de regulă, confidențialitatea, integritatea și disponibilitatea. OT prioritizează disponibilitatea, integritatea procesului și siguranța. Un control de securitate care introduce latență, necesită repornire sau întrerupe un proces fizic poate fi inacceptabil fără aprobare inginerească.

NIS2 nu exceptează OT de la managementul riscurilor de securitate cibernetică. Directiva se așteaptă ca organizația să poată demonstra că măsurile de control sunt adecvate riscului și proporționale cu realitatea operațională.

Stiva de controale: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 și IEC 62443

Un program defensabil de securitate OT conform NIS2 începe cu o stivă de controale pe mai multe niveluri.

ISO/IEC 27001:2022 furnizează sistemul de management. Standardul cere organizației să definească contextul, părțile interesate, obligațiile de reglementare, domeniul de aplicare al SMSI, interfețele și dependențele. De asemenea, cere asumarea responsabilității de către conducere, o Politică de securitate a informației, evaluarea riscurilor, tratarea riscurilor, o Declarație de aplicabilitate, informații documentate, audit intern, analiza managementului și îmbunătățire continuă.

ISO/IEC 27002:2022 oferă vocabularul controalelor. Pentru OT, cele mai importante controale includ adesea securitatea furnizorilor, managementul riscurilor din lanțul de aprovizionare TIC, planificarea incidentelor, pregătirea pentru continuitatea activității, cerințele legale și contractuale, managementul activelor, controlul accesului, managementul vulnerabilităților, backup-urile, jurnalizarea, monitorizarea, securitatea rețelei și separarea rețelelor.

IEC 62443 oferă modelul de inginerie pentru securitatea industrială. Acesta ajută la transpunerea cerințelor sistemului de management în practici OT precum zone, conducte, niveluri de securitate, responsabilități ale proprietarului activului, responsabilități ale integratorului de sistem, așteptări față de furnizorul produsului, restricții de acces la distanță, funcționalitate minimă, managementul conturilor, hardening și controale privind ciclul de viață.

Clarysec utilizează această stivă deoarece evită două eșecuri frecvente. În primul rând, împiedică implementarea ISO să devină prea generică pentru OT. În al doilea rând, împiedică activitatea de inginerie IEC 62443 să se rupă de responsabilitatea consiliului de administrație, de obligațiile de raportare NIS2 și de dovezile de audit.

Politica de securitate IoT / OT a Clarysec formulează direct această legătură:

Pentru a se asigura că toate implementările sunt aliniate la controalele ISO/IEC 27001 și la ghidurile sectoriale aplicabile (de exemplu, IEC 62443, ISO 27019, NIST SP 800-82).

Această propoziție contează. Politica nu este doar o listă de verificare pentru hardeningul dispozitivelor. Ea conectează guvernanța ISO, ghidurile sectoriale OT și securitatea operațională.

Începeți cu domeniul de aplicare: ce serviciu OT trebuie protejat?

Înainte de maparea controalelor, definiți serviciul OT în limbaj de business și de reglementare.

Un manager de fabrică poate spune: „Operăm linia de ambalare.” O evaluare NIS2 ar trebui să spună: „Acest proces de producție susține un serviciu esențial sau important și depinde de PLC, HMI, stații de lucru de inginerie, istorice de proces, switch-uri industriale, acces la distanță al furnizorilor, un contractor de mentenanță, un flux de analiză din cloud și un serviciu corporativ de identitate.”

Clauzele ISO/IEC 27001:2022 4.1–4.4 sunt utile deoarece obligă organizația să identifice aspectele interne și externe, părțile interesate, cerințele legale și contractuale, limitele SMSI, interfețele și dependențele. Pentru securitatea OT conform NIS2, aceasta înseamnă maparea nu doar a rețelei sediului central, ci și a sistemelor industriale și a dependențelor de servicii care afectează continuitatea, siguranța și furnizarea reglementată.

NIST CSF 2.0 consolidează aceeași logică. Funcția GOVERN solicită înțelegerea misiunii, a părților interesate, a dependențelor, a obligațiilor legale și de reglementare, a serviciilor critice și a serviciilor de care depinde organizația. Profilurile organizaționale oferă o metodă practică pentru delimitarea stării curente, definirea stării-țintă, analiza lacunelor și elaborarea unui plan de acțiune prioritizat.

Pentru un mediu OT, Clarysec începe, de regulă, cu cinci întrebări:

1. Ce serviciu reglementat sau critic susține acest mediu OT?
2. Ce active OT, rețele, fluxuri de date și terți sunt necesari pentru acel serviciu?
3. Ce constrângeri de siguranță, disponibilitate și exploatare afectează controalele de securitate?
4. Ce obligații legale, contractuale și sectoriale se aplică, inclusiv NIS2, GDPR, DORA, acolo unde este relevant, contracte cu clienții și norme naționale?
5. Ce părți ale mediului se află în SMSI și ce părți sunt dependențe externe care necesită controale pentru furnizori?

Multe programe NIS2 eșuează aici. Își definesc domeniul în jurul IT-ului corporativ, deoarece este mai ușor de inventariat. Auditorii și autoritățile de reglementare nu vor fi convinși dacă cea mai critică dependență de serviciu apare doar ca o linie vagă numită „rețeaua fabricii”.

O hartă practică a controalelor OT conform NIS2

Tabelul de mai jos arată cum pot fi transformate temele NIS2 Article 21 în dovezi ISO/IEC 27001:2022, ISO/IEC 27002:2022 și IEC 62443. Nu înlocuiește o evaluare formală a riscurilor, dar oferă CISO, managerilor OT și echipelor de conformitate un punct de plecare practic.

Această hartă este intenționat orientată către dovezi. Conform NIS2, afirmația „avem segmentare” nu este suficientă. Trebuie să arătați de ce segmentarea este adecvată, cum este implementată, cum sunt aprobate excepțiile și cum reduce proiectarea impactul asupra serviciului reglementat.

Segmentarea: primul control OT pe care auditorii îl vor testa

Dacă incidentul de la 02:17 ar implica un atacator care se deplasează de la un laptop de birou la o stație de lucru de inginerie, prima întrebare de audit ar fi evidentă: de ce putea exista această cale?

Politica de securitate IoT / OT este explicită:

Sistemele OT trebuie să funcționeze în rețele dedicate, izolate de IT-ul corporativ și de sistemele expuse la internet.

Pentru medii mai mici, Politica de securitate pentru Internetul obiectelor (IoT) / Tehnologie operațională (OT) - IMM oferă o bază practică:

Toate dispozitivele Internetul obiectelor (IoT) și Tehnologie operațională (OT) trebuie plasate într-o rețea Wi-Fi separată sau într-o rețea VLAN separată

Pentru un operator matur de infrastructură critică, segmentarea trebuie proiectată în jurul zonelor și conductelor OT. Utilizatorii corporativi nu trebuie să acceseze direct rețelele PLC. Conexiunile furnizorilor trebuie să se termine în zone de acces controlate. Replicarea istoricului de proces trebuie să utilizeze căi aprobate. Sistemele de siguranță trebuie izolate în funcție de risc și de cerințele de inginerie. Rețelele OT wireless trebuie justificate, securizate și monitorizate.

Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului, în faza Controale în acțiune, Pasul 20, explică principiul din spatele securității rețelei în ISO/IEC 27002:2022:

Sistemele de control industrial trebuie izolate de traficul de birou.

De asemenea, avertizează că securitatea rețelei necesită arhitectură securizată, segmentare, controlul accesului, criptare în tranzit, monitorizare și apărare în profunzime.

În Zenith Controls: ghidul de conformitate transversală, controlul ISO/IEC 27002:2022 8.22, Separarea rețelelor, este tratat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea, aliniat la conceptul de securitate cibernetică Protect, având securitatea sistemelor și rețelelor drept capabilitate operațională și Protection drept domeniu de securitate.

Această clasificare este utilă pentru dovezile NIS2 deoarece segmentarea nu este o diagramă decorativă. Este un control preventiv conceput pentru a reduce raza de impact și pentru a păstra continuitatea serviciilor esențiale.

Managementul vulnerabilităților atunci când sistemele OT nu pot fi pur și simplu actualizate prin patch-uri

NIS2 cere achiziția, dezvoltarea și mentenanța securizată a sistemelor de rețea și informatice, inclusiv gestionarea și divulgarea vulnerabilităților. În IT, managementul vulnerabilităților înseamnă adesea scanare, prioritizare, aplicarea patch-urilor și verificare. OT adaugă constrângeri.

Un HMI critic poate fi actualizat prin patch-uri doar în timpul unei opriri planificate. O actualizare de firmware pentru un PLC poate necesita implicarea furnizorului. Un sistem certificat pentru siguranță își poate pierde certificarea dacă este modificat incorect. Unele dispozitive legacy pot să nu mai aibă deloc suport din partea furnizorului.

Zenith Blueprint, faza Controale în acțiune, Pasul 19, oferă logica de audit corectă pentru vulnerabilitățile tehnice:

Pentru sistemele care nu pot fi actualizate prin patch-uri imediat, poate din cauza software-ului legacy sau a restricțiilor de indisponibilitate, implementați controale compensatorii. Acestea pot include izolarea sistemului în spatele unui firewall, limitarea accesului sau creșterea monitorizării. În toate cazurile, înregistrați și acceptați formal riscul rezidual, arătând că problema nu este uitată.

Baza de politică pentru IMM-uri este la fel de practică:

Inventarul trebuie revizuit trimestrial pentru identificarea dispozitivelor învechite, neacceptate de furnizor sau neactualizate prin patch-uri

În Zenith Controls, controlul ISO/IEC 27002:2022 8.8, Managementul vulnerabilităților tehnice, este mapat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea, aliniat la Identify și Protect, având managementul amenințărilor și vulnerabilităților drept capabilitate operațională în domeniile Governance, Ecosystem, Protection și Defense.

Un dosar OT solid privind vulnerabilitățile trebuie să includă:

• Identificatorul activului, proprietarul, zona și criticitatea
• Sursa vulnerabilității, cum ar fi informarea furnizorului, scannerul, notificarea integratorului sau informațiile privind amenințările
• Constrângeri de siguranță și disponibilitate
• Fezabilitatea patch-ului și fereastra de mentenanță planificată
• Controale compensatorii, cum ar fi izolarea, liste de control al accesului (ACL), servicii dezactivate sau monitorizare sporită
• Aprobarea proprietarului riscului și acceptarea riscului rezidual
• Dovezi de verificare după remediere sau după implementarea controlului compensatoriu

Aceasta transformă „nu putem aplica patch-ul” dintr-o scuză într-un tratament al riscului verificabil.

Accesul la distanță al furnizorilor: punctul critic dintre NIS2 și IEC 62443

Majoritatea incidentelor OT au undeva o dimensiune de terță parte. Un cont de furnizor. Un laptop al integratorului. Un instrument de mentenanță la distanță. O credențială partajată. O excepție de firewall care era temporară acum trei ani.

NIS2 Article 21 include explicit securitatea lanțului de aprovizionare, vulnerabilitățile specifice furnizorilor, practicile de securitate cibernetică ale furnizorilor și procedurile de dezvoltare securizată. NIST CSF 2.0 este de asemenea detaliat pe acest subiect prin criticitatea furnizorilor, cerințe contractuale, revizuiri de due diligence, monitorizare continuă, coordonarea incidentelor și clauze de ieșire.

Politica de securitate privind terții și furnizorii - IMM a Clarysec formulează principiul în termeni clari:

Furnizorilor trebuie să li se acorde acces numai la sistemele și datele minime necesare pentru îndeplinirea funcției lor.

Pentru OT, accesul minim înseamnă mai mult decât acces bazat pe roluri într-o aplicație. Accesul furnizorilor trebuie să fie:

• Preaprobat pentru un scop de mentenanță definit
• Limitat în timp și dezactivat implicit
• Protejat prin MFA sau autentificare continuă, acolo unde este cazul
• Rutat printr-o gazdă jump securizată sau o platformă controlată de acces la distanță
• Limitat la zona sau activul OT relevant
• Jurnalizat, monitorizat și, pentru accesul cu risc ridicat, înregistrat la nivel de sesiune
• Revizuit după finalizare
• Acoperit de obligații contractuale de securitate și de notificare a incidentelor

Politica de securitate IoT / OT pentru întreprinderi include o cerință dedicată privind accesul la distanță:

Accesul la distanță (pentru administrare sau service efectuat de furnizor) trebuie să:

Această clauză ancorează punctul de guvernanță, iar cerințele detaliate trebuie implementate în procedurile de acces, acordurile cu furnizorii, configurația tehnică și fluxurile de monitorizare.

În Zenith Controls, controlul ISO/IEC 27002:2022 5.21, Gestionarea securității informației în lanțul de aprovizionare TIC, este clasificat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea, aliniat la conceptul Identify, având securitatea relațiilor cu furnizorii drept capabilitate operațională și Governance, Ecosystem și Protection drept domenii.

Pentru OT, această mapare ajută la explicarea motivului pentru care dovezile privind accesul la distanță aparțin simultan dosarelor de risc asociat furnizorilor, guvernanței identității, securității rețelei, răspunsului la incidente și continuității.

Răspunsul la incidente: ceasul NIS2 întâlnește camera de control

Revenind la alarma de la 02:17. Organizația trebuie să decidă dacă evenimentul este semnificativ conform NIS2. Article 23 cere notificarea fără întârzieri nejustificate a incidentelor semnificative care afectează furnizarea serviciilor. Secvența include o avertizare timpurie în termen de 24 de ore de la luarea la cunoștință, o notificare a incidentului în termen de 72 de ore, actualizări intermediare dacă sunt solicitate și un raport final cel târziu la o lună după notificarea incidentului sau un raport de progres dacă incidentul este încă în desfășurare.

În OT, răspunsul la incidente trebuie să răspundă la întrebări pe care procedurile IT de răspuns le ignoră adesea:

• Dispozitivul afectat poate fi izolat fără a crea un risc de siguranță?
• Cine are autoritatea de a opri producția sau de a trece în modul manual?
• Ce jurnale sunt volatile și necesită păstrare imediată?
• Ce furnizor sau integrator trebuie contactat?
• Evenimentul este malițios, accidental, de mediu sau cauzat de o configurare greșită?
• Poate exista impact transfrontalier sau impact asupra beneficiarilor serviciului?
• Sunt implicate date cu caracter personal, cum ar fi jurnalele de badge, CCTV, datele angajaților sau înregistrări de servicii pentru clienți?

Politica OT pentru IMM-uri oferă o regulă simplă de escaladare a anomaliilor:

Orice anomalie trebuie raportată imediat Directorului general pentru acțiuni ulterioare

Aceasta include și un principiu de conținere conștient de siguranță:

Dispozitivul trebuie deconectat imediat de la rețea, acolo unde acest lucru se poate face în siguranță

Ultimele cinci cuvinte sunt critice. Răspunsul OT nu poate copia orbește acțiunile de conținere IT. „Acolo unde acest lucru se poate face în siguranță” trebuie reflectat în procedurile operaționale, matricile de escaladare, instruire și exercițiile tabletop.

NIST CSF 2.0 se mapează bine aici. Rezultatele sale Respond și Recover acoperă triajul, clasificarea, escaladarea, analiza cauzei principale, integritatea probelor, notificarea părților interesate, conținerea, eradicarea, restaurarea, verificările de integritate ale backup-urilor și comunicările de recuperare.

Construiți o linie de dovezi de la risc la control

O modalitate practică de a evita conformitatea fragmentată este construirea unei singure linii de dovezi de la risc la reglementare, la control și la dovadă.

Scenariu: un furnizor de compresoare la distanță necesită acces la o stație de lucru de inginerie din rețeaua OT. Stația de lucru poate modifica logica PLC. Contul furnizorului este întotdeauna activ, partajat de mai mulți ingineri ai furnizorului și protejat doar prin parolă. Stația de lucru rulează software care nu poate fi actualizat până la următoarea oprire de mentenanță.

Scrieți scenariul de risc în Registrul de riscuri:

„Accesul la distanță neautorizat sau compromis al furnizorului la stația de lucru OT de inginerie ar putea conduce la modificări neautorizate ale logicii PLC, întreruperea producției, impact asupra siguranței și întrerupere de serviciu raportabilă conform NIS2.”

Apoi mapați controalele și obligațiile.

Planul de tratament trebuie să dezactiveze accesul permanent al furnizorului, să solicite identități nominale ale furnizorilor, să impună MFA, să ruteze accesul printr-un server jump controlat, să limiteze accesul la stația de lucru de inginerie, să solicite aprobarea tichetului de mentenanță, să înregistreze sesiunile privilegiate, să monitorizeze comenzile și traficul anormal, să documenteze stația de lucru neactualizată prin patch-uri ca excepție privind vulnerabilitatea și să testeze răspunsul la incidente pentru activități suspecte ale furnizorului.

Zenith Blueprint, faza Managementul riscurilor, Pasul 13, oferă logica de trasabilitate SoA:

Referințe încrucișate la reglementări: dacă anumite controale sunt implementate special pentru a respecta GDPR, NIS2 sau DORA, puteți nota acest lucru fie în Registrul de riscuri (ca parte a justificării impactului riscului), fie în notele SoA.

Lecția practică este simplă. Nu păstrați dovezile NIS2, ISO și cele de inginerie OT în silozuri separate. Adăugați coloane în Registrul de riscuri și în SoA pentru tema NIS2 Article 21, controlul ISO/IEC 27002:2022, familia de cerințe IEC 62443, proprietarul dovezilor și statutul pentru audit.

Unde se încadrează GDPR și DORA în securitatea OT

Securitatea OT nu este întotdeauna doar despre mașini. Mediile de infrastructură critică prelucrează adesea date cu caracter personal prin CCTV, sisteme de control al accesului, jurnale de badge, sisteme de siguranță a forței de muncă, tichete de mentenanță, urmărirea vehiculelor, sisteme pentru vizitatori și platforme de servicii pentru clienți.

GDPR impune ca datele cu caracter personal să fie prelucrate legal, echitabil și transparent, colectate în scopuri specificate, limitate la ceea ce este necesar, menținute exacte, păstrate doar atât timp cât este necesar și protejate prin măsuri tehnice și organizatorice adecvate. De asemenea, impune responsabilitate, ceea ce înseamnă că operatorul de date trebuie să poată demonstra conformitatea.

Pentru OT, aceasta înseamnă că jurnalele de acces și înregistrările de monitorizare nu trebuie să devină depozite necontrolate de date de supraveghere. Retenția, drepturile de acces, limitarea scopului și evaluarea încălcării trebuie proiectate în jurnalizare și monitorizare.

DORA se poate aplica atunci când sunt implicate entități financiare sau când un furnizor terț de servicii TIC susține reziliența operațională a sectorului financiar. DORA acoperă managementul riscurilor TIC, raportarea incidentelor, testarea rezilienței și riscul asociat terților TIC. Pentru entitățile financiare care sunt și entități esențiale sau importante conform normelor de transpunere NIS2, DORA poate acționa ca regim sectorial specific pentru obligațiile suprapuse, în timp ce coordonarea cu autoritățile NIS2 poate rămâne relevantă.

Se aplică aceleași discipline privind dovezile: identificarea activelor, protecția, detecția, continuitatea, backup-ul, riscul asociat terților, testarea, instruirea și supravegherea de către management.

Perspectiva de audit: un control, mai multe perspective de asigurare

O implementare solidă a securității OT conform NIS2 trebuie să reziste mai multor perspective de audit.

Acesta este motivul pentru care Clarysec tratează Zenith Controls ca pe o busolă de conformitate transversală. Atributele sale de control ajută la explicarea scopului controalelor oficiale ISO/IEC 27002:2022, în timp ce abordarea de mapare conectează aceste controale cu NIS2, NIST CSF, guvernanța furnizorilor, continuitatea și dovezile de audit.

Capcane frecvente în implementarea OT NIS2

Cele mai frecvente eșecuri de securitate OT sunt rareori cauzate de lipsa documentelor. Ele sunt cauzate de documente care nu corespund realității din fabrică.

Capcana 1: IT deține programul NIS2, dar OT deține riscul. Operațiunile, ingineria, siguranța și mentenanța trebuie implicate.

Capcana 2: Inventarul activelor se oprește la servere. Un inventar OT trebuie să includă PLC, RTU, HMI, istorice de proces, stații de lucru de inginerie, switch-uri industriale, senzori, gateway-uri, echipamente de acces la distanță și componente gestionate de furnizori.

Capcana 3: Segmentarea există într-o diagramă, dar nu în regulile de firewall. Auditorii vor solicita dovezi privind aplicarea, controlul schimbărilor și monitorizarea.

Capcana 4: Excepțiile privind vulnerabilitățile sunt informale. Constrângerile sistemelor legacy sunt acceptabile doar atunci când sunt documentate, aprobate, monitorizate și reanalizate.

Capcana 5: Accesul furnizorilor este tratat doar ca problemă de furnizor. Este și o problemă de control al accesului, jurnalizare, monitorizare, securitate a rețelei, răspuns la incidente și continuitate.

Capcana 6: Răspunsul la incidente ignoră siguranța. Procedurile OT de răspuns trebuie să definească cine poate izola dispozitive, opri procese, comuta moduri sau contacta autoritățile de reglementare.

Capcana 7: Raportarea NIS2 nu este repetată prin exerciții. Procesul decizional de 24 de ore și 72 de ore trebuie testat înainte de un eveniment real.

Calea de implementare Clarysec de la responsabilitatea consiliului la dovezile OT

O implementare practică a securității OT conform NIS2 poate urma această secvență:

1. Confirmați domeniul de aplicare NIS2, clasificarea entității și criticitatea serviciului.
2. Definiți domeniul OT în SMSI, inclusiv interfețele și dependențele.
3. Construiți un inventar al activelor OT și al fluxurilor de date.
4. Identificați obligațiile legale, contractuale, de siguranță, de confidențialitate și sectoriale.
5. Derulați ateliere de evaluare a riscurilor specifice OT cu inginerie, operațiuni, IT, SOC, achiziții și management.
6. Mapați tratamentul riscului la controalele ISO/IEC 27002:2022, temele NIS2 și modelele de implementare IEC 62443.
7. Actualizați Declarația de aplicabilitate cu justificarea OT și proprietarii dovezilor.
8. Implementați controale prioritare: segmentare, accesul furnizorilor, gestionarea vulnerabilităților, monitorizare, backup-uri și răspuns la incidente.
9. Actualizați politicile și procedurile, inclusiv securitatea OT, securitatea furnizorilor, accesul la distanță, răspunsul la incidente și continuitatea activității.
10. Derulați exerciții tabletop și exerciții de validare tehnică.
11. Pregătiți pachete de audit pentru NIS2, ISO/IEC 27001:2022, programe de asigurare solicitate de clienți și guvernanță internă.
12. Introduceți constatările în analiza managementului și în îmbunătățirea continuă.

Aceasta reflectă modelul operațional din Zenith Blueprint, în special Pasul 13 pentru tratamentul riscului și trasabilitatea SoA, Pasul 14 pentru dezvoltarea politicilor și referințe încrucișate de reglementare, Pasul 19 pentru managementul vulnerabilităților și Pasul 20 pentru securitatea rețelei.

Aceeași abordare utilizează politicile Clarysec pentru a transforma limbajul cadrelor în reguli operaționale. Politica de securitate IoT / OT pentru întreprinderi cere revizuirea arhitecturii de securitate înainte de implementare:

Toate dispozitivele IoT/OT noi trebuie să treacă printr-o revizuire a arhitecturii de securitate înainte de implementare. Această revizuire trebuie să valideze:

De asemenea, precizează:

Tot traficul din interiorul și dintre rețelele IoT/OT trebuie monitorizat continuu utilizând:

Aceste clauze creează ancore de guvernanță. Dovezile de implementare pot include alerte IDS OT, jurnale de firewall, corelare SIEM, profiluri de trafic de referință, tichete de anomalii și înregistrări de răspuns.

Cum arată dovezile OT NIS2 de calitate

Un pachet de dovezi OT conform NIS2 trebuie să fie suficient de practic pentru ingineri și suficient de structurat pentru auditori.

Pentru segmentare, includeți arhitectura aprobată, diagramele de zone și conducte, exporturi ale regulilor de firewall, înregistrări ale schimbărilor, revizuiri periodice ale regulilor, înregistrări de excepții și alerte de monitorizare.

Pentru accesul furnizorilor, includeți evaluarea criticității furnizorilor, clauze contractuale, procedura aprobată de acces, conturi nominale, dovezi MFA, jurnale de acces, înregistrări ale sesiunilor, revizuirea periodică a accesului și înregistrări de încetare a colaborării.

Pentru managementul vulnerabilităților, includeți inventarul, sursele de informări, rezultate ale descoperirii pasive, tichete de vulnerabilitate, planuri de patching, controale compensatorii, acceptarea riscului și dovezi de închidere.

Pentru răspunsul la incidente, includeți proceduri de răspuns, contacte de escaladare, arbore decizional pentru raportarea NIS2, rezultate tabletop, tichete de incident, proiecte de notificare către autorități, reguli de gestionare a probelor și lecții învățate.

Pentru continuitate, includeți strategia de backup OT, backup-uri offline sau protejate, rezultatele testelor de restaurare, lista pieselor de schimb critice, proceduri operaționale manuale, priorități de recuperare și planuri de comunicare de criză.

Pentru guvernanță, includeți aprobarea consiliului sau a managementului, atribuiri de roluri, înregistrări de instruire, rezultatele auditului intern, KPI, procese-verbale ale revizuirii riscurilor și decizii ale analizei managementului.

Acest model de dovezi se aliniază cu ISO/IEC 27001:2022 deoarece susține tratarea riscurilor, informațiile documentate, evaluarea performanței și îmbunătățirea continuă. Se aliniază cu NIS2 deoarece demonstrează măsuri adecvate și proporționale. Se aliniază cu IEC 62443 deoarece poate fi trasat la arhitectura OT și la controalele de inginerie.

Transformați programul OT într-o pregătire NIS2 verificabilă

Dacă mediul dumneavoastră OT susține un serviciu critic sau reglementat, așteptarea unui regulator, a unui client sau a unui incident care să expună lacunele este o strategie greșită.

Începeți cu un caz de utilizare cu impact ridicat: accesul la distanță al furnizorilor către o zonă OT critică, gestionarea vulnerabilităților pentru active industriale neacceptate de furnizor sau segmentarea dintre IT-ul corporativ și OT. Construiți scenariul de risc, mapați-l la NIS2 Article 21, selectați controalele ISO/IEC 27002:2022, transpuneți-le în modele de implementare IEC 62443 și colectați dovezile.

Clarysec vă poate ajuta să accelerați această activitate cu Zenith Blueprint, Zenith Controls, Politica de securitate IoT / OT, Politica de securitate pentru Internetul obiectelor (IoT) / Tehnologie operațională (OT) - IMM și Politica de securitate privind terții și furnizorii - IMM.

Următoarea acțiune: alegeți un serviciu OT, mapați activele și dependențele acestuia și creați în această săptămână o linie de dovezi de la risc la control. Dacă doriți o cale structurată de implementare, foaia de parcurs în 30 de pași și setul de instrumente de conformitate transversală ale Clarysec pot transforma această primă linie într-un program complet de securitate OT conform NIS2.