Comments 27
Осталось понять, какой стандартный протокол верхнего уровня можно считать доверенным. Допустим, opc ua. А второе ;-) - где в РФ взять резервируемый ПЛК, который это вывезет, в товарных количествах. И третье - схема вписывается требования НТД, например, о том, что ПЛК должны работать автономно без верхнего уровня, позволяя безопасно управлять тех процессом. Четвëртое - резервирование в такой схеме, тот ещё ад будет. Пятое - ПНР и развëртывание, уже представил боль наладчиков. Они модбас-то не все могут настроить, а тут opc ua с шифрованием (и сертификатами)
Предложенные решения не пройдут даже минимальную экспертизу по промышленной безопасности. В который раз убеждаюсь, что в серьезных вещах айтишникам пока не место. Рано. Уровни абстракции не доросли.
Интересно, на чём же нас минимально экспертно завалят.
Условия, которые должны быть обеспечены иными способами, чтобы наша система выполняла цели безопасности:
Оператор благонадёжен
Вот это прямое противоречие с тем же МЭК 61508
Противоречие какому конкретно пункту? И как вы техническими средствами контроллера предлагаете обеспечивать благонадёжность оператора?
Пункту? Этот IEC - основой руководящий документ по теме, которую вы тут описываете. Соглашусь с коллегой выше, это база.
Сама концепция функциональной безопасности ОПО говорит о том, что неважно, кто именно оператор. Он не должен иметь возможность предпринять действия, компрометирующие безопасность объекта. Благонадежен он или нет, это второй вопрос. Если эти ваши игрища с докерами не трогают безопасный контур, то пускай. Хотя вы там частоту вращения турбины с минутной агрегацией смотрите, так что вряд ли.
Вы похоже не знакомы с термином "предположения безопасности". Ознакомиться с ним можете, например, тут: https://www.securitylab.ru/informer/240673.php
Понятия "хакатон" и "скоуп задачи" оставлю вам в качестве домашнего задания.
Для знакомства и ваших навыков чтения. Человек выше говорит про противоречия со стандартом МЭК 61508. https://docs.cntd.ru/document/1200100344
Просто прочтите НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ на титульнике стандарта и подумайте можно ли его не выполнять на территории РФ. Ну и вообще ссылаться на статью 2004 года в 2023 это сильно. Вы уверены что за 19 лет ничего не поменялось?
Так у меня-то претензия, что вы с "предположениям безопасности" лезете не туда. Спокойно устраивайте "хакатоны" и "скоупы" в своих "стартапах", для этого придумали "антикафе" и "смузи" же.
Ваша статья не подходит тут, так как оценивает только безопасность ИТ, а необходимо иметь комплексную оценку всего опасного производственного объекта. Это отдельная категория, тут вам знаете не это! :)
Знаете, я придумал аналогию. Давайте оценим безопасность ПО внутри автомобиля в процессе работы. Представим, что водитель трезвый...
Upd: претензия снимается. Это же и было все в рамках хакатона, пусть там и остается. Виноват, подумал вы и впрямь что-то продуктовое готовили.
Возможно я открою для вас тайну, но да, автомобили проектируют для трезвых водителей. Ибо трезвость водителей обеспечивается другими, не конструкционными способами. Вы бы лучше почитали, а не выпендривались, выдавая очевидные вещи за какие-то откровения.
Нет, я для этого ханипота и придумывал аналогию. Если бы автомобили разрабатывались для трезвых, то на конвейере были бы системы, не допускающие пьяных, а вы, как айтишник, занимались бы безопасностью и устойчивостью таковых ко взломам.
Автомобили проектируют для любых водителей. Однако изначально закладывается риск того, что пьяный или еще какой водитель заснет и повиснет на руле влево, например. И тогда система безопасности должна: определить степень риска (ASIL A/B/C/D), возможную опасность (скорость там, положение на дороге, сближение с разметкой) и принять решение - дернуть руль, остановить, etc. Я свою свинособаку проверял - если отпустить руль, то пикает, потом рулем выравнивает машину, потом с аварийкой останавливается. Здесь тоже есть с десяток датчиков, с пяток исполнительных механизмов, и тоже 12+нужен контроллер, и тоже есть различные проблемы доверия, и обновления надо делать, причем "доверенное устанавливать, не доверенное не устанавливать". Но нельзя взять и разработать кусок, который занимается установкой доверенных обновлений не глядя на остальные вопросы функциональной безопасности.
Впрочем, я занудствовал только потому, что не понимал, что это просто работа в рамках хакатона.
И ладно ТЭЦ, но вот к примеру на АЭС ваше решение даже физически не на чем исполнить будет
При чём тут АЭС и в чём проблема физически запускать свой код на своём же контроллере?
Вообще базисно цель построения АСУ ТП это как раз таки физическое разделение управления на раздельные независимые подсистемы, где идет уменьшение точек отказа как раз таки из-за построения локальных микросистем. А Вы предлагаете взять все и поменять — выстроить единую централизованную систему, которая будет всем управлять. А можно еще и ИИ для управления прикрутить — круто же) Обеспечение отказов должно идти снизу вверх (с полевого уровня) вплоть до использования дискретных релейных систем, до уровня ПЛК, где ничего нельзя залить физически кроме производителя оборудования, который на 15-20 лет несет гарантийные обязательства и соответственно с высокоуровневой SCADA/ERP уже можно творить что хочешь, но на управление тех процессом это влиять не должно.
В главе "Архитектура" утверждается, что система децентрализованная, но вам, наверное, виднее. А в главе "Узлы системы" есть мистический узел "Defender", по описанию которого видимо совсем не понятно, что он делает. А уж гарантийное обновление ПО, которое от нас хотели представители реального вендора - это, наверно, просто фантастика.
Нет, я внимательно все прочитал — децентрализацию вижу в Вашем понимании больше логическую, чем физическую. Не все должно управляться "умными машинами", а большая часть простыми как пробка датчиками, задача, например если берем аварийку и противоаварийную защиту (ПАЗ), то контролировать что что-то сработало. Ну при совсем большом желании можно поверх прикрутить систему диагностики, этим Katser кстати занимаются более менее по моему видению) Вендор лок это ситуация о двух концах — дать исходники кода и участвовать в его доработке и поддержке на контрактной модели это одно (выбор — поддержка оборудования дело Заказчика либо Подрядчика) или просто высасывать деньги с Заказчика это разные подходы. Тут все зависит от ТЗ и конкретного подхода вендора к проекту. Согласен, подходы бывают разные)
в серьезных вещах айтишникам пока не место
Им там не место впринципе, ни пока, ни через 100 лет. Из энергетики, транспорта, медицины, оборонки, да и из финансов их тоже надо поганой метлой гнать.
Архитектура крипто ТЭЦ