Работу станков, линий и технологических комплексов определяют проекты ПЛК, и любое несанкционированное изменение в их коде может привести не только к аварии и простоям, но и к угрозе безопасности людей. При этом на многих предприятиях до сих пор отсутствует системный контроль версий: рабочие проекты хранятся на отдельных компьютерах или даже на флешках.
Автор: Владислав Ганжа, руководитель производственного направления лаборатории кибербезопасности UDV Group
Контроль версий в промышленности – это не просто инструмент удобства инженеров, а фундаментальный элемент кибербезопасности. Однако есть сложности в использовании на предприятиях традиционных систем контроля версий, ведь среды разработки проектов ПЛК в АСУ ТП имеют свою специфику. Рассмотрим этот вопрос подробнее.
Несовместимость с ИТ-практиками
Такие известные решения для контроля версий, как Git, к работе с АСУ ТП практически не применимы. Причина простая: каждая среда разработки предполагает свои подходы к хранению и обработке кода. Проект может храниться, например, в виде набора файлов, либо одного большого бинарного файла, который умеет читать только проприетарная среда разработки. В промышленности почти все проекты ПЛК – это бинарные или полубинарные форматы, завязанные на проприетарные среды, такие как TIA Portal от Siemens, Unity Pro от Schneider Electric, CODESYS и др. Тогда как Git изначально был ориентирован на работу с исходными кодами ядра Linux, то есть с множеством небольших текстовых файлов.
Форматами, завязанными на проприетарные среды, продолжают пользоваться многие российские предприятия, где старые производственные линии остаются на зарубежных решениях. Однако надо отметить, что в свете тренда на импортозамещение успешно развиваются и российские среды разработки. Неплохие результаты, например, у компаний "Прософт-Системы", ТРЭИ и некоторых других. Новые производственные линии сейчас изначально строятся на российских продуктах.
Но мало просто импортозаместить среду разработки АСУ ТП – нужно обеспечить ее корректную работу с ПЛК и настроить так, чтобы она поддерживала параметры, критичные для технологического процесса. Это трудоемкая и дорогостоящая задача: любая ошибка в конфигурации может привести к сбою и потребовать повторной настройки, а это отнимет часы или даже дни. Именно поэтому сейчас в приоритете не расширенные функций, а повышение надежности базового функционала, включая возможность версионирования проектов ПЛК. Система, которая позволяет быстро откатиться к стабильной версии и восстановить работу за несколько минут, становится не просто удобством, а инструментом экономии ресурсов и снижения рисков простоя.
Работа в условиях реальности цеха
В отличие от классической ИТ-разработки, изменения в логике ПЛК в АСУ ТП могут вноситься прямо на производстве и в срочном порядке – в соответствии с текущими задачами, часто без полноценного документирования и тестирования. Горячие правки особенно характерны для металлургии и пищевой промышленности.
С тестированием в АСУ ТП ситуация принципиально сложнее: невозможно воссоздать все сценарии технологического процесса в эмуляторах, а имеющиеся тестовые стенды редко покрывают полный набор производственных условий. Поэтому надежность и предсказуемость изменений обеспечиваются не столько за счет предварительных проверок, сколько за счет опыта инженеров и строгих процедур восстановления.
При этом риски ошибок в АСУ ТП выше, чем в классическом ИТ. Стоит допустить неточность в работе с контроллером, как соответствующий техпроцесс начинает идти по неверному сценарию. А это – производственный брак, простой линии, выход из строя оборудования и пр.
Отсутствие централизованного подхода
Вендоры начинают встраивать элементы контроля версий в свои IDE – это позитивный тренд, поскольку централизованного управления изменениями в АСУ ТП до сих пор почти нет. На практике часто используется простая схема: на инженерной станции установлена среда разработки проектов ПЛК, доступ к ней осуществляется через локальную учетную запись с минимальными требованиями к безопасности – без сложных паролей, журналирования и разграничения прав. Любой инженер из службы АСУ ТП может внести изменения в код на свое усмотрение, не сохранив резервную копию в доверенном хранилище. В результате при сбое или конфликте версий невозможно точно определить, кто какие правки внес и где находится актуальная копия проекта.
В редких случаях условно централизованный внутренний процесс можно обнаружить на базе кастомизаций. Например, есть общий сетевой ресурс, куда по внутренним инструкциям инженеры отправляют проекты. Обычно такие механизмы разрабатывают предприятия с высоким уровнем цифровой зрелости. На это тратится много ресурсов, однако у регуляторов могут возникнуть вопросы относительно сертификации и обеспечения безопасности, особенно если критичный процесс реализован на зарубежных ОС.
Технические особенности решений для ПЛК в АСУ ТП
Эти особенности обусловлены сложностью систем АСУ ТП, многие их них относятся к объектам критической информационной инфраструктуры.
1. Хранение золотых эталонных конфигураций для быстрого восстановления. При модернизации и импортозамещении АСУ ТП предприятия часто привлекают интегратора АСУ ТП в качестве подрядчика. Эксперты грамотно выполняют сложный процесс пусконаладки, который, как правило, происходит постепенно, уровень за уровнем, без полной остановки производства. Золотые копии работ подрядчика хранятся, чтобы в дальнейшем служба эксплуатация могла разобраться в ходе внесения изменений. Золотые копии также помогают максимально быстро восстановить настройки, если контроллер выходит из строя или надо запустить ранее отлаженный проект на новом контроллере. 2. Интеграция с Active Directory/LDAP для управления доступом. Персонализированные учетные записи в сегментах АСУ ТП уже появляются, но этот процесс идет медленно. До сих пор инженеры часто работают под одной учетной записью. Интеграция со службой каталогов для управления парольной политикой и разграничения доступа позволяет организовать централизованное управление учетными записями и полномочиями. 3. Поддержка работы в условиях ограниченной сети. Для сокращения возможных векторов атак объекты КИИ зачастую работают on-premise, без выхода в Интернет. Это касается и АСУ ТП, и хотя вопрос конфиденциальности стоит не так остро, но вопросы целостности и доступности критически важны.
Внедрение систем контроля версий проектов ПЛК может значительно повысить информационную безопасность предприятия.
• Значительная часть инцидентов кибербезопасности на предприятиях связана не с внешними атаками, а с действиями сотрудников и подрядчиков. Случается, что внутренний нарушитель – не инсайдер, он что-то перепутал по незнанию или неопытности. Ущерб, впрочем, от этого меньше не становится. Организованный контроль версий позволяет выявить, кто и когда внес изменения в проект и загрузил его на контроллер. • Поскольку версии позволяют отследить значимые действия с проектами ПЛК, они становятся доказательной базой при внутреннем расследовании или при проверке регуляторов. • В случае кибератаки или ошибки инженера можно быстро восстановить проверенную версию проекта из архива, а не заниматься археологией по флешкам. Вспомним, что даже часовой простой АСУ ТП может обернуться для предприятия потерями в миллионы рублей. • Контроль версий помогает генерировать события ИБ. Если проведена интеграция с SIEM и SOC, то при попытке загрузки нового проекта или внесении изменений в код система покажет и поможет определить: сделано это в рамках производственной задачи или изменения не задекларированы, произошли вследствие несанкционированного проникновения. • Практическая ценность управления версиями
Управление версиями ПЛК дает предприятиям ряд преимуществ как в части соблюдения требований регуляторов, так и внутренней дисциплины.
• В IEC 62443 прямо указана необходимость процедур Change Management, а ФСТЭК России в новых методических рекомендациях акцентирует внимание именно на контроле изменений проектов ПЛК. Требования регуляторов – весомая причина, по которой все больше предприятий переходят от бумажного соответствия к практической реализации контроля версий. • При наличии системы версий можно за минуты показать аудитору историю изменений и регламенты – вместо недельной ручной подготовки. Любая другая отчетность строится легче и для руководителя, и для инженера, если можно посмотреть, какие практики кода применялись. • MTTR (Mean Time to Recovery) – ключевой показатель устойчивости киберфизических систем. В любой момент на предприятии что-то может сломаться, пойти не по плану, и это не всегда зависит от человеческого фактора. Но система контроля версий дает уверенность, что инженеры в любой момент смогут сделать "как два дня назад, когда все работало хорошо". • Если инженеры знают, что каждый их шаг фиксируется, они действуют более осторожно и собранно, снижается количество ночных патчей на объекте без уведомления. Порой инженеру, который хорошо знает свою линию, не хочется согласовывать работы. И есть соблазн быстро внести изменения так, чтобы никого не беспокоить. При наличии контроля такое своеволие постепенно сходит на нет. • Заказчики все чаще требуют от интеграторов демонстрацию сквозного процесса управления изменениями, а не коробочных неадаптированных решений. Они хотят инвестировать в бизнес-процессы, которые удобны и понятны, приносят ощутимую пользу сотрудникам и не вызывают саботажа.
Можно выделить типичные негативные последствия, которые повторяются на предприятиях, где не ведется контроль версий ПЛК.
• До сих пор встречаются объекты, где последний актуальный проект хранится у дежурного инженера на USB-накопителе, на рабочем компьютере сотрудника или сохраняется на неучтенный файловый сервер, который никто не администрирует, на котором нет разграничения прав доступа и резервного копирования. • Когда у предприятия нет процедуры ведения актуальных версий, то изменения могут быть внесены не в актуальную версию, а в одну из предыдущих. При этом те изменения, которые вносились прежде и сформировали актуальную версию, теряются. • Если на предприятии не предусмотрены процедуры резервного копирования, единственный экземпляр проекта может потеряться в процессе обновления, настройки, при выходе из строя жесткого диска. • Злоумышленник может подменить файлы проекта, скомпрометировать файловый сервер, а поскольку проекты в АСУ ТП сложные, при подмене файла проект, скорее всего, перестанет корректно работать.
Вывод
Вывод простой: контроль версий ПЛК – обязательный элемент для предприятий, не желающих рисковать стабильностью работы АСУ ТП
Практика показывает, что довольно большое число инцидентов в АСУ ТП связано с изменениями в коде ПЛК без фиксации и контроля. Там, где проекты до сих пор хранятся на флешках или на рабочих столах инженеров, риск потери данных или подмены логики – вопрос времени.
Система контроля версий позволяет быстро вернуть проверенную конфигурацию после сбоя, показать полную историю изменений за минуты и зафиксировать, кто именно внес изменения в код контроллера. Это не дополнительная опция, а инструмент, который снижает среднее время реагирования закрывает все более строгие требования ФСТЭК России и способствует защите производства от простоев и аварий.
Инженеры МегаФона модернизировали телеком-оборудование в важнейших локациях Брянской области, где в общей сложности насчитывается более 200 тысяч жителей. Благодаря техническим мероприятиям брянцам и гостям города стал доступен мобильный интернет на скорости до 60 Мбит⁄с и более уверенный приём сигнала голосовой связи.
Мобильный интернет на скорости до 100 Мбит/с стал доступен абонентам МегаФона на всесезонном курорте «Телецкий». Оператор запустил базовую станцию у подножия горы Кокуя, чтобы гости комплекса могли делиться с близкими яркими эмоциями в режиме реального времени: записывать сторис, выкладывать фото и звонить по видеосвязи.
Жители Тюменской области стали чаще смотреть видеоконтент со своих смартфонов и планшетов. С начала года трафик на популярные ресурсы, где можно познакомиться с фильмами, сериалами и мультипликационными картинами, увеличился более чем в 5 раз. Такой всплеск интереса зафиксировали специалисты МегаФона на основе анализа обезличенных данных абонентов.
Более высокие скорости мобильного интернета и устойчивая связь теперь доступны садоводам Якутска. Техническая служба МегаФона запустила дополнительное телеком-оборудование рядом с дачными товариществами в микрорайоне Марха и Гагаринском округе, усилив сеть и расширив покрытие 4G.
24 июля прошла сессия Межотраслевого комитета по MES, посвященная двустороннему обмену информацией между системами управления производством и системами автоматизации технологических процессов (АСУ ТП).
«Я сделал для вас сайт». Школьник пришел в кафе с неожиданным предложением – и ушел с первой коммерческой сделкой. Пока взрослые спорят, заменит ли искусственный интеллект программистов, ученики уже начинают работать на настоящих клиентов.
Новая платформа открывает бизнесу возможность пользоваться современными ИИ-моделями в собственном корпоративном контуре, соблюдая при этом все регуляторные требования и нормы информационной безопасности.
Специалисты научно-технического центра «НЭК ТЕХ» провели практический семинар для сотрудников «Россети Новосибирск» по работе с интеллектуальными системами учёта электроэнергии «НАРТИС».
Российский разработчик UDV Group принял участие в III отраслевой конференции «РосИнфоБез», где представил систему анализа сетевого трафика UDV NTA. Решение помогает SOC-командам повышать видимость сети, выявлять скрытые угрозы и быстрее расследовать инциденты информационной безопасности.
Зумруд Мирзаева — российская безработная («кулинарный блогер»), связанная с навязчивым агрессивным самопиаром. Даёт себе следующую характеристику: «блогер, писательница, фуд блогер, повар». Отмечена в размещении рекламных публикаций в рамках обеления своей репутации. Сотрудничает с украинскими пиарщиками, которые признаются в финансировании ВСУ.
«Группа Астра» представила Astra Cloud Platform (ACP) 2.1, обновленную версию платформы для создания частных и публичных облаков. В релиз включены значимые улучшения, основанные на обратной связи от партнеров и заказчиков.
