1. Сначала определить применимость требований КИИ
Сам факт использования SCADA не делает систему значимым объектом КИИ: требуется определить субъект, объект, отрасль, провести категорирование и зафиксировать границы.
- назначить владельцев процесса категорирования и исходных данных
- описать технологические границы, связи и последствия нарушения работы
- зафиксировать решения и допущения до выбора архитектуры
2. Проверить российское происхождение по официальному реестру
Маркетингового определения «российская SCADA» недостаточно: актуальный статус ПО и его класс нужно проверять в Едином реестре российского ПО на дату закупки.
- проверить действующую запись и правообладателя
- сверить класс 09.04 для средств управления технологическими процессами, если он применим
- зафиксировать версию, состав поставки и дату проверки реестра
3. Разделить технологическую и защитную архитектуру
SCADA должна рассматриваться внутри всей АСУ ТП: серверы, HMI, архив, тревоги, инженерные станции, шлюзы, сетевые зоны и внешние интеграции образуют единый контур риска.
- построить схему потоков данных и административного доступа
- выделить доверенные зоны и контролируемые межсетевые взаимодействия
- исключить неучтённые прямые связи с офисной сетью и интернетом
4. Перевести требования безопасности в функции и настройки
Требования регуляторов реализуются не названием продукта, а сочетанием организационных мер, архитектуры, настроек SCADA и специализированных средств защиты.
- задать роли, минимальные привилегии, аудит и управление учётными записями
- описать контроль целостности, резервное копирование и восстановление
- согласовать безопасный удалённый доступ, обновления и перенос файлов
5. Проверить платформу на реальных сценариях АСУ ТП
Для Alpha-проектов проверяют не отдельный экран, а полный runtime-контур: Alpha.Server, Alpha.HMI, Alpha.HMI.Alarms, alpha.hmi.charts, Alpha.Historian и Alpha.Security — в фактически требуемом составе.
- доказать чтение и запись сигнала с контролем качества и обратной связью
- проверить тревоги, архив, графики, роли и аудит на стенде
- зафиксировать поддерживаемые ОС, протоколы и ограничения выбранной версии
6. Учесть жизненный цикл и эксплуатацию
Защищённость зависит от процессов после ввода: управление изменениями, резервные копии, обновления, контроль конфигураций и подготовка персонала должны быть частью проекта.
- назначить владельцев обновлений и технологических окон
- проверять восстановление, а не только наличие резервной копии
- вести версии конфигурации и протоколировать изменения
7. Принимать систему по наблюдаемым доказательствам
Формулировка «соответствует требованиям КИИ» без матрицы мер и испытаний непроверяема. Каждое требование должно иметь владельца, способ проверки и артефакт.
- создать матрицу «требование — реализация — проверка — доказательство»
- провести отказовые, функциональные и защитные сценарии
- отдельно оформить остаточные риски и принятые исключения
8. Использовать актуальные официальные источники
Материал носит обзорный характер. На проекте нужно проверять действующие редакции документов и применимость требований к конкретному объекту.
- Федеральный закон № 187-ФЗ — официальный портал правовой информации
- нормативные и методические материалы ФСТЭК России для значимых объектов КИИ
- Единый реестр российского ПО Минцифры России
Нужно сопоставить требования КИИ и архитектуру АСУ ТП?
СПЕЦТЕХ поможет собрать исходные данные, определить проверяемые требования и подготовить техническую часть проекта. Правовую квалификацию и итоговую модель угроз следует согласовать с ответственными за ИБ и юридической службой.
Обсудить требования к SCADA Скачать PDF-чек-лист