Учебно-лабораторный стенд на базе отечественного ПО MasterSCADA 4D. Функции информационной безопасности в версии Enterprise. Часть 2

Учебно-лабораторный стенд на базе отечественного ПО MasterSCADA 4D. Функции информационной безопасности в версии Enterprise. Часть 2

Гаврилов Александр, Деркач Александр, Киселёва Ольга, Лытаев Андрей, Маценко Вячеслав «СТА», №1 / 2025 / Январь 2025

Учебно-лабораторный стенд на базе отечественного ПО MasterSCADA 4D. Функции информационной безопасности в версии Enterprise. Часть 2

Специалист по информационной безопасности (ИБ) – в настоящее время одна из наиболее востребованных IT-специальностей. В том числе этому способствуют требования к созданию систем безопасности значимых объектов критической информационной инфраструктуры РФ. В этой статье изложена концепция развития учебно-лабораторного комплекса, созданного в Институте Физики Казанского (Приволжского) федерального университета совместно со специалистами компании «Прософт». Описание комплекса было приведено в журнале СТА № 4 за 2024 год. Рассматриваются вопросы, связанные с обеспечением ИБ на промышленных объектах. Особое внимание уделено рассмотрению руководящих документов и мер защиты, используемых в области ИБ АСУ ТП. В статье сделан обзор функций информационной безопасности, входящих в состав ПО MasterSCADA 4D версии Enterprise.

Авторы благодарят компанию МПС софт и лично руководителя отдела защиты информации и безопасной разработки ПО Константина Викторовича Белошапко за предоставленные материалы, идеи и поддержку.

Введение

Эффективное обеспечение информационной безопасности промышленных объектов требует комплексного подхода, включающего в себя следование требованиям нормативно-правовых документов, реализацию мер защиты организационного и технического характера на разных уровнях АСУ ТП. 

Такой системный подход применим и на учебном стенде, для обучения по дисциплинам «Технология построения защищённых автоматизированных систем», «Экспертные системы комплексной оценки безопасности автоматизированных информационных и телекоммуникационных систем», «Технология обеспечения информационной безопасности объектов», «Управление информационной безопасностью» и т.д. Изучение этих дисциплин возможно проводить по сле­дующему сценарию: 
  • краткий обзор государственных стандартов и федеральных законов в области обеспечения ИБ в промышленных системах автоматизации;
  • изучение особенностей АСУ ТП как объекта кибератак (объекты защиты, источники угроз, векторы атак);
  • рассмотрение мер ИБ-защиты АСУ ТП, регламентированных нормативно-правовыми документами;
  • получение практических навыков в области ИБ с применением средств защиты, входящих в состав программных и аппаратных компонентов сис­темы автоматизации;
  • применение специализированных наложенных средств защиты информации (СЗИ).
Изложенная выше концепция проиллюстрирована на рис. 1. Рассмотрим детальнее основные её части.

Краткий обзор стандартов и федеральных законов в области ИБ АСУ ТП

В Российской Федерации обеспечение ИБ АСУ ТП регламентируется Федеральным законом № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», приказами ФСТЭК России от 14.03.2014 № 31, от 21.12.2017 № 235, от 22.12.2017 № 236, от 25.12.2017 № 239 и Указом Президента РФ от 30.03.2022 № 166 по обеспечению технологической независимости. Также  в области информацион­ной безопасности промышленных систем автоматизации существует ряд международных стандартов, в том числе серия стандартов IEC 62443. Ряд этих стандартов были гармонизированы в России.

Описанные в данных нормативных документах требования к обеспечению защиты информации и соответствующие меры защиты могут быть использованы в разных системах промышленной автоматики. Инциденты нарушения информационной безопасности возможны в любых промышленных системах автоматизации. Таким образом, данные документы необходимо рассматривать как методические при изучении основ построения защищённых АСУ ТП.

Изучение особенностей информационной безопасности АСУ ТП 

Анализ рисков, связанных с уязвимостью технологических решений на объектах АСУ ТП, можно начать с отчёта ФСТЭК России (Федеральная служба по техническому и экспортному контролю) от 3 октября 2024 года «Реализация законодательства ОБ КИИ. Реализация технических мер по повышению защищённости. Особенности АСУ ТП» (рис. 2).

В нём учтены в том числе и международные практики, которые показывают, что промышленные протоколы передачи технологической информации строились без учёта специфики информационной безопасности – в них нет механизмов защиты передаваемой информации (HART, Profibus, Modbus и др.), отсутствуют или слабо представлены механизмы идентификации и аутентификации. Особо следует обратить внимание на обновления программного обеспечения. Например, во многих широко известных SCADA-системах по умолчанию используются сервисы, которые обращаются в сеть Интернет для своевременного обновления. При технологическом импортозамещении стоит учитывать эти факторы и вводить применение дополнительных мер по защите. 

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

ФСТЭК России размещает актуальные сведения об уязвимостях и угрозах информационной безопасности в АСУ ТП на специальном ресурсе, имеющем название Банк данных угроз (БДУ) АСУ ТП [1].  В соответствии с представлением на сайте (рис. 3) и пользовательским соглашением ресурса данная информация представляет собой обобщённый перечень основных угроз безопасности информации, потенциально опасных для АСУ ТП. Объекты воздействия определяются в БДУ АСУ ТП следующим списком [2]:
  • ОА.001 Автоматизированное рабочее место оператора (диспетчера)
  • ОА.002 Автоматизированное рабочее место инженера (инженерная станция)
  • ОА.003 Промышленный сервер
  • ОА.004 Сервер архивов
  • ОА.005 Панель оператора
  • ОА.006 Программируемый логический контроллер
  • ОА.007 Программируемый логический контроллер системы противоаварийной защиты
  • ОА.008 Датчики и исполнительные механизмы
  • ОА.009 Съёмный носитель информации
  • ОА.010 Устройство промышленного Интернета вещей
  • ОА.011 Активное сетевое оборудование
  • ОА.012 Средства защиты информации
  • ОА.013 Мобильное устройство

Каждый из указанных объектов воздействия имеет один или несколько компонентов, в направлении которых могут быть направлены векторы информационной атаки. Типы и группы компонентов объектов воздействия приведены в обобщённой табл. 1. С более детальным их описанием можно ознакомиться на сайте БДУ АСУ ТП. 

В качестве примера на рис. 4 в наглядном виде представлено описание группы «К.4.1 Привилегированные пользователи». По информационной карточке «К.4.1.1. Инженер АСУ ТП», расположенной на сайте регулятора  [3], можно определить, в какие объекты воздействия он может входить, ознакомиться с потенциальными способами реализации угроз для этого компонента, а также определить возможные меры защиты.

Меры ИБ-защиты АСУ ТП

С чего начинать построение системы защиты? Эксперты [4] отмечают, что первый этап может быть самым простым и доступным, поэтому первоочередные мероприятия заключаются в настройке встроенного в АСУ ТП функционала безопасности: механизмов контроля и управления доступом, регистрации и учёта, резервного копирования настроек и данных, средств обеспечения сетевой безопасности и т.д. 

Этот же тезис подчёркивается и в приказе № 31 ФСТЭК: в качестве средств защиты информации в первую очередь подлежат рассмотрению механизмы защиты (параметры настройки) штатного программного обеспечения автоматизированной системы управления.

В табл. 2 приведены группы мер защиты, определённые приказами ФСТЭК № 31 и № 239. С перечнем мер защиты внутри каждой группы можно ознакомиться в первоисточниках, т.е. непосредственно в этих документах, опубликованных на сайте ФСТЭК [5, 6]. 
Кроме того, на ресурсе БДУ АСУ ТП ФСТЕК для каждой меры защиты [7] опубликована информационная карточ­ка, содержащая:
  • описание меры;
  • перечень потенциальных блокируемых угроз безопасности информации;
  • блокируемые способы реализации угроз.

Функции информационной безопасности в версии MasterSCADA 4D Enterprise

Разработчики пакета программ MasterSCADA 4D включили в программное обеспечение набор инструментов, позволяющих реализовать средствами пакета некоторые меры защиты, определённые приказами ФСТЭК № 31 и № 239 (табл. 2). В частности, хорошо представлен инструментарий для групп: 
  • I Идентификация и аутентификация (ИАФ);
  • II Управление доступом (УПД);
  • V Аудит безопасности (АУД);
  • VIII Обеспечение целостности (ОЦЛ);
  • XI Защита информационной (автоматизированной) системы и её компонентов (ЗИС).
Ряд базовых мер защиты вводится в проект путём настроек элементов группы «Безопасность» дерева проекта (рис. 5).

Это создание учётных записей пользователей, создание и настройка ролей, настройка прав доступа и т.п. Этот набор мер может быть обогащён путём использования встроенных в Master­SCADA 4D библиотечных функциональных блоков (ФБ). Встроенные ФБ позволяют: создавать, контролировать, модифицировать учётные записи на этапе исполнения проекта; создавать и модифицировать роли на этапе исполнения проекта и т.п. Далее кратко опишем ряд встроенных возможностей пакета MasterSCADA 4D по реализации мер защиты. Это описание нисколько не претендует на детальное изложение вопроса. 

Полное описание функций ПО содержится в руководстве по эксплуатации и онлайн-справке [8]. Наша задача – соотнести текущие возможности пакета MasterSCADA 4D с требованиями регулятора и рекомендовать инженерам использование этих возможностей на практике.

Идентификация и аутентификация

Создание учётных записей на этапе разработки проекта

В MasterSCADA 4D основные опции ИБ сосредоточены в группе «Безопасность» дерева проекта (рис. 5). Здесь, в разделе «Пользователи», можно добавить в проект нового пользователя (рис. 6), назначить ему в панели свойств пароль (необязательно) (рис. 7) и установить права доступа (рис. 8). Если была создана хотя бы одна учётная запись пользователя, в момент подключения клиента к среде исполнения на экране клиентского приложения появляется диалог «Вход в систему» с предложением выбрать пользователя и ввести пароль (рис. 9).




Создание учётных записей на этапе исполнения проекта

Дополнительную гибкость управления учётными записями пользователей на этапе исполнения проекта предоставляют встроенные в среду разработки функциональные блоки (табл. 3). Они позволяют добавлять и удалять новых пользователей, изменять имя и пароль пользователя и т.п. Например, на рис. 10 показан диалог добавления новых и удаления существующих учётных записей пользователей на этапе исполнения, реализованный с применением ФБ UsersAdd и UsersDelete.


В результате работы ФБ UsersAdd создаётся файл Users – уникальный GUID проекта внутри рабочей папки исполнительной системы. Файл содержит записи данных новых пользователей. Файл закодирован. Взамен файла Users можно использовать внешнюю базу данных PostgreSQL.

Интеграция с Active Directory и LDAP 

В MasterSCADA 4D можно объединить встроенную систему безопасности и базы данных службы каталогов двух типов:
  • Active Directory Windows – для тех проектов MasterSCADA 4D, где используется среда исполнения, расположенная на устройстве с ОС Windows;
  • службы каталогов, основанных на использовании кроссплатформенного протокола LDAP (Lightweight Directory Access Protocol) – для тех проектов MasterSCADA 4D, где используется среда исполнения, расположенная на устройстве с ОС Linux.
Соответствующие настройки для использования такого способа идентификации пользователей в проекте показаны на рис. 11.

Установление характеристик пароля, устойчивых к перебору

Политика управления паролями связана со следующими настройками безопасности в проекте MasterSCADA 4D (рис. 12).

  • Минимальная длина пароля. Определяется минимальное количество символов при настройке пароля в режиме исполнения.
  • Количество неповторяемых паролей. Указывает, сколько раз пользователь должен задать неповто­ря­ющийся пароль. Если указано зна­чение 0, то ограничения отсут­ствуют. 
  • Использовать сложный пароль. Определяет состав символов при настройке пароля в режиме исполнения. Если флаг установлен, то пароль должен содержать хотя бы одну цифру, одну прописную и одну строчную букву.
  • Пароль должен содержать спецсимвол. Определяет наличие спецсимвола в пароле. Примеры спецсим­волов: ~!@#$%^&*()-—_+={}[]/\|:;'"<>,.?.
  • Срок действия пароля. Определяет срок действия пароля пользователя. Если время действия текущего пароля достигло указанного, то при начале очередной сессии пользователя появится сообщение, и пользователь не будет допущен к работе до тех пор, пока пароль не будет изменён в режиме исполнения.

Управление доступом

В состав мер по обеспечению безопасности, определённых приказами ФСТЭК № 31 и № 239, входит группа мер защиты информации «Управление доступом» (УПД). Эффективные инструменты для реализации ряда мер УПД включены разработчиками в состав пакета MasterSCADA 4D:
  • УПД. 1 Управление учётными запися­ми пользователей; 
  • УПД. 2 Реализация модели управле­ния доступом; 
  • УПД. 4 Разделение полномочий (ролей) пользователей; 
  • УПД. 5 Назначение минимально не­об­ходимых прав и привилегий;
  • УПД. 6 Ограничение неуспешных попыток доступа в информационную (автоматизированную) систему; 
  • УПД. 9 Ограничение числа параллель­ных сеансов доступа     
  • УПД. 10 Блокирование сеанса доступа пользователя при неактивности
Коротко остановимся на этих инструментах.

Модели управления доступом

В группе «УПД.2 Реализация модели управления доступом» перечислены три рекомендованные регулятором модели управления доступом: дискреционная, ролевая, мандатная. 

Реализация дискреционной модели управления доступом предусматривает управление доступом субъектов доступа к объектам доступа на основе идентификационной информации субъекта и для каждого объекта доступа – списка, содержащего набор субъектов доступа (групп субъектов) и ассоциированных с ними типов доступа.

Реализация ролевой модели управления доступом предусматривает управ­ление доступом субъектов доступа к объектам доступа на основе ролей субъектов доступа (совокупность действий и обязанностей, связанных с определённым видом деятельности).

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

В MasterSCADA 4D предусмотрена комбинация дискреционной и ролевой моделей управления доступом с явным акцентом на ролевой. Остановимся на деталях реализации.

Права доступа

Настраивать права доступа для пользователей в MasterSCADA 4D можно как индивидуально, так и для группы пользователей (ролей). 

Таблица для просмотра и редактирования прав доступа отдельных пользователей и ролей доступна в панели «Свойств» группы «Безопасность» дерева проекта (рис. 13, 14). Для доступа к таблице необходимо переключиться в режим просмотра прав доступа. В выпадающем списке содержится перечень доступных к настройке прав. Для предотвращения случайных нажатий необходимо установить флаг в столбце «Подтверждение». Тогда в режиме исполнения, прежде чем выполнится изменение связанного параметра, появится диалоговое окно. Для фиксации выполненных действий пользователей необходимо установить флаг в столбце «Журнал». 


Для придания большей гибкости механизму назначения прав разработчики предусмотрели добавление в проект группы прав. Группы прав позволяют переопределять право «Управление» для графических элементов из категории «Диалог», таких как кнопки, текстовый ввод и т.д. После назначения группы прав на графический элемент право «Управление» перестаёт действовать на него, и начинает действовать группа прав (рис. 15).

Ролевая модель управления доступом

Наиболее полно в MasterSCADA 4D реализована ролевая модель управления доступом. Как правило, роли пользователей создаются для того, чтобы разделить пользователей проекта, работающих в режиме исполнения, по категориям, например: операторы, инженеры, начальники смен и т.п. 

Роли создаются и модифицируются в основном на этапе разработки проекта. В группе «Безопасность» для этого существует подгруппа «Роли» (рис. 16). Для лицензии Enterprise возможно создание ролей в режиме исполнения с помощью программирования встроенных библиотечных функциональных блоков (табл. 4). 


Например, на рис. 17 изображён вид в редакторе ФБД функционального блока UsersRoleAdd, который служит для добавления ролей пользователей и их настроек в режиме исполнения.

Ограничение неуспешных попыток доступа в систему

Меру защиты, связанную с ограничением неуспешных попыток доступа, можно реализовать соответствующими настройками свойств группы «Роли» элемента «Безопасность» (рис. 18, а).

Количество последовательных неуспешных попыток входа. Определяет, сколько раз пользователь может попытаться неуспешно начать сессию в клиенте визуализации. 

Если установлено значение 0, то ограничение отсутствует. Данная настройка применяется только к пользователям, созданным в режиме исполнения.

Продолжительность блокировки при превышении количества неуспешных попыток входа. Определяет интервал времени, в течение которого пользователь, который не смог авторизоваться за количество попыток, разрешённое в предыдущем пункте, не сможет повторить попытки авторизоваться в клиенте визуализации. 

Ограничение числа параллельных сеансов доступа

Возможность авторизоваться и запустить параллельные сеансы с нескольких клиентов визуализации определяется настройкой «Запрет одновременного входа одного пользователя» (рис. 18, б).

Если флаг установлен, то возможны следующие варианты.
  • В случае если есть активная сессия для этого пользователя с того же самого адреса, то закрывается прошлая сессия, создаётся новая.
  • Если текущая сессия запущена на другом устройстве, с другим адресом, то в случае, если она неактивна больше 10 секунд, она закрывается и создаётся новая. Если от клиента визуализации продолжают приходить запросы к исполнительной системе, то возвращается ошибка авторизации.

Предоставление пользователям прав доступа к объектам доступа, основываясь на задачах, решаемых пользователями

Предоставление пользователям прав доступа к системе для выполнения определённых задач можно ограничить временем смены. Авторизация пользователя будет возможна только в отрезок времени, заданный по каждому дню недели. Сессия будет завершена после окончания смены, что активируется при установлении флага настройки «Завершать сеанс после окончания смены» (рис. 18, в). Время начала и конца смены по дням недели задаётся входным параметром – массивом структур TimeIntervals в ФБ UsersSet­AllowedTime (рис. 19). 

Блокирование сеанса доступа пользователя при неактивности

Интервал времени, по истечении которого происходит завершение сессии, если пользователь не совершает никаких действий в окне (клики мыши, клавиатурный ввод), определяется настройкой «Время бездействия» (рис. 18, г).

Обеспечение целостности 

Контроль целостности программного обеспечения

Параметры проверки целостности программного обеспечения задаются в процессе разработки проекта MasterSCADA 4D в панели свойств элемента «Безопасность». Для активации соответствующих функций требуется установить флажок в один или несколько полей следующих настроек.
  • Контроль целостности проекта. Если флаг установлен, то в конфигурацию проекта включается файл cfg_files.dat, зашифрованный списком MD5 контрольных сумм всех загружаемых из среды разработки файлов конфигура­ции узла. 
  • Блокировать запуск при неуспешной проверке проекта. Определяет порядок работы при неуспешной проверке проекта. Если флаг установлен и при старте режима исполнения найдено отличие контрольных сумм файлов от прописанных в cfg_files.dat, то возникает ошибка за­пуска узла. 
  • Период проверки целостности проекта. Определяет период, с которым будет происходить дополнительный конт­роль целостности после старта режима исполнения.
  • Контроль целостности ПО. Активирует контроль целостности программных файлов исполнительной системы.
  • Блокировать запуск при неуспешной проверке ПО. Если флаг установлен, то исполнительная система не запус­тится.
  • Период проверки целостности ПО. Определяет период, с которым будет происходить дополнительный контроль целостности после старта режима исполнения.
Для управления контролем целостности ПО или проекта, а также получения списка отличий используется Функциональный блок FileIntegrity­Control (рис. 20). 

Его входной параметр «CheckType» может принимать два значения: Project (выполняется проверка целостности проекта) или System (выполняется проверка целостности исполнительной системы). 
 
Выходной параметр «FileInfo» выдаёт описание по каждому проверяемому файлу. Данный выход представляет собой массив структур, которые содержат поля: FileName – имя проверяемого файла, CheckSumFlag – признак соответствия контрольной сумме, CheckSum – полученная контрольная сумма, EtalonCheck­Sum – эталонная контрольная сумма. 

ФБ FileIntegrityControl также имеет выходные параметры: «Running» (отображает статус процесса проверки), «Comp­leted» (сигнализирует об окончании проверки) и «Error» (указывает текст ошибки, если не удалось выполнить проверку).

Регистрация событий безопасности

По умолчанию сообщения типа «Сообщение ИБ» попадают в общий архив сообщений. Однако в ПО MasterSCADA 4D есть возможность формирования отдельной базы данных. Для этих целей в группе «Безопасность» создаётся «Архив сообщений» ИБ (рис. 21). 

На рис. 22 показана панель свойств элемента «Архив сообщений». 

БД будет иметь по умолчанию имя security_events.db и тип локальной БД – sqlite. Для работы с внешними базами данных PostgreSQL или MSSQL следует выбрать соответствующий тип БД из выпадающего списка и указать параметры подключения (адрес сервера, номер порта, атрибуты пользователя).

Виды событий безопасности

1) Сообщения контроля целостности: 
«Ошибка при проверке целостности проекта»
«Ошибка при проверке целостности ПО»
Если проверка целостности будет неудачной, то текст сообщения будет включать в себя код ошибки и список файлов, которые проверку не прошли. Вначале идёт список файлов с отличиями, затем идут пары <код ошибки> <имя файла>.

Коды ошибок:
1 – Файл отсутствует
2 – Ошибка чтения файла
3 – Ошибка в пути к файлу
4 – Несоответствие MD5 сумм
5 – Ошибка дешифрации файла

2) Сообщения по авторизации пользователя. 
«Вход в систему» – регистрация успешного запуска сеанса работы. 
«Неуспешная попытка входа» – если не пройдена авторизация. Для сообщений данного типа добавляется причина его возникновения:
«Неудачная смена пароля»
«Необходимо сменить пароль»
«Пользователь заблокирован»
«Срок действия пароля истёк»
«Недопустимое время логина»
«Недопустимый адрес логина»

3) Сообщения о блокировке пользователя при превышении количества последовательных неуспешных попыток входа.
Разработчик системы может задать количество последовательных неуспешных попыток входа в свойствах группы «Роли» элемента «Безопасность». Вид формируемого сообщения для такого события:
«Пользователь» + login + «заблокирован по превышению попыток логина».

4) Сообщения об ошибке ключа защиты лицензии. 
Система MasterSCADA 4D периодически проверяет доступность ключа в режиме исполнения. Проверка по умолчанию производится раз в 30 минут.

В случае если три проверки подряд были неудачными, то работа в режиме исполнения прекращается. При каждой неудачной проверке формируется сообщение, в котором указывается оставшееся время, которое исполнительная система может проработать без ключа.

«Ключ не найден. Проект остановлен».

«Ключ не найден. Проект будет остановлен через %d минут».

Создание гетерогенной среды

Под созданием гетерогенной среды понимается применение различных типов общесистемного, прикладного и специального программного обеспечения в защищённой информационной (автоматизированной) системе.

Cреда исполнения MasterSCADA 4D поддерживает большинство распространённых в промышленности операционных систем, таких как Windows, Linux, Эльбрус. В частности, на сайте ГК «Астра» указано, что платформа и клиент визуализации MasterSCADA 4D Client корректно работают под управлением ОС Astra Linux. Для применения на производстве и/или в учебном процессе можно использовать рекомендации производителя – компании МПС Софт, оформленные в виде целевого бесплатного курса «Основы Linux для Master­SCADA» [9], описывающего порядок установки Linux, среды исполнения MSRT и клиента визуализации HMI, настройки безопасности, проведение диагностики по стандартным и расширенным лог-файлам.

Защита информации при её передаче по каналам связи

В MasterSCADA 4D предусмотрено использование защищённых протоколов при создании многоуровневой клиент-серверной архитектуры. Для взаимодействия WEB-сервера среды исполнения MasterSCADA 4D и клиентов визуализации/управления предоставляется возможность использовать протокол HTTPS (HyperText Transfer Protocol Secure) – безопасный протокол передачи данных, поддерживается шифрование посредством криптографических протоколов SSL и TLS. 

Для обмена данными внутри системы промышленной автоматизации может использоваться платформонезависимый стандарт OPC UA. Для того чтобы проект MasterSCADA 4D выступал в роли клиента OPC UA, необходимо в группу узла «Протоколы» добавить соответствующий протокол (рис. 23). Политика безопасности клиента OPC UA позволяет использовать типы шифрования Basic128Rsa15, Basic256, Basic256­Sha256. 

ПО MasterSCADA 4D может выступать также и как сервер OPC UA (рис. 24), поддерживая режимы чтения и подписки.

Лирическое отступление

Многие тянут с внедрением средств защиты информации на своих объектах, полагаясь на русский «авось» или «не трогай, пока работает». Но в настоящих реалиях незнание или игнорирование информации в этой области может привести к серьёзным последствиям. Как минимум, могут быть сделаны замечания при проведении государственной проверки  регулятором (на сайте ФСТЭК России ежегодно обновляются планы проверок компаний по вопросам лицензионного контроля).  Как максимум – остановка производства по инцидентам, связанным с атаками злоумышленников. Для понимания современных реалий эксперты рекомендуют периодически анализировать отчёты регуляторов, а также лидеров в области информационной безопасности. Одним из лидеров оперативного информирования по типам, рекомендациям и вариантам защиты от инцидентов является компания «Лаборатория Касперского». На своих вебресурсах она периодически выкладывает обзоры основных международных инцидентов промышленной кибербезопасности. Для примера, за I квартал 2024 года в общей сложности зафиксировано 30 инцидентов, 37% пострадавших сообщили о нарушении операционной деятельности или задержках в отгрузке продукции в результате инцидента. Две трети жертв киберпреступников относятся к сфере производства [10].

Заключение. Перспективы развития учебного стенда

В данной статье мы постарались соотнести возможности пакета Master­SCADA 4D в части функций информационной безопасности с требованиями регулятора, изложенными в документах  [5, 6]. Обобщённые результаты этой работы приведены в табл. 5. 

Именно  этот подход положен авторами в основу концепции стенда. Планируется и дальше развивать и проводить поэтапную модернизацию лаборатории. Опишем некоторые направления.

1) Учебно-методическая деятельность:
  • разработка лабораторных работ по применению мер защиты ИБ;
  • подготовка к защите  магистр. диссертации «Комплекс многоуровневой защиты систем промышленной автоматизации»;
  • развитие лаборатории с учётом  рекомендаций нового ПРОФСТАНДАРТА МИНТРУДА для специалистов по защите ИБ в автоматизированных системах.
2) Техническое развитие и расширение состава стенда:
  • перенос модулей исполнения Master­SCADA 4D на отечественную ОС Astra Linux. Изучение особенностей использования этой ОС в проектах АСУ ТП;
  • внедрение в состав стенда специализированных наложенных СЗИ (межсетевые экраны, системы обнаружения вторжений);
  • интеграция с современными технологиями машинного обучения и искусственного интеллекта для изучения возможностей более эффективного применения мер защиты.
Отдельно следует отметить, что в составе программной платформы Master­SCADA 4D нет иностранного проприетарного программного обеспечения, которые могут привести к невозможности его использования в соответствии с требованиями регуляторов и современным российским трендом по технологической независимости. Также производитель программного обеспечения MasterSCADA 4D (Компания ООО «МПС софт») уделяет большое внимание вопросам безопасной разработки программного обеспечения – в настоящее время готовится Руководство по безопасной разработке, испытания по статистическому анализу исходного кода, фаззинг-тестирования. Результаты этой работы будут доступны в ближайшее время. Дополнительную информацию можно запросить через официального дистрибутора этого программного обеспечения – компанию ПРОСОФТ (info@prosoft.ru).

Внимание, важная информация!

20 декабря 2024 года, во время подготовки этой статьи, вышла новая версия ГОСТ Р 56939 («Безопасная разработка ПО»), предъявляющая более жёсткие требования к разработке и контролю ПО, включая процедуры динамического и статического анализа, фаззинг-тестирования кода программного обеспечения российского производства, используемого для обеспечения безопасности значимых объектов критической информационной инфраструктуры РФ (Утверждены приказом ФСТЭК России от 25 декабря 2017 г. № 239). 

Компания «МПС софт» в феврале 2025 года провела успешные испытания своего продукта на соответствие требованиям приказа ФСТЭК 239. Специалисты могут ознакомиться с протоколом прохождения испытаний MasterSCADA 4D по отдельному запросу в компанию ПРОСОФТ (info@prosoft.ru).

Литература

  1. Банк данных угроз АСУ ТП. URL: https://bdu­asutp.fstec.ru/ (дата обращения: 10.06.2024).
  2. Банк данных угроз АСУ ТП. Объекты воздействия. URL: https://bduasutp.fstec.ru/#/threats/influence-objects (дата обращения: 10.06.2024).
  3. Банк данных угроз АСУ ТП. Компоненты. К.4.1.1 Инженер АСУ ТП. URL: https://bduasutp.fstec.ru/#/components-view/3afe8b69-7db5-4b3d-8738-f7078b96c968?from_list=1&amp...=, (дата обращения: 10.06.2024).
  4. Мухаметшин А. Как защитить АСУ ТП: экспертиза Innostage // СТА. 2023. № 3. 
  5. Приказ ФСТЭК России от 25.12.2017 № 239. URL: https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-25-de­kabrya-2017-g-n-239.
  6. Приказ ФСТЭК России от 14.03.2014 № 31. URL https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-14-marta-2014-g-n-31.
  7. Банк данных угроз АСУ ТП.  Меры защиты. URL: https://bduasutp.fstec.ru/#/bdu/protec­tion-measures (дата обращения: 10.06.2024).
  8. MasterSCADA 4D справочная система, web-версия. URL: https://support.mps-soft.ru/Help-web/index.html.
  9. Курс 3519 «Основы Linux для MasterSCAD». URL: https://lms.iek.group/content/info/7275.
  10. Краткий обзор основных инцидентов промышленной кибербезопасности за первый квартал 2024 года. URL: https://ics-cert.kas­persky.ru/publications/reports/2024/06/03/q1-2024-a-brief-overview-of-the-main-...
  11. Приказ министерства труда и социальной защиты Российской Федерации от 14.09.2022 № 525н «Об утверждении профессионального стандарта “Специалист по защите информации в автоматизированных системах”». URL: https://docs.cntd.ru/document/352000921#6560IO  .
© СТА-ПРЕСС, 2025
Другие публикации