Безопасная разработка для SCADA-систем: требования, проектирование и сертификация

Базовым документом, регулирующим вопросы безопасной разработки для объектов КИИ, является приказ ФСТЭК России № 239. Согласно разделу 29.3 этого приказа, при создании, модернизации или ремонте объектов ЗОКИИ внедряемое или обновляемое программное обеспечение должно соответствовать установленным требованиям безопасной разработки.

Эти требования можно разделить на три основных модуля:

1. процесс разработки ПО должен учитывать требования безопасности;
2. разработчик обязан проводить регулярные испытания ПО;
3. должна осуществляться постоянная поддержка безопасности ПО.

Проектирование защищенных SCADA-систем связано с преодолением уникальных технологических ограничений. К ним относятся длительный жизненный цикл ПО, необходимость поддержки устаревшего оборудования и кода (legacy), а также использование промышленных протоколов, которые изначально не были предназначены для работы
в современных условиях киберугроз. Совокупность этих факторов создает идеальные условия для кибератак, поскольку традиционные меры безопасности зачастую невозможно применить без риска нарушения работы критической инфраструктуры.

Стандарты информационной безопасности задают конечную цель, но зачастую не предлагают готовых решений для преодоления специфических ограничений SCADA-системы. Этот разрыв между «предписанным и возможным» требует поиска практических компенсирующих мер, обеспечивающих сопоставимый уровень защиты без нарушения технологического процесса.

Ключевые меры защиты и подходы к их реализации

Ролевая модель доступа. Задача — обеспечить строгое соответствие всех операций пользователей и системных компонентов их производственным функциям. 

Типичным сценарием атаки является попытка оператора или лица, скомпрометировавшего учетную запись инженера, выполнить несанкционированные изменения конфигурации системы, например, датчиков программируемого логического контроллера (ПЛК).

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

Контроль целостности ПО и конфигураций. Эта мера защищает от внедрения вредоносного кода и несанкционированного изменения логики работы контроллеров. Идеальным решением является превентивная проверка цифровых подписей всех конфигураций и компонентов системы.

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

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

Сложность реализации заключается в необходимости обеспечения высокой производительности при работе с большими объемами данных. Дополнительной проблемой является интеграция с legacy-оборудованием, которое не поддерживает централизованное логирование. В качестве компенсирующих мер используются выделенные серверы для сбора событий с применением временных меток и цифровой подписи, а для устаревших устройств — специальные шлюзы, которые пассивно оценивают трафик и преобразуют его
в стандартизированный формат журналов аудита.

Обеспечение постоянной доступности. Мера направлена на повышение отказоустойчивости
и предотвращение атак, таких как DoS и DDoS. Идеальным решением являются кластерные конфигурации критических серверов с автоматическим переключением на горячий резерв.

Основным ограничением является высокая стоимость полного дублирования инфраструктуры, поэтому на практике используется горячее резервирование для наиболее критичных компонентов, а для наименее критичных — холодное. Особое внимание уделяется отказоустойчивости основного шлюза, так как его выход из строя может парализовать взаимодействие между компонентами системы.

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

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

Защита передаваемых данных. Мера направлена на противодействие перехвату и подмене информации (атаки типа «man-in-the-middle»). Современным стандартом является использование протокола TLS 1.3. 

Однако существует фундаментальная проблема с применением устаревших промышленных протоколов (таких как Modbus, OPC Classic), где встроенное шифрование не предусмотрено.
В качестве обходного решения используются VPN-шлюзы, которые создают зашифрованные туннели для агрегирования трафика между сегментами сети или выполняют трансляцию протоколов.

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

Компромиссным решением является использование централизованного API Gateway, который работает как единая точка входа. Такой шлюз управляет контекстом сессии — автоматически разрывает соединение при длительном простое и может требовать дополнительный фактор аутентификации только для выполнения критических команд, что обеспечивает усиление безопасности без нарушения операционной деятельности.

Таким образом, проектирование защиты для SCADA-систем — это поиск взвешенных архитектурных компромиссов, направленных на создание многоуровневой системы безопасности, которая остается работоспособной в реальных условиях промышленной эксплуатации.

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

Базовыми документами для сертификации являются:

• Приказ ФСТЭК России № 76 «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий»;
• Методика выявления уязвимостей и недекларированных возможностей (ДСП);
• ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»;
• для систем АСУ ТП — Приказ ФСТЭК России № 31 «Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды»;
• для систем КИИ — Федеральный закон № 187-ФЗ и Приказ ФСТЭК России № 239.

До подачи заявки организация должна получить необходимые лицензии ФСТЭК России, например, на разработку СЗИ, и убедиться в соответствии продукта требованиям и полноте документации.

1. Определение уровня доверия. В приказе ФСТЭК России № 76 установлено соответствие между уровнями доверия и категориями систем различных типов. Существует шесть уровней доверия, где шестой уровень является самым низким, а первый — самым высоким.

Начиная с третьего уровня, предъявляются требования к средствам защиты информации, которые обрабатывают конфиденциальную информацию, связанную с грифом «секретно». Ключевой этап подготовки к сертификации — определение необходимого уровня доверия.

2. Определение схемы сертификации. Необходимо выбрать подходящую схему: для единичного образца (если планируется применение одной копии продукта), для партии (определенное количество копий для конкретного заказчика) или для серийного производства
(при отсутствии четких границ по количеству экземпляров).

3. Подготовка минимального комплекта документов для подачи заявки. В него входят формуляр, технические условия или техническое задание, а также список заимствованных компонентов с определением того, находятся ли эти компоненты на поверхности атаки
или реализуют функции безопасности.

4. Заключение договора с испытательной лабораторией и подача заявки в ФСТЭК России.

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

6. Оформление сертификата соответствия. Организация и контроль всей процедуры сертификации осуществляется ФСТЭК России. Процедура сертификации завершается выдачей сертификата соответствия сроком действия на 5 лет.

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