NIS2 OT сигурност: съпоставяне с ISO 27001 и IEC 62443

В 02:17 в понеделник оператор във водопречиствателна станция получава аларма от дозираща система. Подаването на химикали все още е в безопасните граници, но един PLC докладва нерегулярни команди, инженерната работна станция показва неуспешни вписвания от VPN акаунт на доставчик, а дежурният SOC анализатор задава въпрос, на който никой не иска да отговаря под натиск.

Това ИТ инцидент ли е, OT инцидент, събитие, свързано с безопасността, или значим инцидент, подлежащ на докладване по NIS2?

Обектът има защитни стени. Има ISO документация. Има таблица с доставчици. Дори има план за реагиране при инциденти. Но планът е писан за компрометиране на електронна поща и недостъпност на облачни услуги, а не за наследен контролер, който не може да бъде коригиран по време на производство, за доставчик, който се нуждае от отдалечен достъп, за да възстанови услугата, и за регулатор, който очаква доказателства в сроковете за докладване по NIS2.

Същият проблем се проявява и в заседателните зали. CISO при регионален доставчик на енергия може да има сертифицирана по ISO/IEC 27001:2022 система за управление на информационната сигурност за корпоративната ИТ среда, докато средата на оперативните технологии остава сложна плетеница от PLC, RTU, HMI, историзиращи системи, инженерни работни станции, индустриални комутатори и канали за достъп на доставчици. Въпросът на главния изпълнителен директор е прост: „Покрити ли сме? Можете ли да го докажете?“

За много съществени и важни субекти честният отговор е неудобен. Те са частично покрити. Могат частично да го докажат. Но NIS2 OT сигурността изисква повече от общо ИТ съответствие.

Тя изисква единен оперативен модел, който свързва управлението по ISO/IEC 27001:2022, езика на контролите в ISO/IEC 27002:2022, индустриалните инженерни практики по IEC 62443, мерките за управление на риска за киберсигурността по NIS2 Article 21 и доказателствата за докладване на инциденти по NIS2 Article 23.

Това е мостът, който изгражда това ръководство.

Защо NIS2 OT сигурността се различава от обичайното ИТ съответствие

NIS2 се прилага за много публични и частни субекти, които предоставят услуги в обхвата на ЕС, включително съществени и важни субекти в сектори като енергетика, транспорт, банкиране, инфраструктура на финансовите пазари, здравеопазване, питейна вода, отпадъчни води, цифрова инфраструктура, управление на ИКТ услуги, публична администрация, космически дейности, пощенски услуги, управление на отпадъци, производство, химикали, храни, цифрови доставчици и научни изследвания.

Директивата изисква подходящи и пропорционални технически, оперативни и организационни мерки за управление на киберрисковете, предотвратяване или минимизиране на въздействието от инциденти и защита на непрекъснатостта на услугите. Article 21 включва подход „от всички опасности“, обхващащ анализ на риска, политики за сигурност, обработване на инциденти, непрекъснатост на дейността, управление на кризи, сигурност на веригата на доставки, сигурно придобиване и поддръжка, обработване и оповестяване на уязвимости, оценка на ефективността, киберхигиена, обучение, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите, MFA или непрекъсната автентикация, сигурни комуникации и аварийни комуникации, когато е приложимо.

Тези изисквания звучат познато за екип по ISO/IEC 27001:2022. В OT всяко от тях се държи различно.

Уязвимост в уеб сървър често може да бъде коригирана в рамките на дни. Уязвимост в контролер на турбина може да изисква валидиране от доставчик, прозорец за поддръжка, преглед по безопасност и резервни оперативни процедури. Лаптоп може да бъде преинсталиран. Производствен HMI може да зависи от наследена операционна система, защото индустриалното приложение не е сертифицирано за по-нова платформа. Наръчник на SOC може да казва „изолирай хоста“, докато OT инженерът отговаря: „не преди да знаем дали изолацията влияе на управлението на налягането“.

Разликата не е само техническа. ИТ обичайно приоритизира поверителност, цялостност и наличност. OT приоритизира наличност, цялостност на процеса и безопасност. Контрол за сигурност, който въвежда латентност, изисква рестарт или прекъсва физически процес, може да бъде неприемлив без инженерно одобрение.

NIS2 не освобождава OT от управление на риска за киберсигурността. От организацията се очаква да докаже, че контролите са подходящи за риска и пропорционални на оперативната реалност.

Стекът от контроли: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 и IEC 62443

Защитима програма за NIS2 OT сигурност започва със слоест стек от контроли.

ISO/IEC 27001:2022 предоставя системата за управление. Той изисква организацията да определи контекста, заинтересованите страни, регулаторните задължения, обхвата на СУИС, интерфейсите и зависимостите. Изисква също управленска отговорност от ръководството, политика за информационна сигурност, оценка на риска, третиране на риска, Декларация за приложимост, документирана информация, вътрешен одит, преглед от ръководството и непрекъснато подобрение.

ISO/IEC 27002:2022 предоставя речника на контролите. За OT най-важните контроли често включват сигурност на доставчиците, управление на риска по веригата за доставки на ИКТ, планиране за инциденти, готовност за непрекъснатост на дейността, правни и договорни изисквания, управление на активите, контрол на достъпа, управление на уязвимостите, резервни копия, журнализиране, мониторинг, мрежова сигурност и разделяне на мрежи.

IEC 62443 предоставя индустриалния инженерен модел за сигурност. Той помага изискванията на системата за управление да се преведат в OT практики като зони, канали, нива на сигурност, отговорности на собственика на активи, отговорности на системния интегратор, очаквания към доставчиците на продукти, ограничения за отдалечен достъп, минимална функционалност, управление на акаунти, укрепване и контроли през жизнения цикъл.

Clarysec използва този стек, защото той предотвратява два често срещани провала. Първо, не допуска внедряването на ISO да стане твърде общо за OT. Второ, не допуска инженерната работа по IEC 62443 да се откъсне от отчетността на управителния съвет, задълженията за докладване по NIS2 и доказателствата за одит.

Политиката за IoT / OT сигурност на Clarysec посочва моста директно:

Да се гарантира, че всички внедрявания са съгласувани с контролите на ISO/IEC 27001 и приложимите специфични за сектора насоки (напр. IEC 62443, ISO 27019, NIST SP 800-82).

Това изречение е важно. Политиката не е само контролен списък за укрепване на устройства. Тя свързва управлението по ISO, секторните насоки за OT и оперативната сигурност.

Започнете с обхвата: коя OT услуга трябва да бъде защитена?

Преди да съпоставяте контроли, определете OT услугата на бизнес и регулаторен език.

Ръководител на обект може да каже: „Управляваме линията за опаковане.“ Оценката по NIS2 трябва да каже: „Този производствен процес поддържа съществена или важна услуга и зависи от PLC, HMI, инженерни работни станции, историзиращи системи, индустриални комутатори, отдалечен достъп на доставчици, изпълнител по поддръжката, поток за облачна аналитика и корпоративна услуга за идентичност.“

Клаузи 4.1 до 4.4 на ISO/IEC 27001:2022 са полезни, защото задължават организацията да идентифицира вътрешни и външни обстоятелства, заинтересовани страни, правни и договорни изисквания, граници на СУИС, интерфейси и зависимости. За NIS2 OT сигурността това означава картографиране не само на мрежата в обекта, но и на индустриалните системи и зависимостите на услугите, които влияят върху непрекъснатостта, безопасността и регулираното предоставяне.

NIST CSF 2.0 засилва същата логика. Неговата функция GOVERN изисква разбиране на мисията, заинтересованите страни, зависимостите, правните и регулаторните задължения, критичните услуги и услугите, от които организацията зависи. Организационните профили предоставят практически метод за определяне на текущо състояние, дефиниране на целево състояние, анализ на пропуските и изготвяне на приоритизиран план за действия.

За OT среда Clarysec обичайно започва с пет въпроса:

1. Коя регулирана или критична услуга поддържа тази OT среда?
2. Кои OT активи, мрежи, потоци от данни и трети страни са необходими за тази услуга?
3. Кои ограничения за безопасност, наличност и експлоатация влияят върху контролите за сигурност?
4. Кои правни, договорни и секторни задължения се прилагат, включително NIS2, GDPR, DORA, когато са релевантни, клиентски договори и национални правила?
5. Кои части от средата са в обхвата на СУИС и кои са външни зависимости, изискващи контроли за доставчици?

Много NIS2 програми се провалят точно тук. Те определят обхвата около корпоративната ИТ среда, защото тя се инвентаризира по-лесно. Одиторите и регулаторите няма да бъдат впечатлени, ако най-критичната зависимост на услугата се появява само като неясен ред „заводска мрежа“.

Практическа карта на NIS2 OT контролите

Таблицата по-долу показва как темите от NIS2 Article 21 да се превърнат в доказателства по ISO/IEC 27001:2022, ISO/IEC 27002:2022 и IEC 62443. Тя не замества формална оценка на риска, но дава на CISO, OT мениджъри и екипи по съответствие практична отправна точка.

Тази карта умишлено е фокусирана върху доказателствата. По NIS2 не е достатъчно да се каже „имаме сегментация“. Трябва да покажете защо сегментацията е подходяща, как е внедрена, как се одобряват изключенията и как дизайнът намалява въздействието върху регулираната услуга.

Сегментация: първият OT контрол, който одиторите ще проверят

Ако инцидентът в 02:17 включваше нападател, който се придвижва от офис лаптоп към инженерна работна станция, първият одитен въпрос щеше да бъде очевиден: защо такъв път изобщо може да съществува?

Политиката за IoT / OT сигурност е категорична:

OT системите трябва да работят в отделни мрежи, изолирани от корпоративната ИТ среда и системите, достъпни от интернет.

За по-малки среди Политиката за сигурност на Интернет на нещата (IoT) / оперативните технологии (OT) - SME дава практична базова линия:

Всички устройства за Интернет на нещата (IoT) и оперативни технологии (OT) трябва да бъдат поставени в отделна Wi-Fi или VLAN мрежа

За зрял оператор на критична инфраструктура сегментацията трябва да бъде проектирана около OT зони и канали. Корпоративните потребители не трябва да имат пряк достъп до PLC мрежи. Връзките на доставчици трябва да завършват в контролирани зони за достъп. Репликацията от историзиращи системи трябва да използва одобрени пътища. Системите за безопасност трябва да бъдат изолирани съгласно риска и инженерните изисквания. Безжичните OT мрежи трябва да бъдат обосновани, укрепени и наблюдавани.

Zenith Blueprint: 30-стъпкова пътна карта за одитори, във фазата Controls in Action, Step 20, обяснява принципа зад мрежовата сигурност по ISO/IEC 27002:2022:

Индустриалните системи за управление трябва да бъдат изолирани от офис трафика.

Той също предупреждава, че мрежовата сигурност изисква сигурна архитектура, сегментация, контрол на достъпа, шифроване при пренос, мониторинг и многостепенна защита.

В Zenith Controls: Ръководство за кръстосано съответствие контрол 8.22 от ISO/IEC 27002:2022, „Разделяне на мрежи“, се третира като превантивен контрол, който поддържа поверителност, цялостност и наличност, съгласуван е с концепцията Protect за киберсигурност, има сигурността на системите и мрежите като оперативна способност и Protection като домейн на сигурността.

Тази класификация е полезна за доказателствата по NIS2, защото сегментацията не е декоративна диаграма. Тя е превантивен контрол, предназначен да намали радиуса на въздействие и да запази непрекъснатостта на съществената услуга.

Управление на уязвимостите, когато OT системите не могат просто да бъдат коригирани

NIS2 изисква сигурно придобиване, разработване и поддръжка на мрежови и информационни системи, включително обработване и оповестяване на уязвимости. В ИТ управлението на уязвимостите често означава сканиране, приоритизиране, прилагане на корекции и проверка. OT добавя ограничения.

Критичен HMI може да бъде коригиран само по време на планиран престой. Актуализация на фърмуер на PLC може да изисква участие на доставчик. Система, сертифицирана за безопасност, може да загуби сертификация, ако бъде променена неправилно. Някои наследени устройства може изобщо да нямат поддръжка от доставчик.

Zenith Blueprint, във фазата Controls in Action, Step 19, предоставя правилната одитна логика за технически уязвимости:

За системи, които не могат да бъдат коригирани незабавно, например поради наследен софтуер или ограничения за престой, внедрете компенсиращи контроли. Това може да включва изолиране на системата зад защитна стена, ограничаване на достъпа или засилване на мониторинга. Във всички случаи регистрирайте и формално приемете остатъчния риск, като покажете, че проблемът не е забравен.

Базовата линия в SME политиката е също толкова практична:

Инвентарът трябва да се преглежда на тримесечна база, за да се идентифицират остарели, неподдържани или некоригирани устройства

В Zenith Controls контрол 8.8 от ISO/IEC 27002:2022, „Управление на технически уязвимости“, е съпоставен като превантивен контрол, който поддържа поверителност, цялостност и наличност, съгласуван е с Identify и Protect, с управление на заплахи и уязвимости като оперативна способност в домейните Governance, Ecosystem, Protection и Defense.

Силен OT файл за уязвимост трябва да включва:

• Идентификатор на актив, собственик, зона и критичност
• Източник на уязвимостта, например съобщение от доставчик, скенер, уведомление от интегратор или разузнаване за заплахи
• Ограничения за безопасност и наличност
• Възможност за прилагане на корекция и планиран прозорец за поддръжка
• Компенсиращи контроли, например изолация, списъци за контрол на достъпа, деактивирани услуги или засилен мониторинг
• Одобрение от собственика на риска и приемане на остатъчния риск
• Доказателства за проверка след отстраняване или внедряване на компенсиращ контрол

Това превръща „не можем да приложим корекция“ от оправдание в одитируемо третиране на риска.

Отдалечен достъп на доставчици: критичната точка между NIS2 и IEC 62443

Повечето OT инциденти имат някъде измерение, свързано с трета страна. Акаунт на доставчик. Лаптоп на интегратор. Инструмент за отдалечена поддръжка. Споделени удостоверителни данни. Изключение в защитната стена, което е било временно преди три години.

NIS2 Article 21 изрично включва сигурност на веригата на доставки, уязвимости, специфични за доставчици, практики за киберсигурност на доставчиците и процедури за сигурна разработка. NIST CSF 2.0 също е детайлен по тази тема чрез критичност на доставчика, договорни изисквания, надлежна проверка, непрекъснато наблюдение, координация при инциденти и изходни клаузи.

Политиката за сигурност на трети страни и доставчици - SME на Clarysec формулира принципа ясно:

На доставчиците трябва да се предоставя достъп само до минималните системи и данни, необходими за изпълнение на тяхната функция.

За OT минимален достъп означава повече от ролеви достъп в приложение. Достъпът на доставчици трябва да бъде:

• Предварително одобрен за конкретна цел на поддръжката
• Времево ограничен и деактивиран по подразбиране
• Защитен с MFA или непрекъсната автентикация, когато е приложимо
• Маршрутизиран през сигурен бастионен хост или контролирана платформа за отдалечен достъп
• Ограничен до съответната OT зона или актив
• Журнализиран, наблюдаван и, при високорисков достъп, записван на ниво сесия
• Преглеждан след приключване
• Покрит от договорни задължения за сигурност и уведомяване при инциденти

Корпоративната Политика за IoT / OT сигурност включва отделно изискване за отдалечен достъп:

Отдалеченият достъп (за управление или обслужване от доставчик) трябва:

Тази клауза закрепва управленската точка, а детайлните изисквания трябва да бъдат внедрени в процедури за достъп, споразумения с доставчици, техническа конфигурация и работни потоци за мониторинг.

В Zenith Controls контрол 5.21 от ISO/IEC 27002:2022, „Управление на информационната сигурност във веригата за доставки на ИКТ“, е класифициран като превантивен контрол, който поддържа поверителност, цялостност и наличност, съгласуван е с концепцията Identify, със сигурността на взаимоотношенията с доставчици като оперативна способност и Governance, Ecosystem и Protection като домейни.

За OT това съпоставяне помага да се обясни защо доказателствата за отдалечен достъп принадлежат едновременно към файловете за риск, свързан с доставчици, управление на идентичности, мрежова сигурност, реагиране при инциденти и непрекъснатост.

Реагиране при инциденти: часовникът на NIS2 среща контролната зала

Обратно към алармата в 02:17. Организацията трябва да реши дали събитието е значимо по NIS2. Article 23 изисква уведомяване без неоправдано забавяне за значими инциденти, които засягат предоставянето на услуги. Последователността включва ранно предупреждение в рамките на 24 часа от узнаването, уведомление за инцидент в рамките на 72 часа, междинни актуализации при поискване и окончателен доклад не по-късно от един месец след уведомлението за инцидент или доклад за напредъка, ако инцидентът все още продължава.

В OT реагирането при инциденти трябва да отговори на въпроси, които ИТ наръчниците често пренебрегват:

• Може ли засегнатото устройство да бъде изолирано, без да се създаде риск за безопасността?
• Кой има правомощие да спре производството или да премине към ръчен режим?
• Кои журнали са летливи и се нуждаят от незабавно запазване?
• Кой доставчик или интегратор трябва да бъде уведомен?
• Събитието злонамерено ли е, случайно, причинено от околната среда или от неправилна конфигурация?
• Възможно ли е трансгранично въздействие или въздействие върху получателите на услугата?
• Засегнати ли са лични данни, например журнали от системи за контрол на достъпа, CCTV, данни на служители или записи за клиентско обслужване?

SME OT политиката дава просто правило за ескалация при аномалии:

Всички аномалии трябва да бъдат докладвани незабавно на Управителя за последващи действия

Тя включва и принцип за ограничаване, съобразен с безопасността:

Устройството трябва да бъде изключено от мрежата незабавно, когато това е безопасно

Последните пет думи са критични. OT реагирането не може сляпо да копира действията за ограничаване от ИТ. „Когато това е безопасно“ трябва да бъде отразено в наръчници, матрици за ескалация, обучение и настолни упражнения.

NIST CSF 2.0 се съпоставя добре тук. Неговите резултати Respond и Recover обхващат триаж, категоризация, ескалация, анализ на първопричините, целостта на доказателствата, уведомяване на заинтересованите страни, ограничаване, отстраняване, възстановяване, проверки на целостта на резервните копия и комуникации при възстановяване.

Изградете линия на доказателства от риска към контрола

Практичен начин да избегнете фрагментирано съответствие е да изградите една линия на доказателства от риска към регулацията, контрола и доказването.

Сценарий: доставчик на отдалечена поддръжка за компресор изисква достъп до инженерна работна станция в OT мрежата. Работната станция може да променя PLC логика. Акаунтът на доставчика е винаги активиран, споделя се от няколко инженери на доставчика и е защитен само с парола. Работната станция работи със софтуер, който не може да бъде надграден до следващия прозорец за поддръжка.

Запишете рисковия сценарий в регистъра на риска:

„Неоторизиран или компрометиран отдалечен достъп на доставчик до OT инженерна работна станция може да доведе до неоторизирани промени в PLC логика, прекъсване на производството, въздействие върху безопасността и прекъсване на услуга, подлежащо на докладване по NIS2.“

След това съпоставете контролите и задълженията.

Планът за третиране трябва да деактивира постоянния достъп на доставчика, да изисква именувани идентичности на доставчика, да налага MFA, да маршрутизира достъпа през контролиран бастионен сървър, да ограничава достъпа до инженерната работна станция, да изисква одобрение на билет за поддръжка, да записва привилегировани сесии, да наблюдава команди и необичаен трафик, да документира некоригираната работна станция като изключение за уязвимост и да тества реагиране при инциденти за подозрителна дейност на доставчик.

Zenith Blueprint, фаза Risk Management, Step 13, дава логиката за проследимост към SoA:

Кръстосани препратки към регулации: ако определени контроли са внедрени специално за съответствие с GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска (като част от обосновката на въздействието на риска), или в бележките към SoA.

Практическият урок е прост. Не дръжте доказателствата за NIS2, ISO и OT инженеринг в отделни силози. Добавете колони в регистъра на риска и SoA за тема по NIS2 Article 21, контрол по ISO/IEC 27002:2022, семейство изисквания по IEC 62443, собственик на доказателствата и одитен статус.

Къде се вписват GDPR и DORA в OT сигурността

OT сигурността не винаги е само за машини. Средите на критична инфраструктура често обработват лични данни чрез CCTV, системи за контрол на достъпа, журнали от пропуски, системи за безопасност на работната сила, билети за поддръжка, проследяване на превозни средства, системи за посетители и платформи за клиентско обслужване.

GDPR изисква личните данни да се обработват законосъобразно, добросъвестно и прозрачно, да се събират за конкретни цели, да се ограничават до необходимото, да се поддържат точни, да се съхраняват само толкова дълго, колкото е нужно, и да се защитават с подходящи технически и организационни мерки. Той изисква и отчетност, което означава, че администраторът трябва да може да докаже съответствие.

За OT това означава, че журналите за достъп и записите от мониторинг не трябва да се превръщат в неконтролирани хранилища за данни от наблюдение. Сроковете за съхранение, правата за достъп, ограничението на целите и оценката на нарушенията трябва да бъдат заложени в журнализирането и мониторинга.

DORA може да се прилага, когато участват финансови субекти или когато външен доставчик на ИКТ услуги поддържа оперативната устойчивост на финансовия сектор. DORA обхваща управление на ИКТ риска, докладване на инциденти, тестване на устойчивостта и риск от трети страни в ИКТ. За финансови субекти, които са и съществени или важни субекти съгласно правилата за транспониране на NIS2, DORA може да действа като секторно-специфичен режим за припокриващи се задължения, като координацията с органите по NIS2 може да остане релевантна.

Прилагат се същите дисциплини за доказателства: идентифициране на активи, защита, откриване, непрекъснатост, резервни копия, риск от трети страни, тестване, обучение и управленски надзор.

Одитната перспектива: един контрол, няколко гледни точки за уверение

Силното внедряване на NIS2 OT сигурност трябва да издържи на няколко одитни перспективи.

Затова Clarysec третира Zenith Controls като компас за кръстосано съответствие. Неговите атрибути на контролите помагат да се обясни целта на официалните контроли по ISO/IEC 27002:2022, а подходът за съпоставяне свързва тези контроли с NIS2, NIST CSF, управление на доставчиците, непрекъснатост и доказателства за одит.

Чести капани при внедряване на NIS2 OT

Най-честите провали в OT сигурността рядко са причинени от липса на документи. Те са причинени от документи, които не съответстват на обекта.

Капан 1: ИТ притежава NIS2 програмата, но OT притежава риска. Операциите, инженерингът, безопасността и поддръжката трябва да участват.

Капан 2: Инвентарът на активите спира до сървърите. OT инвентарът трябва да включва PLC, RTU, HMI, историзиращи системи, инженерни работни станции, индустриални комутатори, сензори, шлюзове, устройства за отдалечен достъп и компоненти, управлявани от доставчици.

Капан 3: Сегментацията съществува на диаграма, но не и в правилата на защитната стена. Одиторите ще поискат доказателства за прилагане, контрол на промените и мониторинг.

Капан 4: Изключенията за уязвимости са неформални. Ограниченията на наследени системи са приемливи само когато са документирани, одобрени, наблюдавани и периодично преразглеждани.

Капан 5: Достъпът на доставчици се третира само като въпрос на доставчици. Той е едновременно въпрос на контрол на достъпа, журнализиране, мониторинг, мрежова сигурност, реагиране при инциденти и непрекъснатост.

Капан 6: Реагирането при инциденти игнорира безопасността. OT наръчниците трябва да определят кой може да изолира устройства, да спира процеси, да сменя режими или да контактува с регулатори.

Капан 7: Докладването по NIS2 не е упражнявано. Процесът за вземане на решение в рамките на 24 часа и 72 часа трябва да бъде тестван преди реално събитие.

Пътят на Clarysec за внедряване от отчетност на управителния съвет до OT доказателства

Практическото внедряване на NIS2 OT сигурност може да следва тази последователност:

1. Потвърдете обхвата на NIS2, класификацията на субекта и критичността на услугата.
2. Определете OT обхвата в рамките на СУИС, включително интерфейси и зависимости.
3. Изградете инвентар на OT активи и потоци от данни.
4. Идентифицирайте правни, договорни, свързани с безопасността, поверителността и секторни задължения.
5. Проведете OT-специфични работни срещи за оценка на риска с инженеринг, операции, ИТ, SOC, закупуване и ръководство.
6. Съпоставете третирането на риска към контроли по ISO/IEC 27002:2022, теми по NIS2 и модели за внедряване по IEC 62443.
7. Актуализирайте Декларацията за приложимост с OT обосновка и собственици на доказателствата.
8. Внедрете приоритетни контроли: сегментация, достъп на доставчици, обработване на уязвимости, мониторинг, резервни копия и реагиране при инциденти.
9. Актуализирайте политики и процедури, включително OT сигурност, сигурност на доставчиците, отдалечен достъп, реагиране при инциденти и непрекъснатост на дейността.
10. Проведете настолни и технически упражнения за валидиране.
11. Подгответе одитни пакети за NIS2, ISO/IEC 27001:2022, клиентски уверения и вътрешно управление.
12. Включете констатациите в прегледа от ръководството и непрекъснатото подобрение.

Това отразява оперативния модел в Zenith Blueprint, особено Step 13 за третиране на риска и проследимост към SoA, Step 14 за разработване на политики и регулаторни кръстосани препратки, Step 19 за управление на уязвимостите и Step 20 за мрежова сигурност.

Същият подход използва политиките на Clarysec, за да превърне езика на рамките в оперативни правила. Корпоративната Политика за IoT / OT сигурност изисква преглед на архитектурата на сигурността преди внедряване:

Всички нови IoT/OT устройства трябва да преминат Преглед на архитектурата на сигурността преди внедряване. Този преглед трябва да валидира:

Тя също посочва:

Целият трафик в рамките на и между IoT/OT мрежи трябва да бъде непрекъснато наблюдаван чрез:

Тези клаузи създават управленски опори. Доказателствата за внедряване могат да включват OT IDS предупреждения, журнали на защитни стени, SIEM корелация, базови профили на трафика, тикети за аномалии и записи за реагиране.

Как изглеждат добрите NIS2 OT доказателства

Пакетът доказателства за NIS2 OT трябва да бъде достатъчно практичен за инженерите и достатъчно структуриран за одиторите.

За сегментация включете одобрена архитектура, диаграми на зони и канали, експорти на правила от защитни стени, записи за промени, периодични прегледи на правила, записи за изключения и предупреждения от мониторинг.

За достъп на доставчици включете оценка на критичността на доставчика, договорни клаузи, одобрена процедура за достъп, именувани акаунти, MFA доказателства, журнали за достъп, записи на сесии, периодичен преглед на достъпа и записи за отнемане на достъп.

За управление на уязвимостите включете инвентар, източници на съобщения, резултати от пасивно откриване, тикети за уязвимости, планове за корекции, компенсиращи контроли, приемане на риска и доказателства за приключване.

За реагиране при инциденти включете наръчници, контакти за ескалация, дърво за решение за докладване по NIS2, резултати от настолни упражнения, тикети за инциденти, проекти на уведомления до органи, правила за обработване на доказателства и извлечени поуки.

За непрекъснатост включете OT стратегия за резервни копия, офлайн или защитени резервни копия, резултати от тестове за възстановяване, списък с критични резервни части, ръчни оперативни процедури, приоритети за възстановяване и планове за кризисна комуникация.

За управление включете одобрение от управителния съвет или ръководството, възлагане на роли, записи за обучение, резултати от вътрешен одит, KPI, протоколи от преглед на риска и решения от прегледа от ръководството.

Този модел за доказателства е съгласуван с ISO/IEC 27001:2022, защото поддържа третиране на риска, документирана информация, оценка на резултатността и непрекъснато подобрение. Той е съгласуван с NIS2, защото доказва подходящи и пропорционални мерки. Той е съгласуван с IEC 62443, защото може да бъде проследен до OT архитектура и инженерни контроли.

Превърнете вашата OT програма за сигурност в одитируема готовност за NIS2

Ако вашата OT среда поддържа критична или регулирана услуга, чакането регулатор, клиент или инцидент да разкрие пропуските е погрешна стратегия.

Започнете с един случай с високо въздействие: отдалечен достъп на доставчик до критична OT зона, обработване на уязвимости за неподдържани индустриални активи или сегментация между корпоративната ИТ среда и OT. Изградете рисковия сценарий, съпоставете го с NIS2 Article 21, изберете контроли по ISO/IEC 27002:2022, преведете ги в модели за внедряване по IEC 62443 и съберете доказателствата.

Clarysec може да ви помогне да ускорите тази работа с Zenith Blueprint, Zenith Controls, Политиката за IoT / OT сигурност, Политиката за сигурност на Интернет на нещата (IoT) / оперативните технологии (OT) - SME и Политиката за сигурност на трети страни и доставчици - SME.

Следващото ви действие: изберете една OT услуга, картографирайте нейните активи и зависимости и създайте линия на доказателства от риска към контрола още тази седмица. Ако искате структуриран път за внедряване, 30-стъпковата пътна карта и инструментариумът за кръстосано съответствие на Clarysec могат да превърнат тази първа линия в пълна програма за NIS2 OT сигурност.