Comments 23
Статья назрела. Полностью поддерживаю. Но сейчас выступать с таким материалом можно разве, что на конференциях. На производственном совещании, такая позиция это в лучшем случае "ТЫ будешь отвечать, если ЧТО ТО произойдет?", в худшем "профессиональное самоубийство". Страх неизвестности самый устойчивый. Им сейчас больны все не достаточно погруженные в тему. Но надо об этом говорить на конференциях и семинарах, как когда то говорили об обратном, чтобы маятник развернулся. Тоже есть живой кейс, где "рекомендованный фаервол" душит АСУТП.
у меня тоже есть в коллекции инциденты: антивирус или дает загрузить обновление в плк с инженерной станции но не пускает в режиме отладки, или наоборот в отладчике подключается а при попытке загрузить обнову рвет соединение; с настроенными политиками антивирус работал на станциях операторов и архивной, но после обновления все политики и исключения пошли прахом -связи между серверами и контроллерами или пропали, или замедлился обмен ...и самое любимое по требования больших начальников иб..подключение флешек было заблокировано... а потом были разбирательства почему антивирус не обновляли полгода...эта тема уже начинала беспокоить году так в 2013, и самое грустное, что вопросы есть , а ответов ни стандарты не специалисты однозначных дать не могут....каждый находит свои условно безопасные решения....
Изложенное сильно напомнило анекдот про программистов и дятла разрушавшего цивилизацию. Создается ощущение что пром системы проектировали еще большие бездари, раз они рушатся .. да буквально от всего. уж если от сетевых пакетов перестает работать то это вопрос в первую очередь к качеству системы, тут вообще безопасники получается хоть как то от этого спасаю, файрволами то.
Вылет драйверов от обновлений вообще традиционная история что windows, что linux, да и маниакальная страсть к обновлениям - идет от архитектора ОС. Совать систему в интернет ради обновлений - в принципе ну такое себе. Недаром для ответственных придуман дистрибутив ltsp, а linux может вообще в монолите обновятся.
https по сути своей завязан на "левые" сервера в интернете, самопальные сертификаты - наше все, как то очень неоднозначно выходит.
Как можно рассчитывать на системы безопасности если их использование намеренно игнорируется. Пароль LOUVRE и 1234 явно не ИБ поставили. Зато так удобно. Или срочно подключить личный ноут на которым не только рабочий софт но и толпа всякого и без антивируса. Зато так удобно.
Ну и более философский разрез - почему вдруг инженер АСУТП так мечется чтобы спасти от убытков, а ИБ это прям не волнует. Хотя простой - по вине неправильно настроенных ИБ систем.
В общем что хочу сказать, очень однобокая тут подача. Боль понятна, проблема есть, но проблема комплексная, решать надо комплексно, а не "они плааахиеее".
На данный момент все выглядит именно так. Пришли не в чем не разобрались. Но правила свои устанавливают. Даже когда в гости заходите ноги вроде вытираете. Или нет ...?
Дефолтные пароли вообще через раз случаются.
почему вдруг инженер АСУТП так мечется чтобы спасти от убытков, а ИБ это прям не волнует
элементарно же, потому что ИБ за простои не отвечают, с них спрашивают за инциденты в инфобезе, к чему тут философию выковыривать...
Проблема на самом деле более комплексная чем только ИБ. Не знаю как зарубежом, но в РФ в последние годы в ИТ-сфере отчётливо проявляется системное непонимание что такое промышленное ПО и оборудование. Подверженные хайпу инженеры с огромным рвением накручивают свистелки-переделки и микросервисы на железки у которых вообще другая задача. Это выглядит так, словно кто-то пытается встроить интерьер люксового автомобиля в кабину пилота: красиво, инновационно, но абсолютно не соответствует назначению и требованиям среды
Наконец-то "слова не мальчика, а мужа":
В мире промышленных предприятий информационная безопасность становится новой религией. На совещаниях все чаще звучат слова «угроза», «комплаенс», «SOC» и «Zero Trust», вместо привычных «доступность», «надежность» или «MTBF». Инженерная дисциплина, закаленная реальными авариями, постепенно вытесняется бюрократией аудита и отчетами в PowerPoint.
Спасибо за свежий воздух!
Это ж что ж за производство, где ИБшник главнее АСУТПшника?
Если ИБ настаивает на внедрении всяких "безопасных" приблуд, то пусть несет полную ответственность за негативные последствия, вызванные работой этих приблуд. А то хорошо устроились выдавать на гора свои "ценные" рекомендации, но не отвечать за последствия.
П.С. убил ИБшника - спас дерево!
Да никто не будет отвечать. Они свои показатели выполнили и отрапортовали наверх, дальше не их проблемы. Работаю в телекоме уже много лет, конечно тут не критично важные производственные процессы, но то что инженеры на местах потеряли например доступ к оборудованию из-за ИБ - никого не волнует. Но в случае аварии вот вам 4 часа. устраняйте как хотите, хоть вслепую, и чтоб отчитаться.
Глас вопиющего в пустыне. Услышан конечно же не будет - некому. Хозяину оно было наверно было бы интересно, но вот только где он - у "больших" собственность размазана по акционерам, которые обычно где-то далеко и в офшорах. А когда кто-то из них и оказывается где-то близко - язык исполненных чек-листов по бестпрактисам/гайдлайнам/приказам ФСТЭК ему ближе и понятнее. Особенно когда что-то уже случилось и уже надо наказывать невиновных и награждать непричастных.
Да и в АСУ ТП не раз видел такое, которое падает от простого сканирования портов, какой уж тут аудит безопасности. Тут на хабре не раз отмечали, что в АСУ ТП зарплаты не блещут своим размером относительно других направлений разработки, ну общий технический уровень видимо тоже соотвествует.
Странно, что плохую реализацию требований регулятора выдают за практику.
Этого и следовало ожидать! Когда производители СКАДА систем с криками ура рассказывают о сращивании ИТ и ОТ, и как это хорошо. И интегрируют технологии ИТ в свои системы.
Как результат - вместе с ИТ в мир АСУ ТП пришла и ИБ.
А надо было всего-лишь не допускать этого сращивания, использовать свои решения. В отдельный мир ОТ забраться гораздо сложнее, чем в системы на ИТ технологиях.
Допустим, SCADA-сервер упал из-за вируса-вымогателя. Придет инженер, заменит диск
он не просто так называется "вымагатель" не просто зашифровал диск, а спёр данные к себе на удалённый сервак (если конечно канал есть, но он походу есть раз вирус смог туда попасть)
Любая система безопасности, которая этому мешает, играет против
так всегда и во всём - безопасность прямо противноположно удобству (использования), а ещё говорят что если пользователи начинают копротивляться, то значит (иб, админы) всё правильно делают
Сложилось чувство что пришел приказал с сверху выполнить требования по 239, а автор как 99% работащих на заводе начал сопротивляться новому).
Cказать что все ИБ тормозить и замедляет это конечно успех
«Деньги делает то, что работает»
Пункт 3. Точно такое же могу сказать и инженеров. подмены нету, склад закрыт, hart коммуникатор он не зарядил, бэкапы не сделали, с этим контроллером он не работал, и вообще это электриков.
Пункт 4. Допустим вирус шифровальщик зашифровал вам вообще все + ваши бэкапы. А так же положил контроллеры до состояние только в помойное ведро (поверьте такое есть), что делать будите, быстро восстановите?
Вывод: Не настраивайте системы ИБ "полу руками" как вы привыкли настраивать датчики на скрутки и перемычки.
Виды ущерба от ошибочных мер безопасности
Ну внедряйте с учетом специфики кто вам мешает, точно такое же я могу сказать, инженер заказал датчик без учета специфики, что датчик будет стоять в взрывоопасной среде на улице в минус 40.
Ошибочные меры любого на производстве влекут за собой прямые финансовые убытки, причем тут ИБ?
ну так обкатайте на стенде, я и логику контроллера на стенде обкатывал прежде чем в боевой грузить. В чем проблема то??
Неверно внедренный алгоритм АСУТП или неверно настроенный датчик так же может нарушить ход технологического процесса.
Кейc показателен тем, что обычные ИТ-практики (как высокая связность сети без изоляции) неприемлемы в АСУ ТПче за бред, в ИТ как раз все сигментируют, а вот в АСУТП все одно свитче, 90% местных инженеров не знают что такое vlan на заводе.
Как «защита» рушит производство: механизмы ущерба
NGFW / DPI / SSL-инспекция – нарушают синхронность работы устройств. Межсетевые экраны с глубокой инспекцией пакетов, а также средства перехвата и расшифровки трафика часто некорректно обрабатывают или задерживают трафик промышленных протоколов. Есть статистика?? может быть замеры есть??
Зато кино которое приносят на флешке в ночную смену оператор, не сильно нагружает cpu??
Ну так или сами тестируйте или платите вендору. Мне yokogawa говорила что данный патч Windows протестирован с моей версией софта, и ставил без проблем. И еще есть такая практика прежде чем что то обновлять надо сделать бэкап.
Забытый пароль оператор тоже может повлечь за собой такое. Не разу не видел что бы в скаду по sms заходили, делал по пропускам, пока пропуск лежит скада доступна.
дальше не смог читать. извините.
----
В голове появилась аналогия с дедом который всю жизнь управлял насосами с помощью 2 кнопок, и щите у него было две ПВ10.1.Э. И тут я пришел ему внедрять РСУ, и вот примерно тоже самое было, только надо ИБ заменить на современную РСУ.
Вот, кстати, отличный пример того, о чём и была статья.
Подход «мы знаем, как правильно, сейчас всё исправим — а отвечать будете вы» прекрасно описывает классическую ситуацию с внедрением ИБ в АСУ ТП. Инженеров делают и ответственными за безопасность, и виноватыми в любых последствиях. Скоро действительно дойдём до того, что инженеры станут ещё и бухгалтерами.
1. Про «не тот датчик».
Если инженер заказал не тот датчик — он его просто не поставит.
Максимум — датчик выйдет из строя, и его заменят.
Это локальная история.
А вот фраза «ну внедряйте с учётом специфики» — при том, что специфика АСУ ТП игнорируется самой ИБ — отлично показывает уровень ответственности: требования есть, а последствия — не наши. Именно об этом статья.
2. Про “ошибки бывают у всех”.
Я именно это и описываю. Разница только в масштабе.
Ошибка инженера → выходит из строя один участок и он сам потом их исправляет.
Ошибка ИБ → может вывести из строя сеть, SCADA, десятки контроллеров, а кто исправляет?
Это несопоставимые последствия.
3. «Обкатайте на стенде».
Вопрос на миллион: кто создаёт эти стенды?
Когда ИБ требует изменения — ИБ должна и обеспечивать инфраструктуру для тестов.
Но в реальности:
стендов нет,
бюджета нет,
условий нет,
сроки «делайте вчера».
И всё тестируется на живом производстве.
Вот почему это опасно.
4. «Неверный алгоритм тоже ломает процесс».
Согласен — и такие поломки встречаются часто.
Но ИБ-инструменты, внедрённые без понимания работы оборудования, мешают этим поломкам обнаруживаться и устраняться.
Как только вводят ИБ-политику, инженеры начинают терять время даже на самые обычные ремонты и диагностику. А простой стоит дорого.
Это не теория — это ежедневная практика на многих заводах.
5. «Сегментация — нормально».
Сегментация сама по себе — отличная вещь.
Но если, как вы же и пишете, «90% инженеров не знают, что такое VLAN», то при первом же сбое:
инженеры не могут починить,
цех стоит,
ИБ разбирается «когда дойдём»,
потери идут прямо сейчас.
Именно это и было описано в статье.
6. «Есть статистика, что DPI/NGFW ломают протоколы?»
Да. Причём официальная:
NRC по инциденту Browns Ferry — отказ насосов именно из-за сетевого воздействия.
Dragos — DPI вызывает задержки, несовместимые с OT-протоколами.
Siemens и Rockwell прямо пишут о невозможности DPI/SSL-inspection на ряде промышленных протоколов.
Ну и Stuxnet, конечно — удивительно, что вы его не упомянули.
Если есть гипотетическая возможность повлиять на оборудование — это риск, а не «гипотеза». Завод — не пиксели на экране. Тут любая задержка может превратиться в HAZOP-сценарий.
7. «Оператор приносит кино на флешке».
Это было актуально лет 15–20 назад.
Для решения проблемы флешек их не нужно заливать USB смолой.
Нужно просто создать удобный, не мешающий работе легальный канал обмена файлами.
Когда ИБ вводит только запреты, но не даёт рабочих инструментов — появляются “обходные пути”. Это нормальная социальная реакция.
8. «Тестируйте сами или платите вендору».
Вот опять классика:
требуем — но условия для выполнения не создаём.
Если ИБ инициирует действия, она должна:
организовать стенд,
обеспечить тестовые среды,
иметь бюджет,
нести ответственность.
А не перекладывать всё на инженера, который не инициировал изменения.
9. «Забыл пропуск — не зайдёшь».
Именно.
В реальности может быть ситуация:
эксплуататор стоит перед аварийной ситуацией,
видит проблему глазами,
а войти в систему не может,
потому что карточку забыл, срок истёк, пароль сменили, MFA упал.
И авария развивается. Это не шутка — это реальность многих предприятий.
То, что вы не смогли дочитать текст, но при этом написали комментарий — это очень точно отражает текущую практику внедрения ИБ в АСУ ТП.
Требования формируются без изучения контекста, процессов и последствий.
Вы сами только что это продемонстрировали.
Тем не менее — спасибо за комментарий.
Он стал хорошей иллюстрацией к статье.
1. Про «не тот датчик».
У меня были случае когда инженер откручивал термопару вместе с карманом, хорошо там был воздух. Кто сказал что он его не поставит? Еще как поставит. И не такое встречал.
2. Про “ошибки бывают у всех”.
Не правда, обычный инженер в состояние остановить все по одной только блокировке. Десятки контроллеров, если сеть не сигментирована и бай дизайн плохая, то в таком случае ей никто не поможет, тот же инженер может эту сетку и потушить. когда включить свой ноут с WOT в пром сеть , что бы прошивку выгрузить с контроллера.
3. «Обкатайте на стенде».
Ну и причем тут ИБ если у вас нет бюджета. У меня нет денег что бы поменять контроллер, который сгорел. АСУТП виноват что производство стоит?? Обычно бюджеты планируются на год. и ИБ это процесс, а не так как привыкли на заводе, починил и дальше на топчане лежать . Заложи в бюджет не дали денег на стенд, руководство будет брать риски на себя. Если вы и есть то самое руководство которое не хочет этих рисков, значит надо подумать в строну как это сделать с минимальным бюджетом и риском. Если так рассуждать, то замена датчика тоже опасная вещь. А если думать не хочется, то тут ничего не поможет.
4. «Неверный алгоритм тоже ломает процесс».
не вижу связи как они вам мешают. Как firewall который разрешает ip to tp мешает отладки криво написанной алгоритма который загрузили в ПЛК. Я работал по обе стороны, и говорю это не просто так. Будучи инженером я тоже не хотел пускать ИБ и я отлично вас понимаю, потому что они не знают специфики так же как и инженеры на заводе не знаю про ИБ. Вот это проблема, но это не повод говорить что ИБ сломало мне все АСУТП ))))
5. «Сегментация — нормально».
не думаю что сигментации сломает вам завод, либо у вас весь завод на скрутках, либо в понимание как оно там все работает. проверит доступность контроллера по сети мне кажется в состояние любой. а дальше по цепочке проверить) Это ничем не отличается от того если бы у вас не было сигментации.
сдох свич, быстро нашли.
сдох свитч с виланами, ряяяяя ИБ виноваты.
6. «Есть статистика, что DPI/NGFW ломают протоколы?»
и при этом сименс сам продает Industrial Next Generation Firewall который по сути Palo Alto и да он может )) Capable of inspecting layer 7 traffic such as S7 protocol (detecting: start, stop, read, write) or OPC
И тут думаю дело не в dpi а именно в ssl. Лично не присутствовал но видел у российских вендоров сертификаты что они не влияют на goose а там тайминги очень жесткие.
stuxnet уже не принято давно употреблять) Примеров с того времени полно накопилось))
Задержка может возникнуть в плохо обжатом патч корде или то что его мудрый инженер выбрал не экранированный и проложил его вместе с высоковольтным кабелем.
7. «Оператор приносит кино на флешке».
до сих пор это актуально, сидит он в операторной, телефон нельзя, или связь не ловит в операторной, сразу флешка появиться., легальные инструменты что бы смотреть кино?? то есть денег на стенд нету, а сделать канал обмена данным для просмотра фильмов есть)) В целом я тоже поддреживаю что бы у низ был комп который никуда не подключен, для развлечения. Сидел ночами на заводе - знаем.
8. «Тестируйте сами или платите вендору».
Если у вас начальник инициирует изменение в логики контроллера?? пусть сам идет пишет тогда свой алгоритм а не перекладывает все на АСУТП?))
Как иб должен создавать АСУТП стенд? Тоже самое что АСУТП не знает что делать с файрволом. Так про что угодно можно сказать. В этом и смысл, вместе поработать и друг с другом обменяться знаниями. Это только подтверждает тот что ничего нового нам не надо, это лишняя работа, мы привыкли реле протирать, и до конца смены лежать на стульях. Это не наше!! ЭТО ИБ, киповцев, электриков, технологов (нужное подчеркнуть )
9. «Забыл пропуск — не зайдёшь».
тут все просто, забыл пропуск на завод не попадешь в целом. В целом слыхал я про такие аварии когда видишь но ничего сделать не может, а почему ?? да потому что инженера ногами написали алгоритм ПАЗ и откуда они растут его проверили))
Но в целом бай дизайн уже не верно. Случалась авария все остановилось. Клапана перешли в безопасное состояние, что надо открыло что надо закрылось. А не так что дядя ваня должен нажимать на кнопки когда давление зашкалило. Но всю специфику производства не знаю. сужу только во своему опыту, было приблизительно так.
"Требования формируются без изучения контекста, процессов и последствий. "
Так нужно проверить эти требования если есть такая возможность и внести правки с учетом ваших требований. Если вам формализовали такие требования ну так аргументируйте это, ток не как в статье что все зависает , ломается и взрывается как только firewall в сети появляется.
Да вам тоже спасибо за статью, вспомнил что примерно так же думал))
Ущерб от бездумного внедрения ИБ в АСУ ТП: когда «защита» становится угрозой