Свързването на OEE софтуер с мрежата от ПЛК в производствено предприятие създава нов път за данни между оперативните технологии (OT) и информационните технологии (IT).
В повечето заводи OT мрежите са умишлено изолирани от корпоративните IT мрежи, за да се защитят производствените системи от киберзаплахи, компрометирането на ПЛК в производството представлява риск за безопасността и за непрекъснатостта на бизнеса, а не само риск за сигурността на данните.
Всеки софтуер, който пресича тази граница OT‑IT, включително OEE платформи, изисква строга оценка на сигурността преди внедряване. Ситуацията със сигурността на OEE софтуера се е подобрила значително през последните пет години, но вариациите между доставчиците са големи.
OEE платформи, разработени за облака (cloud‑native) и изградени върху модерни архитектури за сигурност, имат принципно различни профили на сигурност в сравнение с локалните (on‑premise) OEE системи, създадени през 2000‑те години, които не са проектирани с оглед на сигурността на границата OT‑IT.
Въпросите в оценката за сигурност трябва да изведат тези различия и да създадат документирани доказателства за позицията по сигурността на доставчика, които вашите IT и OT екипи по сигурността могат да прегледат преди одобрение на мрежовата свързаност.
Последствията от недостатъчната оценка на сигурността на OEE варират от незначителни, неоторизиран достъп до данни или проблеми със съответствието по отношение на поверителността, до тежки, рансъмуер, проникващ в OT мрежата чрез компрометиран OEE сървър и нарушаващ производствените операции.
Като се има предвид, че OEE софтуерът е свързан с производственото оборудване на всяка линия, компрометирана OEE платформа има по‑широк достъп до мрежата отколкото повечето IT системи, които се свързват с OT средата. Този повишен рисков профил оправдава по‑задълбочен преглед на сигурността в сравнение със стандартните оценки на корпоративния софтуер.
Въпроси относно архитектурата и потока на данни: (1) Използва ли платформата за OEE еднопосочна архитектура на потока от данни от OT към IT (само за четене от ПЛК), или има възможност за двупосочна комуникация? (2) Къде се съхраняват производствените данни, локално (on-premise), в конкретен облачен регион или в споделен мултинаемателен облак?
(3) Поставен ли е OEE сървърът в DMZ между OT и IT мрежите, или изисква ли директен достъп до двете мрежи едновременно? (4) Кои мрежови портове и протоколи изисква платформата за OEE да бъдат отворени между OT и IT мрежите? (5) Поддържа ли платформата OEE внедряване без входящи връзки от интернет (изолирано/air‑gapped или локално внедряване)?
Въпроси за удостоверяване и контрол на достъпа: (6) Поддържа ли платформата SAML 2.0 или OIDC за интеграция със служебно SSO? (7) Поддържа ли се многофакторно удостоверяване (MFA) и може ли да бъде наложено за всички потребителски роли?
(8) Прилага ли платформата ролево базиран контрол на достъпа (RBAC), който ограничава достъпа до данни въз основа на завод, линия и функция? (9) Съществуват ли отделни администраторски идентификационни данни за OEE приложението и за подлежащата инфраструктура (база данни, операционна система)? (10) Как се управляват и ротират API ключовете и идентификационните данни на служебните акаунти?
Въпроси за сигурността на данните: (11) Криптирани ли са данните при пренос, използвайки TLS 1.2 или по‑висока версия за всички комуникации? (12) Шифровано ли е съдържанието при съхранение (at rest) и кой стандарт за криптиране се използва? (13) Кои производствени данни се изпращат в облака и кои се задържат локално (on‑premise)?
(14) Записва ли платформата всички събития за достъп на потребители и действия по експортиране на данни в одитен журнал, достъпен за клиента? (15) Каква е политиката за задържане на данни и процесът на изтриване при прекратяване на договора от клиента?
Въпроси за управление на уязвимости и реагиране при инциденти: (16) Какъв е процесът на доставчика за разпространение на пачове за сигурност и какво е типичното време от разкриване на уязвимост до наличност на пач?
(17) Извършил ли е доставчикът тест за проникване от трета страна през последните 12 месеца и достъпно ли е изпълнителното резюме на находките? (18) Има ли доставчикът публикувана политика за разгласяване на уязвимости и специален контакт за сигурност?
(19) Какво е SLA‑то на доставчика за реагиране при инциденти, ако бъде открит пробив в сигурността, засягащ данни на клиента? (20) Притежава ли доставчикът съответни сертификати за сигурност (ISO 27001, SOC 2 Type II), които обхващат инфраструктурата на OEE платформата?
Когато оценявате отговорите на доставчиците в анкетата за сигурност, търсете конкретика, а не общи твърдения.
Доставчик, който на въпроса „Дали данните се криптират при трансфер?“ отговаря „да, използваме криптиране по индустриален стандарт“, е по-малко достоверен от този, който отговаря „да, всички комуникации използват TLS 1.3 с certificate pinning в мобилните клиенти.“ Неясните позитивни твърдения са лесни за правене; конкретните технически твърдения са по-трудни за фалшифициране и по-лесни за проверка.
Третирайте определени отговори като стоп точки, които изискват разрешаване преди одобрение за внедряване. Това включва: двупосочна мрежова комуникация от системи за оперативни технологии (OT) към облака на доставчика (създава входна повърхност за атаки) липса на поддръжка на многофакторна автентикация (MFA) за административен достъп (неприемливо за системи, свързани с OT)
съхранение на данни в юрисдикция, която противоречи на изискванията ви за суверенитет на данните липса на тест за проникване от трета страна през последните 18 месеца и липса на документиран процес за реакция при инциденти. Това не са предмет на преговори, това са базови изисквания за сигурност, които отговорната защита на OT мрежите налага.
Вградете изискванията за сигурност, които доставчиците трябва да изпълнят, в договора за покупка преди подписване.
Включете конкретни клаузи, обхващащи: задължения за уведомяване, ако доставчикът открие инцидент за сигурността, засягащ вашите данни; правото да проведете собствена оценка на сигурността на платформата ежегодно; задължението на доставчика да отстранява критични уязвимости в рамките на 30 дни; и правото на клиента да прекрати договора без санкции, ако доставчикът не изпълни ангажиментите си по сигурността.
Изискванията за сигурност, които не са включени в договора, са предложения, договорните изисквания за сигурност са задължения, които създават средства за защита при нарушение.
Вход
Блог
